Then I'd call you a fool, but since you haven't ...

Back in the days when we had to generate our own tools, the editor/assembler/debugger ran on the target device, albeit not in the target environment. Those 8kB of object code were the development system. One COULD write a cross-assembler and run it on another CPU, but it was, then, more practical to run it on the target core. Even when a HLL was available, it was used in the context of that editor/debugger, with the compiler occupying the space used by the assembler, or, in some cases, coresiding with it in an additional 2KB or even 4KB of system memory. Naturally, the compiler, assembler, and normally also the debugger, were omitted from deliverable code. Object code deliverables were typically on the order of 4KB or less, since the biggest EPROMs of the day were 2kB. By the time 4kB EPROMs were ubiquitous, MCU's with that much code space were beginning to appear.

It was VERY comfortable developing code in such an environment, since one could simply edit/compile/assemble, and execute the code under the resident debugger. Code ran on the target, albeit with the development software present. Since virtually every CPU supported 64kB of memory space, and since deliverable object code seldom exceeded 8kB, it was very much like developing with an ICE. A commercial development system generally used the same CPU core as the target. If one wished to change target cores, one replaced the system CPU with the desired one, and ran the development software on the new target core.

The clear advantage of this particular approach was that the target code ran on the target system with a core operating in the target environment at the target core's rate. That made it easy to monitor hardware/firmware interactions with a logic analyzer in real-time.

I don't know what sort of "debug hardware" can give this sort of support for a developer. JTAG operates at ~100kHz max. Even a classic 805x is too fast to be monitored in real time by such a feature. Yes, you can look at registers, even memory or I/O features, but I don't see how 100 kHz JTAG can keep up with repeated cycles through that process when the process is at 1 MHz. It's nice to be able to look at the state of the target once it's stopped, but traces have to stop in order to trace. That's a fact we couldn't avoid in the '70's either. Back then, nobody had yet thought of splitting Freescale from Motorola. Even Intel's development system ran the 805x code on an 805x. The 8088 was, even in the '80's, when it became part of the PC, after all, too slow to do the job.

RE