Leaded Solder

Embedding a bitmap font in your HyperCard stack

2026-09-08T00:00:00+00:00

I’ve loved HyperCard for a really long time now. As a kid, I made simple games in it. As what could arguably be called “an adult,” I now want to play with HyperCard itself to see what weird stuff I can make it do. Today, I’ll make it display text… in a different font.

HyperCard was developed for the original Macintosh as a way for anyone to quickly build interactive programs. It does this through a combination of “graphics-first” visual authoring and a very natural-like scripting language (which you very rarely have to actually use.) When I was in university, they still had a Mac Plus kicking around just to be able to use one prof’s astronomy calculator that had been banged together in HyperCard many moons ago.

After its initial release, HyperCard caught on not only as a way to make nice front-ends, one-off scientific utilities, and database programs, but also as a way to build games. Adventure games were best suited to it. Myst was famously developed in HyperCard, and so was Caper in the Castro, which is often held up as one of the earliest queer games.

An intriguing font

While reading up on some old Mac stuff, I came across a reference that the Concentration 2.2 stack for HyperCard by Sioux Lacy embedded a special bitmap font. That stack used its custom font for the purpose of displaying the card suit and value of the cards you are asked to match. For instance, you can see the 6 of diamonds and the 6 of hearts being matched in the image below.

Like many other things on the Mac, that font was no doubt embedded in the stack through a resource.

The Resource System

Let’s talk a bit about exactly what a resource is in Mac-land. As you probably intuitively know, even if you haven’t written any computer software before, there’s more than just code that goes into them. Even your most boring business application is going to need to define stuff like icons, pictures, big blocks of text, sounds, colour palettes, and custom fonts.

Historically, a lot of this stuff is just jammed into the program code in the form of #defines or a similar structure. You can see this in my BBC Bridge Companion Tetris clone, for instance, where I set up the graphics for all the little tiles in a block of code near the top.

There’s a few big problems with this model. For one thing, you need to rebuild the entire program (or hack it up in a hex editor) to do something common, like translating English help text to Japanese¹, or changing an icon. The bigger problem, at least for Apple in 1984ish, was that these things use up a lot of memory, and it would be nice to not need to have them in memory all the time.

On the early versions of the Mac system software, the Resource Manager is the chunk of the Macintosh Toolkit API that you use to ask for resources. If you’re not actively using all of the resources at a given time, the system software is allowed to recycle the memory used for them, which is important when you ship a 68000-based computer with only 128kB of RAM.

To implement resources, Apple engineering split executables (and other kinds of files) into two parts: the data fork and the resource fork. You’ve probably heard of these before, when people are upset about why their downloaded software won’t work on a classic Mac. Although the boundaries between these two would soon blur with the introduction of code fragments, for an executable application, the data fork would contain all the code, and the resource fork would contain all the resources.

A lot of old-time Mac owners probably have fond memories of opening up games and other programs in ResEdit, Apple’s official resource editor, and changing around menus and icons and whatnot.

Here’s ResEdit viewing the infamous help picture from Glider:

This model of separating the code from the “data” has been carried on to other operating systems as well, though Windows in particular implements it in a very different way.

For our purposes, we’re going to concentrate only on the resources held inside a HyperCard stack. A “stack” in HyperCard is a HyperCard program. Keeping with the rapidly-aging “index card” metaphor of HyperCard, it represents a stack of cards (or screens) and contains all the code and graphics for a HyperCard program. It also has a resource fork, and contains resources!

As a kid, this never occurred to me. HyperCard always felt like a walled garden that was unique compared to “real” Macintosh programs, so I just never tried to use a real tool like ResEdit on a stack. Turns out it’s incredibly consistent with the rest of 16-bit Appledom.

Be Resourceful

On my emulated Basilisk II install, I fired up HyperCard and made a new stack called test. In order to make sure my stack had a resource fork, I created an icon using the Icon Editor:

My next step was to close HyperCard. Because HyperCard automatically saves, I have to be careful about trying to mess with a stack without its knowledge. Then, I opened the stack in ResEdit, and saw my newly-created ICON resource sitting there in the list, with the very same ID:

ICON is just one of many types of icon resources available on the Mac. With the advent of System 7’s colour icons, many more types were added, such as cicn (colour icon,) icl8, and so on. HyperCard is monochrome by nature, however, so without a custom XCMD such as plotcicn², we’ll stick with the old-school black and white ICON.

Now that we know that HyperCard stacks do indeed use resources, let’s take a look at what a font contains.

Hello Jeff-Nichols

From my vast collection of shareware CDs, I pulled out one of my favourites: Power Tools for Macintosh 2.0. Published by SoftBit in 1992, this thing is basically a time capsule of random stuff they pulled off of an FTP server somewhere. Included in its sparsely-attributed collection are some fonts. I picked J at random, and found a font named Jeff-Nichols 72.

Previewing it in the built-in System 7 font viewer, it looks something like this:

Ah. An uppercase-only font, and a relatively ornate bitmap one at that³. That will be fine for this experiment.

I opened the font in ResEdit. It contains three resources: alis, which I don’t understand and don’t need, FOND, which contains font metadata, and nfnt, which contains the actual characters of the font. After copying the FOND and nfnt resources to my stack, I saved everything and quit ResEdit.

Using This New Font

This took a little bit of work. I wanted to create a field, which is akin to an InputBox in Windows land – it’s a box that the user types into. Although HyperCard has a nice UI for letting you pick which font that field uses, it didn’t pick up the “Jeff-Nichols” font. It showed me only the fonts that were installed in my operating system’s global fonts folder.

HyperCard has a nice feature called the Message Box, which is accessible on the command-M shortcut. When you pick it, a little command prompt appears at the bottom of the screen, which allows you to enter HyperTalk commands. Those commands are dispatched as messages to the HyperCard runtime, hence the name.

HyperTalk is HyperCard’s built-in scripting language, and it combines natural-seeming language with the complete inability to understand actual natural language. I could make dozens of blog entries about HyperTalk alone. After doing some backflips, I finally landed on this magic command:

set textFont of card field 1 to "Jeff-Nichols"

This revealed that I still had the font size set to 12, which made the ornate 72-size font indecipherably tiny. To fix this, I had to go back into the HyperCard font selector (which had now picked up on the concept of the Jeff-Nichols font) and tell it that the text in the field should be size 72. There’s probably a way to do that in HyperTalk as well, but I wanted to take the easy way out.

After that, everything worked.

You’ll also notice me using the icon I previously made on a transparent button on this card. Why? I dunno.

My assumption on how this works is that the Mac Toolbox, when asked to find this font, has a hierarchy of places to search for it, and “available resources” is of course one of those places. I’ve never really done much with fonts before, but now I’m thinking it would be a worthwhile thing to at least have a basic understanding of.

Why do this?

Why would you go to all this work to embed a custom font? Why not just install that font on the programmer’s computer, and use it to make a bitmap image on the card?

The obvious reason would be that you want to dynamically generate something. For instance, if I were making a HyperCard stack that generates pretty greeting cards, maybe I want to apply a foofy font to the text output in order to spell out your recipient’s name. You know, a classy card, as opposed to the ones your uncle sends. HyperTalk has a ton of commands available for programmatically drawing things: in fact, all of the extant drawing tools are just sending messages to HyperCard as it is.

Fonts also have abilities that icons don’t. Icons in HyperCard are limited to 32x32 in size, whereas you just saw that we can quickly draw an enormous, fancy-looking character wherever we want on screen with a custom font.

Although this discovery might seem of limited use, it’s important not to lose sight of the fact that a font is just one kind of resource.

There’s lots of other stuff that could be embedded into a stack, such as custom menus, big graphics, and sounds, such as the voiceover in JapanEASE (pictured.) I wouldn’t be surprised to find out that you can retrieve string resources from a HyperTalk script, which opens up the potential of localized HyperCard stacks.

Conclusion

There’s a lot more to touch on with HyperCard in general, and resources in particular. Bill Atkinson (RIP) and all the other hard-working Apple engineers like Danny Goodman made a really special toolset for quickly developing software. A lot of folks, myself included, can credit their start in computer programming to it. Even though it seems everyone at the time already knew about it, it’s fun to discover it still has lots of tricks up its sleeve after all these years.

Thanks for reading!

Translation is a really annoying problem to solve in older machines. For instance, on PC-88 games, every game stores its strings differently. And making a string longer or shorter (which often happens when you do something like translate “my dog” to “私の犬”) will often mean that you need to pad it, or find space somewhere else in the binary to put the rest of the string, then modify the code that calls that string. For localization alone, a common and easy-to-use resource model makes things much easier. ↩
An XCMD is an “extension command” for HyperTalk (an XFCN is an “extension function;” yes, like Visual Basic, HyperCard makes a distinction between calls that return a value and those that do not.) They’re usually implemented in a native language such as 68K assembly language, C or Pascal, and give HyperCard additional powers past what it was designed to have. For instance, you can add colour using the Color Tools XCMD. XCMDs are embedded into the stack as – what else? – resources. Later on in HyperCard’s lifecycle, Tom Pittman’s CompileIt! was developed, which compiles XCMDs defined in HyperTalk into native code. If anyone’s interested, I may do a followup article on that. ↩
The full preview text used by System 7, in case you’re wondering, is “How razorback-jumping frogs can level six piqued gymnasts!” ↩

Bridge Companion Becomes Block Companion

2026-08-18T00:00:00+00:00

Soon, you will know all the secrets of Z80 game programming. Or at least all the ones I didn’t know before I decided to port Tetris to a game console made to teach pensioners how to play cards. Things only get weirder from here, if you can believe that.

Let’s All Become Development-Environmentally Conscious

Since I don’t live in the UK, I’m not swimming in surplus Bridge Companions. There were a few eBay UK sellers willing to ship if asked, but only for ridiculous sums like £50.

When I first considered this stupid project, it seemed unlikely that I’d be able to get one of these little miracles to my door for less than $175 CAD all-in. I’d hate to spend that much money and then have the console sit while I developed the software, not to mention modifying it for NTSC composite, finding an appropriate 120V power supply, and hacking up the cartridge to use as a test module. Much better to develop the software first, and then trick someone I know over there to sending me a parcel without the eBay margins.

Out of prudence for my pocketbook, I decided to do my first experiments in an emulator. If I couldn’t make software work there, there was no point in involving the messy fun of real hardware.

That emulator is MAME, of course, which is usually my first stop for emulating any oddball system. The driver is bbcbc, and by reading over the source code for the BBC Bridge Companion driver, we can learn a lot about the console. Thanks for going first, MAME authors!

First off, the memory map and Z80 I/O map:

Memory region	What is it?	Comments
$0000 –$3fff	BIOS ROM	Sometimes two 8kB ROM ICs at $0000 , $2000
$4000 –$bfff	Cartridge slot
$e000 –$e7ff	RAM

I/O port region	What is it?	Comments
$00–$7f	Z80 PIO	Controller inputs, primarily. MAME source says only $00, $20, $40, and $60 are actually used.
$80–$81	TMS9129	VDP registers

With this information, I figured I could probably set up a decent Z80 assembly setup and start writing a Hello World for the emulated Companion. I didn’t understand the PIO well enough to use it, but I assumed that the BIOS would have wrapped some functions for that that could be determined later by reverse-engineering the legitimate cartridges.

First, I decided I would set up an emulator. After borrowing the BIOS ROM and a couple cartridge images from a certain internet library, I took an off-the-shelf build of MAME and ran the bbcbc driver with it.

Oops! I guess I need a cartridge. This is somewhat more blunt than the ColecoVision screen for the same error was:

What to play…? How about Bridge Builder? There, that’s much better.

Great, the emulator is working. I decided I would build my first program for the Bridge Companion, but despite the bravado spouted earlier in this post, I didn’t actually know how to program a Z80 with a TMS VDP. Sure, I’d experimented with Z80 assembly in high school and college, we all did, but that was just a phase.

First, I checked if it was supported by z88dk (which already supports virtually everything under the sun,) but unfortunately it was not.

Would it be easier to port z88dk than to just write my game in assembly? In order to know how to port z88dk to something, I assumed I’d first have to learn how to write assembly for it, so I set about re-teaching myself Z80 in general and the Bridge in particular.

I had some big questions:

How do I set up a cartridge that the console would identify as legitimate?
Where do I put my code?
Does the Companion’s BIOS offer any utility code to call that would make my life much easier? The ColecoVision had tons of BIOS subroutines, including controller scanning and writing buffers to VRAM.

To get started, I set up the two BIOS ROMs and the cartridge ROM in Ghidra at their appropriate offsets in the memory map, using the “Add to Program” option.

The Reversible Engineer

The cartridge ROM was looking very weird in Ghidra, which refused to disassemble most of the file. After poking around a bit, I wondered if the cartridge even contained Z80 code, as opposed to some sort of high-level scripting logic like TI GPL. It is a pretty specialized machine, after all, and the BIOS ROM is relatively huge at 16kB.

Maybe the best way to figure this out is to just run it and see what happens. I ran the Advanced Defence cartridge in MAME, with the debugger attached, using the following arguments:

% ./mame64 -debug bbcbc -cart advdefnc

Then I set the MAME debugger to pause execution whenever memory was accessed in the cartridge space and started the game with the following commands¹:

wpset 4000,4000,rw
g

I used “watchpoints” (wp), which are meant to detect access to arbitrary memory, instead of “breakpoints” (bp), which are meant to detect the program counter hitting a specific address. This is because, in MAME, breakpoints have to be set at a specific address as opposed to a range. In effect, this meant that I had to press g a whole bunch to skip past all the accesses to the cartridge before the program counter jumped into it.

I eventually found out that the program counter first landed in the $4000 to $7fff range at the address $401f . Popping back to Ghidra and starting to disassemble from that address, I now saw something that indeed looked like sane Z80 code. I confirmed this address with another cartridge (Advanced Bidding). It would appear we’ve got an entry point!

Since it didn’t seem that this entry point was hardcoded, I figured it would be worth understanding how it was arrived at by the BIOS. Probably the cartridge ROM has it somewhere… and indeed the bytes $1f and $40 were written at $401e and $401d , which are the first two cartridge addresses looked at by the BIOS. Thanks, MAME debugger!

I chopped the first $1e bytes off the Advanced Defence ROM and shoved them into a file and built them with z80asm:

; header - tell bios where we live
; copied from advanced defence, who knows what all this does?
dm 0x8b, 0xe6, 0x52, 0x1d, 0x40, 0x00, 0x00, 0x4e, 0x40, 0x26, 0x45, 0x00, 0x00, 0x1c, 0xe3, 0x00
dm 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xc9, 0x00, 0x00, 0xc9, 0x00, 0x00, 0x1f, 0x40

; main loop - at 0x401f
org 0x401f
run:
ld a, 0x10
inc a
jp run

And looking at it in the MAME debugger, I was able to hit the breakpoint at 0x401f and watch the A register get set to $10 , increment to $11 , and start all over again at the top of the run loop. Fantastic! I was now running my code on an (emulated) BBC Bridge Companion.

I had a lot of wrestling with the assembler I chose initially, z80asm. It seemed like its macro support had broken, or was not working properly, and there was no option to relocate code inside the produced binary. Even so, it just meant that the code got hairier and uglier than it really had to be. I asked around and then switched to zasm, which is much more pleasant, albeit still with its share of confusing error messages.

First Tile!

After a couple of aggravating evenings, I pulled together some example TMS99xx initialization code from an MSX-oriented tutorial with a super-helpful Z80 REPL and a very solid instruction reference. A few hours later, I had a blank screen with a single colour-shifting tile on it, and now I was off to the races.

Getting my (probably too fancy) initialization code to work just took a lot of debugging of stupid mistakes on my part, including but not limited to:

dec hl doesn’t set any flags, especially not the zero flag; you have to dismantle the 16-bit register into two 8-bit registers and compare them in a loop counter
cp a, (hl) is not the same thing as a = *hl; I meant to say ld but presumably was instead thinking about copying files in unix
In whatever the default mode I had it in was, zasm apparently won’t assemble any instruction that isn’t indented, so outdenting ret on one critical call meant that the program just shot off the end of the ROM and into outer space
A 32x24 screen means that the formula for targeting a coordinate in the VDP’s tile buffer is not TILES_BASE + (y * 24 + x) but TILES_BASE + (y * 32 + x). I swear I used to know how to program.

There’s not much I can say to defend myself. Don’t write code at 3am?

Look!! Something is actually on the screen.

Tiling My Shower

Now to make up some test tiles. At first, I wanted to use the font out of the BIOS ROM, but it’s in a strange, non-contiguous order for some reason.

Tile Molester (ugh) is starting to show its age in a lot of ways, so I ended up writing a cheap-and-nasty tilemap extractor in Python instead. I wanted to do it in Nim because I had such a good result using that language’s struct sugar with the PC-6601SR disk utilities, but the available image libraries were underdocumented or just plain didn’t compile. Back to Pillow!

Once my dumper extracted the tiles and turned them into an image, it was a lot easier to see how they are stored in the BIOS:

One slightly surprising aspect of the BIOS font is that there’s no character for “zero.” There are ones for “10,” “11,” and “12,” which I guess makes sense if you’re talking about cards.

The order of these letters inside the ROM is very strange indeed; letters are crammed into groups of eight and symbols are seemingly jammed in between them.

After thinking about it some more, though, it made sense: in the VDP mode I’m running in, you can only choose one set of colours for each set of eight tile graphics. Which means that if you need both red and black numbers (or J, Q, K, A) in the same frame, you have to duplicate them into different segments of the pattern description table. The order is confusing, as you would expect all the symbols and numbers to be front-loaded and all the letters to come in a contiguous block in ROM, even if not so when stored in VRAM. Maybe it makes the pointer arithmetic to go from card face number to “tile index” a little easier somehow?

The letter “H” at $2830 also had a weird line underneath it, as did “Z.” It’s probable the BIOS and games do something subtle about various characters being “shifted” by a row or column in each direction, because some of the card characters are also shifted horizontally. Although reading at an eight-byte alignment seems to have worked for twenty-four of the letters, two of them just decided to be jerks. Jerks.

I ended up redrawing² those two letters, as truncating them to 7 rows would have meant having to tweak the copy loop to bump the VDP pointer twice (skipping over the last row.) It was a little faster (if lazy and inefficient) that way.

Either way, setting up a quick pointer table and loading those into the VDP memory as well was cake itself, and only chewed up a few bytes of my (at this point) spacious ROM.

I could have spent a little more time trying to find the print routine in the BIOS, but I figured it would be easy enough to just write my own, since I’m primarily dealing with hardcoded strings (outside of the eventual score display) and I was feeling too lazy to reverse engineer the VRAM layout of the original games… even though discarding it ended up taking more time than that probably would have.

I also did a little bit of guess-and-checking between the MAME source. At first, I tried to do it the “natural” way by reading the Z80 PIO datasheets and manuals, and trying to set up interrupt handlers, but I figured I would cheat and look at how MAME does things.

Taking a big assumption that this was the right way, I wrote sort of the following input read code, which set the lower nibble on the A register, depending on the button state (0 = button pushed, 1 = not pushed:)

#define BBC_JOYSTICK_REGISTER $20
#define BUTTON_SET_1 $ef ; pass, spades, clubs, rdbl
[...]
    ; write $ef to the PIO
    ld a, BUTTON_SET_1
    out (BBC_JOYSTICK_REGISTER), a
    ; read the PIO's status
    in a, (BBC_JOYSTICK_REGISTER)
    bit 0, a            ; check bit zero of the register, if that bit is 0, set the "Z" flag
    jp z, PassWasPushed ; jump if the "Z" (zero) flag is set

Probably not the most efficient method (especially if I wanted to check all 12 buttons in a loop,) but it seemed to be working so far. We have interactivity!

After that, a bunch of utility-code-writing happened until I had a sizeable library and no further excuse for procrastination.

A Game Has Rules

Now that I had a good base set of code, a running console with a working cartridge slot, a working cartridge PCB to take my ROMs, and a composite mod so I could play the game on my bench TV, all that I had to do now was write Tetris. No problem, right?

I figured that I would keep the game’s feature list short, and not get too crazy. Although I’d written Tetris clones before, they were in much higher-level languages such as C and Rust, so I had to think about how to program common structures in Z80.

Wiebo de Wit’s blog series on writing 6502 Tetris was very helpful. Reading it allowed me to see how someone more experienced tackled the major problems like “rotating pieces,” scoring, and collision detection.

I was also trying not to get mired in “analysis paralysis,” or worrying too much about doing things the fastest/coolest way. I admit that the final assembly program is very caveman-like, slow, and is probably at least three times as long as it should be, but it’s there. At least I probably don’t have to worry too much about making my code too fast and overwhelming the VDP.

A lot of games only update the video memory during the vertical blank period, so as to avoid tearing. I didn’t notice much tearing, and I don’t need maximum performance, so I ended up doing things the lazy way.

In practice, the “lazy way” was writing to video memory whenever I wanted to, but with some NOPs after each write to make sure that the VDP had time to catch up before the next write attempt. This pattern is done on a lot of homebrew ColecoVision games, so I was fairly sure it would work here as well.

Still, I would like to one day experiment with deferring all the video updates to vblank in the future. It seems like the way that TI wants you to do it.

Collision detection was something I put off for weeks, but only took me about 45 minutes plus another 45 minutes of debugging to figure out. As with any programming, breaking it into smaller pieces is the way to go for Z80 assembly – there are just fewer structures provided with which to do so.

And rotation came shortly after, then stacking:

Piece selection is one of those things you don’t think about, but it’s actually very complex. “Real” Tetris implementations have a dizzying array of “grab bagging” methods, where they try to spread out the distribution of pieces, so that it’s more fun for the player, and less random. There are often even sub-methods inside the main method, in order to provide even more nuanced selection. I recommend reading the linked wiki page, it is very interesting.

I first started with a pure random selection, just to try and get anything down on the board. Once I had all seven of the pieces going, I had a weird bug where the “S” shape would transform into the “T” shape in one of its frames. It turns out that the definition was only 15 bytes long instead of 16, due to missing a space when I was trying to define the piece in ASCII.

Shortly after that, I got my first tetris:

Which exposed a bug in my “shift lines down” code:

After sleeping on it, I realized I had been using the A accumulator register to store an important value, and then calling out to a function that obliterates it. As a result, when I used that A register a little bit later to calculate a counter, the counter value ended up being somewhat wrong.

Since the accumulator is so important in an accumulator CPU like the Z80, it’s hard to write a function that doesn’t overwrite it. Lesson learned, again: don’t use “A” in anything that I’m going to do a CALL instruction inside.

A large portion of bugs I made on this project originated in not paying attention to subfunctions stomping on my registers. I will try to use memory more often from now on, instead of being quite as ruthless of a premature optimizer.

Ahh, that’s better.

Back to “grab-bagging” the pieces now. I knew it’s a fixed array of all possible piece types, shuffled. Through channelling my largely-wasted computer science education, I remembered the Fisher-Yates array shuffle algorithm, which worked out.

Man, we have algorithm names on this blog now? I should stitch some leather elbows on my stained car hoodie.

After a bit of debugging, I got it to grab-bag successfully. And they’re right: this is more fun than pure random.

A Weird Problem Emerges

As I started putting in the line-clearing animation, I ran into a strange phenomenon. Adding any more code past a certain point would cause the game to crash on startup, infinite-looped on the solid yellow screen of the BIOS. If I made the ROM really, really long by padding it with NOPs, the BIOS would show a weird “WHAT DO YOU BID?” screen and keyboard prompt.

Through experimentation, I figured out that it seemed to be happening when the code passed the 4800-ish byte range. I made a “broken” and a “working” ROM and then tested them in the MAME debugger, by setting a watch point for any read to the cartridge space:

wpset 0x4000,2000,r

After stepping through each one, I found that the cartridge reading was identical up until the BIOS reached out to a fixed address on the cartridge, $52e6 . The execution differed at that point.On my bad ROM, it would read a very long array of garbage and then start executing at a strange spot inside the BIOS. On my good ROM, it would read $00 within one or two bytes and then boot the main function in my ROM. $52e6 clearly was expected by the BIOS to contain some information.

What value is $52e6 in decimal? It’s 4,838, or about the number of bytes that my ROM was before things started to go haywire. Ah ha.

I picked apart some commercially-released ROMs in the hex editor, and found that all of them – every single one – just put $00 at this location. As a result, I’m not sure what this is for, but I’m guessing because it’s null-terminated, it is meant to be some kind of special string or perhaps even a miniature scripting language to tell the BIOS to set up some environment. Further, my guess is that because my string was “too long,” it ended up smashing the stack or causing some other malevolent state problem that confused the BIOS too much to be able to boot my game.

I instructed zasm to place a $00 value at $52e6 , and then tested with the “bad” ROM’s source code. Now it booted reliably, even after I added a bunch of garbage to it.

So why $52e6 ? It was one of the magic numbers I copied into my ROM from Advanced Defence, and those values are read by the BIOS on initialization. Because I didn’t want to re-organize my program layout, I quickly changed that magic number to point to $4010 , a part of the header that I knew would always be zero – because I also copied it out of the Advanced Defence ROM.

Well, now we know what that part of the header is: a pointer to some kind of null-terminated array for some unknown purpose. Specific, I know.

Adding the “Next” preview was straightforward, but laborious. Although I wanted to do things the fancy way, I ended up copy-and-pasting code and wasting a little bit of memory to make it happen.

Attract Mode

One of the biggest things I procrastinated on was the title screen. If you’ve ever done games, you know that exiting from the game into the “outer game” is a very annoying process. And I’d stacked up a bunch of ugly spaghetti code on my way to the Game Over, so returning to the title screen isn’t particularly easy.

I decided to get over this slothful hump by making the title screen pretty(ish), so I’d want to see it. Then I solved the problem by writing down where the stack pointer was when I started the game ($e7fe ) and then just forcibly resetting the stack pointer to that when I was cleaning up at the end of a game over. Who needs memory management?

I think when I do my next Z80/TMS99xx game – and there will be another, but likely not for the Companion – I’ll do a much better job of organizing game states and only having one big main loop. In other words, I’ll try not to paint myself into a corner next time. Hey, if it didn’t have one or two or fifteen hack-jobs in it somewhere, it wouldn’t be a real game.

I also added some (cryptic) sidebar info to explain how to play the game, because nobody is expected to look at a manual to figure it out. If I ever display this game publicly, I’ll probably put tape labels over the top of the Companion. The hand position required to play it is somewhat awkward, but believe me that it was the best I could come up with. The control panel is simply not designed for a two-handed, fast action game!

It Goes Back Home

Nearing the end of development, Pete Golding offered to test. You may remember him as the individual that started this whole mess in the first place, so it’s only fair that he helps out a little. He bravely tested the game on his BBC Bridge Companion (and UK PAL TV) and confirmed that it worked. It looks good even with the widescreen stretch and RF noise!

What about Canada?

Playing it on my own television, through a cheap PAL-to-NTSC AliExpress converter, is a little bit less pleasant. Although text is legible, there’s a lot of “swimming” in the patterns, and it’s hard to read things on the blue background. The game is very playable, however. I had a lot of fun!

What’s Next?

Now that the game works to my satisfaction, I am preparing to release it to the general public. As you can tell from the copyright date in the screenshots, this thing has been five long years of mostly procrastination on my part.

Because of some work and personal obligations, I haven’t quite had enough time to finish this stuff along with my originally planned release schedule. The next article on the blog will take a momentary break from the BBC Bridge Companion theme, but I’ll have a new story before the end of the year about the last push to get the ROM released and playable.

I wanted to wait until the embedded MAME on the Internet Archive could play it, so that nobody would be forced to embed an emulator, but I wasn’t yet able to figure out how to get that to work.

Once I do figure that out, or more realistically, ask someone for help, I will be sure to provide a link here to play it. That might be an entirely different project, too!

Although I don’t plan on making any fixes unless there are bugs (and there are probably tons,) I would like to provide a variant of the game where it’s sped up quite a bit. The first couple levels are a little boring, but I wanted to err on the side of letting rookies figure out how to use the awkward control panel to operate the game, rather than be instantly obliterated.

As this article series was being published, porchy on BlueSky told me about a 3D-printable BBC Bridge Companion cartridge shell. This shell looks like it has most of the original measurements intact – I think I might just make myself one for this game as a shelf trophy.

Thank you for taking the time to come and read about my weird little game, on this relatively unknown little system. I hope you can also do fun stuff in unexpected places in your own life – let me know about it when you do.

I didn’t find this out until the project was almost done, but you can get MAME to pre-load a bunch of commands into the debugger using the -debugscript command. This would have been useful for me to synthesize during the build process, rather than manually keeping notes of where various symbols ended up. You live and you learn. ↩
“Redrawing” makes me sound less lazy than I am. I made my Python script generate the zasm directive to produce these letters, copied it into my source file, and then just changed the bad line – $ff for H, and $80 for Z – to $00 . ↩

Composite Companion

2026-08-11T00:00:00+00:00

The BBC Bridge Companion has RF video output from the factory, but that’s not good enough for its cutting-edge pastel graphics. In order to get things looking their best, I spent a really long time making a composite video mod for the system rather than finishing off my Tetris clone.

Reaching into my pile of old homemade boards, I pulled out a second-generation Famicom AV mod board¹ and assembled it with a THS7316 video amplifier IC. Obviously, I skipped the audio components, and then hardwired in a yellow RCA female jack. Some ultra-cheap test hooks later, and I had a pretty decent unamplified-composite-video probe!

Using this, I figured I’d be able to hook the probe into various spots on the motherboard. By trial and error, I could work out where to grab composite video from before it goes into the RF modulator.

New Scope, Who Dis?

Of course, none of my candidate points for picking up a video signal seemed to work. I was a little confused, so I shelved it for awhile and then picked up a new oscilloscope².

Before we get started, it’s worth pointing out that I still do not really understand composite video termination. That will probably become really obvious as this article proceeds – I’ve gotten better, but there is so much to learn about baseband that I still feel very uncertain about all of my initial findings and conclusions. Be gentle.

The Tek 2246 I’d been using is great, but it’s just too big and runs too hot for little projects like this. Even in the winter, it turns the room into a sauna. I got a Rigol for cheap to help with this project. It, too, boasts a PAL video trigger mode that seems like it would come in handy.

Almost immediately, I saw part of the problem with my little composite probe. When scoped, the output was only a handful of mV. When I was blindly connecting my composite video probe to everything I could find earlier, I had hooked it to pin 12 (“Video Input”) of the LM1889… but the scope told me that pin 12 had a 13.2V signal. The THS7316 amplifier datasheet says it has an absolute limit of about 5.5V input, which means I probably sent that little chip to silicon heaven. That would certainly explain why I wasn’t getting valid composite video out of it. Oops. I guess that’s why they make oscilloscopes, so you can measure first before plugging things in.

On the input to the RF modulator box, I saw a signal that looked like composite video, but it had a voltage of 1.86V to 3.18V. After asking some questions about it, it was determined that I was probably measuring it wrong. Since the output of the video was not connected to a TV, the 75Ω load that a TV usually puts on the line was not present. I ended up ordering a 75Ω BNC terminator and a BNC tee to bolt onto the probe, and took the measurements again.

With the terminator installed, I was now reading a more reasonable 2.49V peak-to-peak. This obviously isn’t ideal. From what I was reading, you want to aim for more like a 1Vpp signal, where 700mV of that is the colour and about 300mV of that is the sync dip when showing a pure white screen. To make matters worse, I was measuring the “No.” screen. It’s a very yellow screen, so I’d have to go by the sync amplitude to dial the divider in instead of aiming for the 700mV of white or the 1V of the whole signal.

I hacked up another Famicom AV board, adapting it onto a solderless breadboard with pin headers, and set up a simple output circuit. The first voltage divider I came up with (1.5kΩ/2.2kΩ) produced a 560mV sync signal, which was clearly way too strong. After asking blog friend Tianfeng for help, I put in a 1.5kΩ/470Ω divider at his recommendation, which knocked the sync down to about 300mV.

I couldn’t resist trying it on my backup camera monitor. You’ll notice it’s in monochrome. This monitor is super picky with signals and won’t lock on to a colour burst or vertical hold from any TMS99xx-based system, any Sega Genesis, or several other machines I’ve tried. It simply seems incapable of doing 240p at all. So why keep using it? Well, it’s small and easy to set up… and I don’t care if I blow it up.

Building Test Software

I was on my way, but now I needed a way to get a pure white screen to test against, in order to make sure my voltage divider will provide the right levels when presented with whatever output voltage the console generated for ‘pure white.’

With about an hour of work, I modified my in-development Tetris program to generate various colour-test screens instead of addictive puzzle games. This new ROM displays solid white when it starts, and pushing the PASS key on top of the BBC Bridge cycles between screens of different solid colours. Pushing the SPADE button will toggle on some sorta-SMPTE colour bars (see above.) This new program was burned to a 27c512 EPROM, and placed into my bodge-wired new ROM board.

It’s running, so let’s break out the oscilloscope.

Oh man. That looks like a lot of power-supply ripple. I had never built a video circuit on a solderless breadboard prior to this, so I wasn’t sure if the noise was coming from the extra capacitance of the breadboard, the Bridge Companion, or somehow from the bench supply powering the console’s original linear 7805. Even clamping 100µF and 0.1µF decoupling capacitors onto the 5V supply lines of the mod board didn’t make a sigificant difference.

Did You Have Fun At The Mixer?

After poking around the board with the scope probe, I figured out that the ripple was coming from some of the 12V-related signals on the LM1889. 12V on this machine is generated internally from the relatively calm 5V supply, so something wasn’t quite right in the boost circuit. Bravely, I decided to ignore it until later.

It was difficult to find somewhere good to snipe the signal. As already mentioned, the final stop before the RF box had very dim colour. Working backward, I found that the chroma (colour) and luma (brightness/sync) were mixed on the board just by shorting them together, which was a bit of a surprise.

That chroma was still too weak when it arrived at the output circuit, because it was mixed at nearly 1:1 with the luma, which made it hard to divide into 1.0V total without making the colours way too dim. I needed something closer to a 2:1 chroma:luma ratio, in order to try and hit the 2:1 colour:sync ratio that a good composite signal should have. So I started trying to figure out how the LM1889 worked.

It was at this point that I remembered this unit was the very same Bridge Companion that had screwy RF colour, a lot of video noise, and tuned itself to the wrong channel. I decided it might just be a good idea to replace the handful of aluminum electrolytic capacitors involved in the system’s operation.

Position	Capacitance	Voltage	Comment
C3	10µF	50V
C10	100µF	10V	Fishy smell
C12	10µF	50V
C13	10µF	50V
C15	10µF	50V
C19	10µF	50V
C21	10µF	50V
C23	10µF	50V
C25	10µF	50V
C37	100µF	25V

I did this before I got my nice ESR meter, so no scientific proof of cap failure for you. Just vibes.

After the recap, I lost confidence in my composite-mod building abilities and shelved the project for over a year. I didn’t even test the recap.

Starting Over

When I came back to it, I tried reconstructing the composite mod on a solderless breadboard, following the Texas Instruments “AC-coupled” design specifications. This involved remaking some cables, because most of my jumper wires had been popped off and used for other projects.

Colours! That’s good enough video quality for me, especially considering the green gun is not really working on this PVM³. After some measurements to figure out the dimensions and mounting points of the original RF modulator, I made up a quick PCB that duplicated the circuit from the breadboard. I don’t think that shotgun-recapping the system was really what was keeping my composite mod from working before, but it made me feel a bit better.

There were a lot of little things I had to mess with to get the physical alignment right. I’m glad I left room to slip it around for left/right, up/down, tilt. After all that, I was mercifully ultimately successful in getting the port to point out of the hole, such that the composite video cable could still fit into the much smaller opening when the lid of the console was put on.

I also went back and touched up that fraying +5V jumper wire, don’t worry, you can trust me.

It fits! Nice.

Composite Conclusion

Making an AV mod for this system wasn’t as hard as I had originally thought it was going to be. Maybe it’s because my standards slipped. But there is one solid lesson I learned: if you see a lot of ripple on the scope when you’re trying to dial something in, swap the caps already. It’s a lot easier to work from a known-good base than add that extra frustration for a repair that literally took ten minutes to do.

Repair Summary

Fault	Remedy	Caveats
(1984 unit) RF video output seems unstable, noisy.	Recap system.

The big difference between the 1st and 2nd gen Famicom composite mod is the presence of the 75Ω output resistor. The 3rd generation, which I wrote about in Revenge of the Famicom composite video mod, is just a smaller version of that board with an integrated voltage divider circuit. ↩
Most long-time readers have probably seen me use this scope before. The work in this post was done almost five years ago – I have greatly procrastinated on writing up and publishing this series. ↩
Long-time readers will feel reassured that in the several years since this work was done, I still haven’t fixed the PVM. Thing will keep running pink as a pig until it bothers me enough to deal with one billion caps in a box about the size of a coffee mug. ↩

Companion & Companion’s Cartridge Complication

2026-08-04T00:00:00+00:00

In this phase of the BBC Bridge Companion series, we’ll talk about a few simple tasks. Buying a system. Buying another system. Fixing both systems. And developing a cartridge PCB for them from scratch. Doesn’t everyone spend their weekends this way?

First, I’d been puttering along in the emulator, but had not yet taken the plunge on the real hardware yet. It’s expensive buying things from eBay, and even moreso when it’s another country’s eBay, trying to get a fair deal for their prized government-backed information technology treasures.

Oops, eBay

Initially, I really did not want to pay the eBay asking price of $175 for a Bridge Companion, and then also pay a huge shipping fee on top. I kept looking at eBay, but missed when a boxed and complete unit was listed. PeteG from the re-enthused Discord server noticed, knew I was in the market, and gave me the tip-off.

After a week-long bidding war, I scored that boxed Bridge Companion for £90 (about $145 CAD at the time,) shipped. This is definitely more than I planned on spending, but the lure of “cheap shipping” is powerful indeed.

It arrived very quickly and it was extremely well packed. I was unwrapping bubble wrap for nearly ten minutes just to get the box out!

The overall condition was fairly good aesthetically; there was a slight discolouration of the plastic that will probably clean up with a scrub. Definitely not filthy. The buttons felt wobbly but not terrible, which is good since they were the only input mechanism in this console.

Unfortunately, during inspection, I found out that the cartridge slot has had a rough past life. A handful of the leaf pin contacts are either bent backwards or have popped out of their retainers entirely. Even after some work with an angled pick, cartridge contact seemed like it would be spotty at best.

Check out the heavy hardware and reinforcement brace holding the slot in place! Now that’s some serious strain relief, which I guess you can do when you’re charging £199. Great build quality.

There’s no marking on the system of what the AC adapter voltage or polarity was; it just had this marking saying that I should use only the appropriate adapter. This lettering is very clear, and the case overall seemed like very well-done injection moulding. Again, good build quality, possibly helped by the fact that their tooling couldn’t possibly have gotten that many uses.

Heber is a contract manufacturer and hardware designer in the UK; they’re still around, and still make video game equipment, including casino game motherboards and the MiSTer Multisystem. I’m not sure what happened to Unicard.

The 9-volt AC adapter included in the box is not really useful to me. It has a UK-style plug and expects 240VAC, and the polarity (or even whether it’s DC) isn’t indicated on the label. Additionally, the plug seems to have been added by the end-user¹, as it’s “hardware-store grey” and has some repulsive sticky residue on the cord that might, at one point in the past, have been electrical tape. Surprisingly, the cord itself was still supple – it was the electrical tape’s plasticizer that was attacking the styrofoam around it.

After checking inside the machine with a continuity tester, I determined that this barrel plug was centre-negative (the centre pin of the barrel plug was connected to the “common” pin of the 7805 voltage regulator.) A Sega MK-1602 adapter (Model 1 Genesis/MegaDrive) fit perfectly and provided the necessary polarity, voltage, and current ceiling. It works with everything! Gotta pick up more of these little miracles.

Let’s take a look around while we’re in here. Don’t want to start if there’s something else wrong, after all…

Diagnosing the Companion

The first thing I noticed when taking apart the Companion is that the screws were a little weird. They’re coarse-thread Phillips thread-forming screws, to be sure, but the cross head wasn’t exactly cross – more resembling a wounded bird. I’ve never really seen screws like this before; maybe they’re made of a very soft metal and bent before camming out at assembly. I had to be very careful when removing or installing them not to strip out the heads any further. A future improvement would be to go to the hardware store and just buy new thread-chasing fasteners, as they appear to be all the same length and pitch.

No dealer serviceable parts? That’s one step beyond Radio Shack. I don’t know what store you would have bought this at when it was new, but they were insufficiently skilled to repair a machine as advanced as the Bridge Companion.

My serial number was 6123. If they started at 0001, I guess we can assume there are at least 6,123 Bridge Companions out there. That feels like a safe bet, because mine seemed to actually be a revised version - different from the photos I’d seen on the internet beforehand of other Bridge Companion motherboards, and another Bridge Companion motherboard I would later have in my hands. But I’m getting ahead of myself.

Again, it’s worth taking another stop here in the story to reinforce that the plastic panels on this thing are of very high quality. Even though they’re thin plastic, the moulding is sharp, without flash or ugly casting artifacts, and the dimensions are nicely square. It makes me wonder if they reused an injection mould from another product to keep the tooling costs down – the buttons especially make me think of photocopiers.

Once the plastic “chin” piece is removed, the top part with the buttons comes right off. It has a ribbon connecting it to the mainboard, but the pins are so thick that this ribbon pulls right out with no problems. Nice.

The front panel with all the buttons had this chalky white crap on the backside, which I think must have been leftover flux. It didn’t move very well with alcohol, so I had to keep scrubbing at it until it did.

The control panel PCB itself (copyrighted 1984) is just a normal carbon-contact setup, and is shorted by a membrane that is itself depressed by the funky plastic buttons. There’s a power LED here, too, which is a nice feature… on a machine that doesn’t even have a power switch. I guess they expected you to switch it off at the outlet instead, which is not really a thing I could do here in Canada.

The routing on the motherboard is quite good. Now that I know how difficult it can be to do a clean route, the relative lack of vias is impressive.

On the motherboard, we see the big important chips. A Z80, 2kB 6116 SRAM, the BIOS ROM (a single 16kB 27c128 instead of two 8kB 27c64s like in the picture I’d seen earlier), the Z80 PIO, and a TMS9129 VDP with a pair of its own TMS4416 video DRAMs offering a vast 16kB of VRAM².

This 12-input/10-output programmable logic array (PAL) chip most likely contains the memory and I/O address decoding for the system. It’s interesting that the system is using UV-eraseable EPROMs instead of mask ROMs; perhaps production was too low to justify the expense of mask ROMs³.

This 7805 produces 5V for the rest of the system. It’s also strapped to this handsome black heatsink which has a thick coating of some kind.

The RF modulator is your normal UM1233 setup, with no sound hooked up to it of course. I’m sure that the reason these modulators are so common is because they had to get them certified for radio interference. By using a whole module, Heber, Sinclair, etc could outsource the analogue-TV part of the compliance – and all the legal headaches that entails – to Astec.

Near the RF modulator is a common IC in PAL game consoles of the era: the classic LM1889 composite video modulator (I know the name is a little confusing.) The area nearby also has an MC14066 quad switch, which according to the datasheet, is probably also involved in the output video circuit, and an MC14013 D-type flip-flop, which is maybe used as a clock divider or to alternate which field of the video signal is being displayed. I’m not very familiar with PAL generation, as this was the first PAL system I’d ever looked at the video output for.

Let’s take a look at the cartridge before we finish up. It’s a very unusual size that reminds me more of an electric razor than a game cartridge. Thick, narrow, and stocky…

It also has a lot of unnecessary plastic “greebles” all over it that make it look a bit like a weird science fiction prop. There’s even an interesting “skirt” cutout on the back so you can see the gold-plated, non-beveled edge connector. The cartridge feels solidly-built and is made of thick plastic, which I’m sure helped sell the sense of being a quality product to the end customer.

I’d like to thank whoever at Heber decided that the screws should be exposed without having to remove the cartridge label, unlike some systems. Once the four screws are undone, the PCB pops open… look at all that empty space and super-shiny solder mask!

The only ICs in here are the socketed(!) 32kB 27c256 EPROM(!) and a 74ls08 AND-gate, of which most of the inputs are grounded. It’s interesting that there’s a 1987 date on this board. Since this game was packed in with my Bridge Companion, it would mean that they were still selling these consoles for at least two years after release.

That’s enough screwing around inside the machine for now; let’s move on to getting something to happen, even if it’s in PAL.

Video, Kid

Blog superfriend Nicole at Nicole Express published a great article on the Sears Tele-Games Pinball Breakaway TV game. Not only is it a fun anachronistic read, but you’ll also notice that she hooked up a fancy Chinese-made device called the RF-to-AV in order to make it talk to her composite capture rig.

Realizing an opportunity to get out of this without having to do a composite mod to the Companion on top of everything else, I sent away for my own and got it a few weeks later for under twenty bucks. The menus are completely inscrutable (all in Chinese that’s also somehow extremely blurry) but the price is right.

At first, I had some decent success locking onto a signal using my PAL-capable PVM. You can have your choice: with a hellish orange glow, or with a super-wiggly white background that appears purple because my PVM is crying for help that I refuse to give it.

Both times, the PVM identified the successful signal as 525-line PAL, which I don’t think is actually correct for UK “System I.”

Eventually, I was completely unable to lock onto the signal after turning the RF-to-AV off and then on again. After wasting about an hour trying various combinations of standing on my head and cursing the gods, the best I could hope for was an out-of-sync image where I could just barely see smears that I knew were supposed to be text.

It seems (from reading other sources, including the seller’s ad) that the adapter’s “autosense” population of the channel selector is based at least partially on sound coming across the RF. Since the only thing the Bridge Companion is sending on the sound channel is ambient space noise, it’s not likely to work well with this approach. I could see the autosense routine slowing down as it approached 591MHz (“Channel 36” on UK System I,) but it wouldn’t realize a channel was actually there.

I ended up carrying the whole mess to another room and testing it on my Samsung 910MP, the gently-battered⁴ LCD TV that somehow is capable of getting a crappy image out of any source – but I mean it when I say any source. Since it’s a modern set, it can change its fancy little microchippy guts to understand RF from any region.

After switching the 910MP into “Europe/UK” mode and then auto scanning the channels, it found the Bridge Companion at 592MHz and plunked it into “Channel 1.” Now it’s a very bright yellow, rather than the emulator’s tan. Just what colour is this damn thing supposed to be?

I did a little more fine tuning to keep the image from wiggling, and now I finally had a sort-of-legible way to see this obscure PAL RF console in my largely NTSC composite home. But, uh, I didn’t like it.

Winning At The Slots

I didn’t expect I’d have to repair the cartridge slot on this machine, but that’s life.

Since the plastic shell of the slot, its long mounting pins, and the reliefs for the reinforcement braces all seem to be more than a little unique, it worried me that it would be a challenge to find a replacement part.

The solder joints on this slot were in pretty poor condition. If I hadn’t felt the screws on the case snap loose for the first time, I would have assumed someone had already tried to repair it. It’s an interesting contrast to the expensive cad-plated (or maybe just yellow zinc-plated) metal brackets holding the 2x20-pin connector down.

A brand new right-angle 2x20 0.1” edge connector did indeed prove hard to get. It doesn’t really make a lot of sense; I could even find 2x21s. I first grabbed a $10 Sullins from Digi-Key – the only one in stock – only to find out it had a death grip on the cartridge. Just like with the second failed cartridge slot used in the Leako, also a Sullins, I missed the part of the datasheet that said it could only handle 1.57mm thick PCBs and not 1.6mm ones.

There was a 40-pin, right-angle, 0.1” edge connector listed at Digi-Key by TE AMP, but it was listed as “submit a quote request.” For laughs, I did, and they came back and told me that they’d make some if I promised to buy a minimum of 2,688 units, at $5.10USD per connector. I can afford a lot of 44-pin connectors to cut up for $13,727.62 USD!

In the meantime, I found an eBay seller in Taiwan offering some connectors of an anonymous brand, so I bought a box of ‘em. This new mystery-meat connector still had a bit tighter of a grip than I would prefer, but it was still possible to insert and remove the cartridge with a lot of force, probably due to the cheap-feeling pins.

Initially, I was not comfortable with this fix, worrying that the extra force of insertion would damage the console’s board, but once it was completely soldered up it had a surprising amount of strength, and it got easier with repeated insert/remove cycles. For a little extra insurance, I also applied a thin strip of double-sided Gorilla Tape between the PCB and the cartridge slot, which is surprisingly sticky stuff, albeit quite thick.

With a shrug, I figured this was good enough to keep the project moving along. Since I was planning on making my own cart anyway, beveling the edge on it would make the cartridge easier to insert and remove, and thus compensate a little bit for the tightness of the new connector, and if the slot ended up pulling up a bit anyways, I could use my garage vise to bend up a new metal bracket and push the new connector down.

As for removing the slot, it wasn’t too bad. Originally, I planned on using the FR-301 desoldering gun, but I decided on a gentler approach when I realized the solder mask was damaged on the underside:

I ended up snipping each of the pins off the old cartridge slot and desoldering them individually. It’s not as pretty of a result, but the chances of pulling a pad or trace are much lower.

The old cartridge slot, of course, is not in the best condition after this treatment:

Sorry, I couldn’t resist.

I wasn’t sure initially if the metal brackets holding the old cartridge slot down were zinc- or cadmium-plated, but this seems pretty likely to be cad-plating to me:

Yeah, Here’s The Cartridge Pinout

While the slot was removed, I had easy access with my multimeter probes to help map out the cartridge slot. Here’s what I found:

	B	A
20	/ROM_CE Select 8kB bank 4 $`0xa000` (PAL pin 15)	PAL pin 16
19	/ROM_CE Select 8kB bank 3 $`0x8000` (PAL pin 14)	Z80 IORQ
18	/ROM_CE Select 8kB bank 2 $`0x6000` (PAL pin 18)	Z80 MREQ
17	/ROM_CE Select 8kB bank 1 $`0x4000` (PAL pin 19)	GND
16	D3	D2
15	D4	D1
14	D5	D0
13	D6	A0
12	D7	A1
11	A10	A2
10	/ROM_OE	A3
9	A11	A4
8	A9	A5
7	A8	A6
6	A13	A7
5	A14	A12
4	VCC	Z80 WAIT
3	PIO PA1	Z80 CLK
2	Z80 WR	Z80 M1
1	A15	PIO PA0

Tons of useful signals here. A₁₅ seems to be part of an input to the PAL, as well, which probably exposes some bank-switching ability for very large cartridges. Following the pattern, it’s very likely that the unknown A20 edge pin is meant for switching in a whole other bank, but Bridge Builder only goes up to a 32kB ROM and I definitely don’t need more than that for Tetris.

Obviously, this process is made more difficult by the opaqueness of the PAL itself. Without building something like a DuPAL board, I was probably not going to easily reverse-engineer it.

A Companion Companion

To muddy the waters even further, I still had an email notification on eBay set up for new Bridge Companions. One came up from a house-clearing firm, was sold as totally untested, and came with only the cartridge. I made an offer for £25, which was immediately accepted. A very good discount over £90.

The next day, PeteG (who, you may recall, started this whole mess) got one for £5, so I didn’t even get a chance to brag about my great deal.

Why get another? Well, as my grandfather always used to constantly say, “whenever you’re building your own circuit board and trying to jam it into an old machine that you can’t easily get a replacement for, buy another one of them to mod.” He was a weird dude, but he didn’t steer me wrong on this one. Thanks, Grandpa.

When it arrived, I couldn’t help noticing the differences. For instance, this one was serial number 00577! When I opened its copy of Bridge Builder up, it had a date of 1984 and the entire GDP of Great Britain in 64Kbit socketed ROMs. This is how I figured out the “8kB” bank switching in the pinout up above.

The Magic Happens

Through collecting two machines, I now had:

A working cartridge slot in one of them (the second one;)
A socketed cartridge that accepted 27c256 EPROMs (from the first one;)
A television set that sort of worked to display the video coming out of these.

I burned my in-progress test ROM, which didn’t do much more than display a couple in-memory variables and put up the basics of a playfield along with “HELLO WORLD” esque messages to a W27C257 EEPROM (originally bought for the Leako project) and slammed it into the 1987 Bridge Builder cartridge. Thanks for the socket, Heber!

Unfortunately, the new Bridge Companion didn’t show up on the same channel as the old one! I had to re-scan channels again, and ended up with a very bouncy, glitchy output from the new one. It will need a service, but that doesn’t mean I can’t use it to test my game… on real hardware.

I popped the cartridge in, and then plugged in the DC power jack…

Holy crap. It was muddy, it was swimmy, it was glitchy and unreadable, but it was mine.

Even the controls worked! Here’s what it’s supposed to look like, without the “help” of a disintegrating RF output:

Hardly a “game,” but it’s still all my own code and VDP initialization, learned the hard way, and running on the real hardware. What a thrill! Why would anyone do drugs when they could just push one byte at a time to a Z80 I/O port?

The Dumb Cartridge

Because I intended to keep both copies of Bridge Builder intact, I quickly remade the cartridge in KiCad and sent it off for fabrication. I was pleased to find that JLCPCB has a sort of “secret menu,” where they’ll still bevel the edge on your PCBs without also paying thirty bucks for gold fingers.

This board was intended to support up to 64kB 27C512 ROMs, although as far as I can tell, no games this large were ever officially released. With just a cheap tin DIP socket installed for the ROM, it’s not great for iteration speed, but most of my development is done in the emulator anyway. I figured it was all I’d need for now.

I decided to test out the board, and my freshly repaired cartridge slot. Unfortunately, it didn’t work. The cartridge, that is, not the repair.

When trying to load my test ROM on my new cartridge PCB, all that I got was the “No.” screen, indicating that the BIOS was not able to read the first couple bytes of the cartridge ROM in order to find the entry point. Those bytes are there, since I’m using a known-good ROM, so what’s up?

Where did I screw up?

My first check on the new cartridge PCB was the obvious one: making sure CE and OE were getting toggled. CE got bumped at startup, just before the “No.” screen appeared, so the chip-select signal was getting all the way from the Z80 to the PAL to the 74HC08 to the ROM. OE is driven by the console, and was getting pulsed periodically. Not the problem.

I verified the pinout using the pin-header breakouts at the bottom of the cartridge PCB, and the Z80, and made sure there were no shorts between adjacent lines. Doing breakouts like this is a real time saver when you run into an ugly situation like this, and I’m extremely glad I do it even though it makes the routing a lot more annoying.

Since the ‘256 has a programming-voltage (Vpp) pin in pin 1 where the PCB supplies A₁₅, I decided to cut that off and ground it out. This was of course a fruitless endeavour, because the erasing voltage of the chip I was using is 14V, and the programming voltage was 12V, and the Companion doesn’t use twelve-volt logic. Nothing changed.

To make absolutely sure that the chip select logic was working, I bypassed the “decoder” by removing the 74HC08 and jumping from the CS_0x4000 line directly to the output that feeds the CE pin of the ROM using its empty socket. Doing so would disable paging, but I didn’t need it to read the first handful of bytes at $4000 , which the BIOS checks before deciding to show the “No.” screen.

Unfortunately, this jumper job made no difference, and since I had earlier observed a pulse on the ROM’s chip-enable pin as expected, I could reasonably assume that the decoding ‘08 was not at fault. All this check did was rule out that a chip select other than CS_0x4000 was enabling the ROM.

Even though I was certain that, since it was an active-low signal, the fault wasn’t caused by my use of a 74HC08, I put a brand-new 74LS08 back in, just to reduce the number of differences from the original PCB.

Finally, I decided to just brute force things. If the old PCB worked, and the new PCB doesn’t, there must be some difference that keeps it from doing so. Eventually, I realized that the A₁₄ line was not run on the old PCB to the ROM. Oops.

After thinking about it, I realized this made sense. Because the address lines coming into the cartridge are the ones of the CPU, any address delivered to the cartridge is absolute. As such, a read to $4000 (the start of the cartridge in the Companion’s memory map) sets A₁₄ and no other address line.

Since we pass that A₁₄ blindly along to the ROM, it’s like we’re asking the ROM to return the byte at $4000 of itself, when we actually wanted it to return the byte at $0000 .

No wonder it wasn’t working if the ROM was returning some garbage from 16kB into it instead of the actual start of ROM! I cut the A₁₄ line, and now I didn’t get the “No.” screen anymore.

OK – I’d have to figure out a better way of doing decoding if I want the cartridge to actually work with a big ROM, but the colour test program is small enough that I don’t have to worry about page switching for the time being.

It worked, and now I could continue developing my game, knowing that I had a cartridge to put it in.

Repair Summary

Fault	Remedy	Caveats
(1987 unit) Cartridge slot is damaged	Replace cartridge slot.	New slot is tighter fit than before, has really poor strain relief.

The manual actually describes what kind of plug you should buy to graft onto the adapter. It was a bit shocking to me as a Canadian that a manufacturer would “trust” a customer with something like DIY power cord construction. After asking Johnny about it, it was explained that some English electronic products were sold through to the mid-80s without a plug due to competing standards and also cost savings. A standard was established in the late 80s, which also seems surprisingly late. ↩
Like the NTSC TMS9118 in the PV-7, the PAL TMS9129 only requires two DRAMs for video RAM. The TMS9918/TMS9919/TMS9928/TMS9929 have DRAM refresh and indexing logic for eight. ↩
Porchy on BlueSky let me know that they have brute-forced and dumped the BBC Bridge Companion’s PAL at IC1. Thank you Porchy! If anyone is feeling ambitious, it should be pretty easy to make your own clone Bridge Companion at home now. ↩
I’ve told this story before, but the previous owner told me, after taking the $10 cash I paid for it, that he thought it got hit by lightning. ↩

The BBC Tetris Companion

2026-07-28T00:00:00+00:00

Ever done dumb stunts for your friends on a dare? I was hanging out with a bunch of fellow old-computer ne’er-do-wells when the topic of the BBC Bridge Companion came up. It was a useless thing to own, they said, although many of the assembled group had already owned one at some time or another. If you don’t know how to play bridge, then why even bother? Well, I know how to play Tetris, and I know how to write Z80 assembly, or at least I thought I did.

Over the course of the next few weeks, I’ll be publishing more in-depth articles about the details of the Bridgetris project. This post is a shorter overview of the entire project, to give a rough idea of the overall tasks and progress.

A Bridge to the Past

First, a bit of history. What is the BBC Bridge Companion, and why did this thing consume my attention and free hours for a frankly ridiculous and unjustifiable amount of time? Put simply, the BBC Bridge Companion was a game console intended to teach you how to play the card game bridge on your television set.

It’s BBC-branded, because at the time they had a popular bridge-instruction television show, BBC Bridge Club, with some top-flight players looking for a new way to introduce newbies to the game. It is not, however, developed by the BBC.

However, I doubt they sold many, because according to Wikipedia, it cost £200 when new in 1985! You could have bought a 48k ZX Spectrum for £175 (in 1982; probably for much less by 1985) and still had plenty of money left over to buy bridge games for that. I have to assume that it was severely discounted later, or at least never actually sold at that price.

Software was distributed on ROM cartridges, and as far as I can tell there were only ever nine releases made for it:

Advanced Bidding
Advanced Defence
Bridge Builder
Club Play 1
Club Play 2
Club Play 3
Conventions 1
Duplicate 1
Master Play 1

I was unable to find any records for how much the cartridges cost, but it couldn’t have been cheap. Each one appears to have come in a huge moulded-plastic shock box with a thick coil-bound handbook containing most of the lesson material. Bridge Builder was a pack-in with the system.

Gimme the specs

The hardware is what interested me. This thing is put together with a Zilog Z80 and our old friend, the TI TMS video display processor (VDP.) Specifically, it’s a Texas Instruments TMS9129 - the PAL variant of the TMS9128, which is itself the “RGB” variant of the TMS9118 that you previously saw me exorcising from the Casio PV-7 MSX. It even has the “full” 16kB of VRAM¹!

Even as late as 1985, that’s a lot of 8-bit horsepower to throw around; practically a ColecoVision. Although I haven’t tried all of the cartridges yet, it’s not like the Bridge Companion games are really taking advantage of that beefy VDP and CPU:

Robert Maxwell Not Required

I figured it would be a pity not to at least try making the console a little happier. Besides, I haven’t done a really dumb Coleco-adjacent homebrew project since the last one. Worst case, I can always port my game to said ColecoVision, so at least one other person on planet Earth could try it.

I don’t think I’m the first one to have tried this: it looks like cdoty on AtariAge already started tinkering with their BBCBC.

What game would be a good candidate to make for the Bridge Companion? Ideally, it should be something that everyone loves, with timeless rules, and a decent amount of challenge. Also, you should be able to play it with the super awkward ATM-like buttons on top of the console. The only answer is Tetris. Or, to be more specific, a Tetris-like game.

Is this a true Tetris? The Tetris Company would say no: it doesn’t follow the entire ruleset, nor am I paying them any licensing fees. That’s why my game is actually called Bridgetris, which I think everyone can agree is not at all the same sequence of letters as the one that will get me in legal trouble.

Now, I must confess. Although I have had a lot of experience programming games, and a lot more programming software in general, I had only very recently made a Tetris-like game. Like many other projects that I’ve put off forever, it usually comes down to one mental block that turns out not to be a big issue when I actually try to work the problem. For some reason, I had it stuck in my head for decades that the piece rotation code is actually very complex and involves a lot of fiddling.

While programming a Tetris-like game in Rust as part of a pandemic boredom relief exercise, I discovered that, in fact, “piece rotation” in most Tetris games is simply hardcoded. You define a single pivot point and just crank it over. Doesn’t fit? Don’t rotate².

This is that Rust Tetris-like game, with a screenshot proving it looks somewhat like a dropping-blocks puzzler:

So, this was going to be easy. All I have to do now is:

Figure out how to get a game console I’ve never seen and don’t actually physically have to run my own code;
Write an entire Tetris game in Z80 assembly language, without having written an assembly program larger than “hello world” since TI-83 Plus programming in high school;
Write the blog entry about it. I’m doing that part right now. Hello!

Easy!

Tricking Your Companions

On some systems, making it accept a game ROM is just a matter of putting the ROM somewhere that the CPU will jump into when it starts up. That’s the case with the Sega SG-1000, which is easy to program for. As long as your game shows up at $0000 , it will automatically get run when the Z80 CPU comes out of reset.

However, like the ColecoVision, the BBC Bridge Companion contains a somewhat complex BIOS on an internal ROM. When the Bridge Companion starts up, it’s that BIOS that mounts at $0000 . If the BIOS isn’t satisfied that a cartridge is attached, it will lecture you to turn the system off and insert a cartridge.

So how do we convince the BIOS that we’re a legitimate cartridge? By reverse-engineering the BIOS. I opened it up in the MAME debugger, stepping through instruction-by-instruction to figure out just what the BBC Bridge Companion was looking for from the ROM on the cartridge.

After a few evenings of comparing a legitimate cartridge to my nascent homebrew one, I eventually succeeded in building a header that would convince the Companion to run a piece of code that I had written.

And from there… there was nothing the BBC could do to stop me.

Writing The Game

Even though I’d written the previous game in Rust, there’s a large gulf between a high-level language like Rust and writing something in very low-level assembly language. Assembly is extremely pedantic: you describe each and every small step that the computer needs to undertake, in exacting detail.

This is great, because it means the computer won’t take any steps you don’t want it to, but it means that you can turn a simple thought in your head (“maybe I should make the blocks animate”) into 500-plus lines of code very quickly.

Plus, I didn’t really know Z80 assembly language. I had to learn it and all of its fun quirks while also making a game at the same time. Nobody would recommend you live life this way, but it worked surprisingly well. Please don’t look at my code, though. It is a spaghetti mess and about as unoptimized as you can make it.

As I went through it, I made bugs.

Lots, and lots, and lots of bugs.

So many bugs.

It turns out that assembly language is actually pretty simple and fun! You do have a slight overhead of thinking about things. After I abandoned some of the “rigour” that I expect from working in a higher-level language, and just started doing whatever I wanted, the code started flowing. That’s the real game development lesson, kids.

Bonus: Fixing the Bridge Companion I bought

Somewhere out there is a country where Bridge Companions grow on trees. Sonic the Hedgehog music plays too slowly, and everything is in black and white there, because of PAL. In times long past, I would have to board a rickety airplane and fly across the world to sup of this bounty.

Instead, I just hopped on eBay and spent way too much for a (boxed!) Bridge Companion of my very own.

When it got here, I was disappointed to find out the cartridge slot was mangled, with its pins bent out of shape. Even with a dental pick and some precisely-chosen profanity, I was unable to get a cartridge to read or even insert smoothly, and had to replace the slot. After a few weeks of searching, I managed to bodge an AliExpress substitute into the spot.

I was finally able to play real games on my real Bridge Companion. Real games, like the one I was writing.

Discovering the real developers

Although there’s definitely more to be written on this subject, I found out from the packaging that a company named Heber put this hardware together. Imagine my surprise when I was watching an RMC Retro video to find out that they were filming in the old Heber headquarters!

I quickly reached out, and got ahold of some documents from Richard Horne, who was involved in engineering the thing. In the future, I think it would be worth interviewing him in order to get some more primary source information about the system, but this series of articles is already too late as it is.

Super Bonus: Making my own cartridge PCB

Software for the Bridge Companion comes on cartridges, like pretty much any other game system of the 80s. I only had a couple Bridge Companion cartridges lying around, and didn’t want to tear them apart in order to debug my game.

Most cartridges are simply a ROM chip that holds the program. Because the Bridge Companion cartridges used a common UV EPROM, I already knew the pinout. With my trusty multimeter’s continuity test, I could figure out which pins went to that ROM, and make a working copy of the original cartridge PCB.

I went a little bit further than that, too, but that’s a story for another time.

Hyper Bonus: Figuring out a composite mod

Being an artifact of its time, the Bridge Companion only outputs RF video from an Astec RF modulator. If I lived in the UK in the 80s, this would be really easy: connect the sucker to a switch box, run the forks to the back of my TV’s antenna input, and toggle it on when it’s time for bridge.

Things are not so easy today: sure, I can plug it into a TV, but there’s a few problems with that. Canada doesn’t have the same channel frequencies, and also the world has changed a lot since terrestrial television ruled the roost in this country. RF did not look great on the Bridge Companion, especially through an adapter:

A better option is to use composite video. Even though the yellow plug is also quickly evaporating from new televisions, it’s still the best option to quickly improve the video quality of the Bridge Companion³.

I spent a lot of time poring over scans of schematics – which were provided by the aforementioned Richard Horne at Heber, thank you Richard! – and working out the various levels with an oscilloscope, in the pursuit of the highest-quality mod possible. In the end, though, I just ended up doing something very simple, similar to my earlier Nintendo Famicom composite mod series.

I think it looks pretty good!

What’s Coming Up?

Thanks for reading this far on what is basically a glorified executive summary of the project. If you want to come back in the next few weeks to delve into the gory detail of each sub-project, I’d love to have you back.

The next few chapters are:

August 4th, 2026: Fixing a broken Bridge Companion and making that cartridge PCB for it.
August 11th, 2026: Building a composite mod for that Bridge Companion, so I can see it on my TV.
August 18th, 2026: The final chapter! Actually sitting down and programming a Tetris-like game.

Once all the entries are completed, I’ll be releasing the ROM and source code as well. I hope you enjoy reading along with this big project as much as I did working on it.

The TMS99xx video chipset, at least the TMS9918A, is documented as being able to function with 8kB of video RAM instead of 16k. However, I don’t know of any systems that actually shipped in this configuration, and I don’t think I’d want to build one. ↩
Yes, I know that in many Tetris games, rotating into a wall forces you to be pushed out, a phenomenon known as “wall kicking.” That’s not part of the ruleset of this game, please come back for Bridgetris The BBC Master. ↩
Being a TMS9129, the Bridge Companion actually generates YCbCr (conventionally “component,” but the levels are different here) video internally, and converts it to single-channel composite before handing it to the RF modulator to be turned into “television.” An RGB mod of a Bridge Companion is not infeasible, nor would it be especially hard, modders! ↩

400-Line’s Just Fine For A Party

2026-07-07T00:00:00+00:00

When Suruga-ya gave me a really good deal – with free shipping to Canada – on a CRT monitor, I had to take it. Only once it arrived did I realize this monitor was a lot weirder than I thought it was, and now I have to find a way to actually make use of the thing.

This monitor reminded me of the glory days of buying crap from Japan, where you could get yellowed hardware for pennies on the dollar because it was aesthetically unpleasant. Certainly this qualifies as “yellowed;” even though it came with its original Fujitsu shipping box, indicating someone really cared for it, the back of this CRT has probably spent a lot of time basking in the hot sun.

If I’m honest, I bought this because it was a good deal, and tried to figure out a use for it later. As I said up above, Suruga-ya let me buy this monitor for ¥3000, with free express shipping to Canada. I’m sure they’re very mad at me, but it’s my understanding that disposing of CRTs in Japan is not free, and perhaps they lost less money mailing it to me than they would have by simply disposing of it.

My original plan was to use this with my second Fujitsu FM-77AV2. Although its beige-office vibes don’t really match the styling of the sleek black wonder-computer, it has its own charm. I can’t resist a monitor with an anti-glare shield and a silkscreened logo on the glass.

Unfortunately, it turns out that this monitor is not compatible with the FM-77AV2. After a few months of it sitting in my basement, I finally cleared enough desk space to go and test it. First, though, I checked the FM-7 Museum website, which told me that the MB27331 is a fixed-sync “400-line” monitor. That means it’s only compatible with FM-77L4s, and original FM-77s equipped with a 400-line card. The AV2, despite being a newer computer, does not support such a high resolution, and neither do any of the successor AV models.

I also found a scan of a brochure telling me that the MB27331 was sold alongside the Fujitsu FM-16β, where it is described as an alternative to the more expensive, but similarly “high resolution,” MB27333. I’m not sure what the differences are between those monitors; maybe the ‘33 has a finer dot pitch or more inputs.

Okay, that’s enough market research. Let’s see if this thing can emit a phosphor. Something in my voluminous pile of junk ought to be able to drive it…

Get to the source

I went looking for a video pinout for the FM-77L4, just in case it was wildly different from the FM-77AV2. Quickly, I found this great site covering the differences between the FM-7 and FM-77, which includes a comparison of monitor pinouts. It turns out that this monitor has an “intensity” pin, which means it’s a sixteen-colour 640x400 monitor. Very fancy!

Now, I didn’t push all that carbon into the atmosphere and pull all that shipping cost out of Suruga-ya’s coffers not to use this fancy monitor. I remembered that some of my beloved NEC PC-98s have 8-colour digital RGB, and PC-98s also run 640x400 in 24kHz mode. That ought to be pretty close to the frequency this monitor expects, if not dead on.

Because the monitor is reported to expect TTL digital input, I chose a PC-98 that still has digital output. It’s not a perfect match, because, again, PC-98 digital output is only 8-colour, and this monitor supports 16 glorious tones. I chose my (second) PC-9801UV¹, which you haven’t seen yet on the blog, mostly because my PC-9801RA was happily ensconced in my desk and not willing to come out of its cozy nest.

A quick consultation of the PC-9801UV’s user manual gave me the video pinout that I needed to wire the male end of the adapter:

I rummaged through my bin of cable parts, and made up an adapter cable from the 8-pin DIN digital output on the early PC-98s to the female DE9 that the MB27331 expects to connect to². The screw-terminal breakout here is the usual female DE9 part that you’ve seen in other posts; I was happy to see that the pin numbers on the PCB actually matched the correct pin numbers instead of just reusing the male PCB.

The masking tape is there in order to cover up the unused wires leading from the PC-98. One of them is a +12V line, which I didn’t want shorting to anything in the vicinity. The dangling shield jacket could also potentially have caused problems, but very few monitors need the shields connected in my experience, and there are some dedicated ground pins anyway.

I think we can all agree that this monitor looks really good on this computer.

PC-98 Not It?

After crossing my fingers, I fired the monitor up with the PC-9801UV running. As the set warmed up, I eventually got some raster with a stable vertical position, but the video was unintelligibly smeared horizontally.

I remembered that the monitor has a horizontal hold setting on the back, so I grabbed my ceramic adjustment tool and went to town. I could get it close to legible on the topmost text line (albeit shifted 2/3rds to the right,) but the bottom row of key help was still a smeary mess, and the pot was extremely sensitive to any adjustment in that range. It seemed impossible to get any closer, and even if I did, the video was still offset quite a bit horizontally. Some tweaks to the horizontal position didn’t seem to make any difference.

I went to toggle the resolution DIP-switch on the front of the PC-9801UV, which changes it between 15kHz and 24kHz, but nothing changed. Wait, something should have changed.

PC-98 Is It

Did I actually wire this adapter properly?

As soon as I touched the adapter, the wire for pin 8 fell out. That’s the horizontal sync pin. Oops. I twisted it up again and stuck it into the terminal block. Terminal blocks are not really the appropriate connector for a wire this thin; unfortunately it was this or run off a PCB.

Holy cow! It works. Focus is sharp, and linearity looks perfect to my eye. There is this weird vertical turquoise line with sporadic dots inside it, and the video keeps throbbing and wiggling. Maybe the monitor needs caps, or this is something like the PC-98 not shutting off the colour while flying back that the Fujitsu doesn’t like?

I tried moving the line off the edge using the horizontal hold, but as soon as it fell off the edge the monitor lost sync and freaked out. Playing with the horizontal position and horizontal hold together was not able to move it far enough away either.

Since I already had N88-BASIC working, I wrote a simple program to test colour:

10 for i = 0 to 7
20 line(i * 80, 0)-(i * 80 + 79,399),i,bf
30 next i

In N88-BASIC, and probably other Microsoft BASICs of the era, you can draw a rectangle by using the LINE instruction to specify the upper left and bottom right corners of the rectangle and specifying the option B. BF is “box, filled,” as you can see below.

A rainbow of possibilities. And in the right order, too! Somehow I failed to mix up red and blue this time. Go figure I got it right on the throwaway video adapter…

As I suspected, these colours are fairly dim, because I’m not driving the aforementioned Intensity line of the monitor. Unfortunately, the PC-98 only provides +12V for a power output on its video pinout, and I’m willing to bet this monitor will not appreciate being fed that. Of course, that can be regulated down to a nice +5V in order to provide a pull-up on the intensity line, but let’s first figure out what’s going on with this ugly vertical line artifact, and all this dreadful wobbling.

MB stands for More Bfixing?

Although I’m disappointed it wasn’t perfect immediately, I’m not particularly surprised that a nearly forty-year-old monitor might need a little bit of maintenance. Who knows how many hours of excitement this thing has seen in its long life before getting crammed into a box and sent to Canada?

For now, the monitor has gone back in its box – I need the desk room for another broken project – but I am pumped to open it up and recap it soon. Kudos to Fujitsu for making a cool monitor.

Thanks for reading!

Since it’s the first time on the blog, despite many years of failed UV-related projects, I’ll give a quick capsule history of the model. The PC-9801UV is a much earlier PC-98 than the PC-9801RA; it’s from 1986 and has an NEC V30 CPU (8086 equivalent, sort of) running at up to 10MHz. It also has built-in -26 FM sound and the GRCG “Graphics Charger,” making it a great option to run early games on. I’d argue that it can be considered the first “modern” PC-98, although the successor model, VX, added the “Enhanced Graphics Charger” (EGC) that most games expect, so it depends on your definition of modern. ↩
As a side bonus, the video pinout of the PC-98’s digital RGB port is shared by a bunch of other Japanese computers, including my beloved NEC PC-8801mkII, which can also do a “400” line display by scan-doubling its 200-line internal resolution. ↩

IIgs The Future

2026-06-16T00:00:00+00:00

During the tumultuous era where Apple cast the Apple II aside in favour of the Macintosh, they also threw out a really special little computer: the Apple IIgs. It combined the Apple II’s anything-goes accessibility with 16-bit performance and FrogDesign’s good looks. I’d never had one before, but have started to get interested in them recently. Let’s see what it takes to get this slightly battered example running.

Part of exploring the world of old computers means that you get to re-evaluate your opinion of the old computers. When I first started collecting old Macs many years ago, I didn’t have any time for the Apple II systems. They’re so limited, I thought, and not at all fun and colourful like the Macs were.

I regret not having held onto more of those systems at the time, when they were cheap and plentiful, and after getting to know the IIgs through various meets and emulator adventures, I really regret not trying it earlier. Now they’re a little harder to find; many of them have been recycled, and a lot of the remainder have been raptured into collections where they serve as backup units or shelf queens.

For the Apple II faithful, the IIgs is historically important. Woz returned from his plane crash to Apple, and eschewed a cozy management position in favour of making a really kick-ass new computer. Various conspiracy theories are put forward as to why Apple didn’t follow through with a successor model to the IIgs, but they did build the things for six years, which is a much longer production run than most of the failed machines on this blog ever got.

This particular IIgs comes to me from someone on another Discord, who cut me a good deal because its appearance is not great. Although there is yellowing and lots of dings and dents, the primary damage is this huge scar on the side.

From the shape and position of the scar, I’m guessing this used to be an asset tag or an anti-theft clamp that was crudely removed using a chisel. You can’t tell from the front, so I just have tucked that side up against another piece of junk on my desk to cover the damage.

Getting it started

Unlike the other machines in the Apple II series, the IIgs has a completely separate keyboard. This helps it be a tiny little box that shoves easily into the corner of my desk without taking up too much room: a huge plus in my environment.

What kind of a keyboard does it take? This machine is actually the origin of ADB, the Apple Desktop Bus. I always thought it was a Mac thing originally, but the IIgs produced a lot of the innovations that slowly made their way into later Macintoshes. It’s very convenient for me: I don’t have a IIgs-specific ADB keyboard lying around, nor do I want to buy one, but I do have lots of Macintosh ADB keyboards.

For video, I initially connected the composite video output of the IIgs to the NEC JB-1260 CRT that I repaired in a previous article.

When the IIgs is first switched on, it will go to a “check startup device!” screen with a bouncing Apple logo. Obviously, it’s waiting for a boot disk, which I don’t have.

The “triangle” button which is usually used for soft-power ADB Macintosh power-on (and interrupt) is used here as the Apple II’s “Reset” switch. On my IIe, I can bail out of the slot autoboot screen and go to BASIC by hitting Ctrl + Reset… let’s see if it’s the same thing here.

Yes, that worked great. You can indeed use a IIgs in a useful way without having a disk drive attached to it. However, the mini assembler (CALL -151 and then F666G) does not appear to work on this machine. Which is a pity, since I was looking forward to seeing if it had 65816 instructions.

The mini-assembler also doesn’t work on my unenhanced Apple IIe (it has to become enhanced, something I am stubbornly opposing for some reason) so sadly I will have to continue to hand-assemble my 6502 programs. Or, like, download a copy of Merlin.

Floppy Ostrich

I didn’t have a 3.5” floppy drive on hand, and looking at eBay prices for broken and untested drives made me feel a bit ill. Rather than supporting scalpers, I decided to instead support the community, and finally bought a Floppy Emu.

This fancy device emulates Apple II, Lisa, and Mac floppies as well as some limited varieties of hard drive that connect to the external floppy connector on early Macs. It even has support for the new “WOZ” disk image format, which is sort of akin to a flux-level image, making preservation of copy-protected disks easier.

All you have to do is pick an image, and restart the IIgs using Open Apple (Command) + Ctrl + Reset.

The IIgs happily boots off the “disk” and is off to Apple II goodness, such as this copy of ultra-gory stabfest The Bilestoad, which just so happens to be a copy-protected WOZ image as well. Cool!

So far, I liked the system so much that I got around to building an adapter¹ in order to use it with my freshly recapped NEC MultiSync 3D, which can easily do 15kHz RGB with composite sync. Here it is running ProDOS and the title screen of Moon Patrol:

Another good option for RGB video would be to construct a IIgs-to-VGA adapter cable and use it with a GBS-Control upscaler (like the one I built way too quickly a few years ago and still use.)

Ys, or not

While I was looking for other games to try, I was surprised to find a copy of Falcom’s Ys listed with the other archival copies of games available. I haven’t played much Ys, having always been repelled by descriptions of its “half-character” bump combat, but it is novel to see it in English on a Western computer. I threw it on the Floppy Emu.

I was able to boot into the program disk, and get it to ask for the data disk, but then it crashed immediately on an “0201” error. After searching, this turns out to be a memory allocation failure (I assume some equivalent of C malloc is being invoked on the OS level) which made me suspect I didn’t have enough RAM.

After searching online, it was shown to be the case that Ys indeed needs 512kB of RAM. I only have 256kB. Uhhh, I guess I need some RAM.

Wasting money on memory

Originally, I was going to get a GGLabs RAM card, but it was out of stock. Then, I started playing around with the idea of building my own card, maybe with a SIMM socket (I’ve never done one of those before!) Eventually, I found a listing on eBay of two Apple-branded IIgs RAM cards, which take socketed 41256s. They were dirty cheap, and would arrive quickly, and so that’s what I chose.

That turned out to be a mistake, but I’m getting ahead of myself.

This card looks pretty power-thirsty, even with less than half of the total RAM populated. I had a feeling that I’ll need to swap this out in the future if I started adding more cards to the system.

Yes, Ys

Once the RAM was installed, I was now able to boot into Ys a little further, getting the publisher logos and the title screen.

Unlimited Software is a Canadian success story, having done a handful of ports before doing their own original titles (as Distinctive Software) for EA and then becoming part of the Electronic Arts monolith as EA Canada.

Publication was done by Kyodai² which the Ys manual describes as a collaboration between Japanese publishers and Brøderbund:

Founded in February 1988, Kyodai is a joint venture involving 11 Japanese personal computer software publishers and Brederbund Software, Inc. An American company based in San Rafael, California, Kyodai brings best-selling Japanese personal computer software titles to the North American market. We at Kyodai believe that American computer users will enjoy the converted Japanese programs for their superb graphics and their interesting storylines - the same characteristics that made them best-sellers in Japan.

The IIgs port was done by Dave Galloway, who I reckon is likely to be this David Galloway on Mobygames.

No, Ys

Then, it would go to a blank gameplay screen, and dump me out into a blank text-mode screen. The disk would seek for a bit, then go silent.

Something was wrong, and I wondered if I was failing some kind of copy-protection check with my greasy pirate disk image. Still, I checked the Ys manual to see if it had some troubleshooting advice, but it was relatively useless:

NOTE: If the program does not load, check your IIGS Control Panel Slot settings.

Check them for what? Which settings? Later on, the manual explains how to make copies of the game:

Although the Ancient Land of Ys disks are copy protected, you can make backup copies of both game disks. Use a ProDOS utility or a ProDOS copy program to copy both Ancient Land of Ys disks onto blank floppy disks. If you have any questions regarding the use of the utility program or copy program, please refer to the utility program or copy program’s manual.

So… it’s copy-protected, but you can copy it?

I decided to quickly check the RAM on my newly-installed expansion card to see if it was bad. After farting around with the default IIgs diagnostics, which told me “System Good” without explaining if they tested expansion RAM or not, I ran MiniMemoryTester instead. It has a ton of options, but I stuck to the defaults for the first test.

It passed with flying colours. The second test too, this time using a more rigourous “bit walk” test. So the IIgs’ internal memory, and the 41256s on the expansion card, are both perfectly fine.

Now I had two theories for why Ys wasn’t working on my real hardware:

The Floppy Emu somehow doesn’t do something right with its disk emulation, and Ys crashes when that happens. This is not something I can fix or test without buying a 3.5” disk drive and using ADTPro to write my own bootlegs;
The game was designed for ROM 00 and the ROM 01 version needs more RAM than just 512K for some reason. This felt like something I could test with an emulator.

Unfortunately, both the KEGS and GSplus emulators only let me change the Expansion RAM size to 0MB or 1MB at the least. In the menu, at least. I was getting ready to modify the code to use a mere, wimpy 256K expansion.

Reading the release notes, though, I noticed KEGS had a command line option to set expansion RAM size:

RAM size is now settable on the commandline: -mem 0x400000 will use a 4MB expansion RAM card (giving you 4.25MB of memory with ROM 01).

Sure, I can do basic hex math. How about -mem 0x40000 for 256K, big boy?

Now I could run the KEGS emulator in an configuration mirroring my real IIgs. Mini Memory Tester (above) shows that I only have a 256kB expansion.

And did Ys crash?

Yes it did! Apparently, I needed more RAM this whole time. This doesn’t make a ton of sense to me, as I was under the impression that only GS/OS loaded additional patches into RAM to put more RAM pressure on a ROM 01 system. And this game was clearly booting from ProDOS. Being new to the system, I don’t know the IIgs internals very well, but I get the message: put more memory in this sucker so you can play Falcom games.

To figure out the minimum, I decided to bump the emulated RAM up to an extremely generous 512kB of expansion RAM (-mem 0x80000) and try the test again.

So I need at least 512k expansion RAM to run Ys on my ROM 01 IIgs.

Buy another RAM expansion

Now that I had a reason to, I decided that I would like to get more RAM. I considered stuffing this card with more 41256s (as I had with the Tandy 1000SX,) but I didn’t want to wait several months for AliExpress (I only had two chips left,) and also put a ton more heat and strain on the power supply to feed all those DRAMs.

Lucky for me, the GGLabs RAMGS/8 had just come back in stock. This is a relatively inexpensive (for an unpopular system, at least) 8MB RAM upgrade, and it’s nice to support other folks who spend their evenings staring at an oddly wobbly oscilloscope.

I feel like I could have designed and built it cheaper, or at least weirder – I have a lot of 30- and 72-pin RAM SIMMs lying around that could be used. We all know, however, that the last thing I need is another several-weeks-long PCB project, and any respins would quickly eat into that budget. I’ll save my RAM-expansion-building antics for a computer that doesn’t already have a community-made option still available for purchase.

It’s a little hard to believe that this tiny thing contains eight whole megabytes of RAM. But it does:

Ys III, but not that Ys III

As expected, Ys fires right up. Well, by “right up” I mean “after significant load time.” It even loads from disk when you push the “escape” key to pause the game…

It’s a little presumptuous of you to think that I’m going that far, ma’am. I just loaded up this game. I might be going to the sandwich shop and that’s it.

Being familiar with Japanese role playing games of this era, I knew I had to seek out the fortune teller first. She is living in the largest house in the village, which is not at all suspicious.

Equipped as a swordsman? I can do that. I went to the nearby store to buy a 500-gold short sword. Apparently, this sword is good for things other than violence. I am really curious what those could possibly be.

Despite what you may think, Ys’s fortune teller really wants you to have more than just a sword in order to become a swordsman. You in fact need a shield and armour as well, which I found out shortly after this.

Conclusion, for now

If you’re here to watch me play games, I think you may be sorely disappointed. Ys proved that the IIgs was working, but I’ll be enjoying its engrossing narrative and massive world on my lonesome.

I was shocked at how much I liked this IIgs. Much like the PC-88, the IIgs shows the power of taking a solid 8-bit design and extending it to have much better colour and sound.

My next steps with the system are going to be running GS/OS off the Floppy Emu’s emulated hard drive. I want to try and install the ORCA development tools so that I can try my hand at 65C816 development like all the cool kids do.

I may also attempt a motherboard recap. Once in awhile, the MultiSync and the IIgs just refuse to play ball with one another from a cold start. It usually takes a couple minutes of frustrated switch-flipping before video can be established, and since the MultiSync was just fully re-capped and seems to work fine otherwise, I’m willing to blame the IIgs.

That said, while combing through the schematics, I’ve yet to come up with a plausible theory for this fault, and the last thing my desk needs is another exploded computer waiting for an order of one or two weird-value caps. More detective work is needed before I could conclusively point to the motherboard or power supply as being the problem.

Also, wouldn’t it be cool to have an internal SCSI card and BlueSCSI? The schematics of both the IIe/IIgs SCSI cards are out there, and although the faster card (Sandwich II) has all kinds of fancy DMA and customs, the slower card sure looks like it may be within my wheelhouse to replicate. It’s a good thing that I don’t have to, because as this article was getting edited, blog friend DosFox made an open-source clone of the Apple II SCSI card, including reverse-engineered PALs.

If you want to build one of your own, you can download the Gerbers from the GitHub repository here. Check the “Releases” page. ↩
It could be 巨大, “gigantic,” “enormous,” but if you spell it Kyōdai (きょだい,) it becomes “siblings,” which is almost certainly the actual meaning for this publisher-publisher family structure, especially from Brøder-bund. Again, I was not able to find any conclusive information on which of these two it is, but I strongly suspect the latter, considering “Brøderbund” isn’t an actual word either. ↩

Moving Into a New Towns

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

There’s a lot of NEC computers on this blog, but tons of Japanese companies made great machines. Fujitsu, for instance, built a whole spectrum of computers. You’ve seen three of their 6809 machines in previous articles. Today, we’ll figure out how to get this sad 486-based FM Towns II to boot. Ideally, it should stay booted, too.

Introduction

What is the FM Towns? It would be easy to assume it’s a continuation from the 6809-based Fujitsu FM-8, Fujitsu FM-7, and Fujitsu FM-77… but not so!

Fujitsu made their own PC-incompatible x86 system to compete with the considerable might of the NEC PC-9801. One of the big ways in which it differentiated itself from its rival was the introduction of a mandatory CD-ROM drive. With this as a standard feature, they were able to position the Towns as a “multimedia” computer of the future, rather than the dour and serious image of Japan’s so-called national computer.

From what I can tell, its price was pretty close to that of the contemporary PC-98s (such as the PC-9801RA.) That would intuitively mean that Fujitsu was probably taking home a lot less profit than NEC¹ after the cost of a CD-ROM drive, but I have no way of knowing for sure.

In a similar way to Apple of the period, there’s a great clash of aesthetics between 90s-stereo-futurism and the bright, cartoony vibes of some of the software.

This particular FM-Towns II is an HR model, which means a 20MHz 486SX is riding along inside it. Its graphics chipset has hardware sprite support, unlike the PC-98 and IBM PC. All of the Towns machines also have a Yamaha YM2612 FM sound chip, so there’s a lot of potential for cool games and multimedia on the platform.

Tons of games were released for it, although the machine ultimately succumbed to NEC anyway, and the FM Towns became a boring PC-compatible at around the same time NEC gave up on the PC-98 as well.

Arrival

Isn’t it handsome? A lot of people think it’s less pretty than the FM Towns tower or the FM Towns II U-series all-in-one compact machines. All of the “grey” Towns machines look good in my opinion. I think the moulded-in floppy drive inserts and the glossy CD-ROM tray (with chunky eject button) give it a fun 90s-futurist personality.

This machine sparked a bit of a bidding war. It turned out to be fairly expensive, but still a decent deal compared to others I’ve seen.

The auction listing was from the original owner, and they reported that the power supply had failed to start after two years of storage. When it did work, video, sound, and CD-ROM were all tested as working, and the clock battery had been removed. Thank you for your diligence!

As I dug through the machine, everything seemed in order. Unfortunately, there was no expansion RAM in any of the slots, which means we’re stuck for now with the 4MB that is built in to the motherboard.

Power Supply Re-Cap

Anecdotally, power supplies seem to be a common Achilles’ heel of this computer. The towers and compacts are also bad for it. I hoped that I could quickly figure out what was wrong with the PSU and revive the computer. The last thing I needed was a couple weeks of waiting for parts in order to construct another new power supply, especially one for a thirsty 486.

That’s what we in the writing business call “foreshadowing.”

Getting into the machine is really simple, which is a big surprise after working with an FM77AV2, which could generously be described as “a huge pain in the ass.” Most of it is plastic clips, and once the back panel is removed, you can slide the power supply right out.

Immediately, I saw a potential culprit: a Nichicon PL 1000µF cap hanging out on the board. And because the PSU board is mounted upside down, it’s probably been dripping its corrosive death into the motherboard underneath. We’ve seen the damage that Nichicon PL capacitors can wreak on a board before.

I dismantled the PSU, the hardest part of which was popping the clip that held the pass-through power connector onto the thin steel of the case. At this point, I realized a bit of a pitfall: all the brown wires on the wiring harness are not the same voltage!

Indeed, checking the FM Towns Maintenance Manual V2.1, it seems like all the bulk outputs from the supply are the same colour. Talk about a trap for new players. The article goes on to describe how you can wire up an ATX power supply to replace the original Towns unit, but let’s not think about that for now.

Undaunted, I set about desoldering the caps. Each cap was tested on my Peak ESR70 ESR meter, in the hope that I would find a smoking gun as I had with the MultiSync 3D’s totally dead caps.

Position	Capacitance	Voltage	ESR	ESR Good?	Comments
C52	1000µF	25V	0.04	Yes (max 0.08)	Leaky
C53	10µF	50V	5.90	No (max 1.60)	Leaky
C54	10µF	50V	1.22	Yes (max 1.60)	Stinky
C57	2200µF	10V	0.05	Yes (max 0.12)	Dry
C58	2200µF	10V	0.05	Yes (max 0.12)	Stinky
C59	220µF	50V	0.07	Yes (max 0.20)	Leaky
C60	220µF	25V	0.15	Yes (max 0.25)	Too close to 78m15
C62	10µF	50V	0.82	Yes (max 1.60)	Very stinky
C66	2.2µF	50V	“>40”	No (max 4.50)	Leaky
C69	10µF	50V	0.62	Yes (max 1.60)	Dry

There were a lot of badly-leaking caps on this board. The very first one I removed, the 1000µF, immediately filled the room with the stink of chemical death, but it tested out fine on the ESR meter. The 2.2µF is the star of the bad-caps show; I’m assuming from its small value that it serves some kickstart function that wasn’t happening.

As an aside, the FM Towns II compact machines also seem to have some pretty dramatic corrosion problems on the power supply board. In those, as here, we find the hated foe Nichicon PL.

I scraped away a bunch of corrosion near the output end of the PSU, and made sure there was still continuity. It seems like the only trace that was significantly affected was the one containing the 7912 linear voltage regulator responsible for producing the -12V rail. Then I tinned the traces and put on some nail polish for solder mask, which was probably a mistake, because of what happened next…

First, I plugged the system in with a AD-D15NE equivalent adapter so that my NEC MultiSync 3D could show the analogue-RGB output. When I went to turn on the computer, I was greeted with the FM Towns startup screen as it started to look for a boot disk. Nice!

…and then I cycled the disc drive to check if there was a disc trapped inside, and the computer shut off immediately. Subsequent tests had the computer start up, run for a bit, and then panic and shut down. I didn’t hear, see, or feel the fan spinning, either.

I began to wonder if the CD-ROM drive might have been shorting or pulling too much current, causing the PSU to go into protection. The easiest way to be sure is to simply remove the offending components. I pulled off the front fascia of the computer (still just clips!) and then pulled out the CD-ROM and floppy drive. I think that this “sliding front bay” design must have inspired the NEC PC-9821Ap2’s fileslot. Thinking it could be clogged up and causing an overcurrent condition, I also unplugged the gross PSU fan at this point, even though it spun freely with my fingers.

Unfortunately, none of this made much of a difference. +5V also seemed quite low at standby, which was not a great omen.

I had a lot of trouble measuring the voltages during runtime, because the test hooks are at an awkward angle for the probes. Soon, the machine would just shut itself off as soon as I pushed the power button, which made testing virtually impossible.

I was going to have to go back into the power supply, and a good place to start was that very same corroded trace that I just sealed up with nail polish.

Power Supply Again

One of the first things I do when I’m studying a board is to look at the chips. Ideally, I’d like to have pinouts so I know what each pin does, but sometimes it helps to just know what the part is. The most obvious chip on the board is a PWM switch-mode power supply controller IC².

There are lots of posts about the tower Towns II fingering the power supply controller IC as a cause of power supply failure, but this is a different part than that one. It’s not even the same manufacturer!

Another major IC on the board is an NEC chip marked “D4027BC.” Man, I’ve seen 40xxBC numbers before. Could this be the same thing as a CD 4027BC? A J-K flip flop would make a lot of sense to be used as a soft-power toggle switch – and a quick search confirmed it. So now we have an idea on how the on/off switch works.

Pulling out my transistor tester, I decided to check all the transistors in the area. If they’d been corroded, it wouldn’t surprise me if they had suffered some damage in the process. Testing them seemed to all check out. There were some really corroded solder joints near them, though…

After searching, I found this Japanese blog post about FM Towns IIHR power supply failure from July 2020 which fingers one of the resistors, R85, near the relay. I figured it would be worth checking out to see what was going on, and found that it appeared to be corroded.

When I removed it from the board, its coating disintegrated from the heat alone, revealing big chunks of green death inside. It was measured out-of-circuit at 13kΩ, which I think is just a little wrong.

Thank you to Waiyama for posting about this. Nice car, by the way.

This resistor seems to interact with some kind of diode-based OR-gate and control access to the SET₁ pin of the flip-flop. I was beginning to suspect that these sudden shutoffs may have been soft-power-related, not supply protection as I had first thought.

Using my cheapo jeweler’s loupe as a magnifier, I found a bunch of other greened-up resistors in the general area of the 1000µF PLs, which made sense to me, although none of them looked nearly as bad as R85 did. As the caps leak, their juices wick up into the legs of the resistors, which aren’t hermetically sealed against ingress.

A lot of the resistors were weird values, so I ended up doing a large order of resistors from Digi-Key that was surprisingly expensive.

First, I stuck in a replacement for the bad R85, leaving its body floating a bit out of the board so that I could easily grab its leg with the oscilloscope hook later, in case of further trouble. The Towns would start, run for a bit, and then shut off. No real difference.

I had a handful of other resistors that were out of spec, but not nearly as dramatically as R85 crumbling to bits as I pulled it – 25% off instead of the rated +/- 5%, for instance. This was one of those “put in the time” repairs, where I kept hoping for a smoking gun to explain the random shutoff.

Unfortunately, at this point I also started to have trouble reliably reading the resistors, and I knocked a couple off the desk when trying to desolder more than one at a time. The values were almost all unusual as well, which told me that those values must be important, and I’d have to place a big Digi-Key order to get more. Considering how this project was going already, I was starting to think of a plan B.

Supply Drop

As the work to save this PSU began to mount, I also started work on a contingency plan. After measuring the PCB, I started throwing together a very simplified version of the X68000 PRO PicoPSU board.

At first, I had thought that a PicoPSU wouldn’t cut it, and that I would need something beefier. That’s a tall order with a small, strangely-dimensioned power supply case such as this one. But after checking the sticker on the back of the Towns, I realized that I only needed about 60W in a stock configuration, and 120W maximum.

Since the previous owner did me the favour of also getting rid of a spinning-rust hard drive and its thirsty motors, I felt like I would be safe using a PicoPSU setup. Eventually, I do want to look at adding some expansion cards, such as the mysterious display cards, but that’s a long walk from here.

I chose a 150W PicoPSU-150-XT and paired it with a Meanwell EPP-150-12³ to generate the PicoPSU’s required 12-volts from wall power. It’s not clear from the PicoPSU documentation just how much wattage for the +12V input is required to provide a given demand for system output, but I figured that I was not going to be running anywhere near the documented rail limits. Even 80% of 150W is all that the original power supply would be able to source, in either case.

Even with these relatively cheap commodity parts, the build cost of one of these supplies really adds up. The Meanwell was easily the most expensive part of this build, with prices no doubt climbing in anticipation of more tariffs. Hopefully I use this machine a lot…

At this wattage, a fan is mandated on the Meanwells, or they have to be derated. Without the fan blowing on the switching goodies, Meanwell claims you should only be pulling about 100W. Luckily for me, Fujitsu left a giant fan attached to the outside of the Towns’s PSU casing. It’ll help the PicoPSU, too.

I would have liked to use a single Meanwell module for all the output rails, but unfortunately they have very few units that use soft, or “remote” power on/off. And soft power is important, because…

Hard On-Off

This FM Towns, being a modernish computer, has soft power. Unlike the cruder machines in my possession, which are turned on and off by physically connecting or interrupting the flow of electricity from the wall through a chunk of copper, soft power systems become fully activated when triggered by a logic signal.

From the power supply’s perspective, it only has to supply a “standby” voltage (usually +5V, but there’s no particular reason for that if another voltage is more efficient) and some kind of logic to turn the supply “fully on” when requested. On ATX power supplies like the PicoPSU, this is implemented using an active-low pin called ATX_ON. Shorting it to ground – bringing it low, in other words – turns the remaining voltage rails on, and lifting it to +5V or letting it float will turn the power supply back off, shutting off the computer.

This has a lot of benefits, ranging from “don’t have to buy such a beefy power switch” to more sophisticated control of power rails. In the case of the FM Towns, you get a nice pleasant power toggle button on the front of the case, and software-controlled shutdown from inside the operating system.

Unfortunately, it meant that I had to figure out how to implement a circuit that would do the following things:

When the system is off, pushing the ON/OFF toggle button turns it on.
When the system is on, pushing the ON/OFF toggle button turns it off.
When the POWER_OFF signal goes low, the system should be turned off.
Ideally, none of these things are glitchy or weird.

Requirements 1-3 were met with a simple flip-flop circuit. A flip-flop is a very common digital logic part that is, essentially, a 1-bit memory. You set it to on or off, and it keeps that information until you tell it otherwise. There’s many different kinds of flip-flop ICs out there, but the differences are usually down to what interface pins they expose (for example, offering a reset pin,) how many bits they remember, and how they are signalled (active high, active low, high-to-low transitions, etc.) Flip-flops are such a popular chip that I’m sure there’s lots of weirdo application-specific ones out there as well.

Because a toggle button needs to “remember” if the power is on or not (so it can then invert that signal,) I decided to implement it with a 74LS74 flip flop. Choosing this type of flip flop was determined by googling for “toggle button flip flop” and looking around for example circuits. It also helped that I had a bag full of these things and keep seeing them all over the place.

Remember requirement 4? Whenever you push a button, there’s no guarantee that the button is cleanly pushed at all. On a scope, “pushing a button” can often look noisy or wiggly, as the mechanical components of the button physically move around, momentarily breaking or making the connection. Interpreting this in a dumb way can make the button feel fiddly or glitchy. I’m sure you’ve had this happen in the past. Even if you’re really good at pushing buttons, you’re going to eventually “bounce” a switch. Filtering this phenomenon out is called debouncing.

I definitely didn’t want to have a glitchy power button, especially if that power button also toggled power on and off to the computer. When I hit that sucker, I want it to work. To make sure I did the best debouncing circuit I could, I then asked my buddy Scott about Schmitt triggers. A Schmitt trigger is a component that is meant to reduce noise and hysteresis, such as this button debounce. After I borrowed his napkin-doodled debounce circuit, and played around with a Digi-Key forum thread on the topic, I had a basic circuit for on/off and off that I was fairly sure would work.

To test that circuit before ordering a relatively expensive power supply board, I rebuilt it on a solderless breadboard. Remarkably, this worked the first time. Well, the first time after I fixed all the loose wires. Okay, the second time, after I realized that I forgot to power one of the ICs.

I then proudly shoved this circuit into the corner of the board where nobody would ever see it, in the hopes of optimizing the routing of the copper pours coming out of the PicoPSU.

A couple weeks later, the new PSU board arrived. It looked great! As you would expect, I forgot to cut a hole for the middle mounting point on the case, but everything else lined up fine, even the little alignment tabs on the corners.

Unfortunately, the Meanwell didn’t fit. The cool footprint I had made awhile ago for the X68000 PRO PSU that is meant to fit both 4x2 and 3x2 Meanwell units doesn’t actually fit a 4x2 unit, because the “4x2” holes are 35mm apart from the “3x2” holes. In case you’re not great with the metric system, 35mm is somewhat more than “one inch.” That makes it more like a 4.37” x 2” footprint. Not ideal.

I ordered a replacement board, but as I was getting ready to chop up the old harness in preparation for its arrival, I realized I could probably just reuse the existing harness. It’s held into this cool plastic block, so there’s no way that I can screw up the pinout when assembling (designing is another matter.)

It didn’t have anything to do with the fact that I didn’t want to crimp up a new 16-pin Molex connector, trust me.

Not that desoldering the old harness was particularly easy, either. This connector uses those annoying spring clip pins that are really easy to assemble, but very difficult to reuse (because the spring clip ends up getting filled with solder during assembly.)

After some more tweaks and discovering other boneheaded mistakes like this, I ordered a third replacement board. Yep, I’m sure saving money doing it this way.

I was fairly confident that this spin would go well, so I ordered a larger diameter tip for the ol’ Hakko FR-301, settling on the 1mm x 4mm tip. I was hoping that the larger hole in the tip would make it easier to desolder these spring pins. Unfortunately, the tip didn’t really help that much, although it definitely did a great job of melting the insulation on some of the thin signal wires. Oops.

In the end, I had transferred the entire harness to the new board. I now regret not buying a pre-made 16-pin Molex harness from somewhere and using that instead, especially now that I’ve discovered the part on Digi-Key where they sell brand-new wire-to-board crimp pins. All this is for entertainment value and not instruction, folks.

I installed a 20-pin ATX connector into the 24-pin ATX footprint. They are backwards and forwards compatible with 24-pin ATX footprints, so I always try to put down a 24-pin on my board designs if I can. To top off the assembly, I installed the Meanwell into the board using a stack of #4-40 standoffs and nuts, which I applied blue Loctite to in order to make sure they don’t accidentally come loose from the vibration of the fan and/or moving the machine in and out of storage.

Wow, that’s a beautiful board. Because of my historically poor measurement skills, I did make a few components a little too close to the Meanwell for my comfort, but they aren’t electrically or thermally interfering, and there’s lots of airflow for the Meanwell.

The actual power supply part

Now that I could put the PicoPSU and the Meanwell onto the board, the next step was to start crimping harnesses. I needed two harnesses: one to carry power from the wall into the Meanwell, and one to carry +12V from the Meanwell into the PicoPSU.

Crimping up the +12V is relatively easy. As I have done on many previous supplies, I cut the barrel jack off the end of the PicoPSU and crimped the pins for JST “VH” connectors, sticking them into a 4-pin 3.96mm housing.

I really wanted to get rid of the hard-wired power cord. As many long-time readers know, I hate having power cords dangling out the back of my computers. They get in the way when storing, they dangle precariously while trying to fish them through the desk, and they’re generally annoying. This Towns power supply originally had a “pass through” connector right next to the hard-wired cord. It’s meant to provide power to a monitor or other peripheral through a regular wall-power socket, so surely I can just pop out the pass-through output, and put my own connector on there to serve as a power input instead.

Unfortunately, the IEC C13/C14 power connector is a lot wider than the “pass through” power connector is – almost 10mm wider, in fact. The cutout in the case was not going to fit it. I considered cutting the case to make room for it, but in the end I decided I would just run a hardwired power cord out the back and dummy out the pass-through connector entirely.

I ordered some Monoprice power cords to cut up, but through some kind of idiocy on my part, I ordered a whole bunch of useless ones that were only 1.5 feet long. Monoprice takes over two months to ship to my house, so I decided it was best to not make another order of the correct length. This project has dragged on long enough. Instead, I dug through my pile and found another Apple charger extension cord, the same kind I used previously on the X68000 power supply.

For some reason, this Apple cord used the European wiring colours inside - brown for live, blue for neutral – despite being purchased in Canada and clearly meant for a 3-prong 120-volt North American outlet. Go figure. I cut the end off of it, threaded it through a strain-relief grommet, and did an underwriter’s knot, before crimping it for JST VH and connecting it to the Meanwell part of the new supply.

I then found out that at some point – probably stripping the wire, or rubbing it up against the razor sharp power supply housing - I had cut into the neutral wire. That’s not good. I cut it back, stripped again, and re-crimped. Then I just had to look for the screws I misplaced when I started this project several months ago…

Putting it into the Towns

Initially, I wanted to test the power on/off logic separately. That would require soldering a tac switch to the underside of the board and running it on my bench, which I didn’t really want to do. So, after waiting several months, I decided to just shove the power supply in the Towns.

My first order of business was to consult the voltage test points on the Towns motherboard. They’re pretty well-labelled, and easy to hit with test probes, which is to Fujitsu’s credit. I always start with a basic sanity check: are any of the voltages shorted to ground, or each other?

That test came up negative, which both proved that there were no shorts on the power supply board, and also that I hadn’t mixed up part of a voltage rail. Then I used the points on the underside of the ATX connector (I really should have labelled this – fixed in the repo) to do a continuity test to make sure they ended up in the right place. +5V, +12V, and -12V all connected where I wanted them to.

Now, reasonably confident that I hadn’t completely hosed things, I installed the power supply into the case, routed the various cables, and got ready for a test.

Let’s Go Into Towns

For my first test, I made sure to clear a lot of desk space, and set the Towns up on its own power bar. That way, I could flip the switch off (or pull the cord) if things got bad in a hurry. I also made sure I had a fire extinguisher close to hand. Even after building so many freakin’ power supply projects, I still get antsy about that first loaded-up run.

My first surprise was that the power supply turned itself on as soon as I plugged it in. Whoops. I must have screwed something up in the soft power. That said, the supply came on properly, and the computer lit up the monitor and started drawing the Towns boot screen… and kept running.

I started my stopwatch, and at 15 minutes of continuous runtime, I decided that the power supply replacement was probably successful. The CD-ROM tray opened and closed when I pushed the button, and I was pretty sure I also heard the spindle motor rev up too. Although the dirty system fan is running and pushing a lot of air, its bearing sounds pretty noisy, so I may need to oil it or budget for a new one.

After the 15 minutes, I went ahead and tested out the power button again. Pushing it turned the computer off, nicely. Pushing it again turned the computer on, nicely. In other words, the power supply hit most of my goals.

My next move on the Towns, after convincing myself the power supply worked “well enough,” was also straightforward. I wanted to boot this computer into actual software. In my voluminous hoard lives an A-Train III CD-ROM for FM Towns.

Hey, it works!

I can’t wait to be able to click these buttons.

What’s next?

Obviously, the next step is to figure out why the supply turns itself on when it’s introduced to power. I’m hoping that I just screwed something simple up on the reset circuit, and I can quickly modify it without needing a re-spin (and corresponding labour-intensive rebuild.) Once that’s figured out, I will open up the GitHub repository for the board. If you are OK with the current status of the board and need it to resurrect your own FM Towns IIHR, please let me know privately and I will mail you a spare board to build up.

Personally, I never leave my old computers plugged in when I’m not using them, so this will probably be just fine for my needs until I can figure out how to fix the bug.

Now I know the thing boots, so another good project on this computer is to either get a keyboard and mouse combo, or build some kind of adapter. Thanks to the hard work of other folks, I’ve already secured a Hirose HR12 connector to build a keyboard adapter. The protocol and pinout for the keyboard and mouse are well documented in the official Fujitsu FM Towns Data Book, which I look forward to reading cover to cover.

There is still one feature left to test on the power supply: soft-off. That will require me to get into an operating system that has a “shut down” option, and then pick that option. Imagine how much more stuff has to go right before I can truly test this one little signal on the PSU board!

Last, I want to build a SCSI adapter for the weirdo connector inside the system, and then install a BlueSCSI or some other SCSI emulator, so that I can boot my Towns without having to worry about CD-ROM drives ever again. After that, I’ll be browsing the huge piles of FM Towns shareware that Fujitsu has compiled on various CDs, and generally enjoying my life in a new Towns.

Thanks for reading!

Where to get it for yourself

If you want to build your own, I have open-sourced the FM Towns IIHR power supply project on my GitHub account. Gerbers are provided for download in the Releases section, but the BOM and installation instructions are a work in progress.

Repair Summary

Fault	Remedy	Caveats
Power supply does not stay on.	Inspect and replace R85 resistor, clean corrosive capacitor leakage.	Other resistors are also damaged.
Power supply still does not stay on.	Replace entire power supply.	The prototype supply does not stay off when you plug it in.

Like Apple during the post-SE era, Fujitsu did not include a keyboard with the Towns system, with the claimed aim that buyers could choose which one they wanted (including several with OASYS-like key layouts.) Maybe this was part of a scheme to reclaim at least some of that margin. ↩
For those of you following along at home, the switch-mode IC appears to be an NEC µPC1099CX. ↩
A cheaper option is the 120-watt EPP-120S-12, but at the time of development it was only $3 less, so I figured I would rather pay the three bucks. When I designed it, we had at least one fewer war than we do now. The price of the 150-watt unit has crept up, and as I’m editing this, it’s now $12 more than the 120W. ↩

SyncMaster of the Universe

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Tate Mode Unlock

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

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

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

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

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

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

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

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

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

Sitting and Hurting

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

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

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

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

Repair Summary

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

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

Loonies for Loongsons

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

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

What is a Loongson?

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

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

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

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

What’s this one?

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

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

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

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

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

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

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

The Cooler

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

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

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

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

It arrives

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

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

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

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

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

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

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

Cooler install

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

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

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

First boot

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

The shell reads:

UEFI Interactive Shell v2.2

EDK II

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

map: No mapping found.

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

Shell>

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

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

Almost-operating system

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

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

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

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

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

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

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

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

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

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

Updating the BIOS

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

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

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

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

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

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

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

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

Debian, again

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

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

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

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

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

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

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

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

Wi-fi, part 2

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

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

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

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

Upgrading Debian

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

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

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

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

Benchmarks

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

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

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

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

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

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

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

Videogames

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

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

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

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

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

So what video chipset is it?

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

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

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

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

YouTube

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

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

Conclusion

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

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

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

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

Thanks for reading!

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