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=16Excel 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=onRegardless 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 com3Once the transfer ceases, type Special Shift Z to terminate the transfer.
Then convert the hex to a binary
load b:wsov0This 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.