TRS-80 Model 1 Keyboard Repair

If you have been involved with retrocomputers for any time, the chances are very high that a machine that worked perfectly when last used has now developed a new fault (or two or more.....).
This happened to me recently with a TRS-80 Model 1.  In the time I have had the machine it has been very reliable.  I pulled it out of storage after 6 months to do some testing with the Model 1 FreHD Interface and found that the Shift Keys had stopped working.  
Failure of individual keys is a pretty normal occurance on machines this age.  Failure of a single Shift key wouldn't be a big problem because there are two Shift keys.... but in this case neither worked.
The TRS-80 Model 1 keyboard is memory mapped.  The ROM polls a set of memory addresses in the block 0x3801 - 0x3880.  When keys are pressed this pulls up the matching bit on the data bus.  Most addresses link to 8 different keys except for 0x3880 which on the Model 1 is used only for the two parellel wired Shift keys.
The only component that would affect 0x3880 and the Shift keys but no other keys on the keyboard is Z2 (74LS05).

After Z2 was replaced the keyboard was fully operational.


SD-Systems SBC-200 Testing - Part 2

In the earlier post I wrote about testing an SD-Systems SBC-200 single board computer for the S-100 bus using my Northstar Horizon mainframe.

The end result of that testing was that the board seemed to work correctly but Philip had been unable to get it to operate in his S100 Bus motherboard.  

It happened that I had an unbuilt PCB for the same motherboard in my projects box... this was the kick I needed to get it assembled so see what was going on.  

Philip was kind enough to include a partial parts kit when he shipped up the SBC-200.  While most of the components were easily available from Jaycar or RS Components, the 270 ohm 9 resistor SIP resistor packs were proving difficult to locate and these were in the partial kit.  Thanks Philip.

My motherboard is labelled Revision 02 and differs slightly from Philip's in having an extra two slots and some rearrangement of the onboard components but is essentially the same design.  There were a couple of gotcha's documented on the web... the silk screen for Q1 is reversed and the fuse links are only fuses for the power status LED's (interesting) so can be replaced with links.

The motherboard undergoing smoke testing with my home built variable supply while waiting for the switching power supply modules to arrive.

Powering an S100 motherboard requires DC supplies of +8v, +16v and -16v.  The current thinking when using switching supplies is to run +7.5v, +15v and -15v if possible to have less heat dissipation in the onboard regulators.  Aliexpress came to the rescue with adjustable switching supply modules providing the right voltages at reasonable prices including shipping to New Zealand.  


S100 motherboard with switching supplies and SBC-200 installed.


S100 motherboard with switching supplies and SBC-200 installed.

With the motherboard assembled, the power supplies connected and the "known good" SBC-200 installed, I was surprised to find that the board didn't start properly.

Testing with a logic probe and a meter showed that the /RESET line did not go below 1.7v when the reset button was pressed which caused the SBC-200 to not reset correctly.  A clean /RESET is critical to the start address hardware on the SBC-200.  

The schematic showed R18, a 470 ohm resistor between the RESET button the GND.  I assume this was on the board to prevent a direct short to GND in the event that the other side of the reset button was tied directly to VCC rather than via a pullup resistor. The SBC-200 had a pullup resistor so the effect of R18 was to prevent /RESET going below 1.7V when the button was pressed.

Replacing R18 with a jumper solved the problem and a good reset was had with /RESET going to GND and the SBC-200 starting properly. The same solution worked for Philip's Revision 01 board.


SD-Systems SBC-200 Testing - Part 1

One of the challenges with retro-computing is knowing which of the many new/untested components you are trying is causing the headache.

My friend Philip was having just this problem with his SD-Systems SBC-200. 

The SBC-200 is a Z-80 based single board computer for the S-100 bus as is described on

Philip had spent a couple of months trying to get either of his two SBC-200s to show any sign of life and was starting to pull his hair out when he emailed wondering if I was willing to have a look.  In addition to 30 year old board, an extra variable was new build S-100 bus motherboard that Philip was using.  This is a DIY board from the family so there was a risk of the problem being there rather than the SBC-200. 

Having a known working S-100 test machine (The Northstar Horizon) and an unbuilt PCB for the S-100 bus motherboard put me in a good position to remove some of the unknowns so I agreed.  Always one for an interesting retro project also. 

Before Phillip shipped me the board we tried running a boot EPROM that, if my code was right would send a continuous stream of ‘A’ characters to the serial port.  The same technique worked well when initially testing the Northstar.  Unfortunately we got no output on the serial port so the boards duly arrived.  Philip also commented about the problems he was having getting the board to reset using the motherboard reset button and had to use creative techniques like grounding the Z80 /RESET pin with a piece of wire.  Interesting!

The documentation for the SBC-200 suggests these were often assembled from kits and inspection of the boards confirmed this as there were some differences in the construction technique, particularly the default configuration jumpers.  I was a bit surprised when I first looked at the boards that there were no jumpers at all for most options yet the manual has pages of configuration options listed.  It turns out that the jumpers are printed as PCB traces which must be physically cut if a different configuration is required.  One of the two boards had the default configuration traces in place, the other had most cut and headers installed on the board.  I can only assume the constructor wanted to try different configurations.

The default configuration of an SBC-200 has a 2716 EPROM at 0xE000, 1K of static RAM at 0xF800 and a start on power up address of 0xE000.  The documentation also suggested that the SD-Systems monitor expected to reside at 0xE000 so this looked like a configuration to go with. 

Based on all this I picked the “uncut” board to test first.  It also happened to have the test ROM so my guess it was the last board Philip tested.

I cross checked all configuration traces against the manual to confirm the configuration.  I didn’t see any configuration issue with this board… Philip had that bit right.

With the board installed in the Northstar I tested the reset circuit with a logic analyser.  The board uses a 74LS74 flip-flop to control the pull up of the A15-A12 address lines based on the power on address configuration.  This circuit relies on a clean reset from the S100 bus to reset the flip-flop and pullup the address lines.  The boot code is later expected to read IO port 0x7F to clear the flipflop and disable the address line pullup.

For any start address other than 0x0000 this is a critical circuit.  

In the Northstar it worked perfectly and I could see A15, A14 and A13 high after reset. 

The next step was to run the board with the Tauntek  Z-80 In-Circuit Emulator and test the memory and IO port decoding. 

The Tauntek is a fabulous board for debugging Z80 based hardware.  After power up I could display the test code at 0xE000 which confirmed that the ROM was correctly addressed and reads would return the correct data.

OK ===> D E000

E000   D3 7C 18 FC 00 00 00 00-00 00 00 00 00 00 00 00    ................

E010   00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00    ................

E020   00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00    ................

Disassembled this is as follows which was correct for our test ROM (that did nothing but write to a port in a continuous loop)..

OK ===> L E000
E000 D3 7C          OUT (7C),A

E002 18 FC          JR E000

E004 00             NOP

Running the code starting at 0xE000 and breaking showed the CPU cycling between 0xE000 and 0xE002 which is correct.

One thing I missed in the documentation when writing the test code was the requirement to read port 0x7F to clear the 74LS74 flipflop and release A15, A14 and A13.  For ROM code at 0xE000 this should be coded as follows to set the Program Counter and then clear the address line pullup.

JP E0003

IN  A,(7F)

Reading 0x0000 without doing this means you are always accessing memory with these address bits high so it reads the EPROM.  This is correct behavior and the board worked as expected.

OK ===> I 7F

 ---> FC

Reading port 0x7F correctly resets the 74LS74 circuit after which reading 0x0000 returns 0xFF which is correct for a Z80 with nothing at that address.  The board worked as expected.

A quick memory test of the onboard RAM from 0xF800 to 0xFBFF reported no errors confirming that the onboard 1K static RAM was operational and was correctly addressed.

OK ===> MT F800,FBFF

Seeing it was all going so well I installed a Northstar 32K Dynamic RAM card configured for 0x0000 and ran a memory test on the first 0xFF bytes which also passed... so the buffering to the S-100 bus is also working.

So far things looked good so it was time to check out the serial port.  The manual and a multimeter confirmed that the serial port edge connector required the following minimum set of connections to a DB9:

J2 Pin 3 -> DB9 Pin 3

J2 Pin 5 -> DB9 Pin 2

J2 Pin 13 -> DB9 Pin 5

Installed the ‘Send A’ test ROM after updating it to IN 0x7F on start and configured for 9600,N,8,1 the terminal started filling with a stream of  ‘A’ characters.  The SD Systems Monitor also worked.

This was a good board… it seemed Philip’s problems were elsewhere….


Living Computer Museum - VAX 11/780


Page 2 of 30

Powered by Easytagcloud v2.1

Contact Andrew Quinn