Close

EEPROM Flashing

A project log for Dodo: 6502 Game System

Handheld Game System featuring the 6502

peter-noyesPeter Noyes 11/16/2016 at 06:063 Comments

One of the big remaining tasks before Dodo is ready to be available as a kit is to support in-circuit flashing of the 32kb EEPROM that holds the system firmware. I want to continue to add functionality and it would be a major bummer to require everyone to pull a chip out and use a separate EEPROM burner. As of this week, Dodo now officially supports EEPROM flashing over the serial cable!

Version 1.2 of the hardware hooked up the control signals such that in theory the flashing could work, but it took software changes to make it a reality. The trickiest part is that the system code basically needs to overwrite itself which is not straightforward. I ended up creating a small standalone routine that reads from the serial port and writes to the ROM and it is embedded as a resource in the system firmware. This routine is copied into a reserved area in RAM and then executed from there so that no code is read from the ROM while its being written to.

I am pretty happy for my own sake that this now works. I have pulled the chip and reprogrammed it over 100 times during development. I can now iterate much faster when making firmware changes.

In other news, I ported a simple version of Tetris to Dodo. Here is a playable version in the playground.

Discussions

Jac Goudsmit wrote 11/16/2016 at 19:39 point

I'm not familiar with your schematic and I know you probably can't change anything at this stage, but to be able to update an EEPROM that you're executing from, you could have used shadow RAM. As far as I know, this is also the way that modern PC's do it (at least some of them). Basically, a RAM chip and an EEPROM or flash chip are mapped to the same addresses, but their RD and WR lines are controlled through some glue logic that determines what each chip does depending on the R/!W from the processor, for example you could implement the following modes:

- READ from the ROM, WRITE to the RAM (this should be the default when the system comes up; in this mode you can copy the ROM to the RAM by reading all locations and writing them back to the same location)

- READ from the RAM, WRITE to neither (ROM emulation / ROM shadowing, you can use this after booting up and copying ROM to RAM; RAM is usually faster than ROM so it makes your system faster)

- READ from the RAM, WRITE to the RAM (Firmware emulation/debugging mode: a program elsewhere in memory can store the updated firmware in the area where it will normally be placed, and you can run it as you normally do, and modify it if necessary until you're done fixing bugs)

- READ from the RAM, WRITE to the ROM (Firmware update mode: the code is executed from the RAM but the instructions update the ROM by writing to it. The code will look weird because it will LOOK like you're overwriting your own program, but the electronics make sure you aren't). If you use a ROM that requires a special protocol to erase and update pages, that should also not be a problem.

Of course you should make sure before you start overwriting the ROM that the machine has received the code correctly, and it's probably a good idea to design the system so it can deal with an empty ROM.

These are difficult problems that I like to think about while I should be working :-)

  Are you sure? yes | no

Peter Noyes wrote 11/16/2016 at 20:36 point

Thanks! Shadowing is definitely a good idea. In the current design I have 32kb of RAM and 32kb ROM in separate address spaces and all of my glue logic is made from discrete gates so I am pretty limited. In a future version I plan to move all the glue logic into a programmable logic device of some kind, and at that point it would make sense to use a 64kb RAM for shadowing. 

  Are you sure? yes | no

Eric Hertz wrote 11/16/2016 at 11:15 point

Slick, that first part... and Tetris... Whoa, you even got the music!

  Are you sure? yes | no