According to the Kansas catalogue, Philip Gibbs, the author of Kmon, was asked to examine all the existsing assembler/monitors for the Beeb and improve upon them, adding any feature he thought useful. Something of a tall order, so how did he get on?

One of the biggest failures of the existing products, he believed, was the way they 'felt' to the user. Kmon makes extensive use of colour coding of input and screen messages in Mode 7, and this certainly means it's easy to see what's going on. Assembler listings have all relevant MOS labels (such as OSBYTE, OSWRCH) inserted automatically when the relevant address is called, and this goes for user-defined labels too. The scroll speed of hex dumps may be adjusted, as well as being halted using CTRL-SHIFT. These features are very easy to get used to and make use of, but it's a pity after all this thought that there are a couple of niggles. For instance, all input is assumed to be decimal unless preceded by a '&'. Surely everyone who regularly uses a monitor/debugger would prefer a default to hex.

However user-friendly a product may be, it is of little use if it doesn't contain the right features. Kmon is a bit curate's eggish in this. Its assembler facilities are excellent, offering a single and double-pass assembler, producing a well documented listing and providing pseudo-ops ORG, MEM, DFB, DFW, DFS, SPC and REM. Most of these are implemented in the Basic II assembler, but are rather more self-explanatory under their Kmon names. Assembled code may be relocated using a built-in routine and then saved and run, again from within the system. A disassembly is easily arranged and the source is also easy to list and edit from the keyboard.

When it comes to the monitor, although everything is there, some of it is a bit awkward to use. The only time a 'front panel' display shows up, for example, is when running a program which comes across a BRK instruction. If it is then necessary to feed something into one of the CPU's registers, this may only be done indirectly by loading zero-page addresses assigned for the purpose. There is no way of single-stepping a program, although up to ten breakpoints may be inserted at different points in the code. Individual memory locations may be directly accessed and if a two byte value is entered, this is automatically up-ended into the low-byte, high-byte format used by the 6502. It would, however, have been easier to use if it were combined with the hex-dump, thus allowing the user to romp about in memory altering bytes as required (several similar programs offer this). Blocks of memory may be filled or moved, and single or two byte words may be searched for. All commands are single letters, some followed by the required parameters.

Overall, Kmon is friendlier than most, and worth considering in the same light as Exmon, ADE and others, but lacks some of the monitor facilities normally expected. With a few fairly minor amendments, it could be the best of the bunch.