Second Light
for the
Tesseract RCPM+ computer

The term "First Light" refers to the ignition of a star as it condenses from the primordial interstellar material.  "Second Light" is not quite so dramatic.I am using the term to describe the resurrection of the computer which ran Tesseract RCPM+ in Dural, NSW, Australia in the nineteen eighties.

Before I left Australia in the early nineties I gave the computer to a friend. I subsequently lost touch with him but tried to contact him in 2008 only to learn that he had died.  His father had all his computing equipment and was happy to have me take the Tesseract computer away.  Since I was still living in the USA at the time I left the computer with my brother.  I finally got it back in mid-November 2013.

The computer is a Colex 850 using STD bus cards.  The CPU is a 4 MHz Z80.  Other cards provide 256 kB of banked memory, a hard disk host adaptor connected to a SASI controller running a 40 MB NEC D5146 hard disk and a WD1797 floppy disk controller connected to two 130 mm floppy drives, one with 80 and the other with 40 tracks.

To use the computer I had to hook up a serial terminal.  I was not about to try to purchase one so I chose to connect another computer running terminal emulator software.  Unfortunately none of my modern systems has a serial port so I purchased a dual-port PCMCIA adaptor.  You can see it in poking out from the left of the laptop.
Computer on my workshop bench

Of course that was not the end of the story.  I had to make up some cables to join the DE9 plugs on the adaptor to the DB25 sockets on the Colex and then figure out how to configure a terminal emulator (minicom on linux).  Once I had that working then I was able to see the boot screen.
Booted into CP/M Plus


Then the problems became apparent.
  1. There is some mechanical damage to the computer.  The brackets holding the floppy drives and the hard drive are broken so nothing is firmly anchored.
  2. I found that there was no way to transfer files between Tesseract and the rest of the world. Tesseract has two 130 mm floppy drives but none of my other computers has one.
  3. Tesseract had no usable communications software.  That might seem a bit odd since communications was Tesseract's principal job but there was no obvious way to adapt what was there to a direct connection without a modem, especially in view of problem 4 ...
  4. Writing to the hard drive proved to be impossible.  It could be read but any attempt to create or change a file failed. The only place to put new software is on a floppy!
Fixing the drive mountings appears to be simple enough.  I can probably make replacements in my workshop.  The existing brackets are light aluminium and are quite flimsy.  I would probably make new ones from something a bit more robust.

For the file transfer problem the fallback solution is to use a serial communications line so I made up another cable to join Tesseract's modem port to the second serial port on the PCMCIA adaptor.  Setting up the serial link was straightforward, albeit somewhat tedious.  I used ed to write some small programs to verify that things were working.  The first program, auxmsg, was a trivial thing that sent a message over the serial port to a second minicom session on the linux laptop.  I did not have to fiddle with the serial port drivers because it was possible to attach the serial port to the CP/M Plus auxiliary device using a command such as device auxin: = serial[9600] which meant that I cold use standard BDOS calls to read and write to the serial line.

The second program, echo, was almost as trivial.  It received characters via auxin: and echoed them back over auxout:.  The purpose of that program was to establish that two-way communication was working.

The third program, textin, was a bit fancier.  It received a text file (terminated by a CP/M end-of-text marker) and wrote the file to disk. On a CP/M emulator I was able to convert useful (but small) binary files to Intel hexadecimal text files.  After sending those to Tesseract I converted them back to binary form.  For example, I had WordMaster configured for an ANSI terminal on my CP/M emulator.  I converted wm.com to wm.hex, sent that to Tesseract, converted it back to binary form (hexcom wm) and gave myself a more usable text editor.  Even more useful was the transfer of communications software, rz.com and sz.com. These programs use the CP/M aux: device so again no special hardware fiddling was needed and together they offer much more capable file transfer facilities.

At the time of writing I have not figured out what the hard drive problem is.  I suspect it is bad gencpm but that is really just a guess. For what it is worth, there are multiple versions of some BIOS source files on the drive suggesting that the system has been modified several times since I last saw it.  In the meantime I can read the hard drive so I can copy off anything which might be useful although from what I have seen by browsing the disk that isn't very much.  More interesting is the plethora of stuff on Colex-formatted floppy disks that I can now read and almost certainly there is a good set of BIOS files archived there somewhere.  I should be able to get the system running again.

One might ask "Why bother?  Everything which can be done on the ancient 4 MHz hardware can be done much faster on an emulator running on a modern system."  The answer to this question is twofold:
  1. Nostalgia
  2. The WD1797
Nostalgia demands no further explanation; the WD1797 floppy disk controller is something else.  I have written elsewhere on this subject so this will be brief.  The Western Digital floppy controllers are in some ways more primitive than the ubiquitous NEC µPD765 and its derivatives.  Certainly the NEC chip does a lot more than the WD and may make it easier to write software.  But that is also the problem.  The NEC chip operates at a higher level and takes away some of the low-level control from the programmer. In particular, it removes the ability to do raw full-track reads and writes.  For my purposes those features are of paramount importance and allow me to do format determinations and error corrections which are impossible with the NEC chip.

13 Jan 2014:

I have replaced the two broken metal brackets and in so doing anchored all the internal components so things don't flop around now.  I also added a third floppy drive, an 80-track 90 mm unit which behaves just like the standard 130 mm drive.  Looking at the BIOS source I suspect the problem with the installed operating system is that it does not really match the hardware although that is not absolutely clear because it is not obvious what is actually written to the system tracks.  Furthermore the fact that I can read the hard drive means that the operating system must be almost fully functional.  That makes the inability to write to the drive very perplexing.

I'm waiting for a floppy disk cable to arrive.  I am going to install a 130 mm floppy in my desktop computer.  I should be able to use that to provide a second way of getting software onto the Tesseract computer.

14 Jan 2014:

I got write access to the hard drive!

Andreas Gerlich's BOOTSYS program comes with the YAZE-AG emulator and allows one to test a CP/M Plus build without writing it to the system tracks.  However it needed significant changes to work on real hardware.  I finished the changes yesterday.  Today I was browsing Tesseract's hard disk and found a CPM3.SYS which was probably the most recent one built.  I attached that to BOOTSYS:

pip cpm3.com=bootsys.com,cpm3.sys

That overlays the running CP/M Plus with the one in CPM3.SYS and it just so happens that the hard drive is now writeable.

Of course having write access to the hard disk means there are many new ways to render the system inoperable!

22 Feb 2014:

Now I have a bootable floppy!  That means I can start thinking about fixing the underlying problems with the hard drive while maintaining a mechanism for booting the machine in case of failure.

For what it is worth, the issues with the hard drive seem to be twofold.
  1. The number of sectors per track is 17 but the BIOS has it as 15
  2. Except for the first partition, the number of tracks per disk is wrong.
I played around with various bootstrapping programs and developed two.  The first was a modified version of the BOOTSYS mentioned above but whereas BOOTSYS loads an attached CPM3.SYS the new program BOOTLDR loads a CPMLDR/LDRBIOS combination.  That gave me the chance to test various incarnations of LDRBIOS without writing them to the system tracks.  I didn't have a tool to write ths system tracks anyway.  The PUTCPM3 supplied with the system was specifically for writing to the hard drive and I was not anxious to use that knowing that it was using a different geometry from the BIOS.

The second program was one to write the system tracks of a floppy disk.  Essentially it was a floppy version of PUTCPM3 although I am in the process of making it generic enough to write to any disk, including the hard drive.  It assumes a running CP/M+ and uses BIOS calls to do all the disk I/O.  It was this program which I used to create the bootable floppy by writing the CPMLDR/LDRBIOS which had been tested using BOOTLDR.

Before I do anything else I intend to make two more bootable floppies.  Paranoia is healthy.

I shall eventually post all the bootstrap tools to the Tesseract collection.


[ Home Page | Tesseract software collection | Australian coins ]

Visitors

Created 3rd December 2013
Edited 14th January 2014
Copyright ©2013-2014 Jon Saxton, all rights reserved.