Yes, it's effectively a bus pirate. Remember this was a proof of concept... Three of the magic serial widgets (I like that!) are loaded with the address high, address low, and data; the write to the data widget automatically writes to ram on completion. I think that this implementation is conceptually simpler that Chromatix' idea, and possibly faster: my file converter (which handles hex files one line at a time) only includes a write to the address high widget at the start of each line, and if the page changes during a line (I've never seen that but it's theoretically possible) so for the majority of data it's sending only four packets per byte instead of six - saving a lot of time in the load.
The last widget is somewhat wasteful but provides a solid 'done now, go away and never darken my doors again' reset, permanently isolating the serial decode and starting the processor at the just-sent reset vector.
Incidentally, using meld I found the error at the third difference (the others were just changed pointers to the I/O routines): I had mistakenly replaced
Code:
jcc xxxx
with
Code:
bcc $+3
jmp xxx
Oops.
Anyway, the work flow is exactly as I desired; in the same way that one might use an Arduino or Nucleo, it's straight forward:
- Edit code on the host machine (assembly, C, whatever)
- Assemble/Compile code to a hex file
- Convert hex file to a binary stream file
- Set the serial port to 19k2 baud
- Send the binary file (an 8kB file takes around 18 seconds)
- Wake up the terminal (minicom in my case)
- Rinse and repeat
The last three steps use individual commands at present but might conveniently be included into a single shell/batch file (actually, that might include the conversion step, too).
This build is effectively Grant's minimal build: Ram for the bottom half, a minimally decoded ACIA at 0xa000-0xbfff, and then ram for the top quarter. So while what I'm doing at the moment is writing basic into 0xc000 for eight k, it's equally simple to drop an image into the bottom half, anywhere there's ram. The only critical thing is to remember that you have to write the reset and (if used) interrupt vectors. It uses two (well, one and a half) 32k rams simply because I had them in the bits box, and it runs at 1.8MHz because it uses that as the serial clock.
I probably won't build another hardware version, but if I did it would include:
- The OR gate that isolates random writes
- A separate reset for the processor so that it can be reset without reloading the data (a full 64k upload would be over two minutes)
- The two spare inverters used to drive LEDs: one lit when the data is loading and one lit when serial data is incoming. Just for pretty...
The basic technique should of course be adaptable to any 65C02 design - it would require extra buffers for an NMOS processor which lacks BE, of course - and similarly to any other processor.
I'm really rather pleased with it.
Neil