Serial 6502

daniel_bingamon · Post by **daniel_bingamon** » Fri Sep 04, 2009 2:52 am

I was thinking, there are a lot of these new serial memories and other devices out there. A number of people talk here on designing processors, maybe a 6502 type processor that runs with the modern serial memories would be a nice device for small circuits.

Or -
Adding a Serial bus to a 6502.

GARTHWILSON · Post by **GARTHWILSON** » Fri Sep 04, 2009 3:55 am

8BIT (Daryl) on this forum has available a 65-bus compatible SPI port in programmable logic, but of course the processor still has to get the instructions to run it and read and store data on its parallel buses though.

The serial memories are are great for mass storage and replacing mechanical media like floppy disc, hard disc, or tape, but are not suitable for replacing the RAM and ROM in a processor system, for a few reasons.

They're not really random access. If you want to read just one byte of a table for example, you have to send several bytes of address and instruction to get there. Usually then you can keep reading subsequent bytes in order of ascending address without further overhead. That doesn't have much value though if the processor reads only a few bytes max in sequencial order then has to get or store data at other addresses, or branch, etc..

The maximum speed SPI memories will go is usually 50mb/s (a little over 6MB/s) and probably 2/3 of those bits will have to be be address bits if the processor is to use the serial memory like it normally does RAM and ROM. The speed would be a big limiter for a 6502 system.

Another problem with the serial memories is that writes take a long time (like a millisecond or more), and you usually write an entire page at once, whether 1024 bytes or some other similar length.

I²C is nearly 50 times as slow as SPI but the flash memories that write entire pages at once are usually SPI, and I²C serial memories are usually EEPROM that let you write a single byte at a time if you want to. The I²C EEPROMs' slower speed dictates that their maximum densities are only around 128KB, because it would just be too slow to justify trying to store and access more data. SPI ones, if you cound the SPI mode of the little flash cards digital cameras use, get up into the gigabytes.

The serial memories definitely have their strengths and their place, but a processor bus is not the place for them. It's nice to be able to get loads of non-volatile storage using very few wires. The next one I'll probably get is the Atmel AT25DF641 8Mx8 SPI flash in an 8-pin SOIC. I've used some of the 24c256 32Kx8 I²C EEPROMs in 8-pin DIP and fiddled with some others, some smaller and some up to 8Mx8 but in a 28-pin SOIC. I've always gone through a 65c22 VIA to interface them.

Nightmaretony · Post by **Nightmaretony** » Fri Sep 04, 2009 2:34 pm

So it is fairly easy to interface an I2C through a 65C22 then?

GARTHWILSON · Post by **GARTHWILSON** » Fri Sep 04, 2009 8:20 pm

Quote:

So it is fairly easy to interface an I2C through a 65C22 then?

Absolutely, but you'll have to bit-bang, ie, not use the VIA's serial port. Pick two I/O bits you want to use, and write your tiny building blocks more or less in this order (these are the names I gave the routines):

Code: Select all

INIT_I²C
I²C_CLK_UP
I²C_CLK_DN
I²C_DATA_UP
I²C_DATA_DN
I²C_DATA_IN   ; for data direction
I²C_DATA_OUT  ; for data direction
I²C_START     ; to produce the I²C "start" condition
I²C_STOP      ; to produce the I²C "stop" condition
I²C_ACK       ; to produce the "acknowledge" bit at the end of a frame
I²C_NAK       ; to produce the "not-acknowledge" bit at the end of a frame
I²C_ACK?      ; to check the ACK bit sent by a slave device
RD_I²C_BIT
SEND_I²C_BIT
RCV_I²C_BYTE
SEND_I²C_BYTE

then write the building blocks that are particular to the devices you want to interface, for example for the 24256 EEPROM:

Code: Select all

POLL_EEPROM
WAIT_TIL_EEPROM_RDY
SEND_EEPROM_ADR
WR_EEPROM_BYTE
WR_EEPROM_ADR
WR_EEPROM_PAGE
RD_EEPROM_BYTE
RD_EEPROM_STREAM

For the bi-directional data (and possibly clock too, but it's not always necessary), you can leave the output bit on the VIA a zero, then just change the bit in the data direction register so it's an input to let the pull-up resistor pull it up if neither the master nor the device is pulling it down. If you want to output a 1, just leave it in input mode, and if you want to output a 0, make it an output so the 0 in the output bit will pull the line down.

Nightmaretony · Post by **Nightmaretony** » Fri Sep 04, 2009 10:10 pm

Kewlsome. Reason I asked, when I am done with the pinball, am thinking of a more generic pinball computer, except that it goes to multiple processors, giving out orders via I2C lines. I saw a game once that used an I2C center, givint out orders to seperate boards so I thought it would be a good idea. For pinball playfields especially, you can save a giant labor intensive wiring bundle, just a set of huge power wires and some I2C busses to lights, switch and solonoid controllers....

Yup, am still in the pinball madness. Last night was a milestone, finishing up display attract and selft test of that region. Now is the time to get to the playfield light matrix and gert that puppy going, then the switches.... I had revamped my software to use libraries and a tight event loop.....

GARTHWILSON · Post by **GARTHWILSON** » Fri Sep 04, 2009 10:59 pm

I should have mentioned above that the smallest building blocks will probably best be macros so you don't waste the JSR/RTS overhead for a routine that's only two or three machine-language instructions like LDA #00100000B, TSB VIA3PB.