Close

High speed AVR based EEPROM programmer (part 1)

A project log for DB6502

Yet another homebrew computer based on 65C02 CPU

Dawid BuchwaldDawid Buchwald 08/28/2020 at 20:432 Comments

How to lose your mind in three really simple steps

We have all been there, more than we care to remember. 

You are in the middle of creative frenzy, writing your code as the Devil himself. Compile, link, grab the programmer. Fish out that ROM chip carefully from breadboard, place in the socket. Take another look, notice the notch wrong side. Take a deep breath, rotate the chip, burn. Plug it back in, nervously connect power.

Trembling with anticipation you notice that nothing happens. Check power. Check reset switch, no it didn't fall out this time. Try one more time. Nope. Sigh, spend couple of minutes attaching Arduino debugger, step over first couple of instructions, but it all seems good for a while and fails only after several hundred cycles. Repeat - maybe it was freak occurrence.

After another half an hour you finally start checking wires and there it is - one of the suckers got loose. No, not so much to slide out of the breadboard, that would be just too convenient, just enough to make bad connection. Push it in, restart, it works, it works, it works, no it doesn't. Code bug again.

Where was I again? You no longer remember what you were doing, got distracted too much with silly wire not making good enough connection. Coming back to the point where you left off will take some time and impact your motivation.

How to stay sane for a bit longer

If you search /r/beneater for ZIF, you will find small sample of what people tried to do. Hell, even I did that for a while - as it turns out, you can make it fit in breadboard with simple hack (add header female pin header to the socket) so it doesn't loose connection each time you play with it.

For me the solution was to move to PCB, and put my EEPROM in secondary socket like so:

While this works surprisingly well (tooled sockets are perfectly matching each other, and are much more sturdy than the regular IC pins), it still frustrated me how often I have to pull the ROM out and flash it in my programmer. It was really annoying, so the next part of the code I wrote was bootloader functionality that was supposed to reduce the need for ROM flashing, and it worked for some time.

Unfortunately, with the limited resources of 64K address space I had to store at least some code in ROM and my OS was depending on it. Shortly after I added the option of static linking these routines in loadable modules so I could change them and experiment without EEPROM flashing. Again, it worked for a while, but when I started experimenting with higher clock frequencies and had to troubleshoot resulting issues it just wasn't enough.

At least I didn't have to worry about loose wires :)

Does it have to be like this

Sorry to digress so much, but part of the experience for me is to see how my hobby ties into my day job in IT consulting company. One of the things that never ceases to amaze me is that people in my area of expertise are so clever when it comes to coming up with new ideas, and still they do so many things in such awkward way as if they have never known any better. Manual build processes. Awkward release management. Cumbersome testing procedures. Lack of any kind of DevOps culture. Nonexistent source code management procedures. We've all been there.

So, general word of advice would be: if you feel that your team is doing something in quite strange way and you suspect it could be done better - investigate. Challenge. Question. It's quite probable that this one thing can (and should) be done differently. Somebody out there might have came up with much better idea, and chances are you are the last ones to catch up :)

So, going back to the original issue: ROM programming. Does it have to be like that? Sure it doesn't, there is bloody Arduino sitting in your drawer, how many times did you have to fish out the effing EEPROM out of this thing to program it?!

Now that we have established that, let's consider our options here.

ICSP options for 6502-based build

There is plenty of clever ideas out there, and here are some of them:

  1. Have the 6502 run small bootloader off the ROM and use it to load the actual system software from PC over serial,
  2. Give up ROM altogether and use RAM only. Copy code to the RAM using external CPU (again, Arduino/AVR/PIC/...)
  3. Connect 6502 to some kind of Arduino/AVR/PIC that will be capable of ROM flashing.

Let's look at each of them separately.

6502 internal bootloader

I haven't explored this option too much, so I might be wrong, it might actually be perfectly feasible, but there are certain details you have to consider:

In general I want to explore this path one day "just because". Might be interesting experiment, but this is not the way I want to go now.

RAM based machine

This one is really interesting concept, and it has many advantages, unfortunately with some drawbacks:

I don't agree fully with criticism of the last point, but I do feel a bit uncomfortable with system that is not capable of running without much more powerful processor. Therefore I gave up on this idea as well, at least for now.

Onboard ROM programmer

It's not hard to guess that this is the option I settled with in the end. I did it for the following reasons:

Now that it has been decided, the only thing was to write the simple software, right? After all, how hard can it be? In next post I will explore the details of writing AVR-based EEPROM programmer that is at least somewhat usable...

Discussions

David wrote 09/22/2021 at 05:05 point

I'm kind of surprised that none of these options really match up with what I think are far more common options for ICSP options (i.e., avoiding pulling the ROMs and re-programming them).

* serial external media + a tiny internal bootloader ROM that reads the program from the media into RAM, then runs it (where 1970s computers used cassette tape or floppy drives as external media, but today we'd probably use MMC cards or SD cards).

* internal parallel execute-in-place application flash memory + an internal bootloader (perhaps in "real" ROM, or at least flash that cannot be written to by the 6502) that jumps into that application when stand-alone, or overwrites application flash memory when a new application is downloaded (like typical "self-programming" Arduino systems).

Both of these support stand-alone operation, where the 6502 runs an application in isolation without any other CPU nearby.

  Are you sure? yes | no

Dawid Buchwald wrote 09/29/2021 at 09:28 point

Hey, sorry for very late reply, I hope you get to see it. See, I understand your point and you would have been right if not for one small detail - the point of my board is to allow people to learn from the very beginning, with NO SOFTWARE at all. Writing your own bootloader (which I have completed long time ago) is amazing adventure, but doing that requires many, many iterations of trial and error. The point of the onboard AVR programmer is to make this process significantly easier. Hope that this explains my point of view :)

  Are you sure? yes | no