After a long journey, I've finally located the fabled Dr. Dobb's
articles written by John Bass detailing his MacSCSI solution for the
original Macintosh 128K & 512K utilizing the original 64K ROM. I have
published the PDF file at this link (Beware it is a 6MB file):
http://www.mac128.com/MacSCSI.pdf
There is complete software driver documentation and the hardware seems
pretty straight forward. This could well be the start of a means to
equip original 64K ROM Macs with SCSI drives and/or flash drives to
replace the failing HD20 hard drives, something that both the Apple II
community and even the Lisa have enjoyed for several years now.
Hopefully, some of the members of the group with software programming
skills might step up to the challenge of helping to adapt the code to
some contemporary options.
Out of curiosity I read the PDF... and I also saw the thread discussion on the 68KMLA. And pretty much the one observation I have here is this, assuming you're actually setting out to remake this thing with modern components:
"What's the point of SCSI?"
Reading the original article it strikes me that the reason the designer used a SCSI controller + SCSI/SASI drive is that said combo would be *much* simpler to run via a brain-dead memory-mapped interface then a "raw" ST-506 controller/drive setup.(*1) Fair enough, but the critical point is that he did *not* use SCSI because "Apple used SCSI". So, if the point is to provide an inexpensive MFS bulk storage device, why muck around with an obsolete and increasingly expensive hardware standard when the same concept could be applied to something more modern?
Personally I'd suggest directly implementing an SD card slot via SPI. An original Macintosh is probably fast enough to directly "bit-bang" it, so it *could* be as simple as mapping an appropriate 5-to-3.3v buffer into the Mac's memory map somewhere. (You could piggyback it into the ROM space like the original author did, for instance.) However, a better idea might be to use a simple microcontroller like a PIC or something to handle the low-level interfacing with the card, and provide a simple buffered parallel interface on the Mac side. Given that there's oodles of example code out there for driving SD cards with microcontrollers it would in the end probably be the much easier-to-program option, since you could easily adapt the code presented with the MacSCSI interface to talk to it, rather then having to figure out how to do the time-critical bitbanging with the main CPU. (That could get really complicated given the Mac's cycle-stealing video system and mouse interrupts.)
A bonus of using a microcontroller to run the SD card is in theory you could have the microcontroller handle "disk images" on a FAT file system rather then directly reading/writing blocks on the SD media. That would make it fairly trivial to "switch disks" if necessary to get around the onerous limitations of the MFS filesystem. You could, for instance, write a small application which would read a list of disk images from the PIC and present them to the user and allow them to select which one would be mounted the next time the driver initialized.
Anyway.
--Peace
(*1 A "raw" setup would probably require a substantially more elaborate host interface using hardware interrupts and/or a DMA controller, as timing would be much more critical then the SCSI setup in which such low-level worries are handled by the intelligent controller on the drive. I'm curious what the "Hyperdrive" used for a host interface, as it apparently used ST/506 drives.)
Eudi, you talking about something along these lines?
This is an IDE adapter for the Atari ST. The ST had only proprietary ACSI for hard drive interfacing out of the box, which are also increasingly rare and expensive.
The board's dead simple component-wise. Single-sided and mostly direct connections from the 68K chip to IDE, with some lines going to a GAL and a NAND gate.
'Course, being IDE and no Mac driver, it's a bit of a show stopper, but thought it worth pointing to as an example of interfacing directly with the CPU.
As long as it mapped to an unused memory address (or was changed to do so) that widget would probably "work" just fine in a Mac. The only real gotchya is of course the software to drive it. Although... if you *were* going with the straight-to-the-CPU approach programming a driver for an IDE device would be quite a lot less complicated and timing-critical then bit-banging SPI for an SD Card slot.
So, yeah, IDE is definitely another option, probably a better one if you don't want to deal with a microcontroller. Hardware would be dead simple, it should work OK with polling IO, and the ATAPI command set is similar to SCSI, so you could use the source code for that "MacSCSI" driver without much tweaking. Use a CompactFlash card instead of an IDE drive and you achieve a "no moving parts" level of modern.
Yay. :^)
--Peace
Thank you for your thorough review of the alternatives.
I think I can simply answer the question in that there already exist SCSI to IDE adapters which have allowed many to convert their Macs to CF. In more practical terms, SCSI is a well known standard for 68K Macs and drives are still widely available.
While my engineering abilities are mostly limited to building a device from a plan, I have ZERO understanding of writing machine code, or any software, really. There seems to be a dearth of those with this experience who are still actively participating in the vintage Mac community, unlike the Apple II world.
This then is the simple truth of it. There is no one stepping up to really design a more modern storage interface for the Mac (which would certainly have a broader universal appeal among all 68K Macs), so those of us who find this project of interest must make due with whatever we can find.
Also, while I do not know what John Bass was thinking, is it mere coincidence he had the right idea at the right time? I suspect his designs were the basis of many such commercial products such as the Dove MacSnap SCSI adapter. Certainly at the time Bass was designing his interface, there was substantial rumoring about Apple's inclusion of SCSI in the Mac Plus, I seem to remember an '85 article about it over at MacTech in the old MouseHole articles.
In pointing out the alternatives to SCSI I was basically making the point that in the context of a 128k/512k Macintosh SCSI was not a "standard" for Macintoshes. And thus, if the explicit goal is to design a homebrew mass storage system for those machines which uses modern components SCSI is actually a superfluous complication. If you cut SCSI out of the equation then you can just go straight to using parallel IDE or flash memory hardware without the expense of SCSI-to-IDE-to-Flash-to-Whatver converters. ;^)
I guess I've gotten the impression from your postings that your philosophy regarding the 128/512k machines is that you place substantial value on *not* changing out the ROMs for the later 128k 512ke/Plus versions. If changing the ROMS were an option then clearly a better solution then building the "MacSCSI" board would be to do a piggyback board which duplicates the memory mapping location of the Mac Plus SCSI port. It appears that's what the old Dove MacSnap SCSI card (and others, like the Mac Rescue board) did, allowing an upgraded machine to for all intents and purposes perfectly emulate the capabilities of a Mac Plus with no software hacking.
The memory addresses used by the Plus SCSI controller are documented. (A little googling will find them.) Making a little board to decode them and piggyback into the ROM sockets would probably be a trivial job. You could steal the controller chips and ROM from a donor Mac Plus easily enough... but then, you might as well just swap motherboards and case backs and call it a day. Which I think points to the basic problem of motivating anyone to invest the time in building such a board. How are you going to compete in price with used Mac Plus motherboards? (Or used Dove SCSI boards, Mac Rescues, etc.) The problem of putting SCSI into a 128k/512k Mac has already been solved, so why reinvent the wheel again? Designing custom interfaces to put hard disks/flash memory into machines like Apple IIs/Ataris/whatever adds real functionality you can't achieve with original equipment parts. The MacSCSI port does *not*. (After all, as you pointed out you can already add flash with an off the shelf SCSI-to-IDE adapter, so why not add your SCSI port via the same route?)
Anyway. That's why I think you might as well shoot for a direct IDE or SD Card port. It would add "unique" functionality and thus be a lot more interesting to work on then a SCSI board. ;^)
--Peace
OOPs-double post goofup!
jt
Isn't there an IDE HDD-on-a-card for the Apple II?
My suggestion for 68000 upgrades would to be to watch for the "NewLife Accelerator"which was VERY cool back in the day! IIRCit turned a FatMac into a 512Ke++ the extra pluses beside the "e" designation for SCSI, were an increase in RAM capacity to 2.5MB on my 512K by utilizing the MoBo's on-board RAM and adding some SIMM slots.
The other plus was output for a TTL Monitor sticking out the battery hatch, I never found out if they ever implemented the monitor driver as it never worked for me. I later loaned FatMac out to my wife's Aunt and didn't have the sense at the time to say "yes" when she offered it back to me later on. =8-[
I didn't trust myself to do the solder a 68000 socket onto the legs of my 512K's CPU (the included Killy Klip wouldn't work on the package type of the 68000 on my FatMac's logic board) so I bought a used 128K MoBo and butchered that one instead. IIRC, I still have the Docs and drivers in a box somewhere around he . . .
. . . or they might have been lost along with all my large tools in my "Storage Room fiasco." God, do I ever miss that 4'16 Gauge Box & Pan Brake and matching Notcher.
IIRC, a Mac Plus's ROMs were required. At any rate, Google "NewLife Accelerator" + "512K Macintosh" just for $#!&$-n-giggles! Meanwhile I have to sign off before they drag me bodily out of Panera Bread any second now!
jt
I completely agree with everything you say and genuinely thank you for it.
Particularly the part about the "unique" functionality of a direct IDE or SD card. Sadly that is the extent of my abilities, agreeing it should be done!
And you correctly put your finger on the issue, I prefer to keep the 64K ROMs preserving the 128K & 512K software compatibility as much as possible.
I don't agree the MacSCSI is re-inventing the wheel, after-all it implemented SCSI on the Mac before Apple did. I further suspect if John Bass were contacted, he might well have the original software code in his files for the drivers for any number of competitively priced standardized SCSI drives available after the Plus hit the market (as hinted in his article). After all, the only way to officially get the 128K ROMs from Apple was to purchase an expensive 800K drive, or Plus, upgrade kit. That would have opened up a sizable market in 1986 & 87 for Bass and the MacSCSI licensors to upgrade 128K & 512Ks to take advantage of a hard drive as well as preserving the investment. I'm certain the Dove and other boards requiring the 128K ROMs were targeted primarily at the 512Ke.
I guess I was hoping that this article offered an easier solution than it does, but like many obstacles in the vintage Mac community, it boils down to 68K programming for which there is a decided lack of enthusiasm. While I would welcome a new viable MacSCSI driver for a contemporary drive, I would just as equally welcome the IDE or SD solution you propose.
Switching to 128K ROMs shouldn't affect compatability, IIRC.
The NewLife I installed was targeted at the 128K & 512K, NOT the 512Ke! As I'd said, I actually installed it on a 128K MoBo.
Hence, my suggestion that you look for the NewLife accelerator, maybe If I can find the Docs & Disks I can make a convert of you!
. . . or not! ::)
http://www.google.com/#hl=en&q=%22NewLife+Accelerator%22+%2B+Macintosh&fp=KqtEvp1-d7s
jt
p.s. IF you ever do find one and don't wish to acquire it, PLEASE send me a private message!
I WANNIT! I WANNIT! I WANNIT!
While I understand your desire to retain the original ROMs since, after all, that's what really distinguishes an original Macintosh from it successors (and is what makes it a "Museum Piece"), I have to think that it's actually sort of a straw dog when it comes to software compatibility. *Any* mass storage device shoehorned into a 128K/512K is going to require a software driver which badly behaved original Mac software isn't likely to get along with. The Hyperdrive didn't work with every piece of Mac software, and of course the HD-20 driver basically gave you a soft-upgrade to the 128K ROM anyway.
(For that matter, is there any early mac software out there that's definitely known to *not* get along with the Mac Plus/512Ke hardware/ROM? I'm pretty sure they'll boot even the earliest System versions, so the compatibility must be pretty good. Obviously the hard disk in the Plus won't work with a pre-Plus System version, but that problem doesn't demonstrate any *ROM* incompatibilities.)
When I said "Reinventing the wheel" I wasn't applying it to the original invention (John Bass' board was certainly "around" first), but in resurrecting the hardware now *after* the introduction of the "Official" Mac SCSI port. Why I say this...
I suspect there really wouldn't be as big a "market" for this as you might think. After all, a couple points:
A: In the grand scheme of things, the 800K drive upgrade including the 128K ROMs wasn't that expensive. Apple sold it for $299, which compared to the $2500 or $2800 that a Mac/Fat Mac sold for it looks like a downright bargain. (After all, the original external 400K drive was priced at $495, again making the upgrade look pretty cheap.) Since anyone who was *seriously* using a Macintosh would probably already have a 512K RAM upgrade (either official or homebrewed) as well it seems pretty reasonable to say that upgrading to the 512Ke standard was the right base to start from when seriously modernizing an early Mac.
B: A side effect of getting the 128K ROMs in the disk upgrade was that you gained direct no-floppy booting of an HD-20 if you'd already bought one (meaning the upgrade still had value on top of the 800K drive), plus you gained the SCSI driver to support a third-party SCSI board which mapped the SCSI chip to the same addresses as the original. After discontinuing the HD20 Apple themselves essentially endorsed third-party SCSI ports as the only way to add a hard disk to these units without springing for the Plus motherboard upgrade.
In short, it appears that really the "right" way to add a Mass Storage device to a 64K ROM'ed Mac is to upgrade the ROMs. All commercial third-party boards manufactured after the Plus' introduction made the ROM upgrade a prerequisite, and with the ROMs widely available as part of a reasonably-inexpensive disk upgrade that you'll probably want anyway, well... the writing is sort of on the wall, there.
To give John Bass some credit I do wonder if the Dove SCSI board was inspired by his design. (As it also piggybacks off the ROM sockets rather then under the CPU.) A Dove-style board shouldn't be much more complicated then this one... I was about to say it would require slightly more decoding hardware because Bass uses a somewhat skanky shortcut to derive read/write select signals directly from an address line, but reading the Macintosh hardware information here makes it look like that Apple did the same thing! To quote:
That's... eerily similar. The address tables line up pretty nicely, other then that Apple's unit moves a significant digit one bit over in order to differentiate two different data transfer methods with the last bit, and John Bass' card places the base address at 0x5000xx while Apple used 0x580xxx.
So... yeah. Making John Bass' original design makes no sense. Make a Dove card instead. It'll require about one more IC for decoding that last bit, and with 128K ROMs you get a SCSI driver for free.
You're just not going to get away from having to program if you want to use "simple hardware" that *doesn't* emulate some existing hardware device. Emulating an existing hardware device by necessity means more complicated hardware (and most likely programming a microcontroller or FPGA). I do think the "Mac Community" does suffer from the fact that seems that many (most?) of its participants are basically non-technical people in it entirely for nostalgia. This unlike the remaining Atari/Commodore/whatever users, who are much more likely to be "tech types" prone to considering assembly-language hacking the whole point of the exercise.
For mass storage on a 64K ROM Mac the only existing hardware with a readily available driver to emulate is the HD20. Which probably wouldn't be *that* hard to recreate if someone were willing to build a protocol analyzer to go between a functional Mac and an HD20. The IWM floppy controller is basically the same as the Apple ][ disk controller electrically, and there are floppy emulators that work with the Apple ][. Putting the pieces together should be doable for a hard-core hardware hacker. A device roughly as complicated as the SVD should be able to emulate the HD20 once you know how to talk to it. But, yeah, figuring all that out would be a lot of work.
Alternatively, if you're willing to program, well, you can hang whatever you want off an old Mac, within reasonable limits, with just a few ICs. (Don't ask me to do the wiring unless you want your house burned down, however.) If you really think it's worth the effort to have something like this and want to get your feet wet before thinking about ICs and printed circuit boards I have a simple suggestion for you: Assuming you can find a copy of the Aztec compilers the Bass code is using (I googled and had no luck), port the code in the article to target a Mac Plus running System 4.1 with an attached SCSI drive. The hardware is *very* similar. I've been trying to exercise my brain looking at the source code in the pdf, and it looks to me like if you were to change the constants and offsets in "s1410.c" to match the Mac Plus addresses (compare the address tables in the .PDF to the Mac hardware reference I pointed to earlier) you'll be overwriting sectors on an attached hard disk in no time. With that under your belt you can start thinking seriously about hanging a novel IDE or flash-based storage device off a ROM piggyback card. (Or, alternatively, let you do SCSI on a 128/512k equipped with a Dove card or similar.)
(If I had a copy of the Aztec C environment Bass was using I'd almost be interested in trying this myself. I don't have the hardware but MESS has a "real" NCR SCSI chip emulated in its Mac Plus driver now that does block-level IO to an image file. Not that I really have the time, but it could be... fun.)
--Peace
Just as an aside, John Bass was apparently actively perusing copyright restrictions on his code back in 1986. Chances are he doesn't give a damn now, but just maybe you might want to use the DDJ code as an *example* while writing your own if you plan on distributing it. It's not open source.
Not really relevant or anything, mind you, but an interesting reminder that "free to use" does not necessarily equal "free to talk about".
--Peace
All good observations. I did not realize the 800K upgrade was so inexpensive. Surprising. To take that kind of markdown, Apple really wanted to drop the 400K/MFS standard didn't they?
Your suggestion about adapting the code to a Plus first makes good sense. But as I surmised earlier, even finding the proper compiler is going to be a challenge.
Also, good point about the copyright. I can think of no better result than having John Bass come out of the woodwork to stop us! LOL Perhaps then we could get the results of his work compiled and adapted for a small fee. Certainly if one could find and contact John Bass to ask for permission to distribute any resulting code, one would, which of course bodes well for the community producing it to begin with! For all practical purposes this falls into the territory of abandonware. But I would certainly tread lightly on creating anything commercial from this code.
I seem to mistily recall reading in magazines dating from the era that Apple imposed strongarm tactics on its resellers/service departments to ensure that the 800K upgrade was only performed by "authorized" personnel in an attempt to ensure that the "trade-in" 64K ROMs didn't remain in the wild and provide a possible route for building unauthorized/homebrew clones. (Or, equally sensibly, to make sure that an unauthorized cloner wouldn't be able to simply spend $299 a head buying upgrade kits to get modern ROMs + a free floppy drive with no strings attached.)
But, yeah, you can't blame Apple for wanting to get MFS/400K drives out of circulation reasonably quickly. It's annoying for software vendors to have to worry about distributing software on two different media formats (or having to restrict themselves to some least-common-denominator), it annoys customers to have to think about disk compatibility problems when swapping data... etc.
Getting a good development environment set up to target "ancient" versions of MacOS is indeed going to be nontrivial. Additionally, Apple has pretty much expunged anything of interest to pre-System 7 (and really, pre-OS 8.6) programming from their website, so in addition to needing the software you'll probably want a good set of books.
Just for kicks and giggles I did install the Macintosh Programmer's Workshop, on a System 7.5.5 BasiliskII emulator image and played a bit with some of the sample code. (I couldn't find any complete C development environment any older then that.)
One thing that's really annoying is that Apple apparently took it upon themselves at some point to convert *all* the legacy sample code on their legacy developer FTP site from MPW format to Metrowerks. (Which does not appear to be freely available anymore.) I downloaded a sample RAMDisk driver from the FTP site to try to get a feel for what a Mac device driver looks like, but it'd been Codewarriorfied. About an hour of futzing and semi-educated-guesses got the C sections compiling cleanly but the inline assembly in the "main" section is broken. (The syntax isn't right for MPW and it also seems to refer to some globals in an include file that MPW doesn't have.) Being neither a Mac nor 68K assembly language programmer and having at best a casual interest in the problem I'd say I'm out.
(The other discouraging thing I discovered in idly poking is that the SCSI hardware emulation in MESS, while "there", seems to be pretty fragile. Attempting to initialize a virtual hard disk with any System version prior to 6 crashed the emulator with a Segmentation Fault. Forget that as a serious development platform.)
I guess the one last avenue I'd suggest if you ever got beyond the daydreaming phase would be to investigate the .Sony driver replacement ROM patches that BasiliskII and vMac use to provide disk access. vMac's ROM patch works even on the 64k ROM sets. In *theory* I could see a way to completely slam-dunk the driver problem would be to design a ROM socket-based microcontroller-controlled Flash-interface "universal" mass storage device. (Ideally the microcontroller would have rudimentary FAT file system support and be able to map disk accesses to image files.) Said ROM socket device could also contain a chunk of memory (EEPROM, Flash, or even Static RAM) into which would be loaded a patched version of the Mac ROM, allowing even an original 128K Mac to boot directly off a suitable disk image file. It sidesteps the entire OS driver issue and a good chunk of the work is already done. (And if you could find someone to build the hardware there's a good chance you could get someone who contributes to the vMac or BasilikII projects to help you with the software side.)
An interesting side effect of such a device would be that you could easily, say, convert a Mac Plus into a "Super Fat Mac" by loading an alternative 64K ROM image. (Or, let you do the reverse and upgrade a 128K to 128K ROMs and downgrade it again without ever cracking the case.)
--Peace
I did the MacSCSI hack in an evening simply because I was way frustrated using MacDraw from floppy. At that time I had met with other Mac Developers at Apple under MacSEF (Mac Software Entraprneur Forum), and we all shared the same speed frustrations, even from the Profile hard drive that was connected via the external floppy port and was very expensive. I don't have any of the original files easily available, in fact they might well be lost to history other than what I published in DDJ.
If you have watched the Steve Job's movie, you will notice that Steve was ABSOLUTELY firm that the Mac was a closed system, and was NEVER to be opened, hacked, etc. The only exception to this was a vendor that did an MFM drive controller inside the Mac512 case, and was something Steve and various internal developers used. While a number of developers had one of my scsi boards before the DDJ article hit the street, the DDJ article publication was the first time Steve had heard of my SCSI hack. He went ballastic and I was later told that he called an all hands Mac engineering meeting because of it, that created the MacPlus product 3 months in front of it's introduction . Crazy fast development cycle for Apple, simply because of the DDJ MacSCSI article hack made them look stupid. Nobody had considered using the ROM sockets as a clean interface to the M68K address and data lines prior to that, and all that I needed was one more signal from the CPU for easy decode. The NCR5380 was a band new chip in the market, and the MacSCSI design pretty much drove Apple to it as an easy integration and very low cost.
An Apple II upgrade vendor contacted me, and wanted a MacPlus compatable version of the design ... he already had approval to get a MacPlus at the Jan show, so we met in a hotel the night before, where I had access to reverse engineer the MacPlus scsi interface decodes with an HP logic analyzer. Before the show I did a simple NCR5380 generic design using a 3M M68K test clip, mounted with standoff's under the processor board and cable exiting the case. We blue wired a dozen boards that ran error free using the Apple 128K scsi roms, and we introduced a Mac512 SCSI upgrade fully software compatable with the MacPlus the same day that the MacPlus was announced at the show. That same day I had 100 clean boards fab'ed with the MacPlus decodes, and he was selling them at the show.
All of this really pissed Steve off, and I was blacklisted at Apple, and not allowed in the building anymore.
To twist Steves nose a bit, I leaked a rumor that we had a M68020 replacement board for the Mac128/512/Plus which had sockets for Apple's ROM's and proprietary chips desoldered from Mac512 surplus boards. I had actually done the paper design, and board layout ... it was really tempting at the time to see what legal recourse Apple might try.
The response was an M68020 design in the MacII series a while after.
Anybody have the MacSCSI.pdf file?
John Bass
Sr Engineer
Formatting fixed - Tom
I assume it was just the articles from the September and October DDJ, which is available on Archive.org:
https://archive.org/details/dr_dobbs_journal_vol_10/page/n721/mode/2up
Though I haven't been able to track down the original file, so I can't tell for sure.
I've been trying to put together the design and code, but either I'm stupid or it's missing np_chk.c, mountscsi.c, and bootscsi.c.
Well, John, if you are the reason that Apple pushed its release of the MacPlus; congratulations!
The 128K and FatMac were fun; but without hard drive storage, basically still a toy.
I had gone from my Apple ][+ to an Apple //c in 1984 and waited for the Mac to mature a bit more until I purchased an SE/30 for my first Mac in the late 80s with some money I made on Adobe stock.
But earlier, when I saw the release of the internal Hyperdrive 10MB 512K Mac, I pounced and purchased one with an Imagewriter II printer for my parent's business.
My mother would type hundreds, if not thousands of mailing lables twice a year to get out their price lists to customers.
I arrived with the FatMac-Hyperdrive, and OverVue software and told my mother she would only have to type out all those addresses one more time! Then just add new ones and update old ones, as needed.
When the Mac Plus came out, we got one for the desk of my cousin who did the books and I networked the two of them together. That way, the Plus without an external hard drive could function to work on both the mailing list, as needed (one person at at time, of course) and do some word processing and financial work.
I remember General Computers had much trouble with the 20MB version of the Hyperdrive, eventually offering a steep discount to those customers of their newly released 20MB SCSI Hyperdrive.
Damn, if that machine didn't function well into the late 90s until one day it just died! R.I.P.