★ APPLICATIONS ★ PROGRAMMATION ★ Montrac|WACCI) ★ |
| Montrac | Applications Programmation |
I always get this dreadful sense of foreboding when an envelope addressed in Peter Campbell's immediately recognisable handwriting pops through the door. It's usually either a Windows-only development utility for the PCW16, a photocopied review of AutoRoute Express to remind me that I still haven't finished RoutePlanner PCW, or a request to change the colours... It was a pleasant surprise, then, to open the latest jiffy bag and find Montrac, a programming utility which is WAGCO's first original release. Despite the name, Montrac does not track the flow of money in and out of your bank account. Neither is it a branch of the RAC catering for those eager beavers restoring the Montgomery Canal (aka the 'Mont'). It is, in fact, a Z80 monitor/tracing utility - a much more specialised market than the former, and probably more so than the latter. (You should see the problems the Waterway Recovery Group have with their vans...) Quick step to the left If you use Amor's highly wonderful Maxam 1.5 (and if not, why not?), you might have typed |QWXCL out of curiosity at some point. This brings up a not-very-well hidden message, telling you that "There is no need to mention single-stepping. We know! If the reaction to this is good, we will find time to implement it soon." The reaction evidently wasn't, because Maxam 1.6 never appeared: but here are the spiritual successors to Arnor, WAGCO, with a program that docs exactly that. Single-stepping means just what it says: stepping through a machine code program, a single instruction at a time. This lets you observe the effect that each part of a routine has on its variables and the Z80's registers, so if something's going wrong along the line, it'll narrow it down until you know where the bug's hiding. Monitoring shows you exactly what's happening, line-by-line, whereas tracing gives you a general overview of the program's progress without affecting register contents.
As well as these two single-step modes, Montrac stuffs a couple of other goodies into its economical memory requirement of 9k. The best is IROM, which not only displays all the commands built into a sideways ROM (a la |HELP), but also tells you the address of the associated routine: a great time-saver, although it's a shame it won't tell you about the hidden commands in AMSDOS or Protext. Less useful arc |MEM and |UNC, which edit memory and disassemble code respectively. Both are reasonable enough routines, with plus points in the forms of |MEM's extra decimal display and |UNC's ability to understand XH/YH and SLL instructions. However... since the memory editor is annoyingly slow and the disassembler doesn't interpret RST parameters according to standard firmware practice, you'll probably find yourself using the (near-perfect) equivalents in your Maxam ROM. Of coursc, you could buy a single-stepper without owning an assembler. But that would be silly. Cryptic clues About as silly as calling a disassemble command IUNG, in fact. This stands for 'uncode', apparently. All of the Montrac commands have these cryptic three-letter abbreviations, reaching their apogee in |LBF for Load Binary File. (And yes, it docs do the same us Maxam 1.5's |LOAD.) They doubtless make tilings a lot quicker once you're used to the program, but be prepared to be very confused at first. Similarly, there arc no helpful Midtiface II-style menus in single-stepping mode. Options are set with single keypresses, with a response of one beep for ‘off and two for ‘on'. There's a useful command summary in the back of the manual, which you'll need to keep close at hand for the first few weeks. Milk monitor Time to dig out a bugged program to test the program with. Where shall I look? I know, my AA covertape disc. Ho ho. But seriously, I received a letter from Ray Powell the other day saying that he couldn't get my Plus 8-bit printer port patch to work. Now I'm pretty sure it's a ROM problem: I reckon anyone who has more than four ROMs is asking for trouble compatibility-wise. But just to cheek, let's run it through Montracs to see what happens. First of all, it has to be relocated lower in memory, as its original location of &A000 conflicts with Montrac's file buffer. Since I'm going to loeate it at &7000, I try to use Maxam 1.5's |MEM command to set HIMEM to &6FFE Problem. Montrac's IMEM command, the memory editor, gets there first... Anyway, half a minute later, the patch is assembled and happily sitting in memory. Hie interface to the Plus 8-bit routines is obviously that of the firmware routines, so we need to load the character to be printed in A. With no equivalent to Maxam 1.5's |AF command, Montrac will only let you pass BASIC-type IX-block parameters: fine if you're debugging an RSX, but you'll have to write a short loader otherwise. This accomplished, we can finally get down to typing |MON. Inside looking out Sure enough, the first line of code appears: press a key, and it's onto the second. Montrac is sort of clever here, recognising that CALL &BD2B is a firmware routine. Since programmers generally don't want to trace the convoluted internals of the firmware (as long as you're not using a 464, you can be fairly sure it's bug-free...), the monitor automatically executes this routine without monitoring it. Fine. Except that it's not actually a firmware routine (yet), it's my patch. The manual suggests pressing C will get around this, but it doesn't. Rewrite the calling routine to jump directly into the patch, reread the manual, fiddle around for half an hour and... it still won't monitor anything other than the top level of code, passing CALLs with nary a murmur. Indeed, since it doesn't understand RSTs properly, it crashes as soon as it comes across a RST 8. Up to our hips Try it with the Montrac demo program. It traccs subroutines beautifully. It prints helpful lists of register contents when asked, it prints the top ten entries 011 the stack, and it will even do this after every line if asked. It's all a bit too much like a teletype, with no helpful use of windows for values, disassembly and output, but this docs mean that you can use it on a printer and turn screen output off completely -possibly a good thing, since there's no trapping for destructive routines like &BC0E (mode setting). Try again with a different piece of my code, assembled straight from Maxam. It's still not having any of it. I know it's 2am, but I don't smell that badly, do I? Judge Fudge Montrac's internal engine, with a couple of exceptions (notably RST handling), is an impressive piece of aide and could prove to be an invaluable debugging aid - especially for beginners, who are less likely to write programs that take over the whole Sadly, it's not quite there yet. Its human interface is too forbidding for beginners, while it doesn't seem to co-operate very happily with Maxam 1.5, at least - bizarre for a program which is being sold by WACCO. Functions such as loop stepping and subroutine tracing, although great in principle, seem rather erratic. It's equally possible that I haven't got the hang of them, of course, but the CPC Z80 programmers' market now is so tiny (hands up, chaps...) that the program can't afford to seem less than inviting if even double-figure sales arc projected. I suspect I'd love a version 2, with proper RST support, full Maxam 1.5 support, more meaningful command names, and perhaps a souped-up display. Version I shows a lot of promise, but asks too much of the user to be the miracle debugger we all wanted. Elementary, my dear And an apology to Mr Watson for the extremely long time that this review has been in the making: pressures of time, alas (in 10 hours I'll be on holiday at last). Asking one of the few remaining CPC commercial programmers to review' one of the others' products has its drawbacks...
|
