:
February 26, 2012 - permanent link
The latest Development source snapshot continues to improve the X version. To match the behavior of the Macintosh and Microsoft Windows versions, it now tries to determine the application path. This is used when looking for the ROM image, and in looking for disk images named disk1.dsk, etc. If the application directory can not be determined, it uses the current directory, as before (which is often, but not always, the application directory). The application path is also used to determine the application name, which is displayed in the window title bar. (If the application name can not be determined, "Mini vMac" is used as before.)
Determining the application path is implemented (in somewhat different fashions) for Linux, FreeBSD, NetBSD, Dragonfly BSD, and OpenIndiana. I've not figured out an implementation for OpenBSD and Minix.
The build system now supports compiling 64 bit versions for OpenBSD (-t ob64), NetBSD (-t nb64), Dragonfly BSD (-t db64), and OpenIndiana (-t oi64).
Mike Fort sent a fix in setting up the ethernet port in the LocalTalk emulation. And I've put in a considerable amount of debug logging code into the SCC emulation (enabled by preprocessor condition), to make it easier to figure out what it is doing.
I've added TattleTech and Monitor to the software hosted by the Gryphel Project.
February 12, 2012 - permanent link
In today’s Development source snapshot, Mike Fort's alternate version of SCCEMDEV.c (for LocalTalk emulation, with build system option "-lt") is merged with original file, using the preprocessor condition "EmLocalTalk" to enable it or not. This is more maintainable. Much work remains.
Also in this snapshot, the X version now supports a central ROM folder like the Mac and Windows versions have. If "~/.gryphel/mnvm_rom" exists, Mini vMac will look there for the ROM image. If it isn't there, it will look in the current directory as before. (And the -r command line option will override both.)
The X version now also supports saving Activation Codes, like the Mac and Windows versions have. The custom made variation service tried for 3.2.x seemed elegant, and a good fit for funding an open source project, but there does not appear to be demand for it. So for 3.3.x, I'll try going back to the shareware like custom variations service, and try some other tweaks.
The ongoing work on the X version involves drifting further from using the most generic standard c library and Xlib API's. Rather than guess what portability problems this causes, I'd prefer to have real data. So I've been setting up various operating systems in VMware Fusion, and getting Mini vMac to compile in them.
The build system now supports OpenBSD ("-t obsd"), NetBSD ("-t nbsd"), Dragonfly BSD ("-t dbsd"), OpenIndiana ("-t oind"), and, for a challenge, Minix ("-t minx"). These are all for 32 bit x86. I should try the 64 bit versions later. Adding support for other architectures like PowerPC, for the operating systems that support it (like NetBSD), wouldn't be much work, except that I don't know of any way nearly as convenient as VMware for testing them.
This snapshot fixes a bug where the clock is not properly initialized, and is only correct after the first second interrupt.
Also fixed is a more serious bug where in full screen mode, if the emulated screen is too big to fit on the real screen (when autoscroll is available), if the area of the emulated screen that has changed doesn't intersect the visible area of the emulated screen, then an invalid rectangle was used for drawing. I discovered this when trying out Vector Linux 7, which seems to have some extra debugging checks.
I've added Peek-a-Boo and Checksum to the software hosted by the Gryphel Project.
January 29, 2012 - permanent link
The latest Development source snapshot has an initial merge of Mike Fort's LocalTalk emulation. It is enabled with the build system option "-lt". It is currently implemented with an alternate version of one source file (SCCEMDEV.c), but I expect to eventually merge that with the original. I've already editted it quite a ways in that direction, hopefully not adding too many bugs.
The are currently some limitations. It is only implemented for OS X. It requires running the command "sudo chmod ugo+rw /dev/bpf*" to allow Mini vMac (and everyone else) access to all network traffic. It loses packets some of the time. If running faster than 1x, it loses more packets (which in a way is good, as that should be a clue where to look for the problem). So the "-lt" option causes the default speed to be 1x. The "-lt" option also cause Mini vMac to run in the background by default, because Mini vMac can't be a proper LocalTalk node if it isn't running. And you need to manually turn on AppleTalk in the chooser - I can set the PRAM flags to boot with AppleTalk already on, but it doesn't work properly.
All my testing of Mini vMac with LocalTalk emulation has been done in VMware Fusion 4 (sponsored by Peter Godwin and Andrew Macfarlane), which now supports running OS X as guest.
In other news, I've verified that the version of Mini vMac compiled in PC-BSD 9, with the new "-t fbsd" option, works in FreeBSD 9, and also FreeBSD 7.
I've added Burn and Disinfectant to the software hosted by the Gryphel Project.
January 22, 2012 - permanent link
Mike Fort has implemented LocalTalk networking support in Mini vMac for OS X, available as a beta on his website. This allows, for example, using multiplayer games like NetTrek over a local network. It does not yet allow connecting to the modern internet, but Mike Fort says this could be possible by creating "gateway" software.
Using it requires enabling the "Berkley Packet Filter" to allow Mini vMac to access all packets on the network, which has security implications. If I understand correctly, allowing all software complete access to network traffic is not normally considered desirable. An alternative to giving all software access would be to give Mini vMac elevated privileges, which is more convenient, and in some ways safer, but in other ways more dangerous, in that if Mini vMac gets compromised, the entire computer is completely compromised.
I'll be learning more about networking, as I work to merge Mike Fort's code into my version of Mini vMac.
January 20, 2012 - permanent link
Today’s Development source snapshot adds advisory locking to the Linux version (and other X Window ports). Previously in the Linux version, Mini vMac could open an already opened disk image, likely corrupting the image. Now Mini vMac will refuse to open a disk image that has been opened by another copy of this version of Mini vMac (and presumably later versions).
In Windows and Mac OS 9 and earlier, the operating system prevents opening the same file twice with write access (at least when opened in the normal way that Mini vMac does). After some early versions which didn't, OS X now also prevents this for Carbon programs (though it still allows read access to a file open for writing).
The Linux operating system does not prevent opening the same file twice with write access. But it does provide advisory locks, to allow programs to say that a file is in use, to any program that pays attention to this. To make things more complicated, there are two different kinds of advisory locks. Mini vMac is now using "fcntl". If other programs use "flock", they may not notice Mini vMac locks. And Mini vMac can't simply set both locks, because one kind of lock can be implemented using the other, or not, depending on operating system version. I don't really understand this all completely, and/or it isn't designed very well.
As part of seeing how this code works in other X Window ports, I tested it in the latest PC-BSD. I've added "-t fbsd" to the build system, for FreeBSD, because I think PC-BSD and FreeBSD are compatible for compiling, though I still need to test this. There is also now "-t fb64" for the 64 bit version.
It also seems to work in Apple's X11 implementation. I've added "-t mx64" for the 64 bit version, in addition to the previous "-t mi11" and "-t mx11".
And it works in Cygwin/X for Microsoft Windows. I've added "-t cygw" to the build system. Cygwin can also be used to compile the regular Microsoft Windows version with "-t wx86 -e cyg".
Related is MinGW, which the build system now also supports with "-t wx86 -e mgw". Actually since Bloodshed Dev-C++ is based on MinGW, "-t wx86 -e dvc -cl" would previously give similar results.
Support for Cygwin and MinGW is due to Hugh Sparks, who got Mini vMac to compile with NetBeans. NetBeans for Windows C development seems to use either MinGW or Cygwin, and can import Makefiles for them fine. At some future time I could look at supporting a more native style project.
Internal to the build system, there is now a concept of target family, which groups together targets with the same CPU. This simplifies supporting operating systems that support many different CPUs.
------
Thanks to Peter Godwin and Andrew Macfarlane for sponsoring a VMware Fusion 4 Upgrade. And thanks to Evan Appelman for sponsoring storage and web hosting for the Gryphel project.
------
I've simplified the Custom Variations service to be one step, instead of donation and request steps. The previous offer is still good for people who have already donated or customers of the earlier Variations service. Just contact me.
I've added Speedometer to the software hosted by the Gryphel Project.
I was about to host NumberCrunch, my favorite tool for quick arithmetic, but I discovered that it is currently available from the author, with a newer and fancier version than what I had. I've added a link to it on the Math Software page.
I also added Hexy by Marc Liyanage to the Programming Tools page. It is an extension for BBEdit.
December 20, 2011 - permanent link
Mini vMac 3.2.3 is now officially released (with no change from the final beta, as usual). The Changes file lists what has changed since Mini vMac 3.1.3.
Today’s Development source snapshot is the start of the 3.3 branch. It adapts for the Linux version the technique seen in SDL for dynamically loading the ALSA library, so that Mini vMac will still run, without sound, even if ALSA is not installed. So by default the Linux version is now compiled with sound, matching the Mac and Windows versions.
Other changes in the snapshot: Fixed "-min-extn" build option in the Linux version. Changed order of arguments to the link command when building the Linux version. It turns out there is a conventional order for how libraries should be specified, which I didn't know since I hadn't come a across a linker that cared until Ubuntu 11.10. In all X versions, the "Xext" library is no longer linked in. I don't think it is needed, but haven't removed it before since I'm not sure there isn't some distribution where it is. But now I've decided to remove it to find out. And also in the X version, the results of fwrite and fread on disk images are now checked for errors, which stops compiler warnings in recent Ubuntu.
I've added GIF Converter and ShareDraw to the software hosted by the Gryphel Project.
------
Thanks to Kevin Grabher and Todd Katz for sponsoring storage for the Gryphel project.
December 13, 2011 - permanent link
I've added 64-bit Linux binaries for Mini vMac 3.2.3. They are much slower than the 32 bit versions, for lack of assembly language tweaking, but some 64-bit (x86-64) Linux distributions can not by default run the 32 bit binaries. I used 64-bit Ubuntu 10.04 LTS to compile the default variation and the example variations, and tested them in 64-bit Fedora 16, openSUSE 12.1, and Mandriva 2011. Also, the custom variations page now supports x86-64.
As items on my list of links to currently available software for Macintosh Plus are gradually disappearing, I've decided to start hosting some selected software on the Gryphel Project website, in the zipped disk image format that is convenient for use with Mini vMac. I've made new pages for Stuffit Expander and DropStuff that I'd previously hosted, and then added BBEdit Lite and FullWrite.
(For more software in disk image format, ready for use in Mini vMac, E-Maculation has a large collection of shareware and freeware Macintosh games.)
I've also added to the Gryphel Project website a list of alternatives to Mini vMac for running Macintosh 680x0 software. For the goal of the project, the more alternatives the better.
December 6, 2011 - permanent link
The second batch from the Custom Variations beta is available. The beta is now over, and Custom Variations are live.
I've chosen to make Custom Variations a thank you gift for Mini vMac sponsors. Everyone who donates $5 or more is eligible for a Mini vMac 3.2.3 variation. People who have already donated are also eligible. And also, customers of the earlier Variations service are eligible for a custom variation.
An extra benefit of requesting a variation is that it is a vote for what Mini vMac options you think are important, influencing development priorities.
Though Mini vMac 3.2.3 is still in beta, the official release should be close. But if a version 3.2.4 becomes necessary, I'll recompile all variations made previously.
In other news, I've been collaborating with Arbee (AKA R. Belmont), of the MESS emulator project, by making a series of programs similar to CopyRoms, that copy other ROMs found in some Macintosh 680x0 computers, including for the Egret microcontroller (EgretRom), the Power Management Unit of some PowerBooks (PMURom), and Nubus Cards (SlotRom).
Another recent Mini vMac extra is ExportPS, which saves a few steps in the process of printing from Mini vMac.
November 28, 2011 - permanent link
The first batch from the Custom Variations service beta is available.
Lessons learned from the first batch led to a few refinements to the service. The Custom Variations service free beta is open for another week.
In other news, Peter Godwin is working on updating the iPhone port by Jesús A. Álvarez (Zydeco) to use Mini vMac 3.2.3 source code.
November 21, 2011 - permanent link
Todays starts a free beta period of a revised Mini vMac Variations service. The concept now is that I'll make custom made variations, for a small fee, to help support Mini vMac development. Instead of the previous idea of activations codes, you are permitted and encouraged to redistribute your variations. Which I think is more compatible with the goals of the Gryphel project, and open source generally. Previous work for the earlier variations service I think now makes it feasible to build large numbers of custom variations, in batches.
I've updated the Mini vMac 3.2.3 documentation from the list of changes, which gets it closer to the official release. The example variations are more accessible, from the Options page.
In other news, I've resigned from recent paid work to have more time for Mini vMac, and the Gryphel project.
September 20, 2011 - permanent link
Today's Mini vMac 3.2.3 is the first beta of the 3.2.x branch. It has been too long since the last stable version, so I want to put together a new stable version to make more available the improvements since then. The Changes page lists differences from current stable 3.1.3 version.
Since the previous 3.2.2 alpha, the fix that most affects me is allowing command-option drag from a background Finder window in OS X to work again. But there are also a number of other changes.
The new AutoSlow feature is refined a bit. Reading and writing to disk now counts as activity that prevents AutoSlow. Instead of 2 seconds of inactivity before AutoSlow, it is now the longer of either a half second, or 16 seconds worth of instructions executed (which corresponds to about 2 seconds at the default 8x speed).
Misbehaving software running in Mini vMac that makes wild jumps to non memory locations is now less likely to result in a segmentation fault that terminates Mini vMac. It now works about as well as it did in Mini vMac 3.1.3. In the future I'd like to make Mini vMac catch such events properly, but it will take some work to be able to do so without significantly slowing emulation. In the mean while, such events should not cause harm other than terminating Mini vMac, because it is only reading from random memory locations, and not writing.
The "-t xgen" version of Mini vMac for generic x window system now works again. The code for better determination of changed screen area that was added for the AutoSlow feature was previously only implemented for big endian and little endian systems. Now it can also work with out assuming either, by operating on a byte at a time instead of four bytes. It can also now operate on eight bytes at a time, which would be more efficient on 64 bit systems, but this ability isn't used yet.
The build system now supports XCode 4.0.2 (with "-ev 4000").
There is better support in general for different versions of Microsoft Visual Studio. Specifically, support has been added for Visual Studio 2010 (with "-ev 10000"), Visual Studio .NET 2003 (with "-ev 7100"), and Visual Studio .NET 2002 (with "-ev 7000").
There is a new option, "-t wx64", to target for 64 bit Windows. But it is currently slower than the 32 bit version, because that version has some assembly language tweaking.
The copyright message in the about screen of the German version was munged when the about screen was rearranged. This is fixed.
A new build system option "-intl" forces Mini vMac to support international characters in the user interface, even when using the default English. This is useful if the maintainer name needs the extra characters. (It would be nicer for the build system to figure out for itself what character set is needed. But this will do for now.)
In the Windows version of recent 3.2.x, toggling magnify in full screen mode turned off more accurate mouse emulation. This is fixed.
------
Thanks to John Feinberg, John Goodwin, Simone Manganelli, Callum MacKendrick, Gianfranco Cilia, and Fabian Hahn for sponsoring over a year of web hosting for the Gryphel project.
They also helped motivate my taking a week off from other work to work on Mini vMac and get out the new beta. (Not setting aside a big block of time doesn't seem to allow much progress.)
------
In other related news, on Big Mess o' Wires, Steve Chamberlin is documenting his progress on an interesting project to emulate a Macintosh Plus in hardware, using an FPGA.
I hear that Macintosh emulation in the MESS emulator is making major progress. Sometime when I find time, I'll examine its source code closely for ideas.
The PCE emulator is also being actively developed.
Mike Gleason has created "a NEW program in 2011 for 68k Macs", Daleks Forever.
Gil Osher has announced his new Mini vMac for Android port, based on an earlier initial port by Jesús A. Álvarez (Zydeco).
I don't have an Android, but looking at the source code, it looks to be updated to use Mini vMac 3.1.3 code instead of Mini vMac 3.0.4, plus interface refinements like having code for sound, some work on keyboard support, and supporting Reset and Interrupt commands.
Today's Mini vMac 3.2.2 alpha is made from the last source snapshot. (Variations to follow.)
I think I'll phase out the OS X universal version. Five years after the transition, there isn't much demand for it. I'll still keep the PowerPC only version, along with versions for OS 9 and earlier.
A reminder: notification of Mini vMac news can now be found on Twitter.
April 29, 2011 - permanent link
Today's Development source snapshot allows the power button to be used in the OS X version when in full screen mode, to put the (real) computer to sleep.
A problem with this, and the previous enabling of the force quit (command-option-escape), is that they bring up dialogs, which Mini vMac didn't notice and so the real cursor remained hidden. It turns out that requesting window focus events allows Mini vMac to notice when such a dialog has appeared, so that it can show the real cursor.
A previous fix, also in the OS X version, in the February 20 snapshot, involved registering for changes to the screen configuration. Upon receiving such notification, Mini vMac will now also turn off full screen mode if it is on, instead of just leaving the emulator window at a size that is now wrong.
The new autoscroll feature in full screen mode (in all versions) previously tried to keep the emulated mouse on the real screen and out of a border area. After using it a while, I think the border area was a mistake. So now it only scrolls upon reaching the edge of the real screen.
I've rearranged the Mini vMac about page (Control-A) a bit to make room for another idea I have for the variations. It no longer displays which the computer is being emulated. That can be inferred from the variation number.
I've fixed a problem with the previous snapshot, where toggling full screen or magnify mode would turn off control mode.
I have scripts that enforce some conventions in the source code. As of this snapshot, a maximum line length of 72 characters is also enforced. (72 characters fits well on a Macintosh Plus screen. And it is generally thought that lines much wider than that reduce readability, and a better use for more screen space is to put editing windows side by side.)
If no problems turn up, I plan to make a new alpha version from this source snapshot.
April 10, 2011 - permanent link
The latest Development source snapshot may fix a very long standing issue in the OS X version. Mini vMac tells the operating system to hide the cursor when it is over the emulator window, but sometimes the operating system shows the cursor again by itself. The most easily reproducible such situation is when the computer goes to sleep and wakes up. In OS X 10.3 and later, there is a way to tell if the cursor is visible, the "CGCursorIsVisible" routine, but it is not always accurate. So a previous attempt to use this routine to correct cursor visibility just made things worse. Now I think I've figured out how to use this routine without getting permanently confused when it is inaccurate.
By the way, after observing for a while the behavior of Mini vMac versions with and without the attempted fix (in the February 20 snapshot) for problems when switching screens in OS X, I'm fairly confident the fix is effective.
By request, Mini vMac will now by default mount disk images in Disk Copy 4.2 format as read only. This is because by default Mini vMac ignores the checksum and tags of this format, so writing to the image makes it invalid. Mini vMac can be compiled with full support for this format, in which case the images will be writable.
I have created a utility, CnvtDC42, that converts Disk Copy 4.2 format images to a new image without the tags and checksums, that the default version of Mini vMac can write to.
Also in the latest snapshot, the Windows and Linux versions now match a previous feature of the Macintosh versions. When switching from full screen to normal mode, or toggling magnification in normal mode, it will preserve the emulated cursor position, by moving the host computer's cursor. (This was not an issue in full screen mode, because then the host computer's cursor is not in the same place as the emulated cursor.)
There is a new build system option, "-t lx64", to target for 64 bit linux. It would currently be slower than the 32 bit version, because that version has some assembly language tweaking.
As an additional safety feature, the control mode confirmation for the reset, interrupt, and quit commands will now treat anything other than 'y' as meaning no, rather than ignoring it. (With exception that a repeated key is ignored - so 'q' is ignored for quit, 'r' for reset, and 'i' for interrupt.) This is because I once managed to accidentally reset Mini vMac by typing unintentionally into control mode.
There is new build system option, "-emm 0", to disable the more accurate mouse emulation normally used in full screen mode. This allows Mini vMac to work somewhat better on tablet computers without a mouse. But such computers are still not really supported. (The compile time option already existed. Supporting this option in the build system was prompted by communication from someone using Hypercard on their HP TC1100.)
A new build system option, "-var-fullscreen 0", makes the full screen mode option a constant rather than a variable. So "-var-fullscreen 0 -fullscreen 1" will make Mini vMac always run in full screen mode, and "-var-fullscreen 0 -fullscreen 0" will make Mini vMac never run in full screen mode. The "F" control mode command disappears.
Thanks to Matthew Exon for sponsoring a month of web hosting for the Gryphel project. And thanks to Joel Schmidt for previously sponsoring gas. The notification email from PayPal hadn't reached me. I've set up stricter accounting to catch if that happens again.
update For Twitter users, I have set up http://twitter.com/gryphel, basically to announce when there is news here. (Sorry, I don't know how Twitter is supposed to be used.)
March 5, 2011 - permanent link
The latest Development source snapshot fixes a bug reported in the Mini vMac Variations. The numeric keypad can't be used to type in activation codes. (I didn't notice this because I usually use keyboards without a keypad.)
Today I'm trying out an improvement to the Variations service. A problem with the service has been that there are so many possible combinations of options that it is difficult to find some useful subset to offer. So instead you can now order a custom made variation with the exact combination of options you want. Up to 3 custom variations per activation code. An activation code is now $10.
The 3 custom variations are also available to everyone who has previously purchased an activation, as a thank you gift.
My current paid work may not last forever. (For one thing, my main task is to make myself unnecessary.) So I'm still trying to make Mini vMac a self supporting business, in the time I can make to work on it now.
Somewhat related, some time ago I created a Flattr page for Mini vMac. Flattr is a clever micro donation service. One of the cleverest bits is that you need to give donations before you can receive them. So if anyone with a webpage, or maintaining software, that is related to the goal of "preserving software for early Macintosh computers" sets up a Flattr page, and lets me know about it, I would be likely to donate (to "flattr" it).
In conventional donations, thanks to John Duncan, Philippe Dautremont, Eric Eliasson, Dave Henning, and Robert Eliason for 3 months of web hosting and domain registration. And thanks to Gianluca Abbiati, Joseph Buchanan, Douglas Egan, Mike Gleason, Dax Mackenzie Roggio, T.C. Meggs for paying expenses for the next trip to work on Mini vMac, when I can get opportunity to do so.
February 20, 2011 - permanent link
In today's Development source snapshot I tried to fix a problem where switching between using the screen of my new MacBook Air and an external screen would tend to make Mini vMac stop drawing. Reading Apple's documentation, I think you're supposed to call CGDisplayRegisterReconfigurationCallback to get notification of when the screen changes, and then call aglUpdateContext. After doing this I don't see the problem anymore. However, now I don't see the problem in the previous version of the program anymore either. So I don't completely understand what is going on.
I haven't approved of some directions Apple has gone lately, but I have no complaints about the 11" MacBook Air. It is the nicest computer I have used. Besides making travel easier, I like how easy it is to switch between working at a desk, reading in bed, writing on a couch, and web surfing on an exercise bike.
February 12, 2011 - permanent link
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 - permanent link
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 - permanent link
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 - permanent link
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 - permanent link
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.
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.)
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.
February 15, 2010 - permanent link
Luc Pauwels has compiled and packaged Mini vMac 3.1.3 for Solaris 10 on SPARC and x86.