Update: autobooting a superkickstart Amiga 3000 from the Buddha IDE card (posted 2020-10-31)
Last week, I wrote about upgrading my Amiga 3000, where I mentioned that the Amiga 3000's boot ROMs don't recognize the Buddha card. Turns out, that can be fixed.
Early Amiga 3000s don't have their regular kickstart in ROM. Instead, they have a kickstart version 36, which will normally try to load an older kickstart 1.3 or newer kickstart 2.0 from a floppy or the harddisk. Also, this needs to be a special kickstart file, which has a "bonus" attached at the end. To make this work, you need to have a harddisk partition with the device name wb_2.x. That partition must be the autoboot partition with the highest boot priority. (If not, the kickstart 36 will try to boot the system itself, and quickly run into software that is incompatible.)
At some point, I noticed that the v36 bootROM only recognized one of the four cards in my Amiga 3000: the ISDN-Master card in the lowest slot. Above that was the CyberVision 64/3D card and above that the X-Surf Ethernet card and the Buddha. So what if the CV64/3D made the AutoConfig™️ process fail, so the remaining cards couldn't be configured? That hunch was correct. After moving the Buddha to the lowest slot and the CV64/3D to the highest one, all three other cards were recognized, so the bootROM would load kickstart 2.0 from the Buddha.
However... that old kickstart 2.0 then in turn wouldn't recognize drives connected to the Buddha, at least not as autoboot targets. Long story short, I made a kickstart 3.1 superkickstart file and put that on a Buddha partition. With that in place, everything finally works reliably without any dependencies on the SCSI HDD.
Making a superkickstart
So how do you get a 3.1 superkickstart? First, you need an Amiga 3000 kickstart file. I wouldn't waste time with a kickstart for a different machine, although that may or may not work. I spent 20 euros on the Amiga Forever 8 plus edition. That's an Amiga emulator package for Windows sold by Cloanto, the current owner of (most of?) the Amiga intellectual property. It comes with all versions of kickstart and workbench. Alternatively, the ROM file that comes with Hyperion Entertainment's AmigaOS 3.1.4 should do the trick. And there's numerous utilities that will write an Amiga's kickstart to a file, so you could use one of those if you have an A3000 with a suitable kickstart version in ROM.
What you also need is an original superkickstart. But if your Amiga 3000 still runs, you should have that. Then use Epsilon's instructions on how to combine the bonus code from an old superkickstart with a new kickstart file to make a superkickstart. When I tried that, it didn't work. Turns out Cloanto scrambles their kickstart files to make illegal copying harder. You can tell you have a scrambled one because it's 524299 rather than 524288 bytes long. However, the romtool copy function will unscramble your kickstart file. (This runs on a Mac or under Linux.)
For good measure, I also used MakeSuperDisk to create a kickstart 3.1 floppy. (Well, Gotek ADF file.) However, when loading the kickstart that way, none of the drives are recognized as bootable...
Making it all work together
To finish the whole ordeal, I created the following setup:
- SCSI HDD in its original setup, with wb_2.x as the device name and a low boot priority.
- The DOM (Disk-On-Module) that comes with the Buddha has about 94 MB of unused space. So I made a new wb_2.x partition there with a slightly higher boot priority and an AmigaOS 3.1 installation on it.
- Last but not least, on a CF card I made a wb_2.x partition with a more extensive AmigaOS 3.1 installation and the highest boot priority.
The idea was that with the Buddha available and the CF card plugged in, I would boot from that. With the Buddha but without the CF card, I would boot from the DOM. And with the Buddha unavailable, I'd still boot from the SCSI drive. However, that last part didn't work: if the SCSI drive device name is wb_2.x, the system will try to boot off of that drive regardless of the Buddha. So I gave the SCSI drive a different device name and made it non-bootable for good measure. This of course easy enough to change with HDToolbox without disrupting the data on the drive. Between the Buddha DOM and the CF card, my trick did work, but remember: the kickstart will only be loaded from wb_2.x if wb_2.x has the highest boot priority.
I use assign dismount <drive> and assign dismount <volume> in my s:user-startup to make the SCSI drive and BuddhaInstall DOM partition invisible and quietscsi11 to make the SCSI drive motor stop spinning so it's quiet. You can also just do assign dismount <volume> to make a volume invisible for the Workbench, but you can then still access files on that drive/volume through the device name.
All in all, I think I'll probably remove the SCSI drive the next time I open up the computer. Also, I originally got transfer speeds of almost 2.3 MB/sec with the CF card, but now only 1.7 MB/sec. Perhaps this has something to do with the presence of the DOM. However, I like being able to swap out CF cards, so I think I'll leave the DOM in place even if that slows down transfers by half a megabyte per second. (But there could be another reason for that, too.)