uvmac/docs/change/v3.5.html
2020-03-14 15:28:01 -04:00

1 line
20 KiB
HTML

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title> Changes in Mini vMac 3.5.8 </title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="canonical" href="v3.5.html">
</head>
<body>
<div>
<i> <a href="https://www.gryphel.com/index.html">www.gryphel.com</a>/c/<a href="../index.html">minivmac</a>/<a href="index.html">change</a>/v3.5
- <a href="https://www.gryphel.com/c/feedback.html">feedback</a> </i>
</div>
<hr>
<h3 align=center>
Mini vMac 3.5.8 <!-- *<i>Beta</i>* -->
</h3>
<h3 align=center>
Changes
</h3>
<hr>
<p> What has changed in Mini vMac 3.5.8, compared to Mini vMac 3.4.1.
This only lists changes that affect behavior, and so doesn't
include cleanups of the source code. </p>
<p> : </p>
<p>
default compile:
</p>
<blockquote>
<p>
<a href="v3.5.html#feature">New features</a>
</p><p>
<a href="v3.5.html#modified">Changed behavior</a>
</p><p>
<a href="v3.5.html#bugs">Bug fixes</a>
</p>
</blockquote>
<p>
not in default compile:
</p>
<blockquote>
<p>
<a href="v3.5.html#compile_feature">New features</a>
</p><p>
<a href="v3.5.html#compile_modified">Changed behavior</a>
</p><p>
<a href="v3.5.html#compile_bugs">Bug fixes</a>
</p>
</blockquote>
<p>
<a href="v3.5.html#build">Build System</a>
</p>
<p> : </p>
<p> <a name="feature"> <b> New features in default compile </b> </a> </p>
<!-- A new feature is something you would not notice if you used
Mini vMac as you used it previously. If using it as you would previously
would behave differently, that is "changed behavior". -->
<!--
-->
<p> * None Yet. </p>
</p>
<p> <a name="modified"> <b> Changed behavior in default compile </b> </a> </p>
<!--
<p> * None Yet. </p>
-->
<p> *
Mini vMac should be faster on machines that aren&rsquo;t PowerPC or
x86-32. (And also Macintosh II emulation should be faster.)
The C version of the 680x0 CPU emulation was optimized to
be about as fast as the previous assembly code (that was only
implemented for 68000 emulation on PowerPC and x86-32), and then
the assembly code was removed. So Mini vMac should be much
faster for variations where the old assembly code could not be used.
Also, the x86-64 version is now faster than the old x86-32 assembly,
and so is now preferred on machines that can run both x86-64 and x86-32.
(On OS X, various bug fixes should make the Cocoa port now work as
well as Carbon port, which wasn&rsquo;t available on x86-64.)
The C code is tweaked for a specific version of the GCC compiler.
While other compilers are still supported, they can result in
significantly slower emulation.
</p>
<p> *
If Mini vMac reports an &ldquo;Abnormal Situation&rdquo;, it now
also displays a 4 digit hexadecimal number. The original idea was
that if something unexpected happens, you should first figure out how
to reproduce the problem. Then the same thing can be done on a copy
of Mini vMac with debugging stuff enabled. But this idea
doesn&rsquo;t work out so well if the problem can&rsquo;t be
reproduced, and seems to happen randomly and rarely. So now the
non debug version of Mini vMac will display a number, which
doesn&rsquo;t take much code, so at least something can be learned.
</p>
<p> <a name="bugs"> <b> Bug fixes in default compile </b> </a> </p>
<!--
<p> * None Yet. </p>
-->
<p> *
A badly behaved program could cause Mini vMac to crash, attempting to
fetch an emulated instruction from random memory, which memory
protection on a modern computer prevents. Since this is only a bad read,
I don&rsquo;t think any further harm was possible besides crashing Mini vMac.
Most kinds of memory access emulated by Mini vMac have for a quite while
been designed to always be accurate and safe. But for speed,
fetching the next instruction would simply increment a pointer to where
the instruction is in real memory, and relative branches would just
offset this pointer. Only for certain long branches would Mini vMac work
out from scratch where the instruction is in real memory. This is good
enough for all known correctly working software. But it is in theory
possible to write code so that the pointer to the next instruction gets
set to arbitrary memory that the operating system may not allow Mini
vMac to access, resulting in a crash. And not just in theory, I have
seen this happen in programs running in Mini vMac that were
malfunctioning. This bug is fixed by keeping low and high limits for
the instruction pointer, and checking against them as the pointer is
changed.
</p>
<p> *
There is now some testing code that scrambles the mapping between
emulated memory (for RAM and ROM) and real memory, splitting
it into two sets of interleaved blocks (in effect toggling
one bit of the address). Which exercises all the new
boundary checking code. With a number of bug fixes it all worked.
</p>
<p> *
In the Cocoa port, entering Full Screen should now work in
recent versions of OS X, instead of immediately exiting. For
safety Mini vMac automatically leaves full screen mode if it notices
the screen size has changed, implemented in the Cocoa port by
looking for the notification applicationDidChangeScreenParameters.
But recent OS X gives this notification on entering Full Screen
mode, when it didn&rsquo;t used to. So the Cocoa now records the main
screent Rect, and only exits full screen mode if it has changed.
This problem was
<a href="https://www.gryphel.com/c/mail/v3.html#m61">reported by Tim</a>.
</p>
<p> *
The Cocoa port would draw incorrectly in full screen mode if
the emulated screen is larger than real screen.
</p>
<p> *
There is a fix for drag and drop in the Cocoa port.
When Mini vMac becomes the active application, all emulated key are
usually considered to be up, even if the actual keys are still being
held down. But there is an exception for modifier keys held down on drag
and drop (after which Mini vMac makes itself the active application), so
that holding down command and option can be used to rebuild the desktop
files of emulated disks. This exception worked in Carbon, but not
previously in Cocoa. I&rsquo;ve now figured out how to get the modifier keys,
by using [NSEvent modifierFlags]. This only work in OS X 10.6 and later,
so Mini vMac checks that this method is available before using it.
</p>
<p> *
In the Cocoa port, when Mini vMac
is launched by dragging a disk onto the application icon, but there
is also a disk1.dsk image, it now matches the behavior of other
ports in mounting the dragged image after disk1.dsk instead of
before.
</p>
<p> *
In the Cocoa port, when importing and exporting the text clipboard,
Mini vMac was not translating the end of line format.
</p>
<p> *
In the Cocoa port, when importing the text clipboard, if there were
any characters that could not be translated (because they are not in
MacRoman), nothing would be translated. Now, such characters will
translate to &ldquo;?&rdquo;.
</p>
<p> *
In the Cocoa port, when dragging the Mini vMac window
around by its title bar, the emulated cursor position was
incorrect. (The emulation continues running during the
drag in this port.)
</p>
<p> *
In the Cocoa port, if the mouse is moved over the dock, the
cursor is made visible by the operating system, but if the
mouse was then moved directly back into the Mini vMac window
(and there was nothing in between), the system cursor was not made
invisible again, so the system cursor and the cursor of the
emulated Macintosh were drawn on top of each other.
</p>
<p> *
In the Windows version of Mini vMac 3.4, the Mini vMac window
is resizable. This happened when fixing a call to CreateWindowEx
to stop using an invalid window style. The fix is now fixed
by not including WS_THICKFRAME in the style.
</p>
<p> *
There have been reports of graphics problems in the Linux version,
which is suspected to result from drawing
images with one bit per pixel to the screen not being
properly implemented in at least some versions of Linux,
with at least some hardware. So Mini vMac will now always pass 32
bit per pixel images to the operating system (for Linux and
other X versions), even for
black and white images. This could potentially be much less
efficient, so there is a new compile time option to behave
as before,
&ldquo;<a href="../options.html#option_ci">-ci 0</a>&rdquo;.
</p>
<p> *
A C compiler is allowed to assume
that two pointers of different types don&rsquo;t point to the same
memory location. But this assumption could break Mini vMac.
So now for GCC 4.7.4 the option "-fno-strict-aliasing" is
used to prevent this assumption, which appears to make no
significant difference in speed. But for other compilers,
Mini vMac will now try to work correctly even with this
assumption (basically by taking out optimizations for
big/little endian), which will slow it down a bit.
</p>
<p> *
The emulation of the CMPI instruction was considering pc relative
addressing to be illegal, when it is actually fine (though odd). As
<a href="https://www.gryphel.com/c/mail/v5.html#m5">reported by Adam</a>, this
broke Dynamix adventure games. This was in Macintosh II emulation,
but the bug was also present in the default Macintosh Plus emulation.
</p>
<p> *
The emulation of the Move to SR instruction now checks for
Privilege Violation.
</p>
<p> <a name="compile_feature"> <b> New features not in default compile </b> </a> </p>
<!--
<p> * None Yet. </p>
-->
<p> * A new build system option
&ldquo;<a href="../options.html#option_lang">-lang ptb</a>&rdquo;
selects a Brazilian Portuguese translation of the user interface by
<a href="http://www.mteam7.com/en/">Mauricio</a>.
</p>
<p> *
Normally, when in Full Screen Mode, Mini vMac
will try to &ldquo;grab&rdquo; the keyboard, preventing the operating
system from intercepting keys. So in the Windows version,
the &lsquo;windows&rsquo; key can be used as an &lsquo;option&rsquo; key, instead
of popping up the &ldquo;Start&rdquo; menu. And in the
OS X version, Command-Tab won&rsquo;t switch away from Mini vMac.
This is also implemented in the X version. There is a new build option,
<a href="../options.html#option_gkf">-gkf 0</a>&rdquo;, that
disables grabbing the keyboard, allowing
the operating system to intercept keys when Mini vMac is
in Full Screen Mode. This was
<a href="https://www.gryphel.com/c/mail/v3.html#m70">requested</a>
by a maintainer for &ldquo;Rocket Launcher&rdquo;.
</p>
<p> *
Can now use a &ldquo;Twiggy&rdquo; Macintosh prototype ROM,
after merging in work by Mat&#283;j Hybler.
(There are two known disk images that will work with it.)
The build option is
<a href="../develop.html#option_m">-m Twiggy</a>&rdquo;.
(This is not an officially supported option, advanced users
can compile this version if they want to try it.)
</p>
<p> *
Can now also use an even earlier &ldquo;Twiggy&rdquo; Macintosh
prototype ROM, merging in further work by Mat&#283;j Hybler.
(The same two disk images will work with it.)
The build option is
<a href="../develop.html#option_m">-m Twig43</a>&rdquo;.
(This is not an officially supported option, advanced users
can compile this version if they want to try it.)
</p>
<p> *
The new option
&ldquo;<a href="../options.html#option_ahm">-ahm</a>&rdquo;
patches the ROM to replace the &ldquo;Happy Mac&rdquo; icon displayed
on boot when a disk is inserted, with one of the images designed
by Steve Chamberlin for his
<a href="http://www.bigmessowires.com/mac-rom-inator/">Mac ROM-inator</a>
(used with permission).
</p>
<p> *
The new option
&ldquo;<a href="../options.html#option_rsz">-rsz</a>&rdquo;
allows you to set the size that Mini vMac expects the ROM image to be.
The build system will normally select the correct ROM Size
for the Macintosh model you have chosen to emulate. But
you can now override this, such as to use a ROM image for
Steve Chamberlin&rsquo;s
<a href="http://www.bigmessowires.com/mac-rom-inator/">Mac ROM-inator</a>.
</p>
<p> *
The new option
&ldquo;<a href="../options.html#option_chr">-chr 0</a>&rdquo;
prevents Mini vMac from checking the ROM checksum.
The first 4 bytes of a Macintosh ROM contain a checksum of
the remaining bytes, and there is code in the ROM to check
the checksum on boot. Mini vMac patches the ROM image, so
it disables this checking code. Mini vMac does the check
itself before patching the ROM. It also checks that the
4 byte checksum matches one of the known ROM images
for the model you have chosen to emulate.
This option disables these checks, which is useful
if you want to use Mini vMac with a modified ROM image, such
as for Steve Chamberlin&rsquo;s
<a href="http://www.bigmessowires.com/mac-rom-inator/">Mac ROM-inator</a>.
</p>
<p> *
The new option
&ldquo;<a href="../options.html#option_drc">-drc 0</a>&rdquo;
prevents Mini vMac from disabling code in ROM that checks
the ROM checksum on boot.
Since Mini vMac patches the ROM, it also patches
out this check. If you are using a ROM image with Mini vMac that
is already patched (such as for Steve Chamberlin&rsquo;s
<a href="http://www.bigmessowires.com/mac-rom-inator/">Mac ROM-inator</a>
), this check may already be patched out. In that case Mini vMac
doesn&rsquo;t need to, and probably shouldn&rsquo;t, to avoid interference
in case a different method of patching out is used.
</p>
<p> *
The new option
&ldquo;<a href="../options.html#option_drt">-drt 0</a>&rdquo;
prevents Mini vMac from disabling code in ROM that tests
proper operation of RAM at boot. Mini vMac normally patches the ROM
to disable this test, to speed up booting. For greater realism, you
can leave this test in.
</p>
<p> *
The port to SDL 2 now supports importing and exporting the host
clipboard (like most other ports). It also supports the same
&ldquo;-d&rdquo; and &ldquo;-r&rdquo; command line options as
the X ports. And it now uses the function SDL_GetBasePath for
the directory to look for the ROM image and the disk1.dsk, disk2.dsk,
etc. images (and also the debug log file, when enabled).
In the OS X version, in the "Info.plist" file it uses the key
"SDL_FILESYSTEM_BASE_DIR_TYPE" with value "parent", so that
Mini vMac will looking for these images in
the folder containing Mini vMac, like in most other ports.
It also now ignores command line arguments starting
with &ldquo;-psn&rdquo;, which on OS X allows it to be launched
by double clicking without getting an error message. (Previously
it had to be launched with the command line.) Like other
ports, there are now separate magnify states for when in
full screen mode and when not. And when first entering full screen
mode, the magnify state is set automatically depending on the
screen size. A new feature only in the SDL port so far
is that using the scroll wheel of the mouse acts as if
arrow keys are pressed, giving roughly the expected behavior
of a scroll wheel.
<p> <a name="compile_modified"> <b> Changed behavior not in default compile </b> </a> </p>
<!--
<p> * None Yet. </p>
-->
<p> * In the Macintosh II emulation, when compiled with 256
colors or 16 colors or 4 colors, the initial value
in the Parameter RAM is now set to boot in color.
So the initial picture is in color. (Soon after,
the color mode is changed to the value saved on
disk.) This didn&rsquo;t use to work, which is why it
was previously set to boot in black and white.
It seems to work now, for reasons not investigated
yet (probably one of various fixes to video emulation).
It still doesn&rsquo;t work for thousands or millions
of colors.
</p>
<p> <a name="compile_bugs"> <b> Bug fixes not in default compile </b> </a> </p>
<!--
<p> * None Yet. </p>
-->
<p> *
The video driver in the Macintosh II emulation now implements
indexed SetEntries. This is used by the game Crystal Quest
(which by the way requires color depth to be 16 colors).
Also for non-indexed SetEntries, the driver now returns
the no error code. (Apparently this error code is
not usually paid attention to.)
</p>
<p> *
Tara Keeling reported a bug in the Macintosh II emulation,
where if the emulation was running slow enough (such as 1x speed),
and there is a &ldquo;disk1.disk&rdquo; and
&ldquo;disk2.disk&rdquo;, then the second disk image won&rsquo;t
get mounted. There is code to delay mounting the second disk
one second after the first disk, which is good enough for
Macintosh Plus emulation, but apparently not for the Macintosh II.
So the delay has been increased to four seconds, but also now when
a kDriveStatus call is made to the replacement disk driver, the
delay is reduced (to about a fifteenth second). The emulated
computer appears to be ready for a new disk after this call. (Not
reducing the delay to zero is just being conservative.) So even
for the default Macintosh Plus emulation, when inserting
multiple disks there is now usually much less delay.
</p>
<p> *
In the built in disassembler ("-dis"
option), the shift instructions L and R were reversed
(such as for ASR and ASL).
</p>
<p> *
A problem may be fixed in the Macintosh II emulation,
<a href="https://www.gryphel.com/c/mail/v4.html#m8">reported by Stephen Barbieri</a>,
caused by the FPU emulation not coping with invalid inputs.
</p>
<p> *
In the Macintosh II emulation, an &ldquo;Abnormal Situation&rdquo;
report seen when using the Restart command of the Finder has been
removed, since this actually seems to work fine now.
</p>
<p> *
The emulation of the Move from SR instruction now checks for
Privilege Violation on 68020 (it is not a Privilege Violation on 68000).
</p>
<p> <a name="build"> <b> Build System </b> </a> </p>
<!--
<p> * None Yet. </p>
-->
<p> *
The build system has a new Development Environment option, Mini
vMac C (&ldquo;<a href="../develop.html#option_e">-e mvc</a>&rdquo;),
which is really just a particular version
of GCC and supporting projects, compiled into a set of cross
compilers, that is used for official
binaries. The advantage of using a single compiler version
is in getting consistent performance across different
operating systems. Also it easier to tweak C code to get
good performance for a single compiler, than to try to make
code that is optimum for all C compilers.
</p>
<p> *
The build system normally selects the source files needed to
compile the requested variation. There is now an option
to include all source files:
<a href="../develop.html#option_all_src">-all-src 1</a>&rdquo;.
To make this work, all source files now have unique names,
rather than have multiple files with the same name in
different folders in the source archive, for choices of
API, sound API, language, icons.
</p>
<p> *
Support for assembly language is removed, including
the option &ldquo;-no-asm&rdquo;.
</p>
<p> *
There is now an option to put generated configuration files
into a separate directory from the source files:
&ldquo;<a href="../develop.html#option_all_src">-cfg 1</a>&rdquo;.
This is only supported for
&ldquo;<a href="../develop.html#option_e">-e mvc</a>&rdquo;.
</p>
<p> *
The Export command would not overwrite an existing file
(after the Standard Put File dialog asks if you want to replace it).
</p>
<p> * The build system now supports Xcode 7.3.1
(with &ldquo;<a href="../develop.html#option_ev">-ev 7310</a>&rdquo;),
and also 8.2.1 (&ldquo;-ev 8210&rdquo;).
Though not tested,
other versions of Xcode in between should also work, by constructing
the &ldquo;-ev&rdquo; option in the same way.
</p>
<p> * The build system now supports Microsoft Visual Studio 2017
(with &ldquo;<a href="../develop.html#option_ev">-ev 15000</a>&rdquo;).
</p>
<p> : </p>
<p> If you find Mini vMac useful, please consider
<a href="https://www.gryphel.com/c/help/index.html">helping the Gryphel Project</A>,
of which it is a part. </p>
<a href="https://www.gryphel.com/index.html">
<img src="https://www.gryphel.com/d/gryphel-32.gif" width=32 height=32 border=0
alt="gryphel logo, 1K"
>
</a>
<p> Back up to - <b><a href="index.html">Changes in Mini vMac versions</a></b></p>
<hr>
<div>
<i> <a href="https://www.gryphel.com/index.html">www.gryphel.com</a>/c/<a href="../index.html">minivmac</a>/<a href="index.html">change</a>/v3.5
- <a href="https://www.gryphel.com/c/feedback.html">feedback</a> </i>
<br>
copyright (c) 2017 Paul C. Pratt - last update 7/9/2017
</div>
</body>
</html>