Cheap embedded-EEPROM cart proposal

[supercat]

Richard Hutchinson's MemCard is a very nice way to add 32K of EEPROM to the Atari 2600, but it's not without drawbacks:

 

-1- Many people don't have one.

 

-2- It's pretty slow to access.

 

-3- It hogs the right joystick port.

 

It would be nice to include a small EEPROM within a game cartridge. The current bankswitch card Albert sells would be amenable to this purpose with a few slight tweaks:

 

-1- Replace the 20V8 with a 22V10 (more versatile part, but same pinout; actually cheaper at least from some sources)

 

-2- Cut the traces going to pin 13 and (IIRC) 20 of the 20V8/22V10, and connect the trace that connected to pin 20 to pin 13 instead.

 

-3- Wire in a 24LC16B EEPROM chip (2048 bytes in an 8-pin DIP package). Pins 1-4 and 7 connect to ground. Pin 8 connects to VCC. Pin 6 connects to pin 20 of the 22V10. Pin 5 connects to pin 11 of the 22V10, and to pin 14 of the 22V10 through a 2.2K resistor.

 

The 22V10 would be programmed with the following hotspots (note the ranges overlap)

 

$1FE0-$1FFF and $0800-$0FFF-- Will raise SCK on the EEPROM briefly (in addition to other effects)

$1FF4-$1FFB -- As with a normal F4 cart

$1FE0-$1FEF -- Will copy the logic state of the EEPROM SDA pin to the lower banking bit

$0800-$08FF -- Will copy the logic state of A7 to the middle banking bit

$0900-$09FF -- Will copy the logic state of A6 to the middle banking bit

$0A00-$0AFF -- Will copy the logic state of A5 to the middle banking bit

$0B00-$0BFF -- Will copy the logic state of A4 to the middle banking bit

$0C00-$0CFF -- Will copy the logic state of A3 to the middle banking bit

$0D00-$0DFF -- Will copy the logic state of A2 to the middle banking bit

$0E00-$0EFF -- Will copy the logic state of A1 to the middle banking bit

$0F00-$0FFF -- Will copy the logic state of A0 to the middle banking bit

 

In addition to the above, following any cycle to $1FE0-$1FFF or $0800-$0FFF, after SCK has been lowered, the middle banking bit will be copied to SDA (with an open-collector output). Also, if the upper banking bit is set, SCK will be kept high.

 

EEPROM code would need to be spread/copied onto at least six banks for EEPROM operation, but it should be possible to access the EEPROM very quickly while remaining in full compliance with the timing specifications. Reading a single byte from an arbitrary address should take about 120 cycles; additional bytes may be read consecutively for about 32 cycles each. Writing a byte to an arbitrary address should take about 100 cycles; additional consecutive bytes would take about 32 cycles each.

 

Note that the 24LC16 is divided into 16-byte pages. Read operations don't have to worry about page boundaries; a write operation may output 1 to 16 bytes within a page, but may only do one page at a time. Once the 6502 indicates it's done with a write, it must wait at least 5ms before accessing the chip again.

 

Does anyone find the idea of such a cart intriguing? The extra parts cost compared with the present design is under $1 (one resistor and one chip that's about $0.50)

[CPUWIZ]

Cool friggin idea.

[+batari]

There's a lot of potential with this idea, as it's cheap and easy to implement (hardware-wise) and it would eliminate the issues with the memcard (especially the access protocols that not everybody agreed upon.)

 

Though the simplicity of hardware leads to more complex programming. On the surface, the code looks nightmarish, especially that it requires code to be aligned across multiple banks and only works with 32k carts (is this correct?) In order for programmers to use this, this code should be abstracted away from the programmer by a set of well-designed modules and/or macros. I.e., it would be ideal if all the programmer had to do was set up an address and data in a few bytes of 2600's RAM (or registers), then call a macro or subroutine.

 

A potential issue I can see is that EEPROMs are typically limited to 100,000 writes, which may make it unsuitable for use as RAM (slow RAM, but if you need more than 128 bytes, the read/write time might not matter so much.) Though unlikely, if one happens to write the same location every frame, the limit would be reached in less than a half hour.

[Albert]

A potential issue I can see is that EEPROMs are typically limited to 100,000 writes, which may make it unsuitable for use as RAM (slow RAM, but if you need more than 128 bytes, the read/write time might not matter so much.) Though unlikely, if one happens to write the same location every frame, the limit would be reached in less than a half hour.

It was my impression that this sort of thing would mainly be used to save the game state, high scores, and things of that nature, and that it would not be used as additional real-time RAM. In which case the 100,000 writes issue is pretty much negated. I think it would be great to have a board option for just another $1 or $2 in parts that we could offer to homebrew authors.

 

..Al

[supercat]

Though the simplicity of hardware leads to more complex programming. On the surface, the code looks nightmarish, especially that it requires code to be aligned across multiple banks and only works with 32k carts (is this correct?) In order for programmers to use this, this code should be abstracted away from the programmer by a set of well-designed modules and/or macros. I.e., it would be ideal if all the programmer had to do was set up an address and data in a few bytes of 2600's RAM (or registers), then call a macro or subroutine.

 

I'd try to set up something like that. My expectation would be that from a programmer's view, you wouldn't get to use the top 128 or 256 bytes of any bank (except for the standard vectors and hotspots) but otherwise everything else is taken care of for you.

 

Actually, I wonder if it would be useful to add a new set of hotspots (perhaps at $0700-$07FF) that would copy A5-A7 into the three banking bits. If code was assembled so that bank 0 routines were at $1000-$1FFF, bank 2 at $3000-$3FFF, bank 3 at $5000-$5FFF, etc. it would be possible to implement a "return to anywhere from top stack level" via (copied in all banks):

 ldy $FF
 cmp $0700,y
 ret

If it was desired to have the return work at any stack level, something like:

 tsx
 ldy $2,x
 cmp $0700,y
 ret  

Not quite as nice as 4A50's RAM hotspot system, but pretty good anyway. What do people think of that idea (if it fits)?

 

A potential issue I can see is that EEPROMs are typically limited to 100,000 writes, which may make it unsuitable for use as RAM (slow RAM, but if you need more than 128 bytes, the read/write time might not matter so much.) Though unlikely, if one happens to write the same location every frame, the limit would be reached in less than a half hour.

 

EEPROM is not RAM, true. The guaranteed endurance for the 24LC16B is one million cycles. Not unlimited, but pretty generous. Writing to it every frame would not be reasonable (and would probably be too slow, besides) but using it for something like a randomly-generated dungeon should work. The normal "backtrack" maze-generation algorithm might or might not be workable (some intelligent caching would certainly be necessary, but there might be some problems even then) but other maze-generation approaches could be used instead (e.g. generate a smaller maze within the 2600's RAM, then store that to EEPROM. For each 5x5 section of that maze (overlap one square), generate a topologically-equivalent 17x17 section (again, with one square overlap). Make a few arbitrary tweaks and you're done.

 

The maze size would be a little limited with a 24LC16B (since it's 2K, and you'd want two copies of your maze--one in row-major order and one column-major), but I think it should work quite nicely. Going to a 24LC64 wouldn't cost much more, but I don't remember if it still has 1,000,000-cycle endurance and I know that it takes longer for random accesses (three-byte addressing instead of two).