/[cebix]/SheepShaver/src/rsrc_patches.cpp
ViewVC logotype

Log of /SheepShaver/src/rsrc_patches.cpp

Parent Directory Parent Directory | Revision Log Revision Log


Links to HEAD: (view) (annotate)
Sticky Tag:

Revision 1.24 - (view) (annotate) - [select for diffs]
Tue Aug 18 18:26:10 2009 UTC (5 years, 3 months ago) by asvitkine
Branch: MAIN
CVS Tags: HEAD
Changes since 1.23: +1 -1 lines
Diff to previous 1.23 , to selected 1.6
[Michael Schmitt]
Attached is a patch to SheepShaver to fix memory allocation problems when OS X 10.5 is the host. It also relaxes the 512 MB RAM limit on OS X hosts.


Problem
-------
Some users have been unable to run SheepShaver on OS X 10.5 (Leopard) hosts. The symptom is error "ERROR: Cannot map RAM: File already exists".

SheepShaver allocates RAM at fixed addresses. If it is running in "Real" addressing mode, and can't allocate at address 0, then it was hard-coded to allocate the RAM area at 0x20000000. The ROM area as allocated at 0x40800000.

The normal configuration is for SheepShaver to run under SDL, which is a Cocoa wrapper. By the time SheepShaver does its memory allocations, the Cocoa application has already started. The result is the SheepShaver memory address space already contains libraries, fonts, Input Managers, and IOKit areas.

On Leopard hosts these areas can land on the same addresses SheepShaver needs, so SheepShaver's memory allocation fails.


Solution
--------
The approach is to change SheepShaver (on Unix & OS X hosts) to allocate the RAM area anywhere it can find the space, rather than at a fixed address.

This could result in the RAM allocated higher than the ROM area, which causes a crash. To prevent this from occurring, the RAM and ROM areas are allocated contiguously.

Previously the ROM starting address was a constant ROM_BASE, which was used throughout the source files. The ROM start address is now a variable ROMBase. ROMBase is allocated and set by main_*.cpp just like RAMBase.

A side-effect of this change is that it lifts the 512 MB RAM limit for OS X hosts. The limit was because the fixed RAM and ROM addresses were such that the RAM could only be 512 MB before it overlapped the ROM area.


Impact
------
The change to make ROMBase a variable is throughout all hosts & addressing modes.

The RAM and ROM areas will only shift when run on Unix & OS X hosts, otherwise the same fixed allocation address is used as before.

This change is limited to "Real" addressing mode. Unlike Basilisk II, SheepShaver *pre-calculates* the offset for "Direct" addressing mode; the offset is compiled into the program. If the RAM address were allowed to shift, it could result in the RAM area wrapping around address 0.


Changes to main_unix.cpp
------------------------
1. Real addressing mode no longer defines a RAM_BASE constant.

2. The base address of the Mac ROM (ROMBase) is defined and exported by this program.

3. Memory management helper vm_mac_acquire is renamed to vm_mac_acquire_fixed. Added a new memory management helper vm_mac_acquire, which allocates memory at any address.

4. Changed and rearranged the allocation of RAM and ROM areas.

Before it worked like this:

  - Allocate ROM area
  - If can, attempt to allocate RAM at address zero
  - If RAM not allocated at 0, allocate at fixed address

We still want to try allocating the RAM at zero, and if using DIRECT addressing we're still going to use the fixed addresses. So we don't know where the ROM should be until after we do the RAM. The new logic is:

  - If can, attempt to allocate RAM at address zero
  - If RAM not allocated at 0
      if REAL addressing
         allocate RAM and ROM together. The ROM address is aligned to a 1 MB boundary
      else (direct addressing)
         allocate RAM at fixed address
  - If ROM hasn't been allocated yet, allocate at fixed address

5. Calculate ROMBase and ROMBaseHost based on where the ROM was loaded.

6. There is a crash if the RAM is allocated too high. To try and catch this, check if it was allocated higher than the kernel data address.

7. Change subsequent code from using constant ROM_BASE to variable ROMBase.


Changes to Other Programs
-------------------------
emul_op.cpp, main.cpp, name_registery.cpp, rom_patches.cpp, rsrc_patches.cpp, emul_ppc.cpp, sheepshaver_glue.cpp, ppc-translate-cpp:
Change from constant ROM_BASE to variable ROMBase.

ppc_asm.S: It was setting register to a hard-coded literal address: 0x40b0d000. Changed to set it to ROMBase + 0x30d000.

ppc_asm.tmpl: It defined a macro ASM_LO16 but it assumed that the macro would always be used with operands that included a register specification. This is not true. Moved the register specification from the macro to the macro invocations.

main_beos.cpp, main_windows.cpp: Since the subprograms are all expecting a variable ROMBase, all the main_*.cpp pgrams have to define and export it. The ROM_BASE constant is moved here for consistency. The mains for beos and windows just allocate the ROM at the same fixed address as before, set ROMBaseHost and ROMBase to that address, and then use ROMBase for the subsequent code.

cpu_emulation.h: removed ROM_BASE constant. This value is moved to the main_*.cpp modules, to be consistent with RAM_BASE.

user_strings_unix.cpp, user_strings_unix.h: Added new error messages related to errors that occur when the RAM and ROM are allocated anywhere.


Revision 1.23 - (view) (annotate) - [select for diffs]
Tue Jan 1 09:47:38 2008 UTC (6 years, 10 months ago) by gbeauche
Branch: MAIN
Changes since 1.22: +1 -1 lines
Diff to previous 1.22 , to selected 1.6
Happy New Year!


Revision 1.22 - (view) (annotate) - [select for diffs]
Sun Jan 21 17:21:23 2007 UTC (7 years, 10 months ago) by asvitkine
Branch: MAIN
Changes since 1.21: +8 -0 lines
Diff to previous 1.21 , to selected 1.6
Fix Master of Orion II


Revision 1.21 - (view) (annotate) - [select for diffs]
Mon May 8 23:32:58 2006 UTC (8 years, 6 months ago) by gbeauche
Branch: MAIN
Changes since 1.20: +20 -0 lines
Diff to previous 1.20 , to selected 1.6
Don't read from 0xf8000090 during MacOS (8.5, 9.0) installation. Is this an
OpenFirmware check for OldWorld 604-based machines?

XXX I have code pending that makes it possible to use PowerMac ID #3035 and
model 510 (PowerMac G3 Series). However, I have a regression with one of my
MacOS 8.6 disks. This is non-standard anyway since it was installed from the
iMac DV 8.6 discs ("yellow" not generic) with MOL -- SheepShaver can't cope
with it.

So I am not surprised it breaks. Otherwise, 8.5 -> 9.0.4 were fine with it.

BTW, the "regression" is Native Resource Manager is not installed and the
boot gets mad later. FWIW, it's the same as for MacOS 9.1. A resource is
very likely not loaded.


Revision 1.20 - (view) (annotate) - [select for diffs]
Sat May 6 09:23:28 2006 UTC (8 years, 6 months ago) by gbeauche
Branch: MAIN
Changes since 1.19: +18 -7 lines
Diff to previous 1.19 , to selected 1.6
Add 'nsrd' 1 and 'gpch' 650 patches for MacOS 7.5.3 Revision 2.2


Revision 1.19 - (view) (annotate) - [select for diffs]
Fri May 5 19:05:24 2006 UTC (8 years, 6 months ago) by gbeauche
Branch: MAIN
Changes since 1.18: +15 -23 lines
Diff to previous 1.18 , to selected 1.6
Review MacOS 8.6 vs 9.0 patches:
- 'boot' 3: set boot stack pointer only once at the correct place
- 'gpch' 750: fix FE0A opcode replacement (selector #$0a is virt2phys on pgidx)
- 'gpch' 750: remove bogus patch for SonyVars
- Mark patches "9.0" verified accordingly vs. 8.6


Revision 1.18 - (view) (annotate) - [select for diffs]
Wed May 3 21:53:33 2006 UTC (8 years, 6 months ago) by gbeauche
Branch: MAIN
Changes since 1.17: +16 -0 lines
Diff to previous 1.17 , to selected 1.6
Don't access ROM85 as it it was a pointer to a ROM version number (8.0, 8.1)
aka. fix bogus AppleShare extension, it was trying to dereference 0x3fff.

XXX: why is this code called in the first place?


Revision 1.17 - (view) (annotate) - [select for diffs]
Wed May 3 21:45:14 2006 UTC (8 years, 6 months ago) by gbeauche
Branch: MAIN
Changes since 1.16: +135 -0 lines
Diff to previous 1.16 , to selected 1.6
Add patches for native GetNamedResource() and Get1NamedResource(). This will
be useful to fix a bug in the AppleShare extension (see DRVR .AFPTranslator
in Basilisk II)

Unrelated improvement: call sheepshaver_cpu::get_resource() directly, don't
get it through another global function.


Revision 1.16 - (view) (annotate) - [select for diffs]
Sat Jul 2 17:51:43 2005 UTC (9 years, 4 months ago) by gbeauche
Branch: MAIN
Changes since 1.15: +6 -0 lines
Diff to previous 1.15 , to selected 1.6
Issue a SysError(dsOldSystem) if we are trying to use MacOS < 8.1.0 with a
NewWorld ROM. That may be 8.1.0 included but original iMac had a NewWorld
ROM compatible system.

Otherwise we will crash because the boot routine is trying to execute code
through unitialized descriptor that points to 0x13ff, which is obviously
wrong (and unaligned on word-boundaries for 68k code).


Revision 1.15 - (view) (annotate) - [select for diffs]
Sun Jan 30 21:48:19 2005 UTC (9 years, 9 months ago) by gbeauche
Branch: MAIN
Changes since 1.14: +1 -1 lines
Diff to previous 1.14 , to selected 1.6
Happy New Year 2005!


Revision 1.14 - (view) (annotate) - [select for diffs]
Sun Jan 30 17:39:44 2005 UTC (9 years, 9 months ago) by gbeauche
Branch: MAIN
Changes since 1.13: +16 -0 lines
Diff to previous 1.13 , to selected 1.6
workaround direct access to FCBS from Apple Personal Diagnostics in MacOS 9


Revision 1.13 - (view) (annotate) - [select for diffs]
Sun Dec 19 09:26:30 2004 UTC (9 years, 11 months ago) by gbeauche
Branch: MAIN
Changes since 1.12: +5 -0 lines
Diff to previous 1.12 , to selected 1.6
Don't overwrite our serial drivers (9.0)


Revision 1.12 - (view) (annotate) - [select for diffs]
Sat Nov 13 14:09:15 2004 UTC (10 years ago) by gbeauche
Branch: MAIN
Changes since 1.11: +39 -39 lines
Diff to previous 1.11 , to selected 1.6
Implement Direct Addressing mode similarly to Basilisk II. This is to get
SheepShaver working on OSes that don't support maipping of Low Memory globals
at 0x00000000, e.g. Windows.


Revision 1.11 - (view) (annotate) - [select for diffs]
Sun Jun 20 19:10:02 2004 UTC (10 years, 5 months ago) by gbeauche
Branch: MAIN
Changes since 1.10: +20 -1 lines
Diff to previous 1.10 , to selected 1.6
MacOS 9.0.4 support. ;-)


Revision 1.10 - (view) (annotate) - [select for diffs]
Mon Jan 26 22:04:01 2004 UTC (10 years, 10 months ago) by gbeauche
Branch: MAIN
Changes since 1.9: +23 -0 lines
Diff to previous 1.9 , to selected 1.6
Don't access VIA variables in NObj resource ID 100. aka. enable MacBench 5.0
to run.


Revision 1.9 - (view) (annotate) - [select for diffs]
Mon Jan 12 15:37:19 2004 UTC (10 years, 10 months ago) by cebix
Branch: MAIN
Changes since 1.8: +1 -1 lines
Diff to previous 1.8 , to selected 1.6
Happy New Year! :)


Revision 1.8 - (view) (annotate) - [select for diffs]
Sat Dec 27 09:08:51 2003 UTC (10 years, 11 months ago) by gbeauche
Branch: MAIN
Changes since 1.7: +8 -6 lines
Diff to previous 1.7 , to selected 1.6
audio fixes


Revision 1.7 - (view) (annotate) - [select for diffs]
Thu Dec 4 17:26:35 2003 UTC (10 years, 11 months ago) by gbeauche
Branch: MAIN
Changes since 1.6: +6 -5 lines
Diff to previous 1.6
Add new thunking system for 64-bit fixes.


Revision 1.6 - (view) (annotate) - [selected]
Mon Nov 10 14:18:34 2003 UTC (11 years ago) by gbeauche
Branch: MAIN
Changes since 1.5: +13 -13 lines
Diff to previous 1.5
little endian fixes


Revision 1.5 - (view) (annotate) - [select for diffs]
Mon Sep 29 22:48:22 2003 UTC (11 years, 2 months ago) by gbeauche
Branch: MAIN
Changes since 1.4: +27 -27 lines
Diff to previous 1.4 , to selected 1.6
More little endian fixes


Revision 1.4 - (view) (annotate) - [select for diffs]
Mon Sep 29 20:30:19 2003 UTC (11 years, 2 months ago) by gbeauche
Branch: MAIN
Changes since 1.3: +150 -147 lines
Diff to previous 1.3 , to selected 1.6
first round of little endian fixes


Revision 1.3 - (view) (annotate) - [select for diffs]
Sun Sep 7 14:33:51 2003 UTC (11 years, 2 months ago) by gbeauche
Branch: MAIN
Changes since 1.2: +42 -1 lines
Diff to previous 1.2 , to selected 1.6
- Integrate new NativeOp instructions to be used as trampolines to call
  native functions from ppc code.
- Little endian fixes in emul_op.cpp
- Add new 'gpch' 750 patch to workaround crash with MacOS 8.6
- Don't crash in Process Manager on reset/shutdown with MacOS 8.6
- We also have an experimental interrupt thread in emulation mode


Revision 1.2 - (view) (annotate) - [select for diffs]
Sat Apr 12 10:14:07 2003 UTC (11 years, 7 months ago) by gbeauche
Branch: MAIN
Changes since 1.1: +2 -0 lines
Diff to previous 1.1 , to selected 1.6
Make EmulOp() and check_load_invoc() extern "C" so that we are C++ name
mangling independent for asm_linux.S


Revision 1.1.1.1 - (view) (annotate) - [select for diffs] (vendor branch)
Mon Feb 4 16:58:13 2002 UTC (12 years, 9 months ago) by cebix
Branch: cebix
CVS Tags: start
Changes since 1.1: +0 -0 lines
Diff to previous 1.1 , to next main 1.24 , to selected 1.6
Imported sources


Revision 1.1 - (view) (annotate) - [select for diffs]
Mon Feb 4 16:58:13 2002 UTC (12 years, 9 months ago) by cebix
Branch: MAIN
Branch point for: cebix
Diff to selected 1.6
Initial revision


This form allows you to request diffs between any two revisions of this file. For each of the two "sides" of the diff, select a symbolic revision name using the selection box, or choose 'Use Text Field' and enter a numeric revision.

  Diffs between and
  Type of Diff should be a

Sort log by:

Christian Bauer">Christian Bauer
ViewVC Help
Powered by ViewVC 1.1.17