Building Block Computer (Was Re: 16-bit C64/128?)
in [Commodore]
|
Prev: Building Block Computer (Was: Re: 16-bit C64/128?)
Next: Reward: Open Hacker Challenge Crack this BBS and get PAID!
From: BruceMcF on 18 Apr 2008 04:45 On Apr 16, 3:20 am, christianlott1 <christianlo...(a)yahoo.com> wrote: > ok, let me bump this thread up just a second. > the building block computer mentioned a few months ago.. > initially this was assumed (by me at least) to be parallel backplane > bus. why not serial SPI/I2C? those real-chip/fpga modules could just > be strung on a SPI bus with parallel/serial converters. > i've also read about a solution for chip timing differences over the > same bus that doesn't involve an arbiter per say. back in the 70s > there was this thing called the Honeywell Megabus. a WRITE was one op/ > cycle. a READ was two. the read was two because each chip on the bus > would resolve the read request in it's own good time and the WRITE the > data to the requestor when it was able. > ie. a read is a write, just in the opposite direction. > the article was a bit more complicated than what i'm relating because > each chip had an address, but that's just memory mapping, in this case > (SPI) -serial memory mapping-. Yes, if a WRITE is one cycle, READ two, then you can crank up the serial clock to 16 time or 32 times the system clock, and do, when the system clock transitions low: WRITE: 8 serial clocks Address_write 8 serial clocks Data_Write .... that data will be available to any device listening to that address when the system clock transitions high. READ: Clock 1: 8 serial clocks Address_write 8 serial clocks idle READ: Clock 2 8 serial clocks idle 8 serial clocks Data_Read Now there is no need for anything but the shift registers to be able to run at the serial clock pace, they all can run at the system clock pace. On combining SPI and I2C, I described the start bit wrong, but for the base level, I think the spec was write. I2C Start bit is FIRST Data pulled low, THEN Serial Clock pulled low. That's why the SPI Select as the I2C Serial Clock works ... in an SPI transaction, the select is always pulled low FIRST. Whenever SPI select is high, there should never be date put onto the Master-in serial line, so the SPI transactions will never create an I2C start bit. And then if the bus controller *knows* that its a shared bus, and holds the SPI serial clock line high for I2C transactions, there's no way an SPI device will either send or receive data while its serial clock is held high. That would need some extra support electronics to plug a C64 into that bus, but that's part of the price of admission for the I2C bus ... it has a simple system for working out when a bus master can get onto the bus and when devices have to listen to the bus, but not something that a CIA can do at 1MHz without add'l support.
From: christianlott1 on 18 Apr 2008 15:33 Just so we're on the same page.. You're giving the details of connecting the C64 User Port to an extended SPI/I2C bus. You've said that SPI or I2C could not be fast enough to simulate an internal C64 bus. Correct? Without brining in PCIe, is there _any_ possible way to simulate an internal C64 bus in serial fashion? I assumed that if the clock is fast enough and you had serial to parallel converter chips that could run that fast - you could definitely simulate a 1mhz bus serially. Maybe one line for data, two lines for address, one line for control, one for clock? If it needed to be expanded for wider address and data range it would be one line per byte width.
From: BruceMcF on 18 Apr 2008 23:31 On Apr 18, 3:33 pm, christianlott1 <christianlo...(a)yahoo.com> wrote: > Just so we're on the same page.. > > You're giving the details of connecting the C64 User Port to an > extended SPI/I2C bus. > > You've said that SPI or I2C could not be fast enough to simulate an > internal C64 bus. Correct? > > Without brining in PCIe, is there _any_ possible way to simulate an > internal C64 bus in serial fashion? > > I assumed that if the clock is fast enough and you had serial to > parallel converter chips that could run that fast - you could > definitely simulate a 1mhz bus serially. > > Maybe one line for data, two lines for address, one line for control, > one for clock? > > If it needed to be expanded for wider address and data range it would > be one line per byte width. Your responding to what would have been a self-follow-up, if: <8f9e8a85-f2dc-45d7-9254-09f205e09c0b(a)d1g2000hsg.googlegroups.com> .... had gone up quicker on my end. What you said above is basically what I said in the longer original. That is, the standard I2C and SPI are device interconnect buses, not system internal buses, but if you rolled your own, you could have: Serial: Address high Serial: Adress low / data Mode0:Mode1 = address, read data, write data, idle serial clock system clock with serial clock 16x the system clock. If the R/W devices can bring up data in a single serial clock, then you can run a C64 type single cycle Read or Write. With a 1 clock write, 2 clock read system, then all the devices need only run at the pace of the system clock (1/16 the serial clock), you can have a 1 clock write, 2 clock read system The basic bottleneck is that no data can be asserted until all bits of the address have been asserted, which is why for byte-wide transfers the serial clock has to be 16x rather than 8x.
From: christianlott1 on 19 Apr 2008 00:18 On Apr 18, 10:31 pm, BruceMcF <agil...(a)netscape.net> wrote: > What you said above is basically what I said in the longer original. > That is, the standard I2C and SPI are device interconnect buses, not > system internal buses, but if you rolled your own, you could have: > > Serial: Address high > Serial: Adress low / data > Mode0:Mode1 = address, read data, write data, idle > serial clock > system clock > > with serial clock 16x the system clock. If the R/W devices can bring > up data in a single serial clock, then you can run a C64 type single > cycle Read or Write. With a 1 clock write, 2 clock read system, then > all the devices need only run at the pace of the system clock (1/16 > the serial clock), you can have a 1 clock write, 2 clock read system > > The basic bottleneck is that no data can be asserted until all bits of > the address have been asserted, which is why for byte-wide transfers > the serial clock has to be 16x rather than 8x. It would be a cool - and expandable. Going back to Jim's idea: With an fpga running a TIA core on the VIC2, you could turn your C64 into an Atari VCS emulator, or maybe emulate many 8 bit computers of the era.
From: BruceMcF on 21 Apr 2008 14:53
On Apr 19, 12:18 am, christianlott1 <christianlo...(a)yahoo.com> wrote: > On Apr 18, 10:31 pm, BruceMcF <agil...(a)netscape.net> wrote: > > > > > What you said above is basically what I said in the longer original. > > That is, the standard I2C and SPI are device interconnect buses, not > > system internal buses, but if you rolled your own, you could have: > > > Serial: Address high > > Serial: Adress low / data > > Mode0:Mode1 = address, read data, write data, idle > > serial clock > > system clock > > > with serial clock 16x the system clock. If the R/W devices can bring > > up data in a single serial clock, then you can run a C64 type single > > cycle Read or Write. With a 1 clock write, 2 clock read system, then > > all the devices need only run at the pace of the system clock (1/16 > > the serial clock), you can have a 1 clock write, 2 clock read system > > > The basic bottleneck is that no data can be asserted until all bits of > > the address have been asserted, which is why for byte-wide transfers > > the serial clock has to be 16x rather than 8x. > > It would be a cool - and expandable. > > Going back to Jim's idea: But then it ought to be threaded to a post under the original subject. |