The Memorex-Telex MTX-500 series has a (very?) good debugger in ROM. I think the debugger has its own chunk of RAM in a separate address space too. Do any of the other examples have this? One of the examples you mentioned is unfortunately not useful to the hobbyist user (even if the user has experience). The HP-48S and SX hex editor is only a gimmick without a very detailed description of the internal structures of the system. (And being in a FORTH-like language on a 4-bit processor, the internal structures are _vital_. There are lots of magic addresses at other special addresses in memory. The 4-bit architecture is *little-endian* so you have to reverse each hex digit of the addresses too.) It's not very easy to use even if you do have that information. Besides, the editor is a pain to use. A raw dump of nibbles, only a line of them, with no address or context information, and an *invisible* cursor? Realistically I think it was designed for factory testing. Other examples may fit in the same category. Many Macintoshes have a debugger in ROM which is so low-level that it's a step back from the Apple ][ monitor in functionality. Fortunately Apple made up for that by acquiring MACSBUG you can do _interesting_ things like removing copy protection (but you still need to be pretty expert on the Mac). It's free from Apple. Unfortunately it's not in ROM. I'm really hijacking the topic to ask about _useful_ debuggers. Allison thinks debuggers are a thing of the past. I disagree -- I think they can be very useful even on a cutting-edge system. Or perhaps my ideal useful debugger can be very useful on my ideal cutting-edge system. :) Unfortunately their usefulness depends on the software they're debugging. Perhaps Allison was making her point because Windows is such a mess and is so undocumented. Of course writing a useful debugger was difficult in 1980 and is even more difficult now. (No, I don't know how. No, I'm not sure what's required for a debugger to be useful.) -- Derek

Eric Smith wrote: Yup, every OSI machine I have dealt with powers on with: D/C/W/M ? and pressing the 'M' takes you to a neat little 6502 ROM debug monitor. Bill Sudbrink

D. Peschel wrote D - disk boot - Jumps to some fixed address where the disk bootstrap routine is known to be. C - "cold" boot - Machine initializes all memory to power on values and starts basic in ROM W - "warm" boot - Machine performs minimal initialization to restart basic in ROM. Attempts to leave memory (including basic program store) in tact. Sort of a basic debug mode. Example: 1) basic program hangs 2) hit reset button 3) warm boot 4) you can now do things like: LIST or even better: PRINT X$ M - monitor - Runs monitor in ROM, again with minimal initialization Bill Sudbrink