Commit Graph

781 Commits

Author SHA1 Message Date
asvitkine
b2d58d423e Fix compile problem with --enable-jit=no 2010-09-24 00:36:34 +00:00
asvitkine
bb627f28fe add braces around @interface declaration to compile with clang 2010-08-22 19:33:25 +00:00
asvitkine
14339fb01f add NULL return value to macho timer function 2010-08-22 19:31:36 +00:00
asvitkine
8a062fefdc fix printf safety warning 2010-08-22 18:57:11 +00:00
asvitkine
15b346b031 use setenv in preference of putenv 2010-08-22 18:56:11 +00:00
asvitkine
e03ad25362 Fixed for Snow Leopard build. 2010-07-27 03:14:34 +00:00
asvitkine
0973ee0e16 Fix compile on Snow Leopard. 2010-07-27 02:57:10 +00:00
asvitkine
da828ffc73 Fix prefs_macosx.mm compile issue with Snow Leopard. 2010-07-27 02:55:09 +00:00
asvitkine
efad3ba70a use linked list for timers to avoid running out of descriptors 2010-05-05 00:29:46 +00:00
asvitkine
614b33bcd8 [Joel Mauras]
Let makefile build relatives links between SheepShaver and BasiliksII so
they can be moved anywhere into the file system as long as they stay side
by side without having to rebuid the links.
2010-04-08 03:50:26 +00:00
asvitkine
78027e7a46 [Amadeusz Slawinski]
These patches fix the issues with using newer versions of autoconf,
which led to generating broken configure script.
2010-03-07 00:45:10 +00:00
asvitkine
b3c5b07f54 fix more platform compile failures caused by refactoring, based
on patch by Amadeusz Sławiński
2010-03-02 00:37:17 +00:00
cebix
4f28f70207 fixed warnings 2010-02-21 09:59:52 +00:00
cebix
c6a52b6eb2 fixed const-ness 2010-02-21 09:59:14 +00:00
cebix
23b0bda1a5 fixed const-ness and compiler warnings 2010-02-21 09:58:47 +00:00
asvitkine
2b03c79d48 fix dyngen.c breakage on non-MACHO platforms 2010-01-15 01:47:17 +00:00
asvitkine
5ca84603bc [ Tim Douglas <timdoug@gmail.com> ]
use an auto release pool around "Preferences..." menu item creation on Mac OS X
2010-01-02 22:08:51 +00:00
asvitkine
6677e5824c [ Tim Douglas <timdoug@gmail.com> ]
use an auto release pool around modal prefs dialog on Mac OS X
2010-01-02 19:24:24 +00:00
asvitkine
8e1a2f7f48 use correct variable name 2009-11-19 02:07:44 +00:00
asvitkine
ded367a176 [ Patch from Jean-Pierre <chombier@free.fr> ]
More changes to support mach-o x86_64.
2009-11-13 01:46:35 +00:00
asvitkine
f4705aa5e1 code whitespace cleanup and patch_relocations() function 2009-11-08 19:11:02 +00:00
asvitkine
df4aef1fba [ Patch from Jean-Pierre <chombier@free.fr> ]
Dyngen patch for Snow Leopard x86_64 compatibility.
This work is mostly based on the unofficial and incomplete x86_64 mach-o patch of qemu.
2009-11-08 18:16:31 +00:00
asvitkine
3856561935 Fix builds on platforms that may have gotten broken due to my vmdir changes. 2009-09-21 03:34:14 +00:00
asvitkine
c294074fa7 Launcher: Check if file exists. 2009-08-31 05:08:21 +00:00
asvitkine
63b4f8d704 better default prefs 2009-08-30 17:56:30 +00:00
asvitkine
f06f035428 Launcher: Renaming VMs in list. 2009-08-26 07:09:06 +00:00
asvitkine
868bb283d2 [Michael Schmitt]
Attached is a patch to SheepShaver, to fix a problem where the ROM file can only be found on the first boot.

When a user creates a new SheepShaver machine, there is no preference file, so there is not ROM path preference. SheepShaver has logic so that in this case, it will look for a ROM file named "ROM" or "Mac OS ROM" in the current directory.

The user starts SheepShaver in order to get to the built-in Preferences Editor, and changes various settings (such as creation of a hard disk). Then the user reboots.

If the user forgot to set the ROM path at this time, then SheepShaver can no longer boot. The only recourse is for the user to find and delete the preferences file, or use an external preferences editor to set the ROM path.

The fix is to change SheepShaver to use the default ROM names when either the rom path is null (no preference) OR an empty string (preference exists with no rom path).
2009-08-26 00:11:56 +00:00
asvitkine
0075c1faab [Michael Schmitt]
Attached is a patch to SheepShaver, to fix a SIGSEGV crash that occurs when booting a new machine with OS 7.5.

One of the bytes in the xPRAM portion of the NVRAM controls which version of the system memory manager is used by OS 7.5: the legacy 680x0 memory manager or the PPC memory manager (aka the "Modern Memory Manager"). OS 7.5 is supposed to be able to use either one, but for some reason SheepShaver crashes on boot if the 680x0 version is used.

Later Mac OS versions don't have this problem. They don't support the 680x0 version, so they force the PPC version to be used.

The fix is to have SheepShaver initialize the NVRAM to use the PPC memory manager. Note: This is supposed to be the default in OS 7.5.

This affects when a new NVRAM file is used, or when it is initialized after doing zapping the PRAM.
2009-08-26 00:06:29 +00:00
asvitkine
53e416c4b7 Fix position of "browse" button for keycodes file when resizing prefs window 2009-08-18 18:30:19 +00:00
asvitkine
b3b5db5456 [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.
2009-08-18 18:26:11 +00:00
asvitkine
3867b28037 load the VMSettingsWindow nib for prefs window in SheepShaver 2009-08-18 18:22:01 +00:00
asvitkine
c465e7239e Launcher: Use default settings from NIB for new VM. 2009-08-18 03:42:11 +00:00
asvitkine
bc7b9a6c4a MacOSX: Use the prefs editor from the Launcher project. 2009-08-18 03:27:50 +00:00
asvitkine
3e7168c78d allow settings controller to work in non-standalone mode 2009-08-18 03:26:17 +00:00
asvitkine
a98f16a1bd support both foo.sheepvm and foo.sheepvm/ command-line parameters 2009-08-18 02:36:59 +00:00
asvitkine
5a8dfa1b36 [Charles Srstka]
Attached is a set of patches to port the precise timer that is currently used in the Linux and BeOS builds of SheepShaver to Mac OS X (and any other Mach-based operating systems).

Currently, the Linux build uses the clock_gettime() function to get nanosecond-precision time, and falls back on gettimeofday() if it is not present. Unfortunately, Mac OS X does not currently support clock_gettime(), and gettimeofday() has only microsecond granularity. The Mach kernel, however, has a clock_get_time() function that does very nearly the same thing as clock_gettime(). The patches to BasiliskII cause the timing functions such as timer_current_time() to use clock_get_time() instead of gettimeofday() on Mach-based systems that do not support clock_gettime().

The changes to SheepShaver involve the precise timer. The existing code for Linux uses pthreads and real-time signals to handle the timing. Mac OS X unfortunately does not seem to support real-time signals, so Mach calls are again used to suspend and resume the timer thread in order to attempt to duplicate the Linux and BeOS versions of the timer. The code is somewhat ugly right now, as I decided to leave alone the pre-existing style of the source file, which unfortunately involves #ifdefs scattered throughout the file and some duplication of code. A future patch may want to clean this up to separate out the OS-specific code and put it all together at the top of the file. However, for the time being, this seems to work.

This has not been extensively tested, because I have not been able to get my hands on a good test-case app for the classic Mac OS that would run inside the emulator and try out the timer. However, performance does seem to be better than with the pre-existing code, and nothing seems to have blown up as far as I can tell. I did find a game via a Google search -  Cap'n Magneto - that is known to have problems with Basilisk/SheepShaver's legacy 60 Hz timer, and the opening fade-to-color for this game appears to run much more smoothly with the precise timer code in place.
2009-08-17 20:44:30 +00:00
asvitkine
8ac0507a39 re-arrange virtual machines by drag and drop
add a contextual menu that also allows to
reveal the selected virtual machine in finder
2009-08-12 02:18:19 +00:00
asvitkine
fbef7bcf22 more improvements to Launcher 2009-08-06 18:12:25 +00:00
asvitkine
7004db923a allow looking inside bundles and default disk location to inside bundle 2009-08-06 06:42:43 +00:00
asvitkine
61770c58eb keep track of running VMs 2009-08-02 23:46:44 +00:00
asvitkine
b67b983156 disable buttons when no selection 2009-08-02 23:17:18 +00:00
asvitkine
abbd1785b1 delete vm from list 2009-08-02 22:37:34 +00:00
asvitkine
b38bb12ab3 New Virtual Machine button working 2009-08-02 20:24:38 +00:00
asvitkine
820ae8100c misc changes 2009-08-02 19:51:15 +00:00
asvitkine
d38c755204 Launching VMs 2009-08-02 18:59:26 +00:00
asvitkine
07a2d906c4 add icon to launcher 2009-08-02 18:42:06 +00:00
asvitkine
e8e5440b31 initial import of SheepShaver Launcher project for Mac OS X (WIP) 2009-08-02 18:34:57 +00:00
asvitkine
80a7589e29 only if standalone 2009-08-01 15:31:54 +00:00
asvitkine
743888f407 fix PrefsEditor build 2009-08-01 15:31:31 +00:00
asvitkine
5cef748ac7 only "continue previous delay" if delay is 0 2009-08-01 07:02:41 +00:00