Well, a lot of things have been discussed in this loooong thread, even abundant opcodes and a completely different question... So what about getting back to the original question.

While the answer to it is clearly "NO" (or at least nothing readily available), let me elaborate on it a little bit further. Richard, please, correct me.

First, let us put aside the question if it is useful to have a monitor or not. Enough said on that.
Then, let us stress the reason - it is intended to be used on multiple platforms, with as similar user interface as possible across them. (This mostly rules out available emulators and most of the monitors, as the user interfaces for them vary wildly.)
It is not intended to develop new products, rather, to maintain (long)existing and sometimes unique products (again, let us not discuss further the reasonability of supporting an old product and possibility to replace an old product with a new one). It is required, that the debugged program maintains exact timing. Therefore it is required that the monitor runs on the original processor or an equivalent replacement (this is where the SiLabs are ruled out as an emulator for standard '51, as it does not keep the timing of instructions).
It is assumed that there are (relatively) ample resources of ROM space at each target (tens of kB), and there is an UART available (or can be attached in some means) to connect to COM port on a PC. Programming on PC is to be avoided.
It is required that the monitor should have a disassembler, a line-assembler, SFR and memories display and manipulation; then single-step and run process with breakpoints.

The original idea is the full monitor implemented on the target in C (for portability).
Plus: on PC, any dumb terminal is all that is required. One can even do without PC - a terminal is on virtually any platform, including various handhelds - a bonus when working in field.
Minus: The interface - let's face it, by now we all got used to it - no clickable menus and windows :-)
Other minus: Lot of work to be done. Let's analyze: memories and SFR manipulation IS platform dependent. Single step and breakpoints ARE platform dependent. Disassembler and assembler are PARTIALLY platform dependent, if table driven. Displaying and user interface IS NOT platform dependent, but that's the easiest part of the job. And the C itself is rather platform dependent. Seems that not too much of the job can be "recycled" it this way... Also, there is some shlight risk that the monitor would be too big and would not fit within the spare ROM space of each target (OK in this case some of the "luxury" can be spared out, but that's extra work).

IMHO it would be better to have a minimal core in the target, performing just memory/SFR transmit and receive and jump to given address - that's all what's necessary (plus necessary infrastructure - initialisations/connecting, saving/restoring context when entering/exiting monitor/core). The major work is "pushed up" to PC.
Minus: Work on PC inevitable, portability (to to other GUI-enabled platforms (e.g. the handheld)) questionable.
Plus: Most of the job (although the same amount of it platform dependent, but portability of code across various C's is now out of question) can be done on PC where resources are abundant and pre-cooked development tools are readily available. User interface can be more fancy. Minimal core fits to more target systems (with less resources). The core is small enough to justify the job done in asm, if preferred.

The work on PC can be avoided in two ways: the less practical is to insert an another microcontroller between the target and the PC, performing the gro of the work. Then, the PC would again run only a dumb terminal.

The smarter way is to utilise available minimal core systems, where the PC-job is already done (at least mostly). I am aware of two of such: Keil's MON51+uVision, and NoIce.

Keil's is '51 oriented and not too probable that they are willing to implement anything else. They don't publish source code of the target core, so it's not easy to implement it in a non-standard target system; and it's not easy to port it (accepting certain limitations arising from the strict '51 orientation of the PC part) to different targets. In fact, it is enough to know the protocol, but it is not published, either... (but maybe obtainable?). There is a code size limit for the trial version, but for experimenting it is good enough.

NoIce comes with sources for the targets, published protocol, and quite a lot of documentation. It is implemented on similar targets than the required, and the author(s) is(are) willing to port it to other platforms. There is a DOS and a Windows version. Not free, but quite cheap. I don't remember if there is any trial (maybe the DOS version?).


Jan Waclawek


PS. I have a bunch of spare XCHDs here, in good condition, anybody interested?