A few months ago I found an auction for a broken X68000 Compact, which was listed at less than 40,000 yen which is significantly cheaper than what a working Compact would typically go for now, so I took a gamble and bought it to repair.

Getting it mostly functioning took a few weeks, and more work than I expected, so I’m doing a writeup of that here. Since I don’t have much experience repairing these, I took some detours along the way that could have been avoided.

How it arrived, and initial debugging

I was quite pleased when it showed up, because the external case looks nice! There’s only minor scratches. The motherboard had been recapped and the SRAM battery replaced with a coin-cell. The motherboard looked pretty clean, but had a 40Mhz oscillator replaced with a socketed 48Mhz oscillator, which I guess was some sort of overclock.

I replaced the PSU with an ATX-adapter to eliminate that as an issue (since x68000 power supplies are known to be problematic) and restored the motherboard by placing a 40Mhz oscillator like the one that comes stock.

The machine appeared to power up, but soft power on/off did not work, and nothing was being output to the display. Probing around the video out circuitry showed that no sync signal was being generated, and that it was not just a faulty buffer. Things looked pretty dead.

Checking BIOS ROM

My initial guess was that it might be that the system failed to boot due to problems with the boot ROM, and that’s fairly easy to check. I desoldered the ROM with the BIOS and verified it against existing dumps in MAME.

Everything looked good, so this didn’t seem to be related. The memory area where the IPL (BIOS) lives matched the existing dump perfectly.

Probing around CPU and RAM with Logic Analyzer

I then took out the oscilloscope and started probing the CPU pins to see if anything looked unusual. It became clear that HALT was being asserted after only about 1ms, which after some digging into the datasheet either indicates that the CPU is trying to execute an illegal instruction, or that some other device on the motherboard asserts the HALT pin.

When connecting a Logic Analyzer (Saleae Logic Pro 16) to the CPU address bus, I could see it failing after a read of FF0636 where it would start failing. Decompiling the BIOS in Ghidra shows that this is a RTS instruction, which means it tries to get the return address from the stack in RAM which supposedly fails. When probing the RAM, I could see that only two of the four RAM chips were getting CS pulses, indicating that something was broken there. The lower byte was being read but not the higher one.

Since this logic analyzer only has 16 channels, I could not fit the entire Address bus when looking at things, so I had to do multiple sweeps to both check the high range being accessed, and then the more exact position. Since the failure was reliable, this was fairly doable, but if I had 32 channels things would be a lot easier.

To illustrate this further, the first image below shows that the Address has the higher bits set to 0xFF0, and the second image shows 0x636 (and 0x638) for the lower bits.

I do recommend this logic analyzer in general since the software is really great, but for these particular usecases with large address buses, I would probably have preferred something with more signals.

(Detour) Forcing 16-bit reads/writes

Since X68000 is a 16-bit machine, I naively thought that I could just tie the CS signals of all four RAM together (lifting the CS pins of the higher 8 bits), which should allow the code to read the return address from the stack correctly…

… and this worked! Kindof. Instead of halting after 1ms, it would now halt after about 22ms instead.

Connecting the logic analyzer again shows that it now crashed at FF4E7A which is the first time a move.b instruction is executed to read from an uneven RAM address, doing a 8bit read instead of 16. This one asserts UDS but not LDS, meaning that my forced 16-bit reads would not work since they assumed LDS was set.

I did try to work around this by also doing 16-bit reads for these, but then realized that 8-bit writes would now also write the byte that should not be written, so this was a bit of a waste of time.

Actually figuring out the RAM issue

Since no schematics for this exact model exists, I had to do some guessing based on other X68000 schematics, but managed to locate how the LDS/UDS signals are tied to assert the CS on RAM (through the ASA Custom IC).

LDS and UDS go to a buffer at IC84 which connects to the ASA. The buffer itself seems to work fine, but the ASA was not getting a signal for one of the bytes, which seemed to indicate trace damage. From looking at the schematics for non-compact XVI, I patched this up and now the system would boot! Two traces were apparently busted.

Ignore the flux that hasn’t been cleaned up below. It’s fine now 😉

I could now run memtest from SCSI HDD and verify that the system looked OK!

Stuck again when booting games

Floppy drives seem dead, but I could boot a SCSI HDD image now, but when trying to start games, I would get stuck when loading the sound driver.

When looking at this in a logic analyzer, I could see that the CPU was not in halt, but repeatedly trying to read from E90003, which is the address space of the FM audio. Looking around the relevant code in an emulator, this seems to be a loop which repeatedly reads from there until a non-negative value is returned.

042608 tst.b $E90003.l
04260E bmi $42608

… so something else is busted

Fixing the FM audio

I connected the logic analyzer to the FM chip and noticed that despite CS being asserted, RD was stuck high (WR would trigger along with CS though).

This seemed to be fed through a 47LS486 which is a real weird chip without much info… except from in the x68030 compact data sheet where a description exists. In practice, it will just act as an inverter for WR. The relevant output seemed busted though, so I solved that by slapping a LS00 NAND gate on top of the buffer for the relevant signals (while lifting the pin from the 47LS486)…

… and this worked! Games now boot and runs flawlessly!

Replacing the PSU internals

X68000 power supplies are usually problematic, and I don’t want to deal with stepping down 230V to 100V if I don’t have to, so I wanted to do a PicoPSU ATX conversion and drive the Compact from a 12V DC adapter.

There’s many ways to do it, but I had spare PCBs of the PicoPSU V3. These don’t really fit in the Compact PSU case, but some violence later and things were in place. The parts that were broken off are related to soft power only, and don’t carry any real current.

Then there was just the puzzling together of parts…

Everything works!… kindof

Now the Compact boots games and plays them fine, but there’s still some lingering issues. 16Mhz mode doesn’t work, and neither does the floppy drives. In practice I don’t think I really want to deal with floppies when I can SCSI boot so that’s pretty much fine. Having 16Mhz mode work would be nice though. When enabling it, the 16Mhz LED handling works correctly and the CPU gets the right clock, but still it wont boot. For now I’m ok with only running on the “default” X68000 speed though, but maybe I’ll go back to this later.

I’m gonna call this one a win 🙂