This may not be applicable to your situation/hardware.
SCSI2SD v5.0 is not the same as v5.1, v5.2, v4.0, etc. The utility I used here is not the same one used for those versions, and you may not find the same options. Hopefully it'll be clear how to adapt these steps.
SCSI2SD are a variety of devices that simulate SCSI storage, using data loaded from a microSD card. They're popular for use in vintage Macs and other old non-PC machines, and a lot of integrated devices like sampling synthesizers.
In my opinion the SCSI2SD is an unpleasantly primitive device, but they're commonplace, and I already had one. Unfortunately the documentation is extremely poor IMO. In particular I could not find any summary of how to configure a SCSI2SD to act as a CDROM at all, only forum posts describing very specific scenarios for quirky devices. It is my hope that the instructions here will be generally useful.
I have used this for two devices to date:
The problem in both cases is similar: While the host machine supports SCSI CDROMs, it has a "whitelist" of specific make/models it supports, and all other devices will be ignored. This actually makes the SCSI2SD uniquely suited to replacing old CDROMs since, even if you want to use a physical replacement drive, finding one with the exact hardware IDs you need can prove impossible. The SCSI2SD can masquerade as any drive.
The process of setting this up is very easy if you have that data.
Obtain the vendor and device IDs for the drive you're trying to "clone." This is a pair of values like "TOSHIBA"/"XM-3401BMQ." They are extremely specific and must match to the letter, including spaces (sometimse at the BEGINNING of a string.) I believe you also usually need a precise version number, which is e.g. "1.1t."
If you have a semi-working specimen, you may be able to get these IDs using a SCSI diagnostic tool, but it's up to you to figure that out.
Create a CD image containing the data you want to move to the destination system. I used ImgBurn, set to "Create image file from files/folders," and just dragged in some folders and saved them to an ISO.
Write that image to your SD card. I used balenaEtcher for this, picked the ISO as input, the SD card as output. It will complain that it's not bootable; ignore it.
On e.g. Linux you would probably use dd to write the image. I have not tried this. I assume the command would be dd if=discimage.iso of=/dev/sdb, where sdb is the identifier of your SD card. It is up to you to figure out how to do this safely; if you pick the wrong device you will erase your hard drive.
Configure the SCSI2SD. You will need to connect it to your PC with a USB cable, and then obtain the config utility. It took me a while to find it because the older software is not well catalogued. You have to get the right version for your device. v5.0 is not v5.1 is not v5.2 and so on. Read the documentation closely.
If the v5.0 software works for you, I mirrored it here: scsi2sd-util.exe
Run that utility and configure the device like this:
My understanding of these options:
The settings in the screenshot will probably work for anything without a whitelist. If you have an ordinary e.g. Adaptec controller, they will almost certainly Just Work.
Once you've selected all these options, connect the SCSI2SD to your machine, then go to
File > Save to device.Make sure it writes successfully! A failure looks exactly like a success, so you need to read the dialog closely. Once it says it succeeded, you can connect the SCSI2SD to your machine and test.
When I initially configured my SCSI2SD, it was not detected by the Eduquest. I assumed there was a bus-level problem (e.g. termination, wrong ID, etc.) because I assumed SCSI was SCSI. It turns out that the CDROM driver that IBM included with their machines was hardcoded to look for a specific vendor ID, and if it doesn't see it, it simply pretends the device doesn't exist.
A friend looked at the driver, LOC-CD.SYS (I suspect this is a renamed IBMCDROM.SYS) in a hex editor and noticed the clear strings IBM and TOSHIBA. The old drive was in fact a Toshiba. Changing the Vendor field on the SCSI2SD to TOSHIBA fixed the problem immediately. I do not know if IBM would have worked. Since Toshiba made a lot of CDROMs in the era, I suggest you try this.
MacOS in the "beige era" (system 6/7, possibly 8, probably not 9?) was extremely picky about SCSI CDROMs. The Apple official driver only works for Apple-branded drives.
Beware: If you connect a non-Apple CDROM and insert a bootable disc, while it will work, and you can even install an OS from it, and you can restart, boot off the HDD, and still access that drive, you are seeing a fantasy world. I am told that the classic MacOS installer injects a generic CDROM driver into memory that works for the duration of install, and persists through a warm boot, but once you cold-boot the machine, it'll evaporate. Don't waste 12 hours troubleshooting like I did - expect the drive to stop working unless you find a third-party driver, like FWB CD Toolbox, that happens to have support for it (not a guarantee.)
I have only experimented with this on one System 7 Mac (a Color Classic, although really it's an LC550, since that board was transplanted into it.) I get the impression other contemporary Macs have similar problems.
I have not fully figured out this process, but I have two scenarios that you can try.
This should be as simple as writing the MacOS install disc ISO to an SD card, then applying the config from the screenshot above. You aren't trying to match any vendor IDs, so it should Just Work. I have not tested this with a SCSI2SD, but I did with a third-party physical CDROM from LaCie. It works until you cold-reboot.
File > Compile to write out an ISO, then write that to your second SD card with e.g. balenaEtcher.If this doesn't work, get a copy of Disk Tools from OS 7.5 (again, you can get a writeable .IMG from WinWorldPC) and write it to a floppy. Repeat step 6, but when you reboot, pop in the Disk Tools floppy. If it works, you'll boot up into 7.5 with both the CDROM and HDD accessible.
In theory, there's no reason the SCSI2SD shouldn't work with the normal Apple CDROM driver, if you could assign the correct Vendor, Product and Version IDs. I don't know what those are, so I haven't been able to test this. If you know them, please email me: cathoderaydude@gmail.com. You may be able to get these using Apple's System Profiler.
How do you change which "disc" is "inserted"? There is no "swap image" option; you have to write a new SD card and insert it. When you remove and reinsert a card, it's as if you ejected and inserted a disc, so the host machine will behave appropriately. You can just pull the SD card, overwrite it, then put it back in to "swap discs" if you only have one card.
Are there any commonly-used SCSI IDs? I suspect that most "computer" type devices will accept any SCSI ID. My Eduquest CDROM came with the ID set to 0, but the machine, and its picky driver, still see the SCSI2SD just fine if I set it to ID 4. Maybe integrated devices could be pickier. Macs often use 3 for a CDROM, but again, this does not seem important.
It has been suggested to me that by convention, "hard drives are 0 and 1, and CDs are usually 2 or 3, on big iron / unix systems, but usually 3 or 4 on consumer gear (mac, amiga)."
I do not know if this is due to the machine expecting specific IDs, or just because they use a single chain (cable) with multiple devices, and this convention avoids collisions. I suspect the latter - in theory, SCSI IDs should never matter as long as you don't have two devices with the same ID.