80-Bus News

I thought perhaps describing the bones of writing a games programme wouldn’t be a bad idea this time. ‘Battleships’ I thought. But then at the time of writing (late May), I thought that might not be too appropriate. Then I thought of a new game ‘Bomb the Argies’, but couldn’t quite work out the rules, in fact there didn’t seem to be any. Someone might accuse me of being tasteless (same as the writers of the game ‘Three Mile Island’ were likewise abused after their game came on the market three weeks after a certain nuclear power station nearly blew up. Must admit it was quite good, particularly the colour graphics of the glowing reactor, played on an Apple by the way.). So we need a program which will be short, with well defined rules and totally uncontentious, taking these criteria into account, it’s easy to deduce that it will probably also be extremely boring.

Right back in the mists of time, shortly after I acquired a Nascom 1, I remember writing a machine code version of Hangman in the hope that I might justify the time I was devoting to the machine by entertaining No. 1 Brat, at that time aged about seven or eight. Now Hangman’s hardly contentious, the only people that program could upset is the anti-capital punishment lobby, and then only figuratively. So I rummaged about for it, I found a Nascom 1 format tape which I couldn’t read, but no sign of the source. It then occurred to me that it was written in pre-assembler days, and if there ever was a source, it would have been handwritten and not machine readable anyway. So I might as well write a new one. So ‘Simple Hangman’ saw the light of day last evening. It’s printed somewhere in the mag. It’s not buried in this article so that whoever does the paste up on this issue isn’t going to get a headache trying to fit a monumental chunk of DH’s stuff in one place. Apart from that, it runs stand alone, so anyone wishing to use it can do so. Rewriting Hangman has served a secondary purpose, as it has entertained No. 2 Brat, aged about seven and a half, over the last few days. That also explains the choice of words in the word table. I offer this explanation, just in case someone decided to draw Freudian conclusions about me from the word table. Anyway, If anyone wanted to draw conclusions, they’d do better reading this rubbish. Don’t write to tell me your findings, I know, I know!!!

Ok then, let’s think about the special parameters required in writing a program like this. Now the first one is that people reading this article will have different systems, notably, Nascom’s running NAS-BUG 1, 2 or 4 (heaven forbid), Nascom’s running NAS-SYS 1 or 3, Gemini’s running RP/M, or Nascom’s or Gemini’s running CP/M, or some other combination I haven’t thought of. To complete the ‘foul-up’, I’m running a homebrew mixture which features a Nascom 2 with Gemini CP/M and a number of other assorted odds and sods. Now that adds up to a lot of system incompatibility one way or another. How to get round that one? Well, the only areas that need concern us are where the systems are different: the memory maps, the input and output of characters and the way the program is exited. If I provide ‘user patch areas’, for the input/​output and exit areas, and direct all input/​output to the program via these patches then that problem is solved. If I assemble the whole lot starting at 0C83H and provide a ‘start jump’ into the program at either 100H (for RP/M – CP/M) or at 0C80H (for NAS-BUG or NAS-SYS), then the memory mapping problems are also overcome. True under a CP/M – RP/M environment it wastes nearly 3K of space, but we can’t have everything. Another criteria regards memory mapping is that the program shouldn’t be larger than 0FFFH, otherwise it won’t fit on a minimum system Nascom 1 or 2. Of course, the real reason for providing these facilities is that it allows me to be lazy and not have to provide half a dozen different versions.

To make life easier, I’m going to concentrate on only two ‘generic’ versions. A version which will run under NAS-SYS 1 or 3, which I will call the ‘NAS version’ from now on, and a version which will work under CP/M – RP/M, which I will call the ‘CP/M version’ from now on. Differences for the NAS-BUG version simply require the input patch to be changed, such that it saves all the registers, CALLs $KBD, CALLs $CRT, then restores all the registers, whilst the output patch again saves all the registers, CALLs $CRT then restores the registers. The exit should be either an absolute jump to PARSE (but watch out as this does not reset the monitor stack), or an absolute jump to 0000H to reset the system.