-
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.
SCSI for the 512K (or 128?)
- Thread starter Charlieman
- Start date
I wouldn't get too excited about John Bass's SCSI code. He talked and wrote about a lot of things he never actually did. I bought a copy of his driver and built one of the Dr. Dobbs interfaces and never was able to get it to work. I found that Micah was developing a commercial internal SCSI drive for the 512K and Beck-Tech 1 MB upgrades, so I worked with them. Steve Brecher wrote Micah's ROM driver, and it worked pretty well, though Apple pulled the rug out with one system update. Unfortunately, Micah's ROMs only work with the hardware they used, an OMTI 3120 SCSI-to-MFM interface, and a 20MB MFM disk drive. Steve owned the source code, since Micah's financial backer didn't see any need to buy anything other than a license to the object code, so nobody has access to source to modify or learn from it.
There is a very simple source of SCSI boot ROMs. The Apple 128K ROMs. They work. They are compatible with a number of 3rd party SCSI upgrades. They are compatible with most Systems and Finders. They will boot a lot of SCSI drives, but not all. They are genuine Apple. They are readily available from dead Mac Plusses. But I know somehow it's "non-original" to put 128K ROMs in a 512K, but it IS "original" to add somebody else's hacked ROMs. A distinction I find difficult.
That said, if I were attaching a flash drive to a 512K or a Plus, I think I'd look at making an IDE interface that plugs into the Mac's ROM sockets the way Bass's SCSI adapter did. Then I'd need to write a driver for it, which would be easier than writing a SCSI driver AND a driver for a SCSI-IDE adapter. The driver could either be on a floppy, or it could be in ROMs to make the flash drive bootable. That would be cool. And low power cool, too.
There is a very simple source of SCSI boot ROMs. The Apple 128K ROMs. They work. They are compatible with a number of 3rd party SCSI upgrades. They are compatible with most Systems and Finders. They will boot a lot of SCSI drives, but not all. They are genuine Apple. They are readily available from dead Mac Plusses. But I know somehow it's "non-original" to put 128K ROMs in a 512K, but it IS "original" to add somebody else's hacked ROMs. A distinction I find difficult.
That said, if I were attaching a flash drive to a 512K or a Plus, I think I'd look at making an IDE interface that plugs into the Mac's ROM sockets the way Bass's SCSI adapter did. Then I'd need to write a driver for it, which would be easier than writing a SCSI driver AND a driver for a SCSI-IDE adapter. The driver could either be on a floppy, or it could be in ROMs to make the flash drive bootable. That would be cool. And low power cool, too.
Personally, I'm not particularly interested in booting a 128K or 512K from a hard drive. I'm more interested in the expanded storage options it affords, to cut down on disk swaps. I feel like if you're gonna run an original 1984/85 Mac, booting off a floppy is mandatory. I actually kind of like the hand off startup floppy that automatically switches over to the hard drive and then ejects itself. Very elegant, and for me part of the experience. A flash drive that tapped into the ROM would be amazing!
This is where looking at the Outbound Model 125 might come in handy. It used Mac Plus (or SE) ROMs and had an IDE hard drive and there was no SCSI to IDE conversion going on. It does have an on-board EEPROM which contains a bit of extra boot code from Outbound. I wish we could get the source...That said, if I were attaching a flash drive to a 512K or a Plus, I think I'd look at making an IDE interface that plugs into the Mac's ROM sockets the way Bass's SCSI adapter did. Then I'd need to write a driver for it, which would be easier than writing a SCSI driver AND a driver for a SCSI-IDE adapter. The driver could either be on a floppy, or it could be in ROMs to make the flash drive bootable. That would be cool. And low power cool, too.
Anyone know what ever happened to Mike Duffy or Doug Swartz. Of course, even if we could find them, there's a good chance they didn't keep the old code around. Sigh. I would really like the code for the GALs in the floppy and SCSI adapter boxes too...
Isn't *all* the floppy swapping "part of the experience"? If you're looking for an authentic pure-to-Apple's-"vision" early Mac experience that involves a hard drive the only legitimate answers are to use an HD-20 or upgrade to a Plus. ;^b
(It seems to me a schizophrenic set of desires to want to keep the 64k ROMs for "authenticity" yet still want some sort of authenticity-destroying internal hardware add-on to get non-Apple-sanctioned functionality on the system. Isn't that a bit like a car collector *insisting* that their 1908 Model T retain the planetary gearset transmission, wet clutch, starter crank, and all original suspension and brake parts while at the same time scheming on ways to transplant a Chevy V8 engine into it? Besides the obvious technical issues, well... if you want the "authentic" Model T experience you're stuck using it stock, or possibly with period upgrades that preserve the essential factory layout of the car *only*. Anything else puts you in the same category as people who make "T-Bucket" Rat Rods, and at least the people who make those usually have the good sense to upgrade the auxiliary components to units rated to handle the power they've added to the car.)
That snipe aside it seems to me there's zero-hardware solutions to this if someone gets off their rear and fires up the C compiler. John Bass' "vaunted" SCSI code was a hack on example code for a RAMdisk included with his C compiler. He said so in his article. The original Mac has two serial ports, so why not just likewise hack a RAMdisk driver to use one of them to speak to "server" software that dishes up disk images from a modern machine? (A UNIX box, or a Macbook with a USB serial adapter. Was it Porter who said in some earlier post that he'd written just such a driver to use the floppy drive on his DOS machine for Macintosh storage years and years ago?) Using disk images over serial would be "slow", but everything's slow on a Mac 128k, and such a thing could be considered "historically correct". (Serial hard drives like the Tecmar MacDrive did exist for the early Macs.)
If it's acceptable to use an HD-20-esque method of storing the driver on a pre-boot floppy then the hardware hardly matters. Write the driver first for a serial port connected to another computer (the server software would be trivial, and this time I say that meaning that even *I* could probably write the UNIX code for that). Once you have the bugs worked out of that you could instead target a dedicated hardware hack. A microcontroller sitting on a passthrough board snooping the address lines in a ROM slot, ala John Bass, Dove SCSI boards, etc, is an obvious thought. Practically every microcontroller on the market has example code for reading and writing SD cards over SPI in their code library. (Even a powerful one like the Parallax Propeller, which would allow you to write practically the entire program in a semi-high-level language, costs under $10 each. If you went into "mass production" with a printed circuit board you might be able to get a kit price down to under $50 for a printed circuit board and all the parts.)
People really get tunnel vision over thinking "building hardware" is what they need to do, but unless you intend to make a piece of hardware which perfectly emulates a device which is already supported out of the box (Which makes emulating HD-20 the *only* choice if you insist on keeping the 64k ROMs) you're doomed to accomplish *nothing* unless you're willing to get your hands dirty with some system-level programming.
(Well, okay, you could perfectly emulate something else like the Tecmar Macdrive if you had binary drivers for that handy, but to do that you'd need more technical information on it than is likely was every released to build your emulator, the same problem as the HD-20. Really, the only way to practically move forward is to accept the facts as they are and buckle down to write some software. If you don't love your 128K Macintosh enough to do that then why not just seal it in a glass case and be done with it? If no one's writing software for a computer platform then by definition it's "history". Time to move on.)
Why in the heck has nobody ever hacked the HD20 with a logic analyzer? It could not possibly be that complicated of a protocol, it is so unbelievably old.
This deeply confuses me. It seems so obvious and desirable, I do not understand why nobody has cracked it yet. Is there some technical reason that I'm not aware of? I'm sure we even have a pinout of the floppy port at our disposal. I have a Mac 512k and a couple plusses, if someone sells me a cheap HD20 I'd be happy to give it a good crack.
This deeply confuses me. It seems so obvious and desirable, I do not understand why nobody has cracked it yet. Is there some technical reason that I'm not aware of? I'm sure we even have a pinout of the floppy port at our disposal. I have a Mac 512k and a couple plusses, if someone sells me a cheap HD20 I'd be happy to give it a good crack.
Well, I personally AM surprised in light of the fact that so many seem to have the equipment and technical know-how to get flash onto Apple's even older than Macs!!!!:
http://dreher.net/?s=projects/CFforAppleII&c=projects/CFforAppleII/main.php
http://www.reactivemicro.com/product_info.php?products_id=32
http://sites.google.com/site/idiskapple2/home
No doubt someone will try to argue, "Well, the Mac 128k and 512k didn't have SLOTS you see..." Ah come on! How much harder can it be? Honestly, "where there's a will there's a way" rings true in all this. For whatever reason, there are more Apple II enthusiasts who have that WILL and as a result have found a WAY.
See, I knew it! Dogcow, your post falls into my previous post's statement, "No doubt someone will try to argue..." My mention of "slots" is your "architecture."
But the fact is that those flash drive solutions for the Apple II didn't appear on a magic tree. Someone had to make them, regardless of how "easy it is" versus doing so on the Mac. I stand by my previous post. Where there's a WILL there's a WAY.
But as Gorgonops so pointedly put it, no one has yet "gotten off their rear" and done it. But obviously, someone with programming experience would need to do so. (Someone like those who created those Apple II flash drive solutions.)
But the fact is that those flash drive solutions for the Apple II didn't appear on a magic tree. Someone had to make them, regardless of how "easy it is" versus doing so on the Mac. I stand by my previous post. Where there's a WILL there's a WAY.
But as Gorgonops so pointedly put it, no one has yet "gotten off their rear" and done it. But obviously, someone with programming experience would need to do so. (Someone like those who created those Apple II flash drive solutions.)
I cant program in C, so that rules out my ability to program on the mac. But i develop hardware and write the ASM that drives the hardware all the time. If i had a logic analyzer that would fit in my budget, i would have reversed the stuff long ago. But i dont, and i cant afford a working HD20. so thats kinda out of my way.
However i did pick up a book on the nubus architecture and how to devlope hardware/drivers for it, its an apple book. i read it but that sucker is the most complex buss ive seen. hehe. it aint no 8 bit. thats for sure, and thats the world i came from. 8-bit.
However i did pick up a book on the nubus architecture and how to devlope hardware/drivers for it, its an apple book. i read it but that sucker is the most complex buss ive seen. hehe. it aint no 8 bit. thats for sure, and thats the world i came from. 8-bit.
I stand amused that my post was provocative enough for you to post in this thread because now it partly has become your cause too.
But my intention was to be provocative enough to get a few people sufficiently steamed about this topic such that someone capable might come along and lay down the law. The people behind those Apple II flash gizmos clearly did just that. Someone pissed them off enough so they one day stood up and said, "Okay, here it is you selfish bastards. Now call me King." And of course, with product in hand everyone in the Apple II community likely did just that, not only with their words but with their cash as well. Whoever puts their WILL to work and finds a WAY deserves to be crowed King.
not even close
but it comes off as I want and I want someone to do it for me!
wow, just wow is that how it works in a community?
the communities that I involve myself with are more into helping each other, both computer and electronics, if all you want is someone to be king then good luck with that, cause nothing comes of it in the long run, as you already see in this topic, once king doesnt give a crap anymore they might as well not existed except for rumor leaving the community out in the dust
I dont bow to kings, kings are worthless, community is forever
here is a little hint, it takes 3 (ok not counting power and ground) wires to hook up a SD card in out and clock, the rest is totally software, find 3 addressable lines in the mac and write a driver, bam done
For the record I only suggested a microcontroller because of the easy availability of SPI and msdos filesystem driver code could much simplify the task if the goal was to parse emulator images on "normally formatted" cards. But, yes, you can bitbang an SD card and read and write raw sectors with practically no hardware. One ic piggybacked onto the mac motherboard would do you. It just makes the mac software no one wants to write a little harder. Certainly still very doable.
Certainly. Of course, if you don't care about using emulator images directly by dragging and dropping them on the card parsing msdos filesystems in the macos driver is a pointless complication. Just treat it as a big pile of sectors and use "dd" to copy filesystems onto the card. Limits you to one volume per card unless you choose to support hard disk volume lables or some similar offset scheme but who cares. Keep it as easy-peasy as possible for version one and improve it later. Or don't start at all because it's still too hard, whatever works.
Similar threads
