GCC 5 will optimize out an empty 'asm volatile' in op_sraw_T0_T1, and then give us multiple return points. Add a nop so it doesn't do this, at the cost of lower code density.
* Disable -freorder-blocks-and-partition, since it can override -fno-reorder-blocks
* Disable look-header copying, since it tends to cause early returns
* Disable argument pushing, we don't want to change esp
* Look for CPU named "amd64" as well as "x86_64"
* Don't use /dev/ptmx on FreeBSD
* On amd64 FreeBSD uses SIGSEGV, not SIGBUS
* Use MAP_FIXED to force allocations within 32-bits, it's the only way
* Need <sys/param.h> for SHMLBA
* The old offsetof() fix is no longer needed
* Preliminary work on instruction skipping
This patch fixes one lingering problem with the 64-bit clipboard code; the way it was designed, the Mac clipboard was being cleared every time a single item was being requested by GetScrap, causing clipboards with multiple items to be unceremoniously whittled down to one. On the other hand, a similar issue was causing some items to get duplicated on the host pasteboard. This patch fixes the issue by making conversion between the host pasteboard and the Mac clipboard a singular operation; when the pasteboard data changes on the host side, it is all converted and sent to the Mac pasteboard at once, and similarly, all Mac clipboard data is sent to the host pasteboard in one operation. Also, data from the host side is copied to the Mac clipboard only if it has changed since the last check, which should improve performance as conversions will not be done over and over every time the Mac side checks whether the scrap has changed.
In addition, I've added a rudimentary PICT converter. It's rudimentary at the moment, only going in one direction, converting to PICT and not from PICT, and currently it always rasterizes the source image and creates a PICT containing bitmap data. However, it's a start, and it should solve Ronald's issue with copying images from OS X to Mac OS. In the future, more could possibly be added. I've put the new PICT code in the main source directory instead of in the MacOSX subdirectory, so that it can be used by other platforms if needed.
I would like to leave the license on the new PICT code as "Public Domain" if that is okay.
Thanks,
Charles
This patch adds support for international text to Basilisk II / SheepShaver's clipboard support. Text copied on the host side is converted from Unicode to the format that the classic Mac OS Script Manager expects, with localized font variants used if they are available on the emulated system (unfortunately, if a localized font is not available, the text will render incorrectly due to the nature of the Script Manager). When text is copied on the emulated system, the script of the current font is used to determine the encoding of the text, and it is converted to Unicode to be pasted on the host side.
This patch supports copying and pasting text containing multiple scripts; for example, "EnglishČeský日本語", where ranges (0, 7) and (8, 3) are Roman, (7, 1) and (11, 1) are Central European, and (12, 3) is Japanese, can be freely copied and pasted back and forth between the host and emulated platforms, provided that the emulated platform has localized Central European and Japanese fonts installed.
In order to get this to work, I rewrote pretty much all of clip_macosx64.mm. The code now completely uses the Cocoa framework rather than CoreFoundation and Pasteboard Manager. Because this API now uses the Mac OS X 10.6+ version of the pasteboard API, the minimum version of OS X supported by clip_macosx64.mm is now 10.6. I think this shouldn't be a problem, since the 32-bit version still exists, but if this version needs to support older releases, let me know and I can add version-check code to do so. One of the benefits of using the modern API, however, is that our rich-text format is no longer hard-coded to the RTF format, which means we have automatic support for any other format used by the OS X pasteboard system, which as of Lion seems to include RTF, UTF-16 text, UTF-8 text, 'ut16'/'ustl', and others, and which may be supplemented by other formats in future releases of OS X.
I hope you find this patch useful.
Charles
Added code to parse the Classic Mac OS 'styl' resources, allowing formatted text to be copied and pasted out of SheepShaver, not just plain text. In order to do this, I made some changes to the emul_op mechanism, patching ZeroScrap() in addition to the scrap methods that were already being patched. The reason for this is that since we need to read data from multiple items that are on the clipboard at once, we cannot simply assume a zero at the beginning of each PutScrap() operation.
This patch uses RTF to store styled text on the host side; unfortunately, since the APIs to convert to and from RTF data are in Cocoa but not in CoreFoundation, I had to write the new portions in Objective-C rather than C, and changed the extension from .cpp to .mm accordingly. In the future, if we are confident that this file will only be used on Mac OS X 10.6 and up, we can rewrite the Pasteboard Manager code to use NSPasteboardReading/Writing instead. This would allow us to read and write NSAttributedString objects directly to and from the pasteboard, which would make sure we were always using the OS's preferred rich text format internally instead of hard-coding it specifically to RTF as in the current implementation.
I believe that this patch should also fix the problem Ronald reported with copying accented characters.
Since I am new to 68k assembly and the emul_op mechanism, I would appreciate if someone could double-check all my changes to make sure that I have done everything correctly.
Thanks,
Charles
In file included from ../kpx_cpu/sheepshaver_glue.cpp:32:
In file included from ../kpx_cpu/src/cpu/ppc/ppc-cpu.hpp:24:
../kpx_cpu/include/basic-cpu.hpp:50:1: warning: struct 'task_struct' was previously declared as a class [-Wmismatched-tags]
struct task_struct;
^
../kpx_cpu/include/task-plugin.hpp:27:7: note: previous use is here
class task_struct;
^
In file included from ../kpx_cpu/sheepshaver_glue.cpp:32:
In file included from ../kpx_cpu/src/cpu/ppc/ppc-cpu.hpp:24:
../kpx_cpu/include/basic-cpu.hpp:52:1: warning: 'basic_cpu' defined as a struct here but previously declared as a class [-Wmismatched-tags]
struct basic_cpu
^
../kpx_cpu/include/task-plugin.hpp:29:1: note: did you mean struct here?
class basic_cpu;
^~~~~
struct
../kpx_cpu/sheepshaver_glue.cpp:725:13: warning: unused function 'dump_log' [-Wunused-function]
static void dump_log(void)
^
3 warnings generated.
Note: Checks for __LP64__ explicitly because build/host/target
all get reported as i686-apple-darwin10.8.0 (not x86_64).
Also fixes a compile warning in clip_macosx64.cpp.
+ Running autoheader: configure.ac:1393: warning: AC_CACHE_VAL(ac_cv_gcc_no_strict_aliasing, ...): suspicious presence of an AC_SUBST in the second argument, where no actions should be taken
4fb0f92aaf065276712a36cb169081ebc41eeeb4
From: Alexander von Gluck IV <kallisti5@unixzen.com>
Date: Sun, 17 Jun 2012 03:47:26 +0000
Subject: [PATCH] Haiku: Fix missing ;
28ff27fc3ae3878fe9ca589f3c55c4261814266a
From: Steven Noonan <steven@uplinklabs.net>
Date: Wed, 1 Jun 2011 01:34:07 -0700
Subject: [PATCH] configure.ac: fix TUN/TAP detection on Linux
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
d4dc0c70b24dc5981e752403e8fe047637d712a1
From: Steven Noonan <steven@uplinklabs.net>
Date: Wed, 1 Jun 2011 17:48:33 -0700
Subject: [PATCH] configure.ac: enable JIT on 64-bit Intel Mac
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
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.
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).
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.
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.
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.
