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
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
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.
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.
Then the problems became apparent.
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.
- 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.
- 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.
- 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 ...
- 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!
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
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:
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.
- The WD1797
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
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:
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.
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 number of sectors per track is 17 but the BIOS has it as 15
- Except for the first partition, the number of tracks per disk is wrong.
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
Created 3rd December 2013
Edited 14th January 2014
Copyright ©2013-2014 Jon Saxton, all rights reserved.