Mac OS 9 booting on: Mac mini G4 (Detailed Posts)

[MacTron]

DarthnVader,
I am guessing Mactron was up all night at the M.A.R.L. facility copying and pasting code, then testing on his many G4s.... hehe

Unfortunately this stuff is beyond my capabilities ...
... even it takes me some effort to follow some threads like this ...

[solderwire]

Finally got Simplified Chinese version of 9.2.2 running on my Mac mini G4
Just replace display drivers, ROM file, and delete the Multiprocessing folder
With an 120 GB hard drive, I installed Tiger on it, and I am planning to make tri-boot (OS 9, Tiger and Leopard) for software compatibilities.
And I also need to add some Chinese translation to the Mac OS ROM.

[DieHard]

*** Interesting Update on Intermittent "Frozen Mouse" Issue ***

So, the mouse issue, at times the mini has an issue, as reported my many, where the mouse cursor is frozen in one position, yet the machine is not locked up and the mouse "click" still responds, yet mouse cannot move.

So rather than use my programmed shutdown F6 key (thanks Ross); I decided leave the mouse in the "frozen" mode and plug into the key board an original "white" Genuine single click apple mouse (into my genuine apple keyboard) and VIOLA... full mouse support !   The non-apple mouse still frozen with a working click and the apple mouse working 100% !

Ok... now the weirdness...  I decided then, without rebooting... to unplug the Dead aftermarket mouse from USB1 and put the Genuine apple on USB1... I really expected it NOT to work, but VIOLA, it works perfectly !  Switched them again, without restarting and the 3rd party mouse is working again... so the apple mouse reset the frozen Jam-up.  So, my dear Gurus, if we can tell Open firmware that the mouse is a Genuine Apple mouse, I think we will have no more "Frozen Mouse"

LASTLY, we need to ask ALL mini users, are the using USB Overdrive (since it has a modified USB Mouse driver) or the stock 9.2.2 driver.  I am going to see if I get the freeze-up with the USB overdrive extensions turned off

[FdB]

No frozen meese here, ever. Always using the original,
genuine Apple mouse and zero use of USB overdrive.
Voilà!

Now, if I could just get away from option-booting between OS9 and OS X...
(and the clock time-shift weirdness between the two) I'd be extremely hap-hap-happy!

[macStuff]

Finally got Simplified Chinese version of 9.2.2 running on my Mac mini G4

congrats Solderwire!
"to boldly go where none have gone before!"
heheh 

[IIO]

So, my dear Gurus, if we can tell Open firmware that the mouse is a Genuine Apple mouse, I think we will have no more "Frozen Mouse"

i am afraid that it will also act like an apple mouse when you do that, but interesting find.

[DieHard]

I meant for the Non-Apple mouse, to tell OF that the mouse was a Genuine Apple mouse, when it is in fact a generic

[IIO]

i know what you mean, but that "mouse" is the INIT of usboverdrive, isnt it?

[DieHard]

Obviously, since I changed no other settings, it is "seeing" the 2 devices differently regardless or the default setting

[darthnVader]

OF doesn't really care what mouse we use, seems to be Apple's USBhid driver.

We could give Open Firmware the Apple Vendor and Product ID's, but most of the time OS 9 drivers are wise to these sort of hacks. I've noted with PCI Device ID's that overriding them in OF, OS X will use the property you hack onto the Device Tree, while OS 9 drivers will poll the hardware.

Now if it is a property built into the device tree by the Boot ROM or an Option ROM, OS 9 is none the wiser about changes made to those sort of properties.

OS X is wise to PVR hacks, mach_kernel reads the PVR value from the CPU, not the device tree, however OS 9 will just take whatever value we give the CPU in the device tree.

I'll check and see what info we can hack about our mices

Adding to the confusion OF builds properties for the via-pmu adb mouse, the pseudo-hid mouse, and the USB mouse.

I would assume that the classic Mac OS have some deep hooks for ADB.

[ELN]

OS X is wise to PVR hacks, mach_kernel reads the PVR value from the CPU, not the device tree, however OS 9 will just take whatever value we give the CPU in the device tree.

The NanoKernel and the CPU Plugin seem to be exceptions: they ignore the device tree (the NK would have trouble even accessing it), and use the PVR directly. This is actually quite annoying, because it makes a NanoKernel patch necessary to support full power management on a new CPU.

Unfortunately, issuing an "mtpvr" instruction has no effect (it actually crashes QEMU).

[ELN]

RossDarker,

I've just been refamiliarising myself with iMic's excellent ROMs for unsupported machines. He included the extension "Insomnia" to prevent those machines from sleeping that would crash. Instead of omitting the important Apple CPU Plugins file from the default install, could you please include Insomnia?

Great work on that CD, by the way. I used it recently to set up my own mini!

[RossDarker]

Thanks. Yes I will put this in both CD and the install I guess. I cannot find this extension however. If you can link me to it I can start making v6 of the CD. Does this mean that if you try to sleep, even with Multiprocessing and Insomnia extension in, it will stop you from sleeping?

[RossDarker]

Wait I just found the Insomnia extension with "1021v1_Generic_ROM.sit". I'll get making.

[RossDarker]

Ok I see so the extensions prevents it from automatically sleeping I think. Is there a way to remove the Sleep option from the Special menu from the Finder? This would be great because then no one will even be able to accidentally sleep the machine.

[ELN]

It's certainly possible to remove it, but I'm not very keen to dive into that. I'd rather keep the pressure on to get sleep working!

[ELN]

I have an idea about the mouse pointer problem. Here's what information seems to be available on the forum:

• The issue can affect more late-G4 machines than just the mini.
• Fiddling with the USB bus can work around the problem.
• Any brand of mouse can be affected, and USB Overdrive is not a factor.
• A System Enabler in the Mac OS ROM file does not help (sorry about that!).
• The Application Switcher extension is not the cause (sorry about that too).

Here's what else I know:

• The "Custer" 10.2.1 ROM, released with the FW400 MDDs, contains only two significant changes: the backlight parcel, and the USBShimKeyboard resource.
• I once reproduced the problem on my FW800-cum-400 MDD using a hacked ROM with the following properties: no System Enabler, 9.6.1 binaries, and possibly the mini prim-info patch (although I doubt that last one).

Could it be that the new USBShimKeyboard contains a fix to this very problem? Let's give it a go! Attached is a ROM file containing the new resource.

[MacTron]

Ok I see so the extensions prevents it from automatically sleeping I think. Is there a way to remove the Sleep option from the Special menu from the Finder? This would be great because then no one will even be able to accidentally sleep the machine.

Replacing Energy Saver control panel by Sleeper this issue is solved because Sleeper control pannel disable CPU sleep from the main menu also, while alow the HD and display to sleep and wake up as usually.
This is a good solution because 7447 and 7448 don't actually need CPU sleep as it have frecuency scalling tecnology, IIRC.

[IIO]

Ok I see so the extensions prevents it from automatically sleeping I think. Is there a way to remove the Sleep option from the Special menu from the Finder? This would be great because then no one will even be able to accidentally sleep the machine.

the easiest way to remove a menu entry (without causing disorder of the items or bringing up errors when it is missing) is to rename the item to --- which will turn it into a dividerline, i.e. the item is still present but noone can accidentially click it (or its set command key combination)

[DieHard]

he easiest way to remove a menu entry (without causing disorder of the items or bringing up errors when it is missing) is to rename the item to --- which will turn it into a dividerline, i.e. the item is still present but noone can accidentially click it (or its set command key combination)

Interesting, I will try that