Commit Graph

2136 Commits

Author SHA1 Message Date
nigel
4ab9ed8863 Allow linking after prefs API changes from 3 months ago. 2009-11-06 21:33:03 +00:00
asvitkine
02313b55c2 [Joel Mauras]
Patch for network suppor on 2.6 Linux Kernel.
2009-10-20 01:55:03 +00:00
asvitkine
bc6d6caec6 fix PrefsInit on amiga 2009-10-18 16:21:19 +00:00
asvitkine
14a68c2468 trying to get slightly better clip behaviour - swap the data back after
giving it to the host OS, and don't clear clipboard every time as some
apps will put many varieties of the same data in succession...
however, a better fix would be to patch the ROM ZeroScrap function in a
similar way as we patch GetScrap/PutScrap
2009-10-18 01:22:33 +00:00
nigel
5d4fa37892 Another build fix for changed Prefs methods 2009-10-08 09:20:51 +00:00
nigel
29951ad1a5 Re-synch with latest main_unix.cpp to work around method changes in LoadPrefs()
and PrefsInit(). Fixes build error reported by Jean-Jacques Cortes.
2009-10-08 08:56:23 +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
cb55b15d39 Change #include <mach/mach_host.h> to #include <mach/mach.h> 2009-08-21 17:39:58 +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
c6d88f213c [Michael Schmitt]
SheepShaver includes the C errno string in many error messages. One case is when it calls the memory allocation routines in the Basilisk II vm_alloc.cpp program.

This works when the memory allocation routine uses functions that set errno (such as mmap or malloc). For example, running SheepShaver on a Linux hosts produces meaningful error messages.

The problem is that when run on an OS X host, the memory allocation uses Mach routines such as vm_allocate, which do not set errno.

So when SheepShaver reported the error, it used a stale value of errno, which happened to be 17. The result was an extremely misleading error message: "Cannot map RAM: File already exists".

The fix is to change vm_alloc so that it translates Mac return codes into POSIX errno values.

It also initializes errno to 0 at the start of the memory allocation routine, so that no matter what path it takes, it won't return a stale value.
2009-08-11 07:43:46 +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
asvitkine
ccdb8ab3c0 correct implementation of PrimeTime(0) 2009-07-31 20:43:28 +00:00
asvitkine
57b64245ad handle one case of PrimeTime(0) 2009-07-31 19:41:50 +00:00
asvitkine
d0c46de7c3 BasiliskII side of changes to support .sheepvm bundles for SheepShaver 2009-07-23 19:19:14 +00:00
asvitkine
5b958defa7 support for .sheepvm bundles on macosx, containing "prefs" and "nvram" files 2009-07-23 19:12:51 +00:00
asvitkine
581ff8d86f add prefs option to ignore illegal instructions (ignoreillegal) 2009-07-20 18:50:28 +00:00
asvitkine
6db0c7453b [Patch by Kelvin Delbarre]
Fixes copy/paste errors in the Windows version of SheepShaver, wherein pasted
text would have a trailing null character or extra garbage after the end.
2009-04-14 15:17:03 +00:00
asvitkine
9c8387f8d0 more syncing 2009-04-14 00:52:15 +00:00
asvitkine
f2630f5e6a sync Makefile.in with Unix version 2009-04-14 00:36:13 +00:00
asvitkine
7fc0d3137b syncing Windows configure.ac file with the unix one 2009-04-14 00:17:56 +00:00
asvitkine
8ad0bbcc80 windows fix try#2 2009-04-13 23:13:20 +00:00
asvitkine
abb9d2eb24 make sigsegv work better with cygwin 2009-04-13 19:57:08 +00:00
asvitkine
fceeb39d3c Restore OSX built-in prefs editor. Change the configure.ac check for
no_x to WANT_GTK=no since X may be installed when building on OS X,
but we probably don't want it!
2009-03-18 16:09:15 +00:00
asvitkine
b6f9f38f98 [patch by Dave Vasilevsky]
Fix for bug: SheepShaver compiled with VOSF off will not display
fullscreen on OS X. The VM boots, but the display is entirely black.
This was expected, I suppose, since video_refresh_dga() didn't
actually attempt to draw anything!

The patch fixes this. Notes:
* video_refresh_window() now takes an argument of type driver_base,
since nothing specific to driver_window was used
* video_refresh_dga() can now call video_refresh_window_static()
* update_display_static_bbox() now respects the destination having a
different bytes-per-row from the source
* fullscreen modes are now created for all depths
2009-03-03 08:14:53 +00:00
asvitkine
da540a74f6 [patch by Mike Sliczniak]
Here is a patch to allow compiling of SS and B2 with an SDL Framework. You can
get this by downloading from:

http://www.libsdl.org/release/SDL-1.2.13.dmg

Here is how I tested on an intel 32-bit mac with Mac OS X 10.5.6:

SS ./autogen.sh --disable-standalone-gui --enable-vosf --enable-sdl-framework --enable-sdl-framework-prefix=/Users/mzs/Library/Frameworks --enable-sdl-video --disable-sdl-audio --enable-addressing=real
--without-esd --without-gtk --without-mon --without-x

SS /autogen.sh --disable-standalone-gui --enable-vosf --disable-sdl-framework --disable-sdl-video --disable-sdl-audio --enable-addressing=real --without-esd --without-gtk --without-mon --with-x

B2 ./autogen.sh --disable-standalone-gui --enable-vosf --enable-sdl-framework --enable-sdl-framework-prefix=/Users/mzs/Library/Frameworks --enable-sdl-video --enable-sdl-audio --enable-addressing=real --without-esd --without-gtk --without-mon --without-x --enable-jit-compiler

B2 ./autogen.sh --disable-standalone-gui --enable-vosf --disable-sdl-framework --disable-sdl-video --disable-sdl-audio --enable-addressing=real --with-esd --without-gtk --without-mon --with-x --enable-jit-compiler

(esound does not really work on mac, it needs some better coreaudio patches.)

configure.ac for SS has two little additional fixes so that the Cocoa prefs gui
does not get built if you are building for X11 and so that you can use esd, sdl,
or coreaudio for sound.
2009-03-03 08:07:22 +00:00