Erik:
"Actually, the manufacturers take great pains to ensure that emulators do stay in synchronization with the target system.
Which you, while still babbeling about “synchronization” which I STILL do not know what has to do with it, in a previous post stated as a deficiency of an ICE."
*
Richard:

First of all, I think you need to consult a dictionary or spell-checker.

Secondly, there are numerous types and levels of synchronization, of which you seemingly are only familiar with a subset.
*
Erik states: "That is not "synchronization", that is emulating." Richard: ... Emulating is what IT does. Running the code in its ROM is what the target system does.

For a current uC (e.g. P89V51Rx2) the emulator runs the code and so does the chip. Both with no external connections to get the program. If there was ANY difference between what happened running with an emulator (obviously only till a breakpoint was reached) it would not be an emulator, it would be something else.

They can and do, but I don't know how well, how costly, and what "additions" e.g. pods, etc, I'd have to buy before I could get useful work out of their product.

So you ask half the question, get a yes, and then keep refusing the possiblity"
*
Richard:
WHAT? Possibility of what? What question do you imagine was asked? I am not the one who brought up the ICE. An ICE is not a debug monitor. I asked about a debug monitor that does assembly and disassembly, line by line, and is available in 'C' language source code.
*
Erik states: "...No simulator will ever be "true"."
and I say, This is exactly why I prefer the resident debug monitor.

I make a statement denying what you said about a simulator (it can have exact matching) and you reply with “I prefer the resident debug monitor”.

Richard:
Well, your statement is clearly incorrect, but first you should go back and reread what I really did say. You said, "...No simulator will ever be "true"." and that's absolutely false. A simulator can and must ALWAYS be exactly correct, else it is rubbish. After all, it's just a bunch of computations, i.e. software. Software can and must meet its requirements, and the first requirement of a simulator is to be a precise and correct reflection of the simulated subject's behavior when stimulated with the specified stimuli, at least to the limits of the available specifications.

It doesn't matter at all whether the performance of the running simulator is in any sense in line with the simulated object, so long as the output reflects, accurately and precisely, the effects brought about by the stimuli.

Your previous remark about not being able to "match" the performance of an MCU in Windows, though correct, is completely irrelevant.
*
Erik:
"PS
as said earlier, it does not matter what you want (which you keep talking about) you can only have what is available (which I talk about)."
*
Richard:
My original query was,
" ... I'm curious whether anyone has run across a full-function resident debugger for the 805x, including the Maxim/Dallas versions with multiple data pointers, etc, that incorporates all the functions of the old MS-DOS DEBUG.COM. ..."

An appropriate response from you would have been no response at all. Instead, you've repeatedly tried to sell me something I don't want, and, indeed, already have. I don't want or need another ICE. I don't want or need additional JTAG support hardware. What I want is a full-function resident debug monitor, for the 805x, that's available in C-source. If there isn't one, that's OK. I just don't want to spend time reinventing the wheel. If there isn't one, then I velieve it's worth generating one, first, because it'll serve my needs, and secondly because I can adapt it to other MCU's which I also use. That way I don't have to learn a new command syntax, etc. for each debugger I use. I have the PL/M source for the DDT monitor that was written for the 8080. It won't be terribly difficult translating its functional kernel to C. In fact, I have PL/M-51, so I could generate it for the 805x directly, with the exception of the assembly and disassembly routines.
I've "discussed" these matters with you in order to clarify what I want. I believe it's clear to everyone but you.

Erik:
"You may have seen wonderful things for the PC, the ACME, the PHnox, the Unicorn or whatever processor - here we discuss the '51."
*
Richard:

What I've "seen" doesn't matter. I know you discuss the '805x and its scions. However, the mention of other MCU's comes up in the context of why I want 'C' language source code, if it's available, for a debug monitor. The low-level assembly and disassembly rountines would, of course be different, though the associated command syntax wouldn't. The setup modules would certainly have to be different at the lowest level, but the high-level initialization functions probably would remain the same.

BTW, I don't know any of the products you mention, with the exception of the PC.

RE