|
from the
|
About
What is Mini vMac
Download
current stable version:
minivmac-3.1.3
Start
How to get started with Mini vMac
More
Complete index
Feedback
Bug reports, suggestions, corrections, etc.
Help Mini vMac
Ways you can assist
News :
February 12, 2011
Today's Development source snapshot fixes a bug in the 3.2.1 alpha which broke emulation of the trace flag, used by debuggers such as MacsBug and TMON. Thanks much to one of the developers of ScummVM for reporting this bug.
There is no other significant change in this snapshot. In recent months I have accepted some other work that is keeping me pretty busy, so I don't have much time to spend on Mini vMac. But I still intend to maintain it - for one thing, I need it for myself. Highest priority is fixing any regressions - bugs that break things that used to work, like the one fixed today.
September 12, 2010
Today's Mini vMac 3.2.1 alpha is the netbook edition of Mini vMac. It also includes work on better accuracy of speed. This is an alpha, rather than a development snapshot, mainly to help ensure the development version doesn't drift too far from shippable.
Thanks in part to donations from Zebadiah Kimmel and Greg Lee, I now have an ASUS netbook. Using it as one of my primary computers will encourage better support for Windows and Linux. It is a different experience from briefly using them in VMware Fusion. (The model of Mac Mini I was thinking of getting was discontinued, the new model is more expensive, and I can get most of the desired benefits of enabling 64 bit development for much cheaper with the netbook.)
The first improvement I've made for the netbook is auto scrolling. If the emulated screen is larger than the real screen while in full screen mode, the emulated screen will be scrolled to keep the mouse pointer in view. (Previously only the top left corner would ever be displayed.)
The other improvement I've made so far because of the netbook is an "AutoSlow" feature to help conserve the battery. If the user hasn't typed, or clicked, or moved the mouse, and the emulated computer hasn't drawn to the screen, for about two seconds, then Mini vMac will automatically shift down to 1x speed.
A blinking insertion point will not prevent AutoSlow. This required improving the code for detecting how much of the screen was changed. Previously it would detect that areas at the top and bottom of the emulated screen hadn't changed, to limit the amount of drawing to the real screen. Now it can detect that areas at the left and right of the emulated screen haven't changed. If the remaining area that has changed is only a single pixel wide and less than 32 pixels tall, it is assumed to be only a blinking insertion point.
It is possible that some software will not draw anything to the screen for more than two seconds while doing real work, so the AutoSlow feature can be disabled with Control-S-W.
The biggest changes since the last snapshot are not related to the netbook, but about improved accuracy of timing. Mini vMac now measures time in cycles rather than instructions executed. In the simplest form, all instructions are assumed to take the same number of cycles, and this closely matches the results of previous versions of Mini vMac. (Mini vMac actually counts sixty fourth cycles, not just integer number of cycles, so that average times of instructions can be more accurate.)
But by default, Mini vMac now assigns an average number of cycles for each of the 65536 primary opcodes. The larger table now used, as of the last snapshot, for the primary opcodes provides a convenient place to store this, allowing the more accurate timing to be done fairly cheaply.
As a compile time option, in addition to using the table, Mini vMac can try to compute more accurate cycles for certain instructions, depending on the current data. This is slower, and only implemented in the C version of the 68000 emulation, making it slower still. By the way, I believe the MESS emulator takes this approach.
The build system option "-ta 0" selects the least accurate of these three methods, the default is "-ta 1", and "-ta 2" selects the most accurate.
Completely accurate timing would be exceedingly difficult. The CPU and video output conflict for accesses to RAM, and that would seem very complex to model.
The greater accuracy is so far mostly theoretical. The timings were entered from Motorola documentation. It needs to be tested and calibrated by comparing to real hardware.
Currently 68000 timings are used even in the 68020 emulation. More accurate timing for 68020 should be added in a future version. Truly accurate timing for 68020 would be much more difficult than for the 68000 because of pipelining and caching, probably to the point of being unfeasible for Mini vMac. But more accurate averages should be possible.
Sourceforge has improved, but on second thought it's still not ideal for releasing large number of files. So I've decided to bring back the Mini vMac Variations service for distributing compiled variations of this alpha. People who have previously purchased the Variations can use the activation code they already have.
If one in ten users of Mini vMac purchased the Variations (for $5), that would be more than enough to support full time development of Mini vMac, rather than the current slow pace. But, more realistically, it might eventually at least pay for the web hosting costs.
August 4, 2010
Today's Development source snapshot contains an experiment in CPU emulation. The CPU emulation method introduced in 3.0.1, and made the default in 3.1.0 involves a table that classifies each of the 65536 primary opcodes, saving the work of decoding opcodes bit by bit. It has occurred to me that the reason that it is not much faster than the previous approach is because it is a poor fit for the caching scheme of modern processors. On each instruction it loads a random byte from this table, which can cause the CPU to load an entire cache line, perhaps 32 bytes or more, depending on the CPU, the rest of which likely won't be used. One alternative would be to go back to the previous bit by bit decoding, making the program a bit smaller and use a bit less memory, making it more "mini". But instead I've experimented with going in the opposite direction - as long as an entire cache line is being read in anyway, make each element of the table larger, saving additional information that can help with emulation. That's the basic idea, but the pros and cons are complex, and to see what really would happen I needed to try it. Each element is now 8 bytes, and depending on the opcode, saves information about the instruction arguments. The main advantage is that there are now fewer paths for decoding arguments, so those that remain can be better optimized, at the expense of making them larger. Parts of the routines they call are inlined into them, and then rearranged for better parallelism. Another advantage is that since there are no longer separate classes of, for example, the ADD instruction for each style of arguments, instead there can be separate classes for each of the argument sizes (byte, word, and long), avoiding nasty conditional branches that modern processors will likely mispredict. Another benefit is that more of the logic of the emulator is moved into the code that sets up the table (in M68KITAB), simplifying the multiple versions of MINEM68K (c code, and assembly language for each processor). The new approach so far averages around 5 percent faster for x86 and PowerPC assembly language, and I feel more improvement is possible. The c version can be slower than before. The new approach makes careful assembly language optimization more possible, but that generally doesn't help a c compiler.
July 16, 2010
The theme for the latest Development source snapshot is address space translation, the mapping between emulated memory and real memory. With much refinement the new scheme developed at the end of last year (internally known as "UseMATCs"), is within a few percent of the speed of the previous scheme (internally known as "UseBanks"). So I've decided to make the new scheme the default, trading some of the speed gained by recent use of x86 assembly for more accuracy and flexibility. The "UseMATCs" scheme can handle equally well the old 24 bit addressing and the newer 32 bit addressing, available on the Mac II and later. It also allows detecting misalignment without additional speed penalty. This is important because in previous versions of Mini vMac, a misaligned memory access near the very end of a bank of memory could end up reading or writing past the end. This mostly worked for Macintosh Plus emulation, because the memory mapping is mostly contiguous. (For safety, Mini vMac allocates a few extra bytes past the end of emulated memory.) It's just inelegant, and not a practical problem. For later Macintosh computers, it could matter more, particularly if one wanted to emulate a PMMU. Mini vMac can now accurately emulate non contiguous memory mappings.
Some unrelated tweaks to the PowerPC assembly version allow it to nearly maintain its previous speed.
In other unrelated work, the Mini vMac build system now supports the Digital Mars Compiler (with "-t wx86 -e dmc") and the Pelles C Compiler (with "-t wx86 -e plc" and "-t wx86 -e plc -cl").
Much of this work was accomplished during a trip from June 23 to 30, with gas sponsored by Anonymous.
June 20, 2010
The latest Development source snapshot continues work on the new approach to assembly language for the core 68000 emulation. The build system now supports using assembly language in the Linux for Intel version.
Furthermore, assembly language can be used for the Windows version, using the command line tools from Bloodshed Dev-C++ (basically a version of MinGW). I haven't figured out a way to make the IDE deal with assembly code. To compile with the Bloodshed Dev-C+ command line tools, use "-t wx86 -e dvc -cl" in the Mini vMac build system, extract the resulting archive in Windows, and at the Windows command line, run something like "set PATH=c:\Dev-Cpp\bin;%PATH%", then change to the extracted directory, and run "make". The result is somewhat faster and smaller than the previous best version compiled from the c code, using Microsoft Visual C++. This demonstrates the hoped for advantage of using assembly language, getting consistently good results with any development tools.
Compiling for PowerPC Linux, broken in the previous snapshot, is fixed. But late testing revealed a trivial bug in this snapshot preventing the Mac OS 9 and earlier for PowerPC version from compiling. This will be fixed in the next snapshot.
June 1, 2010
Today's Development source snapshot takes a different approach to assembly language source code (previously used only on PowerPC computers, for 68000 emulation). This made it more feasible to start supporting assembly language on Intel computers. So I have started tweaking assembly language on my Mac Mini (starting from assembly language generated by GCC for "MINEM68K.c").
So far it is more than 25 percent faster (on a 1.5 GHz Intel Core Solo). Which isn't all that much. I hope to improve this in the future, but I don't expect by too much. I think the main limitations are unpredicted branches and cache misses, neither of which would be much affected by tweaking, without taking a completely different approach than used by "Mini" vMac.
So the main motivation for using assembly language remains to give more consistent results using different development environments. In the future. The build system currently only uses Intel assembly language for OS X. I have gotten the Linux version to work with it, but haven't supported it in the build system yet. Another limitation is that for both PowerPC and Intel, the assembly language version only emulates the 68000, and not the 68020 used in the Mac II emulation. So the emulated Mac Plus is faster than emulated Mac II. Another motivation for the assembly language is aesthetics. The compiled c code is just so ugly, partly because the c language doesn't allow direct access to certain features of the computer. (Though this doesn't seem to slow it down that much, because of other bottlenecks.)
This work was mostly accomplished during a trip from May 21 to 28, with food sponsored by ClockWise, Greg Lee, Timothy Scoles, and Claude Armstrong, and gas sponsored by Timothy Scoles.
In other news, Jesús A. Álvarez (Zydeco), has announced FuseHFS, to allow OS X Snow Leopard to write to HFS disks (and disk images). (He has previously ported Mini vMac to Android and the jailbroken iPhone.)
May 6, 2010
There is a new Development source snapshot and also many of the Mini vMac Extras have been updated. The main change since the January snapshot is to make the build system and the extras easier to compile with different Macintosh 680x0 C compilers. It's not very "open source" if it requires a compiler that almost nobody has. One development environment that can now be used easily, MPW, is still available from Apple, for free. (It requires a Mac II or later - the Mac II emulation of the last Mini vMac alpha seems to work well enough.) I have started some documentation on compiling with various compilers.
(I had previously started a project to make the build system portable in the same way that Mini vMac is, so that it would port itself as well as Mini vMac, but I backed out of that for being likely in the long run to take up too much time to maintain. The current idea of only supporting Macintosh 680x0 has the advantage that most of the Mini vMac extras can be compiled in the same way as the build system.)
Much of the initial work on this portability was done in a few days in March, one day of which was sponsored by Leon Buijs. For one reason and another (starting with record snow in February) I haven't had much opportunity for longer trips to work on Mini vMac, but hopefully I will again within a month or so. Expenses for the next trip have already been sponsored by ClockWise, Greg Lee, Timothy Scoles, and Claude Armstrong.
Thanks to Zebadiah Kimmel and Iván dominguez martin I have a new keyboard, and so have less stuff to cart around between locations. I think the Apple keyboard is the nicest I've used, quiet, not requiring much force, and the main thing - no numeric keypad. The remainder of the donation from Zebadiah Kimmel, along with one from Greg Lee, go a significant way towards sponsoring a new Mac Mini, which would enable supporting 64 bit Intel versions of Mini vMac.
Thanks to Ryan Schmidt for finding and fixing a bug in the previous (unannounced) snapshot. Also, thanks to an anonymous report, I've made the PowerBook 100 emulation compile work again (though it still doesn't do much).
Douglas Mencken has compiled Mini vMac for Fedora 12 PowerPC Linux. I've added the link to the Ports page. It's not clear to me whether it would work on other PowerPC Linux distributions. The Intel Linux binary I provide seems to work most places, but only because it was compiled on an ancient version of Linux (Red Hat 7.1). I've also added to the ports page a generic X source archive, which was available for Mini vMac 3.0.4, but was previously missing for Mini vMac 3.1.3.
Thanks to Andrew H., CopyRoms will now correctly save a 2M ROM image on a PowerBook 520 or PowerBook 540, instead of 1M. Also because of that discussion, I've started adding md5 checksums to my page of ROM information. I also created the utilities Md5Im and Md5Fl so that I don't need to document or support all the other software out there that calculate md5 checksums.
There are also various other fixes and refinements to CopyRoms and the rest of the Mini vMac extras. For example, binUnpk wasn't setting the bundle bit of the extracted file. FindCode didn't work on a 64K ROM. TestSync would leave the screen corners white.
The new GetRsFrk utility makes it easier to disassemble an application (instead of a ROM image). I've made another example application, Blacken.
Sorry for the lack of news updates lately. With lack of time, documentation and publicity are the easiest things to neglect, since I'm mostly a programmer. But they're probably more important to the goals of the Mini vMac project than the programming.
OLD NEWS - Previous release notes