You insist
"...I still don't see why you need anything other than the most basic "kernel" to be actually resident.
It seems to me that everything else would actually be far better off being in a PC. "

to which I ask, "What's the advantage?"

Remember, all I initially asked was whether there's a monitor with the features I've mentioned that's available as 'C'-source. Most of what I got back, rather than a resounding "NO", which is what's apparently the case, is a bunch of pitches for using systems that are far more complex.

The reason I want source code, if available, is that I want to use it to support all the suitable MCU's, not just this one. While I like the 805x types, I also like some others, and I'd like a debugger like what I've used in the past, under CP/M and later under DOS. One reason is that the very best software I've encountered under Windows is resoundingly awful, poorly documented, and, mostly, falsely advertised.

I trust what I do, however imperfect, because I know what it is. It may take a little time to find out, but, ultimately I'll know what it is. That's never the case with commercial products.

I'll probably produce another 15-25 MCU-based designs over the remainder of my life, of which maybe 4 or 5 will use an 805x in the "classic" packages (DIL40 or PLCC44). The majority of the time spent on these will be in debugging and documentation. I don't want to have to learn a new debugger for each MCU, nor do I want to have to learn to drive someone else's user interface.

It's bad enough having to interact with Windows alone, just to invoke and use the terminal emulator. I certainly don't want to deal with the interprocess communication hassles that were never properly worked out, the DLL's that don't allow themselves to be dismissed when they should, and the other "gotchas" that pop up every day when I'm trying to figure out a problem. I certainly don't want to have to pick up a phone to call a pitifully ignorant support or sales person and then wait days or weeks before getting a solution, if one ever comes down the pike.

I'll repeat, "Where's the advantage" in having an assembler and disassembler on the PC, which will require that I run a communication task, a disassembler, an editor, an assembler, and another communication task just to patch a few dozen bytes of code. Yes, it's doable, but whenever I use a commercial package, I spend more time wrestling with the commercial package or trying to get it fixed than I do being productive. I'm willing to say that in most cases, a resident debugger with a link to a terminal through an external UART/BRG will outperform an ICE and its support tools, or JTAG and the associated tools, in terms of getting the job done. Now, I'm not talking about massive reworks, where new documentation and everything else is required, but merely the stuff I'm most likely to have to do on short notice. I just want to plug in my terminal interface, etc, and try to remember the assembler mnemonics. All of this stuff was much easier before Windows.

you said
"...But I still don't see why you need anything other than the most basic "kernel" to be actually resident.

It seems to me that everything else would actually be far better off being in a PC."

to which I have to ask, "Why?"

If I were writing an OS, perhaps, but if I'm fixing a problem that didn't occur in extensive simulation, and didn't show up in careful analysis prior to generating the code set in the first place, it doesn't require a major computing power to patch the code. It probably wants a bit inverted or a timing parameter modified to get the problem fixed. Do I really want to go through the entire edit, compile/assemble, link, download, and program sequence each time I modify a parameter? Probably not.

I just communicated with someone from KEIL, for example, a few days ago, and concluded that the individual concerned didn't even understand the page modes supported by the latest Maxim/Dallas 805x scions. What he didn't seem to understand is that it's possible to compute precise timing for any sequence of code executing in that environment. Though the MCU inserts extra clock cycles when a page boundary is crossed, it's clearly possible to compute the timing. What his comments mean is that their simulator doesn't simulate the hardware. Would you want to do your work with products from a company that asserts through its personnel that such timing is indeterminate? I'd be really careful!

I said,
" The fact that it resides within the environment under test is what makes it useful, since it then executes code with the timing and under other effects of the local environment."

to which you replied

"No, that is completely irrelevant. "

Now, I don't see how that can be true. If I'm trying to cause execution of a test loop that's not part of the main code body so I can get a picture of the interface state with the logic analyzer, possibly with the goal of tracking down a signal quality issue, I think it's completely relevant.

You said,
"So just putting the minimum debug "kernel" into the chip serves this goal better - because its cost is multiplied by every single chip, whereas only relatively few of the PC-based debugger apps would be required.

And having just a minimal resident kernel makes it much more likely to be generic and suitable to all your products - again reducing the per-unit cost.

Where specific "advanced" features need to be introduced, this can be much more easily managed by having different variants of the PC application that all use the same resident kernel. "

You don't seriously believe I'd ship the debugger with every unit, do you? It's a tool like and ICE or whatever. It goes in when trouble is being sought out, and comes back out when the job's done.

You closed with,
"It is generally best to push as much complexity as possible as far "up" the chain as possible."

... which might be true, were it not for the presence of Windows. Windows is pretty, it's easy to play with, but as for accomplishing useful work outside the common set of office or internet tools, I'd say it's a millstone around one's neck. If your tools use M$ Windows, and I've got almost all the versions, you're in for a difficult time.

RE