Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Irisman]

  I was merely wondering if you'll hit some sort of practical limit for simultaneous instances/instruments depending on what you do with your gained RAM.  Perhaps CPU bandwidth is still going to be the primary bottleneck anyway.  You seem like the right person for the task though!

I don't want to go off topic into a very important thread like this, but in short:
I only use two virtual instruments, a Synth (NI FM7) and a Sampler (NI Kompakt) in Cubase VST 5. My main computer is a  Single 1.5Ghz MDD. It can open up to 10 instances of FM7 with over 128 notes of polyphony.By the other way,  It can open up to 3 instances of Kompakt with up to 24 instruments at the same time, but this is limited by the amount of RAM available, If I load a 1.5 Gb piano, there is no room for any other instrument. I had a song in stand by for months, because I have reached the maximun instruments load before ending the song. Yesterday I have restarted the work because now  I could add one or two more instruments whit this 128 Mb extra ( a church organ BTW)    ...

I'd like to listen when finished 😁

[DieHard]

When you tell us we are at "Max RAM Version" ROM...

We will make a new thread with machines tested and detailed instructions

[MacOS Plus]

The process is pretty straight forward and has to be implemented Manually at the moment...
1) Own an MDD FW400 System (Only one really tested so far)
2) Replace "ROM" file with ELN/NanoPico Limit breaking ROM and reboot
3) cross your fingers and test your apps

Although not tested extensively, the ROM has been booted with no issue on the following machines and worked.
PowerMac G4 AGP with GigaDesign CPU upgrade and 2 GB RAM.
PowerBook G3 (Bronze Keyboard)
PowerMac QS

Again remember not a lot of testing, but simple testing.  Almost no extensions used for testing.

  Also, from my postings above, Sawtooth/1.75GB RAM/Sonnet Dual 1.8GHz, MDD FW800/2GB RAM/Sonnet Dual 1.8GHz, Xserve Rev.1/2GB RAM/Dual 1.0GHz.  (Known hardware limitations unrelated to RAM on FW800 and Xserve still apply at this time, plus Xserve requires two Open Firmware commands prior to boot in order to disable the Promise ATA controllers - CD ATA channel or Firewire boot fine then.)  My normal full set of extensions was used to boot each system.  All of these machines have so far exhibited no abnormal behavior for me, but I still need to perform a suitable 'stress test' that actually accesses the additional 128MB of RAM.  I guess I need to follow MacTron's lead...

  I also did a basic boot test of the ROM on a Quicksilver with Giga Designs Dual 1.8GHz CPU just to see if it would work at all before moving on to the other machines.  QS can only have 1.5GB of RAM installed due to the timing limitations in the official industry specification of the required PC133 DIMMs, hence why this machine has only three RAM slots.  G4 Digital Audio has the same limitation.  Sawtooth and Gigabit Ethernet models support 2GB because they have four slots running at the slower PC100 timing.

  In summary, with the replacement Mac OS ROM file and without any alterations to extensions, you should be able to boot the following machines with more than 1.5GB of physical RAM installed:

- G4 AGP "Sawtooth"
- G4 Gigabit Ethernet
- G4 Quicksilver (both revisions)
- G4 MDD FW400 and FW800

  Keep in mind, as I experienced with my Sawtooth, that these Macs are notorious for often being extremely picky about what brands of RAM and timings they will accept.  Once you get a config that the memory controller accepts you should be home-free.  It's just getting that far that could be challenging right off the top.  The same goes for whether or not you wish to run with a third-party CPU upgrade.  It should have no bearing on your functionality if you've already got it working properly and booting normally before you test the replacement Mac OS ROM file.  Basically what I'm saying is, get your computer booting Mac OS 9.2.2 properly with all the hardware you want, ensuring the extra RAM is recognized by the computer and the OS BEFORE you try the new ROM file.  The only difference you should see at that point is that the Mac OS will include the extra 128MB of RAM in it's available RAM figure.  You should still see any additional physical RAM reported as present without the new ROM, just not available to the OS to use.

  BTW, the dual 1.8GHz Giga Designs upgrade isn't necessarily the best choice available for OS 9 since the CPU patch for OS 9 booting is volatile because it is held only in PRAM.  If it is lost you have to boot into OS X to re-run the OS 9 patch from there.  (The OS X patch is separately applied in firmware, therefore not volatile.)  Sonnet's firmware patch on the other hand is not volatile and supports booting both OS's.  I personally have chosen to avoid unnecessary aggravation by sticking with Sonnet upgrades for my OS 9-booting G4s and relegating my Giga-upgraded Quicksilver to OS X duties.

  If anyone experiences anything different to what I have said in terms of difficulties, please be sure to post details in this forum thread.  Alright members - get to testing!

[ELN]

MacOS Plus, have you tried that last ROM on your 9serve without the pre-patching? I integrated some patches into the boot script that should help. The same goes for G4 upgrades.

[MacOS Plus]

MacOS Plus, have you tried that last ROM on your 9serve without the pre-patching? I integrated some patches into the boot script that should help. The same goes for G4 upgrades.

  Are you referring to the ATA device disable issue on the 9serve?  And are you saying G4 upgrades may boot to OS 9 without their originally-provided OS 9 specific patches (if they were a separate patch from firmware)?  I didn't try it with the Giga Designs without their OS 9 PRAM patch applied, if that's what you mean.  I can try it again that way.

[nanopico]

MacOS Plus, have you tried that last ROM on your 9serve without the pre-patching? I integrated some patches into the boot script that should help. The same goes for G4 upgrades.

  Are you referring to the ATA device disable issue on the 9serve?  And are you saying G4 upgrades may boot to OS 9 without their originally-provided OS 9 specific patches (if they were a separate patch from firmware)?  I didn't try it with the Giga Designs without their OS 9 PRAM patch applied, if that's what you mean.  I can try it again that way.

The patch should be allowing G4 CPU upgrades such as the GigaDesign to boot without any OF/PRAM patching.

MacOS Plus, have you tried that last ROM on your 9serve without the pre-patching? I integrated some patches into the boot script that should help. The same goes for G4 upgrades.

This is just the CPU patch I had provided a while back correct?
Or have you added the stuff to drop the additional OF nodes required to boot the Xserve?  Not something I recall having ever discussed, but if you did add it then thumb up!  If not I'll provide something to you to integrate it.

[ELN]

Are you referring to the ATA device disable issue on the 9serve?  And are you saying G4 upgrades may boot to OS 9 without their originally-provided OS 9 specific patches (if they were a separate patch from firmware)?

That's right -- not that I've actually tested those configurations.

This is just the CPU patch I had provided a while back correct?
Or have you added the stuff to drop the additional OF nodes required to boot the Xserve?  Not something I recall having ever discussed, but if you did add it then thumb up!  If not I'll provide something to you to integrate it.

The very one. It took a while because I wanted to support build-time conditionals in the boot script. So this is what the relevant parts of BootScript.fs look like.

Code: [Select]

{TbxiPatchG4Version} if
" /cpus/PowerPC,G4@0" find-package if
  " /cpus/PowerPC,G4@0" select-dev
  " cpu-version" active-package get-package-property 0= if
     decode-int
     2swap
     2drop
     80010201 <
     0= if
       80010201 encode-int " cpu-version" property
     then
  then
  device-end
then
then


Code: [Select]

{TbxiDisableAppleKiwi} if
" /pci@F2000000/AppleKiwi@15" find-package if delete-node then
" /pci@F2000000/AppleKiwi@1b" find-package if delete-node then
then


[MacOS Plus]

  I didn't know you guys had sorted out how to perform the Kiwi ATA device disable automatically.  This is awesome because I was getting pretty tired of having to go into OF and type the commands in manually every single boot!  Until such time as we make more headway on supporting the Kiwi ATA on the 9serve, this auto-disable will make it so much easier to test anything else on this machine.  And so, I can report to you that this code did allow the 9serve to boot automatically using the CD ATA channel or firewire as before.  This alone is great for my purposes already.

  The Quicksilver with Giga Designs dual 7447a didn't work without their PRAM patch still in place.  It halts at the bright grey screen before the mouse pointer would appear.  I figure I'll have to set up a telnet connection to log what's happening, which I already know how to do from the early days of testing the 9serve.  One other thing to mention is that neither the stock Apple CPU Plugins file nor the hacked Sonnet version in the Multiprocessing folder allow a complete boot with the Giga Designs CPU.  It appears they never figured out the issue for themselves.  In order to boot OS 9 with that CPU, it's single mode only.  (Well, at least until we crack that nut too.)

[ELN]

Glad it worked! I don't want to get too side-tracked here, but I think we need a better resource to document our solutions for unsupported hardware configurations. When I built that Wedge ROM, with several new features enabled, I had the thought that a control panel to switch them on and off would be useful. Any thoughts? Maybe we should start another thread.

Also, would you mind posting, or directing me to, the various PRAM patch utilities for the several accelerator cards?

[MacTron]

I have started a thread about the The Apple CPU Plugins file and the 7447/7448:

http://macos9lives.com/smforum/index.php?topic=3878.msg26161#msg26161

[Knezzen]

This is a bit off topic to the thread, but near the mods of the ROM to get the Xserve booting without the hacking.

I would love to see the "OS9 Helper" patches applied as well, so Old World machines could benefit of the universal Mac OS 9.2.2 install.
This would make it truly universal. I'm going through the 9.1 to 9.2.1 to 9.2.2 upgrade procedure myself right now and would love to have something on hand that just works on my PowerBook G3 Kanga and PowerMac 9500 (with a Sonnet G3 upgrade).

[MacOS Plus]

  One thing I was never certain of - are the modifications applied by OS9 Helper specific to the particular target machine?  I thought that was why you had to process the changes to the Mac OS updaters locally on the target machine.  Also, do these modifications then break compatibility with other machine versions?

  Also mildly off-topic but potentially somewhat related to your request, I wonder if any of the extensive notes on the following webpage would be of use in creating as stable and widely compatible a system as possible?

http://www.sunrisepage.com/computers/macclassic/macos9.htm

  Even the "hybrid" section might yield some useful information.  (I'm not suggesting we automatically take big steps backwards, just consider what works best and avoids file corruption.)

[DieHard]

 
  Also mildly off-topic but potentially somewhat related to your request, I wonder if any of the extensive notes on the following webpage would be of use in creating as stable and widely compatible a system as possible?

http://www.sunrisepage.com/computers/macclassic/macos9.htm

We have gone over that paper many times... most of it is not applicable, some of it is flawed, however, increasing the memory of the finder is a great suggestion... I thing we have some old threads breaking it down

[Knezzen]

One thing I was never certain of - are the modifications applied by OS9 Helper specific to the particular target machine?  I thought that was why you had to process the changes to the Mac OS updaters locally on the target machine.  Also, do these modifications then break compatibility with other machine versions?

I'm pretty sure it's not machine specific more than that there are different "patches" for NuBus and PCI Old World machines.
When you run OS9 Helper you get to choose if you're installing on a NuBus or PCI PowerMac, so I think they somehow needs to be patched differently. I don't have anything that boots 9.2.2 that isn't the last OS9 capable machine (needing special versions, like the MDD), or unsupported and needs OS9 helper (like the Kanga and 9500). So if anyone has an early TiBook or Pismo that can boot with the original 9.2.2 ROM, I can post the pached files on my Kanga so you can see if it works. If is does, we should incorporate the (PCI) patches to the "universal" Mac OS 9.2.2. I don't think there's any need to incorporate the NuBus patches and I think they are incompatible with the PCI paches since you choose what kind of machine you have (see screenshot).

I think this would be a great addition if any Mac with a PowerPC processor and PCI slots could boot the universal 9.2.2.

About OS9 Helper from the Readme file:

On the day that Apple released the 9.2.1 update, I posted a messaged to a Macfixit Forum thread asking for anybody who was willing to help work on a crack for this. Scott emailed me back and we stayed up most of the night hacking away with ResEdit and MacsBug. After exchanging 15 or so emails, we had it mostly narrowed down to 3 resources that needed to be added/modified for 9.2.1 to work. Scott nailed the breakthough the next morning, and we were finally able to get 9.2.1 to boot on our Powersurge machines. Hastily, we posted the patch with little testing. It soon became apparent that more work was needed, as drag and drop support was not enabled. A few days later Scott and I narrowed it down to an obscure line of hex that was in a diffent physical address location than it was in 9.1, and the problem was solved. Soon thereafter I returned to college, and Scott faded away as well. But faithful forum posters kby, kenny, and the Toz took up the slack and began making more and more improvements to the patch. They have pretty much done the bulk of the patch work since 9.2.2 was released, and an excellent job they have done. After a while, I got sick of the patch method and decided to make this a little bit more commercially viable and easier to understand. Thus OS9 Helper was born. Over the next year or so I hope to evolve the utility to have more and more functionality.

[MacOS Plus]

  Okay, cool.  I'd read that many years ago but it only came to mind now because it came up coincidently from a web search I was doing related to OS9 Helper.  I figured some of it was a bit nuts.  Glad to hear it's been read over by the members though for any useful tidbits.  I agree increasing the default memory allocation to the Finder is a good idea, although the same could be said for many of the third-party apps too.  Most users intending to carry on with OS 9 today likely have plenty of RAM available, certainly considering our recent 'gain'.

[DieHard]

  I agree increasing the default memory allocation to the Finder is a good idea, although the same could be said for many of the third-party apps too.  Most users intending to carry on with OS 9 today likely have plenty of RAM available, certainly considering our recent 'gain'.

Yes, but the difference being that you cannot simply "CMD-I" and change the memory, you need to resedit the finder, maybe mactron, can attach a modified one for newbies

[Daniel]

The OS9 Helper patches probably are for the System Suitcase rather than the Mac OS ROM file. As far as I know, there are no projects that have reverse-engineered the System Suitcase anywhere near as much as the Mac OS ROM file is disassembled (if there are any projects to understand the Suitcase at all). Sometime after we get the full 2 GB working without side effects we should create a CDG5 for the System Suitcase.

[MacTron]

The OS9 Helper patches probably are for the System Suitcase rather than the Mac OS ROM file.

That's true. The OS9 Helper basically restore some drivers and resources from 9.1, that were deliberately removed from Mac Os 9.2 to disable the 9.2 boot into OldWorld macs.

... maybe mactron, can attach a modified one for newbies

I can attach a couple of resources that should be pasted with ResEdit into System and Finder files... that's all

But both topics should be splitted from this thread. IMHO 

[macStuff]

  On a related note, have you seen how freaking dirt-cheap PC133 512MB DIMMs are on eBay now?!?  I just bought 16 of them for USD $3.49 a piece and free shipping direct from China. 

wow that is news to me! that is almost free! can you share the sellers name??

is there anyway of benchmarking specific ram chips ?
i mean to literally test the ram? not just if it works correctly,
but also to test the speed? i know theres different nanosecond times associated with ram?
ie: you could have a few peices of the same rating/size (pc133, 512mb for example)
but some from a specific manufacturer or even a specific batch of chips may perform better? is there anyway to benchmark specific peices of ram?

[MacOS Plus]

  On a related note, have you seen how freaking dirt-cheap PC133 512MB DIMMs are on eBay now?!?  I just bought 16 of them for USD $3.49 a piece and free shipping direct from China. 

wow that is news to me! that is almost free! can you share the sellers name??

is there anyway of benchmarking specific ram chips ?
i mean to literally test the ram? not just if it works correctly,
but also to test the speed? i know theres different nanosecond times associated with ram?
ie: you could have a few peices of the same rating/size (pc133, 512mb for example)
but some from a specific manufacturer or even a specific batch of chips may perform better? is there anyway to benchmark specific peices of ram?

  There are many different eBay sellers with this RAM at very low cost.  (The seller's name was "access-market".)  I should note that I never received my shipment because the package got destroyed in transit due to a vehicle accident.  I was fully refunded however.  I did get a different shipment of DDR RAM though.  It was almost as cheap.  That seller's name was "ssffkeep".  As expected, the super-picky G4 MDDs and Xserves rejected some of the sticks even though they were all identical - 5 out of 20 sticks.  It cost so little, I hardly care.  The others will go in my 'not-picky' PC motherboards.

  I too would like to know of a decent RAM testing app for Mac PowerPC, OS 9 or OS X.  It would be nice to have a utility that can read the timing chips on the sticks, like is available on PC.  I'm concerned much less about performance than I am about the sticks not causing weird system behavior.  I've been able to determine that RAM was responsible for random finder crashes and system freezes on one machine even though the system never explicitly complained about problem RAM.