Author: Graham

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: