Jump to content
Mac128

Levco MonsterMac SCSI for 512K

Recommended Posts

And if we could get extra memory too, without sacrificing software compatibility inherent to the 64k ROMs, then of course that would be nice as well (although any memory above 512k would be used as a RAM disk in conjunction with the 64k ROMs and no ROM hack).

 

The Outbound Laptop Model 125 which uses Mac Plus or SE ROMs has four extra SIMM sockets, so eight total. The extra four are totally devoted to a RAM disk--up to 16 MB. And it's maintained even when the machine is powered off, so one can keep the OS and apps on the RAM disk to make the machine super fast.

 

Examining an Outbound Laptop might lead to some interesting add-on card possibilities for the pre-Plus and Plus and SE models.

 

Actually, I've only ever tried 4 MB SIMMs in the RAM Disk slots. One of these days I've got to try 16 MB SIMMs in there. But even a 16 MB RAM disk kills the time that the battery stays charged if the machine is unplugged. Been thinking about building some SIMMs with SRAM...

Share this post


Link to post
Share on other sites

I've commented on Manabu Sakai and his CF card solution before:

 

Ruffled Feathers

Money Back Guarantee

No Performance Guarantee

 

And if memory serves me correctly, I wrote other things too on this site, prior to the hard drive crash. Specifically, I had so many problems with him over email concerning that CF card product that I decided to telephone him, since I speak Japanese. His mother (he lives with her) answered the phone and refused to put him on the line because he apparently told her not to! It was at that point in time I threw up my hands and gave up. The man is far too eccentric for me to deal with. But if one of you out there can massage Manabu Sakai in the right way, perhaps you can get the answers you seek. In the end though, you may just have to buy the item, not knowing completely what you will get, and hope for the best.

Share this post


Link to post
Share on other sites
I've commented on Manabu Sakai and his CF card solution before:

 

Ah, I had forgotten about that PowerBook thread and did not realize you had acted on it.

 

Thanks to Bunsen's post I found the article that discusses performance:

 

http://lowendmac.com/mail/0801mb/0118.html#4

 

However, it may be moot as my e-mail to him bounced and the SCSI adapter is "Out of Stock". I might go ahead and get one of the IDE drives to try with a SCSI to IDE adapter, since if it doesn't work out, I can always throw it into my aging (and complaining) IDE drive in my old PowerBook G4. Though if I go that route, I might as well go with something a little less suspect like this reasonably priced product: http://www.addonics.com/products/flash_memory_reader/ad44midecf.asp discussed here: http://lowendmac.com/reviews/07/flash.html ... the only thing that gives me pause is that it says it requires OS 8.6 and above.

Share this post


Link to post
Share on other sites

And so, the search continues for an upgrade board (especially one with SCSI) that allowed continued use of the stock 64k ROMs. Was such a beast even made? Will we ever know? :-/

 

JDW, this thread seems to indicate that the Levo Monster Mac board did not implement standard SCSI, but rather required specific drivers to access drives. Any drive you inteded to use would have to have a formatting utility that worked with Levco's custom configuration.

http://groups.google.com/group/fa.info-mac/browse_thread/thread/5ac295eaacaa56eb

 

This is actually an interesting observation following on the heels of the Dr. Dobbs article that indicates special drivers would be needed to work with specific drives on Bass' SCSI implementation as well.

Share this post


Link to post
Share on other sites

Mac128, thanks for the insightful article. The for lazy among us (no doubt there are many), here is the relevant paragraph from that article:

Levco has made their system completely compatible with the new Apple file system. Stas Lewak (who was giving the demo) tested the robustness of the new Apple hierarchical file system by copying a folder which had a copy of itself recurusively. He was able to have over 200 levels of folders! ...any changes to the Apple file system would not affect their drive because the system uses the Apple file system. They only wrote drivers to talk to their disk. He said it would be senseless to write a new file system from scratch when the existing one is supported and compatible with the rest of the Macintosh software.

I agree that it is interesting about the part of about drive-specific drivers. And again, that means that even if we were to follow that Dr. Dobb's article and build MacSCSI, how could we expect to find a "compatible" hard drive that would work with the driver they include?

 

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.

 

But again, this is talking about a LEVCO product I've never seen. I see a memory upgrade board on EBAY right now, made by LEVCO. But through the years, I've not seen the LEVCO 20MB internal hard drive spoken of in that article.

Share this post


Link to post
Share on other sites

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.

 

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.

 

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.

Share this post


Link to post
Share on other sites
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 ...

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:

 

http://folklore.org/StoryView.py?project=Macintosh&story=Were_Not_Hackers!.txt

(Scroll to the bottom of that page, click the Show Comments button, and look at the two comments by me, James Wages.)

 

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

My internal HyperDrive 20 is bootable on my other Mac 512k with 64k ROMs. No boot floppy or hand-off required.

 

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?

 

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.

Share this post


Link to post
Share on other sites
I presume [your Hyperdrive 20] does not require a special software driver?

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.

 

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.

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.

Share this post


Link to post
Share on other sites

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.

 

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.

Share this post


Link to post
Share on other sites

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.

Edited by Guest

Share this post


Link to post
Share on other sites
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.

 

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.

 

I got his card, but I've never had any real reason to contact him.

Share this post


Link to post
Share on other sites

I received the following short reply from Steven Szymanski this morning, who by the way is the author of that GCC Gallery site I mentioned in my previous post above:

 

Brad's the one who worked out the boot sequence hack; but what I remember matches what you say - part of installing a hyperdrive was attaching a clip to the processor - that clip was how we hacked in our ROM into the boot sequence. Very much a hack.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×