-
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!
- Thread starter Mac128
- Start date
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.
Similar threads
