5 ms·
TBF even golden era macs had standard SCSI drives but with custom firmware so you couldn't just use any old drive.
by NikkiA 2y ago
TBF even golden era macs had standard SCSI drives but with custom firmware so you couldn't just use any old drive.
- tambourine_man 2y agoI don’t remember that. I upgraded several SCSI drives back then.
- snakeyjake 2y agoThe custom firmware (really just a magic string) was required for "Apple HD SC Setup" or the later "Drive Setup" to recognize, partition, and format the drive. In order to upgrade the hard drive in a classic 68k or PPC Mac you had to either buy an Apple drive, or buy a third party disk utility capable of setting up a non-Apple drive. Many Apple-specific retailers would bundle in the software needed to use a new hard drive with the purchase of one but you'd better believe they baked the cost in to the price of the drive. If all you had was a Mac, your System disks, and a new non-Apple hard drive you 100% could not use it. I used FWB Hard Disk Toolkit, but it was >$100. Both Apple HD SC Setup and Drive Setup have been patched by the retro community to work with any drive, but in the 80s and 90s this was not the case.
- detourdog 2y agoI definitely used FWB but never experienced the need for magic strings or thought FWB was required. Third party disk utilities could often recover files Apples tools could not.
- snakeyjake 2y agoThe user doesn't need the string the Apple software scanned the ROM of the hard drive and looked for specific vendor IDs before proceeding. For the most part (there were EXTREMELY rare exceptions) the only strings that would pass were specific custom models of widely-available drives that were only sold to apple. FWB did not check. You could use ResEdit to haxxor the list: http://www.euronet.nl/users/ernstoud/drvsetup.html http://www.euronet.nl/users/ernstoud/drvsetup.html I cannot believe that page is still online. I first referenced it ON a PPC Mac running netscape. My flabbers are gasted.
- tzs 2y agoEarly versions of FWB did do some checking. It wasn't nearly as picky as Apple's checks for specific drive models, but it did check for several manufacturers. That's because there were vendor specific settings that it wanted to set and some vendor differences in getting some information. There was support for a generic drive but there was a compile time option that controlled whether or not it allowed it and I don't remember what that was set to on release builds. Source: I worked at the contracting company that wrote FWB's early versions and am looking at the source right now to jog my memory. :-) (My current employer owns the IP of that contracting company and knows and is OK with me having these ancient files). Here's the command dispatch table from mid 1990 to show what drives it recognized and which ones needed vendor specific routines. struct command_switch { int (*read)(); /* read command */ int (*write)(); /* write command */ int (*format)(); /* format device */ int (*findsize)(); /* find limits of device */ int (*setup)(); /* setup device paramters */ int (*verblock)(); /* verify track */ int (*ready)(); /* test unit ready */ int (*rezero)(); /* rezero */ int (*reassign)(); /* reassign block */ } CmdSwitch[9] = { { OMTIread, OMTIwrite, OMTIformat, OMTIfindsize, OMTIsetup, OMTIvertrack, OMTIready, OMTIrezero, OMTIreassign }, { SEAGATEread, SEAGATEwrite, SEAGATEformat, SEAGATEfindsize, SEAGATEsetup, SEAGATEvertrack, SEAGATEready, SEAGATErezero, SEAGATEreassign }, {/* QUANTUM */ SEAGATEread, SEAGATEwrite, SEAGATEformat, QUANTUMfindsize, QUANTUMsetup, SEAGATEvertrack, SEAGATEready, SEAGATErezero, SEAGATEreassign }, {/* CONNER */ SEAGATEread, SEAGATEwrite, SEAGATEformat, CONNERfindsize, nulldev, SEAGATEvertrack, SEAGATEready, SEAGATErezero, SEAGATEreassign }, {/* WREN3 */ SEAGATEread, SEAGATEwrite, SEAGATEformat, QUANTUMfindsize, CDCsetup, SEAGATEvertrack, SEAGATEready, SEAGATErezero, SEAGATEreassign }, {/* DEFAULT */ SEAGATEread, SEAGATEwrite, SEAGATEformat, GENERICfindsize, nulldev, SEAGATEvertrack, SEAGATEready, SEAGATErezero, SEAGATEreassign }, {/* SyQuest */ SEAGATEread, SEAGATEwrite, SEAGATEformat, SYQUESTfindsize, nulldev, SEAGATEvertrack, SEAGATEready, SEAGATErezero, SEAGATEreassign }, {/* Sony optical */ SEAGATEread, SEAGATEwrite, SONYformat, SONYfindsize, SONYsetup, SEAGATEvertrack, SEAGATEready, SEAGATErezero, SEAGATEreassign }, {/* Ricoh optical */ SEAGATEread, SEAGATEwrite, RICOHformat, RICOHfindsize, nulldev, SEAGATEvertrack, SEAGATEready, SEAGATErezero, RICOHreassign }, }; I know this is from 1990 because somehow the timestamps on the files have survived. Those files went from a Mac II to a Centris 650 to a series of PCs (with Windows or Linux) to a Power Mac G5 to an Intel iMac to an Intel Mac Pro to another Intel iMac and finally to a Mac Studio. Somewhere along there resource forks got lost, and the project files for whatever compiler I was using in 1990, but still I'm surprised at how much is still around.
- tambourine_man 2y agoYou’re right, there was a magic third party utility. I even remember its icon now, but can’t remember the name. It wasn’t FWB, to my recollection.
- projektfu 2y agoThey were upgradable but the Apple hard disk utility would only format Apple drives. There were several third party utilities and they were usually bundled when buying e.g. Quantum drives, but if you took a drive from elsewhere you'd have to have a copy of the utility. If there was custom firmware, I think it was just the model ID or some other license key system.
- detourdog 2y agoMy experience was the same as you. SCSI drives were swappable. I also remember many claims at the time that they required special firmware.
- endemic 2y agoI maxed the RAM and HDD on my 2010 Intel MacBook Pro -- using standard parts! Really kept that machine going for a long time.
- accrual 2y agoNice! I had a maxed out 2015 MBP and that too lasted a long time. After Mojave, it started to really show its age though.
- throw0101d 2y ago> […] with custom firmware so you couldn't just use any old drive. Commercial storage systems (appliances, SANs) also have approved firmware versions (though not necessarily custom) as there are things like firmware bugs. Supposedly some of the things that ZFS has found is SANs that should 'know better' doing dumb stuff like retrieving the wrong LBAs: the checksum according to the SAN is correct, because it is data+cksum in one sector, but it was the wrong sector that was read. ZFS caught this because its checksums are in the parent directory structure and not tied to the data blocks themselves. This also catches things like the two sides of a mirror being out of sync.