One suggestion stood out – not only because of it’s simplicity but because I have used it many times myself over the years. This procedure requires a very special tool, one that is nearly obsolete in this day and age. I wasn’t sure I had such a rare device.
I did find one, eventually, in the back of a drawer
The mighty pencil eraser, handily attached to it’s applicator wand.
A few quick pokes on the offending contacts, and the resistance dropped to below 1k in most cases. In an hour so, all of the key switches had been reassembled and resoldered.
I did look at the contacts under the microscope but didn’t see anything significant. Perhaps the gold looked a little brighter, but that’s hard to tell on an $80 microscope with 1080p screen that is three inches across 🙂
We’ll see how long the fix lasts, but for now, I am declaring victory.
A pair of vintage TRS-80 computers recently arrived in my office, thanks to a good friend in the US who has been storing them for me and a generous checked baggage allowance on my recent business trip.
Getting one of them working involved learning more about vintage Alps key switches than I expected.
With replacement of the RIFA caps in the power supply, and removal of a jumper, the Model 4 is running natively on 240V. All keys switches are present and working, but there was case damage during transit. I’ll be repairing that later.
The Model 3 is in good physical condition, except for two missing key caps with matching broken key stems, but needed a memory transplant to get to the Cass? prompt. It also got replacement RIFA caps but it’s older power supplies means it will always need a step-down transformer to run on Australian voltages.
Then I discovered that half the keyboard wasn’t working…
After some thought, I decided to find the difference between working keys and not-working keys. This meant measuring the resistance of the keyswitches and comparing them.
Trying to measure the resistance with a multi-meter while balancing the keyboard on it’s edge was an exercise in frustration. And I wasn’t going to solder flying leads everywhere. If only there was a way to somehow connect all the keyswitches in parallel and measure them one at a time….of course!
The Model 3 keyboard connector has all of the keyswitch rows on the last 8 pins (2 rows of 4) and the columns on the next 8 pins (2 rows of 4) . By joining all of the rows together, and all of the columns together, every keyswitch is connected in parallel. Connect the two leads to a multi-meter – bingo! Press any key and get the resistance.
It was immediately apparent that reliably working keyswitches have a resistance of less than 2.5k. Anything up to 10k might work. Anything higher, nope. Non-working keyswitches were sometimes as high as 800k
So what was causing the difference in resistance? Time to pull some hardware and see.
I pulled a dozen high resistance keyswitches and disassembled them to see how they worked.
Each Alps keyswitch has a small conductive plate inside the grey rubber plunger that is pushed onto a pair of gold contacts deep inside the body of the switch. This makes the circuit, and the combination of the spring and rubber provide the key tension.
I industriously swabbed the conductive plate and the inside contactors of each key switch with isopropyl alcohol. A quick resistance test of the first few switches revealed they were now well under the 2.5k limit, so I went ahead and did the rest.
I was tempted to solder them straight back into the keyboard plate. I’d done a random sample and all was good right?
Wrong. About half of the keyswitches were still high resistance. An additional cleaning pass didn’t really do much to help.
So what was going on? Time to dig deeper.
Eventually, I decided to compare a low resistance and high resistance keyswitch under a microscope. The conductor plates showed no difference, but the gold contacts were a different matter.
This is a good switch. There is a lot of gold still on the contacts.
This is a bad switch. The right contact is obviously missing most of the gold.
Well, that explains the high resistance.
So, I’ll need to measure the resistance of every keyswitch as I clean, and/or do a microscopic examination. And when I’m finished, I’ll need to get new keyswitches to replace those that don’t work.
Or maybe I’ll take up Ian Mavric’s offer of a replacement keyboard.
The FPGA TRS-80 project continues. I have the Z80 core, Model 1 ROM, and 16k of RAM connected. I need to rework the video address generation as there are timing issues. Below is a capture of the Z80 booting from ROM. Try and find the first few instructions as the CPU disables interrupts and performs a jump instruction.
I was asked on the TRS-80 Model 1-4 Facebook group about using the internal FPGA memory for ROM emulation. This is a good question.
Splitting the CPU main memory between internal and external access requires a multiplexer on the address and data busses. Not a big deal, but it’s simpler to allocate all of the CPU main memory from one pool. But this is not sufficient reason – if the TRS-80 ROMs were allocated from internal memory, then no external ROM hardware would be needed.
Lets do the math: there is 72k of block memory on Spartan 6 SLX16. Take away 32k for hi res video, 8k for various character generators, and 2k for video character (80×24) leaves 30k.
A Model 1 Level 2 image is 12k, a Model 3 ROM is 14k, model 4 is 8K – we’ve just run out of block RAM.
So, we would be limited to one TRS-80 model per FPGA load. Adding a $1 SPI ROM seems like a good investment to avoid the problem.
The internal memory on an FPGA very fast, dual ported, and quite small. An FPGA that retails for around $30 has about 70kB of block RAM. Retro computer emulations use the internal memory for features that need the performance or can benefit from dual porting, such as full speed access to the video memory with no access flicker.
The main memory of the retro CPU is implemented with external RAM. This external memory is usually high density dynamic memory of 32MB or more in a single chip. It’s a direct descendant of the 4116 and 4164 dynamic RAM chips of the 70’s and 80’s and is very similar to the DDR RAM in a modern PC. Most FPGA development boards come with 32MB or more of external RAM.
Just like the 41xx RAM chips, these memories require periodic refreshing that is synchronized to the accesses for data. This is implemented using FPGA logic, and complicates the design. But the ability to have megabytes of cheap RAM usually makes it worthwhile. Another downside is that the board layout becomes critical because these parts run at high speeds in 20MHz plus range. Consistent trace lengths, special decoupling etc etc.
After a lot of thought, I’ve decided to use a different approach.
I’m going to use 3.3V static RAMs to avoid the refresh and high speed hassles of the DRAMs. I don’t need megabytes of RAM – 256k would be fine. Also, I can’t use the 5V versions because FPGA pins are all 3.3V and level converters triples the parts count.
The 3.3V parts are SMD only, but not ridiculously so.
A surface mount RAM chip
I also need some ROM storage. Using a 3.3V parallel flash ROM just like the RAM is possible, but that adds another big SMD part.
Instead, I’m going to use one or more SPI flash ROMs and have the FPGA copy the appropriate data into RAM when it boots (just like the Model 3 does when using “ROM” BASIC). The SPI ROMs are tiny and cheap and have only 8 pins.
Next step is to do a simple PCB with these parts. There are a few places that will do them at $10 for 10 boards, as long as they are 100mm x 100mm.
Now that the replica of the first computer I ever owned and built is finished (see my 2650 replica), it is time to move on to the first computer I ever used – the TRS-80 Model 1. I spent most of the school Christmas holidays of 1977 in my local Tandy store becoming an expert on this device. Computers have been my career and hobby ever since.
I never actually owned a Model 1 until a few years ago when I acquired two fully operating systems, one with an expansion interface and drives. I’d like a Model 3 and a Model 4, but they are getting hard to find on eBay, and expensive, Besides, I don’t have the room for them all!
There are software emulators for these machines, but that doesn’t fulfill the inner hardware nerd. I want to build something.
There are other TRS-80 replica projects. This guy is building a replica of the Model 1 as close as possible to the original using discrete logic. I like that idea – I recently built the excellent PC-Retro from MTM Scientific. I also found this project with but it has not been updated since 2015.
I’ve decided to build a TRS-80 replica using an FPGA to implement the Z80 core, video generator and most of the I/O and emulation logic, with an Arduino to handle the SD-Card and associated FAT file system. Here is what it will look like:
The intention is to emulate the Model 1, 3 and 4. On-screen menus will be used to select various options. VGA and composite output will be included, and probably HDMI as well. A standard PC keyboard can be used, or a memory-mapped TRS-80 keyboard can be attached. Floppy disks will be emulated by the Arduino, and I’l include a socket for 17xx/27xx controller chip as well.
I’ve got the basic video timing working with a Xilinx Spartan 3 FPGA (see below) and the next step is include the Z80 core and a ROM image. Eagle eyed readers will see slight artifacts on the bottom of the second row of graphics characters – they will be fixed!
I’m open to suggestions and comments. Please email to email@example.com or the various Facebook groups dedicated to the TRS-80 and DIY Z-80
The problem with PIPBUG has been found, and the problem was nothing to do with PIPBUG!
The first 18up5 board that I built has always worked without issues, but the second “pretty” board did not. It took an embarrassingly long time to notice that the second board was missing the interrupt jumpers JP2 and JP3, and that these were also missing from the instructions.
Once these were installed, everything workied again!
If you are having problems with the G command not working, then make sure you have these jumpers installed. These prevent the CPU from getting an immediate (and unhandled) interrupt whenever a user program is executed.