Thread
Levco MonsterMac SCSI for 512K
That may be specious reasoning. The HD20 is "compliant" with 128K ROMs, which mainly means HFS. At the time Levco was developing their SCSI interface board, HFS was the giant rumor in the Mac community and compatibility with the next generation Mac Plus was paramount to success within the industry. Whether in ROM or RAM, any product that hoped to survive for the Mac had to be able to support the 128K ROM changes, just like the HD20 did on the 512K with software. In other words, anything written for the Mac Plus would also work on the Levco board, whether it was clipped to a 64K ROM Mac or not. On the other hand, I don't think there is anything that otherwise prevents a SCSI drive from being formatted MFS, though to be compatible with the 128K ROMs, the option to format HFS would be a requirement. On the other hand, the the Levco patch ROMs (used instead of software drivers to enable booting) may have loaded HFS code, just like the 128K ROM or the HD20 INIT. But I don't think that makes it a 128K machine, no more than the HD20 INIT does. In order to make it bootable, the piggy-backed ROMs are simply a different delivery method for the software, directly injected into the system ROMs rather than taken internally after loading.Next, I am assuming their use of "new Apple file system" actually means "Hierarchical File System" (HFS). If so, that would imply compliance with the 128k ROMs, rather than the 64k ROMs. :-/ It is also interesting to note that Apple introduced HFS in September 1985, and this visit to Levco was made on October 6th, 1985.
While we're on the subject of HFS compatibility, I found this reference to the Rev. 64K ROM (I assume) being released in March '85, allegedly to support changes in the 400K drive. However, this article indicates that it is needed to support the new 800K drive compatibility and that for some reason the older ROMs couldn't. Is it possible that 2nd gen. 64K ROMs had the 800K drivers built-in? After all, the HD20 was announced in April '85, though not delivered until September. In which case, such a ROM would not require the HD20 INIT to access them ... could this also have something to do with System 5 not booting on a 512K Mac on the first gen. ROMs? Or, does this article refer to 128K ROMs being put into 512K Macs? Very curious wither way. I guess I need to do a ROM dump from my Rev. B ROMs and find out ...
http://www.mactech.com/articles/mactech/Vol.02/02.01/Jan86Mousehole/index.html
But I am left to wonder ... even if all of these solutions, John Bass' included, can be implemented on the 64K ROM, will they ultimately preserve the 64K ROM experience or will they alter it in some was so as to cause compatibility issues? In particular, I am hard pressed to understand how Bass' SCSI implementation will be bootable, or is it simply a hand-off solution like the HD20? Without a deeper understanding I would think simply using an external SCSI drive as a storage unit would be the best one could hope to do on a 64K ROM. I suppose a hand-off solution is possible, but an INIT that patches ROM extremely early-on would need to be written to do that. Simply switching to the external System would not be a true bootable experience as many drivers must be loaded earlier in the startup procedure than this allows. And then there are the exact same issues that plagued the HD20: none of the software was designed to be written to large volumes, so there were many incompatibilities from installation to running software off the HD20. This was true of the serial hard drives as well.
Well, you certainly won't find out from Andy Hertzfeld by posting a comment on Folklore, that's for sure. I posted a comment there in November 2005 about this very subject, and no one has cared to offer me a reply! Sorry, but your going to have to copy and paste the following URL since 68kMLA is brain dead when it comes to putting tags around web addresses that contain an exclamation point:I found this reference to the Rev. 64K ROM (I assume) being released in March '85, allegedly to support changes in the 400K drive. Is it possible that 2nd gen. 64K ROMs had the 800K drivers built-in? Or, does this article refer to 128K ROMs being put into 512K Macs? I guess I need to do a ROM dump from my Rev. B ROMs and find out ...
Code:
http://folklore.org/StoryView.py?project=Macintosh&story=Were_Not_Hackers!.txtMy internal HyperDrive 20 is bootable on my other Mac 512k with 64k ROMs. No boot floppy or hand-off required. And keep in mind that the HyperDrive is not compatible with HFS, which is why they use partitions called "drawers."I am hard pressed to understand how Bass' SCSI implementation will be bootable, or is it simply a hand-off solution like the HD20?
James, they may never have seen your comment. You left it about six months after the next most recent comment and that one was not answered either. I suspect that Andy never went back to view the comments.
trag, I think "apathy" is more of the reason for not reading a comment on Folklore. Go to the top page of the Folklore site. Now note the view recent comments text link in the middle/upper portion of the page. Indeed, comments are not impossible to find.
I guess I will need to send an email to get his attention. But the only two email choices are for Bug Reports and Feature Suggestions!
I guess I will need to send an email to get his attention. But the only two email choices are for Bug Reports and Feature Suggestions!
You may have gone into detail about this elsewhere, but lets take a look at that ... I presume it does not require a special software driver?My internal HyperDrive 20 is bootable on my other Mac 512k with 64k ROMs. No boot floppy or hand-off required.
The only way any drive can boot a 64K ROM is if it imitates one of the drivers coded into the ROM, or patches its own code into the ROM early on, which means there is some kind of ROM on the HyperDrive controller just like the MonsterMac board. So no matter what, software is being patched into the 64K ROM when it first loads into RAM. So I am back to the 64K ROMs are being updated in order to use any drive as bootable. The question remains, how extensive are the changes being made to 64K ROM so as to maintain their "authentic" functionality?
As for being HFS compliant, wouldn't that be up to the System? I mean the HD20 loads the HFS code into RAM as the system boots. To conserve resources, a bootable drive would only need to patch ROMs to make it driver aware. The MonsterMac board may include the HFS resources as a System INIT just like the HD20 does. I would think the same would be true of the HyperDrive. Why couldn't it be partitioned as HFS? That's simply a matter of the disk formatting utility which runs after the System loads.
Then again, I am merely speculating as I have no real idea how the whole boot process works.
To be honest, I've never checked the contents of the System Folder on that drive to see. I will need to do that check and report back.I presume [your Hyperdrive 20] does not require a special software driver?
My HyperDrive 512 does not load the HD20 INIT at boot time. I guess that is why it cannot have HFS partitions. So without having checked the contents of my System Folder on that HyperDrive, I can only assume that the code required to make the HyperDrive boot is in the two ROM chips on the HyperDrive Controller Board.As for being HFS compliant, wouldn't that be up to the System? I mean the HD20 loads the HFS code into RAM as the system boots.
Then the HyperDrive works just like the MonsterMac except the MonsterMac patches SCSI code, whereas the HyperDrive is proprietary. It makes sense the HD20 doesn't load as the HyperDrive is was around long before the HD20 and is probably already patching into the same place. However didn't HyperDrive make versions for the Mac Plus? If so, I would imagine they might have created their own drive formatting utility and HD20-like INIT for patching HFS into their 512K retrofitted Macs.My HyperDrive 512 does not load the HD20 INIT at boot time. I guess that is why it cannot have HFS partitions. So without having checked the contents of my System Folder on that HyperDrive, I can only assume that the code required to make the HyperDrive boot is in the two ROM chips on the HyperDrive Controller Board.
Two days ago I wrote to Steve Phillips, who worked for GCC and was on the latter-year HyperDrive team in the past. Steve was kind enough to offer me the following information this morning:
Although I'm not very familiar with this code, my understanding is that the HyperDrive intercepted the Mac boot sequence. When the 68000 started up, it was hardcoded to jump to a specific I/O address. By playing some games with address lines, I believe that the HyperDrive swapped the memory map around so that its own ROM was dispatched to instead of the Mac boot ROM. Once our software had control, it could install the hooks which allowed it to intercept disk accesses. I don't know any of the details of how our code interacted with the original boot ROM, but that was the basic idea -- install hooks so that disk accesses were routed through the software in the HyperDrive boot ROM. All of the code which accessed the MFM drive resided in the HyperDrive ROM, so no INIT resource was required. Some of our other software (e.g. HyperNet), did patch the system file by installing additional resources, but I don't believe that the basic HyperDrive made any modifications to the System file.
I think that Brad Parker developed the initial HyperDrive boot ROM, although I'm not sure. I came to GCC slightly later on, when we were developing the HyperDrive 2000, and I never had much of a reason to go digging through our boot ROMs.
This bit of lore is consistent with what I posted in another thread. I met a guy at the Austin Goodwill Computer Works Store who used to program Mac hardware back in the very old days. He said there was a jump in the early portion of the Mac boot code which allowed developers to sieze control of the boot process by adding hardware with code resident at that address to which the Mac jumped.Two days ago I wrote to Steve Phillips, who worked for GCC and was on the latter-year HyperDrive team in the past. Steve was kind enough to offer me the following information this morning:
HyperDrive intercepted the Mac boot sequence. When the 68000 started up, it was hardcoded to jump to a specific I/O address. By playing some games with address lines, I believe that the HyperDrive swapped the memory map around so that its own ROM was dispatched to instead of the Mac boot ROM. Once our software had control, it could install the hooks which allowed it to intercept disk accesses.
I got his card, but I've never had any real reason to contact him.