The EEPROM

ROL’s current memory map supports two 8K EEPROMS for its software. So far, I’ve only been using ROM 0 at address $e000 to $ffff and ROM 1, at $c000 to $dfff, has been stuck in the breadboard, filled with $EAs (the 6502 NOP). The chips I’m using are some AT28HC64Bs. These chips are 150ns. With this configuration, I’ve had success running ROL up to 4MHz, though it isn’t always stable. 1MHz always works. If I want to get up to 10 MHz, I’m going to have to fix the EEPROM speed issue.

I have been using VASM to assemble the code and my own EEPROM programmer to write the binary output of the assembler to the chips. The programmer is based on Ben Eater’s EEPROM Programmer. I modified it so that I could upload the binary file to the EEPROM via xmodem. I mainly wanted a relatively simple project that I could use to work out how to use KiCad and get some experience with Osh Park. It worked out great.

I will point out, these chips are a little fussy with some of the features. I had trouble getting the fast writing mode and erase to work. Some of that was electrical design: the erase requires 12 volts and I wasn’t sure (at the time) how to get 12 volts out of the 5 volts output by the Arduino, which I’m using to power everything. Some of it is that the documentation for those features requires an NDA.

In any event, I made a schematic of the circuit (thanks to John Winans for some KiCad tips!) and shipped it off to OSH Park and got a little PCB made. I soldered the parts on and it’s been working great. The project is breadboard friendly and the Arduino source code is freely available on my GitHub page. If you don’t want to spring for an EEPROM programmer, definitely check it out.

Now, I’m thinking about the future. I don’t want to use a slow EEPROM. Last I checked, 70ns was about the fastest I could get off of Mouser and the SRAM I’m currently using is 20ns (for comparison). What I’m thinking of doing is having a small bootloader in about 1K or less of EEPROM which runs at a lower clock speed. That bootloader would load the remaining code from an SD card, place it in fast SRAM and then jump to it. One of the first things that code would do is turn up the clock rate.

I’m not sure about this. I need to investigate it further. It looks like the smallest parallel EEPROM I can get is 8K, so most of it would be unused. I hate being that wasteful, but I’m not sure I really have any alternatives. There are some SRAM chips that are battery backed, so they are essentially nonvolatile… as long as the battery is good. Maybe one of those with a rechargeable lithium ion battery, then keep the entire “ROM” on that and scrap the whole bootloader thing? But if something goes wrong with the battery… bleh.

I haven’t really seen a solution to this problem that I really like. Some people are using Arduinos for booting up (and other things). Some are doing something like what I outlined above, just throwing away most of the 8K of ROM space. Some just keep the slow EEPROM and use wait states.

More to come on this topic…

Leave a comment

Your email address will not be published.