Leaded Solder

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

Power Surprise with the ADAM

2025-10-07T00:00:00+00:00

One of the most useful peripherals for the Coleco ADAM is the FujiNet. I got the FujiNet for my CoCo in a previous entry, and it rocks. Adding one simple PCB turned that machine from a generally-useless lump with expensive cartridges, into a very fun computer with online cross-platform multiplayer games, easily updatable software, and expensive cartridges. Would it be just as good on the ADAM? Yes, but somehow I still ended up designing a whole new PCB.

If I’m honest, the biggest motivation for getting the FujiNet is to be able to help test this platform. ADAM has a lot of complexity, between all the peripherals it supports and the platform’s native port of CP/M, and testing new features and regressions often falls on only a few members of the team.

Long term, I also wanted to figure out if I could make a TetriNET client using the Z80 chops I learned making a RAM tester for the Coleco ADAM in a previous entry. Don’t get excited: that’ll have to wait for awhile.

Not wanting to build anything, I went and asked on the Discord if anyone was making them. Henry Rietvald had an older one that he had already made up, and even modified for internal use, and sold it to me for a ridiculously low price. Thank you, Henry!

Installing it

Because this had already been modified into an empty tape drive bay, I had to replace my “blank” tape drive bay with this module. First step is taking the top off the ADAM, which requires no tools.

Inside here is the expansion bay. If I had a RAM expansion card, it would go in one of these bays. Notice how one tape drive connects to two six-pin connectors inside the ADAM. They are staggered, with two pairs 1A/2A at the back, and 1B/2B closer to the front.

I then removed two screws, and pulled the blank tape bay out. I put the two screws back in for safekeeping, but didn’t snug them in super tight. Then I installed the new FujiNet drive bay the same way, being careful to line up the mounting tabs properly.

The sticker on top of the tape drive warns me not to plug and unplug it from the motherboard while the ADAM is turned on. I bet someone figured this one out the hard way.

The FujiNet connects using the ADAMNet external bus, which happens on a 4p4c modular connector. I talked about this for awhile in the keyboard section of the previous article, so take a look over there if you’re really curious.

However, I now needed a way to get to this external bus. The closest connector is on the side of the computer, so I snaked the flat phone cable through the finger gap in the expansion bay “hood,” and then over the top of the computer.

Once I accomplished this, I realized that I am probably actually supposed to route the cable out the cooling fins in the bottom of the case. This would be good enough for testing, until I can figure out a cleaner solution.

Maybe I can make some kind of expansion adapter that uses the two six-pin connectors inside the ADAM? It’s possible those are “hardcoded” in some way to only be tape drives. A project for another day.

Disaster Strikes

At this point, I was ready to test this sucker out. My ADAM was going to finally get on the Information Superhighway. And then I knocked my custom-built power supply off the desk and broke it.

Why did my power supply fail when I did a little thing like “drop it on the floor?” There’s lots of blame to go around. The power cord is too short, which means using this computer has always been a little bit of a challenge involving wedging cables in the right spot and keeping the super-light power supply from being pulled off the desk by its own cords.

The damage wasn’t too bad, and thankfully it wasn’t energized at the time of the disaster. Two ferrule crimps had failed, which made me the most worried of the whole thing. If I hadn’t crimped those things properly in the first place, this whole supply was probably a ticking time bomb as it is.

Of course, the 3D-printed plastic case was obliterated. Although I’m no expert, I suspect that the layer height during printing was a little bit too ambitious. Now it was splitting along the gaps in the layer lines in several places like old deck wood.

All three screw holes for mounting the Meanwell RQ-50B had snapped off at the bottom of the screw, as well as all the screw holes around the periphery holding the power supply case together. The screw holes holding the lid also fell apart as soon as I touched those screws.

I started gluing things back together, but soon figured out that it was a losing battle, as the layer next to the freshly-repaired one would just splinter instead, and all the screw holes around the case were torn out and wouldn’t reliably handle new torque.

Remember when I said up above that I didn’t want to have to build anything for once? Sometimes the universe makes other plans.

Opportunity Strikes

Now I had an opportunity to make things better. I decided I would splurge a bit and go get a nicer injection-moulded “project” enclosure for the Meanwell, put a much longer power cord on this thing, and refresh all the crimps. At the end, I hoped that I would have a more reliable power supply. As it stood, the old homemade power supply was taking away from my enjoyment of the ADAM, rather than making it easier.

The one that I picked is a “Zulkit” waterproof enclosure (200mm x 120mm x 56mm) from Amazon. Being waterproof is not too important, considering I am about to cut a giant hole in the side of it, but it comes with a very stinky gasket that fits into a groove in the lid. This, combined with the fact that the mounting screws are isolated from the cavity inside, makes the enclosure watertight, if you’re too prissy to simply slather the thing with RTV like the world’s worst sandwich artist. It is unclear exactly what the immersion depth is that the waterproofing on this enclosure is rated for, but if you’re trying to use the Coleco ADAM inside your homemade carbon-fibre billionaire submarine, you have bigger problems.

These enclosures have mounting bosses on the inside, but they’re designed to accept a standard mounting plate, which is what you actually put your stuff on. Unfortunately, the mounting plate is not included, and they don’t even give you the measurements. Those measurements are supposed to be on a PDF linked from the product page, which is not the case on Amazon. Even after looking around on the manufacturer’s page, I wasn’t able to find them.

When my new enclosure arrived, I took it apart and measured the holes. It helps when things are obviously a round number, as the 100mm and 90mm hole spacings were. Meanwell also provides in the power supply’s datasheet some decent (but not turn-your-brain-off easy) dimensions. I’m still a rank amateur at using a digital caliper, but I was able to rough in the dimensions and improvise a plate that could hold the RQ-50B in its place.

Naturally, I found it easiest to work in KiCad, the only CAD software that has ever actually made sense to me. This was the project that convinced me that I probably do need a 3D printer, because it’s somewhat annoying to order five of these suckers and wait a few weeks. A laser cutter would be much more useful, though (hint to anyone out there who is looking for someone to send a free laser cutter to.)

To try and make the $3/board price “worth it,” I added a relatively useless prototyping area, so at least I could use the four leftover boards from my minimum-size run as more experimental PCBs down the line. Of course, I printed out a test piece on paper before I sent the order away. Who do you take me for, some dude who makes a lot of dumb mistakes on PCBs?

The chances that anyone else on planet Earth will try to combine this exact model of Meanwell with this exact model of enclosure is low. That said, there’s probably a really good chance that the moulds for this enclosure have been passed around all over the world, and there’s several thousand of these cases getting made every year under a bunch of different names. I can’t be sure without measuring the internal mounting dimensions, but it sure seems to be a pretty common size.

Once it arrived, I put the whole thing together, and found that I had indeed made a dumb mistake on a PCB.

Cheapness bit me in the butt again. I wish that I had made the PCB the whole length of the case, and placed the RQ-50B in the middle, because that would have given me a lot more options for mounting. As it was, the shielding of the RQ-50B got in the way of me getting a screw into the two rear holes properly. This meant that the PCB was only attached with the two front screw holes, instead of all around the board.

Although I’m generally gentle with my things, it’s not good for it to constantly be levering on the centre holes with the supply’s considerable mass, especially considering the fate of this Meanwell’s previous home. Spending a few extra bucks on the mounting plate would have saved me some grief.

Now it was time for the connectors. First up is the IEC power connector. Since I hate hardwired power cords, this is the perfect chance to make the power cord detachable – and let me choose the length of the cord depening on where the ADAM is getting used.

Of course, an IEC power connector needs a rectangular hole. I know how to drill round holes, but my drill bit box did not contain any rectangular bits.

I decided to appropriate a technique from model car building. On one of the YouTube channels I watch about it, Mini 4WD Condele¹ Base, often has to cut holes in the plastic bodies of cars.

He uses a pin vise hand drill to drill all around the perimeter of the desired shape, and then cuts between those new “stitched” drill holes with a side cutter in order to form the larger shaped hole in the panel.

I did the same thing. After measuring the exterior of the IEC and then cutting a template in cardboard, I marked it on my project box in silver Sharpie. Then I started drilling around the inside of the markings.

This took awhile, about 20 seconds per hole. Unlike the nice rubber handle on the Tamiya pin vise in the video, my cheap AliExpress pin vise has only a nasty knurled grip that cut into my thumb as I was endlessly turning. I also created a ton of plastic dust and chips, which I scooped up using a sticky lint roller brush.

Next time I’ll just use a drill press. Someone send me a drill press.

Once I had holes all around the perimeter, I grabbed my cheapest and nastiest flush cutter and started cutting. But… the flush cutter was not deep enough to reach all the way through the thick walls of the case. I could only snip the very outer layer of holes. It would seem that styrene car model kits are a lot thinner than 5mm-thick waterproof ABS plastic enclosures.

Eventually, I just ended up using a box cutter to “punch” this out crudely. Probably the safer thing to do would have been to throw this in the vise and then use a thin chisel to knock it out, but nobody was maimed severely by this heinous misuse of a tool.

After all this, the IEC connector didn’t quite fit. That’s because I cut on the inside of the marks: it’s always easier to take material away than add some more in. I grabbed a triangle file from my pile of files, and spent another ten minutes laboriously carving away until the IEC connector fit.

Nice.

For the power switch, I started off by eyeballing the outer diameter of the switch. Looked like it was about 3/4”, so I grabbed a 3/4” step bit and went to town. Unfortunately, it turns out that it was just a little bit larger than 3/4” – there’s a teeny-tiny tab on one side of the horizontal axis to keep it from rotating – so I had to finish the job with some file work anyway.

In a project like this, it’s always worth saving some money. I heated up the old strain relief in some warm water and then jammed it into another hole cut by the step bit, which fit with some struggle.

Making the harness, however, was a big pain. I wanted to reuse all the wiring from the last time, but wrap the entire length in heat shrink so it would look nice and professional. Unfortunately, I had a lot of trouble pulling all that wire through the heat shrink.

What worked eventually was to solder all the wires in the cable together, then solder a long “lead” wire to the end of them. That way, I could pull the “lead” wire through the heat shrink, and then pull the cable through it. This looked… okay. To be honest, I wasn’t super happy with it, and it caused a bit of kinking on one of the wires near the strain relief as it got twisted. But it was in there.

Once I had that end sorted, I could remove the leader wire, and shove the whole thing through the strain relief. Then I ran out of ring terminals after breaking a few due to my crappy crimper/stripper.

After more arrived, things came together. Rather than use self-tapping screws to hold the IEC connector on, I used a generous glob of clear RTV sealant. Was that a really good idea? Probably not, but it seems to be holding. This time, I actually thought far enough ahead to have gloves and a clamp. Maybe I am becoming a grown-up after all.

A quick check with the multimeter (use the pointy probes!) showed that all the voltages were appearing where they should.

Testing the new old power

Although I’m disappointed in how the “heat shrink cable” turned out, I like how this box tucks neatly in behind the ADAM “Memory Console.” It’s way less sketchy to set up than before, which means I’ll use the ADAM much more often.

That said, I think there is still some annoying finagling with the various cords that need to go into this sucker. This enclosure’s shiny plastic still slides around a bit on the crappy laminate of the desk, so I am going to put some sticky furniture feet on it when I find where my hoard of them has gotten off to. “Room for minor improvement in usability” is a lot better than being grumpy every time I have to dig it out and use it, which is where I was before.

After connecting everything up, I flipped the switch. I noticed right away that the composite video output is still sort of noisy, with diagonal jailbars everywhere. This is not unexpected, because we haven’t changed anything electrically about the giant switch-mode power supply that’s attached to the system. Between this and the video noise when the tape drive is going, I suspect the ADAM needs a review of bypass caps and other filtering, if not additional grounding.

Who cares about junky video? It’s FujiNet time. That’s what I meant to do awhile ago, at the start of this interminable post. Once the FujiNet was ready, it came up with a welcome banner:

And then it started trying to connect to a wifi network that it had remembered from before it was shipped to me:

I couldn’t figure out a way to cancel this process. Once it eventually timed out, FujiNet Config asked me what network I would prefer to use instead. I configured it with my local network and we were surfing the intertubes in no time. My first stop was the Irata Online archive, where I was able to grab a FujiNet-enhanced version of Reversi.

That’s right, instructions about how to forward TCP ports on an 8-bit computer. We’re through the looking glass here, people.

Unfortunately, I only had the keyboard plugged in, and hadn’t gotten my ColecoVision pads out of the closet yet. Anti-climactic to the max. Playing internet Reversi would simply have to wait for another day.

Conclusion

Phew. That “having to make a whole new power supply” really chewed up the word count in this post, didn’t it? In the next article on the Adam, I’ll be diving further into the FujiNet, with the goal of booting some arbitrary code from a TNFS server on my local network. Maybe we can make some improvements to Badam without having to burn a ROM.

In the meantime, I’ll be playing with 40-column CP/M!

Thank you very much to Henry for the kind sale of this too-cool gadget. Thank you also to everyone on the FujiNet team for making it possible for one of America’s least-beloved personal computers to download videogames over the internet.

And thank you for reading! See you next time.

A Japanese portmanteau for Concours d’Elegance, in this case basically a show and shine for model cars. Some of them are really cool! ↩

Building my own ArdSCSIno

2025-09-16T00:00:00+00:00

A lot of newer computers need what is called “a hard drive,” and as I work on 16- and even 32-bit ones, I’m finding more need for SCSI drives. There’s already lots of great SCSI emulators out there, but how do they work? And more importantly: could I make one cheaper?

Long-time readers will remember I’ve used a lot of BlueSCSIs for various shenanigans around the home. These things are great: they’re inexpensive, open-source, and well supported. While it’s undergone a lot of tweaks and at least one platform port since, the original BlueSCSI firmware is based on the ArdSCSIno, a Japanese open-source hobbyist project.

The ArdSCSIno is what it basically sounds like: using Arduino-compatible microcontrollers (which have gotten extremely fast for extremely cheap thanks to parts like the STM32-based Blue Pill board) to emulate a SCSI hard drive in software. It sort of blows my mind that this is even possible, but a 72MHz ARM (even faster with overclocking) is probably a good integer multiple faster than even the fastest 68k Mac.

Before we begin, primary credit for this project goes to ztto, the designer who made an STM32 Blue Pill version of the original ArdSCSIino setup, which was itself originally developed by Japanese hobbyist h_koma2. I’m using ztto’s pinout, and documentation. The only effective difference from their board is that I am just adding optional termination resistors (more on why in a bit.)

I had a couple Blue Pills lying around the house from previous aborted projects (some of which are keyboard converter projects, naturally) so I already had gotten over the big hump that is figuring out how to program the damn things.

Originally, I thought about building a whole bunch of BlueSCSIs instead – just order 10 copies of the Gerbers and then start stuffing them. But at this time¹ (2021,) the BlueSCSI project was brand new and getting the Gerbers was only by request. Aside from the (ultimately unjustified) social anxiety, I figured I would learn more from actually reading the ArdSCSIno schematics and firmware, and getting to know how it all works. I’ll take any excuse to make a board.

Also, I wanted to do some custom PCB layouts for weird computers, but we’ll get to that in a later entry.

Initially, this board was unnamed; the repository was just named ardscsino-fork. After it became obvious just how cheap this thing was to build, I promoted it to “Dirty ArdSCSIno.” I think it has a bit of a ring to it.

Design

I didn’t see much in the original board to improve on; there are basically no components, and all the magic is inside the software. Like the BlueSCSI-v1, I wanted to add passive termination to the ArdSCSIno base. That’s what those big resistor networks are for. Initially, I had a jumper to disable termination entirely, but I decided that if I ended up with a situation where the ArdSCSIno wasn’t the last device on the bus, I’d just desolder the resistors.

The original ArdSCSIno is powered exclusively through termination power, which is the five-volt rail provided by the computer to serve as the “pull-up” voltage for the termination resistors. However, not all SCSI/SASI computers actually provide termination power (e.g. the early-SCSI Mac Plus, the late-SASI X68000) and the termination power wire on the ribbon cable is very long, very noisy, and very thin.

To fix this problem, I wanted to add an auxiliary header for injecting power directly into the board, which could be done with a standard SCSI-hard-drive-style Molex 8681/AMP 641737-1 connector. However, the “hard drive Molex” is a very large connector, and it dominated the PCB. I ended up going with a Berg connector footprint (TE AMP 171826-4) for the first revision, both because I expected I would be using termination power on my test Macs, and also because I would waste less board space if I didn’t populate the connector.

Last, I also wanted to add some mounting holes. Keeping the PCB tiny is a noble pursuit, but sometimes you just have to add a few cents to the build cost in order to be able to zip-tie your board to the case. Wouldn’t want this bouncing around and touching things it shouldn’t.

The result is that the new board looks basically the same as ztto’s board, but with some big chunky resistor networks hanging out. I really like the look of resistor networks, as obsolete as they may be…

I got 13 boards for the price of 10 (which is really the price of 5 – for boards this small at PCBWay, “10” is a no-cost upgrade); a good deal.

Although prices have gone up across the board, at the time the bill of materials only cost $13.18 Canadian per unit. That’s a pretty cheap board! Too bad prices didn’t stay that way.

Blue Pill Pricing

In the time since I did this original math and when I was able to publish this article, Blue Pill prices have nearly quintupled, which makes this PCB a lot less economical. The STMicro Cortex-M3 at the core of the Blue Pill is a very versatile and inexpensive ARM microcontroller, so it was in huge worldwide demand at a time where production was (and is) very constrained. It might make sense to fork this project further and look into using something like an Artery ARM microcontroller instead of the Blue Pill; the Gotek manufacturers already did.

Some good friends of mine have looked into the GD32-based clone STM32s, but they reported a ton of problems with things as basic as “programming over USB” and “programming the damn things twice.” Hopefully the toolchain and quality issues get worked out over there, or they just got an especially bad batch.

Maybe the thing for me to take away from this whole episode is not to count my chickens before they hatch. This whole thing is why I usually try not to add up the costs of projects at any given time – any pricing will change from month to month, especially in the current environment of random shortages, wacky tariffs, and price hikes. Also, the sheer cost of some of these projects will just depress me.

So, cheaper? Yes. Better? Well, so far it doesn’t work. Let’s see if I can make it work.

Finding Out

One thing that I learned about SCSI as part of doing this project is that it has actual pins that do specific tasks, and a human being can make devices that interact with those pins. I’m not sure why I had such a mental block when it came to understanding SCSI; I think I got intimidated by all of the super fast new stuff that came after 8-bit narrow-mode SCSI. There’s also not too many large fixed disk projects in the community to learn by osmosis from, unlike, say, floppy disk drives.

I waited patiently for the demo boards to arrive. A handful went off to a friend, Chartreuse, who helped me with the Leako project. We hoped that we would be able to build these, get them working, and then explore some freaky new stuff like CD-ROM emulation and replacing the Blue Pill with a higher-clocked Black Pill STM32 board for faster transfer rates. All of that didn’t really happen. In the meantime, the Pico-based BlueSCSI-v2 came out. It’s so significantly faster and more capable that those goals quickly became obsolete.

In fact, I just bought a BlueSCSI every time I needed one, and never actually ended up building one of these yellow menaces.

That’s when I ran into another shortage. My preferred BlueSCSI vendor, Drake over at BlueSCSI of Canada/BleuSCSI du Canada, had trouble sourcing parts to make more BlueSCSI-v2s for me at a time that I needed one. You saw how that worked out in the triumphant (and smoky) recent SPARCstation entry.

After that project was done, I thought some more about this project. I still had a need for more SCSI emulators in the future, and still had a small handful of Blue Pills that I managed to collect when they were slightly cheaper than they are now. So let’s throw together one now.

Lookin’ good.

While waiting for the handful of parts that I had inevitably forgotten or used up in the interim, I asked Eric Helgeson, the developer of the then-new BlueSCSI project, if I could use the BlueSCSI-v1 firmware with my sketchy board. He had no problem whatsoever with it, and even helped with a bunch of my dumb questions as I was setting up the board. Thanks!

I used my STLink-V2 clone and whatever version of the open-source st-flash command line tool was still installed on my Intel MacBook Pro from way back in 2015 to write the BlueSCSI.bin firmware file from the BlueSCSI repository. It was written at address $08000000 , like on the BlueSCSI flashing directions.

Mac Test

Obviously, the easiest thing to test with BlueSCSI would be a Mac. I grabbed an SD card out of my pile, wiped it using the SD Card Formatter utility, formatted it for FAT32, and then dropped on an OpenRetroSCSI System 7.1 disk image.

I plugged it into my sorta-working IIsi, and fired it up on termination power only. I didn’t see any LEDs light up on the Blue Pill, and the Mac was unable to find any boot device.

On my PCB, I had clearly connected termination power (pin 26) to the +5V rail of the Blue Pill, and the multimeter agreed. But with the voltmeter, I was seeing less than a hundredth of a volt on the external power connector.

It turns out that the Mac IIsi was a terrible choice to judge termination power.. because the Mac IIsi doesn’t produce sufficient termination power. I’m a little grumpy that I burned a good hour of shop time on this, but luckily I have many other SCSI-equipped Macs to grab for testing.

The next choice was the Bad ADB Mac LC, which is enjoying a comfortable pseudo-retirement being used as a victim for all kinds of things like this. No, it’s not elder abuse, you’re elder abuse. It loves it.

I knew that this doddering old LC had working SCSI termination power, which would make hooking this mess up really easy, so I pulled out the hard drive inside it and jammed the ArdSCSIno in its place.

This time, the lights on the ArdSCSIno turned on. They pulsed. Things happened deep inside its silicon maze. But the LC refused to boot, dutifully popping up a question mark disk after many seconds of waiting for the SCSI bus to get its act together.

After all this, I noticed that the ArdSCSIno was repeatedly blinking the green light five times, which is probably the BlueSCSI v1 distress code for “no SD card.” Indeed, there was no log written to the SD card.

Having learned my lesson from the SparcStation 1+ termination power debacle, I suspected the power was simply too weak for the microcontroller and/or SD card to work.

I checked the power on the ArdSCSIno board and noticed it was only 4.14 volts, which is certainly less than five. Maybe I needed external power for this LC after all? Using a phone charger, I powered the Blue Pill off external micro-USB power. This didn’t change anything, though, and the five blinks remained.

Out of desperation, I tried a known-good SD card from my external BlueSCSI v1 build, and nothing changed. It was a bit of a relief to have it ruled out, but SD cards are a lot cheaper than diagnostics.

Paranoia sets in

As you do when you screw up the pinout a lot on new boards, I wondered if I had gotten the pinout right, and checked the BlueSCSI source code to make sure I hadn’t assigned the wrong pins anywhere. All the obvious SCSI pins were correct, but I found it hard to follow what pins the SD card interface was using, so I went on a dive picking through the BlueSCSI-v1 PCB designs.

Checking their schematic showed that I was using the same pins on the microcontroller, and the same pins on the microSD card. Somehow, I had even avoided mixing up MISO and MOSI. SD card detection should be working.

I decided to check if I had bad solder joints. Unfortunately, some idiot designed the board so that the Blue Pill partially covered the solder joints of the SD card module, making them impossible to probe without desoldering the 40-pin microcontroller first.

As a sort of nasty proxy for actually doing that 10 minute job and having a fixed board in the end, I chose to get scientific and first prove that I had bad solder joints. I decided to try and measure the resistance between those GPIO pins on the Blue Pill involved in the SD card, and ground.

My thinking was that with the card inserted, the resistance to ground on pins connected properly to the SD card should change – there’s additional paths to ground introduced through the circuitry of the SD card when it goes into circuit with the rest of the board. Any pins that don’t change in response to the card being inserted and removed would then, in theory, be likely to be indicative of a bad solder joint.

Pins A7 and A6 (MOSI and MISO) changed from 4.6MΩ with the SD card inserted to 5.8MΩ with the card removed. On the other hand, pins A5 and A4 (SD clock and SD select) did not change from 5.8MΩ at all!

It’s hardly a robust test, but it made me feel clever. Also, now I had a good reason to try and desolder the Blue Pill and see if the joints on the SD card module really were bad. Plus, I had a dim memory of soldering that SD card holder being a huge pain in the butt when I put this thing together years ago, so there’s no way it wasn’t bad.

Did I desolder the Blue Pill?

No, of course not. What I actually did was: order a whole second set of boards to try and make assembly easier.

Version two board

I wanted to make a new “version two” board for a couple reasons:

The old board’s mounting holes were not compatible with anyone else’s mounting sleds. I copied the mounting holes from a few brackets I had lying around, so I wouldn’t also have to design and 3D-print some mounts.
The power connector had a completely wrong pinout, but it used a Berg connector, so someone could possibly plug in a “regular” one from an ATX supply and fry it. I wanted to correct this as well; I’m a little sensitive to voltage mismatches in SCSI emulators as of late for some reason.
I made the old board a little bit too small, which made it difficult to get in and out of the SCSI data cable, since I didn’t have enough leverage or a non-pokey place to grab it. Since I’m paying a flat rate for “anything under 100x100mm,” I just beefed it up a little bit.
It’s too hard to double-check the SD card soldering when the board is assembled, because the Blue Pill gets in the way. I added a whole second set of SD card headers, meant for one of the “Arduino” SD card modules floating around AliExpress. Even if you don’t have one, you can use these pins as test points to do a continuity check. Then you can be sure all the SD card pins are soldered properly on the surface-mount holder.

This revised one hit most of my goals. It made it a lot easier to test the SD card (just using the Arduino breakout footprint as a test probe), although I still globbed up the SD card holder with inappropriate solder globs to the roof. To try and fix this, I made the pads a little longer in the next version, so it was easier to hit them with the iron and ensure a good fillet.

For the new power connector, I tried to use a right-angle Berg connector since one was lying on my desk, but it interfered with the SCSI connector. So I just.. trimmed it. That’s not my smartest move, especially because the cable still didn’t fit afterward. I desoldered it and put in a straight-up Berg.

It was also hard to solder in the Berg connector (pads too small on the Digi-Key footprint,) and an already-legged Blue Pill didn’t fit in the hole because it was super tight and therefore needed thinner legs. I ended up fixing both of these in the next revision of the board.

As for mounting holes… those ziptie holes also interfered with the debug header, and I accidentally deleted the mounting holes from the PCB when I sent the board to fab.

Still, I think it looks really good! I’d be proud to entomb this inside an old computer forever.

Flashing the version two board

Because I didn’t want to desolder the Blue Pill from the yellow board, I grabbed one out of my bin of parts and soldered it down to the board. Before flashing it, of course…

I ran into a problem here. Both BlueSCSI-Updater and QMK Toolbox failed to flash the Blue Pill over USB, claiming a LIBUSB_ERROR_TIMEOUT at 44%. This seemed to screw something up and require me to reflash the bootloader with the STLink every time. After checking with Eric, it turns out that I had a C6T6 STM32, and I needed a C8T6 – not enough flash.

I was pretty sure I checked these when I got them to make sure it had the right amount, but that’s life. I wish I had tried to flash this before soldering it onto the board, but that’s life, too. Digging through my microcontroller bin, I found a C8T6 clone board with USB-C.

They also annoyingly added a 5V pin in the top-left corner, which on my board is expected to be ground, so I just didn’t populate that pin on the header.

The jumpers are also different, so I had to figure out an alternate technique to persuade the board to become flashable. I held the BOOT0 button while flashing the bootloader, and then pushed the nRST button when the BlueSCSI Updater was looking to flash the firmware over USB. This seems to have worked.

After pulling the old Blue Pill and putting this new, freshly-flashed one on, I fired it up only to find out that the status LED wasn’t blinking. It also didn’t bother writing a bluescsi log to the file, so the firmware seems like it was either not running or very mad at me.

I figured out the LED very quickly – this version of the Blue Pill also put the LED on a different pin, PB2, for some reason instead of the normal PC13 – and globbed an LED and resistor onto the backside so I could figure out what was going on. Five blinks meant “no SD card,” so I was essentially back to where I left off with the previous board.

Having done a lot of work and spent a lot of money to get to this point, I realized I was no longer having fun, and put this project back on the shelf for a bit. And by “a bit,” I mean about fifteen minutes, before I pulled it back off the shelf and started working the problem.

After an afternoon of confusion and logic-probing the board, I managed to determine that PA7 had somehow become severed from the MOSI line. I suspect that this happened when I desoldered the old Blue Pill. Maybe a pad was severed or folded over. No matter how it happened, I should have probably noticed it earlier – a fresh board from the JLCPCB box was just fine. A bodge wire on my now-heavily-reworked board fixed it, and suddenly BlueSCSI was detecting the disk images on the SD card and leaving behind a happy little LOG.TXT. Yes.

Does version two work on a Mac?

Coincidentally², the Bad ADB Mac LC had just had its hard drive dumped a few weeks prior to all this testing, so I grabbed its disk image off my backup storage and then threw that disk image on the SD card.

After some cable jiggling inside the LC, the Dirty ArdSCSIno booted the computer off that disk image like nothing had ever happened. It works!

What was the point of cloning it?

You might ask why I bothered to do all this, instead of just running off a few dozen BlueSCSI v1 gerbers, considering the BOM is essentially the same and that I’m running the same firmware on an identical pinout.

That’s a very good question!

To be honest, I’m not sure myself. I’ve spent more money doing it this way than I would have just using the existing design. However, I learned a little bit about SCSI (and a lot about the various mutations of the STM32 Blue Pill) going through this project.

Having an opportunity to look at the original ArdSCSIno code and hardware design was also beneficial. When things get quirky with weird 80s machines³, I’ll be able to understand better what the thing is trying to do.

Another real benefit of this is that, now that I have a working example, I can adapt it to new form factors. I can now build “built-in” ArdSCSIno/BlueSCSIs into the expansion cards for a variety of machines, producing a sort of modern-day hybrid SCSI controller/hard card.

I have a couple machines in mind for this kind of support. Maybe you can figure out why there’s a Blue Pill footprint on this weird daughterboard on this PC-98 SCSI card?

This project actually started as a low-cost alternative to SCSI2SD. How things change in just a few years. ↩
Projects tend to cluster into themes for me. This month, apparently the theme was “SCSI.” ↩
The BlueSCSI v2 firmware is making huge strides to fixing these, especially with SASI-originated machines. We’ll see more about this soon, but for a long time, ArdSCSIno had better compatibility with a number of lesser-known computers than BlueSCSI v1. ↩

Leaded Solder

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

What’s New?

Power Supply

McTwist

Shortages

Miscellaneous

The BOM Generator Script

Procurement

Used Parts Accepted Here

Assembly Notes

Better Tools

Uncontrolled Test

Uncontrolled Test

Controlled Test

A Third Leako

A Fourth Leako

A Fifth Leako

Conclusion

Untrashing a TRS-80

What do we have?

Case Repair 101

Further inspection

Power Supply

Video cable

Does it work?

Conclusion

Repair Summary

Leaded Solder vs. The Crazy 77

History

Background

First impressions

Beep Beep I’m A JP21

Test Fire One

Test Fire Two

JP21 Gun Salute

No Re-Assemble, Solderie

Reset My Head

Keybodging

Inconclusion

Repair Summary

Controlling the Wizzard

Overview

Previous version

Version 1 of the adapter

The sources

The design

Hardware assembly

Firmware

Starting Out

SNES Controller

Sticking Joy to the CreatiVision

How Do You Play Games, Anyway?

Get Off My Bus

More Joy, Less Schtick

Giving the SPARCstation some jumper cables

The class cut-up

Making New Memories

Commodore 64 black screen failure round-up

The origin

The symptoms

What’s a PLA?

Out of memory?

Painful memories

Conclusion

Repair Summary

You’re Out of Timer

Theory

Arrival

Vroom vroom, let’s go

What’s On The Menu?

Remote Possibilities

PC Engine

Soak Test

Okay, Seriously

Weird clunking sound

A Fortuitous Alignment

Conclusion

Repair Summary

Three Times the Fun