News : (Twitter)
July 29, 2014
I've added MacPaint 1.3 to the software hosted by the Gryphel Project. MacPaint was one of the very first applications available for the Macintosh, written by Bill Atkinson, the author of QuickDraw, the core Macintosh graphics library.
In 2010 the source code of MacPaint was donated by Apple to the Computer History Museum, for non-commercial use. I compiled the application from this source, and am making the result publicly available, after receiving assurance that this is a permitted use.
I modified the source to compile in MPW Pascal, so my version is not identical to the original. I have added to the version string and the about dialog, to note that this is a modified version.
July 27, 2014
I've added True Clock to the software hosted by the Gryphel Project.
July 25, 2014
May 20, 2014
Today’s development version fixes a bug reported by Ryan Schmidt, in the new “Export” command of the Build System, where the initial name of the file in the Save dialog was not initialized.
March 19, 2014
MiniUnZp is a new application to use in Mini vMac to unzip a compressed archive created by OS X, preserving some of the Macintosh specific information: the file type, the file creator, and the resource fork. It is currently extremely preliminary, but it functions, and may be useful as is. MiniUnZp is based upon Info-ZIP code copyright Mark Adler and many others.
MiniUnZp was created by starting from the Info-ZIP unip code, and stripping out anything not needed to unzip a single archive named "arc.zip" on OS X. Next, this code was made to compile for Mac 680x0, by creating a library that implements c library functions, using the Classic Mac API. Only the very minimum amount of c library functions needed for MiniUnZp were implemented. Still this library could be useful for other projects, and gradually expanded. After this was gotten working, a post processing pass was created to look for the Macintosh specific information that OS X saves in a folder “__MACOSX”, and another pass to delete (for now) “.DS_Store” files.
The next step would be to merge the unzip code and the library glue to create a better Macintosh port. In particular, to make file handling more native. Also it would be better to use Macintosh handles rather than allocating pointers.
March 15, 2014
In today’s development version:
The Build System window now has a progress indicator. The last development version merged in code from ExportFl to support dropping files onto the application icon, and today’s version merges in more code for additional features. The progress indicator at the bottom of the window can display information about what is going on. Clicking on it is equivalent to choosing the “Go” command from the File menu. The Build System can now potentially allow the user interface to remain functional while processing. But calls have to be added to the processing code to allow this, calls that report progress and can yield time to the user interface code.
The Build System now supports drag and drop (when the drag and drop operating system software is present) onto its window, which has equivalent function to dropping a file on the application icon.
The Build System has a new “Import” command in the File menu, which has equivalent function to dropping a file on the application icon.
The Build System has a new “Export” command in the File menu, which saves the window’s contents to a new file, that the “Import” command can read. The new file has the creator set to the Build System, so double clicking on the file will work. The Build System application defines an icon for the files it saves.
March 9, 2014
In today’s development version:
I've added a requested feature that can help in automating the build process. Files can now be dropped onto the build system application icon. This is equivalent to copying the contents of the file, and pasting it into the build system window after removing any existing text (such as by the ‘Select All’ and ‘Clear’ commands), and then choosing the ‘Go’ command. Multiple files can be dropped, and they will be all be processed. (Though if there is an error, that error is reported, and all remaining files are forgotten.) If the build system application was not yet running when icons are dropped on it, then the application automatically quits after processing all the files. Other ways of generating kAEOpenDocuments apple events, besides dropping files on the application icon, should also work, such as AppleScript.
March 5, 2014
In today’s development version:
Changed URL displayed in about screen to "http://www.gryphel.com/c/minivmac/".
The Pocket PC version wouldn't compile with "-im 1". Removing the call to GetShortPathName for Pocket PC allows it to compile, but then registration won't work if the path of the application contains spaces. Upon further investigation, it seems all that is needed is to put the application path in quotes when setting registry entries, so GetShortPathName isn't needed. So have made this change for both Pocket PC and the regular Windows version.
Renamed the Build System application to include branch information - "MnvM_b34". This makes it easier to deal with the Stable and Development branches at the same time.
Prevent warning about unused code when using options "-var-fullscreen 0 -fullscreen 1 -mf 1".
The Build System now generates a compile time check in a configuration file when compiling with gcc for x86-64 or x86-32, to make sure the 64 bit configuration is not compiled with a 32 bit compiler, or vice versa. This can result (especially when used with "-no-asm"), in a binary that almost but doesn't quite work correctly. The check is for the wrong predefine being present, rather checking that the correct predefine exists, to reduce the chance of incorrectly giving an error on an unusual compiler version.
March 1, 2014
Work has begun on a new branch: Mini vMac 3.4.x. So far it contains a few fixes to bugs that prevented some variations from compiling. And also new for this branch is allowing variation requests compiled from the latest development source, at the Mini vMac 3.4 Variations service. In other news, the Mini vMac Variations service for the stable branch has passed 500 variations served.
The specific changes in 3.4, version 140226 are:
The Windows version wouldn't compile with magnification disabled (-mf 1) and screen depth (-depth) of thousands, millions, or 4 colors. (It's not clear to me why disabling magnification is a popular request.)
The Classic Mac versions ("-t m68k" and "-t mppc") didn't always request a large enough memory allocation in the SIZE resource, particulary for large screen sizes and color depths. The build system now tries to compute the memory requirements more exactly.
The hack allowing the emulated Mac Plus (and other models without Color Quickdraw) to have a larger screen always allocated enough memory for a screen with up to 1048576 pixels. It now allocates more closely to just the memory needed, and can handle screens up to 2097152 pixels (the size of the unused area in the address space that is used by this hack). I believe the previous limitation was mostly consequence of how earlier versions handled memory access in the CPU emulator. The build system will now give an error when the requested screen size contains more than 2097152 pixels (before it would compile fine and just not work right).
By the way, the Mini vMac 3.4 branch is located on www.gryphel.com, instead of on SourceForge. This is part of considering gradually moving all parts of the Gryphel Project to www.gryphel.com. One reason is that it makes it simpler to suggest that people should download Mini vMac and other related gryphel project software only from www.gryphel.com, unless they have good reason to trust the source. I have now seen for myself something claiming to contain Mini vMac which was actually malware, after receiving a couple reports indicating such existed.
January 17, 2014
Mini vMac 3.3.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.2.3.
There have been no reports so far of problems in version 3.3.3 that are not in 3.2.3, the previous stable version. But there has been a second report of drawing problems in Linux. I'd guess that some combinations of drivers/hardware do not properly implement X11 XYBitmap, which is probably not used much in modern software. In the future I might change Mini vMac on X11 to convert the image to color before passing it to X11, at least by default, even though that would potentially be much less efficient.
The Mini vMac Variations service should be simpler to use. It again has a form with pop up menus and check boxes for available options, rather than a single text field. Some invalid configurations are automatically detected. There is no longer a need for an activation code. The service is now free, with a $5 donation suggested.
December 17, 2013
I still don't have much time for working on Mini vMac, but I'd like to get out the work done already into the stable version before it is obsolete. The largest amount of work is in improvements to the X Window versions. The standard variation of the Windows version (with Macintosh Plus emulation) has a few small bug fixes, and the OS X version has even less (it's what I use, and pretty much just works already). But there is one improvement in all versions: more efficient drawing. Outside of the standard variation, of note are Mike Fort's LocalTalk emulation, a Polish translation by Przemysław Buczkowski, fixes for a number of bugs in 68020 emulation reported by “AP”, and initial ports to the Cocoa and SDL API's.
Changes since the May 8 development snapshot:
There were a number of bugs in the 68020 emulation (for Mac II) reported by “AP”. The BFFFO instruction was broken. And, all bit field operations on a register now use rotate rather than shift, as selected bits can be non contiguous. Bit field operations on memory now try to only operate on as many bytes as needed - previously it always operated on 5 bytes, which may have undesirable effects if operating on a memory mapped device. The “MoveP.L <ea>, Dn” instruction mixed up the order of shifting and masking.
Also, there are improvements to the SDL port. Color works (for Mac II emulation). There is more accurate mouse emulation in full screen mode. And the video output is more optimized. (The SDL port was created as a stepping stone to a native Cocoa port, but it can also be used as is to port to other platforms supported by SDL. Such as the TI-Nspire port by Jim Bauwens.)
The WinCE version can again be compiled. The code added to prevent Windows shut down wouldn't compile on WinCE and so has been made conditional. And one other fix is to allow color to work in the X Window versions when compiled with the magnify option disabled.
Previously requested variations have been updated to 3.3.3 on the Mini vMac Variations service.
In other news, Steve at Big Mess o' Wires (previously mentioned here for creating a Mac Plus emulator with an FPGA), has now created, and offers for sale, the Macintosh Floppy Emu. This allows an old Macintosh to access a disk image saved on an SD card, making it much easier to transfer files to and from a modern computer.
August 29, 2013
Mini vMac in the news : John Leake of RetroMacCast has built a “Mini Mac”, a working one third scale replica of the original Macintosh, containing a Raspberry Pi running Mini vMac. This has been reported in a number of places : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25, among others.
July 30, 2013
Matthias Melcher has created “mosrun”, a program for running “MPW tools on Mac OS X, Linux, and MSWindows.” It is like Executor in not requiring a ROM image or system software from Apple, but for running MPW (Macintosh Programmer's Workshop) tools instead of normal Macintosh 680x0 programs. The “project is still in the proof-of-concept stage”, but “the code basically works”.
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.
OLD NEWS - Previous release notes