Amiga short takes: OS 3.1.4, disk error (posted 2020-10-04)
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.