139 lines
6.5 KiB
Markdown
139 lines
6.5 KiB
Markdown
---
|
|
title: Repairing a WY-60 Terminal
|
|
date: 2025-04-28
|
|
tags:
|
|
- retro
|
|
---
|
|
|
|
# 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](https://github.com/bryanc806/WyseBoard/blob/master/WyseBoard.ino)
|
|
which has a PS/2 to Wyse keymap. I also found a thread on
|
|
[geekhack](https://geekhack.org/index.php?topic=51079.0) which revealed
|
|
some more working details.
|
|
|
|
I mostly left this to my friend, who, with [ps2pico](https://github.com/No0ne/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:
|
|
|
|
1. Hypothesis -> Solution
|
|
2. 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.
|