Update: autobooting a superkickstart Amiga 3000 from the Buddha IDE card

▼ 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.)

Permalink - posted 2020-10-31

Amiga short takes: OS 3.1.4, disk error

▼ The last few weeks I've been spending some time with my Amiga 1200 and Amiga 3000, and I want to write about some of that. However, I don't want to spend too much of my own time and that of the readers of this blog on that. So my plan is to do a collection of short takes periodically. This will be the first one. Topics:

• AmigaOS 3.1.4
• Roadshow TCP/IP stack
• Cybergraphx 960x540 resolution
• Disk error
• SD-to-CF adapter

AmigaOS 3.1.4

I don't think we're in any danger of the Amiga joining modern operating systems in having an update every time you've been away from your computer for fifteen minutes. But: turns out that two years ago, there was actually a new AmigaOS 3.1.4. Yes, more than two decades after the last Amiga rolled off the assembly line.

My Amiga 1200 came with 3.0 and I never upgraded to 3.1, as it didn't seem to offer any useful (to me) new features. And then Commodore went out of business. However, there were 3.5, 3.9 and 4.0 upgrades, with tons of new stuff. As the version number suggests, 3.1.4 builds on 3.1. It doesn't offer new flashy features, but just improves a bunch of stuff. For instance, you can now use drives larger than 4 GB. It also brings newer, more colorful icons to the OS, supporting both NewIcons and AmigaOS 3.5 type icons natively.

I opted to get AmigaOS 3.1.4 as a download, and not get new ROM chips. Instead, I just use BlizKick to load the 3.1.4 Kickstart into RAM, overwriting the copy in RAM my A1260 accelerator makes anyway.

I installed the new OS on my Amiga 1200 from floppy disks on a new CF card, which went quite well except I had to install a 68060.library to support my 68060 CPU manually, and without the 3.1.4 Kickstart, booting into the new OS leads to an immediate crash as during startup, ROM patches are loaded but these are of course not compatible with my 3.0 ROMs, hence the crash.

This did make me realize that if you want to run an Amiga in this day and age, you really have to be comfortable configuring stuff manually and not solely depend on installers.

Roadshow TCP/IP stack

I'm rebuilding a new AmigaOS installation from scratch, but I can also boot from a copy of my old install, I wasn't going to throw away 25 years of history. So this was a good opportunity to update my networking. I've used Miami from 1995 or so. Miami is a TCP/IP stack that is entirely configured using a graphical interface, and worked especially well with dial-up modems. However, the GUI creates a lot of overhead.

Turns out there is a much newer TCP/IP stack that a lot of people like: Roadshow. So I installed the demo version, which turned out to be about 50% faster than Miami. So I immediately got the commercial version, my smbfs file transfers can use all the help they can get.

Roadshow does come with an installer, but I needed to make a config file for my I-Card driver manually. (The I-Card is rather obscure because it was available in the 1990s long before consumers had the need for Ethernet.) After it's installed, Roadshow just loads automatically and is completely invisible, like we're used to with modern computers. So highly recommended if you have an Ethernet adapter for your Amiga.

I also installed Roadshow on my Amiga 3000, which only has 4 MB fast RAM left (of 8) after loading Cybergraphx drivers and BBS software, as well as two kickstarts. Replacing Miami with Roadshow improved that by almost a megabyte.

Cybergraphx 960x540 resolution

All this network speed testing meant I spend a bunch of time looking at the output of the Cybergraphx 64/3D graphics card in the A3000. I used a 800x600 resolution, which works very well with the VGA input of my Dell U2312HM monitor. (Much better than the Amiga 3000's native VGA output.) However, after getting 960x540 to work on my Amiga 1200, I wanted to see if I could do the same with the Amiga 3000. Turns out that the Cybergraphx software has supported setting up your own resolutions all along, so I did some experimenting.

When I set up 960x540, the monitor recognized that as 1920x540. So that was good. However, it didn't show all 540 lines, and there as a significant amount of unused space on the left and the right. I fixed this by upping the pixel clock a lot and adjusting the last vertical setting, and then adjusting the pixel clock and phase on the monitor a bit. I can't check the exact settings right now because of the last topic of this post.

Disk error

And then yesterday morning I turned on my Amiga 3000 and it couldn't boot because the harddrive was validating. In and of itself that isn't a huge deal, usually the validation process runs for a while and then everything is back to normal. I actually have a small wait for validation tool in my user-startup so the BBS won't start until the HDD has been validated. So I guess (don't remember) that back in the day, this happened with some regularity.

The trouble is, I have a pretty tricky boot setup on the A3000, and that setup doesn't work if the drive is read-only, as it is during validation. The older Amiga 3000s load their Kickstart from disk in a somewhat peculiar way. When I installed AmigaOS 3.0, I kept that 2.0 Kickstart process, and then loaded a second 3.0 Kickstart and then pointed all the assigns to the 3.0 system in a subdirectory on the 2.0 drive.

Turns out, the execute command needs a temporary file, which normally goes in T:, but if the boot process isn't far enough along to have the T: assign, it uses :T (i.e., a T directory on the boot drive) instead. Which it couldn't, because the disk was validating. And then failed to validate because of a read error. Eventually I was able to boot by creating T: in RAM manually and then executing s:startup-sequence.

Before I figured that out, I actually used a terminal program to exchange files with my other Amiga over a nullmodem cable. This is actually a pretty good option of last resort, because using a terminal program to talk to the serial port is infinitely simpler than setting up networking, which not only requires a networking stack but also a bunch of settings and the right driver.

Right now, DiskSalv is trying to copy data off of the drive to my NAS, but that seems to be taking forever. Fortunately, I made a copy last week, so even if this fails I probably won't lose any data. Maybe I can repair the drive, but I think at the very least I need to do a full format so the drive can remap any bad sectors.

The trouble is that with a non-working floppy drive, if I wipe the SCSI HDD, the computer can then no longer boot. I guess it can be done by having networking running, do the format and copy the necessary stuff back to the HDD from over the network. However, if I make a mistake and the machine won't boot, there's nothing I can do. So I think I'm going to get a Gotek drive to solve that, and as I'm going to open up the 3000 anyway, replace its fan with a quieter one.

SD-to-CF adapter

As an additional option to exchange files with my modern systems, I ordered an SD-to-CF adapter from Amazon. I was lucky, because I ordered a type I card, which is about 3 mm thick. Most are type II cards, which are over 5 mm thick and don't fit in a CF-to-PCMCIA adapter that goes into the Amiga 1200.

The good news is that the adapter works as advertised: you put an SD card in the CF adapter, which then goes into the PCMCIA adapter, which then goes into the A1200. With CFD133 and fat95 installed, the card is immediately recognized, as long as it's formatted as FAT, not exFAT. Just plugging 64 GB of removable storage into the side of an Amiga 1200 is pretty wild.

However, I wouldn't say that this adapter is a success. First of all, the SD card goes into the side of the adapter. This means you need to remove the SD-to-CF adapter from the CF-to-PCMCIA adapter to insert or remove the SD card. The CF and PCMCIA interfaces work with lots of thin pins, so you really don't want to be plugging/unplugging those all the time. And you wouldn't want to use an SD card as (semi-) permanent storage as the transfer speeds aren't great: about 850 kB/sec. A CF card is almost twice as fast at 1.5 MB/sec.

Permalink - posted 2020-10-04