Bondi Blue iMac Restoration
With Apple’s 50th-ish birthday passing and folk considering what machines are most notable/best/significant, I realized that didn’t have an iMac G3. Though I do have 4 other G3’s: Desktop, Minitower, B&W and Pismo. My wife had a Firewire iMac DV back in the day but it had been passed on. So, I bought a cheap Rev A Bondi Blue from a local recycler.Externally, it was a bit scratched and scrapped but nothing a little plastic polish and buffing couldn’t fix. Internally, the condition looked excellent. It had 64MB of RAM, 4MB expansion VRAM, a dead but intact CMOS battery, onboard ethernet and its original 4GB drive. That all worked and the video quality was good. Good start. But..
CD-ROM
The original CD-ROM drive (Matsushita CR-173-D) didn’t work and a thorough cleaning failed to bring it back to life. The OpenFirmware (v3.0.2f) sadly won’t boot from USB although external USB storage is supported - so some software installation was possible. The network could also used to load stuff or to network boot from.I couldn’t find any direct replacement drive on eBay or anywhere. One or two sites claimed to have reconditioned stock but orders got bounced. I tried a later TEAC slim 24x drive which was physically compatible but evidently the firmware was too different.
I eventually managed to find a CR-176-B drive. This is a later revision and it wasn’t clear how the -B designation differed from the -D, but it was worth a shot. Luckily the drive worked fine. In fact, it was happy reading CD-Rs which I suspect the original drive would have balked at.
I’d taken the bezel off the original unit although two of the locating posts had broken off .. typical old ABS plastic. However, the locating points were identical on the CR-176-B so I used acetone to weld them back together. In fact, it took 2 attempts because the posts broke yet again and I needed to transplant posts from the replacement unit.
RAM
64MB RAM is OK for Classic MacOS, but barely adequate for *nix. The Rev A iMac should support 128MB+128MB in its 2 144-pin SO-DIMM slots. But reports noted pickiness and differed as to whether PC66 or PC100 is needed. I wasn’t having much luck trying assorted sizes and latency DIMMS to work .. and then I examined the expansion socket under a microscope: there were about 3 dodgy pins - d’oh!! One pin was a redundant ground line, one bent back into place OK, but another broke off completely. I’ve replaced 66-pin SIMM sockets but I was hesitant to replace the SO-DIMM socket wholesale on this dense CPU daughtercard. I wound up running a bodge wire up the side of the socket and down into the broken pin. It worked .. although I don’t intend to switch DIMMS ever again. 256MB is fine. I found one 128MB PC66 stick in the base slot and a 128MB PC100 stick in the expansion slot worked.VRAM
At this point, I started getting video artifacts, and the MacProTest VRAM tests failed for the expansion slot. Maybe the SGRAM socket was dodgy also? But no .. the socket looked good. I used contact cleaner and deoxit to sort this out.Storage
Although the original 4GB hard drive worked, I wanted to replace it with more modern and capacious storage since I wanted to multi-boot various OSes: MacOS, OSX, YellowDog Linux, Debian Linux, and NetBSD.Note: the Rev A suffers the same limitations as Beige G3s: 128GB is the maximum addressable space and OFW can boot only from the first 8GB of the drive. However, *nix OSes can be bootstrapped (loaded) from the lower 8GB but have their root partition living above this.
So I set about investigating alternatives:
Maxtor DiamondMax 80
Firstly, as reference, I transplanted a 80GB ATA hard drive from my G3 MiniTower. MacOS 9 booted fine and performance was excellent.
But it was hot, noisy and potentially unreliable.
SATA SSD
My got-to is SATA 128GB SSD plus IDE/SATA adapter from OWC. As noted, IDE on these G3s is limited to 128GB with a boot restriction of the first 8GB. In the past I’ve found G3s fussy about IDE/SATA adapter chips and, sure enough, the default StarTech adapter (with Marvell 88SA8052 PATA to SATA Bridge chip) wasn’t recognized by the firmware.
I also had a couple of Chinese adapters using the JM20330 bridge chip. These both successfully booted into MacOS9 although the firmware took a ponderous time to get to the Happy Mac (as many other folk have reported). Furthermore, disk corruption became evident before long (again something I’d seen on other G3 machines). In addition, attempts to install Debian resulted in the disk driver being patched and MacOS becoming unbootable.
No good.
SD card
My next disk replacement experiment was the SD35VCO SD-to-IDE adapter. These are sold under many brand names, all dirt cheap. It’s fast and reliable for MacOS9, OSX and Yellow Dog Linux 3.0 runs nicely. But Debian 8 (Jessie) and NetBSD 9.x wouldn’t boot: the adapter’s PATA DMA protocol implementation doesn’t conform to the IDE drivers in these OSes.
To diagnose and possibly fix these issues, I pulled the SPI Flash PROM for the FC1307A chip (containing an 8051 microcontroller code), dumped the firmware, and used Claude to reverse-engineer the code. Together with kernel boot messages, Claude helped me deduce that during early initialization, the adapter generated an unexpected interrupt which wasn’t cleared - so repeated assertions ended with that interrupt being ignored. Subsequently, proper ATA DMA READ requests had completion interrupts ignored and thus the operations were timed-out. Claude made patching the ROM easy and so experimentation was convenient. However, it didn’t prove possible to fix this issue with a firmware revision. Nevertheless, I was able to build a Linux kernel to avoid the failure on boot but other disk oddities persisted.
Only good for macOS.
CF card
Since CF cards support the ATA/IDE protocol natively, I next tried a StarTech IDE to CF adapter (35BAYCF2IDE) with a 64GB Industrial CF card. This worked reliably for all MacOS9, YDL 3, Debian 8, OSX, and NetBSD 9.2. Random read speed was good (~14MB/s) but write speed was very poor (<1MB/s). This bad write performance was especially noticeable for *nix OSes.
OK but disappointing.
mSATA SSD
My next experiment used a 2.5in 44pin IDE to mSATA adapter with 44pin-to-40pin IDE converter and loaded with a Dogfish 64GB mSATA SSD. Although this was fast and mostly fine booting to MacOS9, it uses the same JM20330 bridge chip as the SATA adapter and again demonstrated the same flaky unreliability.
Fail.
At this point, only the spinning disk or the CF card were workable solutions but both had issues. Now .. my Beige G3 had an underused 64GB Hyperdisk DOM (Disk On Module) SSD which I knew to be fast, efficient, compact and reliable .. so I moved it to the iMac.
DOM (Disk On Module)
These are NAND devices with PATA interface . They are master-only and integrated into a female 40-pin connector intended to be plugged directly into a motherboard with no cabling. An additional cable provides 5V power from the regular Molex connector.
Several years back, these were cheap and available in the US. Today, they’re more expensive and I only see them available from Alibaba.
There wasn’t enough space in the iMac to plug the DOM into the logic board so I acquired a male-to-male 40-pin IDE converter cable to locate the DOM in the hard drive bay.
All OSes now boot and run quickly.
For reference, the 64GB DOM was initialized from MacOS9 and partitioned using pdisk run from OS9 and the other OSes. The partition layout is (as reported by OSX pdisk):
Partition map (with 512 byte blocks) on '/dev/disk0'
#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1
2: Apple_Driver_ATA*Macintosh 54 @ 64
3: Apple_Driver_ATA*Macintosh 74 @ 118
4: Apple_Driver_IOKit Macintosh 512 @ 192
5: Apple_Patches Patch Partition 512 @ 704
6: Apple_Bootstrap bootstrap 262144 @ 1216 (128.0M)
7: Apple_HFS MacOS9 4194304 @ 263360 ( 2.0G)
8: Apple_HFS MacOSX 12319552 @ 4457664 ( 5.9G)
9: Apple_UNIX_SVR2 ydl_root 16777216 @ 16777216 ( 8.0G) FS
10: Apple_UNIX_SVR2 swap 1048576 @ 33554432 (512.0M) FS
11: Apple_UNIX_SVR2 debian_root 16777216 @ 34603008 ( 8.0G) FS
12: Apple_UNIX_SVR2 netbsd_root 16777216 @ 51380224 ( 8.0G) S0 RUFS k0 /
13: Apple_UNIX_SVR2 netbsd_swap 1048576 @ 68157440 (512.0M) S1 SFS k0 (swap)
14: Apple_HFS Mac_Etc 16777216 @ 69206016 ( 8.0G)
15: Apple_Free Extra 37349136 @ 85983232 ( 17.8G)The bootstrap partition is set up by Debian to contain yaboot and friends providing the OFW multi-boot script to boot each of the OSes. Only the OS9 and OSX partitions are in the lower 8GB. Partition 9 starts at the 8GB boundary. Yaboot loads the Linux kernels, and ofwboot loads NetBSD kernel, from any of the low partitions. OSX Tiger was installed using XPostFacto. XPF can be configured to use a low-8GB Helper partition from which to load BootX and then use a high root partition - but I’ve not tried this. Mac_Etc is an HFS+ expansion space for both MacOSes.