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.
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?
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?
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.
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.
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.)
Indeed it would, but somehow I suspect emulating a full Appleshare file server on an affordable microcontroller would be non-trivial.
And why bother with FAT16/32? Assuming one were using CF, they present as ATA devices and ...
And why bother with FAT16/32? Assuming one were using CF, they present as ATA devices and ...
http://en.wikipedia.org/wiki/Compact_Flash#Filesystems
Returning slightly to topic*
Given that the discovery of this listing (three cheers, Mac128!) does indeed get us "closer than ever", and requires only reading and writing to two addresses, and that at least some adaption of Bass's source code will be necessary to allow for modern drives and modern parts; is it at all conceivable that it could be adapted to:
*(I know that my imagination runs ahead of my knowledge at times. I am trying to be constructive here, I swear :b&w: Feel free to run with any of these thoughts, shoot them down, or ignore them)
So as I understand it:
Given that the discovery of this listing (three cheers, Mac128!) does indeed get us "closer than ever", and requires only reading and writing to two addresses, and that at least some adaption of Bass's source code will be necessary to allow for modern drives and modern parts; is it at all conceivable that it could be adapted to:
- faster SCSI chips (such as this one)
- IDE/ATAPI controllers
- 8-bit ISA cards, (and thence IDE, NICs, etc) as has been demonstrated on PIC and AVR micros
- embedded USB host controllers such as the £8.25 Vinculum and its various ready-rolled versions
Scans?
Conversely, is extracting the routines from the 128k ROM and inserting them in the startup System an option?
*(I know that my imagination runs ahead of my knowledge at times. I am trying to be constructive here, I swear :b&w: Feel free to run with any of these thoughts, shoot them down, or ignore them)
Charlieman has some good shots of them on his site: http://www.vintagemacworld.com/macsnap.html
I've been ruminating on that very issue. I think the problem is that even if it were possible to extract the SCSI resources and properly insert them into an earlier system, the 128K ROM has a startup routine that tells the Mac to look for the SCSI devices on the chain. Even if these drivers were in the System, they would load after startup, so that routine would not work to load the HD, and would still require some kind of drive mounting routine added to the FInder. I'm sure there's more to it than that, but it's worth a look I suppose.
Yes, my point being that the routine in the 128K ROM should only be applicable at startup and therefore some kind of mounting software would have to be written to load a drive after the fact, even if it's possible to use the 128K code wholesale.
Yes, I've duplicate posted all around the web ... I have no idea who is lurking where, but the 'fritter site got some prompt attention to the technical side of the project ...
Apparently there's some kind of hook in the original Mac's/Mac Plus ROMs one can use to get your code loaded at boot time. Of course, the code has to be sitting in an eeprom (or similar) at the proper address for this to work, but if you're plugging stuff into the ROM sockets anyway, this shouldn't be a problem. The problem is resurrecting that ancient bit of Mac hacker/programmer knowledge enough to know the specifics.
I ran into a guy at the Goodwill Computer Store years ago who programmed some of those old Mac products and we talked about it at length. From memory, there's some point where the Mac jumps the program counter to a high address in the ROM (I'm a little vague here) and then jumps right back or something like that. At that point, you can insert a chip at the proper address to intercept the execution. I think that's what he told me. I got his card. Perhaps I should email him and see if he wants to resurrect some old memories.
I have no problem believing that as the ROMs were the only socketed chips on the motherboard to allow this, combined with the fact that engineers already snuck in a way to expand the RAM against Job's wishes. I'm sure Jobs even resisted a socketed ROM. Wanna bet the argument about potential bugs was made merely to allow the socket? While it was easy to spot a suspicious change to the hardware, spotting a "hook" in the ROM code would have been much harder for Jobs. This is likely how some of the CPU & RAM expansion boards work which have EPROMs that override the motherboard ROMs on bootup.
The SCSI board is simple, and if you happen across a Micah internal SCSI hard drive kit which existed for both the Mac Plus and the Mac 128 / 512, you'll have essentially the Bass SCSI port. Micah's SCSI adapter added 2 ROM sockets so the DRVR could be present at boot, and a 64K ROM Mac could boot from its hard disk. Find a Fat Mac with a Micah Drive and you've got your ROM driver.
That said, if the criterion is non-destructive, build a Bass style SCSI card, plug it into the ROM sockets, and plug in a pair of Plus ROMs. That'll give you the code you need to access the SCSI port, and nothing needs to be soldered or otherwise messed with on your pristine 128K motherboard. The biggest hassle is feeding a SCSI ribbon cable out thru the battery compartment door, the floppy opening, or the security slot. If you're gonna do an internal drive, you're going to have to do some real hacking & drilling, add a power supply and a fan, so figure an external SCSI drive.
You can unplug everything and go back to bone stock. If the criterion is keeping the Mac 100% "original", then the whole idea of an internal SCSI / flash / HD / whatever is out, right? If your criterion of "original" is 64K ROMs, then you've got to persuade someone who knows 68K assembler and the 64K ROMs inside out to spend 3 man-months to write a driver for you, and that ain't gonna happen. It seems to me some are arguing that they want to turn an original 128K Mac into a Mac Plus but keep it original without turning it into a Plus. :?:
A 128K is so very limited by the tiny bit of RAM, it doesn't work very well with a hard disk. If you have an "Original 128K", then leave it alone. Admire it. Think how it's appreciating in value. Show it off to your friends. Just don't expect to do much more than draw pictures with MacPaint and write short documents with MacWrite.
That said, if the criterion is non-destructive, build a Bass style SCSI card, plug it into the ROM sockets, and plug in a pair of Plus ROMs. That'll give you the code you need to access the SCSI port, and nothing needs to be soldered or otherwise messed with on your pristine 128K motherboard. The biggest hassle is feeding a SCSI ribbon cable out thru the battery compartment door, the floppy opening, or the security slot. If you're gonna do an internal drive, you're going to have to do some real hacking & drilling, add a power supply and a fan, so figure an external SCSI drive.
You can unplug everything and go back to bone stock. If the criterion is keeping the Mac 100% "original", then the whole idea of an internal SCSI / flash / HD / whatever is out, right? If your criterion of "original" is 64K ROMs, then you've got to persuade someone who knows 68K assembler and the 64K ROMs inside out to spend 3 man-months to write a driver for you, and that ain't gonna happen. It seems to me some are arguing that they want to turn an original 128K Mac into a Mac Plus but keep it original without turning it into a Plus. :?:
A 128K is so very limited by the tiny bit of RAM, it doesn't work very well with a hard disk. If you have an "Original 128K", then leave it alone. Admire it. Think how it's appreciating in value. Show it off to your friends. Just don't expect to do much more than draw pictures with MacPaint and write short documents with MacWrite.
I do have a stock 128k logic board myself with the original 64k ROMs, but I prefer to use a 512k logic board instead, since it too has the 64k ROMs plus enough RAM to be quite usable. I simply would like to have the best of both worlds. If there existed a driver for the 64k ROMs, then I perhaps I could track down a SCSI SSD which would eliminate the need for an internal fan and perhaps would be low power enough to not even warrant a secondary PSU.
If a 64k ROM compatible SCSI driver really is impractical to create, then it would be nice to have the means to switch between the 128k and 64k ROMs (via mechanical flip switch on the back). Yes, I know I could accomplish the same tasks I desire simply by having a Mac Plus sitting next to my Mac 512k, and I could just use the Plus when I needed SCSI access. But having a single machine that could do both would be better. It would take up less desk space. But most of all it simply would be impressive a single machine that could do that. It would still be "original" in a major way, plus it would have features that only a 512ke, Plus or higher have -- SCSI access.
As to that 3 months of hard coding work, I wouldn't necessarily rule that out. For truly, if I had experience with 68k assembler programming and if I were retired, I can tell you for a fact that would be on my list of fun projects to tackle. Not sure if I am alone in thinking that way, but I do know there are some on this list far older than myself who might be willing to give it a try, perhaps some day. Some may consider such a "waste of time." But then again, some people may consider our posting on a vintage computing site to also be a waste of time. Let's face it, we're sort of geeky. And this is one of those geeky, but not completely impossible, projects to dream about. It keeps the vintage computing enthusiasm alive and kicking.
That's do-able, too. Put two sets of ROM sockets on your SCSI adapter with a switch. A SCSI ROM isn't impossible, it's just a lot of work for a problem that's already been solved. Micah's ROMs were written by Steve Brecher, a real Mac Guru, and he spent six months refining and debugging them. I suppose I am missing something, but I don't see the allure of the 64K ROM. The 128K ROMs contain the same code and toolbox as the original with bug fixes, and also support HFS, SCSI, and the rudiments of AppleTalk, among other things, *and* they were written by the genuine Mac team. If you enjoy writing drivers, a SCSI driver for the original Mac is a fine way to spend your summer. I promise you'll learn a lot!
Has anyone else seen a Micah drive? It appears they are much more rare than HyperDrives. IMHO, they were a more elegant solution, since they didn't require a CPU clip, drilling holes in the chassis, pop rivets, etc.
Ah, it sounds so simple, but what exactly do you switch? I brought this up in another thread and it was suggested the ROMs could be stacked and the switch would toggle between a single pin that enabled the ROMs.
As that article suggests, I'd also like to switch between 128K & 512K as well. So one Mac would basically be a 128K, 512K, 512Ke and 512K-Plus in one box.
No but now that you've clued me onto it, I will keep my eyes peeled. But isn't the driver only for the Micah drive? It wouldn't work on any other SCSI drive, right?
The switch goes to the chip enable pins. I don't remember the pin number off hand, but if you're building a Bass adapter, it should be noted on the diagram. Micah's ROM should work with most early SCSI drives and a Bass-style adapter. The Micah HD used a SMS 3100 SCSI-to-MFM controller card and any of the 20 MB MFM drives of the day, NEC being the most reliable of the lot.