Went and bought something silly for my X68030, a old Nereid card which extends it with USB and Ethernet.
Setting it up was surprisingly easy. Loaded the drivers in the included floppy and followed these instructions, and everything just kindof worked for Ethernet right away.
Have it hooked up to my router and could jump on IRC with the CLAT client.
Pretty happy with this, and sortof want to keep using this as a IRC chat device for the fun of it. Will have to swap out the fan for something more quite though since the X68030 still runs on original power supply with a fan that’s a bit too loud for me to want to have it on all the time.
Messed around a bit with the available web browsers, but honestly… they’re not really something that’s particularily usable. IRC is neat though, it’s been a while since I’ve been using that.
Still need to mess around with the FTP software for X68000, since that might actually be kindof useful. Currently I’m transmitting files to it by modifying the HDD image loaded through BlueSCSI. I’m not sure using FTP is much better, but it’s at least a cool option!
Was expecting it to be non-functional and broken, and it was. It was also impressively filthy. Check this out:
Before
Outsides and insides were… very dirty. There were remnants of an old overclock mod which was partly disconnected.
Floppy drives were not present. Neither was the power supply.
What was however present was this sick as fuck homemade RAM card. Look at this thing. Home etched!
Cleanup and recap
Before I could really do anything with this thing, I had to clean out all the dirt, so it was bath time.
Things cleaned up nicely!
As mentioned, there were some partial overclock mods that had to be removed. In practice this meant rewiring a lifted pin from the CPU clock, and bridging a cut trace which was related to the second oscillator for the IO board.
I tried booting things at this point, but things were very dead, so I just skipped right ahead to doing the recap and battery swap here as well to exclude simple issues.
Booting and PSU
With the regular IPL, the system would not boot at this point due to the missing floppies, but with a custom IPL installed, the system would now boot fine from SASI. Very nice!
For the missing PSU, I scavenged some old replacement boards I had around, cut them a bit smaller and made a plastic bracked for mounting a Pico-ATX in the case. Turned out OK.
I decided to not have an internal DC converter, and instead running the device off 12V DC, so I 3d printed a small holder for the connector which turned out well.
Extras
Since the device only came with 1MB RAM, I added an internal 1MB expansion as well as a 8MB Polykubos RAM+Midi card.
For Booting the system, I use a Bluescsi V2 Centronics version. The X68000 Pro does not provide termination power over the SASI port, so I went with a slightly hacky fix of just adding a 5V connector through a hole in the back of the case.
Case cleanup
Stickers were removed by a combination of violence, IPA and scrubbing with a soft brush. Case was washed off thoroughly. IO covers were 3d printed. There’s a few deep scratches but other than that, things look pretty good now!
Final thoughts
There were no real setbacks in this restoration, unlike the Compact I worked on previously.
While there were still a lot of steps to perform to get everything up and running, it was mostly smooth sailing, and I could chip away at it on evenings when I had some spare time.
The lack of floppy drives isn’t too much of an issue to me, since I sortof don’t want to deal with 5.25″ floppies unless I really have to, and the custom IPL allows me to bypass the need for a Master Disk since I can just run SWITCH.X from SASI.
10MHz with 10MB and Midi should be sufficient, but I could look into doing a 16Mhz overclock at this at some point.
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.
This is just a small follow-up to the earlier posts, but I noticed that my Henkan Banchou was running real slow on my X68030 for some reason, so I tried swapping it for a old BlueSCSI V1 and that works much better.
I assume V2 would be the same, but this was all I had at home.
Some people seem to swear by Henkan Banchou, but it just wasn’t playing nice for me. As a fun thing, I’m trying out one of those Micro-SD card extenders now too, and routed that out the back of the unit. Makes it easy to swap cards, but realistically I don’t think I’ll do that much.
I’ll keep it like this for a bit and will then just use a regular Micro-SD card.
Later models instead use a LS04 which outputs clean TTL sync, which Extrons will happily eat.
Since these are mostly pin compatible, I assume it would be fine to remove the pull-ups resistors (R26, R27) and swap in a LS04 (IC3) into my CZ-600C, so I tried it out. The only 04 IC I had at home was a SN74HC04N, but I assumed it couldn’t really hurt to use that, and it did indeed work great, and my X68000 now syncs with my Extron perfectly.
On my model, the inverters of the IC are connected to a pin of the stereoscopic 3D port, and to the “Hig Res” pin on the LED board connector. The LED works fine after the swap, and I assume the 3D port should as well, although I don’t see myself using that.
I recently put together a Midiori MIDI card for my X68000, and the process was a little bit complicated, so I thought I’d write down a quick summary if someone else is interested in doing so as well.
Making the bare PCB
This one was straight forward, nothing special here.
Open midori.pro in latest Kicad, go the the board file and Plot the Gerbers (and drill files). I got some warnings about it updating files due to them being created in an older version, but looks like that didn’t matter much.
Zip up and send to board fab of your choice. I used JLCPCB.
I decided to be cheap and not use gold fingers or tapered edges.
Not much to say here. The FPGA has tiny pitch, so be careful and use magnification. At least on the revision (2.2 2020) that I soldered, U2 is oriented the other direction than other IC’s, so check for that.
Since I wanted to be able to have a SCSI to Flash adapter connected internally to my device, I had to make some adjustments to the hardware.
Hardware
I wanted to hook up an internal SCSI HDD to my X68030, and decided that instead of trying to manufacture a cable for this, I’d just make a quick replacement SCSI IO board with the proper connector. This board has the same configuration of resistors and capacitors as the original board, but lacks the external connector. It has headers for setting the SCSI ID, but it’s fine to leave this unpopulated and just use SCSI ID=0 for the X68030.
SCSI Device setup
Setup is quite minimal.
There shouldn’t really be any settings needed to be changed in SWITCH.X. Leaving device boot as STD works, and either 0 or 7 as SCSI_ID works fine.
I had a spare Henkan Banchou 変換番長 Pro from a previous project that I decided to use. I designed and 3D printed a bracket (STL is at end of this post) for this to fit in the top right of the X68030, since that’s where the internal HDD is in CZ-510C.
I loaded this with the SxSI-SCSI HDD Image v3.01 from NFG Games forum, and things pretty much just worked right away, once I connected the cable.
Power is supplied using the flat cable (as long as the connected device doesn’t require more than 1A).
I finally got SCSI working on my X68030 CZ-500C, so thought I’d do a writeup on what I learned. It will be in two parts, where the first one covers the default CZ-500C SCSI support, and the second part covers a new adapter I made for using internal SCSI devices.
CZ-500C SCSI Internals
X68030 has proper SCSI support, not just SASI as some of the earlier X68000 models. CZ-500C does however lack cabling for internal SCSI HDD (which CZ-510C has). The internal connector used from the main board to the SCSI IO board is a non-standard 40-pin flat cable. The schematic for CZ-500C including the SCSI board can be found here.
The IO board itself is quite simple. Other than the connectors and ID switch, it just has a terminating 33oΩ/220Ω resistor network, a bunch of capacitors and a 1A fuse for the external power delivery. It is mounted on top of another IO board for the external floppy, and easy to remove with two screws.
If the SCSI board is not connected to the bottom PCB of the X68030, the system will not start.
External connectors
The external SCSI connector is a “Micro Centronics” connector, which is hard to find proper cabling for. It seems like the Japanese term for these are アンフェノールハーフ50 (Amphenol half 50) or アンフェノールハーフピッチ50 (Amphenol half pitch 50).
When looking for adapters to full-size Centronics, you can search for that in combination with アンフェノールフル 50 (Amphenol full 50), and look for a cable with a male Micro connector that goes to a female full size connector. This can then be hooked up to a Centronics Bluescsi device. Example from an Mercari auction:
There is a SCSI ID switch on the back of the unit. This doesn’t seem to be related to the external device, but rather the SCSI ID that the X68030 uses. Weirdly there’s also an option for this in SWITCH.X so I’m not really sure which option has priority. The compact version of X68030 does not have this switch, nor does other X68000 models as far as I can tell.
