80-Bus News

CALL followed by a RET, both can be replaced by a JP (saving one byte) or better still a JR (saving two bytes). This saved two bytes from Hangman, and further, because I removed a CALL , two bytes of stack space. Further, in CRLF1, where CALL SNDTXT and RET have been replaced by JP, this JP can be eliminated completely (saving another three bytes). The reduction of a CALL – RET sequence to a JP/JR also works for a relative CALL, but saves nothing with a RST.

If you like my random number generator, I can save even more bytes. This is based on SEED=((SEED*5)+21) AND 7FH; and produces an even distribution of numbers between 0 and 127 (i.e. after 128 CALLs it has produced each number once). The sequence cannot be described as truly random as the sequence is always the same so I use the R register to provide the initial seed. The call and return parameters are identical to those of the one used (i.e. called with A=range, and returning with A=0 to range-1).

This random number generator uses only 26 bytes plus one byte for workspace and four bytes to generate the initial value for seed from the R register, which must make it one of the shortest random number generators you have ever seen. The numbers 5 and 21 were chosen to get the best result over the chosen range and for a different maximum a different pair must be used (I used a GEC 4070 to do the calculations, but a Nascom could do it as easily).

Yours sincerely, W. H. Turner.

Well Mr. Turner you win, I should have my wrists slapped for not thinking of that one as it is one of those programming tricks that is lurking at the back of my mind, and, as you say, it saves space. As to your random routine, well that deserves the prize alone, so I’ll be sending you the fiver.

Well, the DH bit gets written as and when I feel so inclined, as it is now shortly after Christmas, I am more inclined than usual (perhaps Dr. Dark sent me some of that West Country gut rot he keeps on about for Christmas). A couple of issues back I wrote a piece about data transmission by radio, which to my surprise brought rather more letters than I had expected, strangely all from radio amateurs. This has identified a new area of the 80BUS readership for me. On the basis that I had about half a dozen letters on that one topic, and that normally anything else only prompts two or three, I can only judge that radio amateurs form a substantial part of the readership, or, alternatively, that they are a vociferous minority. Since that article, the Home Office have seen fit to issue my licence and I have since discovered (by using my radio) that a lot of radio amateurs are also equally knowledgeable about computers, and that a fair number own Sinclair ZX8i1s (never mind, they’ll learn), Nascoms and Geminis.

All this preamble is a way of getting round to my theme for the next issue or so, that of databases, Mbasic and disks. You see, I have written a radio log keeping program, which apart from serving its designed purpose, has taught me an awful lot about the way to tackle large programs in Basic and something about how to handle small databases. “All right”, I hear you say, “What about databases, I’m not interested in keeping a log book so what use is it to me?”. “Well”, I reply, “The princples are the same whether you’re running a log book or keeping a running inventory of the freezer (just in case large mice are persistently running off with next weeks Sunday joint).”

Now what is a ‘Database’. Well it’s a file stored on tape or disk which contains the data you intend to work with, or to modify, or to delete, or what have you. The database has been so constructed as to allow easy access to the various individual parts of which it is composed. Ok? Not really, that sentence is written in the pseudo technical double talk you see in some manuals. Imagine your cheque book, it’s a book isn’t it, odd shape for reading, but a book none the less. Let’s call that an empty database, it’s empty because nothing has been written on the cheques, and it’s the writing on the cheques we are interested in not the cheques themselves. Now the cheque book has a number of individual pages, each unique by merit of the serial number stamped on the bottom. Let’s call this an empty record, again, empty because it’s what’s written on the cheque that matters. Now consider the cheque itself. It has a line for the payee, a couple of lines for the amount in writing, and a box for the amount in figures (a different form of the same data), it also has a line for your autograph and another for the