Leaded Solder

Cleaning up after a Camel

2026-10-13T00:00:00+00:00

Now that my port of CamelForth-80 to the Sega SG-1000 is sort of working, it’s time to get it working better. There’s a lot of undone odds and ends and little bugs that I need to take care of before I can try running it on real hardware, so this week’s (abbreviated) effort was mostly along those lines.

VDP Delay

The Sega SG-1000 is designed around the Texas Instruments TMS9918A video display processor. A lot of great machines use chips in this family, including the ColecoVision, the original series of MSX, the VTech CreatiVision, the BBC Bridge Companion, and the Sord M5. In fact, it’s pretty common to see posts about the TMS99xx around these parts.

Originally, this part was designed for the TI99/4A. Being such a complex part, it does have its little foibles, and one of them is that it takes the chip awhile to “start up” before it will respond properly to commands. We saw this problem back when I was building the Sega SG-1000 RAM test cartridge, where we found that if I started doing stuff as soon as the Z80 was running, some commands would get dropped or otherwise ignored.

All of the original Sega games seem to include some variant of a wait. They either stall explicitly with a “busy loop” for many seconds to wait for the chip to come awake, or spend the free time doing a bunch of Z80 processing and setup for the main game. On the ColecoVision, this isn’t as much of a problem, as the ColecoVision’s BIOS is responsible for setting up the VDP and then handing control to the game. By the time you’re running on that platform, everything is already warmed up and ready to go. The SG-1000 is not as fortunate, seeing as it lacks a BIOS entirely.

So why didn’t we have this problem before? Well, it’s because we’ve only been running this code on MAME, which doesn’t accurately simulate this aspect of the TMS9918A. By the time MAME starts, that 9918 is ready to go. For compatibility with real hardware, this is something that would need to be fixed.

For the purposes of the CamelForth-80 port, I just copied my busy-waiting code from my RAM tester:

sg1000_cold_start:
    ; The VDP gets reset at system startup, but it takes a lot
    ; longer than the CPU to be ready for action. The BIOS on the
    ; ColecoVision/MSX/etc seems to take care of this problem for games.
    ; We could do a bunch of setup stuff here, but for now we'll just spin until
    ; we think the VDP should be willing to listen to us.
#local
BusyWait:
    ld d, $3 ; girls garden used $2 x $ffff
_busywait_outer:
    ld hl, $ffff
_busywait_inner:
    dec hl
    ld a,h
    or l
    jr nz, _busywait_inner
    dec d
    jr nz, _busywait_outer
    ret
#endlocal

Now, it’s a little slower to test the code in the emulator, but it should be more stable on the real SG-1000. How are we going to get it onto the real SG-1000? We’ll get to that in a second.

Bad characters hanging around

One of the more distinctive aspects of my port so far is that every completed command seems to end up with one of these ugly blank characters being displayed:

Obviously, this is something that EMIT isn’t filtering out. There’s some non-printable character being emitted, and we just blindly print it instead of dropping it on the floor. I was feeling particularly lazy and didn’t want to read any code, so I popped it into the MAME debugger to watch what was going on with EMIT.

Turns out when I just hit the return key with nothing on the line, it first emits $20 and then $0d . $0d in ASCII is, of course, carriage return. Now that I knew this, I could go back and read the code to see who was at fault. The CR word built into CamelForth was in fact sending CR and LF to indicate they want a new line to be printed to the terminal:

;C CR      --               output newline
;   0D EMIT 0A EMIT ;
    head CR,2,CR,docolon
        dw lit,0dh,EMIT,lit,0ah,EMIT,EXIT

Rude.

In my hack to EMIT, I only handle $0a , line-feed, as making a new line¹, so $0d ends up being printed to the screen. Since there’s no character defined here, it gets that blank tile.

A further quick hack to EMIT dumps the character on the floor:

_check_for_ignored_character:
    ld a, c
    cp a, $0d ; carriage return
    jr z, _emit_exit

Notice how the naming leaves it open to more ignorable characters? Yeah. That’s what we in the business call extensibility.

Bye, little dude.

Words that interact with hardware

I started writing some words that would be the equivalent of the Z80 OUT and IN instructions, only to find out that CamelForth already defined some. PC@ reads from a port, PC! writes to a port, and C@ and C! do the same for memory: they’re the equivalent of PEEK and POKE. This is enough to start playing with actual hardware.

To test to see if this actually worked, I grabbed the emulator, put a watchpoint on the I/O space², and played around with it: indeed, the format {data} {port} PC! sent a byte to the I/O port I wanted.

I thought about what I wanted my first “outside world” project to be. Although the VDP would be fun to interact with directly, and bfox9900 provided some amazing TMS9918 definitions for their TI-99/4A CamelForth port, I thought that it might be too complicated for a first piece of test code.

Why not the PSG?

The SN76489 sound chip seemed like a way easier prospect: I could get it playing a tone just by sending two bytes.

I wrote some SN76489 code a long time ago, but it was mostly to just test if a bunch of AliExpress chips worked at all. It wasn’t even a good test, as I later found out at least one of them was bunk when I put it into a Soggy clone under construction.

SN76489 has two kinds of commands you can send to the chip: the “latch/data” command, and the “data” command.

Latch/data commands take:

A header bit indicating it’s a latch/data command (1)
A channel (tone 0, tone 1, tone 2, noise)
A type (are you configuring volume or noise?)
4 bits of data

Tone is a total of 10 bits of data, so it doesn’t fit into a single byte. If you’re configuring tone, you follow that 4 bits of data with another 6 bits of data in a data command:

Data commands take:

A header bit indicating it’s a data command (0)
1 unused bit
6 bits of data

So in other words,

If you want to	Do this
Change volume	Send a latch/data command to any channel with type bit = 1, volume value in 4-bits of data
Change noise	Send a latch/data command to channel 3 with type bit = 0, noise data³ in lower 3-bits of data (1 ignored)
Change tone	Send a latch/data command to channels 0-2 with type bit = 0, and the first 4 bits of tone data, then a data command with the subsequent 6 bits of tone data.

Phew, that looks pretty complicated, but there’s only really 3 kinds of operations here. Can we build these up from simple Forth words?

Fundamental operations

Doing this, of course, required me to figure out how to do some bit masking and packing. I cheated for this first bit and wrote it in assembly.

Volume word

The first word I did was PSGVOL, which sets the volume for a given channel. This one was relatively easy, once I got my pad and pen out and started tinkering with bit math by hand. Verifying it later in the debugger, I made sure that the channel number and volume data didn’t destroy any adjacent bits.

Data word

This one is very easy. I just take whatever is on the top of the stack, lop off everything except the bottom 6 bits, and send it to the PSG.

Noise word

Implementing NOISE was easy, too. First, I made a copy of PSGVOL, called PSGLATCH, whose major difference is that it did not set the volume/tone/noise bit. It latches the data in. Then, I wrote a quick Forth word which is the equivalent of:

: PSGNOISE 3 PSGLATCH ;

In other words, it would use whatever is on the top of the stack (data; the “first” argument in the call,) put 3 (the ID of the noise channel) on top of the stack, and call the PSGLATCH word to consume both numbers.

Calling that let me make rocket ship sounds, once the volume in channel 3 (noise channel) was appropriately set. Hey! Composing words is easy and fun, as long as you don’t have to do a ton of stack manipulation in the middle of ‘em.

It’s almost like this is exactly what Forth is good at: iteratively building up a working system.

Tone word

Now we’re in the most complex word of them all. Recall a few paragraphs ago: in order to send a 10-bit tone to the PSG, we first have to latch in the top 4 bits of our 10 bits (with PSGLATCH) and then send the bottom 6 bits with PSGDATA. That seems straightforward, if you have local variables and aren’t working in a language you have very little familiarity with.

I decided that I would rather do this in pure Forth, instead of writing an assembly word that called into Forth somehow. I was just too afraid of mangling the stack, and the recent success of PSGNOISE gave me some hope that I could somehow figure it out by messing around in the interpreter.

From reading the CamelForth source, I knew that 2* did an arithmetic 1-bit left shift, and LSHIFT did a logical n-bit left shift. Why these two are not the same calling convention, I am unsure, but I had some good tools to work with. OR and AND do the obvious thing as well.

First, I did the simple bitwise math to construct the bottom 4 bits of the latch command from the bottom 2 bits of the top byte and the upper 2 bits of the bottom byte. That was easy, and produced the right call, as verified in the debugger.

Unfortunately, doing all this bitwise math mangled the data argument in the process, and I’d need those bits I got rid of for the second call! It consumed the channel number, as well. I’d need to make copies of them, but how could I do it without a local variable?

The answer is stack manipulation. Forth has a bunch of cool words that do stuff like duplicate the value on top of the stack (DUP,) swap the order of the item on the top of the stack and the item one underneath it (SWOP,) rotate the order of the top three items (ROT,) and inject the item at the top of the stack beneath the item beneath it (OVER). I learned about all of this by reading the source code to CamelForth, and also the diagram on the “Stack Operations” page in the Forth Intro.

One nice aspect of Forth that I didn’t appreciate before is that the stack-modifying convention is usually specified in the comments. It’s even machine-testable in the fancier modern Forths as well. Initially, I just overlooked it as line noise, but let’s take a look and see what, for instance, ROT says it does:

ROT x1 x2 x3 -- x2 x3 x1

That seems pretty explicit! Turns out human beings write comments for other human beings to understand.

Now that I was armed with the awesome power of “finally reading the documentation,” I was ready to play around. Initially, I used a lot of paper to figure out the stack flipping operations: I suspected that I would be well-served with a Forth with some kind of stack visualizer. I ended up using Factor on my Mac to prototype the various operations.

In the end, I arrived at something like this:

: DOUBLEUP OVER SWOP DUP ROT SWOP ;
: PSGTONE DOUBLEUP SWOP 6 RSHIFT SWOP PSGLATCHSET DROP SWOP 63 AND SWOP PSGDATASET ;

Wow, a non-trivial Forth program!

Clunky, isn’t it? Let’s step through what’s actually going on in PSGTONE.

As discussed previously, I manipulate the stack to make a copy of the 2 arguments I expect to be there. The stack ends up looking like ... data channel data channel, with channel on the top of the stack⁴.
I swap the order of data and channel so that data is top of the stack, and ready for manipulation.
6 RSHIFT shifts the value of data six bits to the right (remember that data is a 16-bit number) so the previous top four bits are now the bottom four bits.
I swap the order of channel and data back, so it’s in the format to call PSGLATCHSET, which sets the PSG latch with the first four bits of tone data.
I know that PSGLATCHSET consumed the data and channel on the stack, so I am now using my copies.
I do DROP to get rid of whatever nonsense PSGLATCHSET put on the stack because I was religiously doing a pop bc at the end of every call when I wrote it (I need to fix this.)
As with step 2, I swap the order of the top two items on the stack again, preparing data to be manipulated.
I AND data with 63 ($3f ), which knocks off everything except the bottom 6 bits. This is probably unnecessary since PSGDATASET also does the same thing, but it makes me feel cool to have unexplained constants in the middle of my code.
As with step 4, I swap the order back so we’re ready to call PSGDATASET.
I call PSGDATASET, which sends a command to the PSG with the remaining six bits of data.
A tone plays.

Now, I can make really annoying ear-piercing sounds. If I knew how to play music, in theory I could compose these PSGVOL and PSGTONE calls further, making words that understand something like MML notation. However, I don’t know MML yet, so all I can do is annoying beeps.

It’s sort of annoying writing the 0, 1, and 2 in front of PSGTONE and PSGVOL all the time, so I did define some convenience words as VOLx, MUTEx, and TONEx. They do exactly what you think they do.

This can probably be way shorter. I’m sure there’s some powerful stack-manipulation word or some classic technique that I’m just not aware of yet. Also changing the order of arguments would have made things a lot easier, but I wanted to stick with the data, port convention of PC!.

Flash cartridge

I was sincerely hoping to not have to do any hardware stuff for this RetroChallenge. In the past, having to order a PCB and wait a few days for it (and the parts) has rudely thrown off my schedule. Thing is, I was starting to get tired of seeing my work running only in an emulator, and I really wanted to demonstrate the real hardware at a local meet by the end of the month.

I’ve already designed cartridge PCBs for the SG-1000 before: in fact, at least two of them would be suitable for this purpose. I have a simple ROM cartridge, which holds up to a 32K program: the largest possible in the standard SG-1000 memory map.

More recently, I also made a BASIC ROM cartridge, which adds a (largely unmapped and therefore unusable) 64K SRAM to the board in order to support Sega’s Level 3 BASIC.

Neither one of these is exactly what I want. For a dream Forth system, I would want these two features:

A flashable ROM, so I could quickly assemble the interpreter on my computer and send it to the SG-1000 for testing;
A battery-backed RAM, so the Forth system on the SG-1000 could save custom words between power-offs and resets.

Both of these problems open up a huge can of worms: at least one article worth of struggle on each. I’m not sure I’m ready to tackle them, given the few weeks left in RetroChallenge. I just wanted the dopamine hit of getting this thing to work. So I set about getting my CamelForth port ready to be placed on a standard ROM cartridge, burning it to a 32kByte 27C256 EPROM that I had lying around.

As built, my (no doubt highly wasteful) ROM was 7381 bytes, so I used my prepare.py script to pad it and then duplicate it four times to fill a full 32k ROM. The mirroring doesn’t really do anything, and may in fact even mask bugs, but I do it out of habit because it feels weird to leave part of the ROM empty.

Obviously, the iteration speed on this is a lot slower than having a dedicated flash cartridge. UV EPROMs take a long time to erase, and they’re fiddly to keep pulling in and out of sockets to program and wipe them (the legs aren’t getting any stronger with age.) At this point, though, I felt like things were “mature enough” that I hopefully wouldn’t have to do a gazillion iterations to figure out what’s wrong – I still had a pile of unerased ROMs left over from failed attempts at the RAM tester before I discovered the aforementioned “make the VDP wait” trick.

Unfortunately, this part of the project will have to wait until next week! I simply ran out of time messing with all of the sound code and the hours got away from me.

Conclusion

Wow! I wrote an actual Forth program today, with stack manipulation. Although I’m certainly not a rabid adherent to the language yet, I am starting to see the value in its very basic design.

In the next part, I’ll dig out my Soggy-1000 clone, and a keyboard, and a spare cartridge PCB, and hopefully find a ROM that I can program. Then we’ll see if this works on a real console at all. Boy, I wonder where all that stuff is in my junk ~~pile~~ stack?

Thanks for reading!

We could argue all day about whether line feed is the appropriate character for which to begin a new line on my terminal, but C on sane platforms uses \n too, so I figured it was probably the right move. ↩
MAME’s watchpoints let you detect accesses to I/O and memory spaces. In the case of the Z80 I/O ports, you can set a non-breaking watch on anything written to port 0 with the command wpiset 0, 1, w, 1, { printf "I/O port written!\n"; g }. Check the full MAME documentation for more details on all the cool stuff you can do even without MAME’s extensive Lua scripting support. ↩
The noise data consists of 1 bit, which decides if the noise is “periodic” or “white,” and the other 2 bits configure how fast the internal shifter that drives the noise runs. ↩
After this article went to publication, bfox9900 mentioned that it could be simplified to : 2DUP ( a b -- a b a b) OVER OVER ;. Which is totally correct… and already exists in CamelForth! ↩

A Typed Forth

2026-10-06T00:00:00+00:00

Now that we have a functioning Forth interpreter on the Sega SG-1000, it’s time to actually finish hooking up the keyboard input. Because I considered this task to be a little mind-numbing, I’ve put it off for years. How long do you think it took me to figure out? About an hour. One day, I’ll learn.

The story thus far

A few years ago, I was playing around with the Sega version of BASIC for the Sega SG-1000 game console. It was sort of the celebratory lap after adding keyboard support to the Soggy-1000, my low-cost open-source clone of the SG-1000.

That experience left a lot to be desired. Between the limited keywords, difficulty in extending the interpreter, and the poor runtime performance, I thought it would be possible to get a different language working on the machine.

Forth is a super-popular language for low-level programming, as it offers just enough abstraction to keep you sane. Most implementations also offer an interactive “interpreter,” so you also get the immediacy of a good BASIC implementation. I decided to port CamelForth-80, the Z80/8080 port of the popular CamelForth interpreter, to the Sega SG-1000¹.

In the previous article, I documented how I got CamelForth to assemble on my modern assembler, and how I hooked the output from Forth to video output on the Sega SG-1000. Then, I ran into the problem of having to write some code to poll the Sega’s keyboard… and put it aside for several years.

Now, with RetroChallenge well underway, the pressure was on to actually finish that keyboard handling code, even if it’s clunky or otherwise inelegant.

Are you a scanner?

Now was the time for keyboard handling – some very boring, repetitive code! Yaaay!

To scan the keyboard on the SK-1100, you do this process:

Set the lower three bits of port $df to the row of the matrix you want to look at.
Do at least two NOPs to wait for the 8255 to select the lines, and for the data from the matrix to show up on the 8255’s input ports.
Read the row from port $dc for the first eight columns, and $dd for the second four columns of the keyboard matrix. One bit per key will be returned; check which bit is set to know which key is pressed (“active low” in the code.)
Based on your row position and which column is lit up on the 8255, look up and return the ASCII character for that key² (if applicable) to the calling Forth code.

For starters, I ended up making a 14 x 8 2D array in the code, and then using bit tests to figure out which column to send to the array. The scanning function works something like this:

for row = 0 to 6: ' row 7 is for joysticks
        out($df, row);
        nop(); nop();

        keys_down = in($dc);
        for bit = 0 to 7:
                if bit(keys_down, bit) == 0:
                        return keymap[bit, row];
        keys_down = in($dd);
        for bit = 0 to 4:
                if bit(keys_down, bit) == 0:
                        return keymap[bit + 8, row];
        
' nothing pressed
return 0;

Inelegant, maybe, but it works. The actual implementation is insanely ugly, and involves a lot of hand-unrolled loops where I have this kind of thing copy-and-pasted forever:

_kbd_a_bit0:
        bit 0, a ; TODO: Could this be done in a macro?
        jr nz, _kbd_a_bit1
        ; handle key press at bit 0; IDX = 0
        ld c, (ix + 0)
        jp _segakey_out

_kbd_a_bit1:
        bit 1, a
        jr nz, _kbd_a_bit2
        ; handle key press at bit 1; IDX = 1
        ld c, (ix + 1)
        jp _segakey_out

_kbd_a_bit2:
    ...

Phew. That’s a lot of wasted ROM space and a very annoying chunk of copy-and-pasted code that could probably just be a macro at the very least. An obvious improvement would be to compare a to a bitmask, and just do bit shifts on that mask to iterate instead of constantly checking bit 0, a, bit 1, a, etc. But it worked, as you’ll see below.

The keymap looked something like this:

SOGGY_KEYMAP:
    ; 1, Q, A, Z, 0, ,, K, I, 8, 0, 0, 0
    .db 0x31, 0x51, 0x41, 0x5a, 0x0, 0x2c, 0x4b, 0x49, 0x38, 0x0, 0x0, 0x0
    ; 2, W, S, X,  , ., L, O, 9, 0, 0, 0
    .db 0x32, 0x57, 0x53, 0x58, 0x20, 0x2e, 0x4c, 0x4f, 0x39, 0x0, 0x0, 0x0
    ; 3, E, D, C, 0, /, ;, P, 0, 0, 0, 0
    .db 0x33, 0x45, 0x44, 0x43, 0x0, 0x2f, 0x3b, 0x50, 0x30, 0x0, 0x0, 0x0
    ; 4, R, F, V, 8, 0, :, @, -, 0, 0, 0
    .db 0x34, 0x52, 0x46, 0x56, 0x8, 0x0, 0x3a, 0x40, 0x2d, 0x0, 0x0, 0x0
    ; 5, T, G, B, 0, 0, ], [, ^, 0, 0, 0
    .db 0x35, 0x54, 0x47, 0x42, 0x0, 0x0, 0x5d, 0x5b, 0x5e, 0x0, 0x0, 0x0
    ; 6, Y, H, N, 0, 0, 13, 0, 0, 0, 0, 0
    .db 0x36, 0x59, 0x48, 0x4e, 0x0, 0x0, 0xd, 0x0, 0x0, 0x0, 0x0, 0x0
    ; 7, U, J, M, 0, 0, 0, 0, 0, 0, 0, 0
    .db 0x37, 0x55, 0x4a, 0x4d, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0

To figure out the key map, I used the fantastic diagram from Enri’s SK-1100 writeup:

Now that you’ve looked at that matrix, you might notice that something is missing in my handling code up above: modifiers. How am I supposed to be able to type a ! if I am not handling the shift key? That’s a very good question, and one that I didn’t want to solve right away. Perfect is the enemy of good, and all that.

After some fumbling around – I forgot to actually increment the row counter and also overwrote the accumulator that I was using to store that counter – I managed to make it work!

That progress feels really good after many years of procrastination. It’s not noticeably slow, either: even old 8-bit computers are good at doing stupid things really quickly, and it’s not like the computer is doing anything else when it’s waiting for input!

Even return worked, letting me ask the SG-1000 if it had heard of my blog:

Now I can do some simple math:

Even with all this mirth, there were two obvious bugs:

Pushing backspace didn’t, well, backspace.
Pushing the “1” key would reset the computer.

Checking my notes, I realized that the second issue had been a problem on my previous keyboard-scanning code, too. That’s weird.

Why does pressing “1” reset the computer?

After awhile of fumbling around in my code, I realized it would still happen even if the entire keyboard handling were to be commented out. I began to suspect MAME had something weird bound to the 1 key, and indeed it did:

Oops. Pushing the 1 key, even with UI keys disabled, told MAME to push the imaginary pause button on the emulated SG-1000 unit, which triggers an NMI and then crashes because I don’t have a handler for it. Whatever chunk of memory that is located where the NMI vector is expected is no doubt wreaking havoc. I deleted this keybind in the MAME settings and suddenly it stopped rebooting.

The funny, or at least fascinating, part is that it would still type out the 1 before crashing. I’m not sure if this “double firing” is a bug in MAME; it feels like it’s debatable whether the pause button on the front of the unit is a “UI key” or not.

That said, the Pause/NMI button will have to be handled later, because not handling it is sloppy and I already have a reset button on my hardware. I don’t know how to handle it yet, so I added it to my TODO.md and kept going. Now for the mystery of the backspace!

What’s wrong with the backspace?

After a few more minutes of squinting and reading code, it turned out to be the same problem as 1. Well, almost the same problem. The “INS/DEL” key on the emulated SG-1000 was bound to Delete and not Backspace. With a quick rebind, I could suddenly make mistakes again.

Can’t type worth Shift

Now that I could write a Forth program, it was time to… write a Forth program. Only one problem, though. Without a shift key, there is a lot of punctuation I can’t do, such as ", +, <, =, you know… unimportant things for writing programs. I would have to implement the shift key, and potentially ruin my whole day.

My first whack at the problem was to do exactly what I described above: add a second keymap, and just use that instead when the shift key was held down.

This caused something unexpected to happen: the lowercase letter that I intended was immediately followed by an uppercase letter. At first, I thought this might be my debounce code, but I realized that not every letter was doubled up. For instance, j, 7, u, and m didn’t fire twice when shifted. If you check the key matrix up above, you’ll notice they’re all on the “last” row… with the modifiers. That was even less expected. What was going on?

I fumbled around for the better part of a day. In the meantime, I did realize that you could use backspace to remove the extraneous character and actually write some useful programs:

As I was trying to debug my problem, it turned out to have some particularly weird phenomena. If I didn’t scan row 6 during the regular scan, the shift key wouldn’t work at all. This sent me down a bit of a rabbit hole where I began to suspect the emulator³, but we all know it’s never the emulator. It’s my fault.

I had hacked up the keyboard-scanning code I just wrote to “check the shift row first,” and so I started tracing the code step by step instead of looking at the comments. Uh, turns out I forgot to actually write to the port that changes the keyboard row. Oops!

I had written it like this:

        ld a, 6
        ld (KBD_SCAN_ROW), a ; select the accelerator row
        nop
        nop

But what I really meant to write was this:

        ld a, 6
        out ($de), a ; actually write to the port you idiot
        nop
        nop

KBD_SCAN_ROW is a global that I used to make the scanning code a little easier to write; it just keeps track of the row index so that the contents of the accumulator don’t get destroyed during the tests. I’m still paranoid about inadvertently stomping on a register that the outer Forth needs.

D’oh.

Conclusion

Phew! I feel kind of dumb putting this off for so long when the initial implementation was so quick to do. Of course, I keep generating more bugs, but there’s always next week.

Even after these little bugs are fixed, there’s still a lot more to do for keyboard handling. For starters, I want to see if I’ve got room in the character set for kana and graphics characters. It’s easy to lose track of how cool something as simple as “type characters and have them show up on the screen” is.

This was a lot of work. If only there was some kind of higher-level language with loops and stuff that I could have written this keyboard driver in. Maybe it could even compile down to assembly for optimization?

Thank you for reading! I hope to see you again soon.

CamelForth-80 is GPLv3 licensed, so I am publishing the modifications to my GitHub repository here. Use it at your own risk! I have no guarantee the main branch will remain unbroken. ↩
Yes, this prevents you from pressing more than one key at once, but the SK-1100 keyboard doesn’t have any anti-ghosting diodes, so it’s likely to not be a problem. We’ll see if it actually becomes one in practice. ↩
I did try the fantastic Ares emulator, but for whatever reason it will load neither this Forth ROM nor my homemade RAM tester, both of which work fine in MAME, and the RAM tester even works on real hardware. I will have to do some more investigation later. ↩

More like SC-Forth-thousand, am I right?

2026-10-01T00:00:00+00:00

The Soggy needed a good low-level programming environment with which to tinker on future hardware projects, and ideally it was one that I controlled myself, so I could include it on the onboard ROM without infringing copyright. It would be nice if it used a semi-popular programming language for embedded systems, and had an interactive development environment that I could run right on the machine. All that seems to mean I’m finally going to make my first Forth.

The Soggy?

Sega’s first home console and their first home computer are very similar machines. Although the exact reasoning hasn’t been said (to my knowledge,) Sega originally planned to release multiple home computers, at different levels of capability. This plan changed to releasing just one home computer (the SC-3000) and one game console (the SG-1000.) Unfortunately for them, the SG-1000 released on the exact same day as the Nintendo Famicom, but Sega considered it to be a success anyway.

What’s interesting about the shared heritage between these two machines is that you can attach a keyboard to an SG-1000, in order to turn it into sort of a de facto SC-3000¹. A lot of companies promised stuff like this in the 80s, and Sega delivered. As a result, you can run (a very limited form of) BASIC on your SG-1000.

Although I have a very fragile and deteriorating SC-3000, I wanted something I could play with without worrying about shattering delicate keyboard plastic on. The prices of somewhat-more-durable SG-1000s are high and on the rise, especially the very Shōwa-futurist first-generation model. I also had experience with making a clone of the ColecoVision, which uses many similar parts to the SG-1000 (but is not cross-compatible in any way.) I ended up making a clone of the SG-1000, called the Soggy-1000, and made sure to make it compatible with the SG-1000 keyboard.

Naturally, with this kind of ambition and/or excess free time, I quickly ran into the limitations of Sega’s BASIC. A real computer should be able to build programs on and for itself!

RetroChallenge

This project is done as part of the RetroChallenge, a quasi-annual informal competition where everyone gets together and does something cool with retrocomputers for an entire month. This is for RetroChallenge 2026/10. I find that the event helps force me to work on one project, instead of bouncing around between a billion ideas, and so I can get big leaps of progress out of my projects in just one month.

By the rules of RetroChallenge, you are not supposed to start your work early, so that’s why this article is coming out at the very start of the month. It’s all stuff that I have done months, and in some cases, years prior, and the real “challenge” is just getting me to finish it. Everything from now on is part of RetroChallenge, and this article should serve as a primer to figure out just what it is I am trying to do.

Okay, on with the Forth.

Why Forth?

In case you’ve never heard of it, Forth is a very minimal high-level programming language. It’s very common in embedded and small systems, mostly because it’s easy to get the base system working and then lets you incrementally build some functionality using a command shell. Think of the Python REPL, and you’re on the right path.

It takes awhile to wrap your head around the stack-oriented design, but once you do, it is surprising just how elegant the language is. What the Hell is Forth is a great read on the subject, which I saw kicking around the internet only after I started on this ridiculous project.

Another big appeal of Forth to me on these limited machines is that, in many distributions, Forth often includes an integrated assembler. With a suitably equipped Forth interpreter², you can bang out assembly language programs in a REPL on the real hardware, which is an experience you can’t really get anywhere else.

The biggest grain of salt to take with this article, and pretty much every future one I write on the subject, is that I don’t really know how to write programs in Forth. I can hack together a simple program with some serious effort, but I still need to jump back to the documentation to understand a lot of the jargon, and I am almost useless at reading code. Do not consider me as a Forth expert, or even an enthusiastic amateur. The point of this series is to show how easy it is to bring up a Forth interpreter on any random computer you may encounter. If you’re an experienced Forth programmer, please forgive me any screw-ups in advance.

Why Forth on the SG-1000/SC-3000?

With Forth on the SC-3000, I can write all kinds of programs, in a more space-efficient way than with BASIC³. It’s also, frankly, less irritating: I got more than my fill of renumbering large BASIC programs in the 90s.

Forth’s higher-level and more structured than assembly, which means I can write programs much faster without stepping on myself trying to remember the semantics of otir. If I want to, I can even include an assembler, so I can write really fast, useful code right on the machine without having to involve a “real computer” to cross-assemble for Z80.

Last, with the ROM-socket on the Soggy, it also provides a useful platform to make it more useful as a general-purpose computer, with a powerful programming language that’s ready to use from a cold start. I can even write device drivers for new stuff connected to the expansion slot! Like the aforementioned article says, it’s like an assembly REPL.

While I was working on this project, I also found an amazing article in Kilobaud magazine, called, well, Write Your Own FORTH Interpreter. If you’re interested in the mechanisms of how these things really work under the hood, make sure to open that up in a second tab. Or third, or 400th. We’re all friends here.

Port a Forth

I first wanted to start out by porting a Forth. This would cause me to get a lot of the “SG-1000 specific” stuff out of the way, plus maybe give me some good ideas about my implementation. The RomWBW project contains a fork of the GPL-licensed CamelForth-80, by Bradford J. Rodriguez.

CamelForth is originally intended to run on CP/M-80, but the author has thankfully provided a thorough porting guide for how to modify it to run standalone, out of ROM. I have to write my own hardware initialization (TMS9918, stack pointer, etc,) a reset handler, move some buffers around, and replace three words that are implemented to use CP/M.

Those three words, implemented in Z80 assembly, are:

KEY: Returns the key being pressed;
KEY?: Returns true if a key is waiting;
EMIT: Prints a single character to the screen.

It’s really nice to see a thorough porting guide like this. I read through the source code and tried to come up with a plan for attack, merging it into the codebase of my RAM testing program in order to provide a console interface and basic keyboard-reading functionality.

Since the RomWBW version was modified, I ended up grabbing the original from the CamelForth website and working from that.

Getting it to Assemble

You might think all Z80 macro assemblers are pretty much the same. However, there’s a lot of differences in syntax, the order of operations, and especially in macro implementations. CamelForth-80 was originally built with the freeware/public-domain Z80MR assembler, but I have been using Zasm for all of my Z80 projects to date.

I don’t have a particular attachment to zasm, but Z80MR is meant to run in CP/M, and as far as I could tell did not have a modern Mac/*nix port. In fact, if you do a web search, the majority of surviving references to its existence are from CamelForth-80’s own readme. I had to hunt around for a little while until I found this copy of it in the DiscMaster archive of the Oakland CP/M archive CD, where it was distributed in (what else?) Z80 assembly.

So: I’d have to port the assembly from one assembler to another. Should be easy, right?

Building It

The first place zasm bailed was on the very first Forth word defined in the source code, EXIT.

in file camel80.asm:
210:         IF  .NOT.(docode=DOCODE)
                      ^ condition not evaluatable in pass1

That word expanded a macro, head, which itself expanded into a conditional define – an #ifndef, if you will.

head    MACRO   #label,#length,#name,#action
        DW link
        DB 0
link    DEFL $
        DB #length,'#name'
#label:
        IF  .NOT.(#action=DOCODE)
        call #action
        ENDIF
        ENDM

[..]

;C EXIT     --      exit a colon definition
    head EXIT,4,EXIT,docode
        ld e,(ix+0)    ; pop old IP from ret stk
        inc ix
        ld d,(ix+0)
        inc ix
        next

It looks like the last argument of the macro invocation, docode, is meant to signal that the word is implemented as an alternative assembly-language routine, rather than to consider it “as pure Forth.” In other words, it’s thunking out to native code.

Many of the words in CamelForth are defined as docode, which would then match the DOCODE define at assembly-time, assembled into the binary, and then be called when that word is requested at runtime. Others will use the dovar or docolon handlers, which respectively define a Forth variable or composes a Forth word from other Forth words. docode has no special implementation and just falls right through to the rest of the assembly language defined in the word.

The exact way it’s implemented doesn’t really matter to me, but it seems that zasm does its passes differently than z80mr does, and is complaining about it. It does not want to expand the macro and evaluate the macro that came out of that macro on the same pass.

Quoth the zasm documentation:

‘if’ starts a block of assembler instructions, which is only assembled if the given is true. The must be evaluatable in pass 1. Conditional assembly may be nested. note: this may change.

[…]

Normally the assembler directives with ‘#’ should be used. Except that ‘if’ and ‘endif’ can occur in macros and the expanded macro can conditionally exclude some code.

So… including this from a macro should be fine. Why can’t it figure out if our action is equal to DOCODE, a constant, on pass one? I couldn’t figure it out, so I ended up copy-pasting the head macro and making two versions: one that was for everything but docode and one that was just for docode. Then I did a search and replace, and those assembly errors went away. The same thing had to happen for immed, the macro that defines immediate words⁴.

I also had to escape bare characters like <, as the assembler expected a matching brace, or in the case of <>, eliminated them entirely, leaving an empty string.

The next problem was some seemingly oddball names for words. Forth is extremely loose with its naming rules compared to other languages. You can name a dictionary word pretty much anything you want, as long as it doesn’t have a space in it. There’s words called things like COMPILE, or just ,. The head macro generates the strings that are matched to call these words automatically, as you can see in its definition above, from the '#name’ line.

You have head macro invocations like this:

immed SQUOTE,2,S",docolon

You and I both know that that is intended to become a word called S", and that they’re not trying to define a string, but zasm is pretty sure that quote mark’s the start of a string.

Zasm has trouble parsing some of these lines, because it doesn’t know they’re not really going to end up being a string in the end. Presumably Z80MR doesn’t care, or its parser can deal with this somewhat unusual case more carefully.

356:     immed SQUOTE,2,S",docolon
                                  ^ closing '"' missing

Words with commas in them were even worse, as the original author had pre-quoted those. Presumably Z80MR is loose enough that it didn’t mind inserting those into a quote inside the macro either:

99:         DB 3,'',CF''
                   ^ closing quotes expected

Escaping those quotes in a bare word, as I had with <>, is a no-go either. Commas are special in a zasm macro invocation:

85:     chead COMMAXT,8,COMPILE\,
                                 ^ too many arguments: required=3

If I use double-quotes to escape it, zasm just goes ahead and crams those into the listing file verbatim, which isn’t good since I’m going to have to type these later to run the words:

        DB 1,'"."'

Zasm’s documentation is unhelpful on this front:

Note: special characters in string cannot be escaped with ‘'. This syntax was (probably) invented later for the programming language ‘C’.

I decided there was no good reason to do it this way, and rewrote the macro so that it doesn’t try to string-quote the words. Then I went back and changed all the head and immed invocations to use proper quoted strings for the “name” slot.

I could have probably done this more cleanly, especially as ROM space will one day become a limitation. In order to get to the fun parts of this project faster, though, I wanted to get it out of the way.

A big final hurdle is that zasm has case-sensitive labels: the CamelForth-80 code often uses lowercase to define a label and then UPPERCASE to refer to it in code. Luckily, zasm also has a --casefold option that tells it to act more like a CP/M-80 assembler. Success!

At last, I had something built. Now, I just had to make it run on the SG-1000.

EMIT

Writing the EMIT function was a big challenge, but it’s one that I had expected would be coming up. As you might have been able to guess, EMIT prints one character at a time to the output device. On CP/M, the BDOS handles the nitty-gritty of this, sending it to either a TTY or the screen, including scrolling and buffering. On the SG-1000, we’ll have to handle this with the TMS9918 VDP, which does not support hardware scrolling.

First, let’s talk about what graphics mode we’re going to use to display the text sent to the virtual terminal. Because it’s easy to program, I chose to use the TMS9918 mode 1, or “Graphics 1.” This provides a 32x24 tile display. Although this mode presents significant drawbacks, mostly its tiny amount of visible characters, I find that it works well on a television set and also is – again – very easy to program.

First, I had to establish a means of communication between CamelForth and my nascent “terminal.” For starters, I needed to figure out how CamelForth was telling me which character it wanted to have printed. After some experimentation at making a native-code (docode) handler that wouldn’t crash the system, I eventually found that the register C contains the character they wanted me to print. So I shifted that around to get into the area of my font, and…

This was pretty cool, although it turns out that I had screwed up the calling convention and the system kind of halted at this point with a corrupted stack. After half-fixing that error, I now had an infinite spew of ok messages as the nonexistent keyboard input was read, presumably interpreted as a null-terminator (ascii $00,) and QUIT was invoked.

Eventually this stream of ok would run off the end of the nametable memory and start corrupting other parts of the VRAM, so this was a good excuse to implement scrolling. Sure, I could figure out and fix the problem first, but why waste a perfect scrolling test situation like this?

Implementing Scrolling

At first, I thought I could do scrolling in a clever way by having a ring buffer of the screen dimensions in RAM, and then I’d just update that buffer as I am asked to print out more text. If I run off the end of the screen, I’d need to scroll. To scroll the screen in this model, I’d blank the screen, redraw all the lines one tile up, and then wipe the next line encountered and start storing characters into that.

However, I ran into two problems:

Storing an entire screen buffer - 32 by 24 characters - takes up 32*24 = 768 bytes of RAM. That’s almost the entire 1K available for the original SG-1000, which I’d like to support, and doesn’t leave much room for the actual Forth interpreter⁵;
There was no actual reason to store the screen buffer in work RAM⁶, other than when I scrolled, which was going to be a very slow copy operation anyway.

We already have a buffer in which the characters on the screen are stored – the VDP’s video memory! The VDP has a massive 16 kilobytes of RAM available to it, and we can read and write it from the CPU. For instance, we often write to it to, uh, print messages to the screen.

Although I thought about doing something fancy with the nametable memory pointer, I ultimately decided the best way to scroll would be something akin to this pseudocode:

for y from 0 to height - 2:
    for x from 0 to width - 1:
        get character at (x, y + 1)
        store it at (x, y)
blank out last line to prepare for new input

All this interaction with the VDP might be a little slower, but at least no system RAM is consumed by it.

Because the height and width are fixed in Mode 1 as 32 columns by 24 rows, I ended up turning it into this simpler loop:

for hl from 0000 to 32 * 23:
        get character from vram[hl + 32]
        put the result into vram[hl]
blank out last line to prepare for new input

That was much easier to write, although I suspect I could have used the mysterious Z80 index registers as I was working with a fixed offset. I didn’t want to sweat the speed, considering I was going to spend most of my time waiting for the VDP anyway and had nothing better to do until it was ready.

Because I’m not doing this inside the blanking interval, there is the risk of a little bit of tearing on real hardware. The reader is welcome to do a super smooth per-pixel scrolling routine that never flickers.

Although interacting with the VDP is expensive, especially when doing a read followed by a write, the end result was good enough. In a future version, I could always speed it up by using a small buffer in RAM to store the temporary values and read a line at a time, so that I’m not constantly flipping between read/write with different addresses. Or I could do it all in the vblank interval, instead of risking tearing and ugly artifacts by doing it while the VDP is busy drawing a frame.

Nice.

Backspace and Newline

There were, of course, other complicated aspects to doing EMIT. Not every character is as simple as “draw tile at insertion point, increment insertion point, scroll if you need to.”

For instance, there’s backspace, which I think we can all acknowledge is an important key. If you haven’t experienced it before, I strongly recommend trying it.

Here’s why it’s difficult to implement. When “printed,” the backspace character is intended to clear the space prior to the insertion point, and prevent the insertion point from advancing. Both of those are unusual behaviours for a character, which usually do the exact opposite.

That’s bad enough, but because it’s moving in the other direction, that means there’s a potential for it to actually run off the start of the video RAM addresses and start writing into the other end of it. So your backspace code ends up having a bunch of special cases for “if they’re trying to do backspace, don’t do the normal method and do something else entirely.” I fully admit that I could have made it cleaner by rewriting it instead of adding a bunch of spaghetti-code bodges, but that’s life.

I also ended up making a clever piece of code for newline, which I’m somewhat proud of. The sticking point for me was trying to figure out which position is “the start of the next line.” After sitting and thinking about it for awhile, I decided that the cleanest way to express this in C would be something like:

if(to_emit == '\n') {
        insertion_point = (insertion_point + 32) % 32;
        // ...
}

This is a pretty simple solution. It finds the next line, and since it’s forcing it to a multiple of 32 using the modulo operator (%) then we’re sure it’s going to be the start of that line.

However, modulo on Z80 is a little tricky to write, so I thought about it some more. And a few days later, in the shower, I realized that 32 is a power of two, which means I could just use a bitwise operation to knock off the bits that make up any value other than a multiple of 32:

if(to_emit == '\n') {
        insertion_point = (insertion_point + 32) & 0b11100000;
        // ...
}

For instance, buffer position 33 becomes 64 using this strategy (65 is 0b01000001, which becomes 0b01000000 when you knock off the bits you don’t care about…)

I am sure that this is a commonly-accepted trick with 8-bit machines, but I felt kind of clever for figuring it out for myself. This implementation of newline was pretty quick to express in Z80 assembly, which would now join backspace as the second “special case” to EMIT.

It’s not `ok`

Now I just needed to figure out why the interpreter was going bonkers and repeatedly invoking QUIT, which is the word that eventually puts ok on the console.

When I started on this project, I had a very rough idea of how interactive Forth interpretation would work, based on a dim memory of half-awake reading of some Forth books in university:

User types some stuff.
User hits enter.
The interpreter breaks up the user’s input by splitting it along the spaces and storing the tokens in some kind of buffer – 2 2 + . becomes ['2', '2', '+', '.'] – and starts executing from the left side.
The interpreter sees a token, then looks for it in the dictionary to see if it’s a word, and calls that word. At the end of each word’s implementation, it calls NEXT.
NEXT grabs the next token of the input and performs step 4 again.
Assuming there has not been an error, when there are no more tokens left, NEXT calls QUIT, which cleans up some interpreter state, prints ok to the console, and returns control to the user.

My skills in reading and following assembly are a little amateur-hour, especially when that assembly is interspersed with Forth. I decided to set a MAME breakpoint on the implementations of KEY? and KEY, but neither one was being called!

The nice thing about CamelForth being based on CP/M is that I was able to figure out anything that was interacting with BDOS⁷ by checking what called the BDOS word – a native-language call that sets up the arguments and then calls CP/M at $05 . Naturally, since the SG-1000 doesn’t have a CP/M BDOS at that location, calling into that address would probably result in nothing, or a crash.

After some more prodding around, I found a mysterious word CPMACCEPT that was repeatedly being called by QUIT. After reviewing, I realized that QUIT was the code that handled the input buffer. So why did the readme talk about implementing KEY and KEY?, but not this?

I spent a good hour trying to figure out how CPMACCEPT worked, and how to modify it for my purposes. Then I did a Google search, and found that the bug had already been reported by another hobbyist. The solution? Just change the call to use ACCEPT instead of CPMACCEPT, which uses KEY as you might expect.

Even after that discovery, I still had to wrestle with the code a little bit to try and understand it, and ended up gutting KEY completely in order to get it to work like I thought it did (or at least, should.)

I quickly banged out just enough of a keyboard driver to be able to enter the letter A and the carriage return. Using some bodged code, I could enter a nonsense all-As word now, hit enter, and confuse the interpreter.

Yeah, I bet you don’t know what AAAAA is. Not yet, at least.

I defined a word in the assembly source:

head AAAA,4,AAAA,docolon
        DW LIT, 5, LIT, 5, PLUS, DOT, EXIT

In other words, it’s the hardcoded equivalent of the Forth definition:

: AAAA 5 5 + . ;

Or in English, “when someone comes by looking for AAAA, you add 5 to 5 and then print out the result, capiche?” Maybe that’s multilingual, I don’t know.

Anyway, after assembling, I typed in that new word, and called it:

That’s pretty cool!

What’s NEXT?

Little Forth joke there. For the rest of RetroChallenge, I will be implementing keyboard handling. It’s been a couple years since I did the work described in this very post, and the pressure of the challenge is going to force me to actually write the boring keyboard-reading code, even if it’s inefficient or otherwise “big.”

After that, my stretch goals are as follows, although I don’t plan or even hope to get to all of these this month:

Add TMS99xx/SN76489 words to Forth, so I can do graphics and sound;
Take advantage of the Soggy’s 32K of RAM and page-switching to allow you to write truly gargantuan dictionaries;
Figure out a way to do long-term storage of Forth dictionaries;
Build a useful Soggy Forth cartridge that can be used by anyone silly enough to put a keyboard on their Sega;
Maybe even figure out how to write a useful Forth program.

Thanks for reading! See you next week for part 2.

Although an SG-1000 with SK-1100 keyboard attached can run many of the SC-3000 titles and do “computer things,” it cannot run all of them due to a variety of reasons. My Soggy-1000 clone attempts to patch some of these differences over, but we won’t go into those details in this light little introduction to Sega history. ↩
Adding assembly words to CamelForth-80 is not in the planned scope of RetroChallenge this year. Maybe I’ll do it some other time, or just go nuts and write a whole dedicated CP/M port down the road. ↩
MITEC/Sega’s BASIC implementations have a clever “shadow” framebuffer so that the graphics commands can support bitmapped graphics with the TMS9918’s tile modes, but they sacrifice a lot of RAM to do it. ↩
In Forth, an “immediate” word is one that is executed immediately, instead of being compiled by the : keyword into a program. For end users, it can be used to alter the behaviour of the colon-compiler in the middle of its operation, potentially doing something like a macro expansion, but is largely unimportant if all you want to do is write simple programs in Forth and not develop a Forth interpreter like this one. ↩
The SK-1100 BASIC cartridges, intended for SG-1000, get around this by adding some extra SRAM to handle the ‘drawing buffer.’ I constructed a knockoff of this cartridge in the SK-1100 test article, which certainly could be used to build a Forth cartridge in the future. ↩
A lot of 8-bit BASIC implementations let the user scroll up and edit a previously-typed line, then hit return to “send it.” This is not a feature on SC-3000 BASIC, probably for the same reason of limited RAM, so I won’t be implementing such a thing for CamelForth-SG. ↩
BDOS is the pseudo-platform-independent “Basic Disk Operating System” component of CP/M, joining the machine-specific BIOS. It provides a bunch of syscalls for things like handling files and the terminal. ↩

Dogfighting the Sharp X68000 ACE

2026-09-29T00:00:00+00:00

When we were first introduced to the X68000 ACE, we saw that the board was very corroded from battery damage. Later on, I whacked the battery out of it and did my best to clean up the corrosion without completely dismantling the machine. This time, it’s personal. Workstation, that is.

My initial assumption was that all I’d really need to do is get the I/O board out and repair the obvious battery damage. But, as we all know, old plastics can conspire to slow you down on a project. In the end, the system still isn’t working properly, but it’s come a long way.

I had sat on this project for a few months/years, because it doesn’t really have a satisfying conclusion, but I decided that it would be better to publicize my struggles. Maybe it’ll help you fix your own X68000!

Taking It Apart

As you might recall, a twin-tower X68000 consists of two major boards:

The mainboard, which contains the RAM, BIOS ROM, various custom chips, and the CPU;
And the bottom board, which handles a lot of the 8-bit I/O (SASI, FDC, serial, etc) as well as containing the clock battery.

There’s an number of other sub-boards in my system, such as the one that breaks out the external SASI port, the analogue video output board, and the RAM expansion, but those aren’t really important today.

My goal here was to extract the bottom board from the system so it could be cleaned up.

Getting the bottom K5710DE “I/O” board out of the twin-tower X68000 ACE is nowhere near as hard as I thought it was. After looking at a YouTube video, I realized all I had to do was disconnect all the cables from that bottom board, and then remove two screws hidden at the rear of the ‘spine.’ After that, the five screws on the bottom of the machine came right out, which releases the bottom plate and board from the plastic bits. The board is screwed to the bottom plate of the case with three easy-to-remove screws.

Then all you have to do is awkwardly lay the rest of the system on its side, and try not to scratch the plastic any worse.

All of the exposed copper meant for grounding to the screw holes is corroded, with some of it having gotten a big dose of battery acid and corroding even further. The one in the centre is especially bad:

On the initial inspection, I missed that the pin header that goes to the hard drive (SASI) breakout board got corroded as well. Although the connector cleaned up with some alcohol, there’s some green crap all the way up inside the ribbon cable, which probably necessitates a brand new replacement in the future:

I marked the cable with an “X,” so I wouldn’t be surprised later when it came time to put a hard drive in it.

The bottom of the I/O board is surprisingly clean, with only a few spots covered in some kind of dusty white corrosion that seems to be not uncommon for machines stored in Japanese humidity.

Just like on the X1turbo, Sharp’s engineers put the I/O-board silkscreens on both sides to aid in diagnostics. Thank you!

Most of the actual gunk seemed to just be old flux on the ports, but I noticed a suspicious amount of dirt far away from them, especially on the bottom of this trim cap:

This was probably a hand-soldered part. It cleaned up fairly well, and left no indication of damaged traces behind.

On the topside of the board, nothing looked suspicious, although this whole assembly is very close to the RP5C15 time-of-day chip that gets fingered for a large number of soft-power-related failures:

Trace You There

One thing that I noticed is that there was a lot of solder-resist damage on a thick trace running near the battery. When battery corrosion gets really bad, it damages the connection between the copper and the green solder mask, lifting it.

In other words, it rusts like a car does - from the inside, so as soon as you notice a paint bubble, it’s often too late for the metal.

I started probing around here to try and figure out where this thick trace that passed under the original GB50H-3 battery goes. Eventually, I started scraping off the damaged solder mask with an old Olfa blade, until some bare copper was revealed. I checked with a multimeter to see if it was working at all. Everything was electrically connected here to its destination, so I did some more scrubbing, tinned it, and made a note to cover this in UV solder mask later. This isn’t where the fault is, but it sure looks dramatic.

There are, however, a lot of vias in this general area that run between the major backbone ribbon connector (I call it the “Big Ribbon,” for lack of an official service manual term) and IC13, a 100-pin Sharp proprietary QFP in the middle of the I/O-board called the “IOSC.” From what I can tell of looking at a similar chip on the official XVI schematics (the ACE ones are unavailable,) this part seems to jam together a lot of interface duties for things like the floppy drives and SASI hard drive. Important, in other words.

I wanted to make sure these traces were all OK before buttoning the machine up again and beginning on the power supply repair, which at this time I had not begun. A handful of those vias buzzed out to the IOSC directly, but a lot of them were so corroded with chalky, gritty grey solder globs inside them that they were no longer conductive. The vias themselves still seemed to be intact, as I could buzz a handful of the pins on the 68-pin “Big Ribbon” connector all the way to pins on the IOSC chip, but not all.

I figured it was possible that I had corroded traces broken away from the vias, but but without being able to check all the vias, I couldn’t test them to be sure. On top of that, the compromised solder plugging those vias could be holding battery electrolyte that would eventually eat the copper in them - and then I’d definitely have to be able to clear them out to run a patch wire bottom-to-top. And that would just be a ton of work nobody wants to do, right? Right???

Dismantling and Cleaning

After looking at the I/O board, I put the machine back together and put it on the shelf for a few months. Without a schematic or a place to put all the guts of the machine while I had it dismantled, fixing the I/O board seemed intimidating.

I moved on to the power supply, and that meant there was a lot of cleaning involved.

One obvious issue is that the power supply is clogged solid with dust. It left big black streaks of grime behind on the plastic, probably because the fan is too choked to function:

Hopefully the dust absorbed some of the capacitor goo that is surely inside this thing.

I noticed some other interesting things during the disassembly, like the floppy ribbon being attached with velcro:

After removing the PSU and floppy drive and external hard drive breakout board, I noticed that the internal speaker is bolted to the inside of the plastics of one of the “twin towers:”

The “pop up” handle in the middle has this cool-looking pogo stick part that also holds the two halves of the case together:

The piston in mine must be gummed up, as I’ve seen videos where it has a smooth easy action with some “easing.” Mine judders from position to position and won’t smoothly retract without lots of force. As you can see, I’m also missing one of the little plastic “feet” that keeps the handle action feeling good on a desktop. Maybe a good excuse to buy a lathe?

Motherboard comes out

You have to remove the front fascia to get at the motherboard, as it has a pretty complicated three-piece RF shield. Here’s an absurd-resolution picture of just how bad my case plastics are:

You also have to remove the expansion card cage. Luckily, it is easy to unscrew because they left these nice reliefs for your screwdriver.

However, the whole cage is on a massive 100-pin 2-row pin header which is very nerve-wracking to undo:

The RF shield was bouncing around the whole time; it’s very thin metal, and seems to have warped with heat and age.

The motherboard has a lot of interesting stuff too, like the Messiah. So that’s where he was hiding all this time. Someone tell the Pope.

Our Messiah hangs out with a video controller chip called, unimaginatively, Vicon:

The 68K and HD63450 DMA controller are hanging out in the extreme corner of the motherboard, which seems like a weird place to put it since generally you want a CPU to be, well, central. For some reason, the 68k is thankfully socketed.

I noticed that these custom chips near the “IMDRAM” have some solder-bridged pins, but based on their position they are probably power pins, and the bridge is deliberately caused by the solder mask.

I also saw these empty ROM sockets, which say they’re for “512K ROM” odd and even. Like in the X68000 PRO, this lets you run an alternative BIOS¹. The original chips are soldered in, and the nearby SW1 jumper no doubt changes which set of chips the select signal goes to.

That sinking feeling

With all the plastics removed, I scrubbed them down in the sink. Tons of grit and grease came pouring off of every single one of them, and so I gave them a quick vacation in the sun to dry before 303ing the plastic. It’s still in not-great condition (lots of chips to the paint and damage on the edges) but at least now it’s not as gross to touch.

I counted over 100 screws on disassembly, which rapidly overwhelmed my ability to keep them organized. A very complicated case!

While I was waiting for everything to dry, I replaced the missing and torn feet on the metal bottom of the case with 3M SJ-5012 half-inch rubber pads in black. They are pretty much identical to the original feet, right down to the taper, which makes me wonder if it might actually be the original part.

Since the light grey plastic had so many dings and scratches in it, I also gave it a quick treatment with Novus plastic polish. The jury is still out on whether it looks a lot better, but it definitely has reduced some of the more obvious scratches and made the sides mostly shiny again.

To fully restore the aesthetics would require some fresh paint, as the paint is very badly damaged in parts and down to bare plastic in several places. Then I’d need new stickers and labels! If I can put this thing back together and have it running at the end of all this, it’s good enough for me.

Power, Supplied

At this point, I put everything else aside to focus on building a “new” power supply for the X68000. Feel free to take a departure and read about how that went.

In brief, a PicoPSU adapter board was assembled with an onboard AC/DC converter inside the existing power supply case, so that the computer retained its original feel and layout. It worked well!

Hold My Battery

Another side quest was embarked upon at this point.

As I mentioned before, the original battery for the X68000 is a rechargeable NiCad.

Coin cell batteries are much less likely to leak than a NiCad barrel battery, although it’s still very possible and has happened to me in the past. With a holder, at least I can remove the battery if the computer goes into storage for a very long time in the future.

Electrically, I was nervous about choosing a 3.0V ML2032 or 3.6V LIR2032 battery for this because the charge methods differ between the original NiCad cell and the lithium-ion chemistry. The last thing I want is to trade NiCad damage on my I/O board for much more reactive lithium corrosion.

After doing some research, the datasheet for the SRAM chip (MB8464A-15L) says that I only need 2.0V to keep it alive, so a non-rechargeable CR2032 with a diode to block the recharge functionality should work very well.

I spun up a quick PCB (very cheap on Osh since it’s tiny) and then put it together. It uses an 0805 Schottky diode to try and minimize the voltage drop, but even a “regular” amount of diode drop is okay because, as I determined before, the SRAM chip only needs 2.0V. This was my first time installing a surface-mount diode, so I had to squint to figure out on which side the cathode line was.

It would have been nice to make this PCB a little bigger, because it turns out to be pretty wobbly all around. The original battery holder has three points of plastic that contact with the motherboard for bracing, but the PCB only has the two electrical contacts.

It will be annoying in the future to put a battery in or take it out of the holder because of all the wobble, but that’s better than leaking. If I get back in here, I’ll probably put a bit of sticky tack in to provide a little bit of support to the PCB.

Pleased that it fit, I didn’t solder it in, because I knew I’d be messing with the board underneath. And here’s why…

Scraping The Bottom

The I/O board still needed to be repaired. I figured I would start by scratching off the contaminated solder mask, and getting the corrosion and battery electrolyte out of the copper traces.

Even though this trace looks very bad, it is still continuous with extremely low resistance. The fibreglass pencil removed a lot of the contaminated solder mask, but it wasn’t good at removing the rest of the solder mask, unlike with the Amiga 2500, where most of the solder mask came right off within a few swipes. I ended up scraping a lot of it off with a dollar-store box-cutter, which was a harrowing experience until I got the feel for it.

After about half an hour of very slow work, I got to see these hard brown spots in the copper. I wasn’t sure if this was contaminated copper that would start oxidizing again, or if it was just fibreglass substrate where the copper had totally worn away. It wasn’t conductive, so I suspected the latter, but I wanted to make sure.

The negative battery-terminal trace on top has been severed entirely by the damage - the eyelet on the top is completely corroded. There are rivets that you can install to fix a torn plated through-hole, but I didn’t have any or the tools to install them (now corrected,) so a quick patch wire from the negative battery terminal to the vias will return the battery to proper function for now.

We’ll worry about that when it comes time to install the aforementioned coin-cell holder. I want to keep a battery in here so that the boot SRAM (where you load drivers, not just clock and configuration - more on this later) will continue to work.

Once I was somewhat satisfied that the big traces wouldn’t turn back into green nightmares, I turned my attention to the IOSC vias.

Plugging away

I worked for a couple of days on and off to try and clean out the chalky, corroded vias on the I/O board so I could test out the traces from the 68-pin “T” connector to the IOSC chip, including buying a pointier tip for my soldering iron to better direct the heat so I could “burn out” the gunk inside.

This was a lot of fiddly work, and very discouraging as at the end of most days I had no concrete improvement to show for my effort. Eventually, though, the vias were cleaned enough that I could get continuity from the vias to the “T” connector, verifying that the traces on the underside of the board (and the vias themselves) were intact. All 17 vias now buzzed out just fine top-to-bottom, which made me feel a lot better.

Unfortunately, things weren’t as good on the other end of the circuit. Only 8 out of the 17 vias were continuous with the IOSC chip. I would have preferred it the other way - it’s much easier to solder to the through-hole “T” connector than it is to the very fine pitch IOSC chip! Before running some patch wires, I wanted to verify that the traces were in fact bad. If there was just a small portion of the traces that I could clean up and fix, then that would be much easier than trying to bodge-wire onto the legs of the QFP.

I suspected the damage on the traces must be very close to the vias, since that was where most of the battery electrolyte and blue-green corrosion was hanging out. Even a very thick copper trace must become thinner when it approaches a via, and it’s well-known in the PCB manufacturing community that T-shaped intersections and 90-degree turns are notorious for trapping acid.

It took me about an hour to trace out where each via went. I took a high resolution picture and used a paint program to draw lines, which took awhile but is a lot less less error-prone than doing it by hand:

All of the pins that had additional vias nearby the IOSC were continuous from that via to the IOSC. Did that sentence make sense? Either way, it meant that the damage was closer to the vias, as I had assumed. Some of the pins, like the one I labelled “13,” were obviously obliterated.

After scraping back a little bit of the solder mask using an Olfa AK-4 knife (I can’t believe I used a box-cutter for so long for this - the Olfa is delightful) my theory was confirmed. Part of the trace is simply missing.

The exposed copper part of that trace buzzes to the IOSC no problem, but it isn’t connected to the via. I was correct in my initial guess that it has severed itself at the via end. So at least the required patches are short… but they’ll be pretty close together, which is a hell all its own.

The Way Back Out

On previous repairs, I’ve patched point-to-point using Kynar wire or cut-off component leads. On this I/O board, however, these traces are thin and close together, so I decided to try another route.

On the suggestion of some friends, I decided to buy some very thin magnet wire from AliExpress to patch these traces - since it was cheap, I ordered both 0.2mm and 0.3mm as my existing 0.5mm seemed too thick, although I ended up waiting so long for shipping on it that I ended up ordering another reel of 38 AWG (0.127mm) from Amazon, which of course immediately caused the AliExpress order to show up the next day.

The moral of the story is that if you’re reading this paragraph and think you might want to repair traces in the future, go order some magnet wire from AliExpress right now and it might show up by the time you get your next broken PCB.

Since it was my first time using magnet wire to patch traces, I picked up a syringe of paste flux (MG #8341). The idea I had was that the paste would add some height, so that the wire would be completely immersed when it was being soldered on and it wouldn’t matter as much about being able to hold the wire firmly and flatly to the board while soldering it. This way, the flux would provides surface tension that would help the melting solder to pull the wire flat onto the board.

This lengthy video by Branchus Creations has a fantastic zoomed-in view of the wire adhering, which gave me the confidence that I was on the right path.

When I actually went to do the patches, I first tried with liquid flux. It was really difficult to get a good adhesion. It only occured to me here that in addition to the height, the paste flux obviously contains way more flux per drop, because it doesn’t spread out and try to run away from the part that I’m working on. I’m a convert - I only wish it were easier to store the syringe.

To do the patch wiring, I cut off a ~2cm length of magnet wire and then stabbed it through each of the vias. Then, I filled the vias with solder, so that it would be conductive with the wire and also hold it in place. With the wire held tightly, I could bend it on the top side to meet the exposed copper of the trace and solder it down.

This makes it sound much easier than it actually was, because the wire is annoying to remove the coating from in practice (tin both the trace and the wire first, if you can) and everything is super small and hard to see without magnification. Before I figured out what to look for, I had a lot of trouble predicting how long I would have to keep the iron on to get rid of the coating so it would become “continuous.”

It gets worse if any contamination is kicked up from the rest of the board, because that obscures the traces even further and forces you to take a break to clean. It took me about forty minutes to do the first trace, and then the subsequent ones were a little faster. Occasionally I would bridge one trace to the one I had just done by using a bit too much solder, which necessitated some re-work. At one point I actually dropped the entire wire back out of the via for the “#1” trace, and had to redo the entire job.

Here is a photo after I had repaired six traces. It looks ugly zoomed in, but it’s difficult to notice this detail with human eyes. I reflowed the joints after this and tried to make it look okay with a magnifying visor, but I found it really hard to produce a good clean smooth joint.

I’ve gotten a little bit better at trace repair in the years since I did this job, but not a whole lot better.

One thing that really helped was to glob up the soldering iron tip with solder and then run it along the wire and pad while holding it in place with tweezers, like when I’m drag-soldering SMD chips. Unfortunately, I only figured this out near the end.

I started on the vias at the bottom of the photo, and you can tell that I made the wires and their contacts too short. Part of the secret to making this look good and have a long-term reliable connection is to have a large “surface area” where the trace joins to the wire.

I was sure to scrape off and patch past the black corrosion that you can see on the furthest-top trace. Although they were still continuous, you could see some gunk getting exposed as the mask was scraped off:

I think a cool way to repair this (which might potentially be profitable as this damage is common on early X68000s) would be to make a flex-PCB that would pin into the vias and then let you tin some exposed traces onto the original traces. Sort of like an iron-on transfer.

In any event, all of this is going under solder mask for protection, so as long as it’s got a good connection, I’m reasonably pleased.

The backside produced a lot of sticky black goo which I think was a mixture of flux, leftover battery electrolyte, corrosion from the inside of the via, and the enamel coating of the magnet wire. Gross! But it wiped off with some effort. I clipped all these wires later, of course, but they were useful for testing and to keep from pulling the wire out of the via while I was soldering the other end.

At last, all of the obvious I/O board patching was done. Each wire buzzed out between the T-connector and a pin on the IOSC, the pins seemed to go in vaguely ascending order, and there were no shorts between pins. I don’t want to add up how long this took.

For the first test, I didn’t seal this up with solder mask or install the battery holder. If it turns out I had missed a spot, it would really stink to have to remove all of that stuff in order to get back to these traces.

Now to fire up the computer! Let’s go!

Reassembly

Reassembling this thing was intimidating. As I mentioned earlier, it had been a few months since I took the computer apart, and it has dozens of screws.

I did what I always do when confronting something that makes me nervous, and I made a list.

Top of that list was to get the piston action to be less “juddery.” Although I didn’t plan on often using the carrying handle, what’s the point in tearing the machine all the way down to this point without touching it up while it’s easy? I dripped a bit of 3-in-1 oil into it after picking out a couple chunks of dust and hair from the track that the spring cup glides in. The same slow action continued but now it was much smoother.

One big mistake that I made, because of my terrible screw organization when ripping the computer apart, was taking the three fine-thread M2 screws meant for mounting the motherboard to the threaded inserts in the case, and mixing them up with the two coarse-thread M2 screws meant for mounting the speaker to the case plastic. I ended up stripping out both of the speaker holes in the case plastic - they must be the right screws, they’re in the bag with the speaker! Yeah, I put the speaker on a corner of my desk before bagging it up and that’s where I also placed the motherboard mounting screws.

To repair the now hogged-out screw holes, I ended up filling the holes with super glue. After some more experimentation, I determined that these were “thread-forming screws” and would need a pilot hole drilled in order to work effectively. The smallest drill bit I had on hand was 1/16”, which at ~1.58mm was pretty close to 2mm.

Once the pilot hole was drilled into the set super glue, I was able to thread in a screw. I wouldn’t trust this to hold any serious torque or weight, but it seemed to be enough for the speaker. We’ll see how this holds up - a better repair method would be to use some kind of plastic-compatible epoxy because super glue is quite brittle.

When reinstalling the floppy drive, I found out that my newly-spliced floppy power cable was now actually too long compared to before. This was sort of a nice problem to have; I ended up airplane-looping it behind the SASI breakout board to take up some slack. There’s quite the mess of wires in this computer in general:

I noticed that due to the rust on the metal parts of the case, or possibly a previous owner, or more likely incautious removal on my part, some of the brass inserts were cross-threaded and difficult to get the fine-threaded screws in properly.

I kept having to take screws out and put them back in, because later layers reused the same screw holes. There are some screws (namely the SASI breakout screw at the back) that hold in four or more major components. No wonder I had such an annoying time taking this thing apart! Finally I triumphed (of a sort - I was short several coarse-thread plastic screws and long several small fine-thread machine screws) and was able to stand the machine back up as one discrete unit on my desk once again.

At which point it creaked like an old house for about 20 minutes, as all the plastics had expanded during their month of freedom on my workshop floor, and now were a little grumpy at being back with their partners of 30-plus years. Sure looks nice with the freshly polished case front, though!

Testing

I’m not going to lie: I was intimidated. Few things would be worse than spending all this time, effort, and money, and then watching this machine smoke one of its bespoke components. It wasn’t like it was thoroughly tested in Japan, either: it could very well have been dead before it got to me and my repair of the IOSC traces wasn’t the only problem.

In the initial test, since I didn’t have any high-density 5.25” diskettes, I would be looking for the following things:

Red light turns on when the machine is plugged in and switched on, but not powered on;
Green light turns on when the soft power toggle button on the front is pushed;
Video is generated;
…and a legible “insert disk” message/logo is shown!

I did have a boxed retail copy of Klax that I got from the Suruga-ya in Shibuya, but I didn’t really know if it actually worked, nor did I know if my untested floppy drive would just rip the magnetic coating off the disc with a misaligned head. Best not to test with irreplaceable disks.

After cleaning the desk off so there was a place for it to sit, it was Halloween of all days. Perfect for some spooky behaviour!

I connected it to power and turned the hard power switch on, and saw that the red power light was on.

I pushed the power button on the front of the computer. The LED changed to green, and the computer leapt to life!

…And showed a screen of garbage amongst a message in Japanese:

Garbage in… 31kHz? That can’t be right.

The message basically translates to “an error has occurred, please reset.” I half-expected to see this from corrupt (battery removed) SRAM. Pushing the reset button on the top of the case, I got the message again, except now without the corrupted tiles. Hmm.

I didn’t think the video being off-centre was that relevant; this monitor can interpret seemingly everything but sometimes it shoves the video into an inappropriate corner like it’s an Amiga or something. A little horizontal and vertical position adjustment always makes things look better.

I pushed the button on the front to turn the computer off so I could plug in a keyboard, and it didn’t turn off. The power LED turned completely off, rather than blinking, and the screen stayed bright and happy instead of slowly fading out to blackness like a normal soft-power-off situation should. Uh-oh.

After a bit more nervous poking of the reset button, I saw that sometimes the reset made the screen fade out. I wasn’t sure if this was intentional behaviour, but it didn’t always come back from that. Something’s really wrong.

I shut the machine off hard, installed the keyboard, and held OPT1 on startup to reset the SRAM. Nothing changed - the LED in the “Roman characters” key would flicker for a split second on reset but this wasn’t the problem. I tinkered with the machine a bit, removing and installing parts that were easy to get to (e.g. the RAM card and floppy cables) but nothing changed. Even letting it sit for 15 minutes under power to try and reform any marginal electrolytic caps didn’t help.

At this point, I decided to check if the floppy drives would work at least, and stuck a brand-new double-density disk into the primary (#0) drive as sacrifice. The drive happily slurped it up (nice) and the LEDs on the front turned on to signal a disk had been inserted (awesome) but the drives refused to eject it (oh no.) All I’d get when I pushed the eject button was a blinking LED, some motor quivering inside, and no disk ejecting. Uh-oh. My guess is that since the eject process was doing something, it probably wasn’t software or the IO controller blocking it, but some kind of mechanical problem inside the drive - old grease or whatever. It can wait.

So, at least four new problems:

Soft shut down doesn’t work;
Whatever that error message is;
Whatever that video garbage is
Floppy drive #0 won’t eject;

Looking on the bright side, at least there’s a visible raster and it’s loading Japanese characters from the ROM! A lot of stuff has to go right to get this far.

It was probably time for some actual troubleshooting. Because I had just been monkeying in that area, I immediately thought I must have missed a broken trace or some other damage on the I/O board, probably also involving battery damage on the circuits between the “T” connector and the IOSC chip. At least it’s really easy to remove the I/O board, as opposed to almost any other component of this machine.

Fruitless fixing

I’ll save you the several weeks of frustration that followed. I tried a little bit of everything, with no real change in behaviour. One thing to watch out for are the aforementioned saggy RF shields: at one point I created a +5V to GND short using the motherboard’s RF shield as a jumper.

I did a bit more rework on the I/O board and followed some Japanese trace maps I was able to find (thank you Exim; reproduced above) and figured out that the “T” connector seemed continuous with where it was supposed to go. Doing a continuity test on such a high-density connector takes a really long time.

At this point, I was starting to damage traces and pads while reworking things that turned out to be fine, which was extremely discouraging, and I shelved the machine. Thinking on it, I began to suspect the I/O board was compromised in some way I couldn’t tell.

Luckily, another X68000 ACE – a black one, with a nice case – popped up on Yahoo! Auctions. I could just slam the I/O board from that in, and see if it worked! I was able to score it for more money than I paid for the grey ACE, but it was in even worse shape than the thing I had just beat my head against for months.

You see, someone has already tried to repair this one. They’ve done a clumsy shotgun recap, and even soldered in a used barrel battery.

So that’s another project. Just what I needed.

Desperate, I decided that I would depopulate one of the I/O boards, build a reproduction, and swap all the parts across, to rule out any further bad traces and pads and to construct a useful schematic for the ACE. Another good project would be to make a test ROM, which could go in those aforementioned sockets, and do low-level things like check if the TVRAM is okay and if the interrupt table was full of garbage.

However, that’s a BIG PROJECT, and… uh… I didn’t do it. Maybe if I win the lottery, or if the Leaded Solder Patreon replaces my day job.

Inconclusion

Thanks for reading so far! My hope from publishing this article is that someone will come to my rescue and recognize the fault.

Already, from showing off drafts of this project, it seems like blog friend kak-hoofd has a very similar failure (pictured above.) Although testing out the repair is in early days, so far the cause seems to have been a mechanical failure of a via up near the Messiah chip on the motherboard that only popped up intermittently, so I look forward to a lot of frustrating trace checking and via plugging.

Although this machine has defeated me many times over the last couple of years, I think it is still possible to save. As you can see, it’s come a long way just to give me that error message, and it surely can’t be that much farther to save this grey ACE.

If you have a broken ACE, I hope this at least made you feel better about it. If it helped in any way, let me know!

Repair Summary

Fault	Remedy	Caveats
Power supply corroded.	Replace power supply.
Some idiot stripped the hole for the speaker screws.	“Repair” it with super glue.
Extensive battery corrosion has broken traces.	Conduct trace fixes and via stitching on I/O board.
Startup error displayed with corrupt text tiles.	No fix at this time.

I’ve been running EXBIOS on my X68000 PRO for quite some time, with the intent of adding a hard drive, but I haven’t actually finished the power-supply wiring to support that hard drive yet. Be patient! ↩

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

Leaded Solder

Cleaning up after a Camel

VDP Delay

Bad characters hanging around

Words that interact with hardware

Why not the PSG?

Fundamental operations

Volume word

Data word

Noise word

Tone word

Flash cartridge

Conclusion

A Typed Forth

The story thus far

Are you a scanner?

Why does pressing “1” reset the computer?

What’s wrong with the backspace?

Can’t type worth Shift

Conclusion

More like SC-Forth-thousand, am I right?

The Soggy?

RetroChallenge

Why Forth?

Why Forth on the SG-1000/SC-3000?

Port a Forth

Getting it to Assemble

Building It

EMIT

Implementing Scrolling

Backspace and Newline

It’s not ok

What’s NEXT?

Dogfighting the Sharp X68000 ACE

Taking It Apart

Trace You There

Dismantling and Cleaning

Motherboard comes out

That sinking feeling

Power, Supplied

Hold My Battery

Scraping The Bottom

Plugging away

The Way Back Out

Reassembly

Testing

Fruitless fixing

Inconclusion

Repair Summary

Embedding a bitmap font in your HyperCard stack

An intriguing font

The Resource System

Be Resourceful

Hello Jeff-Nichols

Using This New Font

Why do this?

Conclusion

Bridge Companion Becomes Block Companion

Let’s All Become Development-Environmentally Conscious

The Reversible Engineer

First Tile!

Tiling My Shower

A Game Has Rules

A Weird Problem Emerges

Attract Mode

It Goes Back Home

What about Canada?

What’s Next?

Composite Companion

New Scope, Who Dis?

Building Test Software

Did You Have Fun At The Mixer?

Starting Over

Composite Conclusion

Repair Summary

Companion & Companion’s Cartridge Complication

Oops, eBay

Diagnosing the Companion

Video, Kid

Winning At The Slots

It’s not `ok`