• 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.

Levco MonsterMac SCSI for 512K

And if you want the fastest PPC Mac, get a G5 -- seriously, I see no other benefit to going with a 601 or 604e or G3 or even G4 (unless you, like me, love the beauty of the G4 Cube), since PPC is PPC and the fastest PPC rules
Personally, I think the last of the G4s is a better option. The G5 may be faster, but I don't think it lasted long enough for Apple to engineer out the last few kinks. Plus the liquid cooling systems on the high performance models are booby traps with ticking clocks. And Apple kept changing the type of PCI slot included. That kind of architectural change means they never settled enough to really iron out the last of the kinks.

On the other hand, the MDD machines are at the pinnacle of G4 development. They are preceeded by four or five earlier revisions of G4 computer. By the time of the MDD, Apple knew what it was doing with the G4.

In much the same way that the SE is at a pinnacle of 68000 development, although some might put the Classic there. Personally, I think the Classic is on the downward side of that mountain. They reached the top, then looked around for ways to economize and headed back down the hill at that point.

 
In much the same way that the SE is at a pinnacle of 68000 development, although some might put the Classic there. Personally, I think the Classic is on the downward side of that mountain. They reached the top, then looked around for ways to economize and headed back down the hill at that point.
Actually now that I am exploring the Portable, I think the backlit Portable represents the top of the mountain. It is the same specs as the SE FDHD but with a 16MHz data bus and 8MB RAM, or 4MB with similar PDS expansion options (not to mention dedicated video out for using a larger monitor and internal modem). As many have said, the Classic at a minimum should have been the Portable in a compact case, in which instance it would have been the crowing achievement of the 68000 line. But instead the Classic was Apple's last effort to squeeze the last profit out of the original 128K tools while not competing with more profitable models which needed to be recouped (along with the Classic II which was no replacement for the SE/30 either). Had Apple kept the Portable in production, but positioned it as a desktop model now that the price was dropping, they would have essentially had the first iMac. A relatively powerful consumer desktop with a great looking LCD. Truly they were 15 years ahead of their time with that one. Instead they did the same thing and started back down the hill with the PowerBook 100.

 
The Portable was a cool design and I sometimes wonder if its ROM couldn't be adapted to something like the Plus or SE, mainly because it would nice to allocate 8 MB of the 16M memory space to RAM, instead of only 4M.

One of these days I'm going to have break down and learn 68K assembly code....

 
I like almost every aspect of the Portable, except that silly battery design. Why in the world did Apple make you HAVE TO keep that enormous battery in there at all times. And without it, unless you have a PB100 adapter hack, you cannot use the Portable. And even if you buy a refreshed battery pack, you have to be very careful because it's easy to make those kind of batteries go brain dead in short order. But even if you care for the new battery, all batteries die over time. And since the Portable is to heavy to be truly portable, it means you would normally use a power adapter most of the time.

So if the Portable could be rewired to safely use an AC adapter, I think it would be a great machine, even if you wanted to keep it in storage for long periods of time like other classic Macs.

 
The Portable was a cool design and I sometimes wonder if its ROM couldn't be adapted to something like the Plus or SE, mainly because it would nice to allocate 8 MB of the 16M memory space to RAM, instead of only 4M.
I think the lack of 16MHz data bus on the SE would limit your performance. And like the Portable, if you intended to use the PDS slot, you'd be back to the stock SE configuration. You could theoretically fit a PB 100 in the SE case, but not the Portable, without which you'd lose your SE PDS (unless you were using it for a modem in which case the 100 would arguably be an improvement). It should be possible to convert the 100's a simple 1-bit digital video signal for the SE's CRT.

I'm not a big fan of the Portable's design or the Snow White stylings in general. But I do like the Portable's LCD screen and advanced 68000 features. With the screen folded down, it makes for clean desktop storage when not in use and an external monitor and keyboard/mouse make it about the same setup as an LC (and probably more powerful). Plus I love trackballs. However, I would miss the quaintness of the sing-song 400K drives which are not compatible and the early MFS Systems, but I wouldn't miss the fans introduced with the SE & Classic. As a desktop I would prefer it to be closer to the Apple //c form factor with an external mouse, but if I had to transport it a lot, I would definitely prefer it as is, rather than shoving the separate parts in a bag like the SE.

But let's compare them anyway:

_____________SE____|_PORTABLE_|_CLASSIC__|__PB 100__________

CPU_________8MHz______16MHz______8MHz_____16MHz

Bus_________8MHz______16MHz______8MHz_____16MHz

Display_____512x342____640x400____512x342___640x400

Type________CRT______Active Mtrx____CRT_____Passive Mtrx

Ext. Disp._____PDS______Dedicated____NO________NO

PDS___________1_________1_________NO________NO

ROM EXP._____NO________YES________NO________NO

RAM (MAX)____4MB_______9MB*______4MB_______8MB

MODEM_______PDS_____Dedicated_____NO______Dedicated (no Ext. Modem port)

Ethernet______PDS_______PDS________NO________NO

SOUND OUT__Mono______Stereo______Mono______Mono

BATTERY______NO_______YES_________NO_______YES

FAN__________YES_______NO________YES________NO

*5MB if PDS used (8MB & 4MB respectively on M5126), with or without backlight upgrade.

All other ports are the same.

Clearly the Portable wins hands down and the Classic & PB were indeed poor stepchildren and the SE suddenly doesn't seem so much better than the Classic. The Portable had dedicated internal connections for everything but Ethernet which could be installed in lieu of additional RAM and still have 1MB over the SE. With the SE, this choice was nonexistent. Moreover, while the SE provided for all of the functionality of the Portable via its PDS slot, it only allowed one of the options otherwise native to the Portable.

The reality is that Apple did not pursue either the external video or PDS expansion, leaving both to third parties. Therefore, external video adapters are rare and the only PDS cards available are RAM cards (which oddly Apple attempted to discourage). So the practical reality is the SE wins in external expansion options, but the Portable wins in speed and RAM. The ultimate winner depends on which is more important. But it cannot be discounted that both options are there if one is industrious enough to exploit them. The video adapter should be easy enough to make. The PDS is a little more involved and with SCSI Ethernet options, probably not worth the RAM sacrifice. However, I can't help wondering if the SE PDS cards could be adapted for use in the Portable.

 
But getting back to the originally point... I, like Mac128k, want to see if there is a way to get SCSI going on the 64k ROMs, perhaps in conjunction with the HD20 init or similar "software hack." 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). I think its fun to try to max out an older Mac while at the same time retain it's true nature (in other words, add SCSI to a Mac128k with 64k ROMs, rather than gut the machine and put in a Mac Mini and LCD screen).
JDW, you need to get on this guy to produce a few more of these things:

http://209.85.171.104/translate_c?hl=en&sl=ja&tl=en&u=http://artmix.com/CF_powermon.html

Once we get the 64K ROMs working with SCSI it'd be nice to have this up and running on an MacSnap SCSI upgraded 512Ke or better and simply switch it over. I get the feeling it has to be formatted under System 7 anyway.

He's got the IDE versions for sale on eBay pretty reasonably. Shipping from Japan is a bit steep but not prohibitively expensive for such a miraculous device. Almost makes me want to buy one and try it with a SCSI to IDE adapter, but I would be concerned it wouldn't "just work" on an older Mac in that configuration. I'm all about plug and play.

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

 
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.

 
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.

 
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.

 
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.

 
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.

 
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:

 

Code:
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.)

 

I am hard pressed to understand how Bass' SCSI implementation will be bootable, or is it simply a hand-off solution like the HD20?
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."

 
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!

 
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.

 
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.

 
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.

 
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.
 
Last edited by a moderator:
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.

 
Back
Top