80-Bus News

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.

RS232

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 included.

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.