• Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.

MacSCSI by John Bass AT LAST!

Mac128

68020
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!

 
MPW is no help?
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.

 
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?

 
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.

 
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.

 
Whether it be SCSI, processor-direct or another means, I would love to have an INTERNAL / flash drive in my Mac 512 (or 128) /. Just slip a 32MB flash card in and go! / 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.
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.

 
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.
The main problem with this is, I've never seen one. How readily available are they?

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.
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.

 
"FlashPath"
How readily available are they?
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 :?:

the FlashPath which would need a custom driver written for it
I suppose so - the 64k ROM Macs won't take 1.4MB floppies in the first place, will they?

it seems to me we are closer than ever and need look no further than the John Bass solution / a completely engineered solution / has value as a SCSI interface / including potentially using an EN/SC adapter / If "somebody" were going to put any time into this project / this would be the one to focus on.
I agree wholeheartedly that this is the most promising starting point:

The parts for this venture are few. The MacSCSI host adapter consists of four parts*: an NCR5380 single chip SCSI interface, two 74LS10s to provide the address decodes, and a 50 pin header for the SASI/SCSI cable
*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.

 
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.

 
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. 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.
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.

 
Back
Top