Category: Other Computers

I knew this would be a long haul, because i had no technical documentation and my c was very rusty. Without the user manuals, it would have been impossible.

Teensy++ 2.0

The Teensy+ 2.0 is often used for keyboard projects.  It is about the same size as the microcontroller and has sufficient I/O to cover it.

It has a lot more computing horsepower than the microcontroller, so I don’t have to do a great coding job.

It is compatible with the Arduino IDE.

Reverse engineering

I was doing this in 2019. In Jan 2025 i got access to a working keyboard which confirmed some things and contradicted others. I’ve put updates in [] brackets.

I spent many hours trying to get the basics of the circuits on both the keyboard and the microprocessor board.   I needed pretty much the whole keyboard circuit and some of the microprocessor circuit.

I worked from both sides of the interface. Both boards use 74 series logic, so there were a lot of connections to trace!!

With a 25 pin interface, I was guessing it was parallel. [Yes]

The front panel switches come in through the keyboard.

The keyboard has LEDs, so there was a pretty good chance that the interface was bidirectional. [Yes]

There is also a speaker in the keyboard, maybe for keyboard press feedback or for a bell. [Both yes]

The keyboard has a register for receiving data from the microprocessor board.  There is a write line from the microprocessor board for the register.  The LEDs are not controlled directly by the register.  It is read by the microcontroller.  Perhaps it has an interrupt. {Yes, although i didn’t use it as such]

It has two 4 bit muxes that are used to read from either the front panel switch states or from an 8 bit port on the microprocessor.  There is a read line and a select signal from the microprocessor board for the muxes. [There are a couple of other status lines indicating key down and autorepeat.]

There are two strobes from the uC that are ORed and sent to the uP board.  Both operate the buzzer but one is fixed volume and the other is adjustable with a pot.  If both are asserted, there is no sound.  Some of this I only worked out after I started trying some code. [The two lines are coded for 3 functions.]

On the uP board, the strobe sets a flip-flop which I expect is cleared by an interrupt routine.

The front panel switches work without uC software. 

I have created a rough schematic of the keyboard.

Based on this i made up a plug-in replacement for the microcontroller.

A replacement with a USB port proved to be quite handy for other purposes. I recorded the port assignments etc in the source file for the software.

Keyboard Scanner

This is an unusual keyboard.  Each key has a small ferrite core transformer which is saturated by a magnet when the key is unpressed.  When a key is pressed, the ferrite core can pass a pulse from one side to the other.

The keyboard has 10 stimulation lines and 8 detection lines for a total of 80 keys.  There is a shift key and a special shift key to generate more characters – 240 in principle – or even 320 if both were used.

There seems to be no reason why the scanner can’t happily detect all the keys that are pressed at any time.

Of course, any one time is one complete scan of the keyboard. I was thinking that somewhere between 50 and 100ms would be acceptable.  Nobody is going to do any serious typing on this old machine.  That gives about 1ms per key. [This turned out to be a bad idea. It’s too easy to miss the register writes.  It now checks one key and then checks whether the register has been written.]

Generating characters

I wrote a sketch to enter a byte which would be transmitted once to the uP board. I used a scope to watch what was going on.

Part of this was discovering the timing for the data and the strobe.  I could see the read in response to the strobe which is about 100us after the strobe.

The uP board seems to check the state of the strobe so it’s not just about the leading edge. Keeping it down for too long gives repeat characters.

I went through all 256 values to see what each does.  Some were obvious; others less so.  They certainly aren’t ASCII. The highest bit seemed to indicate shift.

The standard characters were easy to detect, but the function keys were very challenging.  There is a lot of guessing involved.  Trial and error.   It would be impossible without the manual.

[It worked remarkably well, but my timings were out by a mile.]

Scanning the keyboard

Having bit 3 of the scan register asserted prevents the uP card from recognising characters transmitted using the code above. I could not work out why. [This line indicates that a key is down and is fed into the status register.  If the 8085 software doesn’t see it, then it thinks the key is up.]

All the scan lines are driven from one register.  4 to set the stimulation line.  3 to set the sense line.  1 to generate a pulse.  Timings were unknown but i was hoping it could be done in less than a millisecond. [A few microseconds works.  The actual keyboard has the pulse low for about 50us and high for about 12us.]

The secondary pulse was quite short.  About 100ns but the stimulation circuit needs to reload – there’s a capacitor that provides a small reservoir of charge and after that the current falls back to the DC level. 

The pulse is about 500mV peak.  The comparator inputs are set pretty close (about 15mV) so it shouldn’t have taken much to get a logic pulse.  I couldn’t get one.  I couldn’t provoke the comparator to ever go low so concluded that the LM319N was faulty.

A replacement LM319N did the trick.  Keystrokes were recognised easily and within a 1us, I found there were false alarms, so I set it up to scan several times and need multiple hits to recognise a keystroke.

[I realised just recently that there is a uC output, pin 21, that affects the comparator threshold.  It is normally high but goes low when a key is released.  I suspect it provides some hysteresis.  I’m not using it at the moment.]

I messed around with the dwell on each key to make sure I didn’t get multiple characters and I didn’t miss any keystrokes.  I added code to work with shift keys and to auto-repeat.

Once the keystrokes were working, it was easy enough to collect the scan codes for each key.

Mapping Keys

Determining the key mapping without a working keyboard was quite an exercise, and I got remarkably close considering i had no understanding of the underlying protocol. [A working keyboard resolved the last of the protocol and mapping issues.]

And with this i had a working system with a pretty awful looking screen and a new USB interface!

The Lexitron VT1303 came with a Raytheon RDS-345 daisy wheel printer. Although badged as Raytheon, it was manufactured by Qume. The model number is Sprint <TBC>. This is a very large and heavy unit.

The connection is parallel and is made with a very long 50 way cable. The connectors are centronics style, but the 50 pins are more reminiscent of SCSI than a parallel interface which is usually 36.

The printer came with some daisy wheels and printer ribbons.

It was definitely non-functional; the carriage and ribbon belts had both disintegrated.  The platen knob was broken. There was also a lot of corrosion.

I was surprised to find that i could buy the carriage belt fairly easily – i would just need to cut it to length. The ribbon belt, which is very small, required a little crafting. The belt could only be replaced with a comprehensive tear down.

I couldn’t find a service manual for this printer, but i did find one for a similar Qume printer.

Replacing them required a fairly comprehensive tear down.  There was also a lot of corrosion. This meant taking the print head off the rails etc which was going to trash the existing alignment and that realignment is quite tricky – it requires a bespoke alignment jig, for example. I was going to have to wing it.

I gave everything a good clean as i disassembled it and removed all the rust as best i could.

The belt was relatively easy to replace.

The ribbon belt is much smaller and is continuousbut the pitch is the same as the carriage belt. I cut the belt to width and then spliced it. It’s not perfect, but i don’t think it needs to be.

I put it all back together again and tried to work out how the relative position of the print head to the platen was set.

My first attempt to align it was a dismal failure. As it printed, the daisywheel didn’t spin freely and some of the arms went flying in all directions.

My second attempt was much better. This thing is awesome to watch.  It spins the wheel very quickly to tee up the right character and then hits it with a little solenoid operated hammer.

The ribbons had all dried out, but i applied a little wd40 to one, and it was good enough to get some printing happening. I made some additional small adjustments to get characters completely printers – not missing the top or the bottom.

The system looks like it could support CP/M and i think i’d seen mention of it somewhere on the web, but i certainly could not find disk images.

I google “Lexitron” regularly just to see if any new material has been added. In June 2021, i was surprised to find that some disk images had been uploaded to archive.org. That person really did me a huge favour.

https://archive.org/download/lexitron-vt-disks

Amongst the images were some CP/M disks.  Just one problem – they were in Kyroflux format. By 2021 Greaseweazle was certainly available and it did have Kyroflux support. I’m not sure why i didn’t head straight down that path – it’s lost in the annals of time.

In any case, it turned out that an Adelaide Retro Computer Group member, Mick S, had a Kyroflux, and he was kind enough to write all the images to floppy disk for me. 

It was awesome to find that some of the disks worked:

• CP/M system disk with assembler and debugger
• Supercalc
• DBase II

Unfortunately, I had no joy with mbasic or wordstar.  The wordstar disk seemed ok, but the binary just terminated with no message. 

At this point, i discovered that the fidelity of my keyboard fix was not great! If I typed fast enough it worked, but if I stopped then the last key autorepeated forever.  I wasn’t particularly surprised.

This meant re-opening the source code.  I thought perhaps I needed to send a second keycode to indicate that the key had been lifted.  I tried lots of experiments (guesses) but I found that a null (character 0) delivered straight away seemed to resolve the issue. 

Then the second issue appeared.  The control key.  I guessed it was the special shift, but once special shift was hit it stayed down forever and a null didn’t clear it.  I tried a lot of different things – a lot – but eventually I found that if, when the key was lifted I sent the keycode twice ie the same character in place of the null then it was switched off.

Both fixes also worked on the original word processor program.  The special shift key had only worked by a quirk in the original program – the character I sent changed a mode which, as a side-effect, cleared the shift special.  I had never resolved how to clear the “set margin mode” but I found the same trick worked.  It is cleared by sending the set margin code twice.

With these fixes, CP/M was useable – but only with the few disks that worked.  I did find that the copy program could be used to format disks – a vast improvement on the word processing program, which had no such facility.

This gave me the kick i needed to address the screen.

After doing some reading, I thought that if I could transfer a hex file I might be able to transfer some more programs.  Once I had the hex file it could be converted to a binary using load.  Normally the transfer would be done with a serial port – but, alas, the lexitron doesn’t have a serial port.  The only input mechanism that I know of is the keyboard – and that would mean a lot of typing.

But – I have an Arduino keyboard scanner now – so that means that it can do the typing for me and a lot faster.  I arranged the code to read characters from the virtual serial port (over USB) – convert them to the keycodes – and then push them into a file using PIP.  There is no flow control, but I found that 4k could be transferred without triggering an awkward disk write.  That means breaking the files into 4k blocks and then reassembling them. Of course, you have to be mad.

First, you need the binaries.  In many cases, they are available.  In some cases, they are encapsulated in images. They can usually be extracted from images using CPMTools.

The executables need to be 8085 compatible – some CP/M programs (eg turbo pascal, I think) rely on Z80 instructions. 

They also need to be compatible with the lexitron “terminal” – which seems to be compatible with the Lier-Siegler ADM-3A. Some programs have an installer to set the terminal type. 

Once you have a suitable binary (and several may be required) then each has to be converted to 4k hex files, each of which is about 12k in size.  I wanted to do this on a Windows PC, so I used srecord-1.64-win32.

It’s easiest to do this in a batch file, eg this one for the Wordstar overlay:

srec_cat wsovly1.ovr -binary -crop 0x000000 0x001000 -offset  0x00100 -o wsov0.hex -intel -address-length=2 -output_block_size=16

srec_cat wsovly1.ovr -binary -crop 0x001000 0x002000 -offset -0x00F00 -o wsov1.hex -intel -address-length=2 -output_block_size=16

srec_cat wsovly1.ovr -binary -crop 0x002000 0x003000 -offset -0x01F00 -o wsov2.hex -intel -address-length=2 -output_block_size=16

srec_cat wsovly1.ovr -binary -crop 0x003000 0x004000 -offset -0x02F00 -o wsov3.hex -intel -address-length=2 -output_block_size=16

srec_cat wsovly1.ovr -binary -crop 0x004000 0x005000 -offset -0x03F00 -o wsov4.hex -intel -address-length=2 -output_block_size=16

srec_cat wsovly1.ovr -binary -crop 0x005000 0x006000 -offset -0x04F00 -o wsov5.hex -intel -address-length=2 -output_block_size=16

srec_cat wsovly1.ovr -binary -crop 0x006000 0x007000 -offset -0x05F00 -o wsov6.hex -intel -address-length=2 -output_block_size=16

srec_cat wsovly1.ovr -binary -crop 0x007000 0x008000 -offset -0x06F00 -o wsov7.hex -intel -address-length=2 -output_block_size=16

srec_cat wsovly1.ovr -binary -crop 0x008000 0x009000 -offset -0x07F00 -o wsov8.hex -intel -address-length=2 -output_block_size=16

srec_cat wsovly1.ovr -binary -crop 0x009000 0x00A000 -offset -0x08F00 -o wsov9.hex -intel -address-length=2 -output_block_size=16

srec_cat wsovly1.ovr -binary -crop 0x00A000 0x00B000 -offset -0x09F00 -o wsovA.hex -intel -address-length=2 -output_block_size=16

srec_cat wsovly1.ovr -binary -crop 0x00B000 0x00C000 -offset -0x0AF00 -o wsovB.hex -intel -address-length=2 -output_block_size=16

srec_cat wsovly1.ovr -binary -crop 0x00C000 0x00D000 -offset -0x0BF00 -o wsovC.hex -intel -address-length=2 -output_block_size=16

srec_cat wsovly1.ovr -binary -crop 0x00D000 0x00E000 -offset -0x0CF00 -o wsovD.hex -intel -address-length=2 -output_block_size=16

srec_cat wsovly1.ovr -binary -crop 0x00E000 0x00F000 -offset -0x0DF00 -o wsovE.hex -intel -address-length=2 -output_block_size=16

srec_cat wsovly1.ovr -binary -crop 0x00F000 0x010000 -offset -0x0EF00 -o wsovF.hex -intel -address-length=2 -output_block_size=16

Excel is a very handy tool for creating repetitive batch files.

Each hex file holds 4k of the binary but takes 12k of space to do it.  The offset in each file is 0x100 which is as expected by the cp/m load program.

The PC serial port (which is a virtual com port over USB) needs to be setup to talk to the teensy:

mode com3:baud=9600 parity=n data=8 stop=1 xon=on

Regardless of baud rate, the rate at which characters are sent to the 8085 has to be throttled in the teensy. 

At the lexitron setup to receive the file:

pip b:wsov0.hex=con:

At the pc copy the file to the serial port:

copy wsov0.hex com3

Once the transfer ceases, type Special Shift Z to terminate the transfer.

Then convert the hex to a binary

load b:wsov0

This will create b:wsov0.com

Repeat for the other hex files.

Once you have all the required files, they have to be re-assembled:

b:

a:pip wsovly1.ovr=wsov0.com[o],wsov1.com[o], ……… wsov8.com[o]

Do it in stages if the command line gets too big.  The hex files are big so will quickly fill a floppy disk, so delete them once converted to com. 

It’s very easy to make a mistake.  Stay alert!!

Using this technique I was able to transfer wordstar, zork, and some utilities.

I thought it may be possible to avoid all this by using the PIP block mode.  This would rely on the OS to stop accepting characters when they weren’t being used eg during a disk access.  Unfortunately, the OS accepts them and then throws them away.  It appears to be impossible to implement flow control at the keyboard interface, even though it is possible with the serial interface.

I found I could push files to 8k with 32 bytes per record.  I have written batch files to assist. 

It was a very long time (about three years) before I mustered the courage to tackle the CRT. My assessment of the implosion risk is that it is credible, and therefore should be treated with some caution.

I started by making a box to secure the CRT while I did the work. I then removed the CRT from the unit and mounted in the box. This protected it from the rough treatment that it was about to receive, and it would help contain material in the event of a mishap.

I’ve seen several approaches on youtube to cataract remediation.  Some people heat up the tube to quite high temperatures, which just looks too dangerous to me due to the significant possibility of uneven heating causing catastrophic failure. See:

https://www.videokarma.org/archive/index.php/t-184752.html

Others use a hot wire, which seems more reasonable.  I thought about cutting through with a high strength fishing line.

In the end I found the gel was quite soft and could be worked out with some plastic picnic knives.  It took a couple of hours and several broken knives to get it to a point where i could break the suction without risking the glass.

I expect the second layer of glass protected the CRT from user abuse, and perhaps gave some assurance that if the screen suddenly imploded, the user had some protection. I’m not totally convinced that the glass itself provided a lot of protection because it isn’t very thick, but it may be laminated. It does have a nice non-reflective surface though.

I think the gel was probably doing two things. Firstly, it attached the protective low sheen glass cover without any risk of dust between the two layers. I expect it was also part of the protection of the CRT from the user and vice versa. It would have been effective at absorbing energy and reducing the scattering of the front glass. Something akin to an air-bag.

I cannot think of a way to replace the gel, but i can at least replace the antiglare screen.

There is no such protection at the back of the CRT, so once the computer cover is off the risk is probably higher at the back than the front.

The CRT also has an anti-implosion band which was in good condition and i left it as it was.

After cleaning up the glass, I reattached the antiglare screen with double-sided tape.  Once in the machine, the anti-glare screen is against the enclosure. I will be treating the machine with some respect when moving it around.

Before putting the tube back in the machine, i put tape around the gap to seal it from dust.

Before and after: