Communications

This package contains programs which do some sort of RS-232 communications.

My System-80 used a custom-built RS-232 adapter which was not compatible with the standard TRS-80 one. The RS-232 adapter came from Deakin University and was specific to the System-80 (i.e. it plugged into the System-80's unique 50-pin expansion bus using a standard 25x2 way plug).

The RS-232 adapter had only the one 50-pin connector, which meant that it could not be used with a disk system (neither expansion box provided a connector to daisy-chain other equipment). The RS-232 adapter was designed for cassette users. When I got my disk system, I modified the RS-232 adapter and soldered it inside the System-80 Expansion Unit. I don't recall how many iterations the adapter went through, but at the end I think I had it mostly plugging in via the 20-way connector which the Expansion Unit provided for that purpose.

The RS-232 adapter was incompatible in another way too. It used a different UART chip than the standard TRS-80 one, which needed to be driven quite differently. My one was more powerful ... but this is of little consequence when every comms-using piece of software needed to be modified to work with my gear. Anyway, I didn't use other peoples' comms software mostly.

dumprom

There was an Australian-designed modem called the NICE Modem which was being sold by an acquaintance of mine, Geoff Arthur. The NICE Modem had a command to dump its ROM contents. This program obtains that data from the ROM and writes it to disk.

exmodem

This was an XMODEM type file transfer program. XMODEM was all the rage before ZMODEM came about. I really don't recall if I wrote this program from scratch or modified somebody else's. In any case, it was hacked many times over the years to add various extensions to the basic XMODEM protocol, such as 16-bit CRC checking, non-integral final block size, and various methods to transfer multiple files in a single session.

getfiles

Getfiles is another "single-use" program. Its job is to get a list of files from an OMEN type system (Ted Romer ran OMEN BBS in Sydney, he is still around but does not run BBSs anymore, he owns a company called Watermaid which manufactures electric pool chlorinators). I couldn't figure out from looking at the source code how it gets the file list, but it then downloads each file.

remote

This little program links the standard TRS-80 display and keyboard devices with the RS-232 adapter. So basically output from programs would go to both the screen and the modem, and keyboard input could also come from the modem.

I used this program to play "security games" with Mark McDougall. I would lock my system down in various ways, and he would dial up via modem and attempt to defeat my security measures. I don't recall just how the system was secured or what tools were made available to assist in the removal of those measures. Perhaps I gave him a debugger or the editor-assembler. I expect Mark did the same with his machine and I dialled into him to try to break through his security.

This program was probably the very first piece of software which became Zeta Internet.

term

Term was a pretty standard terminal program. It was able to use a variety of baud rates, bit sizes and stop bits (as my non-standard UART permitted), and had various compatibility modes and a character translation table. I used it to dial up BBSs but more importantly, to access NSWIT's Honeywell Level 66 computer via modem.

The Honeywell was a dreadful computer and its modem interface was no better than the rest of the system. It was 7 bits even parity if I recall, and half duplex, with no flow control, and it was necessary to wait a little after sending each carriage return, because the system had no input buffering, sending too quickly would cause data to be lost. If you think file transfer would be hard under those conditions, I seem to recall that it had automatic pagination which could not be turned off, and that just added to the difficulty. NSWIT's Honeywell had 5 modems, and some of them would not be working at various times. I remember there was one modem (or one terminal input) which would not accept the uppercase letters T through Z on an input line. If you were to type one of these letters the entire input line would be rejected. I reported this problem to the Computer Centre and they dismissed my report as out-of-hand as if I had been taking drugs.

I remember one more amusing story about the NSWIT computing infrastructure which is worth telling here, even if this isn't quite the right place for it. Around 1985, NSWIT used X.25 multiplexers to link its central Computer Centre (with its Honeywell) to terminal rooms around the campus. These X.25 multiplexers had a certain bug, which was if they saw a packet containing 4 contiguous lowercase "n" characters, i.e. "nnnn" on either input OR output, the multiplexer would crash and all users of that multiplexer (up to 16 people) would lose their sessions. I discovered this problem while trying to read a manpage (or the Honeywell equivalent). I every time I would try to read the manpage the system would crash. After a while I realised the connection. I was able to write the manpage to a file then I went through it line by line with the editor, so I knew the line _before_ the crash line. Somehow I split up the dangerous line character by character to see the 4 "n"s which were the source of all the trouble. I reported that problem also, but I don't recall the problem being fixed before the equipment was replaced with something better. I actually related this story in brief in Risks Digest 14.46, online at http://catless.ncl.ac.uk/Risks/14.46.html on 3rd April 1993.

Download

• trs80-comm-1.0.tar.gz