 |
| Really, colored PCBs should be a requirement. They look so cool. (This is my ZuluSCSI) |
(Get it, she drives me crazy? Because this part is about drives? I’m sorry. I’ll leave now.)
This is where I get to scream into the pixel wall that is xodium.net because hoo boy, this whole bit did NOT go well for me for a while.
When I first got the 9600, it was clean as can be. Not a spot of dust on it. The only main issue was that the the drive was gone, and I mean…these spinning rust SCSI drives aren’t long for this world nowadays anyway, so I was already expecting to have to replace it anyway. No big deal. I stuck in a trusty BlueSCSI and got it set right up.
Only…there was a small issue. It was slow. Slow to boot, slow to do much of anything around the OS, almost felt like the machine was bogged down by something. That’s because while the BlueSCSI is an excellent product, it really shines with older Macs (68k and early PPC). Later Power Macs like the 9600 which are going to be running something closer to Mac OS 9 and doing more demanding tasks? That’s where the BlueSCSI shows its weakness. (There IS overclockable firmware available for it, however, I wasn’t able to get it to work reliably on any of mine.)
Now, there are alternatives available! There’s the BlueSCSI F4, which uses a different design (and is more performant), and there’s also the SCSI2SD v6 and ZuluSCSI, which both seem to deliver performance that almost saturates the 9600’s inbuilt SCSI bus. The problem is cost. BlueSCSIs are roughly $30 (after tax and shipping) if you buy the kit from someone and build it yourself. Which is what I opt to do. (Money is short, and I’ve got the skills. Might as well. Plus, I find it kinda fun.)
The SCSI2SD v6 is $98 before tax and shipping (and it’s out of stock due to component shortages). The ZuluSCSI is a bit cheaper at around $75 or so all out, but still, we’re talking more than double the price of the original BlueSCSI (and a fair bit more than a mostly built F4).
With my current income situation clearly those pricier solutions–while arguably more ideal!–aren’t going to fly. So my options if I wanted to stick with SCSI end at the F4. Which is a fine product, of course!
But what if we didn’t have to deal with SCSI? What if we could put a modern drive interface in here, like SATA?
For a machine like this, totaling up the costs and such, SATA quickly became the most cost effective solution. Preflashed cards can be had for $60ish, or you can roll the dice yourself and pay far less, which is what I did.
Unfortunately, I hit a small snag. I bought an EEPROM and card, but figured out quite quickly that while I had the right card, I had the wrong EEPROM. I also needed a programmer (which I’ve since bought, but Garth was nice enough to let me borrow his). The EEPROM was the big hurdle though because the firmware we’re flashing has a sort of DRM in it that actually checks the model of EEPROM installed on the card. If it doesn’t match one of three chip models, the drivers refuse to load, and no drives will be recognized even if the card pops up fine in Apple System Profiler.
(Those three chips are the AM29LV040B, the PM39LV040, or the MX29LV040. The MX29LV040 is still available from Digi-Key, but is in the process of being obsoleted. So who knows how long it will remain available. The PM39LV040 however is still available new from AliExpress, and even though mine didn’t look like an “official” chip, it was good enough for the SeriTek firmware to load.)
If you’re curious to learn more and go through the motions with me, I did a write up on Tinker Different about the whole process. It was an endeavor, but in the end, it worked!
While I was waiting for the goodies to arrive from China, however, I wanted to look at SCSI solutions just in case this whole thing blew up in my face and I had to bail on the SATA project.
The amazing Garth Beagle once again stepped forward and loaned me his ZuluSCSI for testing, and not long after the also amazing Justin Morgan (who actually donated a GeForce 4 Ti 4600 for my Power Mac G4 way back, so he’s an awesome dude) also allowed me to loan his BlueSCSI F4 XCVR.
Using my original BlueSCSI as the baseline, I set out to begin my testing. If you want to peep the raw benchmarks, they’re on a Google Sheet. I’m missing data for the old F4 XCVR firmware but I’m thinking that’s not exactly relevant, either. Anyway!
ZuluSCSI (v1.1)
This one gave me by far the most trouble. (But also the most speed!)
The ZuluSCSI uses pretty much the same image management system that BlueSCSI uses, so I opted to just take the images I’ve been using and drop them on the ZuluSCSI’s SD card.
This did work, and the 9600 booted fine from the ZuluSCSI! So I set out to begin using the system as I normally world by trying to start up a game of Unreal. What I immediately noticed is that things were…quite unstable. Unreal would throw constant errors. Mac OS was also just generally unstable.
Garth tipped me off that maybe the firmware might need updating, so I looked into it and yes, that might have been it: Apparently the older ZuluSCSI firmwares had issues with images over 4GB in size and here I was throwing a 16GB image at it. Whoops.
(An aside and PSA: Remember in the last part how I talked about how there was a bit of drama and these were originally called AzulSCSIs and they had to rename? Well, the loaner I have here is actually one of those, an original run AzulSCSI 1.1 from before the rename. Why is this relevant? Because if you have one of those original AzulSCSIs and try to update the firmware according to the wiki, your device…won’t update.
This is because the device has no idea what a ZuluSCSI even is, so it completely glosses over ZuluSCSI.bin as a valid firmware file. The trick is to grab the firmware you need and rename it to AzulSCSI.bin, drop it on the root of your SD card, and you’re off to the races.)
You may also find that you still have to do this even with newer firmware. That’s because the bootloader itself isn’t getting updated when you apply updates in this fashion, and the bootloader still thinks it’s an AzulSCSI. Apparently a USB update will update the bootloader to fix this, but it’s something to keep an eye out for.
Once the firmware was updated, things seemed to work better, but now the problem is the 9600 just refused to boot from the ZuluSCSI. Sometimes it’d try, but it’d never make it through the boot, freezing at loading extensions. Usually in this case I can force a boot by turning extensions off (via shift key at boot) but…that’s not exactly what I’d consider reaching the goal.
The weird thing is that the ZuluSCSI would come up just fine in the Finder if I booted from another disk (8.6 CD or the BlueSCSI) but it wouldn’t show up in Drive Setup as an actual SCSI device (even though if I invoked Get Info on the ZuluSCSI’s disk it would show me the right ID and all that). This is both with and without the Apple-centric options set in the ini file and with SW1 flipped, which makes the ZuluSCSI identify itself to the OS as a Seagate ST225 to allow stock Drive Setup to work with it.
On a lark, I tried updating the ZuluSCSI to the latest nightly build (2022-05-25) to see if it changed anything and alas, it didn’t.
Garth suggested something interesting, though: What happens when we put the ZuluSCSI on the second SCSI bus? Because the 9600 actually has two SCSI buses; one internal, and one that’s external but also has an internal connector that shares the same bus. I moved the SCSI cable down to the second bus, got everything ready, and hit the power button…
…it booted right up, no issue whatsoever. What the hell?
So now the ZuluSCSI was working fine. The problem here, however, is that the external SCSI bus on the 9600 goes at half the speed the internal one runs at (5MB/s vs 10MBs, theoretical). So while it still benched very well alongside my original BlueSCSI, it was still half the speed it could be going.
Garth had another idea: He had a third party SCSI card (ATTO ExpressPCI Pro) and suggested to give that a go with the ZuluSCSI: Sure enough, it worked fine, and at full speed (7500KB/s read and 3500KB/s write) with no special accommodations having to be made.
Odd. Guessing there’s a quirk in the 9600’s SCSI controller that trips up the ZuluSCSI because both the BlueSCSI and F4 work fine internally.
(I’ve actually filed an issue against the ZuluSCSI on this particular issue on GitHub. Took a while because GitHub flagged my account and basically softtbanned me but they finally unlocked my account and the issue has been filed
here. Since this post was started, however, I’ve acquired a ZuluSCSI of my own for keeps, so if/when the issue is fixed and/or new firmware is released, I can retest as needed.)
Nonetheless, I can just stick the ZuluSCSI on the ATTO card and tuck it up under the USB card, it fits perfectly and works fine there. Would love to mount it in such a way that allows easy access to the SD card, but the side panel comes off easily enough.
While I had a bunch of headache with the ZuluSCSI, I feel that if one has to stick with SCSI and can’t shoehorn a SATA solution into their Mac (say, for something like an 8100/7100/6100), the ZuluSCSI is really “it” for a high performing SCSI solution. The F4 scores pretty good, but in raw read/write the ZuluSCSI’s advantage just can’t be denied. It’s pretty good.
But it also comes with the disadvantages of having to be fiddled with and configured depending on machines. Most of the time you can get away with just toggling SW1 and it’ll “just work”. If it doesn’t you’re in for a world of hurt.
BlueSCSI F4 XCVR
An odd one, to be sure. This is a BlueSCSI variant made by Androda, and rather than the super compact BlueSCSI design we know and love, this uses a bigger board with more components and instead of using the BluePill board, it uses a BlackPill STM32F411 board. (Which is where “F4” comes from.)
Make no mistake, though: This works exactly like the BlueSCSI F1. Drop images onto your SD card, rename them according to the naming conventions, and you’re off to the races. No configuration required.
Thankfully, this worked very well: Unlike the ZuluSCSI, it worked on the 9600’s internal bus first shot, no finagling around or anything. System didn’t hang, nothing bad happened, etc.
However, also unlike the ZuluSCSI…the speeds–while better than the F1’s by a long shot–fell far short of the ZuluSCSI’s. Using SCSI Director 4 with the very same SD card and images I was using in the ZuluSCSI, I was hitting a ceiling of about 2100KB/s up and down with very favorable seek and access times.
In the midst of writing this out, however, a new firmware was released for all BlueSCSI variants, including the F4. I ran it through its paces and the F4 seems to be hitting a 2MB/s ceiling. Not sure if that’s a limit of the STM32F4 Black Pill, or the firmware. It’ll be interesting to keep tabs on to see if things get better or if this is “it”.
As of right now, I consider the F4 to be a good middle of the road option. It’s dead simple and works well without having to really tweak it to get it working on something like the 9600. It isn’t as speedy as a ZuluSCSI, but as of right now it’s pretty plug and play with no worries. The speed ain’t going to light your world on fire, but it *should* be “good enough.”
(Though in all honesty I’d find the F4 to be an excellent option for the later 68k Macs if you want to eke out more performance from that SCSI bus but feel the ZuluSCSI is overkill. I feel BlueSCSI F1 to be sufficient, but if you want those good read and write speeds…there’s F4.)
Finally, a random note: I’m not sure if the ZuluSCSI/SCSI2SD peeps are out on vacation or something (entirely plausible since this post is going up in the run up to July 4th weekend) but the issue I filed has been sitting for a few days with no interaction. Given the holiday weekend though, I’m willing to give it time (and seeing as the ZuluSCSI is not my main boot device for the 9600, it’s…whatever.)
But I do find it hilarious that one can think “hey, I’m having an issue with my BlueSC-” and next thing you know Eric will be on you like he sensed a disturbance in the force, eager to help. BlueSCSI at least thus far takes the cake for community support.
If the issue with the Zulu gets fixed/there’s updates on it, I’ll be sure to update this post. Would be lovely to have it fully working without the need of a third party SCSI controller!
SATA, finally.
If you want to see the story of getting here, I urge you to read the write up I did on Tinker Different that I linked above.
I had honestly thought this to be too good to be true, but then again, back in the early 00s backwards compatibility was so much better. Something we take for granted today. Also, OS X was still not really catching on in the professional markets due to pro software being slow to adopt OS X.
Oh, and Sonnet was (and still is) a thing, and back then they were a thing that catered to the older Mac market in spades. So maybe it isn’t so “weird” to have SATA on one of these old Power Macs after all, especially when you can run G4s in them if you so please?
Anyway! After going through all the fun times of getting the right EEPROM and getting it onto the SATA card, I expected failure. But nope, it fired right up and mounted the 32GB mSATA SSD immediately (as a PC drive, though). Imagine my surprise being able to step into unpatched Drive Setup and format the drive like it was a native drive to the system. Oh man, this is cool.
I eventually stuck a 128GB SanDisk SSD in and partitioned it 4 ways, 4GB for 7.6, the rest divided evenly for partitions for 8.1, 8.6, and 9.1. This is plenty of space considering these OSes are expecting 10-20GB drives at most.
A fun tidbit: The Mac sees the SATA card as just another SCSI bus in the system. Sure enough, SCSI Director sees it the same way, too. That means we can benchmark it with the same tools and holy moly, this is some speed.
20MB/s read, 25MB/s write, access and seek times a fraction of a millisecond. Oh man. OH MAN.
The best part about all this is that this card just works. 7.6? Yep, it works. (Kind of. Because of the G3 upgrade, 7.6 frequently throws bus errors.) 8.1? Yep. Works. 8.6 and 9.1? Oh yeah.
THIS IS FUCKING AMAZING!
Not only because SATA SSDs are cheap as dirt these days but this unlocks the whole world of SATA for these Power Macs. I have SATA hard drives for days. Would be interesting to see if a SATA DVD-ROM works too, but that’s something for another day (and I need to move the external SATA port to the internal set of pads. Or string a SATA cable through the PCI slots…)
So, what’s the final setup?
Here’s what I’ve got currently connected
SCSI bus, internal
- CD-ROM
- Zip 100
- Open
- BlueSCSI F1 (acting as terminator for right now, no card is installed)
SCSI bus, ATTO card
- ZuluSCSI (16GB backup image and 2GB utilities image)
SIL3112 SATA card
- 1TB 7200 RPM HDD (saturates the bus all the same as an SSD. And big number is good.)
- (Future) SATA DVD-RW drive just for giggles
As of current, that’s the drive setup, and this thing absolutely screams. I have the 1TB HDD with everything on it, with the SCSI buses open for experimentation and such and I shouldn’t have to worry much about anything fun I do blowing back and affecting the installs on the SATA bus. (Contrast to how the ZuluSCSI would get angry if I sometimes got a little too ambitious with things.)
I could keep with an SSD if I really wanted to, but I have spinners for days and because this is a first generation SATA card, short of a small increase in seek times the spinning drives are going to saturate the bus just as easily as an SSD will.
Which frees up the SSD for other things. Say, if I wanted to add it to my MDD (which is something I’m considering!)
But that’s a whole other set of posts that I’m not going to write right now…