Mac OS 9 Lives

Classic Mac OS Software => Hacking the System, Mac OS 9.3, and Beyond ! => Topic started by: nanopico on November 19, 2015, 08:21:24 PM

Title: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: nanopico on November 19, 2015, 08:21:24 PM
So you install 2 GB of ram and OS 9.  Then you go to about this mac and you see that hey the system recognizes that there is 2GB of ram!!! And you get all excited until you notice that Mac OS takes up 512-540 MB (give or take) 
This is not new I know.  DieHard pointed the out to me and directed me towards this discussion
http://macos9lives.com/smforum/index.php?topic=2101.msg10905#msg10905

I've posted elsewhere some theory's I had while examining memory.
So using an iBook with 320 MB of ram I found that the system heap and stack along with some rom space and some other system stuff sits at the bottom of ram (starting at or around address 00002800).  Once the process manager starts it claims the rest of the memory for it's heap except for a little bit at the top which it is allocated for it's stack.
For those of you who don't know, the heap is the working memory where your data is stored and the stack is the memory where the actually executable code is stored.  Because os 9 does not have protected memory you can write apps that pretty much read anything.  With protected memory apps are usually given a virtual address space so it thinks it starts at address 0 the os then translate that to physical addresses.  The heap for the app is then marked as non-executable though on some systems you can override that ins some creative ways.
Back on track though.  So when the system boots it get's the ram size information from Open Firmware.  The memory manager I believe starts before the process manager (don't quote me on that as I haven't confirmed this yet). So the os is fully aware at this point of the 2 GB installed.  Depending on which starts first will be where the ram get's allocated to the process manager. When about this mac shows that MacOS takes 540 MB it's actually not really true.
Looking at the heaps and stack allocations, the system files are still only taking 30-40 or whatever your system uses depending on extensions and what not.
For MacOS memory usage (which is not handled by the process manager) it takes the total ram installed and subtracts what is allocated to the process manager, and assumes what is left is allocated to the system.
So that is where the number comes from.
So poking around with MacsBug you can look at what is in the ram above 1.5 gb.  Guys what there is nothing (no surprise there).  It's all initialized to zero.
So next step is to write a program to put data into memory addresses above the 1.GB limit.
Then use MacsBug to verify it is there.  If that works then it tells us that the memory is addressable and the potential of some sort of ram disk up there is possible (though not necessarily easy in any way).
Just thought I'd share this bit of info.
Title: Re: 1.5GB Limit (some answers)
Post by: DieHard on November 20, 2015, 09:19:07 AM
Wow.... you kinda remind me of iMic's brother... you are going where nobody went before.. Awesome work ! :)
Title: Re: 1.5GB Limit (some answers)
Post by: nanopico on November 20, 2015, 09:31:32 AM
Thanks. I just hope I can actually produce something with all my findings.
Title: Re: 1.5GB Limit (some answers)
Post by: Philgood on November 20, 2015, 11:07:30 AM
Let's get started!
Will 2016 be the year of somewhat bigger for our beloved OS9...maybe we can get the attention of some former Apple engineers to help us
Title: Re: 1.5GB Limit (some answers)
Post by: MacTron on November 20, 2015, 11:16:35 AM
For MacOS memory usage (which is not handled by the process manager) it takes the total ram installed and subtracts what is allocated to the process manager, and assumes what is left is allocated to the system.
So that is where the number comes from.
So poking around with MacsBug you can look at what is in the ram above 1.5 gb.  Guys what there is nothing (no surprise there).  It's all initialized to zero.
So next step is to write a program to put data into memory addresses above the 1.GB limit.
Then use MacsBug to verify it is there.  If that works then it tells us that the memory is addressable and the potential of some sort of ram disk up there is possible (though not necessarily easy in any way).
Just thought I'd share this bit of info.

This is becoming into something really interesting ...  :)
Title: Re: 1.5GB Limit (some questions]
Post by: greatinterface on November 20, 2015, 08:08:42 PM
lets get those 2 gigs working ,just picked up a lovely 23 inch apple display for $50 on craigs list ,bad news my scripts did not copy properly on the boot disc for my "drive cloning"  aka restore project ,will have to try unstuffing on different machine
Title: Re: 1.5GB Limit (some answers)
Post by: nanopico on November 20, 2015, 08:47:01 PM
Another fun update.
A. I'm still not sure how the hardware MMU plays into this whole thing.  Not sure if OS 9 initializes that differently than OS x or it has something odd to do with maybe it's using a signed int for memory address (that would be odd and not fun to break). I only mention this because hardware is also placed with in the address space accessed by the MMU and you should keep that in mind with the next part.

B.  I have a fun utility/crude app I wrote to do some memory test from with in the OS.
  I'm going to share it with anyone who want's to play with it, but first some disclaimers.
1.  It's a very crude, basic app with no error checking/handling.  Yes it's easy to crash it (and actually that's part of the intent for what I'm doing with it.
2.  The user has control of the memory it accesses. So if you put in an address that is mapped to firmware, video card, any other hardware, then it will write some data to it and it very well could break things.  Just so you know.

So this app doesn't directly cause harm unless the user enters and address that could corrupt things.

So here's what it does. 
When it loads it loads with a heap size between 512K and 1MB.
Once loaded it try's to allocated a chunk of memory that is 10 MB in size.  This is using built in system calls for memory.  Since the heap is way under 10 MB this allocation request fails which is exactly what it should do.
Next it asks the you for a memory address.  You must enter it in hexadecimal.  There is no error checking on that so if you enter a non-hex value it will probably crash on that. Since this is fairly useless of an app and more of a test I'm not going to fix that.
After you provide it an address it starts at that address and writes a 32bit integer to the address, moves to the next address writes an integer 1 larger than the previous, ...etc  until it has done this for 10 mb.
If the memory is addressed that test will pass and it will move on to read that data and compare it to what it put in.  If something doesn't match it will give you the address it didn't match.
That's it.  For memory with in the 1.5 gb range and that isn't allocated to anything this all passes as it should (being that the first one fails intentionaly. 
All this really does is determine if a specific memory address is accessible from an application without using the OS memory/process manager routines. 

So in using it I've found that with in the 1.5 GB limit or what the max ram of your machine is, all this works.   Trying to access ram above 1.5 gb fails.  Not sure why yet, but it flat out failed. So from within an application that extra 512 mb is not accessible, yet.

Also just a few other disclaimers.
Putting addresses below 60 mb or so will crash/lock up your system.  On some of my test it grey screened and locked up, some froze the display and then locked up.  In both cases it messed up macsbug enough that I couldn't even enter it.  So please use caution when using this.  I am absolutely not responsible if you brick your system using this. 

Have fun.
Title: Re: 1.5GB Limit (some answers)
Post by: DieHard on November 20, 2015, 08:54:51 PM
Gonna have to fire up a G4 this weekend and crash it a bunch of times, sounds like fun, thanks nanopico
Title: Re: 1.5GB Limit (some answers)
Post by: nanopico on November 20, 2015, 09:13:21 PM
One address I can say don't use is 0x10 (16 decimal) 
It didn't really screw anything up major, but it took a few reboots before my iBook would boot up.  Have fun with it.
Title: Re: 1.5GB Limit (some answers)
Post by: nanopico on November 21, 2015, 07:42:49 PM
One small correction.
I stated that the little utility I posted tried to write 10 MB of data to a place of your choosing.
That was wrong.  The first version I wrote used a 8 bit pointer so it did write 10 MB.  The version I posted uses a 32 bit pointer, so it writes 40 MB.
Just wanted to clarify that for any one trying it.
Title: Re: 1.5GB Limit (some answers)
Post by: nanopico on December 04, 2015, 08:27:07 PM
So after further investigation I've discovered a few things.
The reason the test app I wrote couldn't access the empty ram above 1.5 GB was due to the MMU.
I'm going to over simplify this a bit but I'm going to hit the pertinent parts.
Open Firmware Starts the machine and initialized a bunch of hardware.
The device tree defines the ram sockets and provides info as to what is installed in each socket.  This is why  you see 2 GB in about this mac.
This is also why apple profiler shows the correct amount of ram in each slot.

Next the rom is loaded and starts initializing a bunch of stuff.
The first thing that starts is the resource manager, then a bunch of other stuff get's initialized.
Then a simple memory manager get's started. This initializes the stack for the system components (this is what's sitting in the lower part of ram).

Now the last few things that happen during boot right before the finder is launched is where our issue starts to happen.  Once extensions are all loaded the last thing that happens is the process manager is started.  The simple memory manager from earlier calculates what has been allocated for the various system components and the system stack and heap and all that fun stuff.  And then at the top of all that stuff is the start of ram allocated to the process manager.  When the process manager get's loaded what ever loads it is setting it's limit to 1.5 gb - the system heap and stack.  The process manager then starts it's own memory manager for allocating space to other apps with in it's heap.  When the MMU is setup it maps the physical ram address to the virtual addresses.  So virtual address 0x00000000 is physical address 0x00000000 of ram.  The MMU's mapping end's the virtual ram address space at 1.5 gb which is why access above that is limited or not available.  Where ever the MMU get's initialized during and after rom boot is the location of the code that needs to be patched.
This is why the access violation errors get thrown in my test program.


Okay so that's a bit rambly.  But the point is when the heap get's allocated for the process manager is when the 1.5 gb limit is being set so it starts to narrow down the search and what needs to be modified to get this limit raised.

I also found another interesting tidbit in working through this.  There is something mapped in the upper part of ram near the 4GB mark.  This would be the absolute physical limit and as the MMU's in these machines are 32bit there will be no way to go above that.  I'm suspecting that the stuff up by the 4gb limit are the address to the hardware registers (the ports and address of the graphics card for example).

I'll stop rambling now.
Title: Re: 1.5GB Limit (some answers)
Post by: GaryN on December 04, 2015, 11:31:26 PM
Ramble on anytime, man. Possibly a few of us blockheads might learn something!
Title: Re: 1.5GB Limit (some answers)
Post by: mrhappy on December 05, 2015, 04:13:29 AM
Yes indeed!! ;D
Title: Re: 1.5GB Limit (some answers)
Post by: nanopico on December 06, 2015, 08:29:36 AM
Except some of my ramblings are incorrect while I figure this stuff out. (though they are getting more accurate the further down the rabbit hole I go).
Ramble on anytime, man. Possibly a few of us blockheads might learn something!

I think I might have a possible explanation for the 1.5 GB limit.
By the time any machines could physically handle 2GB of ram, OS X was already in the works.
It was probably though as a low priority to re-write/patch the memory manager/process manager to allow more ram.  Why there was a limit in the first place is beyond me.
But what lead me to the 1.5 GB limit reason is the 9600.  Even though official support was 756 MB apple was probably aware that it could handle 1.5 GB. At that time any of the next generation OS's where in such early stages there was no foreseeable future.  Customers would probably complain if they couldn't use all the ram so the parts of the os that handle that would have been updated and the 1.5 GB limit was probably chosen for that reason.

Again just speculation, but after having worked on all sorts of dev project the past 15 years I can say these things do happen a lot with out much forward thought.



Title: Re: 1.5GB Limit (some answers)
Post by: nanopico on December 07, 2015, 12:43:16 PM
So I've been studying the CPU registers that control the MMU (memory management unit).
So the Block Address Translation tables are pointed to by CPU registers. These control the mapping of the addresses from what applications see to physical hardware address. They are only accessible from code executing in the Supervisory context of the processor (usually this is the os) and the guest process (user programs) as some access to this.  Not all OS's use the guest process for running applications though.  This might actually be the case with the Mac OS as that is usually needed to provide protected memory (which will all know is non-existent in OS 9) but I really don't know right now the reality of this.  At a minimum I can read most of those.  So next step is reading in these tables and seeing what's mapped where and this will give a more definitive idea of what is located where in memory.

One small kill joy though.  The PPC spec that explains the MMU registers does have some notes about 64bit cpu's (the G5).  So some of the Opcodes for accessing the registers are explicitly not supported on 64bit cpus even if the cpu is running in 32 bit mode.  In OS X the memory management routines probably account for this which is why on the G5 you could have more than 4GB of ram in a 32bit os.  OS 9 probably did depend on some if not all of these 32bit only opcodes and registers.  So we now have two major hardware roadblocks to overcome if there is ever any hope of G5 support.  1. the mmu opcodes/registers and 2. the UniNorth 3 bridge.

Also in looking through this I looked more at the PVR and PIR registers.  (these are the Processor ID and Processor Version).
The cpu upgrades that update open firmware through nvram scripts to get newer g4 cpus working, are modifying these.
So now that I know the registers I can find where Mac OS checks those registers.  Then it should help in looking for the list of values the register is compared against to update that to get more cpu's support with out nvram scripts or changing values in open firmware.

Title: Re: 1.5GB Limit (some answers)
Post by: DieHard on December 07, 2015, 02:08:02 PM
I live for these updates on the progress, and appreciate all the details

Thanks... :)
Title: Re: 1.5GB Limit (some answers)
Post by: nanopico on December 07, 2015, 02:56:04 PM
I live for these updates on the progress, and appreciate all the details

Thanks... :)

Thanks.  I'm starting to get to the point where it is shifting from theoretical to actual.  I'm definitely running into things that I have a hard time understanding the reasoning for, which make's it a little hard to explain.  But man this is getting to be real fun.
Title: Re: 1.5GB Limit (some answers)
Post by: nanopico on December 16, 2015, 06:32:51 AM
Tiny update  here.

Macsbug thinks there is no mmu installed on g3's and g4's. This would indicate that it might not be running in the supervisor level of the cpu (though as a low level debugger I find that kind of hard to believe).  This makes it kind of hard to use to view the mmu registers which control all the pages and maps and segments and fun stuff.  It might just be that macsbug (being that it was originally for the 68k macs) just doesn't know the instructions or how to access the mmu on powerpc's.

So now I have to write some assembly code to read the mmu registers and dump them out.
Once I have something working there I might ask if any one can run it on their machines and provide me the output so I can see how different configurations are mapped?  I have several machines I will run it on, but the more the merrier right?
Title: Re: 1.5GB Limit (some answers)
Post by: Protools5LEGuy on December 16, 2015, 07:54:40 AM
Count with me for any test in my 867 dual with 2Gigs of RAM
Title: Re: 1.5GB Limit (some answers)
Post by: Veneteaou on December 16, 2015, 01:15:57 PM
I've can throw in:

- G3 Clamshell iBook 300MHZ
- G4 867MHz Powerbook G4
- G3 800/900MHZ iBook
- G3 350MHz Blue & White tower

I can test it on all of those.
Title: Re: 1.5GB Limit (some answers)
Post by: GaryN on December 16, 2015, 01:38:54 PM
I'm here with:

2003 MDD M8570
Titanium Powerbook  1Ghz  A1025
Powerbook G3 Lombard M5343
Title: Re: 1.5GB Limit (some answers)
Post by: nanopico on December 16, 2015, 07:37:22 PM
Awesome guys.
With the holidays and such coming up (and my kid not having school for a week or so, making me daycare for a week!) I probably won't have anything until the beginning of January.
I'll let you know when I have something ready.
Title: Re: 1.5GB Limit (some answers)
Post by: Protools5LEGuy on May 03, 2016, 08:56:02 PM
Just wanted to add the machines that boot MacOS9 and allow 2 Gigs of RAM:

PowerMac G4 Sawtooth http://www.everymac.com/systems/apple/powermac_g4/specs/powermac_g4_450.html (http://www.everymac.com/systems/apple/powermac_g4/specs/powermac_g4_450.html)


PowerMac G4 Gigabit Ethernet http://www.everymac.com/systems/apple/powermac_g4/specs/powermac_g4_400_2.html (http://www.everymac.com/systems/apple/powermac_g4/specs/powermac_g4_400_2.html)


PowerMac G4 MDD http://www.everymac.com/systems/apple/powermac_g4/specs/powermac_g4_867_dp_mdd.html (http://www.everymac.com/systems/apple/powermac_g4/specs/powermac_g4_867_dp_mdd.html)


PowerBook G4 1.0 17" (Al) http://www.everymac.com/systems/apple/powerbook_g4/specs/powerbook_g4_1.0_17.html (http://www.everymac.com/systems/apple/powerbook_g4/specs/powerbook_g4_1.0_17.html)


I've also made this post sticky
Title: Re: 1.5GB Limit (some answers)
Post by: DieHard on May 04, 2016, 04:05:20 PM
PT5,

Thanks for the list :)

But under OS9 we are limited to 1.5 GB on ALL Models...

http://macos9lives.com/smforum/index.php?topic=2101.msg10763#msg10763
Title: Re: 1.5GB Limit (some answers)
Post by: Mat on May 04, 2016, 06:28:10 PM
PT5,

Thanks for the list :)

But under OS9 we are limited to 1.5 GB on ALL Models...

But that doesn´t change the fact that there are some Macs that allow 2 GB for other Operating Systems. And that is exactly what the list is about: Macs that boot Mac OS 9 AND allow 2GB Ram.
Title: Re: 1.5GB Limit (some answers)
Post by: DieHard on May 04, 2016, 09:09:06 PM
Just to clarify for the members new to PPC G4 Macs...

YES, many can physically handle an install of up to 2 GB RAM, and YES the OS will show 2 GB RAM, and YES, OSX can utilize the entire 2 GB, but unfortunately Mac OS 9 can only utilize 1.5 GB of the physical 2 GB RAM.
Title: Re: 1.5GB Limit (some answers)
Post by: Protools5LEGuy on May 04, 2016, 09:23:52 PM

But under OS9 we are limited to 1.5 GB on ALL Models...

http://macos9lives.com/smforum/index.php?topic=2101.msg10763#msg10763

(http://www.macos9lives.com/_img/diehardposts/macos9_2gb_256_disk.jpg)

Built-In Memory. 1.99. I want to know more about that supersized Mac OS System itself using 811.9 MB instead of 68.1MB. I am keeping the faith in that we will recover some of this memory back to the user. In fact "256" Megs are taken for the RAM disk.

I can always pull out memory to make 1.5 or even 1 Gig. of RAM, but OSX benefits from that extra 0.5 RAM.  We have 4 slots.

On the AL 1.0 GHz 17" Powerbook you have only 2 slots.

We should look if having more than 1.5 Gigs of RAM we make the system more prone to crash.

Also if 1kWindows test shows a slower system when using with more than 1.5 Gigs of RAM.

Imagine we can use that nanopico BootX loader to fool OS9 think it only has 1.5 and the virtual RAM Disk is made before loading OS9. We could call it "2 Gigs patch for OS 9" or "512 Meg RAM disk for 2 Gigs RAM". The benefits of that neglected 0.5 Gig in a RAM Disk for DAW or Photoshop would do wonders. Probably I am delusional with the possibilities.
 
OFFTOPIC: I hate to pull off memory. It reminds me an x86 P4 triple boot I had with W'98 (Needed less than 768 Megs), XP + XXX 10.4.11. 


Title: Re: 1.5GB Limit (some answers)
Post by: DieHard on May 04, 2016, 09:38:32 PM
HA ! That screenshot always cracks me up; 811.9 MB for the Mac OS, Mactron would have a heart attack if that was accurate !

He works for days if he wastes .000002 MB and re-writes extensions... LOL
Title: Re: 1.5GB Limit (some answers)
Post by: Protools5LEGuy on May 04, 2016, 09:57:51 PM
I would pay an 800 Meg Mac OS system TAX gladly if it would allow true multitasking, protected memory, USB 2.0 and FW-800.  :D

In the meantime, it makes sense to have under 1.5 G of RAM for a pure OS9 setup.
Title: Re: 1.5GB Limit (some answers)
Post by: nanopico on May 05, 2016, 06:17:21 AM
I had a new stupid theory earlier this week on this.
Some of the pre-g3 macs that are supported in 9 had 12 ram slots.  They official supported 128 MB dims but others found that 256 ones worked.
This only equates to 768 mb though. I think Apple probably knew that 256 would technically work, but for whatever reason stated only 128 would work.  With 256 used in each slot you get 1.5 GB.  I think that this is the driving force behind the reason for the limit.  That or I'm just crazy.  Still doesn't help solve the problem though.
Title: Re: 1.5GB Limit (some answers)
Post by: MacTron on May 05, 2016, 08:18:47 AM
HA ! That screenshot always cracks me up; 811.9 MB for the Mac OS, Mactron would have a heart attack if that was accurate !

He works for days if he wastes .000002 MB and re-writes extensions... LOL

 ;D ;D ;D ;D

Not at all. This is a very known picture. It only has to do with the Finder way to compute memory. It clearly knows that there is 2 GB installed, but it only can use ( RAM addressable ) 1.5 GB.
Title: Re: 1.5GB Limit (some answers)
Post by: nanopico on May 05, 2016, 08:21:22 AM
HA ! That screenshot always cracks me up; 811.9 MB for the Mac OS, Mactron would have a heart attack if that was accurate !

He works for days if he wastes .000002 MB and re-writes extensions... LOL

 ;D ;D ;D ;D

Not at all. This is a very known picture. It only has to do with the Finder way to compute memory. It clearly knows that there is 2 GB installed, but it only can use ( RAM addressable ) 1.5 GB.

Because the Mac OS usage is calculated by the total ram - what the process manager has allocated to it. Now how to change that allocation and what other ramifications that will have are the problem.
Title: Re: 1.5GB Limit (some answers)
Post by: DieHard on May 05, 2016, 09:44:35 AM
Sorry, lost a little in the translation, I KNOW it's NOT accurate, but if it was.... we would have about 10 threads explaining what extensions/control panels to turn off :)
Title: Re: 1.5GB Limit (some answers)
Post by: nanopico on May 10, 2016, 07:46:30 PM
Quick update here.
I found some older documentation on MacsBug that outlined the mmu and memory map info.
It was older documentation for some of the earlier OS, but the commands in MacsBug haven't changed other than there are some PPC specific alternatives that require that (such as the dissembler).
So between that and system calls asking to for logical to physical translation I can identify a clearer vision of the address space and where the ram sits with in it to find out what regions of physical ram are mapped to what logical address and figure out exactly what parts of the ram it is not using.  Possibly then sending a couple instructions to the MMU to ask it to map the missing ram.  Crazy idea yes, but moving in the right direction.
Title: Re: 1.5GB Limit (some answers)
Post by: Protools5LEGuy on May 10, 2016, 10:10:18 PM
The folks from sheepshaver will thank any info on MMU.
Title: Re: 1.5GB Limit (some answers)
Post by: ELN on May 27, 2016, 08:56:56 PM
Anyone ever used the Potatoswatter's Ephemerboot? It gave you a bootable RAM disk on NewWorld systems. I quote from the docs:
Quote
This also gets around basic limitations in the Mac OS, like the 1.5 gig limit. A 500 meg Ephboot disk should let a 2 gig machine use all of its memory.
Title: Re: 1.5GB Limit (some answers)
Post by: Protools5LEGuy on May 28, 2016, 05:43:39 AM
https://groups.google.com/forum/#!topic/comp.sys.mac.programmer.help/UH78zG9cmPA (https://groups.google.com/forum/#!topic/comp.sys.mac.programmer.help/UH78zG9cmPA)
Quote
Current Multiprocessing SDK from Apple contains
version 1.5d16 of PowerMacInfo tool. Undertstand
there is a version 1.7d5 (post by Rene A. Vega
on 10-25-2001). Does anyone know where this can
be downloaded ?

Also, where might I find additional documentation
on the nanokernel (if any exists) ?

Thanks for any help, Nick Burgoyne    14 Feb 2003
<[email protected]>

Quote
It's up to you to figure what's going on inside the nanokernel. You
might have fun with the source from my hack Ephemerboot, at
http://homepage.mac.com/potswa/source .

You could ask Rene for 1.7d5. Or you could ask me.

   - Potatoswatter
Title: Re: 1.5GB Limit (some answers)
Post by: Philgood on May 28, 2016, 05:48:03 AM
Please post this little app, tool, whatever it is...
Title: Re: 1.5GB Limit (some answers)
Post by: Protools5LEGuy on May 28, 2016, 05:50:42 AM
Wayback machine can't help with http://homepage.mac.com/potswa/source (http://homepage.mac.com/potswa/source)

Googling ephemer boot lead to openstack info ???

http://docs.openstack.org/user-guide/cli_nova_launch_instance_from_volume.html (http://docs.openstack.org/user-guide/cli_nova_launch_instance_from_volume.html)

https://wiki.openstack.org/wiki/BlockDeviceConfig (https://wiki.openstack.org/wiki/BlockDeviceConfig)
Title: Re: 1.5GB Limit (some answers)
Post by: Protools5LEGuy on May 28, 2016, 07:01:38 AM
If we can't reach Rene A. Vega maybe we can with Potatoswatter

http://stackoverflow.com/users/153285/potatoswatter (http://stackoverflow.com/users/153285/potatoswatter)

http://math.stackexchange.com/users/9317/potatoswatter (http://math.stackexchange.com/users/9317/potatoswatter)

http://everything2.com/user/Potatoswatter/writeups/opcode (http://everything2.com/user/Potatoswatter/writeups/opcode)

https://www.facebook.com/Potatoswatter (https://www.facebook.com/Potatoswatter)

http://www.potswa.org/ (http://www.potswa.org/)

http://everything2.com/title/opcode (http://everything2.com/title/opcode)
Title: Re: 1.5GB Limit (some answers)
Post by: IIO on May 28, 2016, 10:06:01 AM
Because the Mac OS usage is calculated by the total ram - what the process manager has allocated to it.

allocated as the max, as long as not some other apps are asking for this RAM to use, then it is the min.
Title: Re: 1.5GB Limit (some answers)
Post by: DieHard on May 28, 2016, 11:19:15 AM
Quote
This also gets around basic limitations in the Mac OS, like the 1.5 gig limit. A 500 meg Ephboot disk should let a 2 gig machine use all of its memory.

As we know, the apple RAM disk memory used pads itself to the System memory used and is thus, worthless in our quest for the missing .5 GB, but if the quote above is real that would be amazing... this means the wheel we are engineering has already been built.  We need to get this app. and test it NOW !
Title: Re: 1.5GB Limit (some answers)
Post by: nanopico on May 29, 2016, 07:00:23 AM
Because the Mac OS usage is calculated by the total ram - what the process manager has allocated to it.

allocated as the max, as long as not some other apps are asking for this RAM to use, then it is the min.

I'm not sure I follow you, but The Mac OS Usage I am referring to is the amount of ram allocated to Mac OS when you view About This Computer.  It's not calculated by the actual usage.

Quote
This also gets around basic limitations in the Mac OS, like the 1.5 gig limit. A 500 meg Ephboot disk should let a 2 gig machine use all of its memory.

As we know, the apple RAM disk memory used pads itself to the System memory used and is thus, worthless in our quest for the missing .5 GB, but if the quote above is real that would be amazing... this means the wheel we are engineering has already been built.  We need to get this app. and test it NOW !

From what i have seen with this, it id ram disk that it mapped to look like a physical hard drive and the ram used by it is not visible to the OS.  The ram disk has to be used to boot the system.  So you in theory would get be able to use all the memory, but at least 512 MB would have to be a ram disk that the system boots from.   It's a rather neat system and I'm trying to wrap my head around it's workings to see what we can learn from it, but it doesn't seem to patch the system memory manager at all so we are still limited to 1.5 GB max allocation once booted.  But once booted the system will still load it's self now within that 1.5 GB and not outside it like it currently does.  So actually in theory, going this route can cause the usable memory to be less than not using this tool/utility/application.
Title: Re: 1.5GB Limit (some answers)
Post by: nanopico on June 13, 2016, 11:11:46 AM
Knowledge attained regarding getting to 2GB.
Just a small update.
So I found some bit's poking around and reading documentation.
So what we know is that the process manager get's allocated 1.5GB of ram and the rest is the system.  This is calculated by the size of the actual memory minus that which is allocated to the process manager.
The process manager is installed at the top of RAM and it's heap grows down, just like every other application.
The system is placed at the bottom of RAM and it's heap grows up.
The reason for this is so that the system doesn't hit a hard limit if it needs to grow. So if it didn't get enough allocated early on and it grows it hits the bottom of RAM and that probably isn't good.
If the system heap needs to grow it takes it from the process manager by shrinking  it and then expanding the system heap.  When the system heap can shrink it does so and then grows the process manager's heap.  Generally you won't ever actually this though.  The system heap really only grows during boot while it's loading extensions.
What I didn't realize is that there is a dummy heap between the two of them. So at the end of the process manager heap is a heap header and then a small empty block.  This dummy heap is supposedly what's moved around to shift the memory between the two heaps.

Supposedly the dummy heap is there to hide some of the aspects of the process manager from things like macsbug.
So in theory if one could find the function location of the function that does the dynamic resizing then one could create an extension
that checks ram and runs that function and boom, you get use of all ram!

This is just a theory. Reality doesn't always align correctly.  It still doesn't explain why the process manager only get's 1.5 GB when more is available. 
Title: Re: 1.5GB Limit (some answers)
Post by: Metrophage on June 13, 2016, 11:38:20 AM
Thanks for your work and sharing of these insights!
Title: Re: 1.5GB Limit (some answers)
Post by: MacTron on June 13, 2016, 12:22:25 PM
This is just a theory. Reality doesn't always align correctly.  It still doesn't explain why the process manager only get's 1.5 GB when more is available.

The whole 32 bits memory space was designed when 1MB of RAM was a lot of RAM :) . This 1.5 GB limit was taken later, to avoid interfering with other addressable directions with others uses. ... Probably.
Title: Re: 1.5GB Limit (some answers)
Post by: nanopico on June 13, 2016, 12:35:16 PM
This is just a theory. Reality doesn't always align correctly.  It still doesn't explain why the process manager only get's 1.5 GB when more is available.

The whole 32 bits memory space was designed when 1MB of RAM was a lot of RAM :) . This 1.5 GB limit was taken later, to avoid interfering with other addressable directions with others uses. ... Probably.

I would completely agree and believe this to be true as well. 
I was trying to figure out if the limit exists due to an addressing method where the page size is the limiting factor, but I have not found any indication of that or any bit pattern to support that yet.
Title: Re: 1.5GB Limit (some answers)
Post by: nanopico on June 27, 2016, 07:18:20 AM
I've found something really really cool (well to me it is).
So the System Heap grows up and the Process Manager Heap grows down.  This would be because they share a boundary and the process manager will be less likely to have to have anything at the bottom of it's heap as it loads programs at the top and moves down and heaps in the applications also grow down (the system heap is the only one that grows up).
There are a set of function exported from the memory manager for shrinking and expanding the heap in both the system and process manager.
These are private methods as normal application should never call them. 
When the process manager is started it looks to a resource for it's size (just like any other application with it's minimum and preferred sizes).
Once the process manager is set up the system heap is grown to meet it and then they proceed to have a wonderful relationship where they have little application children until they are both terminated.  Ok jokes aside. 
So now that I know those functions I can start to look for the resource to set the size.  Modify that and if all my assumptions are correct, then we are in business for gaining back most of that 512 MB (except for that actually used by the system heap).
Title: Re: 1.5GB Limit (some answers)
Post by: mrhappy on June 27, 2016, 08:51:16 AM

Once the process manager is set up the system heap is grown to meet it and then they proceed to have a wonderful relationship where they have little application children until they are both terminated.

now THAT I understand!! ;D ;D ;D
Title: Re: 1.5GB Limit (some answers)
Post by: MacOS Plus on June 27, 2016, 01:31:50 PM
  I seem to recall there being a physical performance limit of PC133 RAM that capped it at 1.5GB.  Do you think the OS limit might just be a legacy holdover of that, so maintaining compatibility with most of the G4 systems wasn't complicated by the arrival of the DDR-based systems?  In any other respect the cap would look arbitrary.
Title: Re: 1.5GB Limit (some answers)
Post by: nanopico on June 27, 2016, 08:10:22 PM
  I seem to recall there being a physical performance limit of PC133 RAM that capped it at 1.5GB.  Do you think the OS limit might just be a legacy holdover of that, so maintaining compatibility with most of the G4 systems wasn't complicated by the arrival of the DDR-based systems?  In any other respect the cap would look arbitrary.

I'm not sure I have ever heard of PC133 having some sort of a a 1.5GB limit.
I know I've got an older server sitting my basement that used PC133 that oddly enough has 2 sticks of 1GB each in it with out issue.

I think the limit is arbitrary at this time, and more likely is some sort of hold over from bank switching and page size related to the pre G3 power macs that had 6 dimm slots.
Title: Re: 1.5GB Limit (some answers)
Post by: MacOS Plus on June 27, 2016, 11:37:50 PM
  Yes, one way or another I'm sure it's a compatibility holdover.  I suppose we should keep in mind that we might break support in some machines by tinkering with this.  Not that it will be of concern to the majority of the users who would want to take advantage of removing the RAM cap since they are more than likely going to be using the later more powerful models anyway.  I'm more curious to know just from an information standpoint if this happens and what machines might be affected and why.
Title: Re: 1.5GB Limit (some answers)
Post by: nanopico on June 28, 2016, 06:08:34 AM
  Yes, one way or another I'm sure it's a compatibility holdover.  I suppose we should keep in mind that we might break support in some machines by tinkering with this.  Not that it will be of concern to the majority of the users who would want to take advantage of removing the RAM cap since they are more than likely going to be using the later more powerful models anyway.  I'm more curious to know just from an information standpoint if this happens and what machines might be affected and why.

The breaking stuff is what concerns me or if it become unstable or something.
My intent is that if this get's figured out an extension can be made so that you only enable it if you need it and know it works for your setup.
Title: Re: 1.5GB Limit (some answers)
Post by: MacOS Plus on June 28, 2016, 09:54:37 AM
  Yes, one way or another I'm sure it's a compatibility holdover.  I suppose we should keep in mind that we might break support in some machines by tinkering with this.  Not that it will be of concern to the majority of the users who would want to take advantage of removing the RAM cap since they are more than likely going to be using the later more powerful models anyway.  I'm more curious to know just from an information standpoint if this happens and what machines might be affected and why.

The breaking stuff is what concerns me or if it become unstable or something.
My intent is that if this get's figured out an extension can be made so that you only enable it if you need it and know it works for your setup.

  This is definitely the best approach.  I found mention of the PC133 issue I was talking about.  It's buried in the text of this web page:

http://etutorials.org/Misc/pc+hardware+tuning+acceleration/Chapter+4+Main+Components+and+the+Optimal+Choice/Motherboards/ (http://etutorials.org/Misc/pc+hardware+tuning+acceleration/Chapter+4+Main+Components+and+the+Optimal+Choice/Motherboards/)

  The relevant text is as follows - "PC133 specifications recommend a limit of three DIMM or six banks at 133 MHz (The maximum memory in this configuration is 1.5 GB)."  As I remember it you can run into timing and bandwidth issues if you try to physically go beyond this configuration.  It's not a guaranteed failure but was enough of a potential problem to be officially mentioned in the spec.  A lot of PC motherboards from the time period (when PC133 support was introduced) reduced their DIMM slot count from four to three to prevent the end user from making this mistake.  You could have more than 1.5GB reliably installed if you ran it at a 100MHz bus speed, which was possible in certain motherboards with switchable memory or shared memory/CPU bus speed settings in the BIOS.

  Obviously the arrival of DDR eliminated this issue, but by then it was probably deemed not worth fixing in OS 9 because it would have opened a huge can of worms.  I know that OS 9 can't even properly identify the type of some of my DDR DIMMs and erroneously claims they are PC133 in System Profiler, which is a very weird thing for it to do in a DDR-only architecture.  (It also claims that one of the stock Apple PC2100 DIMMs that came with one of my Xserves is actually "PC2600".)

  Have you ever wondered why the Powermac G4 "Digital Audio" and "Quicksilver" are the only G4 models with only three RAM slots?  Well they're the only ones built around PC133 memory.  They can't take more than 1.5GB RAM by design so they can't benefit from removing the software limitation.  The "AGP", "Gigabit Ethernet", "MDD" and "Xserve" will be the only machines we can realistically target for greater than 1.5GB.  I'm not sure what would have to be done to effectively test for good behaviour in these systems.  Some of the guys using a lot of software DAW processing might be able to push the limits.  I recall mention though that there is a 1GB-per-application maximum allocation unit in OS 9 also.

  One final note, the four RAM slots in the AGP and Gigabit Ethernet G4s likely were not ever intended for installing greater than 1.5GB.  The cost of larger DIMMs at the time, particularly if bought through Apple, was prohibitively expensive to many users.  The slots were there to make the most of lower capacity DIMMs.  This lets me make good use of the vast pile of 64MB, 128MB and 256MB DIMMs I kept around after they were pulled from other upgraded PC systems.  Most of my OS 9 and 8.6 machines don't get enough serious use to require a lot of RAM anyway.
Title: Re: 1.5GB Limit (some answers)
Post by: nanopico on June 28, 2016, 10:22:52 AM
And I do believe we have a definitive answer!!!
Thank you!

Just to add to this as evidence.  The G4's had 4 PC100 slots up to the Digital Audio which used PC133 and had only 3 slots probably for the exact reason identified by MacOS plus. 

Documentation in Inside Macintosh hints that the OS on 32 bit platforms can support up to 4 GB of ram. (Yes I know that's the limit of the address space, but the document indicates most of that could be used by an application).

So the Digital Audio and Quick Silver machines have the physical limitation of 1.5 GB.

So it might actually be simple to get that extra 512MB back.
Would best be done as an extension and stress tested to ensure stability.
Title: Re: 1.5GB Limit (some answers)
Post by: MacTron on June 28, 2016, 10:35:55 AM
I recall mention though that there is a 1GB-per-application maximum allocation unit in OS 9 also.
This is a Myth. May Be true for some apps but not in general. I have used Cubase with 1.4 Gb or RAM for years without issues:
(http://macos9lives.com/smforum/index.php?action=dlattach;topic=2860.0;attach=3455)

All this memory is used by the 21 instruments loaded in 3 instances of Kompakt ( a software sampler).
I'm waiting to test nanopico's first work about this.  If I can have 512 mb more I could add 7 or 8 instruments more :)
Title: Re: 1.5GB Limit (some answers)
Post by: MacOS Plus on June 28, 2016, 09:09:28 PM
  That's awesome, MacTron!  I'm actually quite interested in dedicating a machine to software sampler instruments.  This probably is just about the best task for pushing the limits of RAM and CPU.  I'll have to try this eventually with one of my three MDDs.  I could probably even MIDI-sync multiple machines if I want to really go nuts.  Did you have to manually allocate all that RAM in the app dialog box or does it just expand on its own as it needs it?

  I have a G4 Sawtooth, MDD, MDD FW800 and Xserve Tray-load, plus a Gigabit Ethernet motherboard I plan to get running also.  This means I should be able to test 2GB RAM on all possible G4 systems when the time comes.  (I guess except for the Xserve Slot-load which is still a work in progress for OS 9.  Not sure I'm interested enough to bother buying one of those.)
Title: Re: 1.5GB Limit (some answers)
Post by: DieHard on June 29, 2016, 10:02:12 PM
Quote
Did you have to manually allocate all that RAM in the app dialog box or does it just expand on its own as it needs it?

CMD-I manually... like Mactron I have set mine very high for Cubase (in my tips I recommend 400,000), but I never tried going past 800,000 (.8GB).

Hmmmmm  :o
Title: Re: 1.5GB Limit (some answers)
Post by: nanopico on June 30, 2016, 07:26:06 AM
Did a little further research last night.
I'm still fairly positive it's due to some hardware limitation at some point that just never got updated in code, but I don't think the actual limit is due to the PC133 limitation as this has been in there long before that.
Title: Re: 1.5GB Limit (some answers)
Post by: MacOS Plus on June 30, 2016, 09:19:22 AM
  I just figure that with OS X well-established by the arrival of the MDD, Apple saw no incentive to build in a workaround even if it was possible in OS 9.  Most users didn't need more than 1.5GB of RAM and the benefit would be available to a relatively limited number of machines anyone would have still been willing to spend money on upgrading.  The permanent limitation of the PC133-based machines and the commitment to the transition to OS X would have made cutting off development on the issue an easy financial decision for Apple.

  I agree that the PC133 models shouldn't have any bearing on the OS code as it stands.  It's unlikely any change you make to the code could exclusively break support for those machines.
Title: Re: 1.5GB Limit (some answers)
Post by: nanopico on July 14, 2016, 05:03:35 PM
Two things as an update to the 2GB shenanigans.
1. I'm working on a program that can call the previously identified functions (the ones that grow the system heap, shrink the system heap, grow the process manager heap and shrink the process manager heap).  These functions are all part of the memory manager.  As these are private functions there will be no headers with definitions for them and the standard methods of linking from the compiler will complain about a lot of things.  So at the moment I'm working out a way to call these.  The intent of this first program is that you can run it and move the boundary between the two heaps to manually adjust the ram usage.  Not sure if it will work, but that's the goal.

2.  While digging through the headers for the memory manager there is an interesting constant defined.  maxBlockSize.   I haven't looked at what it's used for, but it is just shy of 2GB. But as it's a block size it would be greater than one byte.  So on the surface it makes me wonder if there is someway to allocate an objet in code that is 2+ GB in size.  That would be interesting for sure.
Title: Re: 1.5GB Limit (some answers)
Post by: Texas_RangerAT on July 15, 2016, 05:10:30 AM
It's merely an educated guess but I strongly suspect there's a simple reason for the discrepancy between Apple's RAM limit and actual capacity: Apple took whatever modules were available at the time of the machine's development, did extensive testing with those modules and then set that as a limit - forever. If larger SIMMs, DIMMs or whatever were introduced later during the machine's life Apple simply ignored that.

Another thing occurred to me last night. It might be totally unrelated since it affected much older software and hardware but I'm 99% sure I've run into the weird situation of the Finder claiming to use up a whole lot of memory before! My memories of that are extremely fuzzy as it must have been more than 15 years ago but I THINK that was when I tried installing 6.0.3 on a Mac IIcx or maybe IIci with more than 16 MB of RAM. At that time I supposed it was due to 6.x only supporting 24-bit address space or something like that I'd read. Another possibility (though less likely) is that I encountered it on a IIcx (which doesn't have full 32-bit addressing) running 7.5.5 without a 32bit enabler extension installed. I still have both machines so I could do some experimenting but I'm not sure if it's any help since we're talking about 68k hardware and 6.x/7x here.
Title: Re: 1.5GB Limit (some answers)
Post by: geforceg4 on August 24, 2016, 03:12:00 PM
it helps to look at things in perspective
imho u are looking at mac os 9 and judging ram vs performance in a way that the world has conditioned people to look at it since the use of mac OS X + ram sizes exploding into higher capacities.. but mac os 9 is descended from older lowly roots where more ram doesnt neccessarily mean more performance.

lets look at some numbers?

http://www.everymac.com/actual-maximum-mac-ram/actual-maximum-power-mac-g3-ram-capacity.html

here we see the beige g3's max out at 768Mb
the B+W G3s max out at 1024Mb

examining this page:
http://www.everymac.com/actual-maximum-mac-ram/actual-maximum-power-mac-g4-ram-capacity.html

we see that most g4motherboards dont support more than 1.5gb of ram PHYSICALLY limited by the slots...

but lets remember we are talking about an os with history... if u look at the early 1990s..
what was the std/max ram of the flagship machines? mac os 9 is basically the same os as mac os 7 but extended into the future...

http://www.everymac.com/systems/by_year/macs-released-in-1991.html
http://www.everymac.com/systems/apple/mac_quadra/specs/mac_quadra_900.html
STD:4MB!!!!!! MAX:64MB!!!!

http://www.everymac.com/systems/by_year/macs-released-in-1993.html
http://www.everymac.com/systems/apple/mac_quadra/specs/mac_quadra_840av.html
STD: 8mb!!!!! MAX:768Mb

http://www.everymac.com/systems/by_year/macs-released-in-1995.html
http://www.everymac.com/systems/apple/powermac/specs/powermac_9500_132.html
STD:16Mb! MAX:768Mb

http://www.everymac.com/systems/by_year/macs-released-in-1997.html
http://www.everymac.com/systems/apple/powermac/specs/powermac_9600_350.html
STD:64Mb MAX:768Mb

http://www.everymac.com/systems/by_year/macs-released-in-1999.html
http://www.everymac.com/systems/apple/mac_server_g3/specs/macserver_g3_450_bl.html
STD: 256Mb!!!! MAX:1GB

http://www.everymac.com/systems/by_year/macs-released-in-2001.html
http://www.everymac.com/systems/apple/powermac_g4/specs/powermac_g4_867_qs.html
STD:128MB MAX:1.5GB RAM

http://www.everymac.com/systems/by_year/macs-released-in-2003.html
http://www.everymac.com/systems/apple/powermac_g4/specs/powermac_g4_1.25_mdd.htm
STD: 256MB MAX:2GB RAM

even in 2003!!! after the mac os9  funeral... the mdd still shipped with 256mb ram!!!!!! only!

is it possible to think the logic that more ram = more performance doesnt neccessarily apply?
can we wrap our heads around that???  even in 1999 (the year mac os 9 was released) the most powerful mac was shipping with 256mb! most of them even less than that!

having 2GB ram was something that didnt even come into play with PC's untill 2001 with the NT Based Windows XP.. before that windows98se could only even accept 512mb!!!! half a gig MAX! limited by the OS!! the classic mac os works great with 1gb of ram!! you need'nt worry about increasing ram to increase your productivity or performance.. you are better off worrying about what you are actually doing with software programs rather then worrying about a few extra MB of ram hardware.

i dont understand the fascination with the subject of enhancing mac os 9..
even if u got it to take 4GB OF RAM somehow.. IT WOULD NOT MAKE A DIFFERENCE. the RAM is not the limiting factor for performance.
we are talking about an os that is descended from other mac os that used to use very small amount of ram, to do amazing things. 1991 running mac os 7, with only 4MB RAM!!!!!!!! new in the box, with only 4MB RAM!!! think about it..

i keep hoping one day the users of this forum will realize theres more to talk about in how they use the software then to be obsessed + fascinated with getting 2gb of ram to work when theres not much benefit.
to me, im much more interested to talk about drop down menus + functionality within software.. file conversion.. creative processes.. tactics to use multiple software programs together to achieve a better work flow result.
etc etc.. so much software here but noone is talking about how to use it
instead focused + obsessed with RAM size.. sigh
Title: Re: 1.5GB Limit (some answers)
Post by: DieHard on August 24, 2016, 04:44:37 PM
Quote
i dont understand the fascination with the subject of enhancing mac os 9..
even if u got it to take 4GB OF RAM somehow.. IT WOULD NOT MAKE A DIFFERENCE. the RAM is not the limiting factor for performance.
we are talking about an os that is descended from other mac os that used to use very small amount of ram, to do amazing things. 1991 running mac os 7, with only 4MB RAM!!!!!!!! new in the box, with only 4MB RAM!!! think about it..

In most practical applications this is 100% true and let's also remember that programmers of this era were a different breed that prided themselves in a small memory footprint and efficient code... now that being said, for the musician that uses OS9 there would definitely be a major plus to get the 2 GB Limit usable.

For those of us that want to mix in the box and use virtual instruments/plugins under OS 9, then RAM is definitely a factor.  I have personally RAM out of RAM using VST plugins and still had 45% CPU still ready to go.  So although the average OS9 software does not need so much RAM, our digital workstations crave it, so much so, that even that extra .5 GB would let us load many more reverbs/delays and compressors.  So this "fixation" on getting more RAM has real world applications for some :)

Title: Re: 1.5GB Limit (some answers)
Post by: MacOS Plus on August 24, 2016, 04:50:41 PM
  Actually, we're all just doing it for MacTron! ;)
Title: Re: 1.5GB Limit (some answers)
Post by: DieHard on August 24, 2016, 04:58:46 PM
  Actually, we're all just doing it for MacTron! ;)

Yes, I second that :)
Title: Re: 1.5GB Limit (some answers)
Post by: geforceg4 on August 24, 2016, 06:42:21 PM
  Actually, we're all just doing it for MacTron! ;)

doing what exactly tho??
wishing on a star? :) for an alternate universe? where macos9 takes 16gb of ram?

every other os tho, the limitations that were there when the os was current, still apply, this is not linux.
its not open source.. the chances of you guys really modifying + changing functionality of the os is very unlikely.
getting mac os 9 to run on a fw800 is a bit different because its somethng that was purposely disabled
its not something that was an incompatibility that was never overcome by the real developers.. u think there wasnt any
really skilled programmers at apple? who would have loved to advanced their career by coming up with the idea that doubled or quadrupled available ram to the OS???

but a few guys scratchin at notepad on a forums site can do it when the real pros couldnt? :) i dunno guys...
alot of times the best work is done by accepting + Working within the limitations

is anyone getting "out of memory" errors?
Title: Re: 1.5GB Limit (some answers)
Post by: geforceg4 on August 24, 2016, 07:09:51 PM
i find it ironic that im on a forums site for a 15 year old operating system, TO ESCAPE the  "never ending upgrade" crap... usually found with modern os + daw apps.. only to find most of the main users of the forum are obsessed with hacking the os to get that next performance bump upgrade  ;D

(http://cdn.cultofmac.com/wp-content/uploads/2009/12/ThinkDifferent.jpg)
Title: Re: 1.5GB Limit (some answers)
Post by: nanopico on August 24, 2016, 08:30:18 PM
So if we accomplish this then do we get elevated to the "real pros" category? ::)
Title: Re: 1.5GB Limit (some answers)
Post by: geforceg4 on August 25, 2016, 12:19:51 AM
All this memory is used by the 21 instruments loaded in 3 instances of Kompakt ( a software sampler).
I'm waiting to test nanopico's first work about this.  If I can have 512 mb more I could add 7 or 8 instruments more :)

why limit yourself to only one Mac?
its 2016.. we can buy another MDD for pocket change
why not just load up another mac with another audio interface + midi interface... and load up another 21 instruments?
in another 1.5gb of ram?

in my experience its better off when u dont stress the gear to its limit. but rather have each piece only do its one specific job, which means they react instantly rather then choke under load..

why not use an actual real peice of gear to alleviate some of the need like using a Korg Triton?

hardware midi setups have no ram limitations !! only limited by midi channels + audio channels..

Title: Re: 1.5GB Limit (some answers)
Post by: GaryN on August 25, 2016, 12:35:31 AM
i find it ironic that im on a forums site for a 15 year old operating system, TO ESCAPE the  "never ending upgrade" crap.. only to find most of the main users of the forum are obsessed with hacking the os to get that next performance bump upgrade  ;D

No, you're losing perspective. You're on a forum site with every type of user from casual gamers to actual working, revenue-producing professionals using a 15-year-old operating system because it works, it's "removed" from the "never ending upgrade" crap by virtue of being "obsolete" and running lots of "abandon-ware" that mysteriously manages to deliver results indistinguishable from this week's latest and greatest "magic-in-the-box" wonder system and all of the supposedly accurate plugin emulations of 15 to 25-year-old hardware.

"Wow! Have you seen the Harmonizer plugin? The graphics are so cool!"

The main users are not obsessed with hacking the OS…they're busy using the OS.
A few of the main posters however, have more time on their hands.
My point>>>   POSTERS USERS

It's OK though, there is / are a certain amount of shortcomings that were left hanging by Apple because Steve came back and he'd pocketed a LOT of $$ for Nextstep et al so OSX was therefore where the wind was blowing - period. Ultimately a necessary and basically good thing - but it did leave some very loose ends that could stand to be tidied up.

So if the hacker types manage to squeeze a little more performance out of our good 'ol OS, I say more power to them!
They do have incredible energy… I mean, coding OS9 with one hand / side of the brain while simultaneously probing the other side for illicit RF with the other hand (AND actually finding some), I gotta admit, that's sure as hell out of my league!

When you're feeling tweaked  (for lack of a better term - believe me, I know exactly how you feel) about this, just take a look at the member roster. You'll see there's a huge "silent majority", many of whom drop in, find what they need and go back to work. There are undoubtedly even more "unregistereds" that have found resources in the open categories. Actually, most users don't post at all unless they need help with something or really have something to offer.

So relax. It's takes all kinds and ultimately it's all good.


…but if and when someone you've been totally convinced is absolutely certifiably unhinged suddenly drops a posting like:

"A way to create premptive multitasking and multiprocessor memory management in G4's under OS 9.2.2"

and it works
Title: Re: 1.5GB Limit (some answers)
Post by: geforceg4 on August 25, 2016, 01:07:23 AM
alot of times the best work is done by accepting + Working within the limitations

is anyone getting "out of memory" errors?

i have expressed what i felt i needed to express ;) my work here is done :) lol
Title: Re: 1.5GB Limit (some answers)
Post by: DieHard on August 25, 2016, 08:32:56 AM
Like I mentioned, running a studio under OS9 in the box will definitely run out of RAM at one time or another. 

Yes, G4s are cheap, but having multiple noisy G4s with extra cables and monitors are NOT the answer for many users; it may look cool, but many musicians have very little space due to nagging wives and other family obligations and most of the time are crammed in a small corner of the den as the "DAW cave".

So, I really believe, any efforts of maximizing OS 9 to "squeeze" more out of it, are not in vain.

Besides, it's fun to do what the Pros would not do... you act like that had a choice, they were hired employees that signed non-disclosures and were specifically told what to code, and what not to code.  Even if it was changing only a relative small amount of code to raise the RAM ceiling, I doubt any programmer that was making good money would make that argument with management.  They did as they were told, not as they wanted to... so to imply that "the pros couldn't do it, so how can we", may not be an accurate assessment of the facts.
Title: Re: 1.5GB Limit (some answers)
Post by: MacTron on August 25, 2016, 08:40:36 AM
  Actually, we're all just doing it for MacTron! ;)

... well, I must to say - at least -

THANK YOU !

LOL

 ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D
Title: Re: 1.5GB Limit (some answers)
Post by: DieHard on August 25, 2016, 08:48:45 AM
Quote
i find it ironic that im on a forums site for a 15 year old operating system, TO ESCAPE the  "never ending upgrade"

You may see the member base grow even more.   And I would not be surprised it you see another site called "Snow Leopard Lives!" made by ..... me :)

I have setup about 8 DAWs under Yosemite and "el Crap-itain" and it is obvious that the newer OS X versions are so tailored to the Masses, that even the simplest of DAW functions are not very difficult to attain.  Driver issues, lock-ups/instability, poor timing and syncing of MIDI and Audio and taken a pretty big set backwards over the last 2 years.

The best combo I setup in the last 4 months was Mac Pro "Quad Core" 3.7 trash can, Yosemite, and Logic Pro X, and Apogee Symphony I/O 2x6 Audio Interface for a small project studio.  Excellent quality and the guy only had to shell out about $8000.

So, if you buy everything just right, you can get the stability we took for granted a few years ago :)
Title: Re: 1.5GB Limit (some answers)
Post by: nanopico on August 30, 2016, 12:27:44 PM
Here's some good news.
I've written a set of tools for doing some of the work ELN and I have been working on.
Not all of the tools I'm working on are complete, but they are far enough along that I can start using them to find out internals of the System file.

So there are a bunch of function in the PrivateInterfaceLib and MemoryMgr libraries related to handling the System heap and Process Manager heap and the border between them.  I have now been able to make some calls to a few of these functions.  As of the moment, with out knowing the parameters, they all do nothing.  I also don't know the order to call them in yet. 
Now I just have to finish my tools so I can determine the parameters and calling order. 

Hooray Progress!
Title: Re: 1.5GB Limit (some answers)
Post by: nanopico on August 30, 2016, 01:59:40 PM
I had to share this.  It's too amusing.
So in trying to figure out the right combination of calls and parameters I managed to lock up sheepshaver, but not before getting this screen shot.
Apparently I'm able to at least totally mess up the system and process manager zone boundaries.

Now if you have issues with the 512 MB lost when 2 GB is installed, then be warned.

I'm not even sure how the math works out to get these numbers, but the system taking up 3.65 GB when only 512 MB is installed, is totally crazy!
Title: Re: 1.5GB Limit (some answers)
Post by: DieHard on August 30, 2016, 06:22:26 PM
Wow.. what a RAM pig... I never realized that Mac OS 9 used so much RAM...lol
Title: Re: 1.5GB Limit (some answers)
Post by: nanopico on August 30, 2016, 08:08:08 PM
Wow.. what a RAM pig... I never realized that Mac OS 9 used so much RAM...lol

And it can also create RAM out of thin air.


Okay so more updates now that I am at home.

As I assumed earlier when you view About This Mac and see the 550ish allocated to Mac OS and pretty much 1.5 GB for everything else that this was because it took the total amount of RAM and subtract size of the process manager to determine the size to show as Mac OS.    Well my hand little tool confirmed this.  So as of right now I'm pretty confident in this view.
I was able to see that About This Mac showed 560 MB allocated to Mac OS, but the Heap size was only 48 MB (560 - 512) and 8 KB was free in the heap.  So basically everything between the system heap and the process manager heap is in limbo. 
Now to trick the System into giving me a handle to the process manager zone so I can grow that beyond the 1.5 GB limit.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: nanopico on September 15, 2016, 09:59:53 AM
I'm going to back track a bit. Moving the point that the system and process manager join probably won't fix this.
I'm back to the view that the 512 (or something close to that) is sitting above everything else high in ram that not allocated and not in any process/library/managers control.  So I'm back to thinking that when the process manager starts it is just not given all available ram even though the system has it available.

I did find something that looks like it might be setting this value to just some random number that some software engineer picked as "this looks big enough" and it never got updated.  So there may be absolutely no reason that the limit exists other than someone like the number and it was big enough at the time.

So I may have more to report in the not too distant future (I'm pretty busy right now so I'm a little slow on this stuff), but the good news is that I think it's getting close to being fixed, maybe.

Oh and I did find out how to get a handle to the process manager heap, in case anyone is wondering.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: nanopico on November 02, 2016, 09:05:36 PM
OMG

Basic memory map for any one that cares. 
Assume 2 GB of ram installed.
Assume your system heap with your extensions and all that fun jazz takes 32 MB.
System zones and heaps set up at address 0 and use up to 32 MB
Process manager zone created at 1.5 GB and grows down to meet the system. (1.5 GB - 32 GB)
About this mac should now show show 32 MB for Mac OS and 1.5 GB - 32 MB for free space.
But it shows 1.5 GB - 32 MB as free space and then 32 MB + 512 MB for the Mac OS.
Alright back to the memory map (it's generalized here, but if you want more details I can post the full map of my system)


Point is to fix this bug ( do consider this a bug ) The early boot that sets up the MMU in the cpu needs to map out the additional 512 MB so it's accessible and the process manager needs to be told to start at 2 GB and grow down. Since everything is relocatable with in the process manager (if it wasn't we'd all be stuck with like 32 mb of RAM) and that 512 MB of missing memory isn't currently mapped, this should cause almost no problems going forward.

So on to the two things that need to be found to fix this.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: nanopico on November 03, 2016, 08:02:39 AM
Mild update.

Eln kindly pointed out to me in our most recent conversation there are two things mapped just over the 1.5GB mark. I had forgotten about this so it changes things, but only slightly.  So we are looking into how to move those and then see what happens with the creation of the process manager and possible having to update one value there.
So good news is....    This is becoming more of a reality
Title: Re: 1.5GB Limit (some answers)
Post by: ELN on November 13, 2016, 06:20:44 AM
but a few guys scratchin at notepad on a forums site can do it when the real pros couldnt? :) i dunno guys...

We are disassembling and patching the Nanokernel.

https://github.com/elliotnunn/cdg5/blob/master/kernel-disasm-script.py (https://github.com/elliotnunn/cdg5/blob/master/kernel-disasm-script.py)
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: Protools5LEGuy on November 15, 2016, 08:16:28 AM
We are very pleased to have the Dream Team among us!

The troll has been kicked out.

99% Mac OS 9 Lives! users love every little update on these topics.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: nanopico on November 16, 2016, 06:32:31 AM
We are very pleased to have the Dream Team among us!

The troll has been kicked out.

99% Mac OS 9 Lives! users love every little update on these topics.

Updates with progress towards the goal may slow for a bit.  We are rewriting some tools so that we can do the entire process in OS 9.
Yes we are crazy enough to do the whole thing using MPW.  So while we retool we might not see much in the way of a functional result.

And if any one would like to help out, I am looking to verify the memory map as we believe it to be.
Even though I am testing and working on this on 23 different Macs I am looking for anyone who want's to help as I have several that are same model and there are still others I don't have. I'd like to get details from a variety of machines with and with out 2GB installed.

So here are the instructions.

You can now uninstall macsbug by deleting it from the system folder and rebooting

You do need to hit enter after every command (I'm hoping that is obvious to everyone, but who knows)

You will now have a file called memoryMap on your desktop. If you would be so kind as to send that file to me, that would be awesome.

I may ask again for some of you to help in verifing the hardware pci range mapping, but that is a bit harder to put into easy commands as each machine has different hardware so the ranges are different and it's a lot of trial and error to get the range.
[/list]
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: Protools5LEGuy on November 16, 2016, 08:17:55 PM

Yes we are crazy enough to do the whole thing using MPW.  So while we retool we might not see much in the way of a functional result.

So here are the instructions.

   Install Macsbug
      
   

Is this version?

http://macos9lives.com/smforum/index.php/topic,3565.0.html (http://macos9lives.com/smforum/index.php/topic,3565.0.html)

http://macintoshgarden.org/apps/macsbug-663 (http://macintoshgarden.org/apps/macsbug-663)
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: nanopico on November 17, 2016, 05:58:28 AM

Yes we are crazy enough to do the whole thing using MPW.  So while we retool we might not see much in the way of a functional result.

So here are the instructions.

   Install Macsbug
      
   

Is this version?

http://macos9lives.com/smforum/index.php/topic,3565.0.html (http://macos9lives.com/smforum/index.php/topic,3565.0.html)

http://macintoshgarden.org/apps/macsbug-663 (http://macintoshgarden.org/apps/macsbug-663)

Yes that one.
Sorry I should have gave a link to that.
If any instructions are not clear to anyone, please let me know and I'll update them.
I don't want anyone to feel they can't help.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: LillyOmegaWolf on March 06, 2017, 11:09:21 PM
Still need someone to trial it too? Or am I a bit late to the party?
I would love to get the full 2gb of ram working on my G4, if only because I enjoy tweaking and pushing limits :)  so Im happy to copy a new install onto a spare drive and test if you still need testers.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: InspectorG on March 06, 2017, 11:47:25 PM
Still need someone to trial it too? Or am I a bit late to the party?
I would love to get the full 2gb of ram working on my G4, if only because I enjoy tweaking and pushing limits :)  so Im happy to copy a new install onto a spare drive and test if you still need testers.

Same here!
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: nanopico on March 07, 2017, 04:59:25 AM
Still need someone to trial it too? Or am I a bit late to the party?
I would love to get the full 2gb of ram working on my G4, if only because I enjoy tweaking and pushing limits :)  so Im happy to copy a new install onto a spare drive and test if you still need testers.

Same here!

There isn't anything to test at the moment.
The primary factor limiting the memory is thought to have been identified, but not confirmed as work has to be done to move some things in the OS.
As of yesterday I am not working on this for an unknown length of time.  ELN has picked up on this and is running with it along with another fine guy, I'm not sure if it's cool to identify him so right now I'm just going to call him awesome dude.
All is still moving forward, but don't expect to hear anything from me for god knows when.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: LillyOmegaWolf on March 07, 2017, 02:07:11 PM
Well you have put a lot of work into this. So I can understand a break, especially if theres two awesome dudes who have taken this up.
Title: First limit-breaking ROM: testers needed
Post by: ELN on May 24, 2017, 06:18:07 AM
All right, here goes. In the spirit of working in the open:

I think I have broken the 1.5 GB limit...

...by 64 MB.

So now it's the 1.5625 GB limit. But it's definitely a start. First, some explanation.

Before the Trampoline (an ELF-contained bootloader inside the Mac OS ROM file) hands control to the NanoKernel, it populates some data structures that describe many levels of the Mac OS environment. The NanoKernel pays the most attention to ConfigInfo, a structure that was formerly part of the RISC ROM but became a dynamic structure on NewWorld Macs. One of the jobs of ConfigInfo is to tell the NanoKernel how to lay out the address space of the blue task. ConfigInfo instructs the NanoKernel to make the main area, starting at address zero, as large as possible given the RAM available. If "Virtual Memory" is enabled then this area will be expanded later in the boot process, at the command of the 68k boot code. But ConfigInfo also instructs the NanoKernel to create these small special-purpose areas:
Code: [Select]
5fffe000-5fffefff InfoRecord page: contains pointers to structures shared by kernel and userspace
64000000-6417ffff Open Firmware device tree, and Mac II-style "Universal" structures
68fef000-68feffff ConfigInfo
68ffe000-68ffefff Kernel Data Page (kernel actually expands this to ~68ff5000-68ffefff)
68fff000-68ffffff Emulator Data Page

Other areas in the 6 segment are configured differently. The addresses listed might be familiar to anyone who's looked at the NanoKernel log before. But notice in the attached screenshot that the 5fffe000 area is missing, and a 6fffe000 area is present instead. That is because I have inserted code into the NanoKernel that reads the Trampoline's PageMap and edits it. For the curious, here is that code:

Code: [Select]
macro
PutPMDT &w1, &w2
lisori r31, &w1
stwx r31, r20, r21
addi r21, r21, 4
lisori r31, &w2
stwx r31, r20, r21
addi r21, r21, 4
endm


macro
StartSeg &s
stw r21, NKConfigurationInfo.SegMap32SupInit + 8*&s(r3)
stw r21, NKConfigurationInfo.SegMap32UsrInit + 8*&s(r3)
stw r21, NKConfigurationInfo.SegMap32CPUInit + 8*&s(r3)
stw r21, NKConfigurationInfo.SegMap32OvlInit + 8*&s(r3)
endm

macro
SpecialArea &a
stw r21, NKConfigurationInfo.PageMap&a.Offset(r3)
endm


if RedRover & !Vanilla

; INIT
lwz r20, NKConfigurationInfo.PageMapInitOffset(r3)
add r20, r20, r3
li r21, 0

lwz r29, NKConfigurationInfo.SegMaps + 8*6(r3)
add r29, r29, r20 ; r20 being the base of the pagemap
subi r29, r29, 8

@nt6 lwzu r28, 8(r29)
srwi r28, r28, 28
cmpwi r28, 4
bne @nt6
lwz r28, 0(r29)
lwz r29, 4(r29)
; Now r28/r29 are the 64000000 entry!
; (Important because its physical address and size vary)


; Vanilla page table (probably doesn't vary much between NW Macs)

; StartSeg 0x0
; PutPMDT 0x0000ffff, 0x00000a00
; PutPMDT 0x0000ffff, 0x00000a00
;
; StartSeg 0x1
; PutPMDT 0x0000ffff, 0x00000a00
; PutPMDT 0x0000ffff, 0x00000a00
;
; StartSeg 0x2
; PutPMDT 0x0000ffff, 0x00000a00
; PutPMDT 0x0000ffff, 0x00000a00
;
; StartSeg 0x3
; PutPMDT 0x0000ffff, 0x00000a00
; PutPMDT 0x0000ffff, 0x00000a00
;
; StartSeg 0x4
; PutPMDT 0x0000ffff, 0x00000a00
; PutPMDT 0x0000ffff, 0x00000a00
;
; StartSeg 0x5
; PutPMDT 0x0000fffd, 0x00000a00
; PutPMDT 0x0000fffd, 0x00000a00
; SpecialArea IRP
; PutPMDT 0xfffe0000, 0x00000012
; PutPMDT 0x0000ffff, 0x00000a00
; PutPMDT 0x0000ffff, 0x00000a00
;
; StartSeg 0x6
; stwx r28, r20, r21
; addi r21, r21, 4
; stwx r29, r20, r21
; addi r21, r21, 4
; PutPMDT 0x8fef0000, 0x00003013
; SpecialArea KDP
; PutPMDT 0x8ffe0000, 0x00000011
; SpecialArea EDP
; PutPMDT 0x8fff0000, 0x00000012
; PutPMDT 0x0000ffff, 0x00000a01
; PutPMDT 0x0000ffff, 0x00000a01
; PutPMDT 0x0000ffff, 0x00000a00
;
; StartSeg 0x7
; PutPMDT 0x0000ffff, 0x00000a01
; PutPMDT 0x0000ffff, 0x00000a01
; PutPMDT 0x0000ffff, 0x00000a00
;


; Don't forget to patch logical address fields:
lisori r31, 0x6fffe000
stw r31, NKConfigurationInfo.LA_InfoRecord(r3)


StartSeg 0x0
PutPMDT 0x0000ffff, 0x00000a00
PutPMDT 0x0000ffff, 0x00000a00

StartSeg 0x1
PutPMDT 0x0000ffff, 0x00000a00
PutPMDT 0x0000ffff, 0x00000a00

StartSeg 0x2
PutPMDT 0x0000ffff, 0x00000a00
PutPMDT 0x0000ffff, 0x00000a00

StartSeg 0x3
PutPMDT 0x0000ffff, 0x00000a00
PutPMDT 0x0000ffff, 0x00000a00

StartSeg 0x4
PutPMDT 0x0000ffff, 0x00000a00
PutPMDT 0x0000ffff, 0x00000a00

StartSeg 0x5
PutPMDT 0x0000ffff, 0x00000a00
PutPMDT 0x0000ffff, 0x00000a00

StartSeg 0x6
PutPMDT 0x00003fff, 0x00000a00
PutPMDT 0x00003fff, 0x00000a00

stwx r28, r20, r21 ; Name Registry
addi r21, r21, 4
stwx r29, r20, r21
addi r21, r21, 4

PutPMDT 0x8fef0000, 0x00003013 ; ConfigInfo

SpecialArea KDP
PutPMDT 0x8ffe0000, 0x00000011
SpecialArea EDP
PutPMDT 0x8fff0000, 0x00000012
SpecialArea IRP
PutPMDT 0xfffe0000, 0x00000012

PutPMDT 0x0000ffff, 0x00000a01
PutPMDT 0x0000ffff, 0x00000a01
PutPMDT 0x0000ffff, 0x00000a00

StartSeg 0x7
PutPMDT 0x0000ffff, 0x00000a01
PutPMDT 0x0000ffff, 0x00000a01
PutPMDT 0x0000ffff, 0x00000a00


; Later parts of the table
; (definitely vary between machines)

; StartSeg 0x8
; PutPMDT 0x0000ffff, 0x8000003a
; PutPMDT 0x0000ffff, 0x80000a01
; PutPMDT 0x0000ffff, 0x00000a00

; StartSeg 0x9
; PutPMDT 0x0000000f, 0x9000003a
; PutPMDT 0x0020001f, 0x9002003a
; PutPMDT 0x80007fff, 0x98000032
; PutPMDT 0x0000ffff, 0x90000a01
; PutPMDT 0x0000ffff, 0x00000a00

; StartSeg 0xa
; PutPMDT 0x0000ffff, 0xa0000a01
; PutPMDT 0x0000ffff, 0x00000a00

; StartSeg 0xb
; PutPMDT 0x0000ffff, 0xb0000a01
; PutPMDT 0x0000ffff, 0x00000a00

; StartSeg 0xc
; PutPMDT 0x0000ffff, 0xc0000a01
; PutPMDT 0x0000ffff, 0x00000a00

; StartSeg 0xd
; PutPMDT 0x0000ffff, 0xd0000a01
; PutPMDT 0x0000ffff, 0x00000a00

; StartSeg 0xe
; PutPMDT 0x0000ffff, 0xe0000a01
; PutPMDT 0x0000ffff, 0x00000a00

; StartSeg 0xf
; PutPMDT 0x0000ffff, 0xf000003a
; PutPMDT 0x0000ffff, 0xf0000a01
; PutPMDT 0x0000ffff, 0x00000a00

;stw r21, NKConfigurationInfo.PageMapInitSize(r3)
li r20, 0
li r21, 0
li r31, 0

endif

The effect of the patch is to move the InfoRecord page from the 5 segment to the equivalent location in the 6 segment, and to expand the blue area up to the bottom of the next obstacle, at 64000000. This is a difference of 64 MB.

On its own, this patch crashes my Power Mac (even though it only has 256 MB). This is because the 68k Emulator, which lives in ROM just a few KB north of the NanoKernel, contains a hardcoded constant, 5fffe000, which it uses to fetch the LogicalMemorySize from the NanoKernel's SystemInfo structure. I changed that, and all was well. (Hopefully there are no more subtle crashes waiting to strike. Well-written software should use the NKLocateInfoRecord kernel call instead of hardcoding that location.)

Interestingly, the patch alone did not crash QEMU. QEMU is currently my only way to start Mac OS 9 with the full 2 GB of RAM. (By the way, anyone want to send me 2 GB that will work in my FW800 MDD? I'm hopeless with hardware.) QEMU does not start the Dynamic Recompiling function of the emulator, which is the part that contains the hardcoded constant. I am not yet sure why.

So that's one down and

So, I need testers with 2 GB Macs running Mac OS 9.2.2. Attached is a Mac OS ROM file and a copy of NKLogReader. First, dump the log output of your normal kernel. Then, install the patched Mac OS ROM file. If you get a crash on boot, please take a picture of the kernel log. If it boots up, please get a screenshot of the Finder About window and a kernel dump.

Soon we might bust the 1.5 GB limit completely. Good luck, and have fun.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: Protools5LEGuy on May 24, 2017, 08:00:47 AM
Are this 64Mb able to be used as a RAM disk?
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: ELN on May 24, 2017, 08:50:32 AM
The system should see it as normal, usable RAM.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: MacOS Plus on May 24, 2017, 09:28:21 AM
  Not smooth sailing so far.  One of the DIMMs I borrowed from an Xserve to max out the RAM in my MDDs caused random hard freezes.  The usual moral of the story applies - if possible stick to a fully matched set of DIMMs!  Completing a matched set fixed that issue.

  I had a bit of trouble with saving the attached file.  Classilla doesn't use the correct file name for the archive, no big deal, but I don't think the ROM file came out right.  A fresh 9.2.2 boot drive wasn't recognized as bootable at startup with the replacement ROM.  Also I had to pull NKLogReader from your original post about it because it wasn't present in the current attachment.  I was able to run NKLogReader when booted from the original ROM and then save the log to a file.  The modified ROM will have to wait until this issue is sorted out.

  Once I can get 'step one' working, could you apply the "unsupported G4s" patch so I can try this on FW800 and Xserve?
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: MacTron on May 24, 2017, 10:29:41 AM
Great!!!  ;D

All right, here goes. In the spirit of working in the open:

I think I have broken the 1.5 GB limit...

...by 64 MB.
... 64MB...
... this is a small step for a man... but a big step for ...
 ;D ;D ;D ;D

(http://macos9lives.com/smforum/index.php?action=dlattach;topic=2860.0;attach=4388)
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: ELN on May 24, 2017, 10:32:51 AM
I am surprised to hear that! Sorry you've had trouble. I tried downloading the archive from the site. It worked fine for me, log dumper and all.

Here's a new archive. I rebuilt the image with some of the changes I've made in the last couple of hours, and compressed it with a different version of Stuffit. You should get an extra 128 MB recognised now.

My builds should actually boot fine on an "unsupported" G4. (But I reflashed my MDD back in 2015, so I haven't been testing that.)

Thanks for trying it out already! Let me know how this goes.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: ELN on May 24, 2017, 10:36:22 AM
Thanks, MacTron! Could I trouble you for the contents of your kernel log?
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: MacTron on May 24, 2017, 12:23:45 PM
Thanks, MacTron! Could I trouble you for the contents of your kernel log?

No problem but I have to solve an issue with the "Second limit-breaking ROM" because it cant startup the MDD I was using for testing, and in this machine I only have installed one System folder  :-[ ... LOL
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: MacTron on May 24, 2017, 01:26:46 PM
Attached is a screenshot of the crash I obtain when booting with "Second limit-breaking ROM".
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: DieHard on May 24, 2017, 02:31:48 PM
Attached is a screenshot of the crash I obtain when booting with "Second limit-breaking ROM".

Damn !  We were going so quick  thought we would have the full extra 512MB by midnight :)

All joking aside, this is absolutely amazing, even stealing 64MB is like XMas considering Apple never intended to throw us even that small bone.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: ELN on May 24, 2017, 04:41:27 PM
Attached is a screenshot of the crash I obtain when booting with "Second limit-breaking ROM".

That's a pretty miserable crash, but very fixable. My PageMap patching code is very hacky, and made some clearly incorrect assumptions about the state of the map on other people's machines. I should have a fix in a day or two.

So thanks for testing, guys. I'll have another image for you in a couple of days. If you're willing to believe that the second image does work, then we're up to 1.625 GB.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: MacOS Plus on May 24, 2017, 09:14:02 PM
  Okay, so I tried this again after getting home from work this evening.  The first ROM prevents my MDD FW400 from recognizing the drive as a valid boot device.  The second ROM does get recognized but fails in exactly the same way as it did for MacTron.  (I won't bother posting an identical screenshot.)  I don't know what the deal is with the first version of the ROM not playing nice with my machine, but at least I know it's just something with that file given that the second version is recognized.  I will try again on the MDD once you have made further adjustments.

<edit>  Just for the hell of it I tried booting ROM v2 on a Quicksilver.  Now I know that's not particularly useful since this machine cannot have more than 1.5GB of RAM installed in it at all, but I just wanted to see if the boot would complete on a different machine.  It did boot without issue with a machine max RAM of 1.5GB present.  Here's the log output:

Code: [Select]
NKLogReader by ELN.
NKNanoKernelInfo: logi addr 68ffedc0, struct ver 0228, 352 bytes.
NKNanoKernelInfo is within the Kernel Data Page. KDP phys addr 5f7fe000.
NanoKernel log starts after one blank line.

Hello from the builtin multitasking NanoKernel. Version: 0228
Kernel code base at 0x00f10000  Physical RAM size 0x5fffc000 bytes
Created motherboard coherence group. ID 00010001
NKCreateAddressSpaceSub - group at 0x5f7fc1c0 00010001
Created system address space. ID 00030001
 BATs ffc0007f 00c00043   6800001f 00f00043   00000000 00000000   00000000 00000000
Init ready queue 00000000 00000000 00008652
Init ready queue 00000001 00000000 00043290
Init ready queue 00000002 00000000 00219480
Init ready queue 00000003 00000000 010ca400
System context at 0x5f7ff100  Vector save area at 0x5f7fb8e0  SDR1 0x5f80003f
Adding blue task 00050001 to the ready queue
Starting timeslicing
Adding idle task 00070001 to the ready queue
NKCreateAddressSpaceSub - group at 0x5f7fc1c0 00010001
Priming the system free list with 208 pages.
VMMaxVirtualPages: 00064000 VMLogicalPages: 00000000
Interrupt handler kind: 06
Converting PMDTs to areas
 CreateArea [ 00000000 5f645fff ] ID 000a0001 placed ... created
 CreateArea [ 64000000 6417ffff ] ID 000b0001 placed ... created
 CreateArea [ 68fef000 68feffff ] ID 000c0001 placed ... created
 CreateArea [ 68ff5000 68ffefff ] ID 000d0001 placed ... created
 CreateArea [ 68fff000 68ffffff ] ID 000e0001 placed ... created
 CreateArea [ 6fffe000 6fffefff ] ID 000f0001 placed ... created
 CreateArea [ 80000000 8fffffff ] ID 00100001 placed ... created
 CreateArea [ 90000000 9001ffff ] ID 00110001 placed ... created
 CreateArea [ 91000000 91ffffff ] ID 00120001 placed ... created
 CreateArea [ 98000000 9fffffff ] ID 00130001 placed ... created
 CreateArea [ f0000000 f4ffffff ] ID 00140001 placed ... created
 CreateArea [ f5000000 f5000fff ] ID 00150001 placed ... created
 CreateArea [ f5001000 f50fffff ] ID 00160001 placed ... created
 CreateArea [ f5100000 f51fffff ] ID 00170001 placed ... created
 CreateArea [ f5200000 f53fffff ] ID 00180001 placed ... created
 CreateArea [ f5400000 ffffffff ] ID 00190001 placed ... created
 CreateArea [ 68f16000 68f16fff ] ID 001a0001 placed ... created
 CreateArea [ deadb000 deadbfff ] ID 001b0001 placed ... created
Reset system - Into the 68K fire: 0000d032 6806e8c0
ResetSystem trap entered
Kernel code base at 0x00f10000  Physical RAM size 0x5fffc000 bytes
Created motherboard coherence group. ID 00010001
NKCreateAddressSpaceSub - group at 0x5f7fc1c0 00010001
Created system address space. ID 00030001
 BATs ffc0007f 00c00043   6800001f 00f00043   00000000 00000000   00000000 00000000
Init ready queue 00000000 00000000 00008652
Init ready queue 00000001 00000000 00043290
Init ready queue 00000002 00000000 00219480
Init ready queue 00000003 00000000 010ca400
System context at 0x5f7ff100  Vector save area at 0x5f7fb8e0  SDR1 0x5f80003f
Adding blue task 00050001 to the ready queue
Starting timeslicing
Adding idle task 00070001 to the ready queue
NKCreateAddressSpaceSub - group at 0x5f7fc1c0 00010001
Priming the system free list with 208 pages.
VMMaxVirtualPages: 00064000 VMLogicalPages: 0005f646
Interrupt handler kind: 06
Converting PMDTs to areas
 CreateArea [ 00000000 5f645fff ] ID 000a0001 placed ... created
 CreateArea [ 64000000 6417ffff ] ID 000b0001 placed ... created
 CreateArea [ 68fef000 68feffff ] ID 000c0001 placed ... created
 CreateArea [ 68ff5000 68ffefff ] ID 000d0001 placed ... created
 CreateArea [ 68fff000 68ffffff ] ID 000e0001 placed ... created
 CreateArea [ 6fffe000 6fffefff ] ID 000f0001 placed ... created
 CreateArea [ 80000000 8fffffff ] ID 00100001 placed ... created
 CreateArea [ 90000000 9001ffff ] ID 00110001 placed ... created
 CreateArea [ 91000000 91ffffff ] ID 00120001 placed ... created
 CreateArea [ 98000000 9fffffff ] ID 00130001 placed ... created
 CreateArea [ f0000000 f4ffffff ] ID 00140001 placed ... created
 CreateArea [ f5000000 f5000fff ] ID 00150001 placed ... created
 CreateArea [ f5001000 f50fffff ] ID 00160001 placed ... created
 CreateArea [ f5100000 f51fffff ] ID 00170001 placed ... created
 CreateArea [ f5200000 f53fffff ] ID 00180001 placed ... created
 CreateArea [ f5400000 ffffffff ] ID 00190001 placed ... created
 CreateArea [ 68f16000 68f16fff ] ID 001a0001 placed ... created
 CreateArea [ deadb000 deadbfff ] ID 001b0001 placed ... created
Reset system - Into the 68K fire: 0002d032 6806c9e8
Extend free pool: phys 0x5ff3e000  virt 0x00000000  count: 1
Extend free pool: phys 0x5ff3d000  virt 0x00000000  count: 2
Extend free pool: phys 0x5ff3c000  virt 0x00000000  count: 3
Extend free pool: phys 0x5ff3b000  virt 0x00000000  count: 4
Extend free pool: phys 0x5ff3a000  virt 0x00000000  count: 5
Extend free pool: phys 0x5ff39000  virt 0x00000000  count: 6
Extend free pool: phys 0x5ff38000  virt 0x00000000  count: 7
Extend free pool: phys 0x5ff37000  virt 0x00000000  count: 8
Extend free pool: phys 0x5ff36000  virt 0x00000000  count: 9
Extend free pool: phys 0x5ff35000  virt 0x00000000  count: 10
Skeleton key inserted at00021032 013c9360
Extend free pool: phys 0x5ff34000  virt 0x00000000  count: 11
Extend free pool: phys 0x5ff33000  virt 0x00000000  count: 12

  If this is of any use or you need the log for the original ROM, let me know.  Oh, and the archives seem to be working correctly now with Classilla and Stuffit Expander in OS 9.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: nanopico on May 25, 2017, 05:43:20 AM
  Okay, so I tried this again after getting home from work this evening.  The first ROM prevents my MDD FW400 from recognizing the drive as a valid boot device.  The second ROM does get recognized but fails in exactly the same way as it did for MacTron.  (I won't bother posting an identical screenshot.)  I don't know what the deal is with the first version of the ROM not playing nice with my machine, but at least I know it's just something with that file given that the second version is recognized.  I will try again on the MDD once you have made further adjustments.

<edit>  Just for the hell of it I tried booting ROM v2 on a Quicksilver.  Now I know that's not particularly useful since this machine cannot have more than 1.5GB of RAM installed in it at all, but I just wanted to see if the boot would complete on a different machine.  It did boot without issue with a machine max RAM of 1.5GB present.  Here's the log output:

Code: [Select]
NKLogReader by ELN.
NKNanoKernelInfo: logi addr 68ffedc0, struct ver 0228, 352 bytes.
NKNanoKernelInfo is within the Kernel Data Page. KDP phys addr 5f7fe000.
NanoKernel log starts after one blank line.

Hello from the builtin multitasking NanoKernel. Version: 0228
Kernel code base at 0x00f10000  Physical RAM size 0x5fffc000 bytes
Created motherboard coherence group. ID 00010001
NKCreateAddressSpaceSub - group at 0x5f7fc1c0 00010001
Created system address space. ID 00030001
 BATs ffc0007f 00c00043   6800001f 00f00043   00000000 00000000   00000000 00000000
Init ready queue 00000000 00000000 00008652
Init ready queue 00000001 00000000 00043290
Init ready queue 00000002 00000000 00219480
Init ready queue 00000003 00000000 010ca400
System context at 0x5f7ff100  Vector save area at 0x5f7fb8e0  SDR1 0x5f80003f
Adding blue task 00050001 to the ready queue
Starting timeslicing
Adding idle task 00070001 to the ready queue
NKCreateAddressSpaceSub - group at 0x5f7fc1c0 00010001
Priming the system free list with 208 pages.
VMMaxVirtualPages: 00064000 VMLogicalPages: 00000000
Interrupt handler kind: 06
Converting PMDTs to areas
 CreateArea [ 00000000 5f645fff ] ID 000a0001 placed ... created
 CreateArea [ 64000000 6417ffff ] ID 000b0001 placed ... created
 CreateArea [ 68fef000 68feffff ] ID 000c0001 placed ... created
 CreateArea [ 68ff5000 68ffefff ] ID 000d0001 placed ... created
 CreateArea [ 68fff000 68ffffff ] ID 000e0001 placed ... created
 CreateArea [ 6fffe000 6fffefff ] ID 000f0001 placed ... created
 CreateArea [ 80000000 8fffffff ] ID 00100001 placed ... created
 CreateArea [ 90000000 9001ffff ] ID 00110001 placed ... created
 CreateArea [ 91000000 91ffffff ] ID 00120001 placed ... created
 CreateArea [ 98000000 9fffffff ] ID 00130001 placed ... created
 CreateArea [ f0000000 f4ffffff ] ID 00140001 placed ... created
 CreateArea [ f5000000 f5000fff ] ID 00150001 placed ... created
 CreateArea [ f5001000 f50fffff ] ID 00160001 placed ... created
 CreateArea [ f5100000 f51fffff ] ID 00170001 placed ... created
 CreateArea [ f5200000 f53fffff ] ID 00180001 placed ... created
 CreateArea [ f5400000 ffffffff ] ID 00190001 placed ... created
 CreateArea [ 68f16000 68f16fff ] ID 001a0001 placed ... created
 CreateArea [ deadb000 deadbfff ] ID 001b0001 placed ... created
Reset system - Into the 68K fire: 0000d032 6806e8c0
ResetSystem trap entered
Kernel code base at 0x00f10000  Physical RAM size 0x5fffc000 bytes
Created motherboard coherence group. ID 00010001
NKCreateAddressSpaceSub - group at 0x5f7fc1c0 00010001
Created system address space. ID 00030001
 BATs ffc0007f 00c00043   6800001f 00f00043   00000000 00000000   00000000 00000000
Init ready queue 00000000 00000000 00008652
Init ready queue 00000001 00000000 00043290
Init ready queue 00000002 00000000 00219480
Init ready queue 00000003 00000000 010ca400
System context at 0x5f7ff100  Vector save area at 0x5f7fb8e0  SDR1 0x5f80003f
Adding blue task 00050001 to the ready queue
Starting timeslicing
Adding idle task 00070001 to the ready queue
NKCreateAddressSpaceSub - group at 0x5f7fc1c0 00010001
Priming the system free list with 208 pages.
VMMaxVirtualPages: 00064000 VMLogicalPages: 0005f646
Interrupt handler kind: 06
Converting PMDTs to areas
 CreateArea [ 00000000 5f645fff ] ID 000a0001 placed ... created
 CreateArea [ 64000000 6417ffff ] ID 000b0001 placed ... created
 CreateArea [ 68fef000 68feffff ] ID 000c0001 placed ... created
 CreateArea [ 68ff5000 68ffefff ] ID 000d0001 placed ... created
 CreateArea [ 68fff000 68ffffff ] ID 000e0001 placed ... created
 CreateArea [ 6fffe000 6fffefff ] ID 000f0001 placed ... created
 CreateArea [ 80000000 8fffffff ] ID 00100001 placed ... created
 CreateArea [ 90000000 9001ffff ] ID 00110001 placed ... created
 CreateArea [ 91000000 91ffffff ] ID 00120001 placed ... created
 CreateArea [ 98000000 9fffffff ] ID 00130001 placed ... created
 CreateArea [ f0000000 f4ffffff ] ID 00140001 placed ... created
 CreateArea [ f5000000 f5000fff ] ID 00150001 placed ... created
 CreateArea [ f5001000 f50fffff ] ID 00160001 placed ... created
 CreateArea [ f5100000 f51fffff ] ID 00170001 placed ... created
 CreateArea [ f5200000 f53fffff ] ID 00180001 placed ... created
 CreateArea [ f5400000 ffffffff ] ID 00190001 placed ... created
 CreateArea [ 68f16000 68f16fff ] ID 001a0001 placed ... created
 CreateArea [ deadb000 deadbfff ] ID 001b0001 placed ... created
Reset system - Into the 68K fire: 0002d032 6806c9e8
Extend free pool: phys 0x5ff3e000  virt 0x00000000  count: 1
Extend free pool: phys 0x5ff3d000  virt 0x00000000  count: 2
Extend free pool: phys 0x5ff3c000  virt 0x00000000  count: 3
Extend free pool: phys 0x5ff3b000  virt 0x00000000  count: 4
Extend free pool: phys 0x5ff3a000  virt 0x00000000  count: 5
Extend free pool: phys 0x5ff39000  virt 0x00000000  count: 6
Extend free pool: phys 0x5ff38000  virt 0x00000000  count: 7
Extend free pool: phys 0x5ff37000  virt 0x00000000  count: 8
Extend free pool: phys 0x5ff36000  virt 0x00000000  count: 9
Extend free pool: phys 0x5ff35000  virt 0x00000000  count: 10
Skeleton key inserted at00021032 013c9360
Extend free pool: phys 0x5ff34000  virt 0x00000000  count: 11
Extend free pool: phys 0x5ff33000  virt 0x00000000  count: 12

  If this is of any use or you need the log for the original ROM, let me know.  Oh, and the archives seem to be working correctly now with Classilla and Stuffit Expander in OS 9.

I edited this for you to remove ELN's info to the public.  Hope that's ok.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: MacOS Plus on May 25, 2017, 09:24:59 AM
  Yes, thanks.  I didn't catch that it was in there at the top of the text.  I'll keep that in mind for later.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: ELN on June 04, 2017, 02:00:42 AM
Hi everyone,

I have added a new component to the Mac OS ROM: the "Wedge". The Wedge is a chunk of C code inserted into the ROM that runs between the Trampoline and the NanoKernel. It takes the structures prepared by the Trampoline, carefully patches them, spits out some textual debug output, and then hands control to the NanoKernel. The debug output remains hidden in memory while the machine boots up. Once (and if) the machine is booted, it can be read by a small app, WedgeLogReader.

At present the only task of the Wedge is to expand the main segment of Mac OS memory. This allows an extra 128MB of RAM to be used, on top of the 1.5GB limit.

Why go to the trouble of bootstrapping a C runtime? Two reasons:


And what cool stuff is in the attached archive?


Those testers who had trouble with the previous patched ROMs, would you please try this out? The best information to post would be: WedgeDryRun output, WedgeLogReader output, NKLogReader output, and before/after screenshots of About This Computer. Please post text inline! That way I can read it on my phone, and it gets indexed by Google.

For the morbidly curious, here is the Wedge C code. The same code runs in both the attached ROM and the WedgeLogReader. I don't suppose that one of the admins feels like changing the tab size to 4?

Code: [Select]
#include <PPCInfoRecordsPriv.h>
#include <MacTypes.h>


#define kFlagNone 0
#define kFlagIRP 1
#define kFlagKDP 2
#define kFlagEDP 3


#define LA_InfoRecord_Orig 0x5fffe000UL
#define LA_UniversalArea_Orig 0x64000000UL
#define LA_RiscRom_Orig 0x68000000UL
#define LA_ConfigInfo_Orig 0x68fef000UL
#define LA_KernelData_Orig 0x68ffe000UL
#define LA_KernelData_Orig 0x68fff000UL


#define kConfigInfoSize 4096
#define kHardwareInfoSize 192


#define kPatchInfoRecord 0x00000001UL
#define kPatchUniversalArea 0x00000010UL
#define kCanPatchEmulator 0x80000000UL


#define kDelta 0x80000000UL


void *memcpy(void *dest, void *src, long n)
{
long i;

char *d = (char *)dest;
char *s = (char *)src;

if(dest < src) /* copy left to right */
{
for(i=0; i<n; i++) d[i] = s[i];
}
else /* copy right to left */
{
for(i=n-1; i>=0; i--) d[i] = s[i];
}

return dest;
}


void *memset(void *dest, int v, long n)
{
char *d = (char *)dest;

while(n) d[--n] = (char)v;

return dest;
}


struct PME
{
unsigned long word1; /* LogicalPageIndexInSegment(16b) || PageCountMinus1(16b) */
unsigned long word2; /* PhysicalPage(20b) || pageAttr(12b) */
};
typedef struct PME PME;


PME *getPageMapPtr(NKConfigurationInfo *ConfigInfo)
{
return (PME *)((long)ConfigInfo + (long)ConfigInfo->PageMapInitOffset);
}


int pmeIsBlank(PME *pme)
{
if(pme->word1 != 0x0000ffffUL) return 0;
if((pme->word2 & 0x00000f00UL) != 0x00000a00UL) return 0;
return 1;
}


int segmentOf(unsigned long LA)
{
return LA >> 28;
}


/*
Create a PageMapEntry (specifying a logical-to-physical mapping within a PowerPC segment)
and insert it into a ConfigInfo struct, taking care not to corrupt the structure.

(Intended to replicate the behaviour of the Trampoline, based on its debug output)
*/

int AddPageMapEntry(NKConfigurationInfo *ci, unsigned long LA, unsigned long count, unsigned long PA, unsigned long pageAttr, unsigned long flags)
{
PME *pageMapBase = getPageMapPtr(ci);

PME newEnt;
int entryOffset; /* offset of our new entry within the PageMap (bytes) */

int i;


/* Format string lifted from Trampoline (changed a tiny bit). */

printf("AddPageMapEntry: LA = 0x%08X, count = 0x%05X, PA = 0x%08X, pageAttr = 0x%04X, flags = 0x%02X.\n", LA, count, PA, pageAttr, flags);


/* "Design" the new entry. */

newEnt.word1 = ((LA << 4) & 0xffff0000UL) | (count - 1);
newEnt.word2 = (PA & 0xfffff000UL) | pageAttr;


/* Choose an offset for the entry. */

entryOffset = ci->SegMap32SupInit[segmentOf(LA) * 2];

for(;;)
{
PME *existing;

existing = (PME *)((long)pageMapBase + (long)entryOffset);

if(pmeIsBlank(existing)) break;
if((existing->word1 & 0xffff0000UL) > (newEnt.word1 & 0xffff0000UL)) break;

entryOffset += sizeof(PME);
}


/* Shift the entries above our new entry by 8 bytes. */

for(i=0; i<8; i++)
{
if(*((char *)pageMapBase + ci->PageMapInitSize + i) != 0)
{
printf("PageMap overflow!\n", entryOffset/sizeof(PME));
return 100;
}
}

for(i = ci->PageMapInitSize - 1; i >= entryOffset; i--)
{
*((char *)pageMapBase + i + 8) = *((char *)pageMapBase + i);
}


/* Bump the declared PageMap size by 8 bytes. (ignored by kernel?) */

ci->PageMapInitSize += sizeof(PME);


/* The SegMap (four copies) contains an offset into the PageMap at every second word -- update these. */

for(i=segmentOf(LA)+1; i<16; i++)
{
ci->SegMap32SupInit[i * 2] += sizeof(PME);
ci->SegMap32UsrInit[i * 2] += sizeof(PME);
ci->SegMap32CPUInit[i * 2] += sizeof(PME);
ci->SegMap32OvlInit[i * 2] += sizeof(PME);
}


/* Adjust the pointers to the special PageMap entries. */

if(ci->PageMapIRPOffset >= entryOffset) ci->PageMapIRPOffset += sizeof(PME);
if(ci->PageMapKDPOffset >= entryOffset) ci->PageMapKDPOffset += sizeof(PME);
if(ci->PageMapEDPOffset >= entryOffset) ci->PageMapEDPOffset += sizeof(PME);


/* Set the correct pointer if it is a special one */

if(flags == kFlagIRP)
ci->PageMapIRPOffset = entryOffset;
else if(flags == kFlagKDP)
ci->PageMapKDPOffset = entryOffset;
else if(flags == kFlagEDP)
ci->PageMapEDPOffset = entryOffset;


/* Save our new entry in the gap we have made in the PageMap. */

memcpy((char *)pageMapBase + entryOffset, &newEnt, sizeof(PME));

return 0;
}


/*
Create a blank PageMap inside a pre-existing ConfigInfo structure, with only
those "dummy" entries that the Trampoline would create before calling
AddPageMapEntry.

(Intended to replicate the behaviour of the Trampoline, based on its debug output)
*/

void ErasePageMapTable(NKConfigurationInfo *ci)
{
PME *pageMapBase;
long *pmp;
int seg;


printf("ErasePageMapTable at offset 0x%x\n\n", ci->PageMapInitOffset);

/* Zero out the existing PageMap */

pageMapBase = getPageMapPtr(ci);
memset(pageMapBase, 0, ci->PageMapInitSize);


/* Count up with pmp */

pmp = (long *)pageMapBase;

ci->PageMapInitOffset = (long)pageMapBase - (long)ci;

for(seg=0; seg<16; seg++)
{
ci->SegMap32SupInit[seg * 2] =
ci->SegMap32UsrInit[seg * 2] =
ci->SegMap32CPUInit[seg * 2] =
ci->SegMap32OvlInit[seg * 2] = (long)pmp - (long)pageMapBase;

if(seg <= 5)
{
*pmp++ = 0x0000ffffUL; *pmp++ = 0x00000a00UL;
*pmp++ = 0x0000ffffUL; *pmp++ = 0x00000a00UL;
}
else if(seg >= 6 && seg <= 7)
{
*pmp++ = 0x0000ffffUL; *pmp++ = 0x00000a01UL;
*pmp++ = 0x0000ffffUL; *pmp++ = 0x00000a01UL;
*pmp++ = 0x0000ffffUL; *pmp++ = 0x00000a00UL;
}
else if(seg >= 8)
{
*pmp++ = 0x0000ffffUL; *pmp++ = 0x00000a01UL + (seg << 28);
*pmp++ = 0x0000ffffUL; *pmp++ = 0x00000a00UL;
}
}

ci->PageMapInitSize = (long)pmp - (long)pageMapBase;


/* Zero out the special pointers */

ci->PageMapIRPOffset = 0;
ci->PageMapKDPOffset = 0;
ci->PageMapEDPOffset = 0;
}


int PatchMacOSAddressSpace(long patches, unsigned long makeMemAvail, NKConfigurationInfo *ci, NKConfigurationInfo *newci, NKHWInfo *hi, NKHWInfo *newhi)
{
int seg;
PME *pageMapBase;
PME *entryp;

unsigned long LA, newLA, count, PA, pageAttr, flags;

int ret;
int offset;

unsigned long i;


pageMapBase = getPageMapPtr(ci);

ErasePageMapTable(newci);

printf("PatchMacOSAddressSpace: makeMemAvail %08x\n", makeMemAvail);

for(seg=0; seg<16; seg++)
{
for(offset = ci->SegMap32SupInit[seg*2];; offset += sizeof (PME)) /* Iterate over PMEs. */
{
entryp = (PME *)((long)pageMapBase + offset);


/* Misc error conditions */

if(seg < 15 && offset >= ci->SegMap32SupInit[(seg+1) * 2])
{
printf("Overran this segment of the PageMap!\n\n");
return 101;
}
if(offset >= ci->PageMapInitSize)
{
printf("Overran the whole PageMap!\n\n");
return 102;
}

if(pmeIsBlank(entryp)) break;


/* Extract info from PME */

LA = newLA = (seg << 28) | (entryp->word1 >> 4 & 0x0ffff000UL);
count = (entryp->word1 & 0x0000ffffUL) + 1;
PA = entryp->word2 & 0xfffff000UL;
pageAttr = entryp->word2 & 0x00000fffUL;

if(offset == ci->PageMapIRPOffset)
flags = kFlagIRP;
else if(offset == ci->PageMapKDPOffset)
flags = kFlagKDP;
else if(offset == ci->PageMapEDPOffset)
flags = kFlagEDP;
else
flags = kFlagNone;

printf("    nontrivial PME   LA = 0x%08X, count = 0x%05X, PA = 0x%08X, pageAttr = 0x%04X, flags = 0x%02X.\n    ", LA, count, PA, pageAttr, flags);


/* Delete those two annoying PMEs that signal to end the MacOS area */
/* (LA 50000000 count fffe PA 00000000 pageAttr a00) */

if((LA << 4) == 0 && (pageAttr & 0xf00) == 0xa00)
{
printf("MacOS area delimiter: skipping\n\n");
continue;
}


/* Move the InfoRecord page. */

if((patches & kPatchInfoRecord) && LA == LA_InfoRecord_Orig)
{
printf("**IRP**\n    ");

newLA += kDelta;

/* IRP logical address in ConfigInfo */
newci->LA_InfoRecord = newLA;

/* IRP logical address is hardcoded into emulator by lis/ori, so change that. */
if(patches & kCanPatchEmulator)
{
unsigned short hi = LA >> 16;
unsigned short lo = LA & 0xffff;
unsigned short *em = (unsigned short *)0x00f60000UL;

for(i=0; i<0x10000; i+=2)
{
if(em[i+1] == hi && em[i+3] == lo)
{
printf("Patching Emulator lis/ori @ %05x\n    ", i*2);
em[i+1] = newLA >> 16;
em[i+3] = newLA & 0xffff;
break;
}
}
}
}


/* Move the area containing the Universal structures and the Device Tree */

if((patches & kPatchUniversalArea) && LA == LA_UniversalArea_Orig)
{
printf("**Universal/DeviceTree area**\n    ");

newLA += kDelta;

/* Logical address pointers in HardwareInfo */
newhi->DeviceTreeBase = hi->DeviceTreeBase - LA + newLA;
newhi->UniversalInfoTableBase = hi->UniversalInfoTableBase - LA + newLA;
}


if(newLA < makeMemAvail)
{
printf("makeMemAvail is too large with this PME in the way.\n\n");
return 103;
}


/* If this PME was unchanged then newLA will just equal the original LA. */

ret = AddPageMapEntry(newci, newLA, count, PA, pageAttr, flags);
if(ret) return ret;

printf("\n");
}
}


/* Done all meaningful PMEs... put the "MacOS area delimiter" back in */

printf("    Reinserting the MacOS area delimiters:\n");
for(i=0; i<2; i++)
{
printf("    ");
ret = AddPageMapEntry(newci, makeMemAvail & 0xf0000000UL, makeMemAvail >> 12 & 0xffffUL, 0UL, 0xa00, 0);
if(ret) return ret;
}

printf("\n");

return 0;
}


void DebugDumpPageMap(NKConfigurationInfo *ci)
{
PME *pageMapBase, *pme;
int i, j;

pageMapBase = getPageMapPtr(ci);

printf("DebugDumpPageMap\n");

for(i=0; i<ci->PageMapInitSize; i+=sizeof(PME))
{
for(j=0; j<16; j++)
{
if(ci->SegMap32SupInit[j*2] == i)
{
printf("%X ", j);
break;
}
}
if(j == 16) printf("  ");

pme = (PME *)((long)pageMapBase + i);

printf("%03x: %08x %08x", i, pme->word1, pme->word2);

if(i == ci->PageMapIRPOffset)
{
printf(" IRP");
}
else if(i == ci->PageMapEDPOffset)
{
printf(" EDP");
}
else if(i == ci->PageMapKDPOffset)
{
printf(" KDP");
}

printf("\n");
}
printf("\n");
}


/* Main function for Wedge patch */

void wedge(NKConfigurationInfo *ci, NKProcessorInfo *pi, NKSystemInfo *si, NKDiagnosticInfo *di, OSType rtasFour, unsigned long rtasProc, NKHWInfo *hi)
{
char ci_tmp[kConfigInfoSize], hi_tmp[kHardwareInfoSize];
int ret;

printf("Hello from the Wedge.\n");
printf("      ConfigInfo (r3) @ %08x\n", ci);
printf("   ProcessorInfo (r4) @ %08x\n", pi);
printf("      SystemInfo (r5) @ %08x\n", si);
printf("  DiagnosticInfo (r6) @ %08x\n", di);
printf("            RTAS (r7) = %08x\n", rtasFour);
printf("        RTASProc (r8) @ %08x\n", rtasProc);
printf("    HardwareInfo (r9) @ %08x\n", hi);
printf("\n");


/* PatchMacOSAddressSpace */

DebugDumpPageMap((NKConfigurationInfo *)ci);

printf("Rearranging the MacOS address space...\n\n");
memcpy(ci_tmp, ci, sizeof ci_tmp);
memcpy(hi_tmp, hi, sizeof hi_tmp);

ret = PatchMacOSAddressSpace(kPatchInfoRecord | kPatchUniversalArea | kCanPatchEmulator,
                             0x68000000UL,
                             (NKConfigurationInfo *)ci, (NKConfigurationInfo *)ci_tmp,
                             (NKHWInfo *)hi, (NKHWInfo *)hi_tmp);

if(!ret)
{
printf("Copying modified ConfigInfo and HWInfo over the originals.\n\n");
memcpy(ci, ci_tmp, sizeof ci_tmp);
memcpy(hi, hi_tmp, sizeof hi_tmp);

DebugDumpPageMap((NKConfigurationInfo *)ci);
}
else
{
printf("PatchMacOSAddressSpace failed with error %d.\n", ret);
}


/* Insert more clever, interesting patches here. */


/* Uses r3-r9 -- compiler doesn't really need a prototype for this. */
printf("\nHanding over to the NanoKernel.\n");
NanoKernelJump(ci, pi, si, di, rtasFour, rtasProc, hi);
}


/* Main function for MPW Tool */

void main(void)
{
char ci_tmp[kConfigInfoSize], hi_tmp[kHardwareInfoSize];
char *ci, *hi;
long nk_struct_ver, nk_struct_len;
int ret;

printf("Hello from the (dry-run) Wedge.\n");

ci = (char *)0x68fef000UL;
printf("      ConfigInfo @ %08x\n", ci);

NKLocateInfoRecord(6, &hi, &nk_struct_ver, &nk_struct_len);
printf("    HardwareInfo @ %08x\n", hi);

printf("\n");


DebugDumpPageMap((NKConfigurationInfo *)ci);

printf("Copying the system ConfigInfo and HardwareInfo structs.\n\n");
memcpy(ci_tmp, ci, sizeof ci_tmp);
memcpy(hi_tmp, hi, sizeof hi_tmp);

ret = PatchMacOSAddressSpace(kPatchInfoRecord | kPatchUniversalArea,
                             0x68000000UL,
                             (NKConfigurationInfo *)ci, (NKConfigurationInfo *)ci_tmp,
                             (NKHWInfo *)hi, (NKHWInfo *)hi_tmp);

if(!ret)
{
printf("PatchMacOSAddressSpace succeeded (but was forbidden from patching the Emulator).\n\n");

DebugDumpPageMap((NKConfigurationInfo *)ci_tmp);
}
else
{
printf("PatchMacOSAddressSpace failed with error %d.\n", ret);
}
}

And here is some sample output.

Code: [Select]
Hello from the Wedge.
      ConfigInfo (r3) @ 00003000
   ProcessorInfo (r4) @ 0fffff40
      SystemInfo (r5) @ 0ffffe00
  DiagnosticInfo (r6) @ 00000000
            RTAS (r7) = 52544153
        RTASProc (r8) @ 00000000
    HardwareInfo (r9) @ 0ffffd40

DebugDumpPageMap
0 000: 0000ffff 00000a00
  008: 0000ffff 00000a00
1 010: 0000ffff 00000a00
  018: 0000ffff 00000a00
2 020: 0000ffff 00000a00
  028: 0000ffff 00000a00
3 030: 0000ffff 00000a00
  038: 0000ffff 00000a00
4 040: 0000ffff 00000a00
  048: 0000ffff 00000a00
5 050: 0000fffd 00000a00
  058: 0000fffd 00000a00
  060: fffe0000 00000012 IRP
  068: 0000ffff 00000a00
  070: 0000ffff 00000a00
6 078: 4000017f 0ab00012
  080: 8fef0000 00003013
  088: 8ffe0000 00000011 KDP
  090: 8fff0000 00000012 EDP
  098: 0000ffff 00000a01
  0a0: 0000ffff 00000a01
  0a8: 0000ffff 00000a00
7 0b0: 0000ffff 00000a01
  0b8: 0000ffff 00000a01
  0c0: 0000ffff 00000a00
8 0c8: 0000ffff 8000003a
  0d0: 0000ffff 80000a01
  0d8: 0000ffff 00000a00
9 0e0: 0000000f 9000003a
  0e8: 0020001f 9002003a
  0f0: 80007fff 98000032
  0f8: 0000ffff 90000a01
  100: 0000ffff 00000a00
A 108: 0000ffff a0000a01
  110: 0000ffff 00000a00
B 118: 0000ffff b0000a01
  120: 0000ffff 00000a00
C 128: 0000ffff c0000a01
  130: 0000ffff 00000a00
D 138: 0000ffff d0000a01
  140: 0000ffff 00000a00
E 148: 0000ffff e0000a01
  150: 0000ffff 00000a00
F 158: 0000ffff f000003a
  160: 0000ffff f0000a01
  168: 0000ffff 00000a00

Rearranging the MacOS address space...

ErasePageMapTable at offset 0x3ac

PatchMacOSAddressSpace: makeMemAvail 68000000
    nontrivial PME   LA = 0x50000000, count = 0x0FFFE, PA = 0x00000000, pageAttr = 0x0A00, flags = 0x00.
    MacOS area delimiter: skipping

    nontrivial PME   LA = 0x50000000, count = 0x0FFFE, PA = 0x00000000, pageAttr = 0x0A00, flags = 0x00.
    MacOS area delimiter: skipping

    nontrivial PME   LA = 0x5FFFE000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0012, flags = 0x01.
    **IRP**
    Patching Emulator lis/ori @ 181e8
    AddPageMapEntry: LA = 0xDFFFE000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0012, flags = 0x01.

    nontrivial PME   LA = 0x64000000, count = 0x00180, PA = 0x0AB00000, pageAttr = 0x0012, flags = 0x00.
    **Universal/DeviceTree area**
    AddPageMapEntry: LA = 0xE4000000, count = 0x00180, PA = 0x0AB00000, pageAttr = 0x0012, flags = 0x00.

    nontrivial PME   LA = 0x68FEF000, count = 0x00001, PA = 0x00003000, pageAttr = 0x0013, flags = 0x00.
    AddPageMapEntry: LA = 0x68FEF000, count = 0x00001, PA = 0x00003000, pageAttr = 0x0013, flags = 0x00.

    nontrivial PME   LA = 0x68FFE000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0011, flags = 0x02.
    AddPageMapEntry: LA = 0x68FFE000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0011, flags = 0x02.

    nontrivial PME   LA = 0x68FFF000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0012, flags = 0x03.
    AddPageMapEntry: LA = 0x68FFF000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0012, flags = 0x03.

    nontrivial PME   LA = 0x80000000, count = 0x10000, PA = 0x80000000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x80000000, count = 0x10000, PA = 0x80000000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x90000000, count = 0x00010, PA = 0x90000000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x90000000, count = 0x00010, PA = 0x90000000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x90020000, count = 0x00020, PA = 0x90020000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x90020000, count = 0x00020, PA = 0x90020000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x98000000, count = 0x08000, PA = 0x98000000, pageAttr = 0x0032, flags = 0x00.
    AddPageMapEntry: LA = 0x98000000, count = 0x08000, PA = 0x98000000, pageAttr = 0x0032, flags = 0x00.

    nontrivial PME   LA = 0xF0000000, count = 0x10000, PA = 0xF0000000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0xF0000000, count = 0x10000, PA = 0xF0000000, pageAttr = 0x003A, flags = 0x00.

    Reinserting the MacOS area delimiters:
    AddPageMapEntry: LA = 0x60000000, count = 0x08000, PA = 0x00000000, pageAttr = 0x0A00, flags = 0x00.
    AddPageMapEntry: LA = 0x60000000, count = 0x08000, PA = 0x00000000, pageAttr = 0x0A00, flags = 0x00.

Copying modified ConfigInfo and HWInfo over the originals.

DebugDumpPageMap
0 000: 0000ffff 00000a00
  008: 0000ffff 00000a00
1 010: 0000ffff 00000a00
  018: 0000ffff 00000a00
2 020: 0000ffff 00000a00
  028: 0000ffff 00000a00
3 030: 0000ffff 00000a00
  038: 0000ffff 00000a00
4 040: 0000ffff 00000a00
  048: 0000ffff 00000a00
5 050: 0000ffff 00000a00
  058: 0000ffff 00000a00
6 060: 00007fff 00000a00
  068: 00007fff 00000a00
  070: 8fef0000 00003013
  078: 8ffe0000 00000011 KDP
  080: 8fff0000 00000012 EDP
  088: 0000ffff 00000a01
  090: 0000ffff 00000a01
  098: 0000ffff 00000a00
7 0a0: 0000ffff 00000a01
  0a8: 0000ffff 00000a01
  0b0: 0000ffff 00000a00
8 0b8: 0000ffff 8000003a
  0c0: 0000ffff 80000a01
  0c8: 0000ffff 00000a00
9 0d0: 0000000f 9000003a
  0d8: 0020001f 9002003a
  0e0: 80007fff 98000032
  0e8: 0000ffff 90000a01
  0f0: 0000ffff 00000a00
A 0f8: 0000ffff a0000a01
  100: 0000ffff 00000a00
B 108: 0000ffff b0000a01
  110: 0000ffff 00000a00
C 118: 0000ffff c0000a01
  120: 0000ffff 00000a00
D 128: fffe0000 00000012 IRP
  130: 0000ffff d0000a01
  138: 0000ffff 00000a00
E 140: 4000017f 0ab00012
  148: 0000ffff e0000a01
  150: 0000ffff 00000a00
F 158: 0000ffff f000003a
  160: 0000ffff f0000a01
  168: 0000ffff 00000a00


Handing over to the NanoKernel.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: Knezzen on June 04, 2017, 02:37:19 AM
Out of curiosity, technically speaking, what stops you to extend the usable RAM space beyond the 128mb you already extended onto?
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: ELN on June 04, 2017, 03:03:28 AM
Out of curiosity, technically speaking, what stops you to extend the usable RAM space beyond the 128mb you already extended onto?

Very good question.

Note the "nontrivial PME" lines in the output above. These list the areas that the Trampoline instructs the NanoKernel to locate in logical memory, in addition to the MacOS logical area starting at address zero. The Wedge is moving two of them to a location much higher in memory.

The first one is the InfoRecord Page (IRP). With that at 5fffe000, the main area can only expand to a whisker under 1.5GB. By moving the IRP and another small area at 64000000, we can expand up to the next obstacle at 68000000 (which is actually a mapping of the upper megabyte of the ROM, and is not listed in the PageMap above). This gives us 1.625GB. With luck, we will get the full 2GB soon.

The data and code in these hardcoded areas mostly concern the interface between the low-level PowerPC system and the high-level 68k system. There is rarely a need for application code to access them directly, and there are (usually) ways of querying their addresses at runtime, but some software still hardcodes them. Moving them therefore presents a small problem for application compatibility. For example, moving the IRP seems to crash PowerMacInfo and Apple System Profiler (and the 68k DR Emulator, but that's fixed). A similar problem arose when the first PCI Power Macs moved the ROM image from 40000000 (1GB) to FFC00000 (just below the 4GB mark). I suspect that this is the cause of the instability reported on Macs with more than 1GB of RAM.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: Knezzen on June 04, 2017, 03:11:13 AM
Great explanation! Hoping for the best so I can make use of all the memory in my MDD. Not that I ever used the full 1.5GB usable right now, but anyway ;)
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: Daniel on June 04, 2017, 06:14:30 AM
I just tested it out. It works! I don't have any 2 GB macs, but it works just fine on at least one system. Here are the Wedge and NK logs if they are useful.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: MacTron on June 04, 2017, 09:04:16 AM
It Works!  ;D
(http://macos9lives.com/smforum/index.php?action=dlattach;topic=2860.0;attach=4413;image)
AWESOME ! ;D
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: MacTron on June 04, 2017, 09:14:37 AM
Now I'll post the logs:
NKLogReader:
Code: [Select]
NKNanoKernelInfo: logi addr 68ffedc0, struct ver 0228, 352 bytes.
NKNanoKernelInfo is within the Kernel Data Page. KDP phys addr 7f7fe000.

              NanoKernel Log
              --------------
Hello from the builtin multitasking NanoKernel. Version: 0228
Kernel code base at 0x00f40000  Physical RAM size 0x7fffb000 bytes
Created motherboard coherence group. ID 00010001
NKCreateAddressSpaceSub - group at 0x7f7fc1c0 00010001
Created system address space. ID 00030001
 BATs ffc0007f 00c00043   6800001f 00f00043   00000000 00000000   00000000 00000000
Init ready queue 00000000 00000000 0000a8eb
Init ready queue 00000001 00000000 00054758
Init ready queue 00000002 00000000 002a3ac0
Init ready queue 00000003 00000000 0151d600
System context at 0x7f7ff100  Vector save area at 0x7f7fb8e0  SDR1 0x7f80003f
Adding blue task 00050001 to the ready queue
Starting timeslicing
Adding idle task 00070001 to the ready queue
NKCreateAddressSpaceSub - group at 0x7f7fc1c0 00010001
Priming the system free list with 272 pages.
VMMaxVirtualPages: 00068000 VMLogicalPages: 00000000
Interrupt handler kind: 06
Physical RAM greater than the initial logical area.
 Moving 95622 pages into the system free page list.
Converting PMDTs to areas
 CreateArea [ 00000000 67ffffff ] ID 000a0001 placed ... created
 CreateArea [ 68fef000 68feffff ] ID 000b0001 placed ... created
 CreateArea [ 68ff5000 68ffefff ] ID 000c0001 placed ... created
 CreateArea [ 68fff000 68ffffff ] ID 000d0001 placed ... created
 CreateArea [ 80000000 8005ffff ] ID 000e0001 placed ... created
 CreateArea [ 80060000 80060fff ] ID 000f0001 placed ... created
 CreateArea [ 80061000 8007ffff ] ID 00100001 placed ... created
 CreateArea [ 80080000 80080fff ] ID 00110001 placed ... created
 CreateArea [ 80081000 80081fff ] ID 00120001 placed ... created
 CreateArea [ 90000000 9000ffff ] ID 00130001 placed ... created
 CreateArea [ 90020000 9003ffff ] ID 00140001 placed ... created
 CreateArea [ 98000000 9fffffff ] ID 00150001 placed ... created
 CreateArea [ dfffe000 dfffefff ] ID 00160001 placed ... created
 CreateArea [ e4000000 e417ffff ] ID 00170001 placed ... created
 CreateArea [ f0000000 ffffffff ] ID 00180001 placed ... created
 CreateArea [ 68f16000 68f16fff ] ID 00190001 placed ... created
 CreateArea [ deadb000 deadbfff ] ID 001a0001 placed ... created
Reset system - Into the 68K fire: 0000d032 6806e8c0
ResetSystem trap entered
Kernel code base at 0x00f40000  Physical RAM size 0x7fffb000 bytes
Created motherboard coherence group. ID 00010001
NKCreateAddressSpaceSub - group at 0x7f7fc1c0 00010001
Created system address space. ID 00030001
 BATs ffc0007f 00c00043   6800001f 00f00043   00000000 00000000   00000000 00000000
Init ready queue 00000000 00000000 0000a8eb
Init ready queue 00000001 00000000 00054758
Init ready queue 00000002 00000000 002a3ac0
Init ready queue 00000003 00000000 0151d600
System context at 0x7f7ff100  Vector save area at 0x7f7fb8e0  SDR1 0x7f80003f
Adding blue task 00050001 to the ready queue
Starting timeslicing
Adding idle task 00070001 to the ready queue
NKCreateAddressSpaceSub - group at 0x7f7fc1c0 00010001
Priming the system free list with 272 pages.
VMMaxVirtualPages: 00068000 VMLogicalPages: 00068000
Interrupt handler kind: 06
Physical RAM greater than the initial logical area.
 Moving 95622 pages into the system free page list.
Converting PMDTs to areas
 CreateArea [ 00000000 67ffffff ] ID 000a0001 placed ... created
 CreateArea [ 68fef000 68feffff ] ID 000b0001 placed ... created
 CreateArea [ 68ff5000 68ffefff ] ID 000c0001 placed ... created
 CreateArea [ 68fff000 68ffffff ] ID 000d0001 placed ... created
 CreateArea [ 80000000 8005ffff ] ID 000e0001 placed ... created
 CreateArea [ 80060000 80060fff ] ID 000f0001 placed ... created
 CreateArea [ 80061000 8007ffff ] ID 00100001 placed ... created
 CreateArea [ 80080000 80080fff ] ID 00110001 placed ... created
 CreateArea [ 80081000 80081fff ] ID 00120001 placed ... created
 CreateArea [ 90000000 9000ffff ] ID 00130001 placed ... created
 CreateArea [ 90020000 9003ffff ] ID 00140001 placed ... created
 CreateArea [ 98000000 9fffffff ] ID 00150001 placed ... created
 CreateArea [ dfffe000 dfffefff ] ID 00160001 placed ... created
 CreateArea [ e4000000 e417ffff ] ID 00170001 placed ... created
 CreateArea [ f0000000 ffffffff ] ID 00180001 placed ... created
 CreateArea [ 68f16000 68f16fff ] ID 00190001 placed ... created
 CreateArea [ deadb000 deadbfff ] ID 001a0001 placed ... created
Reset system - Into the 68K fire: 0002d032 6806c9e8
 VMAllocateMemory - creating area at 0x69000000 00080000
 CreateArea [ 69000000 6907ffff ] ID 001b0001 placed ... created
Extend free pool: phys 0x7ff2d000  virt 0x00000000  count: 1
CPU plugin registered
SIGP kResetProcessor
Creating idle task
SIGP kSynchClock
SIGP kStartProcessor
Processor scheduled
Sch: Symmetric Multiprocessing
Sch: On CPU 0001  ID-00000000  SDR1: 7f80003f  CpuDescriptor: 7ff2d750  KDP: 7f7fe000
Sch: Starting SMP idle task
EWA 7ff2da90 ContextPtr 7ff2d430 Flags 00480000 Enables 00000000
Adding idle task 0x7ff2d330 to the ready queue
Sch: Going to 00009002 00f54f04
Extend free pool: phys 0x7ff2c000  virt 0x00000000  count: 2
Extend free pool: phys 0x7ff2b000  virt 0x00000000  count: 3
Extend free pool: phys 0x7ff2a000  virt 0x00000000  count: 4
Extend free pool: phys 0x7ff29000  virt 0x00000000  count: 5
Extend free pool: phys 0x7ff28000  virt 0x00000000  count: 6
Extend free pool: phys 0x7ff27000  virt 0x00000000  count: 7
Extend free pool: phys 0x7ff26000  virt 0x00000000  count: 8
Extend free pool: phys 0x7ff25000  virt 0x00000000  count: 9
Extend free pool: phys 0x7ff24000  virt 0x00000000  count: 10
Extend free pool: phys 0x7ff23000  virt 0x00000000  count: 11

WedgeDryRun:
Code: [Select]
Hello from the (dry-run) Wedge.
      ConfigInfo @ 68fef000
    HardwareInfo @ dfffef00

DebugDumpPageMap
0 000: 0000ffff 00000a00
  008: 0000ffff 00000a00
1 010: 0000ffff 00000a00
  018: 0000ffff 00000a00
2 020: 0000ffff 00000a00
  028: 0000ffff 00000a00
3 030: 0000ffff 00000a00
  038: 0000ffff 00000a00
4 040: 0000ffff 00000a00
  048: 0000ffff 00000a00
5 050: 0000ffff 00000a00
  058: 0000ffff 00000a00
6 060: 00007fff 00000a00
  068: 00007fff 00000a00
  070: 8fef0000 00003013
  078: 8ffe0000 00000011 KDP
  080: 8fff0000 00000012 EDP
  088: 0000ffff 00000a01
  090: 0000ffff 00000a01
  098: 0000ffff 00000a00
7 0a0: 0000ffff 00000a01
  0a8: 0000ffff 00000a01
  0b0: 0000ffff 00000a00
8 0b8: 0000005f 8000003a
  0c0: 00600000 8006003a
  0c8: 0061001e 8006103a
  0d0: 00800000 8008003a
  0d8: 00810000 8008103a
  0e0: 0000ffff 80000a01
  0e8: 0000ffff 00000a00
9 0f0: 0000000f 9000003a
  0f8: 0020001f 9002003a
  100: 80007fff 98000032
  108: 0000ffff 90000a01
  110: 0000ffff 00000a00
A 118: 0000ffff a0000a01
  120: 0000ffff 00000a00
B 128: 0000ffff b0000a01
  130: 0000ffff 00000a00
C 138: 0000ffff c0000a01
  140: 0000ffff 00000a00
D 148: fffe0000 00000012 IRP
  150: 0000ffff d0000a01
  158: 0000ffff 00000a00
E 160: 4000017f 55600012
  168: 0000ffff e0000a01
  170: 0000ffff 00000a00
F 178: 0000ffff f000003a
  180: 0000ffff f0000a01
  188: 0000ffff 00000a00

Copying the system ConfigInfo and HardwareInfo structs.

ErasePageMapTable at offset 0x3ac

PatchMacOSAddressSpace: makeMemAvail 68000000
    nontrivial PME   LA = 0x60000000, count = 0x08000, PA = 0x00000000, pageAttr = 0x0A00, flags = 0x00.
    MacOS area delimiter: skipping

    nontrivial PME   LA = 0x60000000, count = 0x08000, PA = 0x00000000, pageAttr = 0x0A00, flags = 0x00.
    MacOS area delimiter: skipping

    nontrivial PME   LA = 0x68FEF000, count = 0x00001, PA = 0x00003000, pageAttr = 0x0013, flags = 0x00.
    AddPageMapEntry: LA = 0x68FEF000, count = 0x00001, PA = 0x00003000, pageAttr = 0x0013, flags = 0x00.

    nontrivial PME   LA = 0x68FFE000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0011, flags = 0x02.
    AddPageMapEntry: LA = 0x68FFE000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0011, flags = 0x02.

    nontrivial PME   LA = 0x68FFF000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0012, flags = 0x03.
    AddPageMapEntry: LA = 0x68FFF000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0012, flags = 0x03.

    nontrivial PME   LA = 0x80000000, count = 0x00060, PA = 0x80000000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x80000000, count = 0x00060, PA = 0x80000000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x80060000, count = 0x00001, PA = 0x80060000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x80060000, count = 0x00001, PA = 0x80060000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x80061000, count = 0x0001F, PA = 0x80061000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x80061000, count = 0x0001F, PA = 0x80061000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x80080000, count = 0x00001, PA = 0x80080000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x80080000, count = 0x00001, PA = 0x80080000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x80081000, count = 0x00001, PA = 0x80081000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x80081000, count = 0x00001, PA = 0x80081000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x90000000, count = 0x00010, PA = 0x90000000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x90000000, count = 0x00010, PA = 0x90000000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x90020000, count = 0x00020, PA = 0x90020000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x90020000, count = 0x00020, PA = 0x90020000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x98000000, count = 0x08000, PA = 0x98000000, pageAttr = 0x0032, flags = 0x00.
    AddPageMapEntry: LA = 0x98000000, count = 0x08000, PA = 0x98000000, pageAttr = 0x0032, flags = 0x00.

    nontrivial PME   LA = 0xDFFFE000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0012, flags = 0x01.
    AddPageMapEntry: LA = 0xDFFFE000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0012, flags = 0x01.

    nontrivial PME   LA = 0xE4000000, count = 0x00180, PA = 0x55600000, pageAttr = 0x0012, flags = 0x00.
    AddPageMapEntry: LA = 0xE4000000, count = 0x00180, PA = 0x55600000, pageAttr = 0x0012, flags = 0x00.

    nontrivial PME   LA = 0xF0000000, count = 0x10000, PA = 0xF0000000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0xF0000000, count = 0x10000, PA = 0xF0000000, pageAttr = 0x003A, flags = 0x00.

    Reinserting the MacOS area delimiters:
    AddPageMapEntry: LA = 0x60000000, count = 0x08000, PA = 0x00000000, pageAttr = 0x0A00, flags = 0x00.
    AddPageMapEntry: LA = 0x60000000, count = 0x08000, PA = 0x00000000, pageAttr = 0x0A00, flags = 0x00.

PatchMacOSAddressSpace succeeded (but was forbidden from patching the Emulator).

DebugDumpPageMap
0 000: 0000ffff 00000a00
  008: 0000ffff 00000a00
1 010: 0000ffff 00000a00
  018: 0000ffff 00000a00
2 020: 0000ffff 00000a00
  028: 0000ffff 00000a00
3 030: 0000ffff 00000a00
  038: 0000ffff 00000a00
4 040: 0000ffff 00000a00
  048: 0000ffff 00000a00
5 050: 0000ffff 00000a00
  058: 0000ffff 00000a00
6 060: 00007fff 00000a00
  068: 00007fff 00000a00
  070: 8fef0000 00003013
  078: 8ffe0000 00000011 KDP
  080: 8fff0000 00000012 EDP
  088: 0000ffff 00000a01
  090: 0000ffff 00000a01
  098: 0000ffff 00000a00
7 0a0: 0000ffff 00000a01
  0a8: 0000ffff 00000a01
  0b0: 0000ffff 00000a00
8 0b8: 0000005f 8000003a
  0c0: 00600000 8006003a
  0c8: 0061001e 8006103a
  0d0: 00800000 8008003a
  0d8: 00810000 8008103a
  0e0: 0000ffff 80000a01
  0e8: 0000ffff 00000a00
9 0f0: 0000000f 9000003a
  0f8: 0020001f 9002003a
  100: 80007fff 98000032
  108: 0000ffff 90000a01
  110: 0000ffff 00000a00
A 118: 0000ffff a0000a01
  120: 0000ffff 00000a00
B 128: 0000ffff b0000a01
  130: 0000ffff 00000a00
C 138: 0000ffff c0000a01
  140: 0000ffff 00000a00
D 148: fffe0000 00000012 IRP
  150: 0000ffff d0000a01
  158: 0000ffff 00000a00
E 160: 4000017f 55600012
  168: 0000ffff e0000a01
  170: 0000ffff 00000a00
F 178: 0000ffff f000003a
  180: 0000ffff f0000a01
  188: 0000ffff 00000a00

WedgeLogReader:
Code: [Select]
Hello from the Wedge.
      ConfigInfo (r3) @ 00003000
   ProcessorInfo (r4) @ 7fffff40
      SystemInfo (r5) @ 7ffffe00
  DiagnosticInfo (r6) @ 00000000
            RTAS (r7) = 52544153
        RTASProc (r8) @ 00000000
    HardwareInfo (r9) @ 7ffffd40

DebugDumpPageMap
0 000: 0000ffff 00000a00
  008: 0000ffff 00000a00
1 010: 0000ffff 00000a00
  018: 0000ffff 00000a00
2 020: 0000ffff 00000a00
  028: 0000ffff 00000a00
3 030: 0000ffff 00000a00
  038: 0000ffff 00000a00
4 040: 0000ffff 00000a00
  048: 0000ffff 00000a00
5 050: 0000fffd 00000a00
  058: 0000fffd 00000a00
  060: fffe0000 00000012 IRP
  068: 0000ffff 00000a00
  070: 0000ffff 00000a00
6 078: 4000017f 55600012
  080: 8fef0000 00003013
  088: 8ffe0000 00000011 KDP
  090: 8fff0000 00000012 EDP
  098: 0000ffff 00000a01
  0a0: 0000ffff 00000a01
  0a8: 0000ffff 00000a00
7 0b0: 0000ffff 00000a01
  0b8: 0000ffff 00000a01
  0c0: 0000ffff 00000a00
8 0c8: 0000005f 8000003a
  0d0: 00600000 8006003a
  0d8: 0061001e 8006103a
  0e0: 00800000 8008003a
  0e8: 00810000 8008103a
  0f0: 0000ffff 80000a01
  0f8: 0000ffff 00000a00
9 100: 0000000f 9000003a
  108: 0020001f 9002003a
  110: 80007fff 98000032
  118: 0000ffff 90000a01
  120: 0000ffff 00000a00
A 128: 0000ffff a0000a01
  130: 0000ffff 00000a00
B 138: 0000ffff b0000a01
  140: 0000ffff 00000a00
C 148: 0000ffff c0000a01
  150: 0000ffff 00000a00
D 158: 0000ffff d0000a01
  160: 0000ffff 00000a00
E 168: 0000ffff e0000a01
  170: 0000ffff 00000a00
F 178: 0000ffff f000003a
  180: 0000ffff f0000a01
  188: 0000ffff 00000a00

Rearranging the MacOS address space...

ErasePageMapTable at offset 0x3ac

PatchMacOSAddressSpace: makeMemAvail 68000000
    nontrivial PME   LA = 0x50000000, count = 0x0FFFE, PA = 0x00000000, pageAttr = 0x0A00, flags = 0x00.
    MacOS area delimiter: skipping

    nontrivial PME   LA = 0x50000000, count = 0x0FFFE, PA = 0x00000000, pageAttr = 0x0A00, flags = 0x00.
    MacOS area delimiter: skipping

    nontrivial PME   LA = 0x5FFFE000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0012, flags = 0x01.
    **IRP**
    Patching Emulator lis/ori @ 181e8
    AddPageMapEntry: LA = 0xDFFFE000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0012, flags = 0x01.

    nontrivial PME   LA = 0x64000000, count = 0x00180, PA = 0x55600000, pageAttr = 0x0012, flags = 0x00.
    **Universal/DeviceTree area**
    AddPageMapEntry: LA = 0xE4000000, count = 0x00180, PA = 0x55600000, pageAttr = 0x0012, flags = 0x00.

    nontrivial PME   LA = 0x68FEF000, count = 0x00001, PA = 0x00003000, pageAttr = 0x0013, flags = 0x00.
    AddPageMapEntry: LA = 0x68FEF000, count = 0x00001, PA = 0x00003000, pageAttr = 0x0013, flags = 0x00.

    nontrivial PME   LA = 0x68FFE000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0011, flags = 0x02.
    AddPageMapEntry: LA = 0x68FFE000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0011, flags = 0x02.

    nontrivial PME   LA = 0x68FFF000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0012, flags = 0x03.
    AddPageMapEntry: LA = 0x68FFF000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0012, flags = 0x03.

    nontrivial PME   LA = 0x80000000, count = 0x00060, PA = 0x80000000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x80000000, count = 0x00060, PA = 0x80000000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x80060000, count = 0x00001, PA = 0x80060000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x80060000, count = 0x00001, PA = 0x80060000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x80061000, count = 0x0001F, PA = 0x80061000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x80061000, count = 0x0001F, PA = 0x80061000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x80080000, count = 0x00001, PA = 0x80080000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x80080000, count = 0x00001, PA = 0x80080000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x80081000, count = 0x00001, PA = 0x80081000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x80081000, count = 0x00001, PA = 0x80081000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x90000000, count = 0x00010, PA = 0x90000000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x90000000, count = 0x00010, PA = 0x90000000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x90020000, count = 0x00020, PA = 0x90020000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x90020000, count = 0x00020, PA = 0x90020000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x98000000, count = 0x08000, PA = 0x98000000, pageAttr = 0x0032, flags = 0x00.
    AddPageMapEntry: LA = 0x98000000, count = 0x08000, PA = 0x98000000, pageAttr = 0x0032, flags = 0x00.

    nontrivial PME   LA = 0xF0000000, count = 0x10000, PA = 0xF0000000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0xF0000000, count = 0x10000, PA = 0xF0000000, pageAttr = 0x003A, flags = 0x00.

    Reinserting the MacOS area delimiters:
    AddPageMapEntry: LA = 0x60000000, count = 0x08000, PA = 0x00000000, pageAttr = 0x0A00, flags = 0x00.
    AddPageMapEntry: LA = 0x60000000, count = 0x08000, PA = 0x00000000, pageAttr = 0x0A00, flags = 0x00.

Copying modified ConfigInfo and HWInfo over the originals.

DebugDumpPageMap
0 000: 0000ffff 00000a00
  008: 0000ffff 00000a00
1 010: 0000ffff 00000a00
  018: 0000ffff 00000a00
2 020: 0000ffff 00000a00
  028: 0000ffff 00000a00
3 030: 0000ffff 00000a00
  038: 0000ffff 00000a00
4 040: 0000ffff 00000a00
  048: 0000ffff 00000a00
5 050: 0000ffff 00000a00
  058: 0000ffff 00000a00
6 060: 00007fff 00000a00
  068: 00007fff 00000a00
  070: 8fef0000 00003013
  078: 8ffe0000 00000011 KDP
  080: 8fff0000 00000012 EDP
  088: 0000ffff 00000a01
  090: 0000ffff 00000a01
  098: 0000ffff 00000a00
7 0a0: 0000ffff 00000a01
  0a8: 0000ffff 00000a01
  0b0: 0000ffff 00000a00
8 0b8: 0000005f 8000003a
  0c0: 00600000 8006003a
  0c8: 0061001e 8006103a
  0d0: 00800000 8008003a
  0d8: 00810000 8008103a
  0e0: 0000ffff 80000a01
  0e8: 0000ffff 00000a00
9 0f0: 0000000f 9000003a
  0f8: 0020001f 9002003a
  100: 80007fff 98000032
  108: 0000ffff 90000a01
  110: 0000ffff 00000a00
A 118: 0000ffff a0000a01
  120: 0000ffff 00000a00
B 128: 0000ffff b0000a01
  130: 0000ffff 00000a00
C 138: 0000ffff c0000a01
  140: 0000ffff 00000a00
D 148: fffe0000 00000012 IRP
  150: 0000ffff d0000a01
  158: 0000ffff 00000a00
E 160: 4000017f 55600012
  168: 0000ffff e0000a01
  170: 0000ffff 00000a00
F 178: 0000ffff f000003a
  180: 0000ffff f0000a01
  188: 0000ffff 00000a00


Handing over to the NanoKernel.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: MacOS Plus on June 04, 2017, 10:14:59 AM
  I guess we're calling this ROM v3?  Well, this time it's recognized properly as bootable on MDD FW800/2GB/Sonnet with no hiccups.  Pretty cool!  Here's the outputs:

NKLogReader:
Code: [Select]
NKNanoKernelInfo: logi addr 68ffedc0, struct ver 0228, 352 bytes.
NKNanoKernelInfo is within the Kernel Data Page. KDP phys addr 7f7fe000.
NanoKernel log starts after one blank line.

Hello from the builtin multitasking NanoKernel. Version: 0228
Kernel code base at 0x00f40000  Physical RAM size 0x7fffb000 bytes
Created motherboard coherence group. ID 00010001
NKCreateAddressSpaceSub - group at 0x7f7fc1c0 00010001
Created system address space. ID 00030001
 BATs ffc0007f 00c00043   6800001f 00f00043   00000000 00000000   00000000 00000000
Init ready queue 00000000 00000000 0000a8eb
Init ready queue 00000001 00000000 00054758
Init ready queue 00000002 00000000 002a3ac0
Init ready queue 00000003 00000000 0151d600
System context at 0x7f7ff100  Vector save area at 0x7f7fb8e0  SDR1 0x7f80003f
Adding blue task 00050001 to the ready queue
Starting timeslicing
Adding idle task 00070001 to the ready queue
NKCreateAddressSpaceSub - group at 0x7f7fc1c0 00010001
Priming the system free list with 272 pages.
VMMaxVirtualPages: 00068000 VMLogicalPages: 00000000
Interrupt handler kind: 06
Physical RAM greater than the initial logical area.
 Moving 95622 pages into the system free page list.
Converting PMDTs to areas
 CreateArea [ 00000000 67ffffff ] ID 000a0001 placed ... created
 CreateArea [ 68fef000 68feffff ] ID 000b0001 placed ... created
 CreateArea [ 68ff5000 68ffefff ] ID 000c0001 placed ... created
 CreateArea [ 68fff000 68ffffff ] ID 000d0001 placed ... created
 CreateArea [ 80000000 8005ffff ] ID 000e0001 placed ... created
 CreateArea [ 80060000 80060fff ] ID 000f0001 placed ... created
 CreateArea [ 80061000 8007ffff ] ID 00100001 placed ... created
 CreateArea [ 80081000 80081fff ] ID 00110001 placed ... created
 CreateArea [ 80082000 80082fff ] ID 00120001 placed ... created
 CreateArea [ 81000000 81ffffff ] ID 00130001 placed ... created
 CreateArea [ 90000000 9000ffff ] ID 00140001 placed ... created
 CreateArea [ 90020000 9003ffff ] ID 00150001 placed ... created
 CreateArea [ 98000000 9fffffff ] ID 00160001 placed ... created
 CreateArea [ dfffe000 dfffefff ] ID 00170001 placed ... created
 CreateArea [ e4000000 e417ffff ] ID 00180001 placed ... created
 CreateArea [ f0000000 ffffffff ] ID 00190001 placed ... created
 CreateArea [ 68f16000 68f16fff ] ID 001a0001 placed ... created
 CreateArea [ deadb000 deadbfff ] ID 001b0001 placed ... created
Reset system - Into the 68K fire: 0000d032 6806e8c0
ResetSystem trap entered
Kernel code base at 0x00f40000  Physical RAM size 0x7fffb000 bytes
Created motherboard coherence group. ID 00010001
NKCreateAddressSpaceSub - group at 0x7f7fc1c0 00010001
Created system address space. ID 00030001
 BATs ffc0007f 00c00043   6800001f 00f00043   00000000 00000000   00000000 00000000
Init ready queue 00000000 00000000 0000a8eb
Init ready queue 00000001 00000000 00054758
Init ready queue 00000002 00000000 002a3ac0
Init ready queue 00000003 00000000 0151d600
System context at 0x7f7ff100  Vector save area at 0x7f7fb8e0  SDR1 0x7f80003f
Adding blue task 00050001 to the ready queue
Starting timeslicing
Adding idle task 00070001 to the ready queue
NKCreateAddressSpaceSub - group at 0x7f7fc1c0 00010001
Priming the system free list with 272 pages.
VMMaxVirtualPages: 00068000 VMLogicalPages: 00068000
Interrupt handler kind: 06
Physical RAM greater than the initial logical area.
 Moving 95622 pages into the system free page list.
Converting PMDTs to areas
 CreateArea [ 00000000 67ffffff ] ID 000a0001 placed ... created
 CreateArea [ 68fef000 68feffff ] ID 000b0001 placed ... created
 CreateArea [ 68ff5000 68ffefff ] ID 000c0001 placed ... created
 CreateArea [ 68fff000 68ffffff ] ID 000d0001 placed ... created
 CreateArea [ 80000000 8005ffff ] ID 000e0001 placed ... created
 CreateArea [ 80060000 80060fff ] ID 000f0001 placed ... created
 CreateArea [ 80061000 8007ffff ] ID 00100001 placed ... created
 CreateArea [ 80081000 80081fff ] ID 00110001 placed ... created
 CreateArea [ 80082000 80082fff ] ID 00120001 placed ... created
 CreateArea [ 81000000 81ffffff ] ID 00130001 placed ... created
 CreateArea [ 90000000 9000ffff ] ID 00140001 placed ... created
 CreateArea [ 90020000 9003ffff ] ID 00150001 placed ... created
 CreateArea [ 98000000 9fffffff ] ID 00160001 placed ... created
 CreateArea [ dfffe000 dfffefff ] ID 00170001 placed ... created
 CreateArea [ e4000000 e417ffff ] ID 00180001 placed ... created
 CreateArea [ f0000000 ffffffff ] ID 00190001 placed ... created
 CreateArea [ 68f16000 68f16fff ] ID 001a0001 placed ... created
 CreateArea [ deadb000 deadbfff ] ID 001b0001 placed ... created
Reset system - Into the 68K fire: 0002d032 6806c9e8
 VMAllocateMemory - creating area at 0x69000000 00080000
 CreateArea [ 69000000 6907ffff ] ID 001c0001 placed ... created
Extend free pool: phys 0x7ff2d000  virt 0x00000000  count: 1
Extend free pool: phys 0x7ff2c000  virt 0x00000000  count: 2
Extend free pool: phys 0x7ff2b000  virt 0x00000000  count: 3
Extend free pool: phys 0x7ff2a000  virt 0x00000000  count: 4
Extend free pool: phys 0x7ff29000  virt 0x00000000  count: 5
Extend free pool: phys 0x7ff28000  virt 0x00000000  count: 6
Extend free pool: phys 0x7ff27000  virt 0x00000000  count: 7
Extend free pool: phys 0x7ff26000  virt 0x00000000  count: 8
Extend free pool: phys 0x7ff25000  virt 0x00000000  count: 9
Extend free pool: phys 0x7ff24000  virt 0x00000000  count: 10
TB drift adjusted to 40064738  ppb ( 13041 / 325462 )
Skeleton key inserted at00021032 010843d0
Extend free pool: phys 0x7ff23000  virt 0x00000000  count: 11
Extend free pool: phys 0x7ff22000  virt 0x00000000  count: 12

WedgeDryRun:
Code: [Select]
Hello from the (dry-run) Wedge.
      ConfigInfo @ 68fef000
    HardwareInfo @ dfffef00

DebugDumpPageMap
0 000: 0000ffff 00000a00
  008: 0000ffff 00000a00
1 010: 0000ffff 00000a00
  018: 0000ffff 00000a00
2 020: 0000ffff 00000a00
  028: 0000ffff 00000a00
3 030: 0000ffff 00000a00
  038: 0000ffff 00000a00
4 040: 0000ffff 00000a00
  048: 0000ffff 00000a00
5 050: 0000ffff 00000a00
  058: 0000ffff 00000a00
6 060: 00007fff 00000a00
  068: 00007fff 00000a00
  070: 8fef0000 00003013
  078: 8ffe0000 00000011 KDP
  080: 8fff0000 00000012 EDP
  088: 0000ffff 00000a01
  090: 0000ffff 00000a01
  098: 0000ffff 00000a00
7 0a0: 0000ffff 00000a01
  0a8: 0000ffff 00000a01
  0b0: 0000ffff 00000a00
8 0b8: 0000005f 8000003a
  0c0: 00600000 8006003a
  0c8: 0061001e 8006103a
  0d0: 00810000 8008103a
  0d8: 00820000 8008203a
  0e0: 10000fff 8100003a
  0e8: 0000ffff 80000a01
  0f0: 0000ffff 00000a00
9 0f8: 0000000f 9000003a
  100: 0020001f 9002003a
  108: 80007fff 98000032
  110: 0000ffff 90000a01
  118: 0000ffff 00000a00
A 120: 0000ffff a0000a01
  128: 0000ffff 00000a00
B 130: 0000ffff b0000a01
  138: 0000ffff 00000a00
C 140: 0000ffff c0000a01
  148: 0000ffff 00000a00
D 150: fffe0000 00000012 IRP
  158: 0000ffff d0000a01
  160: 0000ffff 00000a00
E 168: 4000017f 55600012
  170: 0000ffff e0000a01
  178: 0000ffff 00000a00
F 180: 0000ffff f000003a
  188: 0000ffff f0000a01
  190: 0000ffff 00000a00

Copying the system ConfigInfo and HardwareInfo structs.

ErasePageMapTable at offset 0x3ac

PatchMacOSAddressSpace: makeMemAvail 68000000
    nontrivial PME   LA = 0x60000000, count = 0x08000, PA = 0x00000000, pageAttr = 0x0A00, flags = 0x00.
    MacOS area delimiter: skipping

    nontrivial PME   LA = 0x60000000, count = 0x08000, PA = 0x00000000, pageAttr = 0x0A00, flags = 0x00.
    MacOS area delimiter: skipping

    nontrivial PME   LA = 0x68FEF000, count = 0x00001, PA = 0x00003000, pageAttr = 0x0013, flags = 0x00.
    AddPageMapEntry: LA = 0x68FEF000, count = 0x00001, PA = 0x00003000, pageAttr = 0x0013, flags = 0x00.

    nontrivial PME   LA = 0x68FFE000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0011, flags = 0x02.
    AddPageMapEntry: LA = 0x68FFE000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0011, flags = 0x02.

    nontrivial PME   LA = 0x68FFF000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0012, flags = 0x03.
    AddPageMapEntry: LA = 0x68FFF000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0012, flags = 0x03.

    nontrivial PME   LA = 0x80000000, count = 0x00060, PA = 0x80000000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x80000000, count = 0x00060, PA = 0x80000000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x80060000, count = 0x00001, PA = 0x80060000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x80060000, count = 0x00001, PA = 0x80060000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x80061000, count = 0x0001F, PA = 0x80061000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x80061000, count = 0x0001F, PA = 0x80061000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x80081000, count = 0x00001, PA = 0x80081000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x80081000, count = 0x00001, PA = 0x80081000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x80082000, count = 0x00001, PA = 0x80082000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x80082000, count = 0x00001, PA = 0x80082000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x81000000, count = 0x01000, PA = 0x81000000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x81000000, count = 0x01000, PA = 0x81000000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x90000000, count = 0x00010, PA = 0x90000000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x90000000, count = 0x00010, PA = 0x90000000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x90020000, count = 0x00020, PA = 0x90020000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x90020000, count = 0x00020, PA = 0x90020000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x98000000, count = 0x08000, PA = 0x98000000, pageAttr = 0x0032, flags = 0x00.
    AddPageMapEntry: LA = 0x98000000, count = 0x08000, PA = 0x98000000, pageAttr = 0x0032, flags = 0x00.

    nontrivial PME   LA = 0xDFFFE000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0012, flags = 0x01.
    AddPageMapEntry: LA = 0xDFFFE000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0012, flags = 0x01.

    nontrivial PME   LA = 0xE4000000, count = 0x00180, PA = 0x55600000, pageAttr = 0x0012, flags = 0x00.
    AddPageMapEntry: LA = 0xE4000000, count = 0x00180, PA = 0x55600000, pageAttr = 0x0012, flags = 0x00.

    nontrivial PME   LA = 0xF0000000, count = 0x10000, PA = 0xF0000000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0xF0000000, count = 0x10000, PA = 0xF0000000, pageAttr = 0x003A, flags = 0x00.

    Reinserting the MacOS area delimiters:
    AddPageMapEntry: LA = 0x60000000, count = 0x08000, PA = 0x00000000, pageAttr = 0x0A00, flags = 0x00.
    AddPageMapEntry: LA = 0x60000000, count = 0x08000, PA = 0x00000000, pageAttr = 0x0A00, flags = 0x00.

PatchMacOSAddressSpace succeeded (but was forbidden from patching the Emulator).

DebugDumpPageMap
0 000: 0000ffff 00000a00
  008: 0000ffff 00000a00
1 010: 0000ffff 00000a00
  018: 0000ffff 00000a00
2 020: 0000ffff 00000a00
  028: 0000ffff 00000a00
3 030: 0000ffff 00000a00
  038: 0000ffff 00000a00
4 040: 0000ffff 00000a00
  048: 0000ffff 00000a00
5 050: 0000ffff 00000a00
  058: 0000ffff 00000a00
6 060: 00007fff 00000a00
  068: 00007fff 00000a00
  070: 8fef0000 00003013
  078: 8ffe0000 00000011 KDP
  080: 8fff0000 00000012 EDP
  088: 0000ffff 00000a01
  090: 0000ffff 00000a01
  098: 0000ffff 00000a00
7 0a0: 0000ffff 00000a01
  0a8: 0000ffff 00000a01
  0b0: 0000ffff 00000a00
8 0b8: 0000005f 8000003a
  0c0: 00600000 8006003a
  0c8: 0061001e 8006103a
  0d0: 00810000 8008103a
  0d8: 00820000 8008203a
  0e0: 10000fff 8100003a
  0e8: 0000ffff 80000a01
  0f0: 0000ffff 00000a00
9 0f8: 0000000f 9000003a
  100: 0020001f 9002003a
  108: 80007fff 98000032
  110: 0000ffff 90000a01
  118: 0000ffff 00000a00
A 120: 0000ffff a0000a01
  128: 0000ffff 00000a00
B 130: 0000ffff b0000a01
  138: 0000ffff 00000a00
C 140: 0000ffff c0000a01
  148: 0000ffff 00000a00
D 150: fffe0000 00000012 IRP
  158: 0000ffff d0000a01
  160: 0000ffff 00000a00
E 168: 4000017f 55600012
  170: 0000ffff e0000a01
  178: 0000ffff 00000a00
F 180: 0000ffff f000003a
  188: 0000ffff f0000a01
  190: 0000ffff 00000a00

WedgeLogReader:
Code: [Select]
Hello from the Wedge.
      ConfigInfo (r3) @ 00003000
   ProcessorInfo (r4) @ 7fffff40
      SystemInfo (r5) @ 7ffffe00
  DiagnosticInfo (r6) @ 00000000
            RTAS (r7) = 52544153
        RTASProc (r8) @ 00000000
    HardwareInfo (r9) @ 7ffffd40

DebugDumpPageMap
0 000: 0000ffff 00000a00
  008: 0000ffff 00000a00
1 010: 0000ffff 00000a00
  018: 0000ffff 00000a00
2 020: 0000ffff 00000a00
  028: 0000ffff 00000a00
3 030: 0000ffff 00000a00
  038: 0000ffff 00000a00
4 040: 0000ffff 00000a00
  048: 0000ffff 00000a00
5 050: 0000fffd 00000a00
  058: 0000fffd 00000a00
  060: fffe0000 00000012 IRP
  068: 0000ffff 00000a00
  070: 0000ffff 00000a00
6 078: 4000017f 55600012
  080: 8fef0000 00003013
  088: 8ffe0000 00000011 KDP
  090: 8fff0000 00000012 EDP
  098: 0000ffff 00000a01
  0a0: 0000ffff 00000a01
  0a8: 0000ffff 00000a00
7 0b0: 0000ffff 00000a01
  0b8: 0000ffff 00000a01
  0c0: 0000ffff 00000a00
8 0c8: 0000005f 8000003a
  0d0: 00600000 8006003a
  0d8: 0061001e 8006103a
  0e0: 00810000 8008103a
  0e8: 00820000 8008203a
  0f0: 10000fff 8100003a
  0f8: 0000ffff 80000a01
  100: 0000ffff 00000a00
9 108: 0000000f 9000003a
  110: 0020001f 9002003a
  118: 80007fff 98000032
  120: 0000ffff 90000a01
  128: 0000ffff 00000a00
A 130: 0000ffff a0000a01
  138: 0000ffff 00000a00
B 140: 0000ffff b0000a01
  148: 0000ffff 00000a00
C 150: 0000ffff c0000a01
  158: 0000ffff 00000a00
D 160: 0000ffff d0000a01
  168: 0000ffff 00000a00
E 170: 0000ffff e0000a01
  178: 0000ffff 00000a00
F 180: 0000ffff f000003a
  188: 0000ffff f0000a01
  190: 0000ffff 00000a00

Rearranging the MacOS address space...

ErasePageMapTable at offset 0x3ac

PatchMacOSAddressSpace: makeMemAvail 68000000
    nontrivial PME   LA = 0x50000000, count = 0x0FFFE, PA = 0x00000000, pageAttr = 0x0A00, flags = 0x00.
    MacOS area delimiter: skipping

    nontrivial PME   LA = 0x50000000, count = 0x0FFFE, PA = 0x00000000, pageAttr = 0x0A00, flags = 0x00.
    MacOS area delimiter: skipping

    nontrivial PME   LA = 0x5FFFE000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0012, flags = 0x01.
    **IRP**
    Patching Emulator lis/ori @ 181e8
    AddPageMapEntry: LA = 0xDFFFE000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0012, flags = 0x01.

    nontrivial PME   LA = 0x64000000, count = 0x00180, PA = 0x55600000, pageAttr = 0x0012, flags = 0x00.
    **Universal/DeviceTree area**
    AddPageMapEntry: LA = 0xE4000000, count = 0x00180, PA = 0x55600000, pageAttr = 0x0012, flags = 0x00.

    nontrivial PME   LA = 0x68FEF000, count = 0x00001, PA = 0x00003000, pageAttr = 0x0013, flags = 0x00.
    AddPageMapEntry: LA = 0x68FEF000, count = 0x00001, PA = 0x00003000, pageAttr = 0x0013, flags = 0x00.

    nontrivial PME   LA = 0x68FFE000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0011, flags = 0x02.
    AddPageMapEntry: LA = 0x68FFE000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0011, flags = 0x02.

    nontrivial PME   LA = 0x68FFF000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0012, flags = 0x03.
    AddPageMapEntry: LA = 0x68FFF000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0012, flags = 0x03.

    nontrivial PME   LA = 0x80000000, count = 0x00060, PA = 0x80000000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x80000000, count = 0x00060, PA = 0x80000000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x80060000, count = 0x00001, PA = 0x80060000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x80060000, count = 0x00001, PA = 0x80060000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x80061000, count = 0x0001F, PA = 0x80061000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x80061000, count = 0x0001F, PA = 0x80061000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x80081000, count = 0x00001, PA = 0x80081000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x80081000, count = 0x00001, PA = 0x80081000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x80082000, count = 0x00001, PA = 0x80082000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x80082000, count = 0x00001, PA = 0x80082000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x81000000, count = 0x01000, PA = 0x81000000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x81000000, count = 0x01000, PA = 0x81000000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x90000000, count = 0x00010, PA = 0x90000000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x90000000, count = 0x00010, PA = 0x90000000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x90020000, count = 0x00020, PA = 0x90020000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x90020000, count = 0x00020, PA = 0x90020000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x98000000, count = 0x08000, PA = 0x98000000, pageAttr = 0x0032, flags = 0x00.
    AddPageMapEntry: LA = 0x98000000, count = 0x08000, PA = 0x98000000, pageAttr = 0x0032, flags = 0x00.

    nontrivial PME   LA = 0xF0000000, count = 0x10000, PA = 0xF0000000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0xF0000000, count = 0x10000, PA = 0xF0000000, pageAttr = 0x003A, flags = 0x00.

    Reinserting the MacOS area delimiters:
    AddPageMapEntry: LA = 0x60000000, count = 0x08000, PA = 0x00000000, pageAttr = 0x0A00, flags = 0x00.
    AddPageMapEntry: LA = 0x60000000, count = 0x08000, PA = 0x00000000, pageAttr = 0x0A00, flags = 0x00.

Copying modified ConfigInfo and HWInfo over the originals.

DebugDumpPageMap
0 000: 0000ffff 00000a00
  008: 0000ffff 00000a00
1 010: 0000ffff 00000a00
  018: 0000ffff 00000a00
2 020: 0000ffff 00000a00
  028: 0000ffff 00000a00
3 030: 0000ffff 00000a00
  038: 0000ffff 00000a00
4 040: 0000ffff 00000a00
  048: 0000ffff 00000a00
5 050: 0000ffff 00000a00
  058: 0000ffff 00000a00
6 060: 00007fff 00000a00
  068: 00007fff 00000a00
  070: 8fef0000 00003013
  078: 8ffe0000 00000011 KDP
  080: 8fff0000 00000012 EDP
  088: 0000ffff 00000a01
  090: 0000ffff 00000a01
  098: 0000ffff 00000a00
7 0a0: 0000ffff 00000a01
  0a8: 0000ffff 00000a01
  0b0: 0000ffff 00000a00
8 0b8: 0000005f 8000003a
  0c0: 00600000 8006003a
  0c8: 0061001e 8006103a
  0d0: 00810000 8008103a
  0d8: 00820000 8008203a
  0e0: 10000fff 8100003a
  0e8: 0000ffff 80000a01
  0f0: 0000ffff 00000a00
9 0f8: 0000000f 9000003a
  100: 0020001f 9002003a
  108: 80007fff 98000032
  110: 0000ffff 90000a01
  118: 0000ffff 00000a00
A 120: 0000ffff a0000a01
  128: 0000ffff 00000a00
B 130: 0000ffff b0000a01
  138: 0000ffff 00000a00
C 140: 0000ffff c0000a01
  148: 0000ffff 00000a00
D 150: fffe0000 00000012 IRP
  158: 0000ffff d0000a01
  160: 0000ffff 00000a00
E 168: 4000017f 55600012
  170: 0000ffff e0000a01
  178: 0000ffff 00000a00
F 180: 0000ffff f000003a
  188: 0000ffff f0000a01
  190: 0000ffff 00000a00


Handing over to the NanoKernel.

Original "About This Computer":
(http://i1262.photobucket.com/albums/ii607/SpawnedFromTheEther/MDD%20FW800%20Before.jpg)

ROM v3 "About This Computer":
(http://i1262.photobucket.com/albums/ii607/SpawnedFromTheEther/MDD%20FW800%20After.jpg)

Next I'll move this over to the 9serve and try again!
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: MacOS Plus on June 04, 2017, 12:01:12 PM
Logs from 9serve Rev.1/2GB/2x1.0GHz:

NKLogReader:
Code: [Select]
NKNanoKernelInfo: logi addr 68ffedc0, struct ver 0228, 352 bytes.
NKNanoKernelInfo is within the Kernel Data Page. KDP phys addr 7f7fe000.
NanoKernel log starts after one blank line.

Hello from the builtin multitasking NanoKernel. Version: 0228
Kernel code base at 0x00f40000  Physical RAM size 0x7fffb000 bytes
Created motherboard coherence group. ID 00010001
NKCreateAddressSpaceSub - group at 0x7f7fc1c0 00010001
Created system address space. ID 00030001
 BATs ffc0007f 00c00043   6800001f 00f00043   00000000 00000000   00000000 00000000
Init ready queue 00000000 00000000 00008652
Init ready queue 00000001 00000000 00043290
Init ready queue 00000002 00000000 00219480
Init ready queue 00000003 00000000 010ca400
System context at 0x7f7ff100  Vector save area at 0x7f7fb8e0  SDR1 0x7f80003f
Adding blue task 00050001 to the ready queue
Starting timeslicing
Adding idle task 00070001 to the ready queue
NKCreateAddressSpaceSub - group at 0x7f7fc1c0 00010001
Priming the system free list with 272 pages.
VMMaxVirtualPages: 00068000 VMLogicalPages: 00000000
Interrupt handler kind: 06
Physical RAM greater than the initial logical area.
 Moving 95622 pages into the system free page list.
Converting PMDTs to areas
 CreateArea [ 00000000 67ffffff ] ID 000a0001 placed ... created
 CreateArea [ 68fef000 68feffff ] ID 000b0001 placed ... created
 CreateArea [ 68ff5000 68ffefff ] ID 000c0001 placed ... created
 CreateArea [ 68fff000 68ffffff ] ID 000d0001 placed ... created
 CreateArea [ 80000000 8005ffff ] ID 000e0001 placed ... created
 CreateArea [ 80060000 80060fff ] ID 000f0001 placed ... created
 CreateArea [ 80061000 8007ffff ] ID 00100001 placed ... created
 CreateArea [ 80080000 80080fff ] ID 00110001 placed ... created
 CreateArea [ 80081000 80081fff ] ID 00120001 placed ... created
 CreateArea [ 90000000 9000ffff ] ID 00130001 placed ... created
 CreateArea [ 90020000 9003ffff ] ID 00140001 placed ... created
 CreateArea [ a0000000 afffffff ] ID 00150001 placed ... created
 CreateArea [ dfffe000 dfffefff ] ID 00160001 placed ... created
 CreateArea [ e4000000 e417ffff ] ID 00170001 placed ... created
 CreateArea [ f0000000 f4ffffff ] ID 00180001 placed ... created
 CreateArea [ f5000000 f5000fff ] ID 00190001 placed ... created
 CreateArea [ f5001000 f50fffff ] ID 001a0001 placed ... created
 CreateArea [ f5100000 f51fffff ] ID 001b0001 placed ... created
 CreateArea [ f5200000 f53fffff ] ID 001c0001 placed ... created
 CreateArea [ f5400000 ffffffff ] ID 001d0001 placed ... created
 CreateArea [ 68f16000 68f16fff ] ID 001e0001 placed ... created
 CreateArea [ deadb000 deadbfff ] ID 001f0001 placed ... created
Reset system - Into the 68K fire: 0000d032 6806e8c0
ResetSystem trap entered
Kernel code base at 0x00f40000  Physical RAM size 0x7fffb000 bytes
Created motherboard coherence group. ID 00010001
NKCreateAddressSpaceSub - group at 0x7f7fc1c0 00010001
Created system address space. ID 00030001
 BATs ffc0007f 00c00043   6800001f 00f00043   00000000 00000000   00000000 00000000
Init ready queue 00000000 00000000 00008652
Init ready queue 00000001 00000000 00043290
Init ready queue 00000002 00000000 00219480
Init ready queue 00000003 00000000 010ca400
System context at 0x7f7ff100  Vector save area at 0x7f7fb8e0  SDR1 0x7f80003f
Adding blue task 00050001 to the ready queue
Starting timeslicing
Adding idle task 00070001 to the ready queue
NKCreateAddressSpaceSub - group at 0x7f7fc1c0 00010001
Priming the system free list with 272 pages.
VMMaxVirtualPages: 00068000 VMLogicalPages: 00068000
Interrupt handler kind: 06
Physical RAM greater than the initial logical area.
 Moving 95622 pages into the system free page list.
Converting PMDTs to areas
 CreateArea [ 00000000 67ffffff ] ID 000a0001 placed ... created
 CreateArea [ 68fef000 68feffff ] ID 000b0001 placed ... created
 CreateArea [ 68ff5000 68ffefff ] ID 000c0001 placed ... created
 CreateArea [ 68fff000 68ffffff ] ID 000d0001 placed ... created
 CreateArea [ 80000000 8005ffff ] ID 000e0001 placed ... created
 CreateArea [ 80060000 80060fff ] ID 000f0001 placed ... created
 CreateArea [ 80061000 8007ffff ] ID 00100001 placed ... created
 CreateArea [ 80080000 80080fff ] ID 00110001 placed ... created
 CreateArea [ 80081000 80081fff ] ID 00120001 placed ... created
 CreateArea [ 90000000 9000ffff ] ID 00130001 placed ... created
 CreateArea [ 90020000 9003ffff ] ID 00140001 placed ... created
 CreateArea [ a0000000 afffffff ] ID 00150001 placed ... created
 CreateArea [ dfffe000 dfffefff ] ID 00160001 placed ... created
 CreateArea [ e4000000 e417ffff ] ID 00170001 placed ... created
 CreateArea [ f0000000 f4ffffff ] ID 00180001 placed ... created
 CreateArea [ f5000000 f5000fff ] ID 00190001 placed ... created
 CreateArea [ f5001000 f50fffff ] ID 001a0001 placed ... created
 CreateArea [ f5100000 f51fffff ] ID 001b0001 placed ... created
 CreateArea [ f5200000 f53fffff ] ID 001c0001 placed ... created
 CreateArea [ f5400000 ffffffff ] ID 001d0001 placed ... created
 CreateArea [ 68f16000 68f16fff ] ID 001e0001 placed ... created
 CreateArea [ deadb000 deadbfff ] ID 001f0001 placed ... created
Reset system - Into the 68K fire: 0002d032 6806c9e8
 VMAllocateMemory - creating area at 0x69000000 00080000
 CreateArea [ 69000000 6907ffff ] ID 00200001 placed ... created
Extend free pool: phys 0x7ff2d000  virt 0x00000000  count: 1
VMMakePageCacheable for I/O 00090008
VMMakePageCacheable for I/O 00090009
VMMakePageCacheable for I/O 0009000a
VMMakePageCacheable for I/O 0009000b
VMMakePageCacheable for I/O 0009000c
VMMakePageCacheable for I/O 0009000d
VMMakePageCacheable for I/O 0009000e
VMMakePageCacheable for I/O 0009000f
Extend free pool: phys 0x7ff2c000  virt 0x00000000  count: 2
Extend free pool: phys 0x7ff2b000  virt 0x00000000  count: 3
Extend free pool: phys 0x7ff2a000  virt 0x00000000  count: 4
Extend free pool: phys 0x7ff29000  virt 0x00000000  count: 5
Extend free pool: phys 0x7ff28000  virt 0x00000000  count: 6
Extend free pool: phys 0x7ff27000  virt 0x00000000  count: 7
Extend free pool: phys 0x7ff26000  virt 0x00000000  count: 8
Extend free pool: phys 0x7ff25000  virt 0x00000000  count: 9
Extend free pool: phys 0x7ff24000  virt 0x00000000  count: 10
TB drift adjusted to 33175978  ppb ( 8612 / 259605 )
Extend free pool: phys 0x7ff23000  virt 0x00000000  count: 11
Extend free pool: phys 0x7ff22000  virt 0x00000000  count: 12

WedgeDryRun:
Code: [Select]
Hello from the (dry-run) Wedge.
      ConfigInfo @ 68fef000
    HardwareInfo @ dfffef00

DebugDumpPageMap
0 000: 0000ffff 00000a00
  008: 0000ffff 00000a00
1 010: 0000ffff 00000a00
  018: 0000ffff 00000a00
2 020: 0000ffff 00000a00
  028: 0000ffff 00000a00
3 030: 0000ffff 00000a00
  038: 0000ffff 00000a00
4 040: 0000ffff 00000a00
  048: 0000ffff 00000a00
5 050: 0000ffff 00000a00
  058: 0000ffff 00000a00
6 060: 00007fff 00000a00
  068: 00007fff 00000a00
  070: 8fef0000 00003013
  078: 8ffe0000 00000011 KDP
  080: 8fff0000 00000012 EDP
  088: 0000ffff 00000a01
  090: 0000ffff 00000a01
  098: 0000ffff 00000a00
7 0a0: 0000ffff 00000a01
  0a8: 0000ffff 00000a01
  0b0: 0000ffff 00000a00
8 0b8: 0000005f 8000003a
  0c0: 00600000 8006003a
  0c8: 0061001e 8006103a
  0d0: 00800000 8008003a
  0d8: 00810000 8008103a
  0e0: 0000ffff 80000a01
  0e8: 0000ffff 00000a00
9 0f0: 0000000f 9000003a
  0f8: 0020001f 9002003a
  100: 0000ffff 90000a01
  108: 0000ffff 00000a00
A 110: 0000ffff a0000032
  118: 0000ffff a0000a01
  120: 0000ffff 00000a00
B 128: 0000ffff b0000a01
  130: 0000ffff 00000a00
C 138: 0000ffff c0000a01
  140: 0000ffff 00000a00
D 148: fffe0000 00000012 IRP
  150: 0000ffff d0000a01
  158: 0000ffff 00000a00
E 160: 4000017f 55600012
  168: 0000ffff e0000a01
  170: 0000ffff 00000a00
F 178: 00004fff f000003a
  180: 50000000 f500003a
  188: 500100fe f500103a
  190: 510000ff f510003a
  198: 520001ff f520003a
  1a0: 5400abff f540003a
  1a8: 0000ffff f0000a01
  1b0: 0000ffff 00000a00

Copying the system ConfigInfo and HardwareInfo structs.

ErasePageMapTable at offset 0x3ac

PatchMacOSAddressSpace: makeMemAvail 68000000
    nontrivial PME   LA = 0x60000000, count = 0x08000, PA = 0x00000000, pageAttr = 0x0A00, flags = 0x00.
    MacOS area delimiter: skipping

    nontrivial PME   LA = 0x60000000, count = 0x08000, PA = 0x00000000, pageAttr = 0x0A00, flags = 0x00.
    MacOS area delimiter: skipping

    nontrivial PME   LA = 0x68FEF000, count = 0x00001, PA = 0x00003000, pageAttr = 0x0013, flags = 0x00.
    AddPageMapEntry: LA = 0x68FEF000, count = 0x00001, PA = 0x00003000, pageAttr = 0x0013, flags = 0x00.

    nontrivial PME   LA = 0x68FFE000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0011, flags = 0x02.
    AddPageMapEntry: LA = 0x68FFE000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0011, flags = 0x02.

    nontrivial PME   LA = 0x68FFF000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0012, flags = 0x03.
    AddPageMapEntry: LA = 0x68FFF000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0012, flags = 0x03.

    nontrivial PME   LA = 0x80000000, count = 0x00060, PA = 0x80000000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x80000000, count = 0x00060, PA = 0x80000000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x80060000, count = 0x00001, PA = 0x80060000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x80060000, count = 0x00001, PA = 0x80060000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x80061000, count = 0x0001F, PA = 0x80061000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x80061000, count = 0x0001F, PA = 0x80061000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x80080000, count = 0x00001, PA = 0x80080000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x80080000, count = 0x00001, PA = 0x80080000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x80081000, count = 0x00001, PA = 0x80081000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x80081000, count = 0x00001, PA = 0x80081000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x90000000, count = 0x00010, PA = 0x90000000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x90000000, count = 0x00010, PA = 0x90000000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x90020000, count = 0x00020, PA = 0x90020000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x90020000, count = 0x00020, PA = 0x90020000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0xA0000000, count = 0x10000, PA = 0xA0000000, pageAttr = 0x0032, flags = 0x00.
    AddPageMapEntry: LA = 0xA0000000, count = 0x10000, PA = 0xA0000000, pageAttr = 0x0032, flags = 0x00.

    nontrivial PME   LA = 0xDFFFE000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0012, flags = 0x01.
    AddPageMapEntry: LA = 0xDFFFE000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0012, flags = 0x01.

    nontrivial PME   LA = 0xE4000000, count = 0x00180, PA = 0x55600000, pageAttr = 0x0012, flags = 0x00.
    AddPageMapEntry: LA = 0xE4000000, count = 0x00180, PA = 0x55600000, pageAttr = 0x0012, flags = 0x00.

    nontrivial PME   LA = 0xF0000000, count = 0x05000, PA = 0xF0000000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0xF0000000, count = 0x05000, PA = 0xF0000000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0xF5000000, count = 0x00001, PA = 0xF5000000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0xF5000000, count = 0x00001, PA = 0xF5000000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0xF5001000, count = 0x000FF, PA = 0xF5001000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0xF5001000, count = 0x000FF, PA = 0xF5001000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0xF5100000, count = 0x00100, PA = 0xF5100000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0xF5100000, count = 0x00100, PA = 0xF5100000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0xF5200000, count = 0x00200, PA = 0xF5200000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0xF5200000, count = 0x00200, PA = 0xF5200000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0xF5400000, count = 0x0AC00, PA = 0xF5400000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0xF5400000, count = 0x0AC00, PA = 0xF5400000, pageAttr = 0x003A, flags = 0x00.

    Reinserting the MacOS area delimiters:
    AddPageMapEntry: LA = 0x60000000, count = 0x08000, PA = 0x00000000, pageAttr = 0x0A00, flags = 0x00.
    AddPageMapEntry: LA = 0x60000000, count = 0x08000, PA = 0x00000000, pageAttr = 0x0A00, flags = 0x00.

PatchMacOSAddressSpace succeeded (but was forbidden from patching the Emulator).

DebugDumpPageMap
0 000: 0000ffff 00000a00
  008: 0000ffff 00000a00
1 010: 0000ffff 00000a00
  018: 0000ffff 00000a00
2 020: 0000ffff 00000a00
  028: 0000ffff 00000a00
3 030: 0000ffff 00000a00
  038: 0000ffff 00000a00
4 040: 0000ffff 00000a00
  048: 0000ffff 00000a00
5 050: 0000ffff 00000a00
  058: 0000ffff 00000a00
6 060: 00007fff 00000a00
  068: 00007fff 00000a00
  070: 8fef0000 00003013
  078: 8ffe0000 00000011 KDP
  080: 8fff0000 00000012 EDP
  088: 0000ffff 00000a01
  090: 0000ffff 00000a01
  098: 0000ffff 00000a00
7 0a0: 0000ffff 00000a01
  0a8: 0000ffff 00000a01
  0b0: 0000ffff 00000a00
8 0b8: 0000005f 8000003a
  0c0: 00600000 8006003a
  0c8: 0061001e 8006103a
  0d0: 00800000 8008003a
  0d8: 00810000 8008103a
  0e0: 0000ffff 80000a01
  0e8: 0000ffff 00000a00
9 0f0: 0000000f 9000003a
  0f8: 0020001f 9002003a
  100: 0000ffff 90000a01
  108: 0000ffff 00000a00
A 110: 0000ffff a0000032
  118: 0000ffff a0000a01
  120: 0000ffff 00000a00
B 128: 0000ffff b0000a01
  130: 0000ffff 00000a00
C 138: 0000ffff c0000a01
  140: 0000ffff 00000a00
D 148: fffe0000 00000012 IRP
  150: 0000ffff d0000a01
  158: 0000ffff 00000a00
E 160: 4000017f 55600012
  168: 0000ffff e0000a01
  170: 0000ffff 00000a00
F 178: 00004fff f000003a
  180: 50000000 f500003a
  188: 500100fe f500103a
  190: 510000ff f510003a
  198: 520001ff f520003a
  1a0: 5400abff f540003a
  1a8: 0000ffff f0000a01
  1b0: 0000ffff 00000a00

WedgeLogReader:
Code: [Select]
Hello from the Wedge.
      ConfigInfo (r3) @ 00003000
   ProcessorInfo (r4) @ 7fffff40
      SystemInfo (r5) @ 7ffffe00
  DiagnosticInfo (r6) @ 00000000
            RTAS (r7) = 52544153
        RTASProc (r8) @ 00000000
    HardwareInfo (r9) @ 7ffffd40

DebugDumpPageMap
0 000: 0000ffff 00000a00
  008: 0000ffff 00000a00
1 010: 0000ffff 00000a00
  018: 0000ffff 00000a00
2 020: 0000ffff 00000a00
  028: 0000ffff 00000a00
3 030: 0000ffff 00000a00
  038: 0000ffff 00000a00
4 040: 0000ffff 00000a00
  048: 0000ffff 00000a00
5 050: 0000fffd 00000a00
  058: 0000fffd 00000a00
  060: fffe0000 00000012 IRP
  068: 0000ffff 00000a00
  070: 0000ffff 00000a00
6 078: 4000017f 55600012
  080: 8fef0000 00003013
  088: 8ffe0000 00000011 KDP
  090: 8fff0000 00000012 EDP
  098: 0000ffff 00000a01
  0a0: 0000ffff 00000a01
  0a8: 0000ffff 00000a00
7 0b0: 0000ffff 00000a01
  0b8: 0000ffff 00000a01
  0c0: 0000ffff 00000a00
8 0c8: 0000005f 8000003a
  0d0: 00600000 8006003a
  0d8: 0061001e 8006103a
  0e0: 00800000 8008003a
  0e8: 00810000 8008103a
  0f0: 0000ffff 80000a01
  0f8: 0000ffff 00000a00
9 100: 0000000f 9000003a
  108: 0020001f 9002003a
  110: 0000ffff 90000a01
  118: 0000ffff 00000a00
A 120: 0000ffff a0000032
  128: 0000ffff a0000a01
  130: 0000ffff 00000a00
B 138: 0000ffff b0000a01
  140: 0000ffff 00000a00
C 148: 0000ffff c0000a01
  150: 0000ffff 00000a00
D 158: 0000ffff d0000a01
  160: 0000ffff 00000a00
E 168: 0000ffff e0000a01
  170: 0000ffff 00000a00
F 178: 00004fff f000003a
  180: 50000000 f500003a
  188: 500100fe f500103a
  190: 510000ff f510003a
  198: 520001ff f520003a
  1a0: 5400abff f540003a
  1a8: 0000ffff f0000a01
  1b0: 0000ffff 00000a00

Rearranging the MacOS address space...

ErasePageMapTable at offset 0x3ac

PatchMacOSAddressSpace: makeMemAvail 68000000
    nontrivial PME   LA = 0x50000000, count = 0x0FFFE, PA = 0x00000000, pageAttr = 0x0A00, flags = 0x00.
    MacOS area delimiter: skipping

    nontrivial PME   LA = 0x50000000, count = 0x0FFFE, PA = 0x00000000, pageAttr = 0x0A00, flags = 0x00.
    MacOS area delimiter: skipping

    nontrivial PME   LA = 0x5FFFE000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0012, flags = 0x01.
    **IRP**
    Patching Emulator lis/ori @ 181e8
    AddPageMapEntry: LA = 0xDFFFE000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0012, flags = 0x01.

    nontrivial PME   LA = 0x64000000, count = 0x00180, PA = 0x55600000, pageAttr = 0x0012, flags = 0x00.
    **Universal/DeviceTree area**
    AddPageMapEntry: LA = 0xE4000000, count = 0x00180, PA = 0x55600000, pageAttr = 0x0012, flags = 0x00.

    nontrivial PME   LA = 0x68FEF000, count = 0x00001, PA = 0x00003000, pageAttr = 0x0013, flags = 0x00.
    AddPageMapEntry: LA = 0x68FEF000, count = 0x00001, PA = 0x00003000, pageAttr = 0x0013, flags = 0x00.

    nontrivial PME   LA = 0x68FFE000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0011, flags = 0x02.
    AddPageMapEntry: LA = 0x68FFE000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0011, flags = 0x02.

    nontrivial PME   LA = 0x68FFF000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0012, flags = 0x03.
    AddPageMapEntry: LA = 0x68FFF000, count = 0x00001, PA = 0x00000000, pageAttr = 0x0012, flags = 0x03.

    nontrivial PME   LA = 0x80000000, count = 0x00060, PA = 0x80000000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x80000000, count = 0x00060, PA = 0x80000000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x80060000, count = 0x00001, PA = 0x80060000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x80060000, count = 0x00001, PA = 0x80060000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x80061000, count = 0x0001F, PA = 0x80061000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x80061000, count = 0x0001F, PA = 0x80061000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x80080000, count = 0x00001, PA = 0x80080000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x80080000, count = 0x00001, PA = 0x80080000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x80081000, count = 0x00001, PA = 0x80081000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x80081000, count = 0x00001, PA = 0x80081000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x90000000, count = 0x00010, PA = 0x90000000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x90000000, count = 0x00010, PA = 0x90000000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0x90020000, count = 0x00020, PA = 0x90020000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0x90020000, count = 0x00020, PA = 0x90020000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0xA0000000, count = 0x10000, PA = 0xA0000000, pageAttr = 0x0032, flags = 0x00.
    AddPageMapEntry: LA = 0xA0000000, count = 0x10000, PA = 0xA0000000, pageAttr = 0x0032, flags = 0x00.

    nontrivial PME   LA = 0xF0000000, count = 0x05000, PA = 0xF0000000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0xF0000000, count = 0x05000, PA = 0xF0000000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0xF5000000, count = 0x00001, PA = 0xF5000000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0xF5000000, count = 0x00001, PA = 0xF5000000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0xF5001000, count = 0x000FF, PA = 0xF5001000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0xF5001000, count = 0x000FF, PA = 0xF5001000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0xF5100000, count = 0x00100, PA = 0xF5100000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0xF5100000, count = 0x00100, PA = 0xF5100000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0xF5200000, count = 0x00200, PA = 0xF5200000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0xF5200000, count = 0x00200, PA = 0xF5200000, pageAttr = 0x003A, flags = 0x00.

    nontrivial PME   LA = 0xF5400000, count = 0x0AC00, PA = 0xF5400000, pageAttr = 0x003A, flags = 0x00.
    AddPageMapEntry: LA = 0xF5400000, count = 0x0AC00, PA = 0xF5400000, pageAttr = 0x003A, flags = 0x00.

    Reinserting the MacOS area delimiters:
    AddPageMapEntry: LA = 0x60000000, count = 0x08000, PA = 0x00000000, pageAttr = 0x0A00, flags = 0x00.
    AddPageMapEntry: LA = 0x60000000, count = 0x08000, PA = 0x00000000, pageAttr = 0x0A00, flags = 0x00.

Copying modified ConfigInfo and HWInfo over the originals.

DebugDumpPageMap
0 000: 0000ffff 00000a00
  008: 0000ffff 00000a00
1 010: 0000ffff 00000a00
  018: 0000ffff 00000a00
2 020: 0000ffff 00000a00
  028: 0000ffff 00000a00
3 030: 0000ffff 00000a00
  038: 0000ffff 00000a00
4 040: 0000ffff 00000a00
  048: 0000ffff 00000a00
5 050: 0000ffff 00000a00
  058: 0000ffff 00000a00
6 060: 00007fff 00000a00
  068: 00007fff 00000a00
  070: 8fef0000 00003013
  078: 8ffe0000 00000011 KDP
  080: 8fff0000 00000012 EDP
  088: 0000ffff 00000a01
  090: 0000ffff 00000a01
  098: 0000ffff 00000a00
7 0a0: 0000ffff 00000a01
  0a8: 0000ffff 00000a01
  0b0: 0000ffff 00000a00
8 0b8: 0000005f 8000003a
  0c0: 00600000 8006003a
  0c8: 0061001e 8006103a
  0d0: 00800000 8008003a
  0d8: 00810000 8008103a
  0e0: 0000ffff 80000a01
  0e8: 0000ffff 00000a00
9 0f0: 0000000f 9000003a
  0f8: 0020001f 9002003a
  100: 0000ffff 90000a01
  108: 0000ffff 00000a00
A 110: 0000ffff a0000032
  118: 0000ffff a0000a01
  120: 0000ffff 00000a00
B 128: 0000ffff b0000a01
  130: 0000ffff 00000a00
C 138: 0000ffff c0000a01
  140: 0000ffff 00000a00
D 148: fffe0000 00000012 IRP
  150: 0000ffff d0000a01
  158: 0000ffff 00000a00
E 160: 4000017f 55600012
  168: 0000ffff e0000a01
  170: 0000ffff 00000a00
F 178: 00004fff f000003a
  180: 50000000 f500003a
  188: 500100fe f500103a
  190: 510000ff f510003a
  198: 520001ff f520003a
  1a0: 5400abff f540003a
  1a8: 0000ffff f0000a01
  1b0: 0000ffff 00000a00


Handing over to the NanoKernel.

  Before/After RAM stats same as the results with the MDD (as expected), so I won't bother with additional screenshots.  BTW, posting this from the 9serve!
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: MacTron on June 04, 2017, 01:26:04 PM
I just added 256 MB or RAM to my main working computer (a G4 MDD) and I started to do real life test, In this picture we can see Cubase using 1.54 Gb or RAM, (mainly loaded by Kompakt sampler instruments). No problems by now ...  ;D

(http://macos9lives.com/smforum/index.php?action=dlattach;topic=2860.0;attach=4415;image)
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: MacOS Plus on June 04, 2017, 03:44:49 PM
  I figured you would be the first to max it out with synths!  When we eventually get the full two gigs, please give us a report on latency. ;)
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: DieHard on June 04, 2017, 06:42:03 PM
We should inform the other forums about this !  This is pretty crazy... 15 years after the OS 9 funeral it is getting a genetic overhaul,
128MB might not seem like much until you consider that 128MB is what many users had in the Classic Mac OS era to run OS 9 and all their applications.

In the big scheme of things, this is quite remarkable :)
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: MacOS Plus on June 04, 2017, 07:31:31 PM
  Remember a time when a 128MB DIMM stick wasn't just a leftover at the bottom of your spare pile?  Nostalgic...
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: ELN on June 04, 2017, 08:10:19 PM
I just added 256 MB or RAM to my main working computer (a G4 MDD) and I started to do real life test, In this picture we can see Cubase using 1.54 Gb or RAM, (mainly loaded by kompak sampler instruments). No problems by now ...  ;D

This is good to see! We are considering some other ways of pushing the limit even further. It might require us to patch the Process Manager to divide up its heap. It would be very useful for me to know the memory layout on your machine running Cubase.

Would you mind collecting some data for me? A screenshot of this app while Cubase is running, and the details in the Memory panel of the Get Info window for Cubase.

https://www.macintoshrepository.org/1253-memory-mapper-1-5 (https://www.macintoshrepository.org/1253-memory-mapper-1-5)

And by the way, is it possible to enable VM on a machine with 2GB of RAM? Would someone mind checking?

We should inform the other forums about this !

Go for it!
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: nanopico on June 04, 2017, 08:20:20 PM
I just added 256 MB or RAM to my main working computer (a G4 MDD) and I started to do real life test, In this picture we can see Cubase using 1.54 Gb or RAM, (mainly loaded by kompak sampler instruments). No problems by now ...  ;D

This is good to see! We are considering some other ways of pushing the limit even further. It might require us to patch the Process Manager to divide up its heap. It would be very useful for me to know the memory layout on your machine running Cubase.

Would you mind collecting some data for me? A screenshot of this app while Cubase is running, and the details in the Memory panel of the Get Info window for Cubase.

https://www.macintoshrepository.org/1253-memory-mapper-1-5 (https://www.macintoshrepository.org/1253-memory-mapper-1-5)

And by the way, is it possible to enable VM on a machine with 2GB of RAM? Would someone mind checking?

We should inform the other forums about this !

Go for it!

If I recall, there is a point where you can no longer turn on virtual memory because you have enough RAM.  I don't recall off the top of my head though.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: Protools5LEGuy on June 05, 2017, 06:36:01 AM
We should inform the other forums about this !  This is pretty crazy... 15 years after the OS 9 funeral it is getting a genetic overhaul,
128MB might not seem like much until you consider that 128MB is what many users had in the Classic Mac OS era to run OS 9 and all their applications.

In the big scheme of things, this is quite remarkable :)

Done. https://forums.macrumors.com/threads/mac-os-9-2-2-memory-limit-of-1-5-gb-broken.2048385/ (https://forums.macrumors.com/threads/mac-os-9-2-2-memory-limit-of-1-5-gb-broken.2048385/)
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: MacTron on June 05, 2017, 08:31:40 AM
Would you mind collecting some data for me? A screenshot of this app while Cubase is running, and the details in the Memory panel of the Get Info window for Cubase.
Of course I'll do it, it's a pleasure to participate in this historical thread :)

(http://macos9lives.com/smforum/index.php?action=dlattach;topic=2860.0;attach=4419;image)

I have also added a "About this computer" window, just to remember you that this machine have 1.75 GB of RAM.
 My System and Finder Files have the size values in SIZE resources slightly increased to increase stability.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: MacOS Plus on June 05, 2017, 09:21:56 AM
  Speaking of 1.75GB of RAM, I just went through hell trying to test a Sawtooth over the limit.  I had a matched set of four 512MB DIMMs available to test with but the machine insisted one of them was "incompatible".  After much screwing around and a whole bunch of necessitated PMU resets I managed to get my only remaining extra 512MB DIMM I could find recognized as 256MB.  Of course all of this nonsense is to be fully expected from a Sawtooth motherboard, but at least getting it to count 1.75GBs of RAM proves this machine should be able to recognize 2GB if given RAM it 'likes'.  I'll see if I can purchase more now that I know it's worth installing.

  In the end I still accomplished to purpose of the test - the RAM gain works on this machine with the latest modified Mac OS ROM.  Thanks to all the time I wasted this morning on this I don't have time to post logs yet.  I can make one interesting observation, and that is System Profiler didn't crash in this config on the Sawtooth.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: ELN on June 05, 2017, 04:46:59 PM
I didn't realise that Sawteeth could take all that RAM. Cool!

MacTron, your results surprise me. I expected Cubase to have a smaller base memory partition with several Temporary Memory allocations. Does Cubase have any settings concerning how it manages memory? Thanks for the screenshot!

There are roughly two approaches we can take from here. One is to move the fixed areas, and the other is to patch the Process Manager to work around them. Good fun!
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: MacOS Plus on June 05, 2017, 08:47:22 PM
I didn't realise that Sawteeth could take all that RAM. Cool!

  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.  For that price I don't even care if the Macs don't like them - I'll just use them for my old PC stuff.  It's crazy how much some of this vintage of hardware has depreciated with time!

  Now I should go see how cheap the old DDR RAM is...

<update> Just picked up 20 pieces of PC3200 DDR 512MB DIMMs for USD $2.90 each and free shipping!  At these prices everyone should be stocking up and maxing out their systems.  You really have no excuse!  Even for listings guaranteeing Mac-tested/compatible the prices aren't much higher.

  If anyone else is going to buy RAM, I believe you have to get what's referred to as "low-density" type if you want the best chance of it working in Macs (or many other things, for that matter).  Perhaps someone with decent Apple tech experience in this area can comment further on that.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: MacTron on June 06, 2017, 08:40:47 AM
MacTron, your results surprise me. I expected Cubase to have a smaller base memory partition with several Temporary Memory allocations.
Most of this memory is filled with near 1.5 GB of sampled instruments, loaded inside Cubase by a VST Plugin ( NI Kompakt ).
Here I take another screenshot with an empty Cubase projet, and the same memory allocation:
(http://macos9lives.com/smforum/index.php?action=dlattach;topic=2860.0;attach=4421;image)

Quote
Does Cubase have any settings concerning how it manages memory?
No it doesn't, It only have settings on how dual processors are managed, but this is another thing...
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: MacTron on June 06, 2017, 09:04:27 AM
  I figured you would be the first to max it out with synths!  When we eventually get the full two gigs,
The Synths take all the CPU power first, barely use RAM, but the Samplers eat RAM really easily, a good sampled piano can take 1.5 gb of memory. Usually Samplers to save RAM use a hybrid system (like Virtual Memory) from Hard Disk , but this decrease its capabilities a lot . To said it in short.
Quote
please give us a report on latency. ;)
To report latency, is a very complex task, because it depends in a huge amount of factors ...
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: MacOS Plus on June 06, 2017, 09:27:13 AM
  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!
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: MacTron on June 06, 2017, 01:00:29 PM
  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)   ;D ...
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: MacOS Plus on June 06, 2017, 08:20:07 PM
  Okay, thanks, that's very informative.  Most excellent too that the gained RAM has already made a major difference for your project - that's fantastic!  I'd really love to try loading up a 1.5GB piano myself.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: ELN on June 09, 2017, 06:46:27 PM
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)   ;D ...

Cool! How's it going? Do I get a copy?

Another question for you, MacTron. If you reduce Cubase's allocation in the Memory Info panel (say to 512MB), does this actually reduce the number of instruments you can use? Or does Cubase possibly use the Temporary Memory allocation scheme to get around this limit?
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: MacTron on June 10, 2017, 04:20:19 AM

Cool! How's it going? Do I get a copy?
Of Course you can, Everything is in the downloads sections, If you can't' find something just let me know.  ;)
Quote
Another question for you, MacTron. If you reduce Cubase's allocation in the Memory Info panel (say to 512MB), does this actually reduce the number of instruments you can use?
If I reduce the Cubase allocation in the Memory Info panel, the amount of memory available is reduced accordingly.
Cubase - as most applications - fill its allocation memory with the contents of its files, in this case with scores, mixing setups, virtual effects and instruments etc ...  the virtual samplers ( loaded inside Cubase)  besides the memory they use for its code and resources, uses memory to store the samples that conform the Sampler instruments, as they are loaded inside Cubase they only have access to the memory in the Cubase partition, not outside it.

Quote
Or does Cubase possibly use the Temporary Memory allocation scheme to get around this limit?

No Cubase can't do this. Emagic Logic Audio does.


I have edited this post to add a typical example of sampled instruments memory usage:
500Mb -> Women choir (with all consonants and vowels)
500Mb -> String section ( violin,  violas , cellos, etc) with several articulations (staccato, sustained ...)
500 Mb -> Brass, Woodwind and Percussion.

As you can see a basic setup fill 1.5 Gb of memory and it's hard to insert a piano, an harp or even church organ  :)


A workaround of this is to play the samples directly from disk instead of loading them to RAM, or at least in part, but the polyphony decreases heavily because this process implies that the samples have to travel from the HD througth the PCI bus etc, and this heavily slowdown the playback performance .

I you have Youtube access here you can see an example of this setup. Everything is rendered in real time in a Mac Os 9 machine -even the video- :
https://youtu.be/faisvdwXjpg
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: MacOS Plus on June 10, 2017, 08:54:45 AM
  Or does Cubase possibly use the Temporary Memory allocation scheme to get around this limit?

No Cubase can't do this. Emagic Logic Audio does.

  This is a useful tidbit I wasn't aware of.  In a program that can't do this, what typically happens if it hits the cap?  I remember one DAW program many years ago I had to use on a Quadra with only 40MB of RAM, and this program had a memory leak that would only let me do about three hours work before I had to save/quit/re-open.  If it was allowed to hit the cap of its allocation it would generally crash with a numbered error, so I had to keep the RAM monitor window open and keep watch over it.  I'm fairly certain the memory leak persisted on later more capable workstations using the same software, but the much larger amount of RAM in the other systems masked over the problem.  I don't know if the problem was related only to the software or if it also was a problem with Mac OS 8.1.  The other, better workstations were running Mac OS 8.6.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: DieHard on June 12, 2017, 01:46:31 AM
From GeForce4
Quote
doing what exactly tho??
wishing on a star? :) for an alternate universe? where macos9 takes 16gb of ram?

every other os tho, the limitations that were there when the os was current, still apply, this is not linux.
its not open source.. the chances of you guys really modifying + changing functionality of the os is very unlikely.
getting mac os 9 to run on a fw800 is a bit different because its somethng that was purposely disabled
its not something that was an incompatibility that was never overcome by the real developers.. u think there wasnt any
really skilled programmers at apple? who would have loved to advanced their career by coming up with the idea that doubled or quadrupled available ram to the OS???

but a few guys scratchin at notepad on a forums site can do it when the real pros couldnt? :) i dunno guys...
alot of times the best work is done by accepting + Working within the limitations

I guess there are those above the REAL PROS...
Quote
The Ultra-Pros do NOT accept limitations... while changing the rules they bend the universe into submission

128MB... one small step for Mac OS 9, one giant step for User-kind
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: SonikArchitects on June 12, 2017, 06:30:01 AM
This is so amazing I am absolutely speechless. Want this on my main rig asap.
Is there a DL link and instructions?

Just a side thought, there's been a lot of progress with augmenting 9.22 at this point. Maybe the admins could make an area for downloadable augmentations to the system with txt doc's of simple install instructions.

PS, I've showed some folks at Apple this and they are, shall I say, speechless. Literally.
Winning guys. This is incredible.

Best,
_BT
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: nanopico on June 12, 2017, 07:13:48 AM
PS, I've showed some folks at Apple this and they are, shall I say, speechless. Literally.
Winning guys. This is incredible.

I hope it's speechless because they are impressed.

I guess it was only a mater of time before someone tipped off someone at Apple, who knows though, maybe they already know.

Out of curiosity, what's your relationship with the people at Apple that are now informed of this?
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: DieHard on June 12, 2017, 09:40:43 AM
This is so amazing I am absolutely speechless. Want this on my main rig asap.
Is there a DL link and instructions?

Just a side thought, there's been a lot of progress with augmenting 9.22 at this point. Maybe the admins could make an area for downloadable augmentations to the system with txt doc's of simple install instructions.

Best,
_BT

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
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: nanopico on June 12, 2017, 09:52:24 AM
This is so amazing I am absolutely speechless. Want this on my main rig asap.
Is there a DL link and instructions?

Just a side thought, there's been a lot of progress with augmenting 9.22 at this point. Maybe the admins could make an area for downloadable augmentations to the system with txt doc's of simple install instructions.

Best,
_BT

We are working on a system install

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

We are working on an installer cd with the ROM and the most current version and drivers that are available here (We are still a bit out on this one).
Although ASR is very good, building an installer that is just like Apple's would make sense on this.
All features of the OS would be available and allow the user to decide what to use. 
The ASR images are great for things like the DAW and other stuff, but if a user doesn't need all that and needs things from the OS that are not in the ASR and universal general install should be used.  I think all and all there should be both options available depending on the end users needs.

From GeForce4
Quote
doing what exactly tho??
wishing on a star? :) for an alternate universe? where macos9 takes 16gb of ram?

every other os tho, the limitations that were there when the os was current, still apply, this is not linux.
its not open source.. the chances of you guys really modifying + changing functionality of the os is very unlikely.
getting mac os 9 to run on a fw800 is a bit different because its somethng that was purposely disabled
its not something that was an incompatibility that was never overcome by the real developers.. u think there wasnt any
really skilled programmers at apple? who would have loved to advanced their career by coming up with the idea that doubled or quadrupled available ram to the OS???

but a few guys scratchin at notepad on a forums site can do it when the real pros couldnt? :) i dunno guys...
alot of times the best work is done by accepting + Working within the limitations

I guess there are those above the REAL PROS...
Quote
The Ultra-Pros do NOT accept limitations... while changing the rules they bend the universe into submission

128MB... one small step for Mac OS 9, one giant step for User-kind

And since you brought it up. Notepad is a pretty cool app. I do use it regularly. ;D
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: Irisman on June 12, 2017, 10:03:30 AM
Absolutely impressive work!!  My hat off!!!
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: nanopico on June 12, 2017, 02:22:09 PM
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.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: Irisman on June 12, 2017, 02:52:02 PM
  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)   ;D ...

I'd like to listen when finished 😁
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: DieHard on June 12, 2017, 06:06:03 PM
When you tell us we are at "Max RAM Version" ROM...

We will make a new thread with machines tested and detailed instructions
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: MacOS Plus on June 12, 2017, 10:05:46 PM
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!
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: ELN on June 13, 2017, 08:06:50 AM
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.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: MacOS Plus on June 13, 2017, 09:38:08 AM
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.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: nanopico on June 13, 2017, 02:05:18 PM
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.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: ELN on June 13, 2017, 05:33:40 PM
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
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: MacOS Plus on June 13, 2017, 10:43:40 PM
  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.)
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: ELN on June 13, 2017, 11:14:47 PM
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?
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: MacTron on June 14, 2017, 09:23:56 AM
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
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: Knezzen on June 14, 2017, 11:44:35 PM
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).
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: MacOS Plus on June 15, 2017, 09:24:10 AM
  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 (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.)
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: DieHard on June 15, 2017, 09:36:08 AM
 
  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 (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
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: Knezzen on June 15, 2017, 09:56:34 AM
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:
Quote
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.

(http://macintoshgarden.org/sites/macintoshgarden.org/files/imagecache/thumbnail/screenshots/os9helper.png)
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: MacOS Plus on June 15, 2017, 10:05:58 AM
  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'. ;)
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: DieHard on June 15, 2017, 12:07:17 PM
  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
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: Daniel on June 15, 2017, 01:29:58 PM
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.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: MacTron on June 15, 2017, 01:43:49 PM
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  :)
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: macStuff on August 07, 2017, 02:07:39 PM
  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?
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: MacOS Plus on August 09, 2017, 02:21:03 PM
  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.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: IIO on August 09, 2017, 07:14:00 PM
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.

shouldnt that be in our next update for the 922 universal install?
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: OS923 on November 17, 2017, 04:26:40 AM
In 32-bit Windows there's a similar problem. The "lost" memory is called Invisible Memory, Hidden Memory or Unmanaged Memory. There are several programs for Windows which can use this lost memory as a disk cache or RAM disk. This is probably also possible in OS 9 (as a device driver and there's an open source example from Apple). Normal programs would not be able to access this memory. www.romexsoftware.com has a programming interface for this lost memory. All programs which use this programming interface may be running at the same time. That's how we would best organize this if we get it to work.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: nanopico on November 17, 2017, 06:47:17 AM
In 32-bit Windows there's a similar problem. The "lost" memory is called Invisible Memory, Hidden Memory or Unmanaged Memory. There are several programs for Windows which can use this lost memory as a disk cache or RAM disk. This is probably also possible in OS 9 (as a device driver and there's an open source example from Apple). Normal programs would not be able to access this memory. www.romexsoftware.com has a programming interface for this lost memory. All programs which use this programming interface may be running at the same time. That's how we would best organize this if we get it to work.


From all the work we have done so far, these solutions won't work.
Kernel and Trampoline first have to be patched.  The trampoline has to tell the kernel that it can use 2 GB of RAM, but it has to lock the space used by the emulator.  The kernel will have to be modified to map the physical RAM to virtual RAM addresses.  There are system calls to ask to get into a mode where you can use the physical address, which is used by hardware drivers.  Virtual memory address still has to exist though so that the call can ask for the physical address of a specific virtual address.  There is no virtual address for the missing RAM.
It is possible to bypass the memory manager and use any memory you want as long as it has a virtual address.

One thing to keep in mind.  Apple shipped computers that officially support 2 GB of RAM that were released before OS X was available.
Now because X was just around the corner you could argue that they didn't put any effort into fixing it.  8.6 shipped with the G4 AGP.  That supported 2 GB.   OS X didn't become available until about 2 years later. So OS 9 came next.  Problem still not resolved.  It was probably a significant undertaking so they waited for OS X (stupid fucking idea if you ask me). Did people ever complain about being limited by this barrier?  I would think that Apple would have tried to resolve this so that the customer wouldn't get incredibly pissed off. I would think that they would at least make some level of effort to make the full RAM available. But it's Apple, they make a lot of completely bat shit crazy ideas (well I think they do).

Not sure where that was going.  Point being, it's possible to get it back.  How is the first question. Stability is the next.  We still don't know how much we would have to patch yet to make everything stable, even if using it as a RAM disk.  Kernel, Memory Manager, Process Manager and Trampoline are all going to need some level of patching to make this work before we can even tackle the stability issue.
An extension/driver will not solve this.  If you think it will, you're more than welcome to write one.

Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: OS923 on November 24, 2017, 05:57:01 AM
It wouldn't require patching all these difficult things like Kernel, Memory Manager, Process Manager and Trampoline. Therefore, it has most chance of success. If they solved it this way on Windows, then I presume that patches were too difficult to get it right under all circumstances. A RAM-disk or cache is then better than nothing.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: Daniel on November 24, 2017, 08:22:34 AM
We would need to be able to patch the Process Manager and be able to mess with the data structures of the Memory Manager. The method I consider most likely to work is to use NanoKernel calls to map in the unused memory in one contiguous area somewhere. If we just want a ram disk, we are pretty much done here. If we want it to be usable memory, we have a much harder time. We could try to extend to Process Manager's heap out to the new memory, but there is a bunch of other stuff in between them that we can't move. We would have to patch the process manager so that it doesn't use the big hole in the middle of its heap. If we want a single application to use all the memory, as MacTron wants, we additionally have to stick a non-relocatable block in the application heap that goes around the memory hole. That way, the memory manager doesn't try to use the part of the application heap that isn't actually part of the application heap.

The good news is that the process manager is one of the last things to start up in the boot process and it is loaded from a resource. It is definitely possible to make an extension that does some NK calls and overrides a resource. That doesn't mean it will be easy, but it can be done.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: nanopico on November 29, 2017, 01:42:45 PM
We would need to be able to patch the Process Manager and be able to mess with the data structures of the Memory Manager. The method I consider most likely to work is to use NanoKernel calls to map in the unused memory in one contiguous area somewhere. If we just want a ram disk, we are pretty much done here. If we want it to be usable memory, we have a much harder time. We could try to extend to Process Manager's heap out to the new memory, but there is a bunch of other stuff in between them that we can't move. We would have to patch the process manager so that it doesn't use the big hole in the middle of its heap. If we want a single application to use all the memory, as MacTron wants, we additionally have to stick a non-relocatable block in the application heap that goes around the memory hole. That way, the memory manager doesn't try to use the part of the application heap that isn't actually part of the application heap.

The good news is that the process manager is one of the last things to start up in the boot process and it is loaded from a resource. It is definitely possible to make an extension that does some NK calls and overrides a resource. That doesn't mean it will be easy, but it can be done.

Moving the Process Manager heap and informing of a non-relocatable block is one idea I had a while back.  Not sure if it was discussed here or not. The memory manager works so tightly with the Process Manager that there is likely a patch to that as well.  An extension will be the best bet as you are correct that the Process Manager is one of the last things started prior to the finder.  From everything I have read, the Memory Manager is what starts the Process Manager.  This is the reason I say the Memory Manager would need patching.  It would have to know to load the Process Manager heap higher and set the block it can't use.

Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: nightstalkerpoet on January 04, 2018, 01:50:27 AM
Just jumping in here, trying to look through posts to see what resources everyone is using.

Most likely, this is being used, but if not: https://web.archive.org/web/20030801125655/http://developer.apple.com:80/documentation/macos8/mac8.html

The Memory Manager section seems to give a lot of information on altering low-level OS memory behavior.

This also looks potentially more easily searchable:
http://mirror.informatimago.com/next/developer.apple.com/
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: nanopico on January 04, 2018, 02:28:30 PM
Just jumping in here, trying to look through posts to see what resources everyone is using.

Most likely, this is being used, but if not: https://web.archive.org/web/20030801125655/http://developer.apple.com:80/documentation/macos8/mac8.html

The Memory Manager section seems to give a lot of information on altering low-level OS memory behavior.

This also looks potentially more easily searchable:
http://mirror.informatimago.com/next/developer.apple.com/

I can't speak for anyone else, but yes I have read most of that. All the documented memory management stuff isn't loaded or available until too late.  The issue for the limit is the 68K emulator.  It needs to be loaded way early and so it needs to be loaded into a different portion of memory before it can be called an fully initialized/started so that it can run from a different memory area.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: nightstalkerpoet on January 04, 2018, 06:10:00 PM
I'm still working on trying to understand a lot of this - teaching myself programming specifically to help here.

Is there a way to replace the Apple 68k emulator with the one found in Speed Doubler, and would that help?
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: Daniel on January 04, 2018, 07:06:42 PM
Inserting the Speed Doubler emulator directly into the Mac OS ROM file would be really cool, but it probably won't solve this problem.
The programming knowledge to look for should be some combination of:
•68k Assembly
•PowerPC Assembly
•Familiarity with Macintosh Programmer's Workshop
•Various languages that compile to 68k or PPC assembly (mainly c, pascal, and c++)
•Forth and Open Firmware(not useful for solving the 1.5GB limit but good for other projects)

The major components that are relevent to cracking the 1.5GB limit are:
•the NanoKernel
•the 68k Emulator
•the modern (figment) Memory Manager (the only thing in this list we have the complete official source to)
•the Virtual Memory Manager
•the Process Manager

If you want a challenge, try looking through an early 7.x system file to figure out how Apple utilizes unused NuBus slot space to increase addressable memory on 24-bit systems (this is mentioned in Inside Macintosh:Memory). If that code is findable and usable, that could be 95% of the solution.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: nightstalkerpoet on January 05, 2018, 10:57:25 AM
Thanks, I'll take a look at those!

From reading this page, it appears that the potential conflict could be in a REALLY stupid place - fonts.
https://68kmla.org/forums/index.php?/topic/38338-crazy-ram-in-9600/

I got there simply due to a curiosity of the PowerMac 9600 and Ram.

If 256mb EDO Ram was installed (https://harddiskdirect.com/228471-001-compaq-256mb-edo-ecc-60ns-168-pin-dimm-memory-module.html) in that system, you'd have access to 3gb of ram. I've read MDDs don't like any more than 2gb (though there's potential there for up to 4gb), but maybe the 3gb limit could be pushed in these models for RAM intensive operations that don't require as much speed.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: nanopico on January 05, 2018, 01:52:58 PM
Thanks, I'll take a look at those!

From reading this page, it appears that the potential conflict could be in a REALLY stupid place - fonts.
https://68kmla.org/forums/index.php?/topic/38338-crazy-ram-in-9600/

I got there simply due to a curiosity of the PowerMac 9600 and Ram.

If 256mb EDO Ram was installed (https://harddiskdirect.com/228471-001-compaq-256mb-edo-ecc-60ns-168-pin-dimm-memory-module.html) in that system, you'd have access to 3gb of ram. I've read MDDs don't like any more than 2gb (though there's potential there for up to 4gb), but maybe the 3gb limit could be pushed in these models for RAM intensive operations that don't require as much speed.

Well the OS knows about all 2 GB, but it is only assigning 1.5 to the process manager and the rest is assumed to be system memory by the OS, mapped or unmapped.  Part of the view right now is that the process manager may not be able to handle two seqments of RAM. One option is to somehow give the process manager all the RAM, but mark the 68k emulator as not usable and leave it alone.   

256 EDO in the 9600 wouldn't work afaik.  It limits each dimm to 128.  Limit of the hardware memory controller (not the MMU in the CPU).
Same goes for the MDD.  The memory controller can only handle 2GB.  It's a hardware limitation on those machines.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: ELN on January 06, 2018, 05:30:33 AM
The NK knows about all 2 GB but is instructed by the Trampoline via the ConfigInfo structure to allocate a maximum of Ox5FFFE000 to the primary address range (PAR). The upper layers are informed about the leftover physical memory via the SystemInfo structure, but can only access it indirectly by asking the kernel to map it into the logical address space.

The PAR is limited to that size because of some fixed-address data structures that the upper layers expect to find in the 5 and 6 segments. The kernel gets instructed to create these, too. The infoRecord page at 5FFFE000 can be moved with a few patches to the system, but the structures and code a bit higher up are too deeply rooted to move.
Title: Re: Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers
Post by: darthnVader on March 30, 2018, 04:05:38 AM
You know, many years ago I remember reading and article that technically the G4 could address 4 GB of Ram, but there was some catch to it, and I forget the exact terminology used, so bear with me.

It had something to do with using 4 GB only 2 GB could be made available due to some flaw in how the G4 was made, or how it worked. Something like the other 2 GB could only be addressed as "Shadow" memory, or "Backside" memory?

I don't think latter chips like the 7447/4478 were even made at the time the article was published.

So, maybe, hope beyond hope, later G4's could address unto 4 GB of Ram?

Something similar to PAE?

I mean, with OS 9, virtual memory is disabled with over 1 GB of ram, but OS X can use VM with over that. If we could get it to work, at least partition it as a RAM disk, and run our VM on that RAM disk?
Title: Re: 1.5GB Limit (some answers)
Post by: adespoton on July 13, 2020, 03:33:46 PM
Like I mentioned, running a studio under OS9 in the box will definitely run out of RAM at one time or another. 

Yes, G4s are cheap, but having multiple noisy G4s with extra cables and monitors are NOT the answer for many users; it may look cool, but many musicians have very little space due to nagging wives and other family obligations and most of the time are crammed in a small corner of the den as the "DAW cave".

So, I really believe, any efforts of maximizing OS 9 to "squeeze" more out of it, are not in vain.

Besides, it's fun to do what the Pros would not do... you act like that had a choice, they were hired employees that signed non-disclosures and were specifically told what to code, and what not to code.  Even if it was changing only a relative small amount of code to raise the RAM ceiling, I doubt any programmer that was making good money would make that argument with management.  They did as they were told, not as they wanted to... so to imply that "the pros couldn't do it, so how can we", may not be an accurate assessment of the facts.
Indeed.  Many of the fixes for OS 9 are actually fairly well understood in certain circles.  The issue here was that Jobs was burying OS 9 to drive sales of OS X and simplify the engineering chain.  So most of the people with the access and expertise to fix the problems... were moved elsewhere.  Must be frustrating for some of them, to know what the bugs were, what the proposed fixes were in the pipeline, and not only not be able to fix them, but not even be able to talk about what the issues/fixes were.