I'll deal with these questions in reverse order.

"5. What would you expect to pay (roughly) for a debugger of your specification? (I'm not going to do it - I don't C at all - just being curious). "

I'm engaged in a make/buy decision. Based on the quality of most of the commercial development software I've seen, I wouldn't pay much.

I have a slow period coming up, between July 4th and Labor Day, during which most people take their summer vacations and it's difficult to contact the necessary people in order to do business. It's during that timespan that I do much of my maintenance of both hardware and software. There's another such break between Thanksgiving and the Superbowl, when many people are too busy to do useful work.

"4. What about Keil's Mon51 and its variants (check out e.g. SoftIce at SST and Philips)? "

I'm aware of these products.

"3. What do you exactly mean by "line-by-line assembly"?"

Using MSDOS' DEBUG.EXE as an example, line-by-line assembly is what happens when you type where HHHH is the address to which the assembly takes place. Likewise, line-by-line disassembly is what happens when you type and HHHH is the address from which the disassembly takes place.

"2. DEBUG in DOS does not come with source. Why do you need specifically a C-source debugger? Couldn't PaulMon be the basis (it allows some extensions, so you or somebody else can possibly write the "line-by-line assembly")? "

The source is needed because I want to use the same skeletal debugger for all the MCU's I have to support in this way. That includes the 805x's, the 6805's, the 6801 (though I have a nearly suitable tool called "LILBUG"), and a very few others, for all of which I have suitable "C" compilers. Paulmon is an alternative I'm considering, though it's not easily translatable to other MCU's because it's written in assembler. Substituting a table-driven assembler/disassembler module would probably not be a problem. Efficiency is not a problem either, particularly where memory usage is concerned, since most of the systems I have to support with this type of tool have a very small memory map.

"1. what ROM/RAM/STACK overhead (needed for a resident debugger or at least the space it lives in) is available in your "old designs"?"

Since their (that in the old systems I'm targeting) RAM space is very limited, the use of more modern hardware allows fairly generous use of RAM resources outside the portion of the memory map that is used by the old-timer MCU's being examined.

RE