[This is a copy-post of one on the VCF forums; replying there will probably get a faster response.]

I've long found the built-in machine-language monitors in my vintage computers frustrating, when they even have a monitor at all, and I've finally sat down to do something about this. So I've designed a new monitor, called "tmon," that I feel will be a more powerful and convenient to use yet still be fairly compact, suitable for dropping into a ROM in computers that have space for this (e.g., into the option ROM socket on a NEC PC-8001, or loading into the Language Card on an Apple II). Currently I have only an 8080 version, but I do intend to write 6800 and 6502 versions as well, and perhaps even 6809, 68000 and 8086 versions.

The goals of this project, as described in the README, are to have:

• Reasonably small code size: under 2 KB.
• Very minimal RAM usage: just 2-3 dozen bytes so it can run on e.g. a 6802 with only its 128 bytes of internal RAM.
• Significantly better features than many home computers' built-in monitors, including properly handling the usercode stack (or working without a valid usercode stack).
• A user interface focused on convenience. For example, remembering recently used addresses so you need not continually re-type them and allowing you to intersperse hex and ASCII data input.
• Efficient use of the display, allowing you to display just what you need and minimise non-informational printing to reduce useful information scrolling off the screen.

What I've got now seems good enough to be usable, so I'm now looking for feedback, whether it's just comments on the README or from actual use. Towards this end I've consed up a CP/M version that, while not yet a substitute for DDT (because it runs in the TPA, rather than relocating itself above it), does let you play with it and get a good feel for how it works. I'm particularly looking for feedback on the design of the monitor, but I also welcome comments on the code, especially since this is my first major project in 8080/Z80 assembly language.

If you want to do me the favour of trying it out, attached is a ZIP file with the full README and TMONLVT.COM, which should run on any CP/M system. The ASCII display requires a VT100-compatible terminal supporting reverse and underline character attributes, but aside from that it will work fine on any output device that handles backspace, CR and LF in the expected way. There seem to be some bugs (do read the platform release notes at the end of the README); in particular the K "call" command works on my command-line CPU simulator but not on CP/M for some reason. The README describes where to find the source. (If you want to build from source and experiment with changing it, I'm happy to provide support for that, or even pair-program with you to get you started.)

I'm also happy to look at building machine-specific versions for whatever machine you'd like to use it on. As you can see in the TODO list, Kyocera-85 machines (NEC PC-8201, TRS-80 Model 100, etc.) are high on my list for ports in the near future, as is PC-8001, but I'm happy to look at anything else.

You might want to split the design into 3 parts. A the monitor B simple device drivers C cp/m or dos BIOS.
4 Kb is a better rom size if you have the rom space in the memory map.

I'm rather unclear about what you're saying here. If you mean that there should be a conceptual split between those things well, yes, that's already there. If you check the source, src/i8080/tmon.i80 contains the core monitor code, the BIOS (essentially just reading and writing characters) is provided by the system ROM, OS or, where not present, included from other files (see exe/cpm/tmonlvt.i80 and exe/tmc/i8080/tmon.i80) and the CP/M or DOS BIOS is provided by CP/M or DOS, if present. So what should change about this?


I don't in many cases and, even where I do, I have better uses for the space. But what's missing that needs so much extra space anyway?

It more the case you can't get the tiny EPROMS anymore.

I have a handful of Atmel AT28C16 EEPROM and one Fujitsu MB8516 EPROM, so I'm ok on that front. (I haven't checked how many computers I have that use these, but I don't think it's a huge number.) But even if I didn't, it's not hard to make an adapter board for a more modern device that can substitute for these old ones. (I may end up doing that anyway, if I end up with enough ROM-based code that a Dial-A-ROM or something similar would be useful.)

But size considerations extend far beyond just the PROM devices, or even just having more room for other things. For example, if you want to replace the CP/M CCP, you generally have only 2K of space for that on the system tracks of a CP/M diskette.

if you use EEPROMS don't forget a write protect switch.
I am using 28C64's on my latest project and my serial loader
is a pain to toggle in from front panel. I have new memory cards
with that feature and few bug fixes with bypass caps,but I have
yet to transplant the old proms
into the new cards.

Thanks for sharing your monitor cjs!

Thanks. What I'm really looking for here is feedback on the interface and features, since making changes to that will be easier before I port it to 6800 and 6502 (and probably Z80—I'm really missing the relative jump instructions). And maybe even 68000 and 8086 if I ever get around to writing simulators for those CPUs.

2k is very small. Small is good. Even smallish embedded apps are using 32-bit CPUs these days though.

How does the monitor compare to something like SuperMON / SuperMON816? for the 6502/65816.
SuperMON is a bit larger, but packed with useful features.

Well let's keep in mind this this is designed to run on 1970s hardware, not modern hardware.



Overall, I'd say that tmon is more featureful than SuperMON 1.2, with the exception of disassembly and assembly, which I will probably add as an optional module at some point. (Unfortunately, that increases the size significantly.)

The primary difference is in the user interface; tmon is a lot more keystroke efficient. Once you've set up commonly used addresses, you can keep using those without retyping them. For example, you can type just K to call the current call address, then D to dump memory using the current width, size and examine location to see what your routine changed before returning, and then . to modify at the current modification location before you start the whole loop again. Perhaps I should put an example of this kind of usage in the docs.

Input and display are definitely better. tmon dumps hex, ASCII (which the original SuperMON didn't, though 1.2 does) and screen codes, and lets you enable/disable these separately, so if you need to page forward through memory looking for strings, for example, you can do that a lot more efficiently. As well as hex byte input tmon has hex word and ASCII input, and you can switch between these modes on the fly as you're entering data. E.g., in byte input mode, you can type 'A and it will back up over that and replace it with 41 (the ASCII code for A).

SuperMON 1.2 lets you do input in arbitrary bases, whereas tmon is strictly hex. I'm not sure how useful that is; certainly not as useful as ASCII input. tmon has a calculator built in so you can do 16-bit adds and subtracts, and see the ASCII values of bytes. tmon can also calculate 16-bit CRCs of arbitrary areas of memory, which is handy for checking if things have loaded correctly, or changed, or whatever. (Or what version of a ROM you have in the system.)

Have you read the docs for tmon? I'm interested in your opinion of how you think it would work for you. (And even more interested if you try it out. If you don't have a CP/M machine or simulator, I'm happy to try to build a version for whatever 8080/8085/Z80 machine you do have.)