Heh, apparently the idea of in-system programming has me in a chicken-egg infinite-loop.
'Cause apparently (clicking-through old logs to "add a log") I'e already written quite a bit about it... https://hackaday.io/project/185919-z80-reverse-engineering-and-hacking-adventures/log/207723-in-circuit-programming And, here I was, 'bouts to write about it again as though something new.
Anyhow, I've finally swapped-out my test-firmware EPROM for a flash chip, which at the very least will prevent me from stupidly looking at the UV eraser.
The flash chip (An AT29C512 in a PLCC package) I made a DIP adapter for back during #Improbable AVR -> 8088 substitution for PC/XT ... Stupidly, I lost the documentation, so had to beep out the wiring. But, after having done-so, I realized just how forward-thinking I was way back when (Thank you, old me!).
This guy can replace any (jedec-pin-compatible) PROM from the 28pin 64kilobitters to the 32pin 512kilobitters, and probably more in either direction, by changing a few jumpers.
And, unlike plugging a 256kbitter in a 128kbitter's socket, when you program it in a regular external chip programmer, with the regular [AT29C512] chip-specific settings, you don't have to load it at an offset (e.g. 0x4000, when using a 256kb chip in place of a 128kb chip, due to the higher address bit's being tied high for a different purpose).
So, I shoulda been using this all along, but I had to figure out those jumpers and its pin-compatibility first, so had been using a 256kb chip with an offset at 0x4000, and noticeably-increasing UV-erasure-times, and...
Anyhow, after I reverse-engineered my own project, I made sure I won't lose that documentation by folding it up and sliding it in the space between the PCB and the pins... Or, I would-have, but a folded 8.5x11 just won't fit. So I spent friggin' hours, strung-along by "just one more step" trying to print it smaller, just to find out all my attempts were unnecessary because apparently all I had to do from the start was unplug the printer and plug it back in. (Yes, OBVIOUSLY, one of the first things I tried was turning it off and back on. Stupid "soft" power switches!)
Anyhow, printed at about 1/4 page it fits snugly and should be there for me in another 7 years, for another project.
Before that, though, it'll speed up this project, slightly, and "idiot-proof" it a bit, and reduce the dangers.
It's still quite a process to pull it, change jumpers, put it in the programmer, and actually the process is tremendous...
So, yes, immediately after the first successful test and the noticeable albeit slight improvement, I started thinking, again, about in-circuit programming.
This is no longer the "Wild West Of Computing"... we have fewer of the sorts of hurdles they had to hack-around... (Though, we have hurdles of our own). I'm not afraid to use some of our newer tools. 5V-only Flash-ROMs exist, now. OK? Right? So, Hey, Me: save yerself some trouble, dummy!
Right. So *all* I need is a means to upload the new firmware image, then the unit can program that to itself. Presto!
So, the whole reason this interests me, again, is because large/untested code-changes are *extremely* daunting to me.
And... what would an in-system firmware-downloader/flash-programmer be...? A large/untested code-change.
I [kinda] need this thing to be able to make this thing. Chicken-Egg.
I think I ran into the same with #Vintage Z80 palmtop compy hackery (TI-86) ... Heh!
Anyhow, not a show-stopper, but a bit ironic.
The other idea, e.g. using an AVR, putting the Z80 in bus-release, well, it has a slew of other such chicken-egg issues, many similar (e.g. parsing ihex files)... But, long-run, I guess, stand-alone in-circuit-programming is the best option... So, I guess I just need to bite the bullet.
So I guess we're talking a jumper/switch to boot to a higher address in the flash, loading the flash-writing utility into RAM (almost forgot that!), listening to the serial port for an ihex stream, parsing that into a byte-stream to be written, telling the sender to pause (flow-control...), writing the data (does this chip require sector-writes?), repeat.
Sounds easy! Except, of course, few of these things are written yet, and they... EACH... should be tested along the way...
And boy-howdy, wouldn't it be nice to have an in-system programmer to develop/test those?
Hah! Was bouts to say "well, some of that can be tested on a computer, e.g. the ihex-parser"... but, hah! We don't [yet] have C for this thing. What'm I gonna do, run a z80 emulator? I wouldn't even know where to start!
Oooh, maybe the TI-86?
Anyhow, it's just funny...
Third reread: DUH. Period.
Hey this Z80 stuff is fun, but I'm all about code-portability and tools that can be reused...
AVR, now, seems the best way to go. A system like that could be chip-clipped to *many* different processors... And I have a box full of various boards with 8bit CPUs I might like to hack similarly (e.g. boards from an old modem, a C64 floppy drive, some custom 8085 SBC, even an old CD-player).
OK, so... Chip-clipping the CPU is really only necessary for bus-release and reset. Address/Data/Rd/Wr, etc. could all be clipped directly to the ROM... Since the whole point, then, is to replace the original EPROM with flash, it makes a heck of a lot of sense to chip-clip (or otherwise intercept signals) from there, than the CPU...
At which point a small board, similar to the one I already have (jumpers and all) wouldn't be a bad idea, maybe a header for a ribbon-cable to the AVR... And a couple pins with wires and test-clips from there to the CPU.
The board, itself, then, drops into the ROM socket. The AVR can be disconnected once standalone ISP is running...
And THAT might be the best part of this idea... Having written the ihex parser, flash-programmer, etc. in C, already, for the AVR, it'd be portable to the other CPUs once we get C for them.
And *that* brings me full-circle to my old idea of trying to find a universal/minimal set of assembly instructions and registers... Hmmmm....