Login  •  Register


The time is now: Sun Nov 18, 2018 4:33 pm

Emaculation wiki  •  Delete all board cookies



Post new topic  Reply to topic Page 1 of 1 [ 1 post ]
Print view Previous topic  |  Next topic
Author Message
PostPosted: Tue Mar 14, 2017 11:49 am 
Offline
Site Admin
User avatar

Joined: Mon May 20, 2002 4:37 am
Posts: 3668
Location: Uiwang
Lots of recent updates. Here's a quick copy/paste:

http://www.gryphel.com/index.html#news

March 5, 2017

In the latest Mini vMac Development source snapshot, for x86-32 versions, Mac II emulation is now even closer in performance to the Macintosh Plus emulation. Previously Mini vMac 3.5 used a non-standard stack alignment for Macintosh Plus emulation on x86-32, when compiled with GCC 4.7.4 (with the “-e mvc” option), which results in smaller and faster code. However, for OS X, any calls to external libraries could crash, and such calls can be generated by the compiler itself. For Macintosh II emulation, such a call is generated for 64 bit division, so previously the non standard alignment was not used. Now instead Mini vMac contains its own (not particularly good) implementation of 64 bit division, used for CPU architectures which don't directly provide it and the compiler would generate a library call. So the non-standard stack alignment can be used. To make it easy to detect if the compiler generates any other problematic calls, on OS X Mini vMac is now linked without the compiler libraries (for GCC 4.7.4).

Compiling with GCC 4.7.4 previously generated warning messages about “aliasing”. A C compiler is allowed to assume that two pointers of different types don'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.

Also in this version, a bug is fixed in the Cocoa port, where it would draw incorrectly in full screen mode if the emulated screen is larger than real screen.

Also fixed is a bug in lazy evaluation of condition flags for the Tst instruction and similar.

February 26, 2017

In the latest Mini vMac Development source snapshot, the emulation of the coprocessor instructions (F line instructions) is reworked to not use the opcode, but instead only use the entry for the opcode in the OpDispatch table. So now the main emulation loop doesn’t need to save the opcode for Mac II emulation, helping to make it perform exactly as fast as Macintosh Plus emulation.
Latest News : March 12, 2017

The latest Mini vMac Development source snapshot adds support for Visual Studio 2017 (with “-ev 15000”) and has been tested with Apple Xcode 7.3.1 (“-ev 7310”) and 8.2.1 (“-ev 8210”). Basically only version information seems to have changed in the file formats.

The emulation of the Move to SR instruction now checks for Privilege Violation, and emulation of the Move from SR instruction now checks for Privilege Violation on 68020 (it is not a Privilege Violation on 68000). The build system should now correctly include all icon files with the “-all-src 1” option. And compiling the Windows CE version with “-e mvc” should work again.

Various compiler warnings and other small issues were also fixed. I expect to move the 3.5 development branch to beta soon, after further testing.

------

Thanks to Christopher Tar for the Gryphel project for sponsoring over a half month of web hosting.
February 19, 2017

In the latest Mini vMac Development source snapshot, the emulation of the 68020 instructions is updated to not use the opcode, but instead only use the entry for the opcode in the OpDispatch table (as the 68000 instructions already do). The next step will be to do the same for F line instructions such as FPU calls. Then the only use of the opcode will be for that lookup, and so the opcode won’t need to be saved, in the most speed critical part of the program. This will help make the Mac II emulation perform exactly as fast as the Macintosh Plus emulation (where the opcode is already not saved).

Thanks to ClockWise for sponsoring over a day of health insurance costs for time I spend on the Gryphel project.


Top
 Profile  
Reply with quote Post a reply  
Display posts from previous:  Sort by  
Post new topic  Reply to topic Page 1 of 1 [ 1 post ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
 

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group