News : (Twitter)
May 8, 2013
Today's Development source snapshot may now work on Raspbian for the Raspberry Pi. (A binary for Linux on ARM is included, stretching a bit the meaning of source snapshot.)
I received a bug report last year that the Linux ARM version of Mini vMac was freezing on the Raspberry Pi. We narrowed it down to a problem with sound, but I couldn't solve the problem without having a Raspberry Pi of my own to work on.
I recently got a Raspberry Pi, and have been able to debug further. As far as I can tell, the "snd_pcm_avail_update" call of ALSA is broken in Raspbian. It doesn't return a value less than the buffer size, but increases without bound. So I've put in a work around, that tests if the result is unreasonable, and if so calls snd_pcm_status_get_avail (after calling snd_pcm_status), which seems to work correctly. (I'm not really sure exactly what the difference is supposed to be between snd_pcm_avail_update and snd_pcm_status_get_avail.) This work around is currently only enabled for ARM.
The work around is actually the second needed fix. The first problem is that before snd_pcm_start is called, snd_pcm_avail_update returns a reasonable looking value, but doesn't change as sound samples are written. Mini vMac was waiting for the ALSA buffer to become full before starting the sound playing, and so sound never started playing. Thinking about it, this algorithm wasn't really right anyway, even if ALSA was working as documented. ALSA doesn't promise that its buffer will be the size you request, it could be much larger or smaller, and so waiting for it to fill could give inconsistent results. So now instead Mini vMac waits until its private buffer is full, then transfers as much as will fit into the ALSA buffer, and then starts sound playing.
April 27, 2012
Jim Bauwens has announced an initial port of Mini vMac for the TI-Nspire graphing calculator.
Also, a status update: Sorry for disappearing for some months. I have lately accepted paid work to update one of the oldest programs for Macintosh still sold to use the Cocoa API. My plan is to make the platform independent and platform dependent parts of this program interact as closely as possible to how this is done in Mini vMac. Then in the future most of the work of continuing to update and port to new platforms can be shared between it and Mini vMac. (The hard part is more in getting a good grasp of the parts of the API to use rather than writing code.) And then work on Mini vMac can continue with less of the distractions of poverty. But there are still some months more to go to get to that point.
December 6, 2012
In today's Development source snapshot, the Cocoa port for OS X seems to be feature complete. I'll do some testing, and then compile an alpha version that others can test.
Work in today's version includes: remembering window positions when toggle Magnify and Full Screen mode, remembering magnification state when toggle Full Screen mode, automatically choosing magnification for Full Screen mode, support color for Mac II emulation, using relative mouse motion in Full Screen mode, using a borderless window for Full Screen mode to eliminate some drawing artifacts, using localized strings for the application menu, allowing for better error recovery on toggle Magnify/FullScreen by creating the new window before disposing of the old one (which also reduces flicker), implementing the drawRect method to eliminate flicker when create the new window, using the mouseLocation method of the NSEvent class to get current mouse position on each tick (because the location data from events gets stale in a number of situations), using setPresentationOptions when available (instead of the older SetSystemUIMode), support compiling with the 10.4 SDK, adding an applicationDidChangeScreenParameters method to update the OpenGL context when needed, and cleaning up the sound code a bit.
November 29, 2012
Today's Development source snapshot continues work on the Cocoa port for OS X, including: handling aliases, supporting "~/Library/Preferences/Gryphel/mnvm_rom", generating projects for the XCode IDE (in addition to previously supported compiling with the command line), using OpenGL for drawing (as done in the Carbon version), using more efficient drawing code (taken from the Carbon version), and Full Screen mode.
November 15, 2012
Today's Development source snapshot continues work on the Cocoa port for OS X, restoring features from the Carbon version.
Such features include: Drag and Drop support. An Open dialog. A Save dialog (used by ExportFl). Clipboard support (used by ClipIn and ClipOut). Mini vMac style menu bar. Date and time zone. Setting the window title from the application name. Keeping the names of files (used by ImportFl). An error alert, used such as if Mini vMac fails to start. The "mnvm_dat" directory. And, advisory file locking.
November 1, 2012
Today's Development source snapshot includes an initial port to Apple's Cocoa API, and an SDL port that was used as a stepping stone to the Cocoa port.
The Carbon API, which Mini vMac currently uses for the Macintosh OS X version, is nearly defunct. Apple continues to label more and more of it as deprecated.
The first step to an Cocoa port was to port to the SDL library (Simple DirectMedia Layer). Programs built upon SDL can be easily compiled to run on many platforms, including Cocoa on OS X. But I started with Linux. The Mini vMac build system option for this port is "-t wx86 -api sdl". Then I got it to work in OS X. When I compiled SDL on OS X it turned out to be 64 bit, so I just used that, and added a "-t mc64" target to the build system, for Macintosh x86-64. (The Carbon API can't be used for x86-64, which is why this target wasn't already supported.) So the build system option for this SDL port is "-t mc64 -api sdl -cl". (Only the command lines tools are supported so far, not the XCode IDE.) Eventually I could add support for the other platforms supported by SDL.
The basics of Mini vMac work in the SDL ports. But some features of Mini vMac can't be implemented on top of SDL. So the SDL ports are not intended for practical use, but as a stepping stone to more native ports.
The next step was to merge the source code for Mini vMac and SDL into a single program. Then I removed all SDL source code for platforms other than Cocoa. Then I removed SDL code that Mini vMac didn't make use of. Then I started cleaning things up. And in the end I had a basic port of Mini vMac to Cocoa. (The build system option is "-t mc64 -api cco -cl".)
This was all a lengthy process, but still much easier than directly trying to learn Objective C and Cocoa and writing a port from scratch. Now that I have some practical feel for how they are used, I am starting to to wade into the documentation for a better understanding. It took me a day just to pick out about 100 PDF files from Apple that seemed most relevant.
Much work remains before the Cocoa port can replace the Carbon Port for OS X. There are missing features to implement, and also I have to review the code and decide where there would be more appropriate ways of implementing things for Mini vMac.
Thanks to Guillermo Graña Gomez, nicola giacobbe, Adam Hope, Édouard Canot for sponsoring the Gryphel project, including web hosting for October.
Thanks to a report from "AP", today's snapshot also corrects a bug in emulating the DIVS.L instruction of the 68020 (for Macintosh II emulation).
Another fix is that the Windows version now responds to the WM_QUERYENDSESSION message, so that if you try to shut down your computer with Mini vMac running (with mounted disk images), then Mini vMac will complain and stop the shut down.
Also, thanks to a report from William Grana, I've adjusted the build system to suppress warning messages that were generated when compiling the Macintosh II emulation with Microsoft Visual C++.
Thanks to a report from "David", I've updated AutQuit7, AutoQuit, and EjctQuit with the fix previously applied to the Mini vMac build system, so that they will work in emulators such as Basilisk II and SheepShaver.
I've added ShowSizes, The Tilery, ASCII Chart, Camera, Print2Pict, ScreenSnap, O'Clock, attoClock, StopWatch, LightningPaint, View Picture, XLisp-Plus, Zoom Lens, Moon Tool, MacROT13, and SoundHandle to the software hosted by the Gryphel Project.
August 6, 2012
I've begun making Recipes for Mini vMac. These are How-To guides that go beyond the Getting Started guide. Each is illustrated, perhaps too extensively illustrated. It was easiest to make the screen snapshots first, and then write some text around them. I'd been intending to make these for a long time, but a complaint about the documentation being inadequate got me to work on it now.
Also lately, I've begun to seriously study the source code to the MESS emulator, in hopes of getting ideas from all the work that has been done in it lately for Macintosh 680x0 emulation, and adapting them to Mini vMac. And so making the results of that work more accessible, in my opinion. (I can't copy code directly, both because of incompatible licenses, and because of the very different architectures of the programs.) So far I have gotten MESS to compile and run, and then I've cut out a lot of code not related to Macintosh emulation, reducing the approximately 400 MB of source to under 10 MB, which is more manageable, but still a lot to study.
I've added Lunar Phantom, FKey Manager, ResCompare, Calendar, MacAstro, Finder Info, and Creator Changer to the software hosted by the Gryphel Project. Lunar Phantom is used in one of the new recipes to illustrate "wrapping" a game. Some of the others may be used in future recipes.
Thanks to Charles Lehner, Evan Appelman, Fabian Hahn, and Micah Bly for sponsoring web hosting for the Gryphel project for July, August, and most of September. And thanks to andrew macfarlane, Matthew Nash, Cameron Harvey for sponsoring a memory upgrade, which allows running multiple VMware Fusion virtual machines at the same time, speeding up compiling of Mini vMac variations.
And thanks to Landon Fuller for sponsoring living expenses for one half day of work on the Gryphel Project today. I've decided to reallocate some previous non specific donations that were not yet used to this purpose. This may help in getting me to find 4 hour blocks of time to focus only on Gryphel project work. Thanks to Landon Fuller, Dmitry Larionov, Todd Katz Kevin Grabher, and Evan Appelman for sponsoring an additional 7 half days, to be scheduled in the future.
June 30, 2012
The latest Mini vMac 3.3.2 alpha improves sound in the X versions, and has a few miscellaneous fixes.
The X versions can now be compiled to play sound using the Open Sound System (OSS) API, in addition to the Linux-only ALSA that was previously supported. A new build system option, “-snd-api”, can be used to select which API to use. The sound API is normally selected automatically, using ALSA for Linux, and OSS for everything else, but it is possible to choose the OSS API for Linux (using “-snd-api ddsp”). Generally, an implementation of an OSS compatible API for each operating system is used, and not the official OSS itself. In the future, it would be possible to add support for a more native sound API for each operating system.
Sound is now enabled by default on FreeBSD and NetBSD. Sound compiles without problems on Dragonfly BSD and OpenIndiana, but I have not been able to test on these yet. Getting sound on Dragonfly BSD seems to require some manual setting up. OpenIndiana doesn't seem to produce any sound at all in VMware Fusion. Sound also compiles without problems on OpenBSD, but it doesn't work - setting the desired sample rate fails. Minix doesn't really seem to support sound yet.
In the Linux version, using ALSA to play sound, snd_pcm_start was called before putting any sound samples in the ALSA buffer. This is not the way ALSA is meant to be used, and could cause stuttering at the beginning, or according to one report (by “Éric”), prevent sound from working at all.
In the Linux version, when playing sound with ALSA, snd_pcm_delay is no longer called. The delay until a sample is played is not really relevant. What Mini vMac needs to know is time to buffer underrun. So Mini vMac now looks at buffer size minus the available space in the buffer, which may be more useful, for the purpose of preventing buffer underrun while minimizing latency.
The Windows version now maps the Enter key on the numeric keypad to the Macintosh Enter key. It can now distinguish that key from the Enter key on the main keyboard, which is mapped to the Macintosh Return Key. There was previously no way to type the Macintosh Enter key. Thanks to “Alex” for pointing out this issue.
In the Windows version, in Full Screen Mode, the check for whether a key down event is an autorepeated key is incorrect. So potentially keys could have been ignored when they shouldn't have been. I've removed the check, since it isn't clear how to do so correctly (when using a "low level keyboard hook"). This doesn't affect Macintosh emulation, since there is an additional check for redundant events. It can affect the Control mode, such as when holding down Control-M.
The Windows CE version suffered bit rot. It now compiles and at least works on the Microsoft Device Emulator with Windows Mobile Version 5.0. I have no idea if it works on real hardware. This port was starting to interfere with maintaining the main Windows version, and the choice was to remove it entirely or make it maintainable.
The hack that allows extra large amounts of Video RAM in the Macintosh II emulation wasn't working properly because an array used for address space translation in the CPU emulation wasn't allocated large enough. Now the build system chooses the allocation size. (This problem was observed for 1024x768 with millions of colors.) Further detail: Each NuBus card gets only 1M of address space when the computer is in 24 bit mode. And a Mac II seems to usually draw in 24 bit mode. When more Video RAM is needed for the requested compile time options, Mini vMac uses address space from adjacent NuBus slots.
This Video RAM issue affected the requested variation number 507 of the Mini vMac Variations service. I've updated this variation, and all the rest, to Mini vMac 3.3.2.
May 29, 2012
Today's Mini vMac 3.3.1 alpha supports more host targets, has a few miscellaneous fixes, and adds a Polish translation.
Przemysław Buczkowski contributed the Polish strings for the Mini vMac user interface. They can be selected in the build system with “-lang pol”. This is the first translation that uses characters not in the MacRoman character set.
I figured out how to set up the QEMU emulator with some Debian Linux images provided by Aurélien Jarno. This so far allows adding support for Linux on ARM (Debian armel port), selected with “-t larm” in the build system, and to provide better support for Linux on PPC, selected with the existing “-t lppc” option in the build system.
I've also figured out how to extract compiled applications out of my VMware image of Minix 3.2. The compiled applications are very large, apparently because Minix doesn't yet implement shared libraries. (The build system now supports Minix 3.2.0 instead of Minix 3.1.8.)
So the Mini vMac 3.3.1 downloads page now includes versions for Linux on ARM, Linux on PPC, and Minix 3.2.
The X Window versions as of Mini vMac 3.3.0 look for the application path and name. Since this might not give the desired results, there are now command line options to override them. “-d [directory_path]”, in which [directory_path] is used instead of the application directory when looking for the ROM image, and disk1.dsk and so on files. And “-n [app_name]”, in which [app_name] is used instead of the application name for the title of the Mini vMac window.
In X Window versions of Mini vMac, when using the Mini vMac extension to create a file on the host system, such as with ExportFl, a save dialog is not implemented. Previously the file would simply be created in the application directory with the asked for name. This was not safe, at worst it allows a program running in Mini vMac to replace the Mini vMac application. So now files will instead be created in a folder named "output" in the directory containing the application. This folder will be created if it does not exist.
In the Microsoft Windows version, if a path to a disk image is passed to Mini vMac on the command line that is longer than is legal for a path, a buffer overflow would result. This is fixed.
If the host computer is not fast enough for Mini vMac to run at 1x speeds, then Mini vMac would not run smoothly, pausing for a few seconds periodically. The test for this situation was incorrect, and a one byte counter would overflow. (Have such counters as small as possible makes it easier to detect bugs like this.)
When using the new magnification factor option set to 3x, with a particular real and emulated screen sizes, I noticed autoscroll would not reveal the last row of pixels. This was because Mini vMac constrains scrolling to multiples of two pixels (so scrolling of the standard gray pattern looks better) and because the emulated Mac constrains the mouse to one pixel less than the bottom and the right. So to avoid this issue, Mini vMac now constrains the emulated width and height of the visible area in full screen mode to a multiple of two (but only if the visible area is smaller than the emulated screen size).
For the Mac II emulation, there is now a flag that the platform dependent code can set at program start up to indicate that the requested color setting is supported. The platform independent code will check if color is supported before emulating a color machine. This means that a version of Mini vMac compiled for color will still at least run in Black and White if displaying color is not possible.
The build system uses a default color depth for Mac II emulation of 256 colors rather than Black and white.
For Macintosh II emulation, AutoSlow is now disabled by default. AutoSlow may need some further tuning to work well with Mac II emulation.
Using the build system option "-lt" no longer causes speed to default to 1x. Mike Fort's LocalTalk emulation appears to work just as well at higher speeds.
When compiling the Mac 68K version of Mini vMac, the build system now generates some assembly language glue that allows the "large" code model to work correctly with the standard libraries, and not cause linker errors if Mini vMac grew larger.
April 18, 2012
Mini vMac 3.3.0 is the first alpha of the the 3.3.x branch. The Changes file lists what has been done so far since Mini vMac 3.2.3, with the highlights being Mike Fort's LocalTalk emulation, and work on the X versions.
I think it is important to regularly test that the development branch compiles on all supported platforms, and provide the compiled applications for people to try. Instead of only providing source snapshots, as I've been doing for some months.
There is a new permutation of the Mini vMac Variations service. It is a hybrid of the Mini vMac 3.1.x Variation service and the Mini vMac 3.2.x custom variations. For Mini vMac 3.3.x, you can request variations that I will compile for you, and try them as long as you like, before purchasing an activation code. This may be feasible now that I have the process of compiling variations pretty well automated.
Though Mini vMac 3.3.0 is an alpha version, activation codes purchased now will still be good for all later versions in the 3.3.x branch. Activation codes purchased previously for 3.1.x will still work for 3.3.x variations. (Probably new codes will be required for 3.4.x.)
April 15, 2012
Gil Osher has updated his Mini vMac for Android port to version 3.2.3 of Mini vMac. Compiled variations may be downloaded from the Android Market for Macintosh Plus (free) and Macintosh II ($1.99) emulation. Source code is available on GitHub.
March 23, 2012
Today's Development source snapshot includes initial support for color in the X Version (for Mac II emulation), and a build system option for higher magnification factors than 2.
The X Version so far only supports 24 bit "TrueColor", and has a few other limitations on format. I doubt that anything besides TrueColor is used on modern machines, and so probably won't support the other options. Other depths such as 15, 16, and 32 bits may be used, and so probably should be supported, if I can find a way to test them.
A new build system option "-mf" allows changing magnification from the default 2. For example, "-mf 3" sets the magnification to 3. This may be useful as modern screens get higher resolutions. The option "-mf 1" disables magnification (removing the Control-M command). At least for now, the magnification factor must be an integer.
Though it wasn't previously supported by the build system, the code for the OS X version already allowed higher magnification. The Windows version also had such code, though it was slightly broken. These versions were easy, because the APIs have support for magnification. The X API doesn't seem to have such support. Mini vMac previously implemented it's own code for 2x magnification.
Today's X version implements a more general magnification algorithm that is also simpler and faster, using a table to process one byte at time. The OS X version now also uses a table to process a byte at time when the color depth is 3 or less. Even though magnification doesn't need to be handled, it is still simpler and faster than the previous methods.
The OS X and X versions now take advantage of knowing the left and right of the changed area to reduce the work when translating between the emulated screen format and the host screen format. Recent versions of Mini vMac started finding the left and right of the changed area, to allow autoslow to work better, and to reduce drawing to the real screen. But the translation step hadn't been updated.
The Mini vMac build system should now work properly in other emulators such as SheepShaver. It was anonymously reported that the build system would crash emulators. The test for whether the build system was running in Mini vMac (so that the resulting archive may be exported to the host) was not good enough.
The same report also mentioned a number of unused parameters warnings when compiling the SCC emulation, which should be fixed now.
I've recently tried out Windows 8 Consumer Preview in VMware Fusion for a few minutes, and Mini vMac seemed to work fine. (In the desktop environment of course, not Metro.)
I've used EZChat quite a bit in testing the LocalTalk emulation as I merged it into my version of the code. I was able to contact the author of EZChat, and purchased a license for it.
March 2, 2012
Today's Development source snapshot includes a couple fixes from Mike Fort that make LocalTalk more reliable. The problem of occasional lost packets seems to be solved.
It also includes various maintenance stuff I've done on the LocalTalk emulation, such as splitting the platform specific code out to a separate file, which should make it easier to port to other platforms besides OS X. Actually the same Berkeley Packet Filter code probably should be able to work on various BSDs, and perhaps Linux. For Windows, perhaps the WinPcap library could be used.
I also made the LocalTalk emulation check the "Addr Search Mode (SDLC)" flag before discarding packets meant for other machines. This allows programs like "Network Watch" (from Cayman Systems) to work.
February 26, 2012
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.
February 12, 2012
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.
January 29, 2012
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.
January 22, 2012
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
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.
December 20, 2011
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.
Thanks to Kevin Grabher and Todd Katz for sponsoring storage for the Gryphel project.
December 13, 2011
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
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
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
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.
In other news, I've resigned from recent paid work to have more time for Mini vMac, and the Gryphel project.
September 20, 2011
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.
OLD NEWS - Previous release notes