Building Block Computer (Was: Re: 16-bit C64/128?)
in [Commodore]
|
Prev: The Visible Computer Book Companion Disk for Christian
Next: Building Block Computer (Was Re: 16-bit C64/128?)
From: BruceMcF on 18 Apr 2008 04:08 On Apr 16, 3:20 am, christianlott1 <christianlo...(a)yahoo.com> wrote: > 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. The main question is whether its a memory bus or a modular bus. If its a modular bus then, yes ... indeed, if it has a clock running at a standard I2C speed and a single SPI bus master, then you can mix SPI and I2C on a common bus as long as you are careful with your SPI select logic ... I2C sends data between start and stop bits, and if you pick the correct map of the I2C bus onto the SPI bus, then its possible to have an I2C start/stop when the SPI is not selected. An advantage of I2C over SPI for the C64 is that it would only use one User Port serial channel ... setting a CIA serial port clock tick to 5 system clocks would give 10 system clock ticks per serial clock tick, or 100kpbs, which would be the original (1982) I2C clock speed. So the C64 could be an I2C bus master, and the CIA is fast enough to keep up with standard mode I2C data. But it might need more glue, or use some of the hardware handshaking. To get to fast mode or high speed mode in a stock C64 would require a cartridge. A High Speed mode design would probably have its own oscillator, and at around 3.4Mbit/s could do a DMA in chunks of 16 bytes without holding the bus so long it would give the VIC fits. A clean start on a modular bus design would be: CLK1 ... output from bus master CLK2 ... I/O from bus master OUT ... output from bus master I/O ... I/O from bus master DAD0:DAD1:DAD2 ... output from bus master ALERT ... input to bus master (maybe I/O if there's handshaking) VCC GROUND For SPI: CLK1=Clock CLK2=SEL OUT=Controller Out, Device In I/O=Controller In, Device Out DAD0-DAD3=Device Number For 3-wire SPI (eg, LCD controller) CLK1=Clock CLK2=SEL OUT=Controller Out, Device In I/O=High DAD0:DAD2=Device number, 0-6 (7 is not an allowed device number). For I2C: CLK1=High CLK2=Sel/Clk OUT=High I/O=Data DAD0-DAD2=High To glue an SPI device to that, either hardwire or have switches to pull an SPI Sel low when CLK2 is low and the three Device ADdress line match the device number. I think that's it ... I haven't looked at I2C (or SMEBus) as much as SPI, but I think that the I2C start bit requires a Low to High clock, and an I2C device ignores what is on the data line until it gets a start bit. So as long as you are careful that your de-select logic for the SPI bus is not an I2C start bit, you can do whatever you want while the SPI Select / I2C select/clock line is low. And for the SPI bus, its not data if the SPI-Clock line is not ticking, so if the I2C bus master holds that line high, its not data to confuse the SPI device. The main design issue then is how you want to design the ALERT handling on the bus. One idea would be to have a single ALERT line, which is a single input in a slot, and a dedicated I2C that the bus master can poll when it receives an ALERT to find out which slot sent the alert. A second idea would be to have an SPI alert logging device as device #7, specifically set up so that its happy to get selected and deselected all the time when the bus is used for I2C, and basically consisting of a shift register containing the ALERT inputs from the different slots. Since there is a 7-bit address space for I2C devices, that would easily support as many modular cards as you could stack on top of one or two stackable headers. If you want a serial backplane for a 32/16, and you have fast enough shift registers, it seems like it would be possible to roll your own. For a 16-bit address, 8-bit data system, have two serial lines ... one is I/O, one is Output only for the high byte of the address. Have two mode lines ... write address, write data, read data, idle. And a serial clock line and a system clock line. For a write cycles, 8 serial clocks to put the address on the bus, 8 serial clocks to read the data, the serial clock has to run 16 times the speed of the system clock. Devices that are read from the bus in the current cycle need to be able to respond at the serial clock frequency, the processor, devices that only read data, and devices that are accessed with a wait state between addressing and data can run at the system clock speed. To go to a 32 bit address, 16 bit data, double the serial clock speed and use 16-bit shift registers, or go to four serial lines. But since its relatively inexpensive nowadays to have a microcontroller on the card side of a serial bus, and since its straightforward to set up an SPI interface to a chip with just a shift register and a little glue, I'm not 100% sure why a backplane is that appealing. |