SheepShaver on Apple M1

About SheepShaver, a PPC Mac emulator for Windows, MacOS X, and Linux that can run System 7.5.3 to MacOS 9.0.4.

Moderators: Cat_7, Ronald P. Regensburg, ClockWise

shearer
Space Cadet
Posts: 8
Joined: Tue Nov 24, 2020 3:54 am

Re: SheepShaver on Apple M1

Post by shearer »

Ronald P. Regensburg wrote: Thu May 20, 2021 7:19 pm SheepShaver is inflexible in which location in memory it uses. The error is typical for when other processes are occupying that specific location in memory. I was about to ask you if SheepShaver would launch after a restart of your Mac Mini. Usually that solves the problem.

Good that you solved it by assigning less RAM. And 512 MB is plenty for most purposes.
I did try restarting previously, but that did not fix the issue.
Just for testing I increased the RAM back to 1024, and without closing SheepShaver it froze when restarting the OS.

When I change it to 768MB RAM it does launch without Rosetta, so I will settle on that!
User avatar
Ronald P. Regensburg
Expert User
Posts: 7821
Joined: Thu Feb 09, 2006 10:24 pm
Location: Amsterdam, Netherlands

Re: SheepShaver on Apple M1

Post by Ronald P. Regensburg »

shearer wrote: Thu May 20, 2021 8:07 pmJust for testing I increased the RAM back to 1024, and without closing SheepShaver it froze when restarting the OS.
Better not do that! After any change in settings SheepShaver should be quit and launched again. The prefs file is read by SheepShaver when the application is launched. Restarting the emulated machine after changes in the prefs file may result in conflicting and unintended behaviour.

I do not know why SheepShaver cannot use 1024MB RAM when run on Apple Silicon natively. Do others have the same experience?
Jagmn
Student Driver
Posts: 20
Joined: Fri Feb 19, 2021 7:37 am

Re: SheepShaver on Apple M1

Post by Jagmn »

Yes: this seems to be the case on my setup, too.

I've just had a look through the code paths for x86_64 vs Arm64 and it is down to how the different builds handle their memory allocation. NATMEM_OFFSET is used for Arm64 whereas x86_64 is using REAL_ADDRESSING. In the latter case, the RAM and ROM areas are allocated contiguously (so your ROM might not be at a static offset) whereas the former expects to be able to allocate ROM at a fixed offset (which, in turn, is clobbered by the request for 1024MB of RAM).

The different approaches are required but it is possible to make the NATMEM_OFFSET approach work with 1024MB of RAM: it's just yet more hacking in what is already a bit of a code warren. I'll see if I can clean out both build options and propose a patch (I already have something booting but it's a thorough hack job).
Jagmn
Student Driver
Posts: 20
Joined: Fri Feb 19, 2021 7:37 am

Re: SheepShaver on Apple M1

Post by Jagmn »

Quick update on where I'm at with the memory allocation patch and two usability questions I have:
  • I've cleaned up the issue on MacOS and changed the default approach to allocating the low memory globals, main RAM, ROM and the signal stack. This seems to be working and lets me ask SheepShaver to use up to 1529MB of RAM (~1450MB of which then is available within the OS).
  • I've added a new textual error message to report when the amount of RAM requested is not going to work (or would crash SS if it was actually used).
  • I'm still going through the Linux builds to make them work in a similar fashion as there is a parallel warren of code governing these.
My usability questions: It is currently possible to request a high or negative amount of RAM as the setting is parsed in as an int32.
  1. To reduce user headaches in the future, should we allow the user to specify '-1', or some other value, to use as much RAM as is programatically possible?
    1. The host OS would then be left to decide how to deal with the situation if this was more than physical RAM.
  2. For invalid memory settings (negative, too small, too large) should we default to a more sane value? The current behaviour is:
    1. If ramsize <= 1000: multiply it by 1MB (this will result in multiplying negative values by 1MB)
    2. if ramsize < 16MB set ramsize to 16MB
User avatar
adespoton
Forum All-Star
Posts: 4208
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: SheepShaver on Apple M1

Post by adespoton »

Jagmn wrote: Fri May 21, 2021 3:19 pm Quick update on where I'm at with the memory allocation patch and two usability questions I have:
  • I've cleaned up the issue on MacOS and changed the default approach to allocating the low memory globals, main RAM, ROM and the signal stack. This seems to be working and lets me ask SheepShaver to use up to 1529MB of RAM (~1450MB of which then is available within the OS).
  • I've added a new textual error message to report when the amount of RAM requested is not going to work (or would crash SS if it was actually used).
  • I'm still going through the Linux builds to make them work in a similar fashion as there is a parallel warren of code governing these.
My usability questions: It is currently possible to request a high or negative amount of RAM as the setting is parsed in as an int32.
  1. To reduce user headaches in the future, should we allow the user to specify '-1', or some other value, to use as much RAM as is programatically possible?
    1. The host OS would then be left to decide how to deal with the situation if this was more than physical RAM.
  2. For invalid memory settings (negative, too small, too large) should we default to a more sane value? The current behaviour is:
    1. If ramsize <= 1000: multiply it by 1MB (this will result in multiplying negative values by 1MB)
    2. if ramsize < 16MB set ramsize to 16MB
A quick check:
Are you working against the cebix repo or kanjitalk755's repo? I don't think you ever stated that.

Seems to me that one thing that should be done here is setting the int to a uint, or else ensuring we've got strict bounds checking on both sides if everyone's OK with -1 as a "use up to max value".
Next, if we're modifying this code, it would also be a good idea to follow http://www.macos9lives.com/smforum/inde ... pic=2101.0 and set a safe maximum value for RAM: 4096MB being the largest addressable by an OS SheepShaver can emulate, 1536MB being the largest usable as Application RAM in OS 9.

So you should be able to set memory to 4096 and then use 2560 of it as a RAM disk, and still have max RAM available inside the OS. At least you can do that on actual hardware.
User avatar
Ronald P. Regensburg
Expert User
Posts: 7821
Joined: Thu Feb 09, 2006 10:24 pm
Location: Amsterdam, Netherlands

Re: SheepShaver on Apple M1

Post by Ronald P. Regensburg »

(adespoton replied while I was writing my reply. I will post it anyway.)

You did not explicitly state which code you are working on. I suppose it is the source code we use here: https://github.com/kanjitalk755/macemu

About RAM memory:
Negative values should best be avoided. I remember several users who got into trouble by a negative RAM memory setting that they were not aware of.

The build-in prefs editor in SheepShaver for macOS defaults to 16MB (ramsize 16777216).
For a MacOS 9.0.4 installation in SheepShaver that is too little. Even with 32MB (ramsize 33554432) SheepShaver cannot start up with extensions enabled.
In my setup manual for OSX/macOS I advise to set RAM to 128, 256 or 512MB.
Also 1024MB works fine (on Intel). With larger values SheepShaver crashes at launch.

BasiliskII will gladly start up with System 7.5.5 with 16MB of RAM.
In my setup manual for OSX/macOS I advise to set RAM to 128 or 256MB.
Also BasiliskII can run with 1024MB of RAM, although that will rarely be useful.

I suppose a minimum value should best be 16MB (ramsize 16777216) and a maximum value could be 1024MB (ramsize 1073741824).
Jagmn
Student Driver
Posts: 20
Joined: Fri Feb 19, 2021 7:37 am

Re: SheepShaver on Apple M1

Post by Jagmn »

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 :smile:

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?
User avatar
adespoton
Forum All-Star
Posts: 4208
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: SheepShaver on Apple M1

Post by adespoton »

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 :smile:

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.
User avatar
Ronald P. Regensburg
Expert User
Posts: 7821
Joined: Thu Feb 09, 2006 10:24 pm
Location: Amsterdam, Netherlands

Re: SheepShaver on Apple M1

Post by Ronald P. Regensburg »

RAM disks do not work in SheepShaver.
On real hardware they were useful as temporary disk for some tasks because they were much faster than floppies or harddisks. I do not see any use for RAM disks in SheepShaver.
Jagmn
Student Driver
Posts: 20
Joined: Fri Feb 19, 2021 7:37 am

Re: SheepShaver on Apple M1

Post by Jagmn »

Thanks for the input adespoton & Ronald P. Regensburg; What I have today seems to work (though I still don't have a dev environment for checking Windows builds - I'd still like to get that set up). I agree that it's worth experimenting with the placement of the signal stack and SheepVars so I'll see what can be done around these.
The other constraint is that the ROM is put after the top of RAM, aligned to 1MB - so that was bringing my MB number down somewhat. :smile: I could experiment with moving that placement, too.

adespoton: Is there an archive of the ROMs you've listed somewhere? Mine are extracted from various ISOs or pre-existing installs and it'd be good to get a wider test base.
User avatar
adespoton
Forum All-Star
Posts: 4208
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: SheepShaver on Apple M1

Post by adespoton »

Jagmn wrote: Mon May 24, 2021 8:49 am Thanks for the input adespoton & Ronald P. Regensburg; What I have today seems to work (though I still don't have a dev environment for checking Windows builds - I'd still like to get that set up). I agree that it's worth experimenting with the placement of the signal stack and SheepVars so I'll see what can be done around these.
The other constraint is that the ROM is put after the top of RAM, aligned to 1MB - so that was bringing my MB number down somewhat. :smile: I could experiment with moving that placement, too.

adespoton: Is there an archive of the ROMs you've listed somewhere? Mine are extracted from various ISOs or pre-existing installs and it'd be good to get a wider test base.
https://docs.google.com/spreadsheets/d/ ... =840977089 - check the linked github repo's test images.
User avatar
Ronald P. Regensburg
Expert User
Posts: 7821
Joined: Thu Feb 09, 2006 10:24 pm
Location: Amsterdam, Netherlands

Re: SheepShaver on Apple M1

Post by Ronald P. Regensburg »

And there is the new world rom file that can be extracted from the “Mac OS ROM Update 1.0” using TomeViewer in Classic Mac OS. It can be used in SheepShaver with Mac OS 8.5 through 9.0.4. It is probably the most used rom file by users of the SheepShaver builds posted here. The extracted file can be downloaded from the Redundant Robot site: https://www.redundantrobot.com/sheepshaver
User avatar
adespoton
Forum All-Star
Posts: 4208
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: SheepShaver on Apple M1

Post by adespoton »

That would be New World ROM 1.1.2, MD5 17b134a0d837518498c06579aa4ff053. The test images include most of the New World collection from 1.1 through 10.2.1. SheepShaver only supports up to New World ROM 5.5.1.
Jagmn
Student Driver
Posts: 20
Joined: Fri Feb 19, 2021 7:37 am

Re: SheepShaver on Apple M1

Post by Jagmn »

Thanks! Very useful. Interestingly I wasn't initially able to boot with 5.5.1 (ROM patching error) but that might be down to my code base being in transition.
Post Reply