---
title: Repairing a WY-60 Terminal
date: 2025-04-28
draft: true
---

# 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:

image here

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 we were clearly not done.

image here

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.

image here

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.

Image of functional block diagram, showing the attribute and character data pipelines.

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.

Image of the PCB schematic, showing the complex bus interconnect and 74-series chips.

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:

Image of cold solder joints.

Uh, guys?

Image of more cold joints on a different chip.

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.

# 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 a 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.

( image of editing this post with the terminal )

# 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.

