X68000 V4 Image issues on X68000 Pro with ZuluSCSI?

Started by Tristan's Game Room, January 15, 2023, 07:06:11 AM

Previous topic - Next topic

Tristan's Game Room

I'm slowly, but surely getting around to getting the X68000 to run games. With each issue I can get fixed, it seems 10 more problems appear in it's place. This issue being no different.

After some issues with the ZuluSCSI itself, I finally get around to using my ZuluSCSI on my X68000 Pro. I put the V4 Image onto the SD Card, I have to rename the file to "HD30_512.hda", for the ZuluSCSI to read the image. Since this is what someone on Reddit had to do to get the ZuluSCSI to work on their X68000. I install the SXSI Drivers, make sure everything looks good in switch.x, reboot. The bootloader detects the ZuluSCSI & the V4 image. It goes to boot & it gives me an address error. (SR=$2000:PC=$0002D16). Later on, I get it to give me a second error. This one being a bus error. (SR=$0000:PC=$00036240). Eventually at some point, the bootloader would tell me to check connection. I've tried different HDD images to no avail.

If I had to guess, this has to be an SRAM issue. As I've yet to replace the original battery. So I have to let the system sit unplugged for 24 - 48 hours before I have to install the SXSI settings again. I did order a few coin cell battery holders from Console5, so I will be replacing that old battery sometime in coming days. In the meantime, I would like to ask for help on this issue.

Address error.jpg
Bus Error 1.jpg


Hey, not even sure if the ZuluSCSI does it, but have you tried creating a 20MB SASI image and tried booting off it, just to make sure everything works as if it was 1989?

If it does, then you do the SxSI + SCSI thing?

Let me know how it goes, cheers.

PS: I have a Pro (or two...) and I'm interested in the ZuluSCSI as well.

Tristan's Game Room

I tried two times creating a partition with the ZuluSCSI. Unfortunately, both times didn't work. First time, my mistake was using all 32GB of the SD Card... which corrupted the SD Card. The second time, I tried 20MB like you said. To no one's surprise, it didn't work. I just got my BlueSCSI today, so I'm willing to try that.


Did you change the battery yet and check the area for any damage?


Hello, I've just been through similar trials with ZuluSCSI (RP2040 version) and have got it working on my ACE using default config, latest ZuluSCSI 1.2.0 firmware from December '22, 4GB SDHC card formatted with FAT32, and the V4 games image using the same filename as you. I'm giving the ZuluSCSI board additional power using the floppy power connector.

Make sure the termination DIP switch is enabled on the ZuluSCSI, and also make sure your cables are good. I was connecting mine to the external centronics connector and it wasn't working, eventually I realised the cable I bought was wired upside-down (I had to file the key notch off the 50pin IDC connector so I could insert it upside down, then it was all good!)

Just wanted to confirm it does work on the SASI machines.


I'm using Zuluscsi V1.1 with FW 1.2.0 on a ACEHD and was getting Address & Bus errors but it was related to my 1mb ram expansion not making good contact with the motherboard. Gave both connectors a good clean, reseated and it's rock solid. I'm running V4 image with SP1 & SP2.

I would highly suggest you check your RAM also because of the address errors.


Another note on ZuluSCSI RP2040 with SASI machines - if you're using firmware v1.2.0 you'll probably find you cannot write anything to the HDD image. Any attempt to write yields a white box saying "write error". If you enable the ZuluSCSI debug log and try again you'll find a lot of parity check fails and CHECK_CONDITION "sense 0x00004700" errors on writes when you check the log file.

This happens because the ZuluSCSI expects to see a parity signal that SASI x68ks don't produce. They don't have a pin for it on their 20-pin HDD connectors, and without this signal the ZuluSCSI will constantly complain about parity errors. It'll ignore those errors on reads, but will fail on writes.

It can be fixed, though, if you're prepared to make a small change to the ZuluSCSI firmware and recompile it. All you need to do is change the line in scsi_accel_rp2040.cpp that reads:

if (SCSI_DMA_PIO->irq & 1)

if (0)
(it's line 687 at time of writing) or comment out that whole condition. This disables the parity checking and allows writes to occur.

I've mentioned this to the ZuluSCSI devs so maybe we'll get a config option to turn off parity checking in a future release. If you found this post years later, you might wanna check if they already introduced a config option before modifying the code.