conflicts would ensue if more than one card tried to generate Nasio. This is
borne out by the circuit diagram for the ram. (Incidentally, Map say that the
circuit diagram for the VFC is “now available”.) Now some of you may look up
the NasBus issue 3 spec (in the N2 manual) and cry “Nasio is not an OC line!”,
so who is right? Well, my Nascom I/O card generates Nasio correctly, and
treats it as an OC line, so I guess it was either a misprint or Nascom
changed their minds.
I know this may seem a trivial point to go on about, it’s just that I
like all I/O peripheral cards to generate Nasio, so that I can unplug, say,
the I/O card and still have a working Nascom. I initially connected the Nasio
link on my Map VFC, as well as having the I/O card generating Nasio, and
consequently took a VERY long time getting the RS232 on the I/O card to work
properly, all because the I/O card and the VFC were arguing over Nasio.
This brings me neatly onto my next topic. I was surprised to read that
Rory O’Farrell has been having problems PIPing COM files over the RS232
interface. A short time ago I had a similar problem, in that I needed to get
some files transferred from an ICL PC to my Nascom. I tried using PIP, and
like Rory didn’t have much success. It would open the file, but didn’t seem to
“know” when the ICL PC had finished transmitting. The file was probably in
memory, but I didn’t know where. I also encountered problems of different
buffer sizes (no RS232 handshaking!). I solved this by writing a very simple
program to run under Monitor.Com which read characters from the serial
interface into memory. Then when the ICL PC had finished transmitting, I
pressed RESET, re-loaded Monitor.Com, and, because the cold boot loader leaves
the TPA alone, there was my file in memory, waiting to be saved.
The ICL PC had preceeded the file by sending about 40 NULLs, and
terminated the file with about 40 more nulls (and a control-z character!), but
by using DDT on the ICL PC I was able to determine the exact size of the file,
and how it began, so it was easy to identify where the required program was.
Very simple, and so much easier and quicker than using a disassembler!
Re-Inventing The Wheel
It has occurred to me while upgrading to CP/M that I would need to
translate all my Zeap files to Macro-80 format, and all my Nascom Basic files
to MBasic format. This will doubtless require the writing of some simple (or
not so simple?) program. Now how many other people have written such
utilities? Quite a few, I would imagine. What a total waste of time and effort
if such routines already exist! I wholeheartedly agree with Dr. Darks comments
about “idle bodies” in this context. Such routines would be so massively
useful to Nascom (and Gemini owners who have switched from Nascom?) that I am
sure Mr Editor would publish such an article were it to be submitted. This is
why Dr. Dark’s “Ring of Rust” software circle has got to be a good idea, in
that everyone can swap such useful little utilities. As I write, I am not on
the “ring” yet, but then I only wrote to Chris a week or so ago asking to be
Why have I not written such utilities yet? Well, I have just written a
Zeap to Macro-80 preprocessor, which will be put on the “ring” in due course,
and, of course, written up into an article for this magazine just as soon as I
have written a Nascom Basic to MBasic preprocessor.