Nascom News­let­ter

Just as in the standard monitors, the W)rite command requires the start address and the one-after-the-finish address. However, a third argument is needed by HOBBIT, the address at which execution takes place. For when a program is R)ead, it executes from the specified address. If execution is not wanted, or if a file in required to be read to a different address than its logical one, then it can be L)oaded down to anywhere on supplying the L command with a single argument.

The two final commands go a long way to support standard Nascom software, whether it is an EPROM or RAM-based. The “Z” command requires two arguments. The first is the address of the start of a file, where that address holds the length of the file. The second argument is the execution address. For example, if you have ZEAP in EPROM, then Z 1000 D003 would store the source code and when R)ead would warm start ZEAP. Similarly, for NASPEN, Z 101A B806 would do the same. The “B” command also requires two arguments, but in this case the first one is the address of the first byte of the tile which also holds the address of the end of file plus one. Microsoft BASIC files are of this nature, for the ROM version B 10D6 FFFD saves the program. The RAM versions of both ZEAP and BASIC are thus also supported, if you know their relevant addresses.

There are 6 error traps in the system. They are indicated only by a single letter, but 6 are not too difficult to remember. The errors indicated are:–

A

Filename already exists

B

Bad file structure, ie. your program

C

Hard read error

D

Tape full

E

A file of that name does not exist

G

Cassette write protected

To date I’ve had no hard read errors, in fact the system appears to read/​write perfectly, with no errors at all.

The documentation also explains the function of the major routines in the software, together with their addresses, so that they can be called by your own machine code routines or programs. It is a pity that the original source code is not available (ie. for sale) as there is obviously a certain amount of redundancy in the operating system due to its wide support of all monitors and speeds, and other things, like the directory could do with altering.

Actually, I can understand the author’s reluctance to release his source code. The Philips Mini-DCR requires phase encoded data and, as far as I am aware, all previous designs have accomplished this in hardware. Dave Tucker has managed to perform this in software, which is why the interface is so simple, and presumably why the system has been kept so