Thread
MacSCSI by John Bass AT LAST!
After a long journey, I've finally located the fabled Dr. Dobb's articles written by John Bass detailing his SCSI 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).
The hardware seems pretty straight forward, but I have no idea how to go about compiling the code in any useful way. The code appears to be v.1.0 though it is reported as fully functional at least within practical application with some known bugs. The final article is published December 1985 and hints at an impending v.2.0 release, though there is no other evidence that this was ever published anywhere. It may well be that the release of the SCSI equipped Mac Plus the following month diluted the interest in this particular solution, or Bass took the whole enterprise private (as I'm sure there was a market for adding SCSI to the original Macs when the 128K ROMs became difficult to obtain). Either way this appears to be the end of the road for 64K ROM SCSI solutions, but if the collective army's brain-trust can come up with an effective implementation, it 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.
Note the effective disk and file limitations. Whatever the outcome, this is a fascinating look at the thinking of the Macintosh pioneers!
The hardware seems pretty straight forward, but I have no idea how to go about compiling the code in any useful way. The code appears to be v.1.0 though it is reported as fully functional at least within practical application with some known bugs. The final article is published December 1985 and hints at an impending v.2.0 release, though there is no other evidence that this was ever published anywhere. It may well be that the release of the SCSI equipped Mac Plus the following month diluted the interest in this particular solution, or Bass took the whole enterprise private (as I'm sure there was a market for adding SCSI to the original Macs when the 128K ROMs became difficult to obtain). Either way this appears to be the end of the road for 64K ROM SCSI solutions, but if the collective army's brain-trust can come up with an effective implementation, it 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.
Note the effective disk and file limitations. Whatever the outcome, this is a fascinating look at the thinking of the Macintosh pioneers!
I was going to edit my post above to include relevant links to other threads concerning this topic, but new forum rules no longer allow that. My apologies for any multiple posts which follow as I locate subsequent links. This post represents the culmination of this thread originally started by Charliman. Here's another a related thread.
MPW is no help?
For those of you uninterested in Googling up cryptic acronyms you do not understand (like I did just this morning), I assume that porter is talking about the Macintosh Programmer's Workshop.
For me no. Assuming I could create compiled stand-alone file with it, in particular I run out of steam when contemplating how they would interact with the System & Finder. Also, is there an application here, or does it simply get called by the standard Finder and System disk drive routines? Perhaps someone with more experience with this sort of thing will be so kind as to help implement it.
What I did discover is that the NCR 5380 SCSI chip he uses is identical to the one included in the Mac Plus. Also, the XEBEC driver interface he uses seems to use the basic and most common SASI, legacy SCSI-1 standards.
Perhaps I am jumping the gun, but this hardware should act identically to the Mac Plus SCSI interface, possibly down to the SCSI driver in the Plus ROM. However, I doubt it will allow a 512K to boot from a SCSI device. But once the hardware is in place, shouldn't I be able to use something like the ZIP 4.2 driver to access a ZIP on the bus?
The traditional way of doing drivers was to compile code as a code resource of type 'DRVR' and use resedit to paste it into the system file.
I've not had a chance to look at your PDF yet, Mac128, but I'm sure that I'll enjoy.
Porter is correct in that the source needs to be compiled as a DRVR resource for insertion into a System file. Plus we are working with the lowest SASI/SCSI definition and Apple II enthusiasts have given up fighting against NCR 5380/SASI/XEBEC. We can learn a lot about the Mac 128 and 64KB ROMs from the Bass project, but only use it as a base point.
From my old notes:
Fastime MacSCSI
The September 1985 issue of Doctor Dobb's Journal published an article by John Bass describing a SCSI interface board for the 128 and 512K Macs. The article included schematics for a basic board and sample driver code. Judging by postings on Usenet, many technically able Mac enthusiasts used the design as the basis for their own controllers and kits were sold by a company founded by Bass called Fastime. The Bass design was also licensed by companies (Warp 9 and Mirror Technologies).
** Check whether Warp and Mirror really were the same company.
Porter is correct in that the source needs to be compiled as a DRVR resource for insertion into a System file. Plus we are working with the lowest SASI/SCSI definition and Apple II enthusiasts have given up fighting against NCR 5380/SASI/XEBEC. We can learn a lot about the Mac 128 and 64KB ROMs from the Bass project, but only use it as a base point.
From my old notes:
Fastime MacSCSI
The September 1985 issue of Doctor Dobb's Journal published an article by John Bass describing a SCSI interface board for the 128 and 512K Macs. The article included schematics for a basic board and sample driver code. Judging by postings on Usenet, many technically able Mac enthusiasts used the design as the basis for their own controllers and kits were sold by a company founded by Bass called Fastime. The Bass design was also licensed by companies (Warp 9 and Mirror Technologies).
** Check whether Warp and Mirror really were the same company.
Whether it be SCSI, processor-direct or another means, I would love to have an INTERNAL CF card flash drive in my Mac 512 (or 128) that is compatible with the 64k ROMs. Just slip a 32MB flash card in and go! Even if it needed to be partitioned into "drawers" like the old internal Hyperdrives, it would be fun to have. It would be super quiet, quite fast and would draw virtually no power. It would put off no heat and put no strain on the power supply. I see these sort of things all the time for the Apple II. Hobbyists put these things together, for goodness sake. Yet there is nothing like that for old Macs. Yes, I am aware the Apple II has slots. And yes I am aware its "easier" to program for the Apple II. But is the Mac "that" much harder?
For certain values of 'old'.
There are IDE to SCSI, and CF to IDE, so for Mac Plus onwards there is a solution.
Porter, I specifically mentioned "64k ROMs" in my last post, which indicates the "old Macs" I was speaking of; namely, the original Mac 128k and Mac 512k (not the 512ke). Indeed, Mac128 is also focused on something that would work with the original 64k ROMs. The old 64k ROMs are the keypoint here. We all know we can do many things with the 512ke and onward. The point here is to do miracles with the older 64k ROM Macs.
Was the protocol used by the HD20 ever made public? To be in keeping with the original machine you should hang a disk from a serial port.
No. We've been over that in the related HD20 link referenced above. That's the whole idea here to ultimately replace the failing and increasingly rare proprietary HD20 Rodime hard disks, not to mention giving the 128K a hard disk option it can use.
When you say hang a disk from the serial port, that was the recommended method by Apple. However, third party companies immediately saw the advantage of using the floppy disk and they along with Apple offered solutions, some for the 128K. The HyperDrive took another more destructive path attaching directly to the 68000 chip, which also required a 512K RAM upgrade. All of this was contemporary to 1984. Bass' solution is elegant as well as being a contemporary solution, not to mention simply adding SCSI to the original Macintosh which lays most of the groundwork for taking advantage of those methods to which you allude available to the Mac Plus onward (Actually the 512Ke can use a commonly found commercial SCSI board in conjunction with the 128K ROMs to add SCSI functionality). The greatest challenge on this board is that there seems to be very little 68K programming going on as compared to other boards like the Apple II. Therefore, we need ready made solutions like this which can be more easily be tweaked to meet our needs in the absence of a dedicated software engineer. Adapting the HD20 interface to accept a flash drive would likely be a significantly more substantial project, even if someone went to the Stanford Library and were able to find the original HD20 documentation in the Apple archives, not to mention it would not return the numerous benefits of SCSI. With very few exceptions, if they only had more RAM, there is nothing the 128K & 512K can't do that the Mac Plus does, except SCSI.
There's one possibility that occurs to me: the "FlashPath" is a floppy disk shaped adapter for SmartMedia flash cards, which goes into a floppy drive. Sony made them for their floppy-based Mavica digital cameras. I have no idea if they require drivers on a Mac - ISTR they needed them on PCs. If they do require drivers, then they would not be bootable and would need to be used with a second internal or external floppy drive - if Mac drivers even exist. And they will be slow. They also may not be compatible with 400k/800k drives.
Still, worth looking into perhaps?
Apart from that, seems to me someone needs to get busy with a microcontroller and the serial port, or a logic analyzer and reverse engineer the floppy drive connection protocol.
The main problem with this is, I've never seen one. How readily available are they?
And the main problem with this is the "somebody" part. And like the FlashPath which would need a custom driver written for it, the floppy/flash would require hardware be built as well.
From my limited viewpoint, it seems to me we are closer than ever and need look no further than the John Bass solution for that somebody to write a driver for a contemporary drive interface. Think of it, not only is this a completely engineered solution but it has value as a SCSI interface, not some third party proprietary solution that has no practical applications outside of this limited one, including potentially using an EN/SC adapter on it to bring true Ethernet to at least the 512K. If "somebody" were going to put any time into this project it seems to me like this would be the one to focus on. Thanks again to Charlieman for having the insight to suggest it in the first place.
Here's one if you want to try it. No idea how regularly they show up. Not even that sure how I found mine, or where it is now :?:
I suppose so - the 64k ROM Macs won't take 1.4MB floppies in the first place, will they?
I agree wholeheartedly that this is the most promising starting point:
*emphasis mine
Indeed it opens the way for the various SCSI to xxx storage solutions, including perhaps ordering the ACARD SCSIDE chips and buiding it all on a single board. And given the fact that it uses only two read/write memory locations, and the available source code listing, perhaps it can even be a starting point for a direct flash drive interface.
I was just throwing suggestions out there for anyone who might be interested to follow up on. It's not my place or yours to prescribe or proscribe what "someone" might want to work on, and I apologise if my wording implied any disparagement of this solution.
Correction via Wikipedia:
By the power of the Wayback Machine, I was able to find drivers and manuals. Driver requires PowerPC :-/
Yes and I thought this had been discussed elsewhere before, but could not find it. You are correct in that any Mac with an IWM chip cannot use a 1.4MB drive. I'm not sure that this device would actually require a particular type of disk, but most likely it does. However, the most problematic detail about this drive is that it is read-only. So it would not make a very practical storage medium, even if a 68K driver could be written.
Have you priced the 53C80 these days? I don't think they're all that readily available.
Then again, if only ten people are ever going to want the solution, I guess it doesn't matter if the chips are $10 each.
However, if someone does decide to program up a new driver solution, that person may wish to consider contacting me. I have a brick of over 500 53C96 SCSI chips and I'd be happy to donate up to 100 of them to such a project. If one went that route the driver guy would want to code for the 53C96 instead of the 53C80. Altering the hardware design would probably be trivial.
In most of the projects the hardware is mostly trivial, though somewhat expensive to design. It's getting the software drivers written and figured out that's tough. We do seem to lack devoted software hobbyists.
Buy an old Mac Plus and desolder the chip.....
Heresy! Get the torches! Get the pitchforks! Where do you live again?Buy an old Mac Plus and desolder the chip.....
Whereas butchering a 128k with a hardware mod isn't?
"Butchering"? Are you referring to this project of adding a SCSI adapter board to a 128K?Whereas butchering a 128k with a hardware mod isn't?
People are welcome to do what they like with their own property, but yes, adding a SCSI adapter to 128k is a devaluing operation. It's technically interesting and challenging, you may slightly increase it's utility, but at the price of no longer having an "original mac", and also going against the grain of the philosophy of the original machine.
Oh yes, and you'll void the warranty.
I was just looking at the DOVE MacSnap SCSI adapter board I have. From a design perspective it looks exactly like the John Bass schematics, though with a few more resisters and capacitors as well as terminators. Obviously the Bass design is for use with a single hard drive and no pass through or daisy chaining.
However, what interested me the most, is that the Dove board uses the same 5380 SCSI chip and two EP320PC-2 chips. The differences between the EP320PC2 and the 74LS10 escape me and the internet was not much help, but it strikes me as more than coincidence that the designs are otherwise so symmetrical.
The Dove requires 128K ROMs, which suggests that it relies on the SCSI software and drivers within the ROMs to access the drives on the bus. John Bass' design seems to add the proper software to the System file on the startup disk. Therefore, it seems as though the Dove board might work perfectly well with the 64K ROMs as long as the drivers and formatting software are present in the System file. The Dove boards turn up routinely on eBay and if this hack were so, it would eliminate the need to build these interfaces. However, the most difficult part is still going to be to adapt this driver at a minimum to a modern SCSI drive.
However, what interested me the most, is that the Dove board uses the same 5380 SCSI chip and two EP320PC-2 chips. The differences between the EP320PC2 and the 74LS10 escape me and the internet was not much help, but it strikes me as more than coincidence that the designs are otherwise so symmetrical.
The Dove requires 128K ROMs, which suggests that it relies on the SCSI software and drivers within the ROMs to access the drives on the bus. John Bass' design seems to add the proper software to the System file on the startup disk. Therefore, it seems as though the Dove board might work perfectly well with the 64K ROMs as long as the drivers and formatting software are present in the System file. The Dove boards turn up routinely on eBay and if this hack were so, it would eliminate the need to build these interfaces. However, the most difficult part is still going to be to adapt this driver at a minimum to a modern SCSI drive.
Well I have to respectfully disagree. Particularly when the perception is that this particular "upgrade" is described as "butchering".
"Devaluing" is a relative term, in that it can be temporary or permanent. In this case, this is no more devaluing than plugging in an external hard drive into a serial port. The ROMs are socketed, so they easily pull out, the board goes in, the ROMs go in, the cable comes out through the battery access, clean and elegant. The Mac is still original but can now be used with a modern storage solution. All one has to do to return it to stock condition is unplug the board and re-seat the ROMs, in principle no different than unplugging an external drive. No damage is done to the existing case or hardware. If I saw such a unit on eBay with the board installed I would still pay top dollar knowing it could easily be restored to stock condition, especially if the 64K ROMs were still intact as with this process.
As for the original philosophy, even the external floppy disk drive goes against the grain as anything the customer ever needed was already built into the box, including all the storage they ever needed (the ext. FDD wasn't even available until 6 months later). Perhaps it goes against "Jobs' philosophy" but in agreeing to allow the ROMs to be socketed, he unwittingly agreed to the addition of another port. Also, had SCSI existed as a universal standard in 1983, it's arguable whether it would have been included on the original Mac. And if USB had existed we would not be having this argument. Jobs had no qualms with expansion, he simply wanted the Mac to be a closed box with the user only able to add onto it via the ports and software. The fact one has to open the box to access the ROM sockets is a trivial technicality. I see this no differently than the commercially available Quark QC-10 hard drive which also connected to the floppy disk port against Apple's guidelines, yet the use of which did not void any warranties.
As for voiding the warranty, even at the time that is highly unlikely since the board can be easily removed with no traces it was ever there, hence the devaluing argument. Jobs might have even applauded this solution as he later did the engineer's RAM expansion deception which saved his ass, since it plays by all the rules: it uses an existing "port" interface and is essentially a software solution. In fact, if I had to sum up Jobs' philosophy of the original Mac it was: the customer should pay for a new model if they want new features. Almost no one at Apple felt that way. So it's a question of whose philosophy you apply, and I would argue we are long past being concerned with the philosophical motives behind the original January 24th introduction. For the advantages offered by the SCSI board adapter, this particular argument is moot, especially considering the alternatives to hard to find and failing parts every passing year virtually ensure usually destructive upgrading it to keep it useable.
Either way, "butchering" is the last word that should ever be used for a non-destructive modification, especially this one.
When I got my first Mac Plus I had no external floppy or harddisk, but I did have a PC and a copy of Lightspeed C3.0
Back then I wrote two storage drivers...
1. a serial floppy, using the serial driver I wrote a storage driver that would talk RS232 to the PC. The PC ran a server program that let the mac read, format and write to the IBM PC's floppy. So presumably I was the only person using Mac formatted 720k 5.25" floppies.
2. a RAM disk, the mac plus had 4Mb so I allocated a meg to the RAM disk to put the C compiler. When I started the machine, the first thing I did was copied the C compiler to the RAM disk. I'm sure there were other RAM disk programs available but this was long before the internet took hold.
From memory the storage driver only had to support synchronous operation, not async, which was a real blessing.
Regarding original Mac expansion, that's what the Zilog SCC was for!
Back then I wrote two storage drivers...
1. a serial floppy, using the serial driver I wrote a storage driver that would talk RS232 to the PC. The PC ran a server program that let the mac read, format and write to the IBM PC's floppy. So presumably I was the only person using Mac formatted 720k 5.25" floppies.
2. a RAM disk, the mac plus had 4Mb so I allocated a meg to the RAM disk to put the C compiler. When I started the machine, the first thing I did was copied the C compiler to the RAM disk. I'm sure there were other RAM disk programs available but this was long before the internet took hold.
From memory the storage driver only had to support synchronous operation, not async, which was a real blessing.
Regarding original Mac expansion, that's what the Zilog SCC was for!
Sorry, but I had a similar reaction as Mac128 when I interpreted the post as gutting one Mac for parts use in another -- especially if the Mac you gut is in good working condition (or could easily be fixed to make it in working condition). As to the comment about people being "welcome to do what they like with their own property," I would ask you if it is okay to beat your dog to death even though he is owned by you. Your response would of course be "no, but a Mac is not a living creature." Even so, some of us here are so attached to our Macs that we treat them as such. Hence, you will often get a response from us that resembles how we might react to news of a dog-beating.
With that said, I am intrigued by this thread, if actually it leads to some specifics on what we must do to get a SCSI drive (or processor direct disk -- like the HyperDrive) to work on a Mac 128k or 512k with the original 64k ROMs. But in the end, we might have to recruit Andy Hertzfeld on this project before anything usable materializes. (Andy is a geek, but perhaps not geeky enough to do something like this. But personally, had I a similar experience and if I had spare time now, I would find it fun and interesting to work on a challenging project for a device I played an integral role in building some 25 years before.)
Did you try octopart.com?
Did you indeed? }
Lately, I've been pondering the serial port as a place to hang flash drives. I recall seeing RS-232 card readers long ago, in the early days of digital photography. Any thoughts?I've thought the slickest way would be to have a microcontroller do LocalTalk and appear to the Mac as an appleshare server. Then the flash drive can stay as FAT32/FAT16 and the Mac is none the wiser.