* The code was hardwired for 8-bit mode, unplug that and set it up for
32bit mode (much simpler).
* You need a ROM that supports 32bit mode for now
* Mode switching not supported yet.
* 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
We want to have just one base driver that can handle both fullscreen and
windowed mode, so that we can easily switch between modes.
Create a virtual init() method to do construction, so we can move common code
from the derived classes into the base init().
Issue: https://github.com/cebix/macemu/issues/26
On non-Mac platforms, driver_fullscreen constructor sets up software cursor,
but switch_to_current_mode() ask for a hardware cursor, possibly due to a typo.
Neither one ends up being drawn, so the cursor goes invisible.
This change makes them agree to use a software cursor. We should eventually
move to just one place deciding which cursor to use, so they don't have to be
kept in sync.
Port forwarding allows the emulator to host servers that can be
accessed from outside the virtual network.
The code for parsing the preference option "redir" is adapted from
qemu code. The rest was already implemented.
This patch introduces a few changes:
1. Data of arbitrary Mac OS types which aren't handled (i.e. non text/picture types) will now be passed through to the host pasteboard, just like in the 32-bit code.
2. Reorganization of a few things.
3. Fixed a memory leak (whoops).
I'm basically submitting this patch now because I have a few other changes I'm going to try, but since I'm not sure that they're going to work, I thought it better to flush out the changes I've already made at this point first.
Thanks,
Charles
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
./configure --enable-macosx-gui
The goal is to get rid of the build files under src/MacOSX by
allowing the ones under src/Unix to produce the same outputs.
Note: This currently has video problems, but this is consistent
with what you get when building out of src/MacOSX.
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
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.
thread is currently only used to poll for CDROM devices and is not useful
when "nocdrom" is set. This change also fixes the problem of the emulator
preventing the CD to be ejected at the host level despite "nocdrom" being
set in prefs.
Thanks to Robert Munafo <mrob27@gmail.com> for investigating this problem!
| This patch affects the Makefile.in used to compile Basilisk II in
| order to allow out-of-tree compilation. This is useful for building
| multiple flavours of the Debian package.
|Author: Giulio Paci <giuliopaci@gmail.com>
| This patch fix a compiler warning about the direct printing of strings
| using formatted printing functions without the use of a format string.
|Author: Giulio Paci <giuliopaci@gmail.com>
|Forwarded: no
|Last-Update: 2012-03-04
version of slirp (where this code comes from), with the following checkin:
commit 2f5f89963186d42a7ded253bc6cf5b32abb45cec
Author: aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
Date: Mon Jan 26 19:37:41 2009 +0000
Remove the advertising clause from the slirp license
According to the FSF, the 4-clause BSD license, which slirp is covered under,
is not compatible with the GPL or LGPL[1].
[1] http://www.fsf.org/licensing/licenses/index_html#GPLIncompatibleLicenses
There are three declared copyright holders in slirp that use the 4-clause
BSD license, the Regents of UC Berkley, Danny Gasparovski, and Kelly Price.
Below are the appropriate permissions to remove the advertise clause from slirp
from each party.
Special thanks go to Richard Fontana from Red Hat for contacting all of the
necessary authors to resolve this issue!
Regents of UC Berkley:
From ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change
July 22, 1999
To All Licensees, Distributors of Any Version of BSD:
As you know, certain of the Berkeley Software Distribution ("BSD") source
code files require that further distributions of products containing all or
portions of the software, acknowledge within their advertising materials
that such products contain software developed by UC Berkeley and its
contributors.
Specifically, the provision reads:
" * 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* This product includes software developed by the University of
* California, Berkeley and its contributors."
Effective immediately, licensees and distributors are no longer required to
include the acknowledgement within advertising materials. Accordingly, the
foregoing paragraph of those BSD Unix files containing it is hereby deleted
in its entirety.
William Hoskins
Director, Office of Technology Licensing
University of California, Berkeley
Danny Gasparovski:
Subject: RE: Slirp license
Date: Thu, 8 Jan 2009 10:51:00 +1100
From: "Gasparovski, Daniel" <Daniel.Gasparovski@ato.gov.au>
To: "Richard Fontana" <rfontana@redhat.com>
Hi Richard,
I have no objection to having Slirp code in QEMU be licensed under the
3-clause BSD license.
Thanks for taking the effort to consult me about this.
Dan ...
Kelly Price:
Date: Thu, 8 Jan 2009 19:38:56 -0500
From: "Kelly Price" <strredwolf@gmail.com>
To: "Richard Fontana" <rfontana@redhat.com>
Subject: Re: Slirp license
Thanks for contacting me, Richard. I'm glad you were able to find
Dan, as I've been "keeping the light on" for Slirp. I have no use for
it now, and I have little time for it (now holding onto Keenspot's
Comic Genesis and having a regular US state government position). If
Dan would like to return to the project, I'd love to give it back to
him.
As for copyright, I don't own all of it. Dan does, so I will defer to
him. Any of my patches I will gladly license to the 3-part BSD
license. My interest in re-licensing was because we didn't have ready
info to contact Dan. If Dan would like to port Slirp back out of
QEMU, a lot of us 64-bit users would be grateful.
Feel free to share this email address with Dan. I will be glad to
effect a transfer of the project to him and Mr. Bellard of the QEMU
project.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6451 c046a42c-6fe2-441c-8c8c-71466251a162
version of slirp (where this code comes from), with the following checkin:
commit 2f5f89963186d42a7ded253bc6cf5b32abb45cec
Author: aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
Date: Mon Jan 26 19:37:41 2009 +0000
Remove the advertising clause from the slirp license
According to the FSF, the 4-clause BSD license, which slirp is covered under,
is not compatible with the GPL or LGPL[1].
[1] http://www.fsf.org/licensing/licenses/index_html#GPLIncompatibleLicenses
There are three declared copyright holders in slirp that use the 4-clause
BSD license, the Regents of UC Berkley, Danny Gasparovski, and Kelly Price.
Below are the appropriate permissions to remove the advertise clause from slirp
from each party.
Special thanks go to Richard Fontana from Red Hat for contacting all of the
necessary authors to resolve this issue!
Regents of UC Berkley:
From ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change
July 22, 1999
To All Licensees, Distributors of Any Version of BSD:
As you know, certain of the Berkeley Software Distribution ("BSD") source
code files require that further distributions of products containing all or
portions of the software, acknowledge within their advertising materials
that such products contain software developed by UC Berkeley and its
contributors.
Specifically, the provision reads:
" * 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* This product includes software developed by the University of
* California, Berkeley and its contributors."
Effective immediately, licensees and distributors are no longer required to
include the acknowledgement within advertising materials. Accordingly, the
foregoing paragraph of those BSD Unix files containing it is hereby deleted
in its entirety.
William Hoskins
Director, Office of Technology Licensing
University of California, Berkeley
Danny Gasparovski:
Subject: RE: Slirp license
Date: Thu, 8 Jan 2009 10:51:00 +1100
From: "Gasparovski, Daniel" <Daniel.Gasparovski@ato.gov.au>
To: "Richard Fontana" <rfontana@redhat.com>
Hi Richard,
I have no objection to having Slirp code in QEMU be licensed under the
3-clause BSD license.
Thanks for taking the effort to consult me about this.
Dan ...
Kelly Price:
Date: Thu, 8 Jan 2009 19:38:56 -0500
From: "Kelly Price" <strredwolf@gmail.com>
To: "Richard Fontana" <rfontana@redhat.com>
Subject: Re: Slirp license
Thanks for contacting me, Richard. I'm glad you were able to find
Dan, as I've been "keeping the light on" for Slirp. I have no use for
it now, and I have little time for it (now holding onto Keenspot's
Comic Genesis and having a regular US state government position). If
Dan would like to return to the project, I'd love to give it back to
him.
As for copyright, I don't own all of it. Dan does, so I will defer to
him. Any of my patches I will gladly license to the 3-part BSD
license. My interest in re-licensing was because we didn't have ready
info to contact Dan. If Dan would like to port Slirp back out of
QEMU, a lot of us 64-bit users would be grateful.
Feel free to share this email address with Dan. I will be glad to
effect a transfer of the project to him and Mr. Bellard of the QEMU
project.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6451 c046a42c-6fe2-441c-8c8c-71466251a162
For my work on digital preservation it's important to have "golden"
disk images that are not corrupted by user action. In order to enable
this, I've added support for VHD virtual disks (especially snapshots !)
to the Linux and OS X versions of BasiliskII and SheepShaver.
The support uses the open source libvhd library which is part of xen,
available here:
http://www.xen.org/products/xen_source.html
The piece that's needed is libvhd which is in tools/blktap2 and it can
be separately compiled.
The vhd-util enables creation of vhd disks and snapshots.
Compiling libvhd for OS X is non-trivial and required 1) a new config
and 2) a number of small changes to the include files and c files.
Compiling for linux is a snap.
I use this as follows.
1) create my "golden image" gold.dsk in the usual way
2) create a snapshot: vhd-util snapshot -n gold.vhd -p gold.dsk -m
3) use the snapshot in my prefs file
In my work the golden images are in an AFS system which means the golden
images can reside at "universal" addresses. The snapshots are initially
tiny, so a complete virtual machine configuration -- prefs + snapshot is
quick to download for the end user.
The snapshots are copy on write which has the pleasant side effect of
letting the end user keep any changes.
This attached patch allows you to compile the Carbon Pasteboard services on
Snow Leopard if you are building for 32-bit, but not if you are building for 64.
To maintain backwards compatibility, the Carbon UI APIs aren't going to be
stripped from the 32-bit any time soon. However, there is no worry about
that in 64, so they didn't include it.
Add bin/cue support. The following should work:
1) Basilisk and SheepShaver with sdl-audio and bincue on linux and os x
2) SheepShaver with bincue and core audio on os x
GCC has become too smart - we need to slice the binary created to be sure the
address of the trap is within the test addresses. This is why each trap occurs
between two case labels and a new section of assembly code is set in between.
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
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.
