2600 in 2006

I do, of course.

 

I am wondering something, though. I recall you saying that you wanted to use a 2k EEPROM. Is there a 4k EEPROM out there that's just as easy to use, but maybe a little more expensive?

 

Also, would it be very easy to allow one to be able to program the EEPROM from a PC without needing to remove the chip, given a special cable/connector/programmer and software?

I am wondering something, though. I recall you saying that you wanted to use a 2k EEPROM. Is there a 4k EEPROM out there that's just as easy to use, but maybe a little more expensive?

 

The 4K and larger EEPROMs require an extra 36 cycles to do a random read/write. The prices for 4K and 8K parts are still quite cheap; I think the 8K part is about $0.25 more than the 2K part. My thought was that some games might want the faster access and most games wouldn't need the larger capacity. Wiring is the same regardless.

 

Is 2Kbytes really not enough? Strat-O-Gems makes good use of the EEPROM, and it only takes 320 bytes. Although 36 cycles isn't a huge extra penalty for random reads, it could be a nuisance if trying to access the EEPROM within the kernel (not quite as crazy an idea as you might think). In a Super-Maze-Craze style game, for example, which shows 24 rows of 40 pixels each, it would be necessary to do a random seek and six byte reads for every sixteen scan lines (assuming 1/4 of the pixels are always set, 1/4 always clear, and the other half variable). On a 24LC16, the random seek would take about 128 cycles; on a 24LC64, it would take about 164. The data fetches would take 216 cycles, so seek+fetch would take 344 or 380. If one figures the kernel would need an average of 40 cycles per scan line to run the display with already-fetched data, there would be about 576 cycles available for data fetching and munging, and for kernel management. Things would be very tight, but might be workable. But that extra 36 cycles could make a big difference.

 

Also, would it be very easy to allow one to be able to program the EEPROM from a PC without needing to remove the chip, given a special cable/connector/programmer and software?

 

When the chip is on board, the 2600 will control.them. If you want to include a serial-port-operated EEPROM utility within the ROM, that wouldn't be too hard.

Sounds interesting to me. Unfortunately I don't understand exactly how you would program the EEPROM as my hardware knowledge is very limited, but it would certainly be useful to have. If you were writing from the chip during the kernel wouldn't you quickly wear out the chip (assuming it is based on flash memory)?

 

Chris

Oh, yes I'm also intrigued and think it's a swell idea.

 

It's a nice option that's available on Vectrex carts and should pretty darn handy.

Sounds interesting to me. Unfortunately I don't understand exactly how you would program the EEPROM as my hardware knowledge is very limited, but it would certainly be useful to have. If you were writing from the chip during the kernel wouldn't you quickly wear out the chip (assuming it is based on flash memory)?

 

A "write" cycle entails the processor sending a start signal, followed by two or three bytes of address information (depending upon the chip), followed by any data to be written. The data is transferred into a small buffer within the EEPROM chip; if one or more bytes of data followed the address, and if the write cycle was properly terminated by a STOP signal immediately following the acknowledgement of the last byte, the contents of that buffer will be stored into the EEPROM array. When this occurs, the chip will become inaccessible for about 2-5 milliseconds.

 

A "read" cycle entails the processor sending a start signal and one byte of address information, and then reading as many bytes of data as are desired. Data will be read sequentially, starting at the last address specified in a "write" cycle.

 

Note that "writing" zero bytes to the chip will not cause a store operation to take place, but will merely set the address that should be used by a succeeding "read" cycle. There is no lifetime limit to how many such zero-byte write cycles may be performed, and no delay is required between such a write cycle and a following read.