nfg.forums

+1 for using Exbios as well for the built in SxSI support - it also fixes the ram limits and allows for a full 12mb installed on these older machines.

and I believe they both auto detect the ram installed so you don't even need to use Switch.x

As well as showing you useful information about what is attached like a PC BIOS would display at boot.

There's no exbios for old x68k, and i don't think anyone is working on it, but i like the concept, even if i use SRAM config since years, with no issue, as Sharp engineers planned 40 years ago.
Yes, i see from dos only 10mb ram of my 12, but what's the difference?

Quote from: aotta on January 05, 2026, 06:18:35 AMThere's no exbios for old x68k

IPL 1.6 supports all models.However I don't own anything older than an expert to test its driver on.

Quote from: LowDefAl on January 05, 2026, 08:29:22 AM

Quote from: aotta on January 05, 2026, 06:18:35 AMThere's no exbios for old x68k

IPL 1.6 supports all models.However I don't own anything older than an expert to test its driver on.

The link you posted return an error 404

Quote from: LowDefAl on January 05, 2026, 08:29:22 AMIPL 1.6 supports all models.However I don't own anything older than an expert to test its driver on.

I use IPL 1.6 in my ACE HD and I still have to install the SxSI drivers in SRAM to boot from HD

Quote from: X-Col on January 06, 2026, 01:43:08 AM

Quote from: LowDefAl on January 05, 2026, 08:29:22 AMIPL 1.6 supports all models.However I don't own anything older than an expert to test its driver on.

I use IPL 1.6 in my ACE HD and I still have to install the SxSI drivers in SRAM to boot from HD

Thank you @X-Col for confirming, so i think i'll pass in burning new roms with IPç 1.6 on my X68Ks...

I did burn some IPL roms for my Expert 2 when I had the issue with writing to the SRAM (it did not help and I replaced the chips in the end).

I think there is a Github or something explaining a bit about building the IPL roms with options, but I just did a basic thing and didn't try to add a SxSI driver etc.

From memory the X68000 ROM has quite a bit of diagnostic serial stuff in it, so could remove that and insert the SxSI driver in the space.

What we really need is the holy grail of someone who can communicate in English/Japanese and knows the X68000+code/programming.

My wife's cousin is Japanese and teaches English, but she doesn't have an interest in retro computers, apart from occasionally buying some hardware for an old geek or 'Otaku' as she called me

There was an old thread on this very subject

https://nfggames.com/forum2/index.php?topic=5503.msg37656#msg37656

Alas nothing came of it

I messed with it for a while. The SxSI driver needs a lot done to get it to be happy running from ROM IIRC. More or less half of the ROM is the kernel debugger and ROM Human so there's a good bit of space in there.

The other thing I've considered is making new "SCSI" cards that just use an microsd plugged into it but there'd need to be some other value added to make it worthwhile for non-PRO users. Like it'd need expansion RAM and/or MIDI or something so it doesn't eat up a valuable slot just for that. The other catch is that I'd need to write a SCSI ROM to go with it since the OS expects such a thing to exist and have actual code in it for interacting with the new hardware. Basically the driver is in the SCSI I/O slot cards ROM and oh lord am I lazy.

New year, I have time. I hate to make commitments since I'll probably never do it but I personally like some variation of option B here.

I have long wondered why no one has made an SCSI-SD expansion slot card before as expansion slot midi, memory and midi+memory cards have already been made by others. Unfortunately most of those projects are now dead, with the original creators no longer selling their creations.

If those projects had been made open source after being abandoned then at least two third of the ultimate expansion slot card would already be ready to reuse. I imagine the SCSI one is the hardest project to undertake of the three, which is why no one has attempted it.

I have an original SCSI expansion card that came bundled with one of my units. I tried briefly to connect BlueSCSI to it and see whether a SASI machine would just boot off of it without anything in SRAM, but no dice. I guess I am missing something. The BlueSCSI LED's did lit up, so I think it has TERM power at least, unlike the SASI connector on the machine itself, but I guess there must be more to getting it to work. I believe I managed to boot an external SCSI MO drive from it years back, but I don't remember how I did it.

In any regard, I would ideally want a midi card in my machine as well, and I believe I also have an FPU and memory expansion card well, which means I dont have room for all three in one machine, and I'll have to prioritise, so a combo card sure would be convenient in that regard.

Anyhow, I wonder if some drivers could just be "borrowed" from that official SCSI card, it must have the code you describe somewhere in ROM. I know people are puzzlingly super nervous about stealing 40 year old abandoned code for some reason, personally, I would just nick it. Chances of anyone from Sharp giving one trouble for it is basically zero. It's tinfoil hat territory to worry about it in my opinion.

Of course I don't know anything about the process of making an external SCSI card, perhaps it would be easier to start from fresh rather than try to reverse engineer an existing card, and accompanying code.

In any regard, I get the impression that memory expansions are easier to implement than midi expansions, there have certainly been more of one than the other, so it would be more realistic to marry 10MB memory to a potential SCSI-SD project, rather than a midi combo one.

On the other hand, there are already existing Pi based midi module implementations, so in a dream scenario one could have the ultimate expansion card combining SCSI-SD, with 10mb memory and built in midi card/midi module in one. With that much functionality the card could take up all two slots as the only other thing I can imagine people would want is a math co-processor expansion card in their machines.

The only outputs from the card would be the SD card slot, an audio out for midi output, and perhaps a switch to choose between LA or GS midi emulation.

I wonder if a Pi could take care of both SCSI to SD and midi emulation in tandem....

@kamiboy pretty sure Sharp opened up their X68000 stuff for the community, so there should be no issues using their code.

The modified ROM route would certainly be the cheapest way, especially for those of us that already have ram expansions and bluescsi etc devices.

I probably have enough EPROMS to do about 5-10 machines. The bit that takes the longest, is removing the labels from the old chips to erase them!

I ended up purchasing an FPU for my Compact, since they aren't very expensive and I already have the ram expansion board needed to install it.

I am planning on attempting to fix Virgin Angel when it comes in. I can't guarantee I'll fix it, but I will try my best. I won't receive the FPU for another 2-3 weeks however.

Quote from: aotta on December 30, 2025, 05:28:39 AMI replaced in all my 3 X68K (ACE HD, Expert and CZ600) the original battery with a LIR2032, installed with coin cell holder wired far from the M/B.
I'm not afraid of any leakege.
And, Bluscsi2 works perfectly with SxSI.
And, i use my X68KFDPi2W (or my FDX68) instead of floppies, old 40 floppy drives are definitively not affordable!

The problem with rechargeable 2032 batteries (like the LIR2032) is their voltage drop curve is linear. This means that after 6 months, they can be at 2.5V and a year at 1.5V.  CR2032 maintain close to 3V and drop to 0V right at the end.  You would prefer that kind of voltage drop for your SRAM, especially if you keep your X68K unplugged for months at a time.

I ended taking the LIR2032 out of X68000 and installing a CR2032 (with resistor + diode) and noticed that the SRAM holds on to data much much longer (I plug in my computer once every 1-2 years)

Quote from: LowDefAl on January 05, 2026, 05:27:23 AMFrankly at this point the community needs to stop using SRAM for SxSI support on pre-Super's. Good for testing and playing wth the machine short term but there is a better solution as long as you open the case, and lets face it you have to do that to add these things anyway.

Even setting aside the issue with the battery, the SxSI driver won't help if your floppy drives don't work.

I don't think that's right. I've helped a handful of people get SASI X68K setup. In all cases, SxSI SRAM driver + SCSI2SD or ZuluSCSI on external connector (the devices are in 3D printed cases) This way, they can easily change the HDD image without ever opening the system. I provide them with a 5.25" boot disk with instructions on how to reload the SRAM if it ever dies. The SRAM battery is extended to a coin holder just behind the cover if the battery ever dies.

And for those with bad FDDs, no big deal. I have an FDX86 to help there.

A fully loaded ACE or Expert is just as capable as a Super.

I tried the program XDFBOOT.X made by yunkya2, with the henkan bancho pro device on the XVI with the following results:

Bonanza Bros. with the version included in SxSI-SCSI HDD Image v3.02 only worked on the XVI at 16MHz. Using xdfboot it works perfectly at 10MHz and 16MHz. I couldn't try it on SASI systems, as I still have to finish repairing my Expert.

Knight Arms, which used to boot randomly, now boots correctly.
I also started Chojin, previously reported by the user Hissa, and it works perfectly, with MIDI support.

However, I fear that it might not be able to save the progress since it is loaded into memory.

The program xdfboot.x will borrow about 3MB from the total system memory to function; the program is not capable of emulating games with more than two disks at the moment.
Don't worry, games like Valis II, which require 10MB to run, will still start without any problems.
The process is reversible, returning your total memory to default values, if you wish.

@spectreman Thanks for testing these out, so the same limitations apply as with 2hdboot, where progress cannot save to the disk?

@incrediblehark Unfortunately yes, the changes only affect the image loaded in memory, but they don't change the .XDF files.
It seems more effective than 2hdboot, although at the moment it is limited to just two .xdf images.

I also tried New Zealand Story, applying the nls.x fix in the .xdf of disk 1, and it worked perfectly even at 16MHz, without any graphical glitches.

For those who are interested in trying xdfboot:

I preferred to copy the xdfboot.x file into the BIN folder, but it will actually work perfectly well in the folder containing the games too.

You will need to create two batch files. One to install the program that will reduce your SRAM by 3 MB, which is necessary for it to function.

The file must contain this command:

xdfboot -s

The second batch file, will be useful when you want to restore your SRAM to the default values, if you need it:

xdfboot -r

I preferred to create them inside the folder that contains all the .xdf games, for convenience.
When Japanese text appears, press any key to run the command, and the system will reboot to apply the changes.

!START.BAT file contained in the game folder should look something like this:

xdfboot.x game_name_1.xdf game_name_2.xdf (you can also go beyond the 8-character limit).

When starting the game, the cursor will continue to blink for the entire duration of loading into memory.
To transfer the games to your HDD image, you can use editdisk.exe (editd169e), while to convert .dim files to .xdf, use vfic.exe (vf011010).

If it is used in emulators like XM6-typeg, remember to deselect the update memory switch function in the options, otherwise the system memory will be reset to the default values.

xdfboot.x: https://github.com/yunkya2/xdfboot

editd169e and vf011010: https://nfggames.com/X68000/index.php/PC_Tools/Disk/

Quote from: incrediblehark on December 27, 2025, 11:08:48 PMthanks for following up! I'll see if I can get a working file for you as soon as I'm back from the holiday break. I have a SASI machine I can test with too, I just forgot about this image...

How is this project coming along? Is it even possible to make a working SASI image? Which SD-HDD solution do you use for your SASI machine?

@kamiboy I apologize for the delay and lack of updates... I have been doing some testing. I still need to test with SCSI2SD and ZuluSCSI, and my testing so far with BlueSCSI has not been successful. One thing I'd like to try next is the ROM loading function of the BlueSCSI to see if I can load up the master disk as a bootable rom to get around broken floppy disks. Problem I have is my bluescsi uses a Pico 1 which only has 800kb usable rom area. Unfortunately a 2DD floppy doesn't seem bootable on X68000. I'll attach the master disk converted to ROM file for anyone who has the proper hardware and wants to give it a shot. I set system to X68000-SASI in the bluescsi.ini - this was the only configuration I was using at the time.


My CF card reader is broken, so when my replacement comes in I'll start Henkan Bancho testing. I think this may be successful as it claims to have SASI support. We'll see!

One last thing for now - I have a set of EXBIOS roms that I have used in a PRO, going to see if I can use these to load Sxsi without master disk / sram loading. Not sure if they are compatible in older towers.

Tried the ROM just now only to find out that I also got a pico1 with my BlueSCSI...

@incrediblehark In fact, Henkan Bancho Pro/V4 is the only one with native support for SASI systems; if the experiment doesn't work with this device, I doubt it will work with others.

Alternatively, one could consider the possibility of adding a SCSI expansion card like this:

https://classicpc.org/番長の相棒-ver-2/

@spectreman thanks for the link, I have a SCSI card I can test next, but I like this one too, looks like you could use it to install an updated bios in ROM 2.

 I may try ordering one but not sure when I would receive it with Japan Post halting US shipments.

@incrediblehark I have translated the manual for the SCSI expansion card using an automatic system into .pdf format; you can find it attached.
Unfortunately, the text is rather small, but I hope it is still useful to you.

Hi, I received my 68882 FPU yesterday and installation went without any issues. Virgin Angel is now fixed, it turns out that the game detects the FPU on start up, but if it finds it, the game writes $0000 to $E9E006. This causes the bus error, so I just patched the game to skip the routine that does that write.

M.X is the patched game executable, copy it over to the floppy or hard drive image, overwriting the old M.X.

Let me know if you find any issues, I didn't test too far into the game, just made sure it could boot and generally worked.

@rezb1t Everything seems to be working correctly, and the saves are working too.
Great job, as always!

@rezb1t you've done it again! Thank you for the fix, I'm behind on getting all of these added...

Small update to my testing of the SASI image. I am not able to get it to boot properly with Henkan Bancho either. It's looking like there's a conflict preventing this. If I create an image I get a hard disk error when trying to format, which leads me to believe there's something wrong with a setting or naming comvention with the image on henkan bancho.

In order for the image to be bootable on a stock system with clear SRAM, the SASI disk has to be set as HD0, as that is the only one bootable when your sram is erased and default is STD for boot order. Having to go in and change SWITCH would defeat the purpose of using this image in systems without working floppy drives.

On the Henkan Bancho the ID0 led flashes briefly and turns off whe I have my image named to reflect SASI0 and LUN0 or LUN1. Does not boot. But even changing switch settings to HD1 and assigning ID1 it still doesn't boot but everything else appears to be functioning properly, which also makes me think my settings for the HB are off for the hdf file. I plan to keep troubleshooting this and see if I can work out a solution.

@incrediblehark Use this test image to check if Henkan Bancho starts normally.

I don't know the Henkan Bancho card, but it can manage both sasi and scsi at same time?
Considering the size limits of sasi drives, the only useful solution would be booting the x68k from sasi id0 and then having programs and games in scsi id1-idn, @incrediblehark , is this the goal of your test?

Yes, at least that was the intention when I originally suggested this option to be explored. It does seem that SASI support is seemingly a hindrance, either that or making a proper SASI HDD image is tricky.

@spectreman, how did you source the linked SASI images? I'll try them on my Zulu once I get home.

While trying to make a SASI drive I had the same problem as @incrediblehark, where trying to format the image on a real X68000 would throw up an error.

Haha, actually never mind. These are HDF files, I cant test these, they wont work on BlueSCSI. It only accepts hda images. The HDF files are for emulators, not sure if any of the SD-SCSI devices support them.

@spectreman Thanks for the images, I didn't need them but it solved the issue I was missing. I needed the [256] tag added otherwise the device assumed 512 byte sectors (SASI uses 256 bytes). I was suspecting this and overlooked it. after adding that my SxSI_Enable.hdf boots perfectly on the Henkan Bancho!

@aotta Yes, my goal is to establish a way to load the SxSI drivers via SASI hdd image to allow users to then install the main HDD image for use. Not necessarily run both SASI and SCSI images at the same time but after loading the SxSI drivers with the SASI image, then switch to the full HDS images.

@kamiboy I will continue trying to get a working BlueScsi image...

@kamiboy The .hdf format is natively supported by the Henkan Bancho Pro/V4 device, designed in Japan. 
It can simultaneously accommodate both .hdf (SASI) and .hds (SCSI) files.

Incrediblehark's intention is to create a .hdf image containing the SxSI drivers, for example:

SxSI_Installation[sasi0][lun0][256].hdf 
Games[scsi1][512].hds

However, the biggest obstacle remains, the incompatibility of emulation devices. Although this option is available for Henkan Bancho, for devices like BlueSCSI v2 it is more complicated.

For those who are interested in Henkan Bancho:
https://classicpc.org/変換番長v4-内蔵モデル/

Installation kit for SASI systems:
https://classicpc.org/変換番長v4-x68000sasi内蔵スペシャルキット/

Here is my link to the updated SxSI_Enable_v2 HDD images on my Google Drive:

https://drive.google.com/drive/folders/1iK__LUtNerBvA9Ds_QyKEFPjOGTejMV2?usp=sharing

I currently have working images for both the Henkan Bancho and ZuluSCSI. I'm still getting hung up on BlueSCSI though. I don't think its recognizing the proper heads and cylinders for the image. I tried adapting my settings in the ZuluSCSI.ini file to their equivalent settings on BlueSCSI, but it still will not boot.

@spectreman Thanks for the nudge in the right direction, it allowed me to fix my image and create the Zuluscsi one as well.

@kamiboy If you have a ZuluSCSI, try this one out and let me know if it works for you!

This should hopefully solve the problem of loading SxSI drivers on machines without working floppy drives.

@incrediblehark But couldn't you have released the HDD image before I made useless posts? (just kidding).

Congratulations!!!

Great job, but for the BlueSCSI v2 version, do you want to make kamiboy happy or not? (just kidding again).

Quote from: incrediblehark on January 22, 2026, 10:44:19 AMHere is my link to the updated SxSI_Enable_v2 HDD images on my Google Drive:

https://drive.google.com/drive/folders/1iK__LUtNerBvA9Ds_QyKEFPjOGTejMV2?usp=sharing

I currently have working images for both the Henkan Bancho and ZuluSCSI. I'm still getting hung up on BlueSCSI though. I don't think its recognizing the proper heads and cylinders for the image. I tried adapting my settings in the ZuluSCSI.ini file to their equivalent settings on BlueSCSI, but it still will not boot.

@spectreman Thanks for the nudge in the right direction, it allowed me to fix my image and create the Zuluscsi one as well.

@kamiboy If you have a ZuluSCSI, try this one out and let me know if it works for you!

This should hopefully solve the problem of loading SxSI drivers on machines without working floppy drives.

I have BlueSCSI actually, I got confused. But from my understanding Blue is the successor to Zulu, and they both require .hda image files. I will try the one you attached when I get home, cheers.

Quote from: spectreman on January 22, 2026, 12:12:16 PM@incrediblehark But couldn't you have released the HDD image before I made useless posts? (just kidding).

Congratulations!!!

Great job, but for the BlueSCSI v2 version, do you want to make kamiboy happy or not? (just kidding again).

Correct me if I am wrong, but BlueSCSI is the cheapest SD-SCSI solution out there, and SASI X68000 machines are the cheapest way to get into the Cadillac of 80's computers.

So a working BlueSCSI SASI bootable image would be of benefit to many. I certainly know I will buy at least one more BlueSCSI for my other X68000 if a SASI bootable .hda image ever materialises.

Who knows, I might even get a third to replace the ancient AztecsMonster in my Compact in the future.

@kamiboy Thanks for testing it out. Attached is the ini file I was trying to use to get the .hda to work with bluescsi. Maybe you can find what I am doing wrong compared to the zuluscsi config. Otherwise this may be something that needs to be pushed for an update to bluescsi?

The game Buster freezes at the beginning of the first level; the problem can be fixed by starting the game with 2hdboot or xdfboot.

Quote from: incrediblehark on January 22, 2026, 08:58:03 PM@kamiboy Thanks for testing it out. Attached is the ini file I was trying to use to get the .hda to work with bluescsi. Maybe you can find what I am doing wrong compared to the zuluscsi config. Otherwise this may be something that needs to be pushed for an update to bluescsi?

ZuluScsi use the same SCSI2SD core FW for managing SxSI interface, and it's confirmed by ZuluSCSI source code:
https://github.com/ZuluSCSI/ZuluSCSI-firmware/blob/main/lib/SCSI2SD/src/firmware/scsi.c
at row #3 you'll find my name within the authors, but i only made some change for X68000 compatibility in BlueScsi2 repo (i don't even own a ZuluSCSI)!
So, if your SASI image works on Zulu, it should work on BlueSCSI2 too... what about the LOG file? could you enable the verbose output and check what could be wrong?
I'll do some test with your image in next days too.