Yes, the NoICE debugger supports lots of targets. That's one I'll undoubtedly have to investigate.

Whether the debugger is physically resident in the MCU's internal memory or in an externally applied PROM of some sort is of no concern. What matters is that it is resident in the local microcontroller's memory map. None of the old systems I have to support have more than 8KB of code space in use. That, generally, resides on an EPROM external to the MCU, which, in most cases is an 803x. For debugging purposes, I would probably prefer to have the debugger resident in an MCU that I physically install in place of the existing one, using a daughterboard that has external RAM mapped into code space, and RAM mapped into R/W memory space, such that the existing code can be copied into the RAM, the RAM then switched into code space, and executed there under control of the debugger. Only I/O on the target system is accessed under such circumstances. I've been using that sort of mechanism since the '80's, though it's only been since the early-to-mid-90's that memories have been dense enough to allow me to package the entire circuit on a board the size of a business card.

I've given a fair amount of thought to the question of what an ICE can do for me, particularly since I have several, and they seldom do much for me. The debugger does most of what's needed from an ICE. If it has the line-by-line assembler and the instruction-by-instruction disassembler, there's little that's needed from an ICE that isn't done by the debugger. In such a case, all that's needed is an off-chip UART/BRG.

As for your "table-driven" (meaning driven by a sheet of paper on the table) assembler, there was a time when we had to do that until we had written our own assembler, back when we couldn't simply go out and buy a personal computer.

RE