Leaded Solder

SyncMaster of the Universe

2026-05-05T00:00:00+00:00

When I was visiting my buddy, he pointed out that he had a 24” LCD monitor in the garage that he was throwing out. Sometimes it wouldn’t turn on, he explained. I don’t remember what he said after that, but the monitor ended up in the back of my crappy van full of cool junk, and now it’s here. Ready to be used for… monitoring?

This here is a Samsung SyncMaster 245B. It’s a surprisingly chunky LCD from the halcyon year of 2007. It sports a 1920x1200 pixel panel, and it is not working. The blue light on the power button will blink, but nothing happens when you try to turn it on.

After hauling it home in the aforementioned cool junk van, I decided I would take a look at my new monitor… someday. And after tripping over it multiple times in a row, that day became “today.” Looking at the internet, the commonly reported problem is that the 68Ω resistors on the power board get baked to death, go super high resistance, and then kill the monitor. On top of that, you have the usual Samsung issues with cheap electrolytic capacitors and general disdain for the concept of thermal management.

Taking apart the monitor was not as easy as I would have liked. I unscrewed the stand (more on this later) and then worked around the periphery of the monitor using a series of spudgers, starting at this convenient arrow.

It was slow going, until a majority of the plastic clips freed up with sickening crack-pop sounds. Thankfully, the case plastic is quite thick, and it didn’t explode into a million pieces from my thuggish prying.

To remove the power supply, you have to pull the four screws out, and then pull up this padded section here. It reveals a hole that you can slide the power plug and switch bezel out through, and then you can work all the super-tight connectors off the power supply board.

It tickles me a little bit that they have an elaborate black rubber cover over the transformer and other switching components, but the big primary side capacitor’s solder joints are just left out in the elements for you to bump into, while you try to unscrew it and wiggle it out of the case.

I decided to first tackle the problem resistors. These 1W resistors are supposed to read 68Ω, but once I split them out of the bundle of silastic goop holding them, there was evidence of blue-green corrosion on the legs. I only measured one of the resistors as it was removed, and it revealed itself to be 95Ω out of circuit. That’s a little more than it should be.

Annoyingly, the legs are folded over onto the pads to hold them in place. It’s a little hard to remove them using a desoldering gun, and I ended up pulling one pad while wiggling a little bit too hard to make one resistor loosen up. Luckily, the pad it connected to was right next door.

My first order of resistors were 5W power resistors, but they were way too big to mount into the board safely. I went back and reordered some much less ridiculous Vishay axial 2W resistors, figuring that the extra wattage would translate to a longer life, at least until the ultra-cheap caps blew and killed the monitor again in the future.

Speaking of ultra-cheap caps, I noticed this 105°C, 470µF/35V cap right next to a super-hot switching transistor. It looked like the shrink wrap around it had deformed and pulled back from the top. I pulled it out of circuit and checked the ESR. Marginal failure, but still a failure. Unfortunately, I didn’t have a 470µF cap in that voltage rating on hand. I had a Digi-Key cart going, and so I stuck a handful of Rubycon 10,000-hour replacements in there.

Reassembling the monitor was pretty easy, as long as I remembered to slot the boards into their little bent-metal trays before I tried to do the screws up.

With some hesitation, I went to power the monitor up. On the first try, it flickered the “analogue” video mode indicator up for a few frames and then went dark again. After restarting the monitor, the indicator came on and stayed on.

The monitor flipped between analogue and digital inputs for awhile, searching for a signal, and then dropped to a bouncing “please connect cable” screen.

Excellent. The monitor was alive, although something was emitting a nasty (if faint) buzzing noise, likely one of the caps I didn’t bother touching. I let the monitor run for awhile like that, waiting for an abrupt failure or little cough of smoke, but found nothing.

Since it was the closest, I decided to use the PC-9801RA2 to test the monitor. I hooked up the GBS-Control upscaler to the display, and fired up the computer. After some video mode tweaking, I had a legible N88-BASIC(86) display.

I wrote a quick (to write; very slow to run) program in BASIC to test for colour in the graphics plane:

CLS
FOR Y = 0 TO 200
FOR X = 0 TO 640
PSET(X, Y), Y MOD 8
NEXT X
NEXT Y

And as I waited (and waited,) the screen filled up with some glorious interlaced colour. I’m sure there’s a faster way to fill the screen with a test pattern, but I don’t know it.

I’d call this fixed, or at least fixed well enough to be usable until the next crappy cap implodes.

Tate Mode Unlock

Why bother saving this monitor at all? Well, besides the obvious platitudes about rescuing perfectly good equipment and diverting it from the international e-waste industry, this monitor can rotate to a portrait mode.

This, in theory, is useful to me as a consumer of supergun-related products. A lot of arcade games use a portrait-style display, which is referred to in the community as TATE MODE.

None of my other monitors can do this trick, and so it seemed like a good idea to take this one home and nurse it back to health just in case this one would save my butt one day trying to play a shooter.

Unfortunately, there are two problems with this monitor’s rotate mode:

It only rotates one direction: clockwise. Although it’s the most common, not all tate-mode games use a clockwise monitor rotation: for instance, Galaxian is inconveniently a counter-clockwise rotation on the PlayStation Namco Museum anthology. Luckily, most emulators can display either way, and I don’t anticipate using this monitor with real arcade boards.
It doesn’t actually rotate. When I tried to turn the monitor, it just bumped up against something in the mechanism and wouldn’t move.

Once I got the stand off as part of the repair, I suddenly realized why it wouldn’t rotate. Samsung put this giant bearing in here, and then locked out the rotation mechanism with a screw. I can sort of understand why they’d want to do this, in order to make it easier to carry and set up, but other manufacturers manage to do that with a little button you can push to unlock the rotation.

Luckily, removing the screw was pretty straightforward once I figured it out, but why isn’t this on the outside of the stand?

I assume the use case here is “set the monitor up as either horizontal or vertical orientation,” not “let them decide.” But allowing it to pivot like on the Dell monitors would have been a cool move, Samsung.

Unfortunately, I was about to have a bigger problem with this monitor.

Sitting and Hurting

I popped the LCD onto a shelf in my basement and came back to it a few months later, to use in place of another Samsung monitor¹ that was acting up. Unfortunately, I now noticed that there were several columns either fully or partially missing from the display. While the shape was consistent, what’s odd is that this artifact seemed to change colour depending on what else was being shown on screen.

At first, I hoped that this was just some kind of glitch with what I was running on it, but I noticed that this nasty blob even persisted when the monitor had no signal and was hunting between digital and analogue inputs. I don’t know if something bumped into the panel while it was in storage, if I did something wrong during reassembly that took awhile to show up, or if it was just fated to die this way.

Ultimately, this is a very disappointing end for such a big and bright monitor. I’ll still keep using it as a bench monitor until a nicer one – maybe another 15kHz Dell – comes along, but it’s not what I hoped to get out of this project.

At the very least it is at least usable, unlike how it showed up on my door. Can’t win them all!

Repair Summary

Fault	Remedy	Caveats
Does not turn on	Replace corroded 1-watt 68Ω resistors with 2W.
Several capacitors look dodgy	Measure ESR, replace those that failed.
Screen won’t rotate	Remove hidden lock-out bolt.	Screen now rotates too much.
Screen damaged	Store things better next time.

My hit-by-lightning Samsung 910MP, who else? ↩

Loonies for Loongsons

2026-04-14T00:00:00+00:00

Although we usually deal with old computers around these parts, today’s project comes to us from the futuristic year of 2021. What makes it interesting? You can’t buy it at your local store. Or any store, really. Today, we’re going to be getting a salvaged Loongson 3A5000-based motherboard up and running, and figuring out how good Linux is on a domestic Chinese CPU.

What is a Loongson?

For the last couple of years in China, local industry has been working hard on developing hardware and software for domestic needs. One such company is Loongson Technology, who run a fabless operation making their own chips. They started out in the late 2000s building 64-bit MIPS CPUs, which I don’t really know anything about, but then things got interesting with the development of their own instruction sets.

In other words, their CPUs are not Intel/AMD64-compatible, or ARM, or PowerPC: it’s its own whole new CPU family, with presumably-incompatible machine language.

With the 3A2000 CPU, they moved on to their own “extended MIPS” ISA, and then with the 3A5000, they released chips with their own ISA, called “LoongArch.”

One of the cool things about this design is that, unlike a lot of the PowerPC boards out there, a lot of vendors are building systems that you can actually buy around them. Taking a tour around the salvage market reveals a lot of SoC-style embedded machines, laptops, micro-ATX motherboards, mini-PCs, and even full-blown Lenovo desktop machines using a LoongArch chipset.

What’s this one?

This specific motherboard, the ML5A-MB¹, came to me through a salvage listing on Goofish/Xianyu, which seems analogous to a Mercari-style marketplace website from what I can tell. Looking closely at the pictures in the listing, it looks as if a recycler got an entire computer in, and removed the motherboard to reuse/scrap the case and cooler. As a result, I had no idea if the board worked.

That motherboard sports an LS3A5000LL CPU, which is a quad-core 2.3GHz processor that is rated to sip 35W of power at full trot. If you click through to that link, one of the interesting things you’ll see is that this CPU has 16 GPIO pins! Clearly, they wanted to leave their options open.

Ports on the back are roughly what you would expect from any other modern PC. USB3, audio, HDMI, VGA, DE9 RS232, and integrated RJ45 Ethernet. Yeah, you read that right. There’s analogue VGA in addition to HDMI. I would have expected everything to be digital-only by now.

Prices for these things are highly variable, but this was on the lower end of the market. Using a proxy site, I paid CNY260 (about $50 Canadian at the time of writing) for the motherboard, and a further CNY96 (about $20) to ship it. That’s a little more than I would usually pay for an untested motherboard, or anything, but surprisingly a lot of them are much more expensive, and shipping would cost more with a big ol’ cooler attached.

If I had a larger budget, I could have walked away with an entire system. Like I said earlier, there were even sellers offering turn-key Lenovo towers, and there’s a handful of laptops from new-to-me brands available as well.

My new motherboard showed up after about two weeks in transit. I had a few tasks ahead of me before I could make this into a functioning computer, which we’ll cover in the next sections.

I needed a cooler that fit. Although cooler footprints are not particularly standard (e.g. Intel and AMD use different ones) I was confident that whoever made this motherboard probably just grabbed one “off the shelf” rather than make a new one from scratch.
I needed to stuff this thing with RAM and storage. Luckily, it appeared to take standard DDR4-3200 RAM and m.2 SSDs, which – while skyrocketing in price – were still available.
Last, I needed to get an operating system for this thing to run. The board is recommended to be used with Loongson’s own Linux distribution, Loongnix, but they’ve been working hard to support Debian as well.

The Cooler

Before the board arrived in the mail, I started looking for coolers. I don’t know why I started at this part. Maybe because I don’t know anything about coolers. A few weeks prior, I had put together my first AM4 machine, but that (used) CPU came with a cooler. I’ve said the word “cooler” a lot in this paragraph. Cooler cooler cooler.

From some quick research, I determined that all the CPU manufacturers have decided to have different spacing for their mounting holes. Because of course they have.

After a quick search, I came across a manufacturer called Coolserver, who was selling a seriously overbuilt CPU cooler for Loongson CPUs. The page states that the “CPU hole distance” is 80 x 80mm. Would I get lucky and find out that represents a common spacing for a CPU cooler I can just buy off the shelf here? Yes, of a sort. Water Cooling UK’s round-up article shows that the LGA 2066 CPUs also happen to have an 80x80mm cooler mount.

I’m glad I waited to buy an LGA 2066 cooler, because that is definitely not what my motherboard takes.

It arrives

As soon as I worked the board out of its styrofoam shipping enclosure, the first thing I did was measure the distance between the cooler holes. Centre-to-centre, it was 75mm, which matches a super common Intel 1155. Boy, I’m sure glad I didn’t buy an LGA 2066 cooler for this!

Since I had so much trouble finding this information, my suspicion is that this hole spacing is not part of a Loongson “standard” but is instead decided upon by whatever motherboard manufacturer is doing the integration. In this case, they probably opted for an inexpensive, high-quality, commonly available family of coolers to take maximum advantage of the existing Intel supply chain. Smart.

With my local store devoid of inexpensive 1155 coolers, I grudgingly placed an order on the jungle site for a Thermaltake “Gravity i2” Intel cooler². In the meantime, I set about looking over the motherboard, hunting for any shipping damage that could cause my first journey into the LoongArch universe to be unpleasant.

One very weird part of this board is that the CPU has what appears to be hot glue around the corners of it. There’s also a very sloppy glob of hot glue on the thumb tabs on one of the RAM sockets. Did whoever put this system together glue in the RAM to keep it from coming loose during shipping? If so, what’s the deal with the CPU?

Since the board was shipped, the unshrouded pin headers for front-panel connectors (USB, audio, etc) had variously bent pins. I used a mechanical pencil with no lead in it to bend these back into a facsimile of where they were supposed to be.

I also noticed one of the soldered “tails” on the backside of the RAM connectors had been bent over and seemed to be touching an adjacent solder joint. A bit of work with my Hakko straight-jaw pliers fixed that, and I went over the rest of the board looking for other bent things to fix.

Naturally, I took zero pictures of any of this happening.

Cooler install

I was getting ready to smear some thermal paste on here and receive the collective anger of the Internet, when I realized the new cooler I had bought came with a weird plastic cover on the bottom. After removing the cover, I realized someone had already applied thermal paste to the cooler! Convenient, and not least because it allows me to escape blame for my own special technique of applying thermal paste³.

Sure enough, the 1155 cooler bolted right into the existing backplate (I lined them up beforehand to make sure they were the same) and I snugged it on slowly in a star pattern. At last, it was time to throw this board into the micro-ATX case I had lying around and fire it up.

Since this thing follows standards, it’s a really easy install. In fact, it was a smoother job than installing an MSI X470 Ryzen board was a few weeks earlier – the front-panel labels on the ML5A are much easier to read.

First boot

After connecting all the front panel connectors and saying a small word of thanks to the anonymous engineers who made this sucker, I hit the power button. After a series of beeps and VGA sync gains-and-losses, it let out a constant BEEEEEEEEP at high volume and kicked me into the UEFI shell.

The shell reads:

UEFI Interactive Shell v2.2

EDK II

UEFI v2.70 (ZD-TECH, 0x00010000)

map: No mapping found.

Press ESC in 1 seconds to skip startup.nsh or any other key to continue.

Shell>

The shrieking of the speaker was getting to me, so I shut the computer off and tried to find a way to turn the speaker off. No such luck, so I just put some tape on the buzzer.

That made it still annoying, but much more tolerable while I figured out my next step. Not being familiar with UEFI, I wanted to poke around in the shell to see if I could find any cool features, such as a RAM test. No luck there either, but at least the keyboard was working.

Almost-operating system

While the board was in transit from China, loong64 became an official architecture of Debian. That’s a pretty nice coincidence. Of course, stable isn’t going to be provided until the forky release in 2027, but it sounded like at least things are headed in the right direction.

Since this computer is intended to be a “toy” for now, I didn’t want to spend too much money on storage for this operating system to run on. Even though the modern era has significantly bloated installs, Debian is still pretty svelte, so I figured I could get away with a 256GB SSD.

It was at this point I realized that I didn’t know how physically large of an SSD this machine took. The M.2 cards come in different physical dimensions, described as “width height” sizes. For instance, “2280” is a 22mm wide x 80mm long SSD, seemingly including the edge connector. I took a caliper to the footprint on the board, and it read 75mm, so I needed a 2280.

The local electronics recycler sells 2280 M.2 256GB SSDs for about $27 Canadian, which is probably a reasonable price, especially considering the recent ridiculous inflation in the flash memory industry. They are used, of course, and you can’t pick what brand you get, but the folks at the recycler claim that they have “95% and above” health condition, whatever that means. I’m not sure what other brands they have, but I am pretty happy at having gotten a Toshiba. Maybe one day I’ll have an entire computer made by them.

Now that I had some storage, it was time to install it. Debian doesn’t have a livecd or anything particularly fancy at the moment, but they do have a Debian 12 NETINST ISO available on the loong64 port page. I wrote this somewhat old ISO to a USB flash drive using all the default Rufus settings, but the computer continued to end up in the UEFI Shell. Somehow during this, the computer decided to stop shrieking at me during the speaker, so that’s a win already.

During one of the restarts, I noticed that the computer also displayed a brief sign-on message before heading to the Shell. It’s hard to read, because the crappy Samsung LCD I was using to test it likes to put itself in sleep mode and only wake up after a lot of frames have been missed, but I was able to see “Del” and then a bunch of Chinese characters. I restarted again and mashed Del… and got into a more traditional BIOS settings screen!

Even better, it had an English language setting near the bottom of the first page.

It is revealed that I was running KunLun BIOS v4.0.

Unfortunately, the boot order was already set to boot off of the USB stick. If I tried to forcibly boot off of the USB stick on the last page of the settings, it would just flash the screen black and then return to the BIOS screen. I re-wrote the USB stick two more times, first using the “DD” method and then changing the partition table to “GPT,” but neither change worked. I could clearly read the disk from inside the UEFI Shell, as ls fs0: worked, but run fs0:boot/vmlinuz just paused for a second and then returned me to the shell. I was missing something.

If I ran bootloongarch64.efi, which worked for one of the Debian maintainers, it would raise an error cannot allocate memory for memory map. Aborted. Press any key to exit. Searching for that error message, of course, led to a GitHub issue that told me I needed to update my BIOS. Despite the fact that the Debian page also warned me to do so, I really did not want to update my BIOS, but let’s update that BIOS.

Updating the BIOS

The Loongson git repository containing firmware images offered four options for my board, the ML5A. Unfortunately, they were cryptically named, with no documentation:

UDK2018-LoongArch-ML5A-stable2408_Gmem_dbg.fd
UDK2018-LoongArch-ML5A-stable2408_Gmem_rel.fd
UDK2018-LoongArch-ML5A-stable2408_NoGmem_dbg.fd
UDK2018-LoongArch-ML5A-stable2408_NoGmem_rel.fd

For rel and dbg, I can guess that those mean “Release” and “Debug,” but what was “Gmem?” Some searching indicated that it is a new virtual-memory model that tries to integrate external memory in some better fashion. That confused me, but I decided that I would probably like to have it, whatever it is, and besides, the BIOS chip is socketed(!) on this motherboard anyway. I chose the release version with gmem and downloaded it.

The main readme of the repository had some good nuggets of info, walking me through how to do an update from a USB stick. It also had this piece of gold, which tells me we’re in good hands:

Back up current firmware. We recommend that you need a burner, and read the contents of the SPI flash through the burner and save it.

Imagine any of the North American motherboard manufacturers telling you to buy a programmer and do an SPI flash dump before updating your firmware. I love it.

I decided to ignore this advice and do an update. From the “Save & Exit” tab of the BIOS screen, there is an “Update BIOS” option. Picking that will let you navigate through the filesystem of the USB stick and then select the *.fd image. At that point, it brings up a “Firmware is being updated, please do not power off” screen and a very slowly increasing progress bar. One of these days, someone should make a firmware update screen that isn’t terrifying.

Somewhere in the middle of this process, the screen shut off and then I got kicked into a completely new BIOS screen that was now once again in Chinese. It still had an English option. Hooray!

Debian, again

I rewrote the Debian install media using Rufus, this time with all the default settings. This time, the computer booted instantly to the installer’s Grub bootloader when selected from the BIOS menu. I picked “graphical install,” and it panicked because it was unable to mount root fs on unknown-block(0,0). On a second attempt, I noticed it was first complaining about not being able to find a file marked /install/gtk/initrd.gz, which was indeed missing from the filesystem. I must have accidentally bumped a key and skipped that message the first time. Regular install it is.

This process started about as you would expect for a Debian text-mode install, including all the awkward pauses where it seems like it isn’t doing anything. I was using a non-free Edimax USB wi-fi adapter at this point, so the installer stopped me to tell me to go get the Realtek chipset drivers and put them on some disk it could access. It then went away, and asked me for another driver, this time a firmware blob for what I assume is the onboard NIC. If you give a mouse a cookie…

After that, the net installer was able to establish a friendly connection with my wi-fi router and set about the great project of installing nets. Er, installing from nets.

I named the new hostname qie, which is sort of a terrible Romanization of the Chinese word for penguin, 企鹅 (qǐ’é.) It seems as if the literal translation of this word is close to “standing goose,” which is very funny. Look, this blog is educational.

Although I was conflicted, I decided I would follow the Debian installer and use a swap partition. I know it can shorten the write lifetime of the drive, but this computer is unlikely to become my main system, and the drive has already been hammered by some other dude before it hit the recycler anyway.

I ran into some trouble trying to configure apt and get the package mirror configured; it kept insisting that various mirrors didn’t support the sid distribution, when they clearly did. Eventually, I figured that this was probably a network problem, and went back to restart the configuration of my wi-fi device. A few more DEAUTH_LEAVING events came while I was trying to get more packages installed, and I was starting to remember why this USB wi-fi adapter was in the back of a drawer, after failing to use it reliably with the Raspberry Pis.

I wired the Loongson quickly to an Airport Express serving as a wireless bridge, and everything went smoothly after that. GNOME and GNOME Flashback did not install because of various unavailable or conflicting dependency packages (on a fresh install, using tasksel? I can only assume this arch is still a little bit in-development, although Debian 12 is also very old) but XFCE happily installed. I prefer WindowMaker anyway.

After a reboot, I found myself back at the Loongson BIOS screen. A new boot device had been added: debian. I picked it and ended up in grub, and then booted into my newly-installed XFCE environment. I’ll have to figure out how to get this thing to autoboot later, but for now, I have a working Linux environment.

Wi-fi, part 2

To fix the terrible USB wi-fi, I decided to grab a real wi-fi card. Amazon had what was claimed to be a PCI-E x1 wi-fi card with a compatible AR9220 controller for eleven bucks. Unfortunately, when it arrived, it turned out to be a PCI wi-fi card, which I would have noticed if I looked closer at the picture. That was returned, and I then doubled down on my plan to cheap out.

I decided that I would grab an M.2 wi-fi card, because I had an extra tiny M.2 slot on the motherboard, and it would be neat to have wi-fi built in with no awkward card jammed in the back. eBay provided an “Intel 9560NGW” for $7 US shipped. When it finally arrived, I slotted it right into the machine, screwed it down, and then fired it up.

After I was able to get to a prompt, I checked to see if the card was detected. lspci | grep -i intel didn’t mention anything at all about this card, which is weird for something that is in a (teeny little) PCI slot. After a quick web search, it turns out that some of these Intel wi-fi cards aren’t M.2 at all – they fit into an M.2 slot, but use a proprietary Intel interface called CNVio, where most of the guts of the card are done on the motherboard chipset. Wish I had known that before I bought one!

I went back to the Airport Express bridge after that, but I do plan to eventually buy a PCI-E x1 wi-fi card. Modern computers are so much fun!

Upgrading Debian

Of course, sid is a pretty unstable “release” of Debian. I decided to see if I could get something more filled-out, which would hopefully make installing exotic packages (like SDL2, apparently) a little simpler.

After some mucking around in sources.list and consulting debian ports, I determined that only sid is really “supported” by Debian, which makes sense as that’s probably where all the work for forky/2027 is going. Then I found the unofficial loong13 branch of trixie, which is hosted on debian.net. Then I broke my apt badly trying to use their deb repository without knowing how to tell the machine to accept the release signature.

I ended up finding the package that installed the keyring (debian-loong64-non-official-archive-keyring,) digging the *.deb file out of the pool, and installing it with dpkg -i. Then I figured out what file it installed using dpkg --listfiles and provided that to my apt sources. That let me do apt update to the unofficial trixie, and I was ready to do a dist-upgrade. This… surprisingly… worked?

Even if it had blown up⁴, the unofficial loong13 project also provides a network installer ISO, and my install was fresh enough that I wouldn’t mind paving over it to get a more useful version of Debian installed.

Benchmarks

What do you do when you get a new-to-you CPU? The obvious answer is to benchmark it against some other CPUs to see what it’s faster than.

Phoronix has a bunch of benchmarking tests, so I decided to head over to their website, OpenBenchmarking.org, and see how the 3A5000LL was holding up. The answer is not especially well, but that’s an aggregate view and CPUs have gotten really fast since 2021 (or, if you’re feeling more generous, the 2015 Intel CPUs that this is reported to be about the same speed as.)

For starters, I decided to compare the collected results against the Intel i5-3570 (2012.) Why that one? I just evicted one of those from my Windows computer because it could no longer hit minimum specs for new games, so I wanted to see if it was still more worthwhile than my new prize.

The answer is: without exception, the 3A5000LL was not faster than my old i5-3570. And it absolutely is not anywhere near faster than the Ryzen 5 3600X that I replaced the i5-3570 with.

You can make a bunch of excuses for this. Compilers are probably not optimizing well for the 3A5000 yet, whereas we’ve had decades of Intel/AMD dominance in personal computing that make that investment pay off. But it seems overall that the Loongson in practice is not even beating a 14-year-old Intel budget CPU. It narrowly beats out an Intel Core Quad Q6600 from 2007, so at least the Loongson does whip the CPU I had prior to the i5-3570.

At the time of writing, OpenBenchmarking.org had the 3A5000LL at roughly the 13th percentile. That’s not too bad when you consider that it’s being compared against every CPU ever made. I doubt I’m in the 13th percentile of the world’s fastest runners. The faster-clocked 3A5000 places in the 14th percentile, and the later (2023) 3A6000 gets bumped to 21st percentile, both of which seem like nice leaps to me.

I think it would be interesting to do a more in-depth comparison, but I may not be well equipped for this kind of spreadsheet-bothering. No, let’s see if this sucker can run Doom.

Videogames

Of course, everyone knows a modern computer can run a Linux port of Doom. I know for a fact that Chocolate Doom doesn’t need an extremely powerful video chipset, so it’ll probably work on whatever integrated video chipset this Loongson has. Plus, it has an easy Debian package. I decided to install that and then copy doom2.wad into /usr/share/games/doom. chocolate-doom then immediately started up in Doom II.

Shocking nobody, Doom II runs quite well on a computer made 27 years after its release. Now we can give this thing a bit of a challenge.

Say, what is this thing capable of? Let’s put it to the test with Extreme Tux Racer.

On the test “bunny hill” level, I was getting about 30-38 frames per second, which is not phenomenal, but is entirely playable. So even hardcore gamers will be pleased with their purchase of a turbo-budget Loongson!

Quake ran pretty well on this thing at default settings, although timedemo demo1 revealed that it was again only getting about 33fps on a windowed 800x600 context⁵. The console (via Quakespasm) did spit out a ton of information about the video chipset, however, including that it had tons of nice GL extensions available.

So what video chipset is it?

lspci reveals that the video chipset is reported to be a Loongson 7A1000, which appears to be the north/southbridge for the motherboard. So it’s an integrated video solution of some kind. This unofficial LoongArch FAQ tells us that it’s “based on the Vivante GC1000.”

Unfortunately, I wasn’t able to install mesa-utils to figure out exactly what the adapter reports for extensions and capabilities. This is because the package insists on a specific pinned version of the xkb library, which my increasingly-rickety Debian install wants me to downgrade a bunch of stuff to use. I am going to leave that particular fun for another day, and just repeat what the official documentation says:

The GPU supports OpenGL ES 2.0 and OpenGL ES 1.1; OpenVG, Futuremark certified, BitBLT and Stretch BLT, rectangle fill, hardware line drawing, color font rendering, YUV color space conversion, and high quality scaling. Space conversion, high quality scaling, etc. The display controller supports dual DVO signal output and hardware cursor, gamma correction, output dithering, etc. The memory interface uses 16-bit DDR3 SDRAM interface with a maximum data rate of 1333 Mbps.

OpenGL ES support on a desktop is maybe not as exotic as it once was, what with all the WebGLs out there, but 2.0 does have shader support. Whether or not things running on Xorg are taking advantage of it for hardware acceleration is a bit of a mystery at this moment – I may actually end up reinstalling the OS from Trixie to start with and hope that fixes it.

YouTube

After installing firefox-esr, I decided to go check if YouTube works. Modern web video is encumbered by a million different codecs, many of which are proprietary. Even great old machines like the Power Macintosh G4 series are having trouble keeping up with the Commodores these days.

To my delight, YouTube seemed to work just fine, and I was able to catch up on some essential PC-6001 repair videos. It didn’t even serve me any pre-roll ads, which is probably the ideal outcome for any general-purpose computer.

Conclusion

The real surprise with this machine is not how weird it is – it’s how normal it is. So many standards are followed in the Loongarch machines that, if you never ran uname -a, you’d probably never have any idea that it wasn’t a regular old amd64 on a cheap clone motherboard.

Truth be told, I’m a little bit disappointed that it isn’t more quirky and odd. Maybe the “more official” Linux distributions like Loongnix and Deepin have more cool stuff, but that could be run on regular commodity PC hardware too.

A huge part of this success comes down to the hard work of all the contributors to Linux and the related userland ecosystem, who have slaved away to make things as portable as possible. According to that Trixie-port page, virtually everything can simply be built from source and doesn’t care that it’s running on this different computer architecture. As someone who fixed stuff for Linux/PPC, that’s amazing on its own.

If you have any ideas for things I could run on this Loongson, or research questions in general for me to chase down, let me know. Like most things in my pile of computers, I don’t really have a great use for this one, but it sure is cool. I would like to try assembly language, but that’s definitely a project for a future entry.

Thanks for reading!

SMBIOS info reveals the manufacturer of this motherboard to be THTF, which seems likely to be Tsinghua Tongfang. ↩
A note from the future: this cooler turned out to be nice and quiet. I figured it would be a lot louder, judging from the low price and the handful of negative reviews on Amazon. I’d buy this again. ↩
It’s exactly the same technique you would use. Don’t tell anyone; they won’t understand us. ↩
There are still a gob of confusing package conflicts with pinned versions that make installing things annoying. Turns out forcibly in-place downgrading your Debian install is a bad idea. Unless I can figure out how to unravel these, I may end up reinstalling the OS with the trixie ISO anyway, as I hope they’re leftovers from sid. ↩
Timedemo for demo2 and demo3 were fairly consistently 31fps and 29fps, respectively. Trying to get big timedemo numbers made me feel just a little bit nostalgic of the days of trying to overclock a Celeron. Hey, anyone got a 300A they won’t miss? ↩

Make Your Own ColecoVision At Home (Part 5 - Making More)

2026-03-24T00:00:00+00:00

Leako – my ColecoVision clone – has reached a point where it has to become a thing that is actually buildable by other, more normal, people. On top of that, we’ve got chip and part shortages out the wazoo, and a smattering of bugs and reliability issues to knock down. Will revision number seven be the charm?

What’s New?

This revision of the board was mostly to try and improve reliability of the machine. While heavily testing (playing with) my previous-generation board, a lot of things bugged me.

Power Supply

For starters, I didn’t like that Leako version 6 relied on a barrel jack to provide the regulated +5VDC power to run the rest of the system. Not only do you have to worry about the quality of the regulation, and find a compatible adapter, but I also added some (still untested) protection circuitry to avoid reverse-polarity episodes. If there’s one thing I’ve learned from reading console-repair articles, it’s that the average person does not understand DC barrel jack polarity.

I had a couple options, such as designing a polarity-independent input circuit, going up to a 9VDC input and adding a 7805, or finding another way to power it altogether.

In the end, I ended up going with USB, as I had on my Sega SG-1000 clone, the Soggy-1000.

Getting a USB “B” jack is fairly inexpensive, it has okay strain relief, and everyone has a couple USB power adapters lying around. Of course, it’s not a panacea: some USB power adapters are a ripple-fest with terrible regulation, because USB was never really intended to be a universal power supply. Some chargers will push around 5.25V or even higher, which might damage some of the salvaged ICs. I ended up using a nice (but $18) Anker wall-wart to test my system with, and I was fairly happy with the results.

McTwist

There’s a lot of strain issues on the version-six board. For one thing, the force of putting a cartridge into it made the board dip like jumping on a diving board, because nothing is supporting the board in the middle. That twisting will eventually produce bad solder joints, and maybe even shorts or board damage. I put a hole to mount another board standoff near the cartridge to fight this, but I didn’t do it quite right. More on this later.

I also wanted to adjust the controller ports so they didn’t hang as far off the board, and use a port that could be “clipped” into place. While testing all the controllers on the previous iteration of the board, I was getting worried about how much the controller ports were twisting around when plugging and unplugging. Broken solder joints are no fun, and torn pads definitely wouldn’t be.

The change in controller port part worked great, and only required minimal re-routing to make room for the changes. Unfortunately, when I was defining the custom footprint for it in KiCad, I forgot to add a ring of copper to solder the pins to. As a result, the springy “strain relief” pins on the controller port are not soldered down, which significantly weakens them. Oops.

Since then, I’ve replaced the entire footprint with one provided by the manufacturer. It didn’t show up on this v7 board, but that’s life.

Shortages

Naturally, the ongoing component shortage nightmare was going to hit me, too. I got off pretty lucky, considering.

I ended up tweaking the system to take a different power-switch FET, and used a Maxim ICL7660 voltage inverter in lieu of the original TI part to generate the -5V.

The most annoying part was waiting for 74LS541s to come back in stock. TI’s 74-logic fabrication was apparently moving to a new process at the time, and they were slowly certifying and reintroducing their chips in order of descending popularity. Apparently the ‘541 isn’t a very popular part because I had to wait over a month for it. More on that in a bit.

Miscellaneous

To make assembly faster, I went through and labelled all the parts on the board with silkscreen. Now, you can tell where passives go just by looking at the value on the board, which makes it a lot easier to stuff the board. Prior to this, I used a printout of the BOM (bill of materials) and crossed it off with a pen as I went. There were some other improvements relating to BOM as well, which I’ll cover later in this article.

I found out that the manufacturer of the RCA jacks I had been using also made them in various colours. To make sure I plugged video into the video port, and audio into the audio port, I picked up the correct colour for those jacks and specified them in the BOM. It’s the same footprint regardless, but the colour-coding helps make it feel a little bit more professional.

Reliability-wise, I also grounded all the unused inputs for the 74 logic after hearing about this practice from Dave Park in the X68000 PRO power supply rebuild. I think it lowered the current draw, but I can’t really be sure. Either way, doing so is a good idea.

Last, I put a nice little radius on the board’s corners. It didn’t really show up well after fabrication, but the corners do seem less “pokey.”

The BOM Generator Script

KiCad comes with a Python script (“plug-in”) which will generate a bill of materials (BOM) CSV file automatically from your project. I’d had problems using the script before with previous versions of the Leako, so I ended up taking theirs and hacking it up.

The biggest problem I wanted to solve was that Digi-Key’s BOM CSV importer just didn’t understand the file. Most of this was because the Digi-Key importer was very immature up until recently, and would spit my file back out, rather than give me a way to fix it or even hand out a reasonable error message.

Their documentation also didn’t say what the field names it was expecting were. All of my Digi-Key part numbers are tracked using a DigiKey field in their respective KiCad symbols, for instance. I ended up creating a new BOM using their web editor, putting some random garbage in it, and then exporting it to CSV to see what it would produce. Then, I copied those column names into the Python script, and made it re-map the DigiKey field into Part Number.

Digi-Key also lets you enter a little descriptive text next to the parts you buy, and then they print this on the baggie that they put the parts in. To make assembly go faster, I wanted to print the location of each part on the bag. That way, I could reach into the box, grab a bag at random, look at it, and know where that part should go. I ended up mapping the KiCad field References to Digi-Key’s Customer Reference. I didn’t need to do this part, it turns out, because Digi-Key’s web UI had matured enough that it would just let me designate any column as Customer Reference. Still, it’s nice to have.

In the future, I will also add the project name as a configurable prefix, so that I can order multiple projects’ BOMs in one box, without getting confused about whose “U1” this particular bag belongs to.

The final feature I wanted to add to the BOM exporter was footprint splitting. KiCad considers a socketed IC to be just one part: the socket. It only exports one row for that part, so I have ended up doing stuff like buying RAM, but no sockets for that RAM. We’ll talk more about that specific screw-up in a bit.

When I’m buying from Digi-Key, I want to order two parts – the socket, and the part that goes in it. For these cases, I ended up making this field into a semicolon-delimited list¹, and then having the plug-in generate separate rows for each token in the list.

It would have been nice to add a configurable (or at least pulled from project information) prefix. This way, if I use this again in the future and order multiple different projects, I don’t have to guess if a given bag’s “U6” designator refers to the Leako, or the Soggy, or what. This will probably get fixed right around the time I have this problem, or shortly after.

At the time of writing, I have since upgraded to KiCad 6, which appears to have a whole new plug-in architecture. This means that I’ll probably have to do all these changes again for future projects. C’est la vie.

Procurement

This version of the project had two aims:

To build a second Leako;
To ensure that my BOM (bill of materials) was reproducible, i.e. that I wasn’t missing some parts. My big fear was that I would give someone the BOM, they’d spend some of their hard-earned money to buy it, and they’d end up with not enough parts to build a working system.

As it turns out, my only major BOM error was that I only used the fancy new “splitter” feature on the CPU socket. I should have also specified some DIP sockets for the expensive 62256 SRAM; as it is, they ended up soldered directly to the board. Oops.

Here’s how many parts you get if you order just enough for one (1) Leako, and occasionally click the “cost optimizer” for things like caps:

Once all the components were removed, this made a huge amount of plastic waste, which I’m not too excited about. My shop only has so much capability to re-use empty plastic bags…

Additionally, as you might expect from the current semiconductor shortages, the price of the BOM went way, way up. I estimated the previous BOM at around fifty dollars; this one is over eighty bucks, which starts to make this project feel like it’s not much of a cost savings over a garage-sale ColecoVision at all. The PLCC Z80 CPU is particularly expensive, making up $12 of the total BOM price, and has since also famously gone out of production.

This huge increase in build cost is very demotivating, and it will probably affect my designs in the future². Hopefully, all these cool 5V parts will keep getting made, and the prices will return to normal.

As I mentioned earlier, there was also the shortage of 74LS541s; they shipped separately, almost a month later. This meant that I was sitting for a few weeks with a Leako that I couldn’t control, which had some interesting consequences that I’ll get into later in this article.

Used Parts Accepted Here

That ends the new parts. The Leako still needs three no-longer-produced “vintage” parts from other systems in order to work, and so these must be obtained from salvage:

The Texas Instruments TMS9918 video display processor (VDP;)
The Texas Instruments SN76489 sound chip;
A 27c256 (E)EPROM to contain the Coleco BIOS³

While being an idiot, I had broken a leg off of a 27C257 EEPROM awhile ago, and soldered a new pin header leg in its place. This wasn’t reliable enough for regular insertion-and-removal from a socket, so I decided that it would see its permanent home in this system. I wrote four copies of the no-delay BIOS to the EEPROM (using a script that was developed for a future ridiculous project – stay tuned) and shoved it into the socket.

I had also ordered a set of TMS9918 video chips from a trusted seller on AliExpress, but when they arrived they were one chip short, and had all their identifying markings scraped off. The seller/AliExpress refunded me the entire purchase price, but I had a suspicion that they were still TMS9918s. Doing resistance checks and comparing those checks with a “known” TMS9918 confirmed it. I populated the remaining sockets with one of these salvaged TMS9918s and one of my also-dwindling hoard of working SN76489 sound chips.

As 9918s get scarcer, future versions will likely use the Pico9918: while I really like the look and feel of the original part, the Pico9918 shaves the most expensive five chips off the BOM (SRAM, the three latches, and the 9918 itself) and adds RGB output.

Assembly Notes

The “v0.7” board makes a couple of changes, and not all of those changes were for the better.

One big trap is that I found out that the 10µF load capacitors for the ICL7660 -5V regulator were placed way too close; it was hard to drag-solder the chip’s legs without hitting them.

Assembly on the 74LS574 VRAM latches still sucks: the pads are too tight so you have to very precisely place the chip to get enough “meat,” and the chip is too tall to hold with tweezers. I made the pads slightly wider on the v0.8, which might make things easier, but I’m not planning on building one anytime soon – at least not without some exciting new features.

I also had moved the series electrolytic capacitor responsible for the composite video output closer to the connector. This, unfortunately, meant that the cap now occupied the same space as the tip of the composite video plug if you had a particularly deep one on your video cable, as I do. Oops.

Assembly overall took me about four hours. I’ve gotten a lot faster this time around than with the last board. Almost all of this performance improvement can be credited to better tools.

Better Tools

The best investment by far was the StickVise. This is basically a horizonally-aligned clamp that lies flat on your desk and holds the board about a centimeter off the surface. Its clamp is just loose enough that you can slide the board out, flip it over, and slide it back in when you want to look at something on the other side. A genius tool, and 100% worth the money. I should have bought this years ago.

As with the BlueSCSI build from a few years ago, I used blue poster putty to hold in the through-hole components so that they wouldn’t fall out when I turned the board over to solder them down. StickVise now makes this weird springy holder – the PartLift – to push parts up against the board, and I picked up one, but I was afraid of using it for some reason.

Making the “BOM generator” script print the locations of each part on the little Digi-Key baggies was also a huge time saver, as was the labeling on the board. This way, I could pull a bag out of the box at random, and immediately know how many parts needed to be used and where they went. No need to look at a printed-out BOM.

The new-to-me Kester 63/37 solder helped a lot with drag-soldering of SMD ICs. It seemed to flow much more like how I want, without cold solder globs building up on the tip. There were still bridges and underfills, but it felt more like it was my fault when they happened.

Uncontrolled Test

I hooked the Leako board up to my Anker USB power brick, with a USB voltmeter/ammeter in between⁴. Initial power-on showed that it was pulling about 0.29A at 5.08V sitting on the BIOS screen, which is more or less what the original, DC-plug, Leako pulled. Good indicator, so let’s strap it up onto a TV and check the video.

I did find one serious, but survivable, boo-boo during assembly. With a mounting screw installed into the new strain-relief position near the cartridge, it would add a little bit of height from the head of the screw sticking out. The bottom of the cartridge case would interfere with that head, and the cartridge PCB would not make full-depth contact with the connector as a result. This renders the new strain-relief hole useless, unless I somehow find some very low-profile screws.

I’ve since moved the support mount’s hole to the side of the cartridge slot, where it should only be threatened by an empty space under the cartridge shell.

The cartridge shell also now interfered with the 74LS04 and 74LS74 at U11 and U20, respectively. This was a big surprise, and a huge disappointment to come right at the end of the assembly process.

Before, the cartridge would just barely clear the tops of those packages, whereas now it sits a little cockeyed and would sometimes keep carts from booting. I wasn’t sure why this didn’t happen before, but as soon as I compared the two boards, I realized I had made a mix-up in the BOM between revisions and ended up using a different cartridge slot.

That new, blue Sullins slot places the cartridge just a teensy-tiny bit closer to the board than the old black TE AMP cartridge slot did. The datasheets said the housings were both 15.49mm tall above the PCB, but the TE AMP datasheet says the insertion depth is 0.05mm shallower (7.54 vs. 7.49), which can’t possibly make that big of a difference. Without an answer to my mystery, I shrugged and changed the BOM to use the TE AMP part, and moved a chip a little further away from its landing zone just in case.

The crooked approach didn’t interfere with cartridge reading, but in the future versions, I will also flip these offending ICs to the underside in order to make it much easier to put the cart in.

Uncontrolled Test

However, all was seemingly not well with the assembly. Since the ‘541s were missing, the console thought that all of the joystick buttons were being pushed at once.

More concerning is that Cosmic Avenger came up fine with tile graphics and “smooth” scrolling, but the player ship looked corrupt - just a couple of coloured squares.

I had assumed that, like the original bring-up of the Leako, I had simply not soldered the surface-mount ‘574s which feed the video RAM properly. As a result, wherever the game was sticking the sprite tiles into video RAM was not being read or written properly. Although I had paid special attention to the ‘574s during pre-flight inspection, I was also really tired – a recipe for failure.

I broke out the jewelry loupe and a very strong light to take another look. Everything looked fine there, so I tried another game. Donkey Kong worked 100% fine. In fact, really well. Buoyed by the missing controller, Mario ran all the way to the right of the screen, and hid there in the corner for several seconds until a particularly determined barrel finally got him.

Controlled Test

Eventually, some 74LS541s rattled loose from the distribution network. These had a then-new 2022 date code on them, so they must have been fresh out of the oven, after TI’s aforementioned change in fab process for their 74s.

Unfortunately, when I fired up the system, I found that it blew right past the BIOS screen⁵, and then got stuck on the skill select screen. No amount of pushing buttons on either my homemade joystick or a known-good Super Action Controller would make the game run.

I thought hard about what I had changed on the controls between revisions of the Leako. Pretty much everything was the same, except for the -5V generation. It had changed from the out-of-stock TI charge pump chip to a ICL7660.

I should have checked that when I did my first fire-up even before the ‘541s arrived, but no time like the present. With the red probe of the multimeter on the -5V test point, and the black probe on the ground test point, I was observing +1.6V. That’s quite a lot more than -5V… what happened?

After closely inspecting the tight spot that I had to solder the ICL7660 in, I wasn’t satisfied with the soldering job. I desoldered the 10µF that was too close to the pins, then reflowed the pins… like I should have in the first place. Always check your work while it’s easy! It looks like pins 2 and 3 (oscillator cap positive and ground, respectively) were not well-attached. Now, I was getting a reliable -5V (or at least, -4.8V.)

Getting the -5V generation to work properly, sadly, did not measurably improve the system’s performance. The same “autofire” phenomenon happened, except when testing it this time I noticed that I could pull right on the joystick to bypass the skill select menu. So it was treating some “fire” inputs as “number pad” inputs.

I cut the ICL7660 out of the circuit entirely and pulled the joystick down to GND instead of -5V. I’d never felt great about this “super pull-down,” and now was the chance to see if it worked okay without it. The verdict: sort of. My custom-made joystick worked great, but the Super Action Controller’s more complicated maze of diodes just didn’t reliably respond to joystick inputs.

On top of that, even though I had a working joystick of sorts, pulling down and to the right was treated as the equivalent of pushing the “*” button on the system, pausing the game. And the song it plays when paused on Frenzy is really freaky; it’s squelchy and hummy enough to make you think you’ve broken your system. Once I figured out that the game was pausing instead of just breaking, a lot of things fell into place. Namely, I could kill a full room of robots in Frenzy as long as I didn’t touch the diagonals. Nice.

So, it seemed to me that the mode-select logic wasn’t working. Why not? It turns out that U23, the 74LS00 that makes up both halves of the “flip-flop” that handles mode-select latching, was not well-soldered on pin 6. It looked fine from a casual glance, but at a certain angle and with strong lighting you could see some exposed pad. After touching that up, and also the pads around it for good measure, I now had the ability to play Frenzy with the correct buttons!

Just like with the first board’s weird graphics, the fault was my poor SOIC-soldering skills. I’ll definitely have to spend more time checking my joints from now on, and take more time around ground pads that need a little extra heat.

Frenzy and Zaxxon are a lot of fun with the Amazon-parts joystick controller. The leaf-switched joystick lets you place the movement more precisely, and it makes these games just that little bit closer to arcade-perfect. I would strongly recommend building something like this to any ColecoVision owner.

Just to confirm that it wasn’t the -5V’s fault, I went and re-implemented my bodge to pull the controller to ground instead of -5V. The Super Action Controller also worked with the pull-down tied to ground instead of -5V, although it seemed a little glitchy moving up or right, which may just be the nature of that controller. More testing is necessary in this configuration.

A Third Leako

The Cambridge Centre for Computing History was doing an anniversary exhibit, and wanted to see homebrew examples of systems released in 1982. I sent a bare board of the Leako (along with a bare board of the Soggy, for next year) to blog superfriend Pete Golding, who then actually bought all the BOM, and assembled one of his own clones.

Unlike me, he didn’t drag-solder, and seems to have ended up with better results. There were some bad joints on the ‘574s that needed to be cleaned up before the video would display properly, and one of his TVs got very angry at the signal and refused to display colour at all. I suspect the 33pF load caps on the clock crystal are simply the wrong value, so I will add an adjustment pot in future versions.

Thanks for being a guinea pig, Pete!

A Fourth Leako

Blog friend Famiclone also tried to assemble one at this point, but ended up with one that didn’t seem to be able to boot games or the internal BIOS. Long-distance debugging hasn’t worked so far, so I am regretfully going to get them to ship it back to me and see if I can figure out what’s gone wrong.

A Fifth Leako

Blog friend Cheshire has also built one! He reports that quadrature controllers are still not working quite right, and he has a theory that I used the wrong logic family. We’ll work together to figure out what the problem is!

Conclusion

This phase of the project was full of ups and downs.

There’s obvious progress: the system still works. More Leakos got built, and more of them successfully ran games. That means the total number of ColecoVision systems in the world increased. One got built and run across the ocean, for museum visitors to see! It’s got a reproducible BOM, which you can buy parts for! I reused part of the design to make a Sega SG-1000 clone, and then brought those fixes back to the parent board!

On the downside, a lot of the new stuff I tried out didn’t work. I am still rushing through the soldering, which makes for an unreliable system that’s challenging to debug. The cartridge-interference issue practically forces a new revision of the board, which means more assembly time and expense, just for the sake of a chip being moved a little further over. Shortages continue to dog this project, as do flaky original controllers.

I was expecting a triumph and got kind of a weak “good enough.” That’s why this blog entry is coming out several years after the board has been assembled and tested – the whole thing bummed me out, even though I should be really happy with how far it’s come.

Don’t worry, though. This isn’t the last you’ve heard of the Leako project, and I’ve already made some changes to my technique and the board’s design to promote a more reliable outcome next time.

For instance, the PLCC socket and the PLCC Z80 that goes in it is entered as 2057-PLCC-44-AT-ND; 269-3899-ND, respectively. ↩
For instance, the Soggy-1000 revision that was made after this has already gone to a salvaged $1 DIP Sharp LH0080A for its CPU rather than these expensive and now no-longer-made Z80s. ↩
27c256-compatible EPROMs might actually still be in new production somewhere, but you can buy a vacuum-packed brick of old ones from AliExpress for about fifty cents apiece. Waste not, want not… ↩
This inline USB voltmeter/ammeter really freaked out my Rigol digital oscilloscope whenever I tried to take readings with it mounted – the Rigol would read ridiculous voltages on logic pins. I only needed that ammeter for the initial bringup, but I kept it connected because it looked cool. ↩
For this specific unit, a “No-Delay” BIOS was flashed onto the BIOS EEPROM, which lets you skip the otherwise unskippable 12-second countdown on the “ColecoVision Presents…” screen and get right into the game. It makes testing a lot faster. ↩

Untrashing a TRS-80

2026-03-03T00:00:00+00:00

This Model 1 TRS-80 has been through a lot before it was rescued out of an e-waste dumpster by my friend. With some patient work, I should be able to turn it back into a computer. But how bad will this Frankenstein’s monster of a trash 80 become in the process?

What do we have?

Tandy was one of the first to the personal computer game. The TRS-80 is a Z80-based home computer from the late 70s, and they sold a lot of these things.

Most Model 1s you’ll encounter have an “expansion interface” attached, which is a large flat box containing extra RAM and some peripherals (most importantly, the floppy controller.) This computer came with a cable attached to the expansion connector, but no expansion interface on the other end of that cable, so either it was lost in the bottom of the ewaste dumpster or was cruelly separated from it. That’s too bad, but it does give me another project in the future if I end up liking this thing.

Since this machine had been inside an e-waste dumpster for awhile, it had been basically rock-tumblered with everything else in the box. That caused a lot of case damage, but it also broke some other, more valuable bits. Shaking it out, I found:

Key caps;
The power LED and its retaining gasket;
Broken pieces of what seemed to be a key switch;
An SMD fuse holder(???);
Random pieces of conductive foil

Oh yeah. This is going to be a project.

This poor computer’s top case was broken in two spots, with a big crack in the corner that had folded the case over itself. There was also a smaller crack across the expansion port frame, and the expansion port cover flap was missing entirely.

The port cover with labels had fallen out, so I had no idea which of the three identical 5-pin DINs were which!

You don’t want to mix these up, because one of them is power, and can serve around 20VDC and 20VAC. I would assume the tape logic and video output do not appreciate this. Plus, the power supply brick doesn’t even have a switch on it, so one accidental mis-plug even with the system off will cause damage. Hey, it was the 70s. If you weren’t paying one hundred percent attention while plugging things in every single time, clearly you just aren’t cut out for this brave new future of being asked about MEM SIZE?

A whole corner of the bottom case is missing, so making it nice is not a priority. Not able to find my usual quick-setting model cement, I instead used Tamiya Extra Thin model cement to first bond the big crack and then the smaller crack while squeezing them together by hand. The cement seemed to melt some of the silver paint, so be careful with squish-out.

Everything seemed more torsionally rigid after doing the very basics of case repair, which meant I was going in the right direction, and it wasn’t likely to just explode again like an Apple case.

The top case has this black keyboard-surround insert. That insert is cracked so badly in the corner that someone has run a self-tapping screw in here to replace a missing tab and hold it in place. This supports the theory that the machine was damaged way before it hit the recycler, because only someone who wanted to keep using the computer would care enough to do something like this. Probably it got dropped or smashed when it was still in use!

Think my warranty is still valid? I didn’t open the case myself.

Case Repair 101

Every single screw post on the top case was broken off. I removed them one at a time and marked where they came from.

Removing the screw posts from the screws took a lot of effort, but once it was done, I was also able to take a look at this giant dent on the back case. Some gentle heat and prying made this finally pop back straight after about ten minutes of work:

I had a lot of trouble getting the model cement into the cracks of the case. An additional problem is that my clamps really did not like to seat on the curvy TRS-80 case, so it was hard to hold things together while they dried.

In some places, I stitched the ends together with a soldering iron on very low temperature to help hold things together while it dried. The end result is not particularly pretty, but this was never going to be a full restoration with so many pieces missing. A better restoration would probably involve moulding new corners, or simply 3D-printing a whole new case. For now, I’ll be happy if it holds together well enough to be typed on.

When I had to reattach the broken-off posts to the top case, I first did a dry fit. Then I marked the orientation, applied a generous slathering of model glue to both sides, and put them back in place with the position markings lined up. This is much better than my usual tactic, which is to get both sides wet with glue and then forget exactly what orientation everything is in, then panic.

I also used way more cement than on previous projects, which I think made a big difference here. I’m reasonably happy with how I was able to restore the broken-off screw posts to the top case.

One of the posts was missing most of its guts, which made it impossible to repair. The remaining five will have to take on the brunt of the case load.

Since the back plate was missing, I went and found some pictures of other TRS-80s to figure out what is what. The power connector is, unsurprisingly, the one with the power switch next to it. The middle one is the composite video connector, and the outermost is “tape.”

I did order from JLC a new back plate to be printed based on the one in the aforementioned repository, and it showed up very quickly and looks great.

For that extra little smidge of safety, I also wrote with a Sharpie on the motherboard underneath the power port, indicating that it was indeed “power.”

Further inspection

Despite everything this poor computer has been through, the motherboard looks like it’s in pretty good condition. Maybe all the dirt and dust that’s usually in these things fell out through the giant hole in the case.

Although the Model 1 is a very normal-looking Z80 system with no exotic custom chips, the age of the construction means that there’s still a lot of unusual-looking stuff going on with this board, especially in the power-supply section. I can absolutely see why a lot of people swap the RAM out and then do a 5V-only conversion. I’ve never owned a MOSTEK-made Z80 before, either: to be honest, I didn’t even know they made them before I opened this sucker up.

Looking forward to coming back here in order to understand how they make video. I have wanted to do a character generator for a long time now.

Power Supply

One of the sticking points on rebuilding this model 1 TRS-80 was figuring out what power supply to use. No power supply came with this system, and used ones are very expensive after shipping since they consist mostly of a giant heavy brick. I didn’t want to spend a bunch of money on a power supply only to find out it was broken, but I needed some kind of power supply to find out if it was broken. Think I read a book about this kind of problem once.

Like a lot of systems of its era, the TRS-80 needs split voltages to run the DRAM. Although it’s certainly possible to convert it to 5V-only RAM and run an internal regulator, it’s probably not the best diagnostic process to be modifying a system while also trying to repair it.

Instead, I looked around and found this PSU build guide from Shock Risk. It uses a commonly available Triad F-241U transformer (which outputs 18VAC and 9VAC.) Transformers are oddly expensive when bought in single quantity: this one cost an eyewatering $36.

The original TRS-80 PSU provides ~20VDC which is regulated to 12VDC inside the computer, and 17VAC for rectifying and regulating into +5VDC and -5VDC inside the computer. This is my first time wiring up a mains transformer, so I’m glad someone went ahead and did all the hard work of figuring how to do it. I’m also glad they included photos, because I did not have enough confidence in myself to go solely off of the schematic.

Rectification for the “you left me plugged in” LED and the DC rail is done on the PCB, which doubles as a mount for the transformer into the case. It’s pretty straightforward, and just uses a pair of high-wattage 1n4001s. It took me a little bit of experimentation from my screw collection to determine that the threaded inserts in the case were M3 screws; the case manufacturer only included the screws for the lid.

Following the guide, I also sourced an identical Bud enclosure, but I also made sure to get a “DAC-13F” fused IEC power connector. Having a fuse is a good idea!

This was absolutely not the most economical approach to getting power into the Model 1. Probably the easiest and cheapest way would have been a 5V conversion with 4164s, but the power supply is a solid build where someone else has already figured out most of the snags, which I’m super grateful for. Hopefully I get a lot of use out of the Model 1 to justify it!

As for the case, I had a really great plan to use my knockoff not-a-Dremel to cut the hole for the IEC connector, thus avoiding me having to hand-drill like on the second ADAM power supply. That plan didn’t last long, partially because the not-a-Dremel’s wheels are too small to get a good plunge into the thick plastic, but also because of my relative inexperience with the thing. Maybe I should’ve used an angle grinder… anyway, I ended up drilling holes around the periphery with a power drill, and then cutting it out this time. Much faster.

When wiring the transformer, I had a lot of trouble. Initially, I wanted to use some spade connectors that fit perfectly on the tabs of the transformer. When I actually wired everything up and went to test fit it, however, it turned out that the spades were too long to fit. I love doing the same job twice, but worse the second time around!

After a lot of annoying pushing and fondling to get everything into the case, including breaking the legs off the LED and having to put a new one in, I was finally able to tuck everything together.

Getting the M3 screws that mount the PCB down were a bit of a pain. It’s just deep enough to make the screw fall off the driver as I’m lowering it into the case, and whatever material they were made out of is simply not magnetic. I ended up putting a bit of sticky tack on the head of the hex key.

Similarly, I used RTV to hold in the LED and the IEC connector, but I had left it in the garage in December weather and didn’t take my time to warm it back up properly. Winter cold made it take a really long time to cure, and it was really difficult to get out of the tube so I put it on too thin. Like painting in the winter, I’d stick this in a cup of warm water first next time.

That RTV also didn’t do a great job sealing the connector, since its natural stretchiness let the connector move around a lot when the cord is being plugged and unplugged. Not a good combination for mains power. I will be using the screw holes, like I should have in the first place.

Overall, I feel like this power supply build went fairly well. If I had to do it again, I would be tempted to try the RetroStack TRS-80 Model 1 power supply, which uses a somewhat smaller transformer and a very nice 3D printed case.

I plugged in the supply and tested the AC and DC voltages unloaded – they were high, of course, but seemed to be in the range of what I needed. Now, it was time to go onto making another cable.

Video cable

Here’s a fun fact: when the Model 1 came out in ‘77, it was extremely uncommon for television sets to have composite video input ports (and still not super common for small sets, for most of a decade afterward.)

The Model 1 has no RF modulator, so how did they connect it to a monitor? Tandy modified a common television set to have a composite input, and sold it as the TRS-80’s special monitor. What they’d actually done is take a hot-chassis television set, and modify it, making the TRS-80 itself power the opto-isolator that sends risk-free composite video into the set.

What this means is that the TRS-80 provides a +5V output alongside a luminance-only composite output. We’ll skip that +5V output and wire the rest into a standard composite video cable.

Conveniently, the composite video cable for the TRS-80 Model 1 is also a five-pin DIN, so I just grabbed the other half of the 2m MIDI cable I chopped up and soldered a yellow male RCA connector to the other end. This doesn’t produce an extremely long video cable, but 1 meter should be enough to reach a monitor on a desk for now.

To provide a little bit of strain relief, and also keep the cut-off ends of the unused conductors from shorting to anything, I once again put a glob of RTV in there before sealing up the connector. Surely if I keep trying it, eventually things will work out for me and the stinky toothpaste.

Does it work?

I put the motherboard back in the (beaten up, but now somewhat stronger) bottom case and applied spacers where I felt like they should go. This is almost certainly not correct, as I remember some of the spacers were doubled up, and I ended up with leftover ones, but it is good enough for a precarious test.

Admittedly, this is not the most ESD-safe environment, but a TRS-80 Model 2 was clogging the entire desk at the time, so I had to do what I could. You get it.

Surely, this completely battered computer won’t start properly. I bet I get a screen full of garbage or some kind of ominous screeching noise followed by smoke!

Oh. Well. Or it could just work. Maybe the keyboard is broken? I’ll hit enter.

Surely there has to be some problem with this that will keep me from entering a program.

A couple of the keys were pretty bad, but after some repeated pressing they came back to life. Frankly, I’m a little bit surprised: the ribbon joining the two boards didn’t look particularly good.

Dang. This computer might actually work. These things are tough.

Conclusion

This part of the project went really well. I had to build a lot of cables due to the TRS-80 Model 1’s pioneering nature, but it’s not like it was very complex stuff. I don’t mind a project that’s time consuming and productive; the ones where it’s time consuming and you never seem to make any progress are much more discouraging.

From doing the power supply, I learned a little bit about how to wire a transformer. I think now I would be much more confident debugging a linear power supply, or even building one for an oddball voltage. Maybe a Commodore 5VDC/9VAC one could be my next stop.

From building the composite video cable, I learned basically nothing, but I think it looks a lot nicer than my average cable. Starting with a pre-soldered DIN cable here (the MIDI cable) helped a whole lot, even if it is annoyingly short.

Case repair is always a bit of a crap-shoot. I’m glad I was able to find my quick-setting Tamiya, though it seems while I was working on this, the old-computer community started getting really interested in UV resin. Paired with some screen-door mesh, that might be a good way to reinforce the top case against future damage, although the giant holes will still remain.

Cracks aside, I’m not sure how much further I want to go with repairing the big holes in this old case. I could mould some new corners with packing tape and epoxy, or I could simply spend forty bucks and get a new one printed.

My next step will be working on that keyboard, and getting everything to look nice with the top case installed. I suspect I’ll want to start with figuring out how to solder the power LED back onto the motherboard: I wasn’t able to immediately guess the polarity with a continuity test to a known ground and +5V, but I can always poke around with a longer-legged LED to see which way it lights up.

Then, it might be nice to load some actual software on this sucker. I’ll need another 5-pin DIN…

Thanks for reading.

Repair Summary

Fault	Remedy	Caveats
Top case is shattered.	Fix broken posts with model cement	Unlikely to be a good long-term fix; screws will probably break it again as the plastic continues to shrink and embrittle.
Bottom case is shattered.	Bend cracked parts straight by hand, and then glue with model cement. Reinforce with soldering iron.	A big chunk of the case is still missing.
Port label backplate is missing.	Print a new one.
No power supply was provided.	Build one.	This power supply is big and heavy and kind of inconvenient to store, but it does work really well.
Power LED is broken off.	Not fixed at this time.
Several keys are broken off, and many key-switches are damaged.	Not fixed at this time.

Leaded Solder vs. The Crazy 77

2026-02-10T00:00:00+00:00

Things don’t always go to plan! When battling one of the most complex 8-bit home computers ever made, you can expect to run into some problems.

History

The Fujitsu FM-77 is the “second” series of FM-7 machines, which you could say makes it the grandson of the FM-8 (or a weird niece of the FM-11.) Like with the transition from the NEC PC-8001 to the PC-8801, Fujitsu moved from an all-in-one wedge computer design to a separate case-and-keyboard desktop computer design.

The same general design persists, with two 6809 CPUs, but Fujitsu has taken the opportunity to add a bunch of nice performance features like improved DMA, faster graphics display (thanks to sub-CPU cycle stealing,) and much more memory.

This particular unit is the FM-77AV2, which came a little bit later and offered much improved video quality. Most notably, it offers a 320x200 mode with 4096 simultaneous colours, with no palettes, which is pretty crazy for 1985.

Fujitsu kept the FM-77 line going for awhile after this, adding even more colours and even faster internal performance, but those machines cost an absolute fortune, so we’ll not be seeing them in the immediate future.

Background

Blog friend Sampson sent me this beleagured Fujitsu. He had done a bunch of testing and inspection on the machine already.

He reported that at least two things were wrong:

The analogue RGB video, sent from the JP21 port, did not work;
The computer itself didn’t work, either.

After several months of fighting with it, he was preparing to send it to recycling. Graciously, he instead decided to ship one of the densest imaginable personal computers to me to see if I could fix it.

First impressions

Like I said up above, this computer is friggin’ heavy. You don’t expect it, either, as the machine is not particularly large and has a plastic exterior. The most likely cause of this weight is the excessive amount of metal shielding:

The poor machine has been beaten around, with a lot of tabs broken off all the plastics, and a bunch of grease and dirt clinging to the interior.

As soon as I opened the computer, I found some ugly organic-looking gunk on the top of the shields. My first guess was that a lithium clock battery had exploded, which meant that the faults were likely to be corrosion.

Inside the card cage, I found two cards of unknown purpose.

The first card has a bunch of stuff on it, plus a mini-DIN-4 connector that goes to a rotting cable with a DIN end on it.

I’m not sure what it is; a search of the apparent part number (Fuijtsu D330-0001-T014/01) did not turn anything up. Maybe you know. My best guess is that this was for a hand scanner because of all the latches and counters. At the extreme end, it could possibly be a mouse, but it seems like a lot of logic for the latter.

The other card is also a bit of a mystery; it’s much smaller, and it has a delay line on it as well as a small amount of MB81464 RAM. That card part number (Fujitsu D198-0001-0101, and D330-0001-T114/01) also didn’t turn up anything. Those numbers are very close to each other, which makes me wonder if these are meant to be companions. Fujitsu does tend to make “two card” solutions because they keep making their expansion bays too small.

I checked their tantalum bypass caps for shorts, and found none. I noticed that a third sub-board underneath the shield had a zip-tied Sanyo “Laser Lithium” battery on it, which had not appeared to leak and was unplugged. Although I’ve never seen one of these leak, mostly because of their excessive potting, I cut the zip-ties and disposed of the battery just to be on the safe side.

Beneath the cards were more chunks of black stuff all over the interior, which is also consistent with a lithium battery failure (they like to explode and throw these all over the place.) But I couldn’t see any other lithium batteries in the area!

The floppy/sound board seemed to take a decent whack of the gunk, but it didn’t appear to get directly onto any parts. Or so I thought.

Like a lot of other Japanese machines, many of the metal surfaces, including the port shields, were covered in white powder that I thought might be leftover rework flux or even humidity damage. This goes for the card connectors as well.

One port had a bit of green gunk, which I couldn’t immediately identify. Maybe it is what the white gunk used to be before it dried.

I could also find some green gunk on the legs of some of the very small-value ceramic bypass caps.

At the motherboard, I noticed that someone had swapped CPUs: there was a 6309 installed into the slot closest to the front, and the original 6809 at the rear. We know from the FM-8 adventure that the 6309 was a common CPU upgrade to get all the cool extra features (like more registers!) that the 6809 does not provide.

That rear 6809 had been monkeyed with, as it was sitting cockeyed into the slot, and had heavily bent legs, but it appeared to still be making good contact into its socket.

Whatever did explode, the black chunks seemed to have fallen around the sub-CPU area. Unfortunately, the computer had been moved quite a bit in shipping, so it was hard to figure out an exact origin.

The computer is built up in layers, with the top RF shield also mounting part of the card cage, the power supply, and both floppy drives. It’s a real project to get inside one of these – bring several ziploc bags to keep all the screws in. Naturally, I immediately punched the end of the power switch off when I was trying to wiggle the power supply cable free, and that broken-off end went flying under my desk, never to be seen again.

I wanted to look at the power supply to see how hard replacing the switch was, and to check for damage. Unfortunately, the case is soldered shut, so I decided that I did not actually care enough to go deeper inside. Why would you do this, Fujitsu?

Once the motherboard was exposed, I set about reading the socketed UV(!) EPROMs that were on the board.I have a Python script lying around for extracting 8x8 tiles from BIOS ROMs (fonts, etc) so I pulled the ROMs, dumped them, and looked around for strings and tiles. Looked like at least this font was retrievable intact, so the larger ROM was probably fine:

Oddly, there were at least two ROMs that seemed to contain font tiles. Maybe something special with kana.

I was very happy to see that, unlike the NEC machines of the era, Fujitsu has very thick, clear, and easy-to-follow traces. Thank you to whoever did this board layout.

This seemingly-proprietary MB15021 video DAC IC¹ has a little bit of corrosion damage to the gold strap on the top. Not being familiar with ceramic ICs, I wasn’t sure if that was actually a functional element of the chip, but it was definitely suspicious as being the cause of the analogue video problems.

Not seeing any particularly dramatic corrosion on the top side of the motherboard outside of the DAC, I wanted to look at the underside to see if anything had been pooling down there and wicking up the legs.

Removing the motherboard from the case is another project, because there’s a bunch of small-gauge cable running everywhere that is not loomed or braided together very well, and there are insufficient channels in which to place it. I ended up cutting a lot of zipties, and hoping that I remembered where they went when it came time to put the computer back together.

I lost count of how many screws and shields I had to remove from this thing in order to get the motherboard out. No wonder it’s so damn heavy!

Surprisingly, the underside of the motherboard looked perfectly clean. I took the board over to the sink and used the boar hair brush along with mild dish soap to clean off all of the grease. Although the brush kept coming back from the board pitch black, I made some really good progress even on the first pass.

For the white gunk on the underside, I first tried to use isopropyl alcohol and a water flush, but the white gunk would keep coming back as soon as it dried.

For the metalwork, I used Spray Nine all-purpose cleaner and a firm toothbrush, which dislodged most of the ugly stuff. While doing this, I found out that the gunk near the card cage door was actually some kind of sticky thick clear-brown substance – not flux, not battery leakage. No idea what this was.

Now that I was reasonably happy there was no catastrophic corrosion damage, I wanted to try and power on the computer and figure out what wasn’t working.

Beep Beep I’m A JP21

In what seems like a betrayal of the ideals of the era, the FM-77 doesn’t have a Japanese 15-pin analogue RGB video port, or even a DIN8 one for digital RGB. Like some MSXes and MSX2s, it has a JP21 RGB port instead.

JP21 looks like the good old SCART connector, and in fact it mechanically is, but the pinout is significantly different. Since I didn’t have a JP21 to VGA adapter on hand, I decided to make one up using scraps I had on hand.

Unlike VGA and like SCART, it appears JP21 sends composite sync, where the horizontal and vertical sync signals are combined into one signal. This is sort of unusual for a computer monitor, but obviously more common for television.

Although I know my NEC MultiSync LCD can process a combined sync on the horizontal sync pin, a lot of other monitors can’t. Why not do things the right way and split them up if they’re going into a “VGA” sink?

I used the very popular (and surprisingly expensive) Texas Instruments LM1881 sync separator to split this combined composite sync signal into horizontal and vertical syncs, then fed them to a VGA port along with the colour data. Realistically, as this is a 15kHz signal, it’s not “really VGA” – but I already had the VGA footprint on hand from other Japanese computer video-out projects, the cables are cheap, and I had a bunch of leftover (also expensive) connectors to boot.

So how did it go? Well, considering this was my only working computer with JP21, you’re about to find out.

Test Fire One

I plugged the motherboard in (without the floppy board connected) and fired it up. My LCD monitor, connected through the JP21 adapter, did not seem to find a signal and would not come out of sleep mode. When I applied the logic probe to the test point I had marked as “composite-sync,” there was no activity, just constant high.

However, it seemed like address bus stuff was happening on both the main 6309 and the 68B09E sub-CPU. The BIOS ROM closest to the main CPU was getting both output-enabled and chip-selected periodically. Using my logic probe, I poked at a few Fujitsu-branded buffers in the area of corrosion damage, but didn’t see anything particularly obvious.

I connected the PVM to what I thought was the composite-video RCA jack in the back, but nothing was produced. I would see a dim flash at power-on indicating a DC offset, but no sync latch or output. Later, I found out that the text on the back of the machine actually said “audio output.”

On the advice of Soji-san, I checked the hsync and vsync pins on the digital RGB connector on the back. This connector is a very pleasing-looking female DE9. Supposedly, v-sync was to be seen on pin 9 and h-sync on pin 8. And indeed I saw a lot of activity on all four lower pins, which told me that something is happening – the computer is generating some kind of video.

To figure out what was going on with the digital RGB connector, I decided to make a simple digital RGB adapter. Like the one on the PC-8801mkII, this adapter just steps down the TTL-level colour signals to something much lower that a VGA monitor would prefer, using 150Ω resistors. Here is the GitHub link to the FM77AV2 digital RGB to VGA adapter, with Gerbers so you can order your own.

I’d have a better picture, but I’ve misplaced the actual board in the months since working on this computer. You know how it is.

At first, I was going to make this adapter using a screw-terminal hood, like the adapter on the X1turbo, but I couldn’t find my bin of VGA cable cutoffs. Like most of my life, I was already in the process of ordering some boards, so I decided to pay JLCPCB a few dollars and set the machine aside while I waited for the adapter PCB to arrive.

Test Fire Two

When the digital-RGB adapter board arrived, I quickly threw it together – with so few parts, I had everything on hand. As soon as the machine was powered on, the NEC 1970NX monitor I use on my bench lit up and latched onto the signal.

Holy crap, we have a working computer. So what’s actually wrong with this thing?

JP21 Gun Salute

At first, I assumed the problem was with my homemade JP21 adapter. After all, I don’t really know what I’m doing, and it seems more likely that the people at Fujitsu did know what they were doing.

I realized that the logic probe was probably the wrong thing to use to look for the 1Vpp composite sync signal, and reached for my scope. This would also tell me if the signal was getting stepped on, malformed, or otherwise just too weird for the monitor to accept.

To start out, I scoped the sync and blue pins at the JP21 connector. Both of those pins produced a pleasing square wave with nice sharp edges. Output was coming out of the Fujitsu, so what did I do wrong in adapting it?

Confused, I buzzed out the SCART male-male cable I had grabbed to use with this adapter. Being a newbie to SCART, I did not realize that a seemingly “straight-through” cable actually crossed over a bunch of signals for daisy-chaining purposes. I made some bodges to try and put those signals back in the right place, and soon had a nasty board full of junky soldering that still did not work.

At this point, I started getting confused about the various bodges I had made, and wondering if I had gotten the JP21 pinout upside down or reversed. Power to the LM1881 seemed quite low, at around 300mV, so I bodged a USB cable directly into it to provide that power. Now, the monitor would wake up, claim “out of range” a few times, and then go to “no signal” and turn itself off. Still, that’s progress.

I decided I would merge what I had done into a version-two board (with configurable jumpers!) and order it. I built that board, and it still didn’t work. I resolved to chase the video output chain from the FM77 to figure out what was broken. Then, I decided that sounded too much like work, and I already had “some” working video, so I moved on to more fun things.

No Re-Assemble, Solderie

At this point, I figured it would be a good idea to see if the machine worked when reassembled. Unfortunately, as soon as I re-added the “FDC/Sound” board, which is required for the front panel, the computer stopped generating working video on startup. The fan still ran, and it seemed like it was doing something, but the monitor would never wake up on digital RGB.

Because I had been testing as I re-assembled the machine, I started unplugging cables until it worked again. The culprit was the “CON 3-13” connector, a 26-pin ribbon cable going into the front-right of the FDC/Sound board. When that cable was unplugged, the computer would start up to BASIC, and when it was plugged in, the computer would not put anything on the screen.

Just to be sure the computer wasn’t blocking while waiting for it, I plugged in a floppy drive to the FDC board. The floppy drive seeked to track 0 on startup, but nothing else changed.

I looked in the FM-77 schematics, but there was no “CON 3-13.” There was a 26-pin connector going to/from the FDC board, called “CON 1-12.” And the signals appeared to be mostly joystick-related, which made sense because the ribbon cable is very close to the front-mounted joystick ports.

My assumption was that, when provided with one of these signals, something on the FDC board was holding up the startup sequence. An obvious first candidate was YMIRQ, which appeared to be an interrupt request line issued by the YM2203 when its internal timers fired.

I decided that I would pull CON 1-12 out of the plug and jump all of the suspicious lines across with Dupont jumper wires. That way, I could pull them out one at a time, and when the computer started working again, I’d know what signal it was that was holding the computer up.

Pulling YMIRQ didn’t do anything, to my surprise. Working down the list, I finally pulled RESETB – and the computer came alive, but everything on the sub-board still stayed stuck in reset! Something on the FDC/SOUND board was holding up reset!

Reset My Head

Fortunately, the schematics told me which parts of the sub-board consumed the RESETB signal. Unfortunately, it was virtually all of them: eleven chips, ranging in complexity from a simple 7474 to the YM2203 to the big MB88551-701N microcontroller QFP.

I wasn’t sure how to tell which chip was driving the erroneous signal. Maybe there’s some kind of test equipment for this specific task? I dimly remember a tool called a “current tracer” being mentioned from YouTube. Either way, I didn’t have it, so I did the next best thing, and started desoldering 74 logic from the board to test in my TL866. This board has generous pads, slightly oversized through-holes, and a very thick solder mask, so I thankfully didn’t have to worry too much about pulling pads and traces.

Every piece of 74 logic passed in my TL866’s Logic Test, so I started moving onto the more complex chips. Everything involved in reset with a DIP was desoldered from the board, a socket installed, and then tested with the chip removed but RESETB attached to the FDC/Sound board. It still remained stuck.

Finally, I came to the part I was dreading: the surface-mount MB88551 QFP. I determined that this must be the keyboard controller, based on the signals going into it on the schematic. Because I didn’t want to desolder it, I simply cut the trace leading to its reset pin and fired the machine up. It ran!

Great – a custom microcontroller with mask ROM has a glitchy reset pin and is driving the reset signal for the entire computer. I love this. Upon reading the relevant schematic, I found out that the MB88551 microcontroller’s RESET pin could be configured as either an output or an input. Surely the original machine had it configured as an input, and something had gone wrong inside the package, maybe from whatever corrosive nastiness leaked onto this pin in the past.

Now recall this earlier picture where a bunch of black likely-corrosive death was lying right next to the 88551:

That really gronky looking pin with the via very close to its pad? That’s RESETB, baby. Something’s gotten in there.

I cleaned around the area to make sure it wasn’t shorting to any adjacent pins, but it didn’t seem to be. I am still not confident enough in hot air to remove this part entirely.

So now I was in a bit of a pickle. With the 88551’s RESETB signal detached from the system, I could now start the computer up. Unfortunately, without the keyboard controller, some oddness is to be expected. For instance, the kana and caps lights were lit all the time, when it seemed like they should extinguish shortly after startup:

The keyboard also was unlikely to work, even if I had one, which provided a further impediment.

I pulled the 88551’s reset line up to +5V with a bodged-on 33kΩ resistor, but there was no difference. It still stayed annoyingly low. The same happened with a 2.2kΩ resistor, showing that whatever output circuitry was driving reset low on the micro was pretty strong, and fighting it was more likely to damage the microcontroller than fix things.

I was ready to give up, but then I tried again with 560Ω. That moved it to +2V, which is in the right direction. I knew that the “high” switching voltage, Vih, for CMOS was roughly 2/3 VCC, so I needed to hit something around at least 3.3V? Let’s see where we get to with something a little more forceful…

Pulling it up with a stronger 75Ω seemed to make things less consistent. I was starting to see a weird white screen at startup, or garbled video, but the kana and caps LEDs were turning off after startup, indicating that the 88551 had come out of reset and was starting to slavishly obey its internal programming. Occasionally, the machine would crash and stop displaying video (not even sync) or seem to restart BASIC. Sometimes during this no-video tantrum, I’d see the kana and caps LEDs flickering very quickly.

I checked for shorts and bridges and unusually high resistances from my crappy bodgework, but found none.

Looking at the scope, the level at the reset pin hovered sort of close to 3.2-3.6V, which seemed like it could potentially be a little ambiguous for “high” or “low” input levels, and digital logic is renowned for its dislike of hovering around “I dunno.” I swapped my pull-up out for a much stronger 33Ω resistor, as that’s what came out of the pile of resistors first, and the symptoms seemed to, if anything, get worse, although the reset level did rise to around 3.9-4.2V, which is pretty decisively “high” in my book. However, the glitchiness didn’t really go away, with only about 1 in every 3 startups causing the front panel LEDs to extinguish. And I had no keyboard – whether IR or wired – to test it with.

I now suspected that I had cracked the “make it not reset anymore” code, but my timing needed work. My guess was that my little hack circuit wasn’t holding the 88551 in reset long enough, or not resetting it properly, which meant that it was waking up in a bad state. Either it was crashing the sub-CPU (which caused the crazy graphics and reset?) or just misbehaving in general (which caused the bad LED behaviour.)

The MB88551 seems to do a whole lot inside the system that isn’t strictly related to keyboard shenanigans. According to the relevant schematic, it is also related to real-time clock, and can drive both the main and sub-CPU data buses. The firmware on it is likely to be pretty complicated!

Keybodging

I didn’t want to throw out the entire computer, sick as it was, for the sake of a single keyboard controller. Hell, it was on a sub-board, and almost all of the parts except the keyboard controller were fine.

I sat down with a notepad, and came up with some ideas:

Remove the 88551 entirely, and try to black-box duplicate its function with an RPi Pico or something, without an intimate knowledge of its ROM function, a working reference FM77AV2, or even a keyboard to test against;
Remove the 88551 and send it to someone to be decapped, so at least we knew what was in the ROM, then use the 88551 datasheet to write a disassembler, reverse-engineer the disassembled ROM, and then port the whole mess to an entirely new floppy board using a different microcontroller;
Give up on having a keyboard and only play games that use the joystick;
Strip the machine for parts;
Develop a better reset circuit for the MB88551 alone, using what I learned from using the 33Ω resistor to force reset.

Although the first two ideas sound like the most “fun,” the last one seems to be the easiest next step. My guess was that using the resistor alone was not working because it didn’t hold the chip in reset long enough to get its brains in order. I didn’t really understand how a “timed” circuit like this should work, so I asked a friend. Chartreuse showed me a few different circuits that might work, including this one from his 6800 homebrew:

This design uses a 555 timer chip to hold an active-low reset signal at power-on for a little while, and use an NPN transistor to drive the actual reset line. I plan to build something like this, but I’m also still kicking around some of the other ideas.

I’m not confident that this bodge would be safe long-term, either: there’s a good chance that whatever is driving this signal is going to get really mad that it’s being forced up with a very strong resistor. Every time I start thinking about doing it, I get cold feet.

If you’re willing to decap and read out this ROM, get in touch – I’ll send you the whole floppy board.

Inconclusion

For now, the FM-77AV2 sits on my storage shelf. It’s been there for over a year. Its bulk and complexity makes it too annoying to leave out on a workbench, and I’ve moved onto other machines.

Although I have no idea why the analogue video output is not working, I suspect it may be related to the video DAC (even though I reported blue as being present, I’m not convinced that I remembered this correctly.)

I have recently just found another FM-77AV2, in order to try swapping parts over to resuscitate that part of the machine. They’re somewhat expensive (as are most Fujitsu 8-bit adjacent machines) but I think that it will be a worthwhile purchase if it helps me solve this mystery.

I still don’t have a keyboard, which I suspect might make reimplementing the keyboard controller a little bit more difficult. I have built Soji-san’s IR keyboard adapter (pictured below) but I think doing this as a hard-wired keyboard will be the easiest place to start for now.

While I’m waiting for the second FM77 to arrive, I have started building an implementation of this PS/2-to-FM77 keyboard adapter PCB. I am very grateful to everyone involved to making stuff.

Releasing this post is both a way for me to say “hey, sometimes this stuff is hard,” but also to motivate myself with ideas from the community about how to fix this problem. Like I said, it’s been on the shelf for a long time.

If this is an endemic problem to the 88551 mask ROM microcontroller, and not just ESD or someone spilling a bunch of bleach into a computer in storage, it will probably affect a lot of other systems in the future – not just my toy computers. In that situation, it would be essential to figure out a method to start documenting these mask ROMs and build equivalent parts before more of them become unusable.

Fujitsu of this era do not have a particularly good reputation in the arcade community because of other mysterious chip failures (reported to be bond wire corrosion or other package issues leading to failure – please comment if you know more,) and it would be sad to not have a substitute for these “custom” chips in order to keep FM-77s on the road.

Thanks for reading!

Repair Summary

Fault	Remedy	Caveats
System does not produce legible analogue video.	No fix yet.
System does not produce any video.	Cut stuck reset line on keyboard controller.	No fix for keyboard controller yet.

The MB15021 video palette DAC is also used in the regular FM-7, so maybe I can try a swap. ↩

Controlling the Wizzard

2026-01-20T00:00:00+00:00

Remember back when I cloned the VTech CreatiVision/Dick Smith Wizzard, Australia’s almost-favourite video game system that’s also a computer? That was a fun time. Now for the really fun part of the project: trying to get the controller to work.

Overview

For those of you unfamiliar with the structure of the CreatiVision, which includes virtually everyone reading this, let’s talk about the keyboard.

The keyboard on the CreatiVision is implemented by two large membrane matrices on the individual controllers. You can tell right away that it’s a lot denser than the “number pad” on the ColecoVision or Intellivision controllers, and it implements a full-ish 48-key keyboard plus two joysticks and four fire buttons.

By seating both controllers in the console, you can use it as a very unsatisfying keyboard.

Dick Smith (and probably VTech) also sold an aftermarket keyboard that was of generally higher tactility and was “permanently” installed, making it easier to write things that used both the keyboard and paddles.

Previous version

It’s been quite a while since I made any updates on this project, so it’s worth going over what was accomplished in the previous CreatiVision clone article back in 2023.

In that project, I used some old VTech schematics to build a single-board computer version of the CreatiVision. Because of the complexity of the keyboard, I decided to… not do it yet. As a result, I ended up with a working CreatiVision that I couldn’t actually play games on. You could only watch (and hear) the attract mode of Sonic Invader.

I called this clone DerivaVision, because it’s a derivative work and not creative at all!

In theory, my board was compatible with real CreatiVision controllers and keyboards, but I didn’t have any. The logical follow-up project would be to build an active converter which would adapt common interfaces, such as more readily-available game controllers and keyboards, to the CreatiVision’s parallel-matrix layout.

Version 1 of the adapter

Since I would need to poll the “new” devices and convert their signals to the CreatiVision’s expectations, I would need a microcontroller of some kind. At the time, I hadn’t worked with the Raspberry Pi Pico much, but I liked how fast it was, and I would need something fast to respond to the CreatiVision’s demands for joystick data in time.

Keyboards are read through the 6821 PIA on the CreatiVision’s motherboard. The specifics of interacting with them are all abstracted away by calls to the BIOS, which surely every well-behaved game will use with no exceptions.

Much like on the ColecoVision, the keyboard consists of multiple “select” lines. When they are asserted, the pins correspond to different signals. It’s essentially a keyboard matrix read, but with a very unconventional matrix.

One thing I was worried about was interfacing the 3.3-volt Pico with a 5-volt system. For the sake of protecting the chip from its host machine, I chose a 74LVC245, which is an octal bus buffer that is capable of level translation.

Remarkably, using a 74LVC245 was cheaper than buying all the resistors and resistor networks to form a voltage divider. It even comes in DIP, which helps vibe with the rest of the system.

My plan after version one is complete is to integrate all of this into the main board of the DerivaVision. Maybe I can even get rid of the surprisingly expensive 6821 PIA in the process, along with the R-C snubbers that probably aren’t necessary when the CreatiVision CPU’s just talking to another microcontroller.

The sources

As you can see from the diagram above, I chose a PS/2 keyboard, and SNES controller. This is mostly because I already had the connectors on hand: feel free to mock me for my choices.

The biggest drawback of the SNES controller is the sheer size of the connector: it takes up a lot of board room, so much so that it’s not really practical to have 2 controllers plugged in. We can fix that later.

The biggest drawback of a PS/2 keyboard is that it is now becoming harder to find PS/2 keyboards in any random thrift store. Still, I just built a new (to me) Ryzen computer, and that fancy new motherboard had a PS/2 port. If it’s good enough for AMD…

The design

On the original CreatiVision, the controllers connect internally using a 0.1”-spacing pin header. I kept that pin header arrangement and tried to eyeball the positions, so that an original controller could still be used.

For my adapter, I ended up designing a vertical “card” that plugged into the pin sockets on the board using pin headers. This connector is cheap and easy to source, although it has a lot of drawbacks – it’s really easy to bend a pin, or insert the card one pin off, for instance.

Of course, the Pico needs power, and unfortunately the CreatiVision matrix connector doesn’t provide it (or ground.) To pick up +5V power and ground, I ended up re-using the logic-probe test hooks that were already present on the main board and running a soldered hook from the Pico card to the DerivaVision main board. To help prevent fraying from constant insertion and removal during testing, I globbed a bit of hot glue onto the wires to hold them still.

I’m mostly happy with this layout: it’s got very few parts, and the card is an interesting shape, which adds visual appeal.

Hardware assembly

Once it arrived, I was able to assemble it using a right-angle pin header and two 10-pin “Arduino shield” stacking connectors from Amazon. A lot of annoying fiddling happened, and the board wobbles around a bit, but I think it looks pretty good for a prototype.

Please ignore all the mess on my desk, 2023 was one hell of a year. Honestly, it hasn’t gotten a lot easier since.

As you can see from this artsy shot, I got lucky and the SNES port just barely clears the capacitor here. Like my grandpa used to say, it’s better to be lucky than good.

It’s a lot of fun to pull this “card” in and out of the board, but I ended up leaving it installed into the DerivaVision, and using the debug pins on the Pico to flash it.

Firmware

The downside of making a microcontroller-based thing is that you have to write software for it. My day job is writing software, and although it’s not embedded software, I much prefer hitting things with a screwdriver or a hot chunk of metal to relax instead of chasing down linker errors.

Starting Out

I’d had a lot of hairballs before on previous Pico projects setting them up. Primarily, I had trouble making a CMake makefile that I was happy with. It seems like the official guidance for Pico projects is to either stick them all under a central root in your filesystem (so you can navigate upward to find the SDK,) or to write some very complicated makefiles.

When I was looking at polpo’s picogus code, I noticed that his CMake makefile had been automatically generated. After a quick search, I found the pico-project-generator repository managed by Raspberry Pi themselves. After installing tkinter¹ (through the python-tk package in Homebrew) I was able to create a new project.

Overall, this process was fairly smooth, but I would have preferred that it set up .gitignore for the build directory. The default setup spews a bunch of object files and CMake caches all over the filesystem, which I definitely didn’t want to put into Git.

I had some trouble getting output from stdio to go to the USB port; it turns out that the CMakeFiles I had copied had turned off stdio-over-USB:

pico_enable_stdio_usb(creativision-gamepad-keyboard-v1 0)

Changing that to 1 made it appear in /dev/ and connection was easy:

% screen /dev/tty.usbmodem101 115200

Now I could see the results of my debug puts! That’s almost as good as having a real debugger.

SNES Controller

I had a lot of problems reading in the SNES shift register, which was very surprising as I’d pulled it off many times on other microcontrollers. Hitting “B,” the first button in the register, would set all the other buttons down, but not any of the other buttons.

One thing I forgot to do is actually tell the Pico which pins are outputs. After an hour of so of frustrated poking around, I grabbed the logic probe and discovered that the clock and latch pins were doing absolutely nothing. After some more frustrated poking around, I realized that I forgot to call gpio_init(...) on any of the output pins, which meant that they would just not produce an output when asked to do so.

void loop() {
    pad->update();

    SnesButtonState state = pad->get();
    
    if(state.buttons[SNES_B]) {
        puts("Button B is down");
    }
    if(state.buttons[SNES_A]) {
        puts("Button A is down");
    }
    // more buttons down here

With that solved, I was now able to read the SNES controller. I did consider implementing a “just-pressed” state, but the CreatiVision doesn’t have a facility to care about that, and will handle the unpressed -> pressed transition in software.

Getting the SNES pad to work was, in my mind, the “minimum viable” version of this project. Before I went too far down a rabbit hole adding PS/2 keyboard support, I wanted to check to see if I could actually output the joystick info all the way to the CreatiVision first.

Plus, I didn’t have any cartridges that used the keyboard…

Sticking Joy to the CreatiVision

This was a bit of a puzzle until I went for a drive and thought about it. Scouter3d from the CreatiVemu forums had posted a great thread about making an Atari 2600 joystick to CreatiVision adapter, and helpfully included the entire decoded matrix. The only problem was that I was confused by the explanation of how the matrix worked.

On the left controller Pin 1 to Pin 8 are connected to Pin 9 or/and Pin 10 when a key is pressed or the joystick moved…

On the left controller, pin 9 of the joystick connector is is PA3 on the 6821. I was initially not sure how to represent the state of “being connected,” but after my drive, it made more sense. Looking at the schematic for the CreatiVision clone, you can see that these lines are pulled up by 10kΩ resistors. If nothing is driving the lines they will forever be high, which the software calling the 6821 will understand as “not pressed.”

So, my theory was that the process went something like this:

The software running on the CreatiVision asserts PA0..PA3 depending on what part of the keyboard matrix it wants to scan.
The software checks to see which pins go low when this happens. These are the “pressed” keys. For example, if the CreatiVision is scanning PA3 (pin 9) at the moment, and it sees that pin 6 is also low, it interprets this as a “left joystick, moving right” action.
The CreatiVision then proceeds to change the matrix by asserting a different combination of PA0..PA3 and repeats the previous steps.

If this was the case, then I needed some way to react really quickly (faster than the 6502 could read it back) to PA0..PA3 being changed, and to bring those pins on the matrix low as appropriate.

For my first draft, I didn’t do anything fancy. Speed was unlikely to be a problem, considering the Pico is a 132MHz future computer shrieking at a 2MHz 6502 through a 6821 peripheral interface.

Interrupts might disrupt the timing on my reading of the joystick or the PS/2 keyboard, and the Pico PIO accelerator, while a slick solution to this exact class of problem, seemed like a lot of extra hassle.

So I just wrote the simplest, dumbest code I could think of. I constantly check the “row select” pins and then remember which row the Creativision is trying to look at.

I store a 4 x 16-bit (unsigned short) “current keyboard matrix” array. Depending on which row I last saw the Creativision asking for, I send the corresponding entry of this array onto the 6821’s inputs using gpio_put_masked². The pins that are pushed go low on this bitmask, and the CreatiVision looks at this and goes “hmm, yes, the left fire button is pressed.”

That way, I only need to remember which bit masks are set by a given key (in this case the SNES buttons) and then set those bit masks when I find out the button has been pushed or lifted.

My first run didn’t work: I had forgotten to hook the +5V and GND jumper wires to the board, so the Pico was not getting any power. After that was done, it still didn’t work.

How Do You Play Games, Anyway?

I went to find a manual for Sonic Invader, and realized I had to hit RESET on the system before I could get out of the attract mode and choose which game mode I wanted to play. Ah, old school games. In MAME, pushing the key “Z” started the game, but since I don’t have an overlay, that was momentarily beyond me as to what function that exactly was. That also didn’t work on my controller adapter, but at least now I knew I was in the right place in the game to accept input.

During this period, I was turning the system off, pulling the board out of the system, and flashing it with a USB cable. This was very frustrating, especially since I was debugging the matrix at the same time. Eventually, I realized I was too far ahead of myself, and I needed to build up a base of confidence. I had to go even smaller than emulating a single button!

To make sure I had everything right on the Creativision side, I made up a little test probe that consisted of two wires and a push button. With this, I would be able to emulate pressing a specific keyboard button, and also eliminate all of the complex functionality that was going on in my controller adapter. No sense worrying about my code and bringing out the logic analyzer if it turns out the junkyard 6821 I put in doesn’t work.

I knew from playing with MAME that all four fire buttons (each controller’s “left” and “right” triggers) would advance the “game mode” counter when the game was in the post-reset phase. All I had to do was get one of those four buttons to work. Easy, right?

After poking around with my homemade “button probe” while the system was running, I was able to isolate a pair of signals that sent a fire button: PA3 shorted to “pin 8” on my J1 header. This seemed to roughly correspond to “pin 3 + pin 2,” or “Fire Left (Right Joystick),” on the spreadsheet. It was at this point that I realized the spreadsheet had been counting from the other end of the connector for “pin 1” and would need to be inverted.

I should have built this little test probe in the first place; a lesson for next time.

After that, it was back to the Pico firmware, now that I knew what pair of signals I needed to send exactly. Turns out that I made a lot of really stupid errors with bit math in the firmware, and I had no end of trouble trying to get it to work at all. Turns out that – just like when I was trying to read the SNES joypad a few paragraphs ago – I once again forgot to do gpio_init before trying to feed any GPIO outputs, so nothing was ever coming out of the Pico.

Now that I knew the Pico was sending stuff, it was time to figure out why the system wasn’t receiving it. I put the Pico on the scope and found that… something was driving the Pico’s outputs, even when the Pico wasn’t?

As an aside, probing this thing is really annoying. I ended up laying the whole board on one lengthwise end, and let the cartridge hold the whole thing up like a bicycle kickstand. Precarious debugging? In my Leaded Solder post?

Get Off My Bus

After an evening of struggle trying to figure out why the Pico wasn’t talking to the CreatiVision, I looked at the schematic and had a terrible realization. Those 74LVC245 buffers which I had used for level translation between the 3.3V Pico and the 5V CreatiVision? Turns out I had the DIR pin backward.

When the DIR pin on the 74LVC245 is high, signals are buffered from the “A” side to the “B” side. I had the Pico on the “B” side, and the DIR pin was high, so the 74LVC245 was constantly trying to drive the Pico’s outputs while the Pico was also trying to drive them. Bus fight!! Not great for the Pico, but boy is that little chip tough. I slapped my forehead and quickly bodged it to work.

Remarkably, I actually thought ahead and left a jumper for the DIR signal on the board. Cutting that jumper and bodge-wiring DIR to ground was easy. Now, all of a sudden, it was driving the fire button super aggressively, all the time!

After cleaning up some more of my matrix math (and removing some debugging code I added in a sleep-deprived state) I was able to get the SNES pad to send a “fire button” signal all the way into the CreatiVision. The game mode advanced to “2.”

Success!

More Joy, Less Schtick

I was all ready to do some directional pad work, but first I had to make all four fire buttons work. For some reason, only the ones connected to PA0 and PA1 seemed to be reliably responsive.

Out of an abundance of paranoia, I set the code to flash the LED whenever it was scanning a certain row of the matrix. For PA0, the light was flashing very rapidly. For PA1, the light was flashing slightly less rapidly. By the time I got to PA2… it wasn’t flashing at all.

I began to suspect a timing problem. After putting it on the scope, I could see all four matrix pins were getting asserted at 60Hz. That’s a pretty tight window for the matrix scan. Eventually, I remembered that I had left a debug printf inside the “row changed” code… a debug printf that blocked the CPU while it was getting burped out onto the UART that I wasn’t even using!

Oops. After fixing that, all four fire buttons worked properly, although I was not sure whose fire buttons they really were.

At this point, I was also able to put together a “Z” button press, so I could start Sonic Invader. Unfortunately, the game wasn’t that enjoyable the first time. Things seemed laggy. Sometimes it would smear inputs into the next matrix, or feel like it was “dropping” my inputs, so I rewrote matrix scanning to use falling-edge GPIO interrupts instead of polling, and that seemed to make things better. Probably this is what I should have done in the first place, but sometimes you have to make bad decisions to get to a good place.

Directions were the next challenge, specifically diagonals. The CreatiVision actually has a very unusual (by modern standards) joystick – the membrane that it pushes underneath actually represents a 16-way joystick, whereas the SNES controller is only 8-way. Those of you who are better with math than I am will immediately recognize a problem.

Because the CreatiVision controller is finer grained than the SNES pad, we can immediately see that we can only directly map to eight of those 16 directions. All of the 22.5-degree angles (e.g. NNW) are impossible to make with the SNES’s directional pad. As a result, this is not the most authentic controller adapter, and if any games are dependent on precision directional control, they won’t play as well on this adapter.

I decided that this was probably sufficient. If someone gets really upset about it, they can always make a version that uses a PlayStation analogue controller or some other analogue-stick-having thing.

Some more hacking-up of code got me to a point where the d-pad was working in at least the “left” and “right” directions. Sonic Invader didn’t give me much opportunity to test the others.

Now at long last, we have a working one-player controller adapter for the CreatiVision clone. That has one working fire button, one start button, and two directions. Not exactly the full suite of capabilities, but a lot more than “absolutely no way to input anything,” which is what we had before.

In order to get the keyboard working, though, and help nail down the last few oddities in my direction logic, I’d need to get or write some keyboard test software. With test software, I can make sure that the CreatiVision software is actually reading the key that I think I’m sending. That’s what we’ll do in the next article about the DerivaVision, which hopefully will take less than several years to arrive. Thanks for reading!

pico-project-generator has many command-line options and it seems to prefer that you use them. However, even if you don’t use the --gui option on launch, it will still crash because tkinter isn’t installed. Since I had already used the bandwidth and disk space to install it, I decided to go the easy way out and use the GUI this time. Like all tools of this nature, it was annoying enough to get running that it didn’t save me any time. I probably won’t use this generator anymore now that I have a working project; I’ll just copy the repo contents and gut the source code. ↩
This is the same way that we write to the data bus on the v1 PC-6001 multi cart. ↩

Giving the SPARCstation some jumper cables

2025-12-30T00:00:00+00:00

My SPARCstation 1+ is very forgetful, and the cause is the old evil of batteries. In this case, the battery is entombed in an immortal epoxy container, which makes it really hard to swap! That’s why my good friend, and yours, the Dremel, is here.

Because the SPARCstation is an advanced, modern computer, it stores a lot of what it understands in the world inside its ST M48T02 “Timekeeper” chip. This is actually a RAM chip with a little hat, which in turn contains a rechargeable battery. Collectively, this component is referred to in Sun literature as the IDPROM.

This whole model is sort of similar to the “suicide chips” in Sega and Capcom arcade games, which use a potted module to hold onto encryption keys or some other kind of swizzling table in order to provide copy protection.

These Timekeeper family of chips are used in a handful of other non-Sun computers, all for similar purposes. For instance, there are several models of the Philips CD-I that refuse to boot properly if the battery in their Timekeeper goes flat.

On the Sun, several settings are saved in this little 2-kilobyte miracle, such as:

the serial number/unique machine ID (hostid;)
the MAC address of the ethernet chipset;
the current time and date;
all the boot settings.

It’s this last one that is the most annoying part for us. Because the SPARCstation is starting up every time without any knowledge of the past, it always defaults to the most intensive diagnostic. That means it takes a good 5+ minutes of RAM checking and ROM checking before I can do anything at all, and I have to tell it what device to boot from every time. There’s always a screaming, angry message or two when SunOS finally boots, with one part or another of its corrupted saved data being out of range and intolerable.

I could buy a new M48T02. They are still made, but they cost $27 USD on Digi-Key (PN 497-2825-5-ND.) Even before the exchange rate, that’s a lot of money that would be better spent on more computers. And eventually, ST will just stop making these altogether.

The class cut-up

Over the years, similarly cheap Sun aficionados have added an external battery to the Timekeeper. By cutting into the epoxy on top of the module, we can figure out where the battery is connected to the internal RAM, and put a new battery on it. That’s what we’ll do.

Removing the chip from the Sun’s motherboard is easy on these things. Unlike some cheap PC clones with soldered-in Dallas time keepers, this is just in a regular 24-pin DIP socket. I gently pried it out using a flathead screwdriver and flipped it over to look at the epoxy cap.

Make sure to take a picture before you pull anything, so you know which end is “pin 1.” Although there’s a dot and a polarity groove, the matte finish of the epoxy makes it easy to miss when you’re rushing. On top of that, there’s no convenient “pin 1” silkscreen marking on the motherboard like there is for some other ICs on this computer.

The socket, also, is not super obvious on polarity, which is a very annoying thing. Unless you already know what the polarity was, I can see this being ambiguous. Maybe you disagree, but either way, a photo is cheap insurance.

As I said above, the way that these modules are constructed is two-part. There’s a wide DIP chip on the bottom, which provides the actual RTC logic and memory of the timekeeper, and has the pins that connect to the computer. On top of that, ST has entombed a crystal and a lithium battery in what they call the “CAPHAT.” This sarcophagus-like arrangement is mostly just epoxy, though, and many folks before me have figured out how to cut into the CAPHAT and either completely remove the battery, or jump an external battery into it. I decided I would attempt the latter task.

The terminals for the battery are on the non-pin-1 end of the package, so I put it into the vise with pin 1 facing down.

My first hack at it with the cutting wheel went way too deep. I was surprised at how soft the epoxy actually was and how eagerly the Dremel bit into it. Spooked, I chipped away at it more gradually after that. Then, once I had both contacts exposed, I worked around the area with the grinding ball mill attachment to grind the plastic off around them.

After a little while, I could see the top and sides of the cell emerging from the epoxy coalface, so I used a continuity test to figure out which terminal was which. The negative terminal is continuous with the ground pin on the package, which is pin 12. It’s conveniently also the terminal that is closer to that pin. This seems to generally be the convention on Timekeeper ICs, but I don’t want to say it will always be the case for your own chip. Make sure you always check first, and then check your work!

Once I figured out which terminal was positive, I cut in a little bit further to split the cell’s tab from the terminal. This is so that I wouldn’t end up charging the old lithium cell in parallel. To make sure everything was electrically clean, I used a glob of flux and solder to tin the terminals. I threw some cheap wire on there, and stuck a CR2032 holder on top with a dot of clear silicone RTV.

Before inserting the battery and powering the chip, I made sure to double-check that I had the wires around properly. First, I got the M48T02 datasheet and confirmed that V_ss, or ground in this case, was still on pin 12 of the chip. The negative terminal of the newly-installed battery holder was continuous with this pin, so I at least didn’t have reverse polarity.

One big downside of this arrangement is that, with the additional height added by the coin cell socket, the middle SBus expansion card slot is now harder to use. In fact, I’m pretty sure it now interferes with any card. If I end up having to populate all three slots on this SS1+, I will have to remove the RTV’d on battery socket and mount it somewhere else on a fly wire. A problem for the future to solve, like acid rain or prop comedy.

Making New Memories

Now that the SPARCstation is capable of remembering things, it is time to reprogram the contents of the IDPROM. This is not a hugely difficult process, but it’s boring enough that I put it off for many, many weeks after the excitement of “cutting into a chip.”

The first step is to look at the bottom of the computer to identify the serial number. Both the IDPROM and the MAC address derive from this serial number. You could put anything in there, but you might as well do it right. Or at least better than I did.

This was the first problem I ran into when following the comp.sys.sun.admin NVRAM/hostid FAQ. The instructions for resetting the IDPROM clearly say that the hostid is the byte string of the decimal serial number:

Bytes c through e in the table above are collectively referred to as the serial number. If you convert the concatenation of bytes c-e to decimal, this is the serial number you see when you turn the machine on.

My serial number is “029F1287.” That’s not a decimal number, nor does it fit into three bytes as a hex number. If you interpret it as hex, that’s four bytes, which my advanced mathematics education tells me is “more.” I did find another thread on sunhelp complaining about the same problem, but with no seeming resolution.

Knowing that it doesn’t really matter what I put in there, I ended up interpreting it as a hex string, skipping the first byte entirely, and using $9f , $12 , and $87 . It just has to be unique on my network, which it certainly will be.

Another problem arose when I started plugging in the script. These instructions say to use real-machine-type, but I don’t have that word defined on my ROM version, so I just used $53 instead, for “SPARCstation 1+ (4/65).” Yours will probably be different! Don’t copy me.

You set the IDPROM using a mkp word. Remember that this is Forth, so you’re entering data in reverse Polish notation. Bytes C through E are the serial number on the IDPROM, and Bytes 2 through 7 are the MAC address, should you want to make these different for some reason.

After booting the SPARCstation, I went into new command mode (n) and then started throwing OpenBoot commands at it. The first batch here should be the same for all Sun machines, although you may want to try real-machine-type . first to make sure that you have that word defined, unlike me.

set-defaults
setenv diag-switch? false
1 0 mkp
real-machine-type 1 mkp
8 2 mkp
0 3 mkp
20 4 mkp

We’ve now set the header of the IDPROM and the first three bytes of the MAC address. After this, you will need to replace $host_id_ with the values you got from your own serial number.

At the very end, a checksum of the preceding bytes is done using XOR and then stored in byte F.

$host_id_1 5 mkp
$host_id_2 6 mkp
$host_id_3 7 mkp

0 8 mkp
0 9 mkp
0 a mkp
0 b mkp

$host_id_1 c mkp
$host_id_2 d mkp
$host_id_3 e mkp

0 f 0 do i idprom@ xor loop f mkp

I then turned the machine off and back on again. The serial number was remembered!

After that, it wouldn’t boot because it was trying to boot off sd(0,0,0)vmunix, which, if you remember from the previous post, is a victim of Sun redirecting the SCSI IDs in firmware. SCSI ID 0 is SCSI ID 3, and vice versa.

Rather than undo that, I did setenv boot-from sd(0,3,0)vmunix to set (and remember) the default boot volume, and then boot to get me into SunOS.

Hooray! This computer is finally working, remembering its own settings, and booting on its own. Unfortunately, the mouse still isn’t working, even though it’s a new-to-me Sun Compact-1 mechanical mouse (part number 370-1587-03, which should be compatible.) I don’t have a good setup to test what the mouse is doing at the moment, so we’ll save that for a future post.

Thanks to Rees and the entire Sun community for helping me figure out how to get this pizza box booting properly again.

Commodore 64 black screen failure round-up

2025-12-09T00:00:00+00:00

Through the kind contribution of a friend, I was able to move a bunch of broken Commodore 64s into the hands of other folks. And then help those folks fix those Commodore 64s, because they’re broken and that’s where all the fun is at. Here’s the tale of the first C64 of the bunch to be fixed. And the second.

The origin

I was invited to head out on a road trip to go visit John from CelGenStudios, who had a literal carport full of cool junk that he wanted to get rid of. As all Canadians know, winter means that the value of having “covered car storage” often outstrips the value of all the things inside it. Sometimes having a free garage bay is worth more than the car inside it!

Among other cool things, that you’ll hear about in future articles, there were at least seven dilapidated Commodore 64s. I say “at least” because we took these back from BC to the local retro-computer club, where they were given away to the members. I kinda lost track of how many were out in the community, but they all came back for a later “Fix-It” event. Broken stuff? My favourite.

These machines were in bad shape, with most missing top and bottom cases and keyboards, and some missing major components from their sockets. However, donating them instead of playing the eBay casinos is a very generous thing to do.

Thank you to John not just for this junk, but all the other junk too! It is great to see it distributed to a bunch of other weirdos.

The symptoms

Of course, we started by looking through the pile of power supplies to see which ones were going to lose regulation and turn the C64 into ash. Fortunately, we found a supply of the “good” generation and hooked it up with a multimeter present, and made sure that it didn’t drift and wreck any of the RAM.

As with a lot of Commodore 64s, the problem here is that when I plugged it into a TV and turned it on, there was just a black screen. I did notice a sync flash, but there was also some strange noise in that flash that quickly disappeared.

I quickly re-measured the +5V DC on the known-good power supply, and was happy to know that it was within range, so at least we weren’t undervolting or overvolting the system.

What’s a PLA?

First, I suspected the 906110 PLA. The PLA (“programmable logic array”) IC handles all of the decode logic for the Commodore 64 motherboard. You can think of it as sort of like the traffic cop giving directions so that the CPU or video chip requests are always going to the right place.

All of the logic is integrated into one part to save costs. If Commodore had to stuff a C64 board with dozens of 74s, it would be larger, consume more power, and cost more money, especially if someone on the assembly line installed one of those 74s backwards once in awhile. For companies bigger than weird hobbyists, if you’re planning on building a whole lot of machines, the up-front cost of producing a mask for “a chip that contains all my decode” is easy to justify against future per-unit savings. Especially if you also own the chip fab that makes those chips.

The PLA’s pinout consists of sixteen inputs (I₀ through I₁₅) and eight outputs (F₀ through F₇.) There’s also a chip select pin, which disables all the outputs when it’s not asserted.

Since the PLA is commonly fingered in most failures of C64s, I decided to look there first. I didn’t have a known-good one on hand, outside of my single working C64, so I built up a GALPLA board, and brought it with me. The GALPLA implements the PLA’s equations using a pair of GAL20V8 programmable logic devices.

At the same time, I wanted to actually verify the old chip was bad before swapping it. If I don’t know for sure that the chip is bad, I won’t know for sure that I’ve actually fixed the computer if it starts working when I swap the PLA. It might just be a manky socket, or some other intermittent issue that will reoccur later.

To make sure the old PLA was bad, I decided I would take a look at the outputs on the scope. Since I was away from home, I brought my new Zoyi¹ pocket scope with me, which is a thoroughly imperfect yet also really handy little tool.

And then when I got there, I found out that one of the other club members, Jason, had brought a BackBit chip tester! I’d never used this particular model before, and I knew it had an entry for the 906110² PLA.

Surprise: that test failed instantly! I was so surprised at my luck that I went and got another PLA out of a different broken machine and ran that, which passed. My cobbled-together GALPLA was also tested, and passed.

After swapping the GALPLA into the system, we now had a sync flash on startup, although the computer was still not working properly. Now, it would boot to a BASIC startup screen, and report “OUT OF MEMORY ERROR IN 0.”

Out of memory?

I know that this is in greyscale; we were probably using the wrong video cable for the composite port on this 1702. Don’t worry, the C64 was generating perfectly fine colour.

However, we can see well enough to know that BASIC is in distress. The most likely cause for this error is that one of the soldered-down DRAM chips has gone bad.

Some piggybacking with a known-good 4164 didn’t seem to change the outcome of the startup, so it was determined to run the C64 diagnostic and remove the ones that it complained about one at a time. Turns out that three RAM chips failed, and were progressively eliminated by a Versa64Cart loaded with a diagnostic image (and S-video output adapter) brought by Baptiste. Each RAM removed was socketed when it was returned to the board.

There was some concern at this point that the GALPLA might be too tall to clear the keyboard, but we may be able to trim away the plastic clips on the pin headers to lower it, if we really have to. For now, it seems fine, but we also didn’t have a complete top case to test with.

Eventually, we were given a clean bill of health by the C64 Diagnostic software. Some later inspection showed that there seemed to be some occasional corruption on the very leftmost column of text. The BackBit VIC-II test passed, but we ran out of time to do some more parts swapping on this one.

Fixed! Sort of. At least it’s booting. Who’s next?

Painful memories

We fixed a handful of other C64 boards from this hoard through the same process, for a total of four out of six boards working by the time I went home. Hopefully we can get at least one more!

However, since these three other boards were basically fixed by high-speed parts swapping, I won’t write too much about them, but I will share the one machine that I found interesting, because I’m still not sure what was going on.

One interesting failure we found was that of another black screen C64. The 82S100 PLA in it had failed according to the tester, so we swapped it from a parts board that was had no power coming into the +12V regulator (will check this one later, too!)

After that, we got a sync flash, indicating (I assume) that the CPU was now capable of using the PLA to address the VIC-II video chip in order to turn it on, but then something bad happened after that and it wedged itself on a black screen.

At that point, it was time to stick in the DesTest MAX cartridge, which consistently did not run – at most, we’d sometimes get a solid white screen.

DesTest MAX claims that it only needs a few devices in the documentation:

The 6510 CPU, VIC-II and PLA need to be functional, though the ROMs, CIAs and SID are not required and can be removed if socketed.

Well, since you asked nicely… I tested the CPU in the BackBit, which failed “8 tests.” I’m curious what those exact tests are, or how many tests there are, but I couldn’t figure out a way to make it tell me. Maybe there’s a log file on the SD card?

I would never have thought to test the CPU, which means that this tester probably helped save this machine. After swapping a 6510 from the computer that won’t power on, I was able to get an annoying white flash from the startup but nothing else.

At this point, I decided to remove all the socketed parts not needed to run the DesTest MAX cartridge. A lot of things were socketed, which made me suspicious that this was not this computer’s first time under the knife.

Working methodically, I removed both CIAs and tested them – they were fine. I removed one ROM at a time and tested after each one³, and found that once the 901225-01 character ROM was removed from U5, the computer was now able to boot the DesTest MAX cartridge.

I reinserted all the CIAs and all the ROMs except for U5, and it continued to boot the cartridge properly, so I once again scavenged the U5 ROM from the power-stricken C64 and swapped that in. Success – DesTest MAX booted and went through the whole suite of tests!

Look! I was even able to boot BASIC.

After replacing one of the ROMs, a dead CPU, and a dead PLA, this motherboard was once again alive.

I am still not sure why this ROM kept the computer from booting, as DesTest MAX does not attempt to interrogate the original system ROMs before running. My best guess is that it was stuck on output-enable for some reason and was putting junk on the bus. Maybe that’s also why the CPU died, and maybe the PLA helped jam that output enable on in the first place.

Once I had removed the parts, I realized that the U5 ROM had been marked through with a red Sharpie by (I assume) some previous technician. Did they know this part was bad, and just couldn’t find a replacement?

I didn’t hold onto the part, but it wasn’t thrown away, either. I may try to set it up on a breadboard and see if I can verify this hypothesis in isolation when I can get it back.

If you have your own theory about this failure, please feel free to speculate below.

Conclusion

Black screens are not always the PLA. I know it was the PLA for both of the machines shown here, but at least half the PLAs tested passed on the other computers. It seemed anecdotally like the 82S100s were more successful, but our sample size is too small to draw conclusions.

I learned two things on this adventure. One is that a mask ROM can fail so severely that it hangs the entire bus up, and the other is that a specialized chip tester might actually be worth the money.

For the latter case, I had long avoided specialized testers – I like my TL866 and my GQ-4X4 for their versatility, but they are limited in their ability to run complex test vectors (mostly because of crappy software.) They certainly can’t test a 6510 CPU, which is something I would never have bothered with testing (or maybe could not have identified on a scope) without this thing making it easy.

I’m not sure when I’ll add a complex tester to my arsenal, but I have definitely been convinced that they can come in handy.

There’s still some faulty Commodore 64 boards around, especially that pesky one with the mysterious power problem. It would be really impressive to fix all of them, but it is possible that they will turn out to be more difficult, or involve replacing a more complex chip than a PLA. I’ll be sure to let you know when we figure those out too.

Repair Summary

Fault	Remedy	Caveats
Black screen (with sync.)	Replace bad PLA and bad RAM.	There are further visual faults whose origin could not be identified by automated testing, and we didn’t have enough time to do a deeper dive.
Black screen, but a different computer (also with sync.)	Replace bad CPU, PLA, U5 character ROM.	The exact mechanism of the ROM keeping it from booting is unknown at this time.

Not sponsored. If you’re a test equipment vendor and you want to sponsor me, get in touch. I guarantee you I will misuse your stuff enough that you won’t need a QA department. ↩
We found out that the same test will also work for an 82S100 PLA, because we had a few systems with those around. Most passed! ↩
Like the Retro Chip Tester Pro, I assume the BackBit has some way to identify ROM chips from the checksum, but couldn’t figure out how to make it do this. ↩

You’re Out of Timer

2025-11-18T00:00:00+00:00

Now that there are more clubs forming in my local area, I’ve been thinking about taking some of my junk to shows. Of course, this means I’ll need a cheap small colour TV if anyone wants to see that junk work. Maybe something like this inexpensive 13” Samsung CXJ1352? Too bad it won’t stay running.

Hailing from a fee-encumbered auction on eBay, even with a best offer, I paid a little more than I wanted to. I did so, rather than picking up a working set from local Kijiji, because the problem described is mysterious:

Tv powers on with flashing timer light, The timer shows 0 minutes remaining and then the tv powers off shortly thereafter. We don’t have a remote and are not familiar enough with the unit to troubleshoot the matter so we’re selling the unit as is.

While the set was in transit, I was happy to find a service manual with a single web search. That service manual included a packing list, which told me that the original remote was Samsung part number AA59-10026Q, which is needed to activate the VCR menu or switch to the AV-in mode. Apparently, the front panel buttons will do playback features, but nothing else VCR-related.

Because the “timer” light was blinking, I thought it could be some kind of cryptic error code. However, the service manual makes no reference to any front panel lights. I couldn’t find the user manual, either, but I don’t expect it would have that kind of information.

Theory

I’m not sure if modern televisions still have this feature, but a lot of CRTs from this period had “auto-off timers.” The idea was that you’d sit in bed, watch some TV, and set the timer. When the timer expired, the TV would automatically shut itself off so it wouldn’t be running all night after you fell asleep in the middle of Letterman’s top 10.

For parents, these timers were also used to limit how much TV your kids were watching – which means the timer value has to persist across the set being turned off, and probably even unplugged. Kids are crafty when they need to get around the computerized babysitter in order to watch the rest of Letterman, for instance. That need for resilience means the set has to have some kind of long-term storage that holds the timer data. I looked around in the schematic, and immediately found an Atmel 24C02 i2c EEPROM connected to the CPU.

My initial guess was that this EEPROM was corrupted somehow – maybe a lightning strike, maybe it hit the write limit, maybe it’s developed forgetfulness out of pure age. If that’s the case, then the fault would manifest this way: the set wakes up, reads the value of the EEPROM, sees that the “remaining time” is something like negative seventeen trillion seconds (which is less than or equal to zero seconds,) and then shuts itself off.

While the TV was on its way, I decided to see how much it would cost if I had to replace the EEPROM. i2c-based EEPROMs tend to be really cheap, because they’re sorta modern, and modern things suck, so nobody wants them. I ended up ordering a 24C02 EEPROM from Digi-Key for $0.70, just to be on the safe side.

Arrival

It took forever to get here, and it wasn’t packed especially well. That’s eBay for you.

I noticed as I was getting it out of the box that it had a weird noise inside, almost like something was rolling around inside the set. That’s not good. I checked the VCR slot to see if I could figure out what it was.

What the hell is that?

I used some long pliers to get the contents of the VCR out, and found two glittery green fake plastic icicles and a Pokémon card from 2020. Some children have been “working on” this television set. Warms my heart to see that kids are still cramming stuff into VCRs in this day and age.

Keen viewers will notice that there is only one metal hook for two icicles. Uh oh. I could hear something else rattling around in the bottom, too, if I picked up and tilted the set from side to side. The prudent thing would be to take the set completely apart and look for the stray icicle hook made of conductive metal, in case it’s bridging something that shouldn’t be bridged.

So I fired it up instead.

Vroom vroom, let’s go

The convergence between green and blue wasn’t exactly great - there’s lots of fringing and misalignment on the OSD. More on this in a bit. The timer light was indeed blinking.

Unlike what the eBay seller said, the TV did not at any point pop up an ominous “0 minutes remaining” message and turn itself off. I sat watching the “Line In” channel for about half an hour while eating my lunch, waiting for a timer-induced failure. Not exactly riveting viewing, but I’ve seen worse.

I grabbed some universal remotes and started tinkering. I came away frustrated on the “TV” settings, with seemingly hundreds of button presses failing to find a code that controlled the TV. Then I remembered - it’s a TV and a VCR. On the “AUX” or “VCR” settings, I could turn the set on and off and access limited menu items, but not all the buttons worked. In particular, the “Mute” button, which is required to access the service menu, does not work on this remote under “VCR;” it always sends a message out through whatever the “TV” setting is programmed to instead.

So I bought another universal remote. This fetching blue Philips number cost me twelve dollars.

While I was waiting for the remote to arrive, I was able to check some menu items using the front panel buttons.

I found some interesting things. For one thing, putting the VCR in “Demonstration” mode popped up a red “Demonstration” OSD, so I knew that the red gun of the CRT worked. I also noticed that the time-of-day clock had reset, which is no surprise since the TV had been unplugged for years.

No timed shut-off or turn-on for the set was set, nor sleep timer, although I did inadvertently schedule a timed recording one or two times. Navigating this menu was really frustrating.

I also noticed that some of the channel tuning settings seemed to have changed over the course of testing. The Add/Remove Channels option couldn’t be toggled with my remote, but I noticed that it changed from Added to Deleted a few minutes later.

Initially, I had suspected EEPROM corruption, and now it was seeming more likely.

Something really interesting happened when I tried to change the time of day clock. If I put it to a year before 2000, it would work as I expected. On the other hand, if I changed it to a year past 2000, each increment would make the set seem to stop “listening” to the remote and front panel for awhile, and the OSD menu would eventually turn itself off. Even the power button wouldn’t work.

Remote Possibilities

I let the set sit for a little while, and the universal remote showed up. As soon as I unpacked it from the box, I looked at the little sheet of device codes that came with it. Sure enough, stuffed into a very tiny corner, was the device category of “TV/VCR Combo Units.”

I tried the first code, and immediately had some success. However, the volume and mute buttons didn’t work, so I tried the second code, 1522, and had even more success. Now the mute button worked, so I could get into the service menu.

To get into the service menu:

Shut the TV off but leave it plugged in;
Press Mute, 1, 8, 2, Power

I scrolled down to the “EEPROM Initialize” option and picked it. The set shut off, and along with it… the blinking timer light! There are a lot of other cool options in this menu that I plan to revisit in order to do calibration, although I doubted that the convergence could be controlled through software. This set may be from the far-off future year of 2001, but it isn’t that fancy.

I decided to also check for more details on the back label of the TV at this point, to track down the service manual. The “SVC Mod.” is CXJ1352BX/XAC, the chassis number is V15A, and it was made in Tijuana. While combing through the service manual, I found that this set has RGB pins getting fed by an external OSD¹, so it should be fairly easy to cut in the middle of these and do an RGB mod as well. Some sets generate the OSD inside the jungle IC, so there is nowhere to tap in order to inject RGB into the set.

I believe this easy RGB mod is also the case with a lot of Samsung sets from this era.

According to the service manual, here’s what each of these cryptic acronyms mean:

Cryptic acronym	Somewhat cryptic name
AGC	RF AGC adjustment (gain control)
VCO	PIF VCO adjustment (something-P I/F voltage controlled oscillator, composite related?)
SCT	Sub-contrast adjustment
SCR	Sub-colour adjustment
STT	Sub-tint adjustment
RC	Red cut-off
GC	Green cut-off
BC	Blue cut-off
GG	Green gain
BG	Blue gain
SB	Sub-brightness adjustment
VA	Vertical size
VS	Vertical centre
HS	Horizontal phase
AFN	???
ACS/VChip	??? censorship chip disable?
TRAP	3.57MHz switch (???)
OPTION	AFT adjustment (???)
EEPROM	EEPROM initialize

No convergence adjustment.

PC Engine

Because it was on top of the pile, I grabbed my Core Grafx and plugged it into the TV. I was immediately rewarded with some atrocious convergence around the circumference of the screen:

Sadly, convergence is not something that is easily adjustable in software on most (all?) sets, this one included. I assumed I would have to go and wiggle some yokes, which is something I hadn’t ever done before and didn’t want to do solo in case I made it worse. For now, I would just sit further back from the set, and maybe take my glasses off!

Klax was legible, but not beautiful, in this condition. The top of the screen is getting cut off, so I probably need to take a visit to the “vertical size” adjustment (VA) in the service menu.

NHK Taiga Drama Taiheki, a turn-based strategy game based on the then-popular Taiheki drama series, has a really nice static title screen, so I wanted to use it to see if sharp detail could be discerned. To my surprise, this looked quite good, albeit with the usual flickering fringes from the PC Engine’s famous dynamic dithering.

Soak Test

Now that I knew the TV was working, it was time for a soak test, to make sure that the timer fault and random shutdowns didn’t re-occur. The last thing I would want to do is haul it to a meet and then have to keep resetting it, or have no display at all. In keeping with my tradition of not playing videogames for very long, I decided it was time to watch a movie.

Being in the modern era, I wanted to hook it up to some kind of streaming service, but I didn’t have any streaming devices that did composite output. Netflix is built into my TCL television set, and my PS3, Xbox One, and PS4 are all HDMI sources. My Xbox 360 only has a component cable, and I wasn’t about to go shopping for another, mostly because I wasn’t sure if the 360 could even still Netflix and/or chill.

The only solution was to buy a streaming box of some kind. Somehow I’ve managed to avoid it this long. I decided to try and get a Roku Express, but the last supported version of that device that has composite (model number 3910) has been marked up to insane prices on eBay:

Even the HDMI ones were fairly expensive. I checked for Apple TVs as a joke, thinking that there was no way the fruit company would have anything cheaper than an Android TV box, but I was wrong. I got this A1427 (3rd generation) Apple TV for literally 99 cents on eBay instead. It even came with an HDMI cable and a fresh battery in the remote.

Of course, it needed to be converted from HDMI, so I recruited the help of my good friend, $4.14 HDMI-to-AV-box-from-AliExpress. These things have gone up in price, as I remember them being below three dollars before. That’s inflation for you.

Even though the HDMI-to-AV box has a USB port for power, it can be powered through HDMI if the source device chooses to do so. The AppleTV is one such device: it even powers this box when it’s asleep, causing it to display this test pattern of colour bars.

The convergence problems are obvious even on this screen: not only is the text wiggling, but there is a dramatic band of green in between the yellow and teal bars on the left, and another band between magenta, red, and blue each.

After a bunch of thumbing-in passwords using the remote, I was now on the Apple TV main menu. Text is barely legible on this thing, not just because of the convergence issues (which are glaring,) but because the user interface expects to be shown in a high-resolution mode like 720p at the very least.

Some more thumbing-in and I was able to watch Netflix². The Lost World has never looked more VHS-y.

Trust me that it looks a little better in person, but only a little better. Long Exposure mode on my phone is not my friend here. I’ll have to improve my technique if I want to keep taking pictures of CRTs…

Okay, Seriously

There’s no way that I was happy with the performance of this set. Even though it ran for hours without dying, the picture was totally awful.

Now, I’m no CRT expert. I barely know how to turn a knob. But I do know what I like, and I don’t like what’s going on here.

To figure out what areas to focus on, I used my Model 1 Genesis with a Test Cartridge over composite. The Test Cartridge comes with several of the 240p Test Suite test screens, including what it calls the “overscan test,” which puts an evenly-spaced grid of boxes onto the screen.

Already, this does not look great. A closer inspection of the left side shows convergence issues, as the white boxes have red and green lines bleeding out of them. There’s also some concerning geometry issues in the corners, as the white boxes are also not really boxes, but more resemble a house falling over.

On the right side, the linearity problem maybe gets a little better, but the convergence problem gets even worse, with green not even in the same postal code as the rest of the channels near the right edge.

Although the convergence is really distracting, that flagging in the corners on the left side of the picture really bothered me. It started to feel like it could be a power supply issue, and it’s possible that the convergence was being made worse by weak focus as well – those corners are kinda blurry.

Weird clunking sound

Of course, all of this non-functionality didn’t keep me from using the set. Whenever I needed a not-particularly-valuable CRT to run for a long time at a club meeting, I pulled this sucker out. Of course, that required transporting the tube, and every time I did that I heard some faint clunks inside.

Time to take it apart. I put the TV on the floor next to some other TVs that also needed work, because my desk was being occupied by TVs that need work. I may have a problem.

Opening this set is easy, with just a handful of screws on the back. Someone has been in here before, judging from the fact that most of the case plastic is cross-threaded and in terrible shape.

Given the fact that there were some Christmas ornaments inside the VCR, I should not have been surprised that there were also some decades-old Starburst candies. Hey, they say that solar flares mess with RF, maybe removing these starbursts will touch up the convergence?

I pulled a total of seven candies out of this thing. That’s like a third of a package. Kids are so wasteful. This took me about an hour to get all of them fished out of the VCR’s many folds and gewgaws.

After cleaning up around the set, I decided to take a look at what chips are onboard. Here’s the Toshiba TA1282N all-in-one 52-pin jungle IC. This thing does it all, from OSD to deflection control. As I mentioned up above, it also has some obvious RGB inputs on pins 15-17, which could be very interesting for us later.

Since this is a television set from The Future, there are very few other “big” parts on the motherboard. Here’s another one: a Zilog SZM-644E, which is almost certainly a mask-ROM microcontroller. This chip is also probably where the OSD comes from, since there’s hardly anyone else living on this board.

Unfortunately, I was not able to find a data sheet (let me know if you do!) Right next to this MCU is the aforementioned small Atmel 24C02 i2c EEPROM, the one which we have decided that we don’t have to replace right now.

After buttoning up the set and doing literally no adjustment, measurement, or even eyeballing of caps, I made sure that it still worked by playing some Soggy-1000 games on it. It’s amazing how bright this tube still is, considering the hours it must have seen.

Okay, in the van with you.

A Fortuitous Alignment

Now that the set was working, I hauled it to a show in order to brag about my SG-1000 clone. As one does.

When I was showing this pile of junk at a local show, our local CRT mechanic Baptiste was also visiting. I asked him if he would take a look at the convergence on the Samsung, and after he saw how bad it was, he obliged. Because I was too dumb to bring a copy of 240p Test Suite with me, we instead had to do it by making SK-1100 BASIC repeatedly write a . character with white-on-black text (COLOR 15,2; 10 PRINT "."; 20 GOTO 10), but it was enough to work.

After a couple minutes fiddling, it looked way better. He told me that it probably needed additional convergence strips (fancy tape-on magnets³) to get it perfect, and that the top left of the set needed an external degauss to be tolerable. You can see that interference on all-blue pictures, but that’s pretty rare for me.

Still, it looked pretty good to me, and I thanked him profusely for his time and magic fingers.

Thank you again Baptiste!

Conclusion

That’s probably enough posting about this dumb cheap TV/VCR for now. Despite a rocky start, I have grown to like this little set, and I’ve been carting it to shows just as I intended. Would it be nice to have 15kHz RGB? Oh yes, but that can wait until later.

Does anyone have a tape they won’t miss that I can try the VCR with? I’m pretty sure I got all the melted Starburst out of it…

Repair Summary

Fault	Remedy	Caveats
TV timer light blinking, shuts itself off	Get into service menu and initialize EEPROM	Shutting off phenomenon was not reproduced during initial testing
Weird clunking sound inside set	Remove candy from VCR	I never found that Christmas ornament hook, did I?
Convergence is off	Adjust convergence rings	For better quality, will require external convergence strips

On Screen Display, basically the channel indicators, menu, etc. Everything that’s overlaid on top of the program by the television’s microcontroller. ↩
While I was editing this article, Netflix made sure to email me and say that the AppleTV I used will soon not work with their service. We had a great time together while it lasted, Jeff Goldblum. ↩
It looks like these are straightforward enough to make myself, but I probably won’t do so at this time. ↩

Three Times the Fun

2025-10-28T00:00:00+00:00

If you think “funnest” isn’t a word, you’re wrong. Maybe you just haven’t met the Apple III yet, Apple Computer’s comprehensively-failed attempt at turning the hobbyist miracle of the Apple II into a serious business computer. If anyone asks, I’m a serious business person, so I’m allowed to have this.

What is the Apple III?

The Apple III was Apple’s attempt to get into the business-computer market. By taking an Apple II+, expanding it, and chucking a bunch of cool new features on it, the idea was that they could produce a system that was more turn-key than hackery. Tandy followed a similar idea with their TRS-80 Model II.

There’s a lot of cool stuff added to the Apple III, like a standard 80-column mode, paged memory management with at least 128kB of RAM out of the box, RGB(!), and a built-in floppy drive and disk controller. It’s also got a new operating system, Apple SOS, with a hardware abstraction layer and a filesystem with sub-directories.

Unfortunately, the dreaded second-system effect was on full display here. In addition to the useful features outlined above, Apple also added a bunch of odd gimmicks and confusing evolutionary dead-ends. Plus, even after a troubled and lengthy development cycle, the original released units were incredibly unreliable.

After awhile of trying to ship working units, Apple made a revised model – the Apple III+ – and greatly incentivized unhappy customers to upgrade to the new model.

Let’s be honest, though. “Weird gimmicks” and an unloved computer is basically catnip to me. One of those gimmicks is the cast aluminum case. Made like a car engine block, the main body of the computer is one giant chunk of metal. While very impressive to look at – maybe my favourite aspect of the machine – it doesn’t do the thing any favours, thermal-wise. You’ve probably heard the story about Apple support telling folks to pick up and drop their Apple IIIs on the desk; I bet you can figure out before the end of this article what part of the machine that fixes.

What’s wrong with this one?

Reportedly, mouse pee. This marks the third Apple III I’ve heard of that has been peed inside by mice. It could be because the cast-aluminum unibody doesn’t have any block-off plates for unpopulated card bays, so mice can easily get inside the massive openings in the back and pee inside it.

The first thing I did was pop off the top plastic case, which is accomplished by turning the two quarter-turn fasteners, one on each side, and removing the plastic. This exposes the top of the card cage, a speaker, and not very much else.

Yes, the Apple III can do digital RGB. However, this is not a “planar,” for lack of a better term, RGB output. Like the AppleColor 100, the output is actually indexed. I haven’t done anything with this yet; for now we’ll be using the “black-and-white” composite video jack to test the computer.

Check out that headphone jack. Yeah, no beeper speaker for us. This baby has an actual DAC.

I’m lucky to have a 128K model here – it’s an early board and therefore the most troublesome. Huh. Maybe I don’t know what the word “lucky” means after all.

The 32K and 96K configurations would probably have been produced from not filling up the internal memory board quite as much. But I’m getting ahead of myself.

It’s also worth noticing the address here: Bandley Drive! Apple amalgamated their various buildings and moved to 1 Infinite Loop in 1993.

Last: “In the event of difficulty?” Don’t worry Apple, I don’t plan on having any difficulties with the power supply.

On to the keyboard! This machine has clearly gotten smacked around, and a bunch of parts on the keyboard are broken as a result.

I’m not a fan of the layout of this arrow key cluster at all. I would have preferred an hjkl-style layout at the very least. Apple agreed, which is why the III+ comes with that ever-so-slightly better layout from the IIe.

One interesting thing about these arrow keys is that they are actually two switches in one. By pressing down hard, you’ll feel a second momentary switch engage. This appears to be the equivalent of the “repeat” key on the Apple II+ keyboard, so you can scroll without having to repeatedly press arrow keys.

I had no idea where to start rebuilding this reset switch, so I put all the parts I could find in a Ziploc bag and left it for another day. It’s not like the reset key is important for Apple II programs or anything, right?

Getting screws out of the underbody of this system is difficult. Galvanic corrosion – interaction between the aluminum of the case and the mild steel of the screws – has been made worse from the rodent damage.

Frankly, it’s also kind of dumb that you have to flip the entire computer over to get the motherboard out. I know it’s the same deal with the Apple II series of computers, but it’s so much more annoying with the heavier cast aluminum case.

The internal Disk III floppy drive is going to need some work. For starters, it’s belt-drive, and one of the mounting posts for the PCB has cracked. It’s also absolutely filthy. I put it to the side for now and kept going with the rest of the computer.

There’s a cool Apple logo moulded into the underside of the unibody. Very stylish.

In the process of being dropped on the keyboard, the main keyboard circuit board (there’s two of them, with one belonging to the arrow keys) has cracked, severing a trace.

Keystems

I felt sad looking at the badly-beaten keyboard and all of its punched-out teeth, so I decided to get some new key stems for it. I checked online, and vendors such as Joe’s Computer Museum were selling Alps long- and short-stems. I wasn’t sure which kind I needed, so I pulled a cap of an intact key.

This weird cylinder-shaped thing on top of the keystem is not what I expected at all. It seems like the other keys sheared off here, where the base of the cylinder makes a right angle with the stem.

After checking with the Apple III Technical Procedures, Appendix A, I was able to determine that this was an 705-0015 “Alps Short-Stem” key switch with a 815-0772 “Straight adapter” installed on it.

So I need to get some replacement short stems, and a straight adapter. I don’t have a good source on getting a replacement “straight adapter” for now, but I plan to measure this and make something that can be 3D printed. There’s no sense in spending money and time on repairing the keyboard if the mice have completely destroyed this poor computer.

Scrub A Dub

I removed the power supply and checked it out. It looks okay, except for a cracked “RIFA” brand X2 capacitor. This would probably have turned into magic smoke if I had been dumb enough to power the supply right now. I put this on the to-do list and kept going.

While I was at it, I started cleaning the disgusting case.

To clean the textured case plastic, I used an old standby. I chucked a bunch of Oxy-Clean into warm water and then used a toothbrush to scrub. Lots of dirt came out, and the water in the cup got filthier and filthier every time I stuck my toothbrush back into it, even with regular rinses in the sink.

Soon, the plastic keyboard frame and the top case shroud were looking much better, and the cup was pitch black.

Unfortunately, once cleaned, I realized that the keyboard frame had two cracks in it, around the reset button. The crack doesn’t go the whole way through, but if the frame is flexed it does get wider. I decided to leave this alone for now and try to figure out how to stiffen the backside later.

Logic Earth, Logic Board

Removing the motherboard is straightforward if awkward. All you have to do is flip the computer over and then unscrew the plate holding the motherboard from the underside, then pull it out. It probably helps that the previous owner had already unplugged the power supply, disk drive cables, and all the cards first.

Since this is an early board, it has an onboard clock battery. I’m not sure what kind of clock battery, as it has thankfully been removed, but the evidence of its presence (and leakage) is obvious. Not the biggest of our problems right now, but I needed to deal with it eventually.

At the other end of the board, a missing “58167” part initially gave me some worry, but a quick search showed that the MN58167B is a clock/calendar IC, which is considered optional nowadays. No battery, no calendar, no worries.

The keyboard controller IC nearby is pretty raunchy, with rusty legs and a corroded socket. It’s responsible for decoding the keyboard matrix into ASCII codes for the computer. At least it sounds like this might not be a custom part, and there is an excellent community-made aftermarket replacement, built around a PIC 16F18875.

I saw a lot of these weird little 18-pin DIP Apple-branded chips. A quick trip to the Apple ASICs site reveals that the 341-0045 is a ROM (specifically, a PROM) that’s responsible for “bus/memory select logic.” It takes ten inputs and produces four enables. There’s dumps of these weird little ROMs out there, so if one of these are bad (or if I want to upgrade to a 5V memory board) I can hopefully make a new one.

I used a boar hair brush and warm water with dish soap to clean off all the large gunk. It might not be the most clinical approach, but I assure you that this board was gross enough that this was the only way I was going to be able to touch it with bare hands.

Somehow, despite all the horrible pain this board has been through in its life, this sharpied assembly mark persists from 1982.

Sonication Rules The Nation

I did the logical thing at this point and bought more tools. Namely, a 30L Vevor ultrasonic cleaner. This thing is massive, and it takes an absolute boatload of distilled water every time I fill it up. At first I was going to build a little mini-workbench and install an outlet in a storage room to run it, but I couldn’t take the waiting anymore and just plugged it into the wall in my laundry room.

What better board to take it on its maiden run than this awful Apple III logic board? I set it in for eight minutes, and when it was done, the board looked cleaner – but not by much.

I asked around and Mark from the Mark Fixes Stuff YouTube channel set me straight. The solvent needs a much higher temperature (over 54°C) which means I needed to pre-heat the water and solution. For several hours, with the lid on.

After a couple hours, I finally had the temperature high enough. I measured the solvent and poured it in, then ran the ultrasonic empty for ten minutes to “de-gas” and mix the solution. After that, the Apple III board went back in the steaming soup, and was run for another eight minutes…

That did it! Just so I wasn’t wasting all the energy required to get the solution up to temperature, I then threw in every dirty board I could get my hands on and ran them too, along with the rest of the Apple III’s boards. Everything turned out much better, even battery-soaked carnage. I drained and disposed of the ultrasonic’s contents immediately after, out of fear of corrosive goop still lying around in the water. It was here that I remembered just how heavy nearly thirty litres of water really is, and how hard it is to drain it out of the tank without making a huge mess on the floor. Putting this thing up on a workbench would have made things a lot easier, and that’s since been corrected.

RIFA Madness

I decided to remove the cracked RIFA-brand safety caps from the power supply, but while I was in there I tried out my then-new Peak ESR70 ESR meter. That meter is a little picky, and immediately discarded every cap from the power supply that I put in front of it as “bad.”

The funky 70s power switch felt very weird, but it might just be the way the switch is designed, as it seemed okay on a continuity and resistance test. I’m thankful that it isn’t arcing, because I would have had to try pretty hard to find a replacement for it.

Luckily, the power supply uses all common values of caps, and so I was able to swap all of the rejects. One cap was glued in, and I’m not entirely sure why. Maybe because it’s close to the primary side and more likely to be vibrated?

I was confused by a resistor that had been clipped out. However, it looked like the same one is clipped out on other photos of Apple III power supplies.

A lot of the 1000µF caps are super tall ones in little clip-in plastic mounting brackets, which I had initially assumed were meant to prevent vibration without having to glue the cap in. You see these brackets in car ECUs.

They happily snapped onto the replacement caps, and actually seemed to hold them in place fairly well when I flipped the board over to solder it. Maybe that’s what they’re for!

I was surprised to see this new RIFA-branded cap was grey, having only seen yellow ones in old junk throughout the years. Yes, I put in new RIFA-brand caps. I assume they’ve figured out how to make more reliable safety caps in the last 40-ish years, and if not, I’ll deal with it in the 2060s.

Fixin’ Time

Now that the main logic board was clean enough that I could touch it without gloves on, it was possible to give it a closer inspection and see if it was safe to introduce power. I popped a couple of the larger chips out and re-socketed them, and was pleasantly surprised to find that the sockets were not nearly as crunchy as I had expected.

The next thing to do was to reinstall the RAM board. It sits atop the logic board. There are two kinds of RAM boards released with the Apple III: the early 12-volt board, and the later 5-volt board. This, in case you couldn’t guess by the very cool stacked DRAM ICs, is an earlier 12-volt.

Because the memory board had been shipped loose in the box, I didn’t know which way it went on. The stacking connectors which hold the memory board above the motherboard are not keyed – usually I’d expect to see these things at least staggered. Sloppy.

After looking at some Googled pictures of other people’s Apple III motherboards, I figured out that the “notch” goes towards the card slots at the back of the computer. It feels very flimsy to work with these connectors, and I bet this awkward high-rise, high-speed connection represented a big part of the thermal failures on these machines. This was almost certainly what was being reseated during that Apple support tale of “lift the computer off your desk and drop it.”

I had to do a few assemble-and-disassemble cycles before I could keep the power cord from being pinched by the case, but ultimately I triumphed and had an ugly but clean motherboard and partially-rebuilt power supply in the ugly but somewhat less clean case.

I decided that I would start the system with as little attached as possible: no keyboard, no disk drive, no cards. This would make sure that if one of those were funky, I wouldn’t be blaming the computer itself. Nothing left but to fire it up. I used a Monitor III that a good friend found at an estate sale.

“RETRY.” Okay, wow, that’s a good sign. Blinking cursor, legible text, text that makes sense as human communication, stable raster… a lot of things had to go right to get to this point. I was feeling pretty good.

After a quick poll of anyone I could find with Apple III knowledge, it turns out that this message means the computer is waiting for a disk. Of course, I didn’t have any disks, and the disk drive wasn’t hooked up (or even assembled) anyway.

Let’s try a cold restart. I flipped the power switch off and then back on again. This time, instead of “READY,” I got this “DIAGNOSTIC RAM.”

It should all be ., but instead half of the rows are 1. Exactly half. That’s suspicious. I was stumped on this one, and couldn’t find anything obvious in either Apple documentation or forum lore, and couldn’t figure out what would control only odd bits on the memory schematic. At this point, I also needed to clear the workspace I was using for the Apple III, so it went back into the tote for a few months.

I had a bad feeling about the “READY,” too. I had been told that not having the keyboard connected (or having a bad power-light bulb in the keyboard) would keep the computer from progressing past the keyboard diagnostic¹. And yet here we are, well past the keyboard diagnostic with no keyboard plugged into the computer. That’s suspicious, especially because of all that corrosion damage to the keyboard controller we saw earlier, and the crack in the keyboard PCB.

A more intensive test is called for.

Test Software

For testing, I wanted to make at least a disk of the Apple III “Confidence Program.” This tool has a bunch of options for testing hardware: thorough memory tests, machine feature profiling, disk drive testing, tests for all the graphics modes, and a soak test.

MAME had the disk image in its Software List, so I grabbed a MAME dump on the Internet Archive and used the ia utility to download all the images that matched *apple3*. I ended up with some images like Business Basic, the Apple II emulator disk, and Apple Pascal, as well.

I was about to hook up the Apple IIe and do a disk-writing session with ADTPro, but then I came across this project by “Thorsten B” which is meant to adapt the 26-pin Apple III to use the 20-pin Floppy Emu. I immediately sent away for the board and made up a quickie ribbon cable to test it.

This is better in the short run: I was already working on a suspect computer, so I didn’t also want to include suspect disk drives (especially ones still full of gunk) and floppy disks into the diagnosis tree. I know that the Floppy Emu works reliably, and that the adapter has been tested to work, so the number of potential new problems that could be created were minimal. I hoped.

It was a little hard to find a 20-pin shrouded box header with a central locking tab, so I ended up using this giant one with latching claws. This means it looks a little dumb, and the nice case they designed for the PCB doesn’t even come close to fitting, but it works. I actually really like these latching claws since it makes it easy to remove the cable without pulling on the ribbon and potentially damaging the crimp.

Unfortunately, when I started up the Apple III, it seemed to make no effort to boot off the Floppy Emu (which at least was getting power.)

A Firmer Emu

After a few months of wondering what was going on, it turns out that the Apple III’s super tiny 4K boot ROM only supports booting off an internal floppy drive², so I had already made one obvious mistake.

I took the computer back apart again, because the connectors are not readily accessible with the motherboard installed. As beautiful as this case is, I was definitely getting tired of dealing with it. I decided I would put the power supply and motherboard on the bench “loose,” and just deal with the extra space they took up in the dismantled configuration for a little while longer.

The Floppy Emu came to life and actually seeked tracks. This beaten-up Apple III is alive enough to try and load software off disk! The Confidence Test program quickly loaded, although you can tell something is not right.

Something is clearly going on with every second character; only odd characters are highlighted on the menu. Hmm! Just like the zero page diagnostic RAM failure. However, the keyboard works to navigate the menu, and although there’s some graphical corruption left behind when the “help” menu is brought up, I can run it like this for quite some time before anything goes wrong.

However, when I selected a menu option, the system would read several tracks from the disk and then go to a black or partially blank screen, unable to start any of the sub-modes.

Restarting the machine kicks us back to the “Diagnostic RAM” screen, now with a complaint about “A/D,” but with the keyboard attached, I learned that I can hold down CONTROL to guarantee that it will attempt a disk boot every time.

What’s A/D?

At this point, I was pretty convinced that at least one of the DRAMs on the RAM card had gone to silicon heaven. However, I couldn’t find my 1-bit or 4-bit DRAM tester boards, so I decided to do a little bit of research before wasting an afternoon digging through the pile of crap on my desk.

Reading the poorly-OCR’d service manual much more closely than I had previously, I was able to figure out some more about how the diagnostic screen worked and what its cryptic errors were.

A/D is an indicator of a bad read of either the high or low reference voltage of the 9708 chip located at M9.

That’s something to take a look at later, but for now let’s try to get things to boot and run well enough that “non-working joystick” becomes something I can worry about.

Remembering what you’ve lost

A little further down, we also have some suspects to check for “ZP” failure:

ZP indicates a zero page register failure. The zero page register is port B of the 6522 located at B6. Other possible chips for this failure are the S257s at locations D7 and D8 or the Ls132 at D4. This is where the zero page portion of the address gets fed to the system memory. Also note the NOT ZPGE signal which should originate at the LS51 at B11.

It also explains where each “bad” signal goes to on the memory board:

Notice that the same chips appear multiple times, interleaved. This would be useful, except for the pattern we’re seeing; it is unlikely to my eyes that exactly half of the chips have gone out for a smoke and never come back. One of the TMS4116 chips, at position C-17, looked visibly dodgy, with some kind of still-caked-on environmental contamination having potentially crept inside the package. Could it be screwing up multiple lines? I didn’t think so, especially not without getting super hot in the process.

A more likely suspect for a failure this big is the super sketchy connection between the RAM board and the Apple III motherboard, so I decided that I would do a crude continuity check and see how things looked from there. That passed with flying colours – all 50 pins seemed to be making continuity, which is honestly more than I expected.

To be thorough, I pulled the RAM at C17 out and put it in the 4116 RAM tester I had on hand. It failed nearly immediately and consistently, with four angry red lights showing what I assume is a basic write/read failure. Two others in the “C” row had intermittent failures, and either showed up as 8K or failing timing/decay tests, but I suspected those were corroded legs. All the others in the “C” row tested out just fine.

So this was still worthwhile (it found a bad chip!) but, again, because of the pattern of failure I suspect our problem is somewhere in the addressing logic.

Because the 74LS51 at position B11 was very easily accessible, I pulled it out and popped it into my TL866. minipro claimed that the chip failed:

However, a known-good 74LS51 also tested identically. The test case as described by Minipro makes sense to me with the datasheet, but something else is going wrong with that test.

Thanks for the memories

Grudgingly, I ordered some AliExpress TMS4116s to replace the three bad ones I had found on the memory board. Once those were swapped in, the self-test at startup displayed something very different:

It looped between this bad-memory screen and a screen full of rainbow vomit:

“ZP” is gone – with a functioning zero page, I can now run a whole lot more software. Plus, the Confidence Program menu is not checkerboard-y anymore. Despite the death loop, it continued to boot to disk by holding control and open-Apple.

However, the RAM test fails instantly, claiming “BAD MEMORY.” Yeah, I know the memory is bad, that’s why I’m running the RAM test.

The “machine configuration” test tells me that the Confidence Program believes itself to be running on a 32K Apple III, which is not a configuration that exists, and also (for you math majors out there) is a number significantly smaller than the 128K this thing is supposed to have. So we still have bad memory somewhere.

Now that the zero page was working, I suspected the RAM diagnostic error message had become more accurate. I went back to the service manual “map” of which ICs to replace, and started spot testing them.

Almost all of the failing chips were “B” row Mostek MK4332s, which I had not figured out what to do with just yet. It’s a special module, as shown on the preceding link, and I don’t have replacements to hand, so something would have to be fabricated.

However, D17 was a regular 4116, so I tested that. It failed immediately, so I replaced it, and suddenly that bad bit was gone from the RAM test. The Machine Configuration window of the Confidence Program now said I had a 64K Apple III. The RAM test still would not proceed past “BAD MEMORY,” but at least there was some improvement.

As for the MK4332s, I don’t want to condemn these beautiful gold parts to the scrapyard without first testing them. Unfortunately, the DRAM tester that I’d used thus far does not directly support the 4332’s pinout. For a first test, I swapped the 4332s at positions D2 (bad) and D3 (good,) and the error followed the moved chip.

Test some MK4332s

I quickly dashed off a weird little bodge board to convert the 4332 to a 4116 pinout, so I could test the 4332 in my 4116 tester. Glad I got that out of my system.

Since the 4332 is basically “two 4116s³,” the way this works is that there is a switch to toggle between which bank is being tested. You must test each 4332 IC twice, one for each 4116 inside.

Yes, I did think about writing a whole microcontroller-driven test, but the existing 4116 testers already have fancy timing tests and short protection that I don’t want to implement.

I wish I had dug through my used-parts bin more and come up with a pair of 3-pin slide switches instead of the jumpers. It’s kind of annoying to move them between runs, but I’m not doing this all day.

Another thing I wish I had done was add pull-up resistors to the CAS and RAS lines. Without them, I had a frustrating evening where I had tons of sporadic failures of chips the Apple III’s diagnostic test had been happily passing.

At first, I thought it might be the test being just that much more hardcore, but gradually I realized I had made a silly error. Like usual.

Not only that, but I had written a note to myself (in the draft of this very article) for when the board arrived to add those pull-ups, and had already added them to the PCB in KiCad. Thanks for nothing, Past Me.

Once I added those pull-ups to the board, I had what I expected. Seven chips failed, as the III had claimed, but an eighth also narrowly failed the RAM tester (2/4 lights lit.) I decided to get rid of that one, too, and make it an even eight to replace.

If you ever need this tester, let me know. I strongly doubt I’ll ever see another 4332 in my life, unless used Apple III prices get a lot more reasonable.

Hopefully, there is some kind of magical fix for these 4332s in the future, and they can go back to work one day. Looking at the corners of the individual “4116s” stacked on top of the board, I can see some dodgy-looking solder joints, but I’m not convinced that it’s safe to hand-flow them, and the joints in between the modules are impossible to reach with an iron.

Most of the failed modules are still at least half good, with only one of their onboard 4116s dead, but I don’t feel confident enough in the long-term reliability to hot-air off the dead stacked 4116 and swap it to make one good chip out of two bad ones.

Even with the damaged silkscreen, I still felt they were cool enough to hold onto, if only as modern industrial art.

Make some MK4332s?

I had a couple ideas about how to replace the MK4332s. For starters, a quick web search found a Joe’s Computer Museum page about how to make an MK4332 out of two 4164s, which is something I have quite a few of lying around. Thanks, Joe.

These bodged-up double-4164s are both ugly and wasteful (128Kbit of RAM to make a single 32Kbit IC??) but the cost makes sense. 4164s are sub-$1 from AliExpress in small quantities. Even if I had stacked 4116s, it would still cost about twice as much, and be less reliable, as the older ICs are triple voltage (+5/+12/-5v.)

Unfortunately, my early testing shows that I’ll need to make at least eight of these contraptions, which means 14 4164s and a nice machine-pin socket for each. This immediately triggered my “laziness reaction,” which medical professionals have told me manifests primarily by wanting to make PCBs so I wouldn’t have to do any bodge wiring.

I considered making a whole new memory board, but that’s sort of infeasible, because of the dumb bottom-entry Molex stacking connectors on the board. They’re hard to find these days, and although I see some mention in the 1981 databook for Molex, the part numbers provided are totally unavailable in any pin count, let alone the 25 pins I need. Plus, I’d probably make two or three coasters before I got a board that worked.

My second thought was to replace a bank of eight ICs at once, using something like the Spectrum 48K lower-RAM bodge board. This would probably work, although it would also likely be a fiddly mess with a bunch of bodge pins, decode logic, and whatever small surface-mount 5V 32Kx8 SRAM I can still find.

For now, I decided to start by making a weird little 4164-on-4164 stack. I’m getting better at bodge wiring: I only burnt my fingers, like, three times doing this.

My first one took about an hour, and ended in me melting the very last pin on the machine-pin socket that I was using to hold it. Combined with the worry that I wouldn’t have enough height left for the keyboard, I revised my plan after that, running jumper wires directly into the Apple III memory board’s sockets and not soldering them in there.

Yeah, let’s go make that “fiddly mess with a bunch of bodge pins.”

More Soon

This article has already gotten quite lengthy, so thanks for sticking with it so far. I think the Apple III represents not just an interesting failure in Apple’s history, but a fascinating computer in its own right.

It’s unfair that it’s gotten so little support over the years. Once I can figure out a good solution for the MK4332s – which probably deserves an article on its own – I am hoping to get this thing working primarily so I can explore Apple’s very-overengineered implementation of the UCSD Pascal system.

Maybe in the long run I could even port a Tetris-like to it? Cleaning up mouse poop is one thing, but having to write 6502 assembly might be a bridge too far. See you all again really soon.

Fault	Remedy	Caveats
System full of mouse poop.	Clean mouse poop with futuristic hot tub.
Disk drives full of gross stuff.	Use a Floppy Emu adapter for now.
Cracked RIFA safety caps.	Replace.
Computer displays “RETRY” and won’t boot off Floppy Emu.	Stock Apple IIIs can only boot from the primary floppy drive.
Computer displays “DIAGNOSTIC RAM” error with half of RAM failing.	Replace bad TMS4116s.	Re-seating the 74LS51 may have fixed the issue also.
Computer displays “DIAGNOSTIC RAM” error with other RAM failing.	Use service manual to replace indicated 4116 RAM.	No good replacement on hand for failed 4332 RAM yet.
Confidence Test memory test fails immediately with “BAD MEMORY”	Probably the same as above.
Computer displays “DIAGNOSTIC RAM” error with A/D failing.	Not fixed at this time.

This annotated and modified disassembly of the Apple III ROM seems to indicate the keyboard modifiers register, KEYBD, is at $c008 . Alongside the bits for the other modifiers such as CTRL, one of the bits of that register somehow shows if the LED is drawing current, which means the keyboard is attached. ↩
At least, as per the readme for SOS HD Boot. ↩
Which IC speaks is chosen by which of the pairs of address strobe pins you clock in – RAS1 or RAS2. You want to make sure to complete a full transaction before trying to select the other chip in the package, because there is actually no protection whatsoever against both 4116s trying to drive the data-out pin at the same time. ↩