6.5 KiB
| title | date | tags | |
|---|---|---|---|
| Repairing a WY-60 Terminal | 2025-04-28 |
|
Intro
While doing my usual craigslist perusal, I stumbled across a listing of a Wyse WY-60 monochrome terminal. I don't have a proper terminal yet, and they're kinda cool, so I figured I would pick one up. I learned that they had more than one, and one of my friends also wanted one, so I left the following afternoon. They had 3 units in total, but one was a bit more battle-scarred than the others. I think the seller just wanted it gone, since he let me take it for free. This would be what is known in the writing industry as "foreshadowing".
The Wyse WY-60 was a popular terminal due to it's comparatively low cost, wide range of "personalities", and plenty of features. It can do 80/132 column, smooth scrolling with scrollback, and a bunch of other stuff I haven't figured out yet.
Keyboard
The units did not come with their keyboards. These terminals used a 4P4C connector with a custom keyboard protocol, so we would need to make an adapter. Fortunately the keyboard protocol is pretty simple, and is documented. Before I bought the terminals, I found this project which has a PS/2 to Wyse keymap. I also found a thread on geekhack which revealed some more working details.
I mostly left this to my friend, who, with ps2pico as the reference, was able to bit-bang the protocol and provide USB host to plug a keyboard in with an OTG cable. There are some keys that don't map, like the function key, or the "setup" key.
Impasse
At this point we needed to test them out. And this is where I realized that, despite picking the unit with the least yellowing, mine didn't work. I saw the cursor, and a line for the status bar, but no characters in sight:
Thankfully, the scuffed one worked, so I was able to confirm that I could interact with it. However, the geometry was bad and there seemed to be some shaking in the text, meaning a power supply wasn't being stable or a capacitor had gone. I had one board with working digital side, and one with a good power/analog side. There's also a maintentance manual at bitsavers so I had a troubleshooting guide and repair manual.
There was a spot in the manual that mentioned what to do if you didn't see characters. Check the font RAM and this custom controller chip.
I (blindly) decided to replace that font RAM, desoldering it and adding a socket. I used the RAM from the damaged unit as a donor. This took a while, as I was still figuring out the best way to disassemble the unit. Testing it was initially challenging as it sits on the screen face as you take it apart.
Eventually, I got it back together. But to my dismay I was still greeted with a blinking cursor and no status line. At this point, I needed to probe the system while it was running to see if any chips were being silent.
I eventually came up with this setup. It's not very safe, but I coped by telling myself that I would only touch the system when it was off. That rule didn't last long. Fortunately the low voltage digital stuff that I care about was close to the table and far from the spooky high voltage near the top of the board.
My next hunch was that something was wrong with the Attribute data pipeline. The attribute data is what determines if a character or line is large, blinking, reverse-color (block), or "blank". I thought that if the pin for "blank" was stuck high, none of the characters would not load properly. The character attributes can either be stored alongside the character itself, or in a separate "Attribute RAM", which is read at the same time.
With my new test setup, I was able to find and probe pins from the underside of the board.
One of the challenges here is that there are multiple busses, each with potentially multiple masters.
Not only do you need to probe a data line, you also need to have a probe for whatever makes the chip
"active", be it a chip select, or an ~OE pin on a logic buffer nearby.
I started from the font ram, then checked U20, which was the custom chip. I kept working backwards, but couldn't find anything that felt wrong.
Things took a quick turn when I noticed this while setting up a probe:
Uh, guys?
It can't possibly be this, right? U17 and U15 are part of character storage, and I did see the font RAM output non-zero, meaning it had to have rendered something! I quickly cleaned up the joints and powered it on. I couldn't see it at first, but it worked. Thankfully I found this before starting to replace other chips.
Takeaway
This highlights the two styles of troubleshooting:
- Hypothesis -> Solution
- Hypothesis -> Validate -> Solution
It feels pretty good to zero-shot a repair or fix, but it also can leave you with blind spots. In my case, I didn't want to try to probe the board while hot, but later it became necessary unless I just started replacing chips indiscriminately. Once I started probing, I wanted to find something that seemed "off" before going further. I would have noticed the character RAM eventually, if I finished my testing of the Attribute RAM. In this case it was easy to spot visually and so I didn't need to test it any further.
While I was working on this, my friend was using his unit to develop the USB keyboard adapter. His unit was slightly more yellow and has some centering issues, but otherwise is fully functional. By the time I had mine figured out, the firmware was mostly complete, so it was a quick flash away. I might blog about it some time, but the protocol is really simple.
I'm typing this last portion in Vim on the terminal, using the VT100 mode.
Next
It's not perfect. I don't know much about ye olde terminal behaviors and finding replacements for modern tools that weren't built with a VT100 compatible in mind is a task of itself. The flow control seems to be DTR-based, which Linux doesn't support natively. We might be able to hack around that with a shim but that's a problem for later. It works fine at 9600 baud using software flow control.
To the folks who rave about the terminals of yore, I get it now.