Jagmn wrote: ↑Fri May 21, 2021 7:53 pm
Ah, sorry: all my hacking is on top of the kanjitalk755 fork (same base as the Apple Silicon patch I originally supplied and the Arm64 JIT I've been getting up to scratch).
I'm happy with your suggestion of the bounds checking functionality.
However, looking at the memory map that SheepShaver uses I can't see how it could give the OS more RAM than will fit before the first shared Kernel Data area (0x5fffe000); at least not without some major re-orchestration that might break other things in the ROM patching et cetera. SS also needs to fit the ROM and signal stack into that space. There might be some 'easier' options possible if the ROM would be happy at an address above the hard-mapped locations, though that might take more delving than I can do right now
As an aside: do RAM disks work within SS? A quick test on my 9.0.4 seems to let me set it but the OS never actually creates it (at boot). Would RAM disks be useful within SS?
Now that I think about it, no, they don't. And I think you've already tangentially identified part of why -- they can't be properly addressed in SheepShaver's memory model.
And looking at my records, the "best" Old-World ROM for SheepShaver, 960FC647, supports memory between 32MB and 1GB. The second-best ROM, 960E4BE9, supports memory between 512MB and 1.5GB. The oldest supported ROM, 6F5724C0, supports memory between 8MB and 136MB. These are all 4MB ROMs.
Let's assume the first 4MB of the addressable space is the ROM. The signal stack should be able to go anywhere, so while it's in that space right now, I'll ignore it as far as memory requirements go. This leaves us with 1531MB addressable space without some major re-working. This is only 5 bytes shy of the known limit, so I'm guessing that the known limit is incorrect. This also implies that in an actual Mac, the rest of the RAM, while not addressable by the OS as Application memory, can be addressed as a RAM disk, which must be using a different method of addressing. So I'm guessing SheepShaver just doesn't implement that addressing at all, hence no access to RAM disks.
The long and short of this is: it looks like our ceiling should be 1531MB, and less if we keep the signal stack in that area too. And it looks like our floor should be either 8 (if we fix some things) or 32 (if we leave things as-is) MB. We should probably emit an error for anything outside that range, even if we round down or up as needed and keep running. And if we supported -1, that would allow us to support max RAM without future modifications, should SheepShaver's memory addressing code get updated in the future.