Controller card, or the Gemini Intelligent Video Card, to give us the required
screen size, there’s no way that we can see what we want to see nicely
formatted on the screen. Therefore I was pleased when I found an article by J.
Baraclough on page 135 of January ’82’s PCW giving the necessary changes to
ED.COM and DDT.COM for them to fit onto smaller screens. To summarise his
article: In ED, the number of lines written by the P command are held in
location 161CH (Version 1.4), and 17DBH (Version 2.2). Change this from 17H to
0DH. For DDT’s D command, the number of bytes displayed per line is held at
0A15H, change this from 0FH to 07H. The number of bytes in each block
displayed is held at 09EDH, so change this from 0BFH (16 x 12 lines) to 05F (8
x 12) or 06F (8 x 14 lines). The number of lines disassembled by the L command
is held at 09BCH, it’s set to 0CH (12 lines) change it if you wish to 0FH for
your 15 line screen.
Spurred on by this information, I sat down and worked on ZSID.COM, and
came up with the following: For the D command, 12AFH holds the number of bytes
displayed per line, change this from 0FH to 07H for a screen less than 54
characters wide. 125EH holds the number of bytes displayed per block, so
change this from 5FH to 2FH for a standard Nascom screen.
AN OPEN LETTER TO RICHARD BEAL
Oh well, Mr. Beal, it looks as though you’re going to have to start
work now if you’re going to get a CBIOS written to support CP/M version 3’s
new features by the time it’s released. When you’ve finished it, how about
writing a utility program to run under CP/M that will give us all the
debugging features of NAS-SYS that we know and love, plus a few extras such as
Find, Compare, Read and Write programs from/to disk, and Call (like Execute,
but CD rather than C3). It doesn’t need to have any screen handling or support
for the Nascom keyboard, because that’s already in the CBIOS, in fact it can
lose all the Monitor functions, and there will be no need for us to be able to
access any of the subroutines unless we want to write ‘illegal’ programs.
It shouldn’t be difficult, or take long, because you’ve already got
most of the source code. All it needs is the ability to relocate itself to the
top of the TPA. I’d do it myself, but I’d feel tempted to let other people
have a copy, and that would get me into copyright problems, wouldn’t it!
MACRO-80, LINK-80, ZSID, AND SYMBOLS
Those of you who are rich enough to own the Microsoft MACRO-80 macro
assembler and Digital Research’s ZSID Symbolic Instruction Debugger (I once
knew a singing duo called the Symbolics. Sym was a really nice girl, but her
partner....) or those who are dishonest and know someone who has these
packages will know that the symbol table produced by MACRO-80 is incompatible
However, the table of globals produced by LINK-80 is compatible. So,
we have to convert all the symbols in the source file for MACRO-80 to globals.
This is easily done using ED.COM or DISKPEN. Using the F command replace all
the occurrences of ‘:^I’ with ‘::^I’. This will look for the colons before a
tab, and replace them with two colons, thus declaring that symbol to be
public. Using LINK-80, the Switch ‘/Y” when used after ‘/N’ and before ‘/E’ or
‘/G’ will create a symbol table ‘PROGNAME.SYM’ which is compatible with ZSID.
I find that the Nascom 2 keyboard is illogical. Every time I try to
hit the “ENTER” key, I usually hit one of the other keys that it hides amongst
(OK, I’m not the best typist around, all those spelling mistakes in this
article are really tpynig errros!). I usually hit the one that sticks out on
the end: CH/LF. So, one night in a fit of drunkeness, I attacked my keyboard
with a blowtorch and some solder, and when I next used my computing machine, I