@wmeyer48 wrote a comment on the front-page about a guy who built an In-Circuit Emulator back when these things were new...

Always did kinda wonder how those worked...

I did just see a vid about how debuggers insert breakpoints. (Surprisingly obvious... self-modifying code *replaces* the actual instruction with a call to the breakpoint function). 

It requires the code be executed from RAM, though. But that factoid was a key to one of my earlier ponderings about some sort of in-circuit-programming method. Maybe swap the ROM with a battery-backed SRAM which also just happens to be connected to another machine capable of erasing and writing it. (and, i suppose, somehow putting the z80 in a bus-released state, and resetting it, DMA?).

Would be pretty easy these days for a microcontroller to be that reprogramming host. Would be even easier to put something like this in the system via a 40-pin "chip clip" atop the z80, to access those reset and bus-release signals.

Surely nowhere near the functionality nor complexity of an ICE, but within my means. I might just go about it something like that, as I do quickly get overwhelmed with big code-changes which haven't been tested in small pieces along the way. 

...

Somewhere in there I begin to contemplate using FLASH, instead of RAM, and take it a step further to a sort of in-"ROM" bootloader so the Z80 can reprogram its own ROM (e.g. via a serial-dump?). But that'd be a ways off (I'd have to learn something like Zmodem?).

And, it's interesting to point out, developers at the time didn't *have* FLASH as an option. And large SRAMs (even approaching the size of their ROMs) were *very* expensive, if even available in single chips.

The ol' "Wild-West of Computing" was a crazy era with many hurdles to overcome... inspired quite a bit of "hackery" at its finest.

...

Thanks to wmeyer48 for the reminder. 

...

1 friggin 18 in morning, 6/23:

DUH. The flash-programming utility is:

A) stored in a higher address-space, selectable via a switch on the appropiate address bit. SD70 boots into that space, instead of the bootloader (which would otherwise precede *any* firmware tests)...

This makes it sound too complicated.

 Simply upload an intel-hex file.

No friggin' fancy terminal-emulator combined with xmodem, or whatever, to switch from text-mode to binary-upload...

 Simply flip a switch on the SD70, reset...

Even my phone can do the next part (assuming it gives me permission):

'cat newfirmware.hex /dev/ttyUSB0'

Done.

The ihex format looks pretty simple.

The only concern is flow-control... Flash-programming is kinda slow (slower than serial?!)

Oh, and the potential for ihex files which are sparse or out of order. 

These might otherwise require a RAM big enough to store the full ROM image...

BUT Could easily be fixed in a bash-script at the sending-side.

Simple.

So, say I can find a 32K+ flash chip in my collection... seems more than reasonable, given the things I've scavenged.

The first 16K are for the firmware testing. The second 16K is for the FLASH-programming utility. Simply use a switch a pull-resistor, and a.c n XOR (or numerous other options) to swap the highest bit's value, depending on if you want to boot into the testing firmware or the flash-loader.

Really, this explanation makes it seem more complicated than it is.

I doubt I can get this done in just a few days, but it'd be so worthwhile that it's probably one of the first things I'll do before I begin my own firmware experiments.

Only thing is  it means getting flash-programming and serial I/O right, first...

...

This "duh" comes after hours of contemplating using an AT89C52 *as* the flash-ROM. Thing about this microcontroller, over say the AVRs I'm *way* more familiar with, is that it can be programmed as though it was an EPROM. And *that* means it can also be read-back *just like an eprom*.

So, the idea, essentially, was to use it as little more than a FLASH ROM (because I've a few in stock from some twenty years ago that I likely would never use, otherwise) .

The idea looks like it should work, but its access-times leave a lot to be desired. 48 clocks from address-valid to data-out. It can run at 24MHz, so could be ROM-accessed at no more than 500KHz. :/

But: The Z80 looks to use two of its clocks for each read, so it could be running at 1MHz! Until you recognize yet another oft-ignored timing... The time it takes to release the data bus after /RD or /CS goes inactive... which iis another 48 8952 clock cycles. So, now, the Z80 has to run at 500KHz, heh.

 OR use wait-states. Which, in this case, looks like it would require a 6-bit counter from the 8952 clock, or maybe a three-four bit counter from the z80 clock (and would require a bit of overkill delay-wise). I guess it was ridiculous. BUT: possible, if I didn't have any other/normal flash chips. But, the cool thing is, it wouldn't require *any* 8051 programming! 

Also, unlike all other FLASH chips I've seen, it allows writing individual bytes one-by-one, in any order. (As long as the bits you're writing high were "blank"=high already, e.g. 0xff from an initial erase). So, it could be a handy consideration in later projects... E.G. its 8KB is 256Kbits... So, imagine, say, an impulse-counter that can count to 256000...

Or, since the Z80's NOP, as I recall, is 0x00, one could use something like this (at a low CPU speed, or appropriate wait-states) to store small bits of (limited-functionality, e.g. no interrupt vectors) experimental code... which, as the next version is uploaded just write 0x00=NOP over the previous version.

...

WAY back in the day, I had a buddy who worked at a place that used OTP PICs at such rates that they had a bin full of old buggy(?) versions, headed for the trash. This guy... I thought him utterly crazy,  at the time... He grabbed-up these chips and figured out which instructions he wanted to keep for his own projects, or which bits he could write to Zero to turn old instructions into ones he wanted. All the others he'd convert to NOPs. Now THAT'S a hack. That guy was brilliant!

...

About a decade before meeting that guy, I started my "career" at a place where OTP 8052's were used during devel (which is why I acquired the Flash-based AT89C52's, thinking I discovered the holy-grail for my boss, who, of course, at about the same time discovered another brand's equivalent). But, yahknow if I were smarter, at the time. I'd've thunk them burnt and buggy OTPs, deemed useless, a pretty awesome score!

I imagine that guy (sheesh, what was his nsme? ... Dan!) probably eventually wrote a script to fit his desired program into whatever was already burnt on the chip... Despite a few hurdles (or minor limitations)-- interrupt-vectors being an obvious one, and cycle-accurate timing would obviously be a nogo--he basically acquired *numerous* microcontrollers for his own projects, and kept them out of the trash bin. Gotta give that guy props.

...

Anyhow, I'm definitely considering options for in-system-programming... And I'm not afraid to use options, like FLASH or AVRs, that didn't exist in the Z80-era. Unfortunately(?), I also need to consider the limitations I face, which vary greatly from the world I came from... E.G. Having a full-on *this-era* compy running means eating up batteries, then charging them again with extreme gas prices.. So... Well, I'd've *definitely* done this with an AVR in the past; it'd simply do a bus-request to the Z80, causing it to disable its address/data outputs while the AVR rewrote the flash-rom... But writing that code would drink a lot of juice... So, I'm considering options I might not have  before... 

And, really, an onboard solution makes a lot more sense. 

Say there's simply a switch inside labelled "Upload firmware: See instructions at 9600baud (press reset when connected)"

Then it simply sends some instructions amounting to: "run: cat newFirmware.hex > /dev/ttyUSB0"...

I'm pretty sure even ten years from now I could understand that... right? No special dongles or AVR "blackbox" required...

Heck... those instructions could be *very,* thorough... e.g. including an address-map, schematics in ascii-art, and far more. Hmm!

Heck, memory's so-available these days  we could even include chat-logs and these very posts/comments... Disassembly of the original firmware... The list goes on.

Heck, throw a 1GB SDcard in the mix, and every version of test-code could be kept *in* the machine, flashable *to* the machine, accessible via nothing more than a simple serial interface with a menu... Don't even need to find an SDcard reader in twenty years... Surely UARTs will still exist.

"We Have the technology!"

I'd long thought that AVRs should have a, say, 4MB space for storing the source-code. This takes it to a new level.

(friggin' sunrise coming soon.)

...

"flip switch to log onto the SD70-hackery BBS"