Category: Other Computers

This is a long technical post. There’s probably only one reason to read it: you have a Lexitron with a broken keyboard. I’m not going to polish it much, but I leave it here just for you!

I spent a lot of time creating a teensy replacement for the microcontroller in the keyboard.  One of the great challenges was to work out the key codes sent from the keyboard to the 8085.  This was very time-consuming and there were some that I never really cracked.

With the arrival of working keyboards, I could just swap out the original for one of the working units. Buuut the teensy solution actually provides a mechanism to move data from a modern PC to the Lexitron and that’s handy.  Also, I guess I’d like to just close the loop!

I can now sniff the communication between the 8085 and the keyboard microcontroller.  Because the keyboard appears to be just another device on the 8085 bus the data is transmitted as a parallel byte.  This would be easy to sniff with a logic analyser, but not so easy with an oscilloscope.  I thought my Analogue Discovery 2 might be sufficient for this task.

Two Different Keyboard Types

One of the VT202 units uses the same Cortron Keyboard as the VT1303.  The other uses a Digitran keyboard which looks quite different but seems to be entirely compatible with the Cortron.  The Digitran sound is not as loud.

Revisit Operation

Keyboard Pinout

Pin	Name	Function
1	+5V
2	+5V
3	GND
4	GND
5	NC
6	GND
7	Strobe_L	This line indicates activity on the keyboard.  It is asserted for 5us when a key is pressed and for 10us when a key is released.   The strobe is not asserted when a front panel switch is changed.  It is not asserted when the shift key is pressed.  It is asserted for spec shift.
8	D5
9	D6
10	GND
11	D7
12	D4
13	Kbd_Read_L	This line causes the keyboard to put data on to the 8085 bus.   The read occurs about 100us after the strobe is asserted. A0 is low.  Scan code?   A second read occurs about 8us after the first.  A0 is high. Switch state?   This strobe is asserted a couple of times every 10ms (approx.)
14	Screen On	This also appears in the status register.
15	A0	This selects the data that is read by the 8085 – either the keycode or the status of the front panel switches.
16	Kbd_Write_L	This strobe is asserted about 5us after Read is asserted in response to the Strobe.   This strobe is asserted every 10ms (approx.)
17	Reset?
18	GND
19	D3
20	D2
21	D1
22	D0
23	-15V
24	-15V
25	+15V
26	+15V

Character Register

Bits 6:0 = Character number

Bit 7 = Shift

Status Register:

Bits 1:0 = Print Spacing

Bit 2 = Pitch

Bit 3 = Screen Spacing

Bit 4 = Not used (input pulled up)

Bit 5 = Key pressed

Bit 6 = Screen On/Off

Bit 7 = Autorepeat (although it doesn’t seem to be used)

Command Register:

Bit 0 = Key click

Bit 1 = Type Through LED

Bit 2 = Select LED

Bit 3 = Continuous Typing LED

Bit 4 = Write LED state (Bits 1, 2 & 3)

Bit 5 = Acknowledge

Bit 6 = Bell (Not supressed by volume control)? Under CP/M this is sent when Select is pressed.  Select causes an alarm chime (not volume controlled). 

Bit 7 = Unknown

Adjustable volume applies to key strokes.  Alarms have a fixed volume.

Word Processing Program Behaviour

Periodic

Once every 10ms or so the program reads the status register and writes the Command Register. 

Keystroke

When a key is hit the keyboard alerts the uP by asserting Strobe_L for 5us.  The program responds by reading the character, reading the status register, and then writing 32 to the Command Register.  This seems to be an acknowledgement. If there is a LED change or sound then that will be sent a few milliseconds later.

The key release is also acknowledged with a command write which can update the LED state and sound a bell but I think does neither.  

The unit only autorepeats on space, backspace, dash, underline, and full stop.  This auto repeat is convoluted.  It involves resending a specific character after the wait time has elapsed.  This triggers the software to autorepeat.  It looks like the bit 6 of the status word is set at the same time.  This is set by an output from the microcontroller (Pin 29).  Although the original keyboard does this it does no appear necessary.

Character	Original Output	Autorepeat Output
Space	80	112
Dash	103	119
Underline	231	247
Full stop	26	122
Backspace	110	126

I can’t see any obvious pattern in these numbers.   They just are.

CP/M Behaviour

Periodic

Once every 10ms or so the program reads the status register. 

Keystroke

When a key is hit the keyboard alerts the uP by asserting Strobe_L for 5us.  The program responds by reading the status register, reading the character, and then writing the Command Register – it can acknowledge, set LEDs, or make a sound.

The key release is also acknowledged but the LED data is not repeated.  There is no periodic write The key release is also acknowledged with a command write which can update the LED state and sound a bell but I think does neither.  

CP/M autorepeats on most keys but not Spec Shift or Sel. It initiates a beep on each auto repeated character.   

CP/M politely ignores the autorepeat shenanigans that the keyboard does for the word processing program.

In CP/M lots of keys are defined as function keys that can be changed using the config program.  The config can also control auto repeat and key click. 

Select is a caps lock key.

My Current Keyboard Code

The current routine that I have for sending a character to the 8085 sets up the character and then takes then asserts the strobe (indirectly) for 1ms.  It then sets up another character (usually zero).

The real thing asserts the strobe for 5 or 10us.  Both the key register and the status register are read within about 100us of the strobe.  The Command Register is then written.  This may be the trigger to clear the key but maybe not.  I previously concluded that the key needed to be nulled but I’m not sure why it does.

My implementation autorepeats on all keys except “mode” keys like Spec Shift and Margin Set.  The actual unit does not autorepeat, although the software does under some circumstances.

I’ve treated Spec Shift and Margin Set as special cases because they are used in combination with other keys.  Certainly, autorepeat doesn’t apply.  CP/M treats Margin Set as a normal function key. 

This means that the effect of these keys is application specific.  Eg in CP/M the Spec Shift key is used to create control keys eg Ctrl-C to do a soft boot.  In the word processing program it has no effect on the letter c.  Spec Shift does not beep.

Shift really is different.  No key code is sent with just the shift key, and the character that is sent is modified if a shift key is pressed.  When shift is pressed the most significant bit is set.  This applies to all keys including Spec Shift and Margin Set.

The various reads and writes change a little with CP/M.  CP/M still reads the front panel switches but I have no idea what it does with the state. Similarly, the LEDs have no apparent function. 

Under CP/M Select behaves like a caps lock.  The shift is done in software.

Observations

Key hit

Close up of subsequent reads and write.

With the autorepeat:

The regular status read (word processor software):

Revised Keyboard Code

The keyboard code has been substantially reworked based on the observations that were possible using the logic analyser function of the Analogue Discovery 2.

• Autorepeat has been removed except to the extent required by the word processing program.
• Each key press and release is transferred to the 8085.
• The timings have been changed to better match the real keyboard.
• Only one key is checked and processed on each pass of the main loop so that commands are less likely to be missed.
• All sounds are generated only at the request of the 8085.  There are no automatically generated sounds.
• An additional signal was discovered that is set when a command is written and is cleared when the command has been read.
• A few missing key codes were found.

Things like Spec Shift, Set Margin, and Select now work as advertised (as far as I can tell).

The code works on the VT1303 and the VT202.  It works with the word processing programs and with both the VT1303 CP/M and the VT202 CP/M.

Mapping

The transmitted codes can be read straight off the data lines (see waveform pics above).

Circuitry

https://www.pjrc.com/store/teensypp.html

The mapping from the microcontroller to the teensy are shown in this table:

uC Pin Nr	uC Pin Name	Teensy Pin Nr	Signal Name	Comment
1	T0
2	XTAL1
3	XTAL2
4	RESET_L
5	SS
6	INT_L	D4	uC_New_Command
7	EA
8	RD_L
9	PSEN_L
10	WR_L
11	ALE
12	DB0	C0	DB0	Data bus for the keyboard.
13	DB1	C1	DB1
14	DB2	C2	DB2
15	DB3	C3	DB3
16	DB4	C4	DB4
17	DB5	C5	DB5
18	DB6	C6	DB6
19	DB7	C7	DB7
20	VSS	GND
21	P20	F6	LED_TypeThru
22	P21	F5	LED_Unused
23	P22	F4	LED_Select
24	P23
25	PROG
26	VDD
27	P10	B0	Column0	Keyboard Column
28	P11	B1	Column1
29	P12	B2	Column2	Also drives a status register input to indicate that the current key has been pressed.
30	P13	B3	Column3	Also indicates when an autorepeat could be started.
31	P14	B4	Row0	Keyboard Row
32	P15	B5	Row1
33	P16	B6	Row2
34	P17	B7	Pulser	This creates an opportunity for a pulse at E7
35	P24	F3	LED_ContType
36	P25	D3	uC_Rd_L	Enables command register so it can be read via Port C.
37	P26	D2	uC_GotOne_Loud_L	Loud Beep for Alarms
38	P27	D1	uC_GotOne_Adj_L	Adjustable beep for key presses
39	T1	E7	uC_Sense	Senses when a key is down
40	VCC	+5V

I have a couple of working Lexitron word processors that run the CP/M operating system. They use an unusual disk format for which i have no means of decoding or encoding. The only input that these machines have is the keyboard which is a somewhat tedious means of transferring programs and data. This has limited the applications that i have been able to transfer to these machines.

Documentation and the CP/M implementation both suggested that Lexitron produced a communications card that could do asynchronous serial communication but i had never seen one. Recently i did a search on ebay, and discovered a card that was likely to be the unicorn communication card so i snapped it up. It arrived from the UK within a couple of weeks.

It has a 8251 programmable communication interface (PCI), an 8253 programmable interval timer (PIT), a 8255A programmable peripheral interface (PPI), and an MM5307 baud rate generator (BRG). It has a lot of RS232 drivers/receivers so i suspect that a bunch of parallel port lines use them.

I couldn’t be sure that this was the right card for either the VT1303 or the VT202 but i crossed my fingers and took the lid off the VT202.

Looking at the relationship between the PCI and the drivers/receivers, the pinout on the DIP connector was consistent with the usual RS232 pinout. The connector allows for external transmit and receive clocks, but there is some logic which allows the PCI to also use the clock from the onboard baud rate generator.

The card seemed to be in good condition. I checked for shorts on the power rails but found none. The spare slots in the card frame a little different to the slots that are home to the other cards, but the affected pins were not in use by the communications card.

Unfortunately the card developed a short on power up, resulting in the -15V fuse blowing. After replacing the offending tantalum capacitor and the fuse, the system started up ok with the board present.

I ran the configuration program on the CP/M disk to set port to 9600, no parity, one stop bit, 8 data bits. I also set up pun: and rdr: to use the serial port. I tried to get it to transmit data using:

pip pun:=rdr:

Alas, there was nothing so i started checking things out – which is a little laborious without an extender or a schematic. I did confirm that the card accessed both the PCI and the PPI, which i took as a sign that it was the correct card.

The PCI transmit/receive clock was missing and this was because the BRG was not oscillating. Everything around it looks ok:

• Power lines
• Crystal connected
• Parallel control inputs from PPI changing as they should
• Capacitors values are plausible

Currently, i’m concluding that the IC is dead which is a shame because it’s not easy to get.

In the interests of progress i pulled the IC and provided my own clock from a lab waveform generator. Frequency= 9600 x16 = 153.6kHz.

Lo and behold, there was communication:

Although the BRG is disappointing the overall result is very good. I can either knock together an emulator or try to source a replacement.

Before charging in, i decided to see if it was just the oscillator that was at fault. It would make life easier if the divider was still a going concern. I configured it for an external oscillator – again provided by a waveform generator. This seemed to work ok. It is possible that the oscillator fault is due to the crystal and the IC is actually fine.

Given some uncertainty about the crystal characteristics, testing that hypothesis seemed more trouble than putting together a replacement oscillator. There are plenty of spare footprints on the board.

Oscillator modules at 2x 921.6kHz = 1.8432MHz so i settled on that frequency. A flip-flop will divide by 2.

I built up the mod above and reconfigured the baud rate generator to use an external oscillator. It worked fine. The oscillator and divider are in the bottom left hand corner.

Unfortunately, i have found that the xon/xoff does not seem to work with data being sent to the lexitron. The configuration program does call the setting “output flow control” so i guess i should have been forewarned!

This means that i will either need to write a transfer program or adapt kermit to this machine – or i suppose i could attempt to write my own driver. I think the best course of action is to adapt kermit. I’ve never done that before and if i learn i might be able to make a version for the Osborne Executive as well.

The operating system seems capable of setting up the communication parameters so i would just need to correctly set the address of UART on an 8251 version of kermit.

The first thing i need is the base address of the UART. I wrote a little basic program to read all the I/O locations and sent a character to the UART from a PC with the hope that it would appear in the data register of the UART. Sure enough it did “t”=116. It is at 48H and again at 4AH.

Actually, i may be able to use the generic version of kermit. In doing a bit more reading i see that there is a generic version that uses operating system calls. This version relies on the the CP/M IOBYTE being used by the Lexitron OS version. There is a speed penalty from using the generic version but i could live with that for now.

A handy place to start is here:

http://www.z80.eu/kermit.html

Kermit80 is distributed as a common part (CPSKER.HEX) and a customised part. The generic part for CP/M 2.2 is CPVGEN.HEX.

The initial transfers to the target machine are a little tricky because i needed to rely on the tools that were already present on the machine. In this case i have a serial port that can be accessed with PIP.

In principle, it should be possible to transfer hex files fairly safely using PIP as long as the OS supports XON/XOFF flow control. I’ve already discovered that this support is limited. That means that there is a risk that the computer will not keep up with the data. I experimented and found that it was quite reliable at 2400 baud unless the machine got distracted by some other I/O eg a disk write.

I had previously found that PIP has quite a good buffer and that 4k of data translated to hex (ie about 12k of text) does not trigger a disk write during the transfer.

CPSKER.HEX weighs in at about 70kB. I divided it up into 6 files and transmitted each one using kermit on a PC and PIP on the Lexitron.

Because the disks don’t hold a lot of data and the hex files are inefficient, there is some disk juggling to be done. I find it convenient to create working disks with a boot track and PIP, STAT, and LOAD. Two of these gives sufficient working space.

At the Lexitron i configured the serial card to use 8 bits, no parity, and 2400 baud and received with PIP via the RDR: device:

B> a:pip kerm0.hex=rdr:

At the PC:

Kermit> set port com4
Kermit> set baud 2400
Kermit> transmit cpsker.hex

Once the transfer is complete it is necessary to connect to the Lexitron as a terminal and send an end of file character, Ctrl-z.

I repeated this for kerm[1..5] and also for the custom file CPVGEN.HEX.

Then the files can be concatenated locally with PIP:

B> a:pip kerm411.hex=kerm0.hex,kerm1.hex,kerm2.hex,kerm3.hex,kerm4.hex,kerm5.hex

At this point the files are ready to be converted to an executable. The standard LOAD program can only do one file at a time. The kermit411 distribution includes a more advanced load, MLOAD, as a small hex file. I transferred it in the same way as above and then converted it to an executable:

B> load mload

And then created the kermit executable:

B:> mload kerm411,cpsker
B:> kerm411

Kermit on the Lexitron requires some setup:

Kermit> set port tty
Kermit> set file binary

Note that the baud rate is already set by the OS config program.

Then any file can be transferred using send and receive. I sent pacman95.com as a test. The terminal characteristics aren’t quite right, but it got there.

It does not sound like much, but this is a very important step forward for the Lexitron ecosystem. I should now be able to transfer a bunch of generic CP/M programs and data.

Using the terminal mode in kermit on the Lexitron is a little complicated by the unusual keyboard. I could connect using “connect” but i could not find the exit key. Shift-Menu does provide a menu though, and this does have a command to exit. More experimenting required.

At the PC end, timeouts occur during disk writes. The length can be increased to, say 10s, at the PC end with:

Kermit> set transmit timeout 10

The error limit can also be increased at the PC end:

Kermit> set retry limit 100

Having got Kermit running on the Lexitron CP/M my attention could turn to adding some more applications. The Lexitron does have the limitation that it uses an 8085 microprocessor and that rules out any apps that assume a Z80. This seems, for example, to include Turbo Pascal. The Lexitron also uses 35 track single sided drives; the space available is only 140kB which is tight.

BDS-C was written for the 8080 and doesn’t require a lot of disk space. The author’s website provides the software, sources, and various other files for the last version, 1.6. It also has a video where he talks about the history of the compiler and more:

https://www.bdsoft.com/resources/bdsc.html

i was able to transfer the files to Lexitron floppy disks by means of kermit. Once i had set up a disk with just the essential items it was good to go.

I started to punch in hello world and then realised that there were no braces {} on the keyboard. I eventually worked out that the ascii codes correspond to some unusual characters that the Lexitron uses so i just used them in place of the braces.

{ = §

} = †