BlueBox in Mac OS X DP2

[zsn0w]

Hi all,
I am trying to get the BlueBox (and I guess by extension Classic mode) in Mac OS X Developer Preview 2 updated to 9.1 so I can run Photoshop 7. It comes on 9.0. I can install 9.1 no problem, but then, after a restart, it will not boot. It just sits at the Happy Mac icon. I tried copying the "MacOSROM" file from a 10.0 Cheetah install to replace the one that DP2 uses thinking that may be the issue, but then it just yells at me that the ROM is corrupt or missing, so that won't work (maybe I could take the one from the public beta or DP3 or 4? but I know at least in DP3 it's still only running 9.0 out of the box). Anyone have any thoughts on what the issue could be? It seems to me like there's not a huge difference between 9.0 and 9.1 besides the Window menu being added, but I have never really used 9.0 much, it's always been 8.6, 9.1, or 9.2 for me.

My next thought is that there might be a "classic support" file somewhere like there is in the released versions of OS X that is getting wiped or upgraded with the install that BlueBox can't handle/operate without the original of? Could there be some extra extension doing it? I would think that that would cause the freeze to occur once the Mac OS 9.1 screen comes up, not the happy Mac screen?

Is there a way to manually update components of 9.0 to 9.1 on at a time to test compatibility of different things and get it to a point where I can install Photoshop 7?

Any help or suggestions are appreciated.
Thanks,
Zack

[Knezzen]

This is unknown territory for me, but someone here will probably be able to help you out

[IIO]

as you know, photoshop 7 would also run in a proper OS like 10.4.11, but i take it that there must be a reason to use it in blueblox under pre 10.0

i can only guess. as there is probably no checksum validation or something in that field, maybe it is enough to change the version number of the Classic ROM and some other system files? so that they look like the ones from 9.0?

[Jubadub]

Check for any files inside your System Folder with the name "Classic Support yadda yadda" or similar. These are created, and added, by Classic on most Mac OS X versions. I don't know if Cheetah's Classic uses those, but it's worth a look.

I don't expect the MacOSROM file to have anything to do with giving you the Classic/BlueBox support you need. But I could be wrong.

Also, rather than using Cheetah, try a closer relative: check things with the BlueBox/Classic for Mac OS X DP3, DP4 and also Mac OS X Public Beta.

i take it that there must be a reason to use it in blueblox under pre 10.0

It's the latest version that still retains Mac OS UI and UX! (Personally, though, I prefer Mac OS 9.2.2 for that.)

[zsn0w]

As Jubadub said, the reason to use BlueBox in DP2 is that it retains the Mac OS UI and UX (and thus graphical speed as well), while also offering some advantages over OS 9. I enjoy the file navigation in OS X, but I also enjoy the more spatial approach in 9 for some things. Rhapsody and the OS X DPs has a sort of mixture of the two that is really nice to use -  you start in a column browsing folder viewer, but double clicking any folder will break out a new window and act like classic Mac OS file browsing. Having unix underneath everything is nice for me when dealing with file storage and organization. I also just like the quirkiness of it and feel that it fits my PowerBook G3 well.

I haven't had a ton of time to mess with this since my initial post - St. Patrick's Day always has me pretty busy, and then today the starter on my car died, so I'll be removing the old one and replacing it whenever the part arrives. Hopefully this weekend I can work on this some more.

What I did find out was that DP2 doesn't seem to create a copy of the BlueBox base image in a folder for each user like OS X Server 1.0 does. Instead, it creates an alias in that spot to the instance of the image that it copies somewhere else. I cannot for the life of me figure out where. The alias just appears broken under OS 9, OS X, and Rhapsody. I think it's saved at the root of the drive somewhere maybe, but I don't know for sure. I've done some decently thorough searching through all the files (including hidden ones) without luck. This makes it slightly harder to experiment on the system. If I run the update in the BlueBox image, I have no way to edit it after the fact, because I can't find it and copy it off of the drive to mount it! I can, however, mount the base image that it uses to create the individual user instances. Would it be valuable for me to upload that somewhere? I did try to mount and update that, then re-zip it, but that results in the MacOS app on DP2 to freeze before it even opens the window - worse than when I updated it from within the running BlueBox image which resulted in freezing at the Happy Mac icon. There are "Classic Support" files in there. I'm thinking I could try to just copy the one from BlueBox's original image in the place of the 9.1 one after the update. I don't know if that will allow 9.1 to boot or not.

I'm still thinking if there's some process to manually update 9.0 to 9.1 by just replacing all the necessary files, that may be the best route. I've never heard of that done before, but I don't see why you couldn't do it given how modular and straightforward OS 9 seems to be from a system file perspective.

[aBc]

After your initial post I was wondering about any advantages of BlueBox over OS 9.2 - but then you said the magic words: “quirkiness” and “Power Book G3” and piqued my interest.

I’ve a "Can't kill it" iBook G3 here that I “throw” quite a lot of things at. It acts as a go between for files primarily downloaded for G4s here - from a much newer model (Intel) iMac internet portal. Such “base” files continuously build up on the iBook before getting burned to CD, etc... Before then, making the trip downstairs to the G4 dungeon. I keep telling myself that I will reformat and partition the iBook and do clean installs of both OS 9 and OS 10.4.11. But like many such projects here, the iBook continues to await that attention without complaint.

So yes, do please keep us all posted on any progress & your findings.

http://macintoshgarden.org/apps/mac-os-9x-project-replace-existing-page

Have big fun! (Quirky’s good.)

[ssp3]

I'm still thinking if there's some process to manually update 9.0 to 9.1 by just replacing all the necessary files, that may be the best route. I've never heard of that done before, but I don't see why you couldn't do it given how modular and straightforward OS 9 seems to be from a system file perspective.

IIRC, there were some significant changes from 9.0.4 to 9.1. What exactly, I don't remember, but let me give you two examples:
1. Long time ago, my G4 accelerated PM8500 could run 9.0.4 but not 9.1
2. SheepShaver works with 9.0.4 image, but not with anything 9.1-9.2.2

Maybe the same applies to DP2. Do some research, or, maybe, some developers can chime in.

[Jubadub]

I'm still thinking if there's some process to manually update 9.0 to 9.1 by just replacing all the necessary files, that may be the best route. I've never heard of that done before, but I don't see why you couldn't do it given how modular and straightforward OS 9 seems to be from a system file perspective.

If I'm not mistaken, you just might be able to attempt that by simply going to the System folder, then overwrite the 9.0.4 files with 9.1 ones. At minimum, you will need to overwrite "System" AFAIK. Probably a good idea to also try overwriting "Finder". You can consider doing that with other "System suitcases" there, as well, but I suggest you do this one file at a time, and in the order I presented. Of course, make sure the files you will overwrite are not actually loaded/booted from at the time of overwriting.

@ssp3 IIRC 9.1 made use of hardware that gives the OS a lot more of memory protection, using the... MMU, was it? SheepShaver simply does not emulate that hardware. If this is also the case for the DP2 BlueBox, a later version of the BlueBox might take care of it, or some other form of hacking.

I also heard 9.1 did away with the ability of handling compression of the resource fork, and/or compression of PPC binaries, or both. I don't know. But another thread here on the forums suggested that maybe if the ability was brought back, the likes of After Dark should be able to run again without modifications. Not sure if Apple was incompetent there, or if, as usual, it was them being evil, particularly Steve Jobs, once again. A lot of things started breaking, and a lot of artificial walls started getting raised, as soon as Steve Jobs returned to Apple circa the System 7.5 era.

@zsn0w Did you consider trying BlueBox from DP3, DP4 and OS X Public Beta like I suggested, as well?

[zsn0w]

@zsn0w Did you consider trying BlueBox from DP3, DP4 and OS X Public Beta like I suggested, as well?

I have not, that is going to be one of the next things I try. An issue there is that 9.1 wasn't out until After the Public Beta, so I believe 10.0 was the first to actually run 9.1 in it's Classic Environment. I know for a fact DP3 runs 9.0, and DP4 gets rid of BlueBox proper, having only "Classic", although I don't think that is a major issue - they seem to just be different views of basically the same program. All this also doesn't mean that the classic support hasn't been slightly updated to be able to handle 9.1 even though it isn't on there because it wasn't officially released yet, but reinstalling all these OSes overtop of eachother is getting old. I think the best way to do this is going to be to get a bunch of 4gb CF cards so I can swap all of them in and out after installing and compare the files on the fly.

[zsn0w]

I still haven't had a ton of time to work on this. I've been playing with it when I can, but I've kind of pushed it aside while trying to fix another issue: the apparent lack of PC Card support in the OS X DP2. I really doubt that the OS doesn't support it: I have seen PCMCIA usage referenced on rhapsodyos.org on a PDQ in Rhapsody. I can't imagine that support was taken away. Instead, I bet it is an incompatibility with the specific cardbus model that the Lombard advertises to the OS. The Lombard refuses to boot from a PCMCIA CF card (VERY annoyingly), while my PDQ has no problem with the same exact card and adapter. For some reason, OpenFirmware doesn't seem to like the one in the Lombard. It reports as "cardbus" whereas the PDQ one reports as "pccard", so I have been mucking around in OF trying to see what I can do (it also could have something to do with the cards I'm using reporting themselves as "removable media". I don't believe rhapsody/OpenStep/OS X DP 2 had any support for removable drives like that? I will pick up an industrial CF that is advertised to report itself as a non-removable drive and try that. But anyway, the thing will boot from the DVD drive (which IS recognized in DP2), which is just listed in open firmware as an ATA bus disk. What is stopping me from buying a broken CD drive module, removing the drive from the little adapter plate on the end, and wiring that up to a CF Slot? It's all ATA. I don't see any reason this wouldn't work? I don't know if there are any active electronics on that little board, but maybe the Expansion Bay Module connector itself is just ATA pins over a different physical layout even? Any thoughts on this?

[robespierre]

Both the Wallstreet/PDQ and Lombard have CardBus controllers, whatever the name of the OF device is. I do not know whether they are electronically the same interface, but that would be likely.

The optical drive is PATA (well, technically it is ATAPI over ATA); the expansion bay also supports floppy drives (right?) and  batteries, and those are not ATA, so there are either additional pins or carried over another interface.

[zsn0w]

Both the Wallstreet/PDQ and Lombard have CardBus controllers, whatever the name of the OF device is. I do not know whether they are electronically the same interface, but that would be likely.

The optical drive is PATA (well, technically it is ATAPI over ATA); the expansion bay also supports floppy drives (right?) and  batteries, and those are not ATA, so there are either additional pins or carried over another interface.

I believe the cardbus on the PDQ is a slightly different model number in OpenFirmware, as well. I have never quite figured out what all the system takes into account when choosing drivers - name, model, "compatible", etc. I would assume that a PCMCIA connected CF card in True IDE mode would work on just about anything without software drivers - it's just an ATA/IDE connection over the computer's PCI bus. I can reason that cardbus may expect drivers, even if it's dropping into the PCMCIA compatibility for the CF card adapter. I don't know, though. Either way, something is majorly different with how OpenFirmware handles the two because it will not boot off of the Lombard's card slot even if I try to force it.


The physical connections between the expansion bays and modules are different from Wallstreet/PDQ to Lombard/Pismo, not just the physical dimensions of the modules. Apple did not have a floppy drive for the latter, and I don't know if any third parties did. By looks alone, I'm assuming that these are only an ATAPI connection while the former may be some sort of SCSI bridge if it isn't just the pins for both floppies and ATAPI put together in one connector. I have only seen CD, DVD, hard drives, and Batteries (different connector in the same bay). I have read about Zip drives and VST SuperDisks, but I don't know if those were ever made for the Lombards and Pismos or just the Wallstreets and PDQs.

I'm going to disassemble my DVD drives a bit to take a look when I get home from work.