:
March 6, 2015 - permanent link
There is a new Mini vMac Development source snapshot, which fixes several reported bugs, adds a couple compile time options, and makes a significant change in how the platform independent and platform dependent code interact.
------
Thanks to Stephen Chamberlin, Marc Schaedle, Chaowang Zhang, Daniel Shuman, Ursula Katoll, Edward Mendelson, and Gottfried Haider for sponsoring the Gryphel project web hosting with Rackspace for February, January, December 2014, August, July, May, April, and March. (I've returned to the previous method of accounting for how donations are used.)
------
bug fixes:
* The OS X version of Mini vMac was using the wrong syntax for the value of the LSRequiresCarbon key in the Info.plist file in the application bundle, as reported by Ryan Schmidt.
* The Linux, and other X, versions of Mini vMac would crash when exporting a file, if the “out” folder in the application directory didn't exist, and Mini vMac lacked permission to create it, due to not properly handling errors in the routine “FindOrMakeChild” in the source file “MYOSGLUE.c”, as reported by Éric of Montréal.
* The Linux, and other X, versions of Mini vMac can crash if the HOME environment variable is not set, due to missing error checking (which in turn was due to incorrectly disabling an alternate implementation), as reported by fzn.
* The Linux, and other X, versions of Mini vMac will now look for the ROM image in the application directory before looking in the “~/.gryphel/mnvm_rom”, instead of after, to match the behavior of the other ports. This makes it easier to have a ROM image for general use, and still be able try out another ROM image.
* The autoscroll feature (used in full screen mode when the emulated screen size is larger than the real screen) would not work when the emulation was stopped (using the “Stopped toggle” in the “S” command of the Control Mode).
* In the Cocoa port, Mini vMac would fail to mount a disk image located on a file system that doesn't support locking. It now checks the result from the flock call, and only prevents mounting if the file is already locked, and doesn't prevent mounting for other errors.
* The WinCE version wouldn't compile. WM_INPUTLANGCHANGE changed events used by the new keyboard unscrambling code for Windows don't seem to be present in WinCE.
new compile time options:
* A new build system option “-svl” selects the initial value of the Sound Volume in the Parameter RAM.
* A new build system option “-sss” selects the output Sound Sample Size.
some internal changes with visible consequences:
* To make Mini vMac simpler and more maintainable, the interaction between platform dependent code and platform independent code has been changed a bit. Instead of the platform dependent code calling a routine to emulate one tick (sixtieth of a second) whenever appropriate, the main loop of the program is now in platform independent code, which periodically calls platform dependent code to check for events. A visible consequence of this is that the emulation will now stop running in certain circumstances when it used to continue running, such as during the open disk image dialog. The exact situations this happens varies for each platform.
* To minimize glitches in sound output when emulation starts, stops, or just isn't running fast enough, the sound call back functions in the various Macintosh versions and the SDL version will now try to play an appropriate transition in each of these circumstances.
* In the Cocoa port, when the platform dependent code checks for events, rather than using a time out value, it turns out there is a bit less overhead to check for events, sleep, and then check for events again. This allows matching the performance of the Carbon version, making the Cocoa version more ready for prime time. (Apple has declared Carbon very, very deprecated.)
The same fix actually also applies to Carbon. Mini vMac used to use a standard Carbon event loop with a complicated system of timer events only because a manual event loop didn't get quite as good performance. With this change, all ports can use the same platform independent event loop, as described above.
------
In other not so recent news, a number of bug reports by Steve Chamberlin led to improving FDisasm enough so that its output for the Macintosh Plus ROM can be fed to the MPW Assembler and get back the original ROM. This also works for the Mac 128/512 ROM, and the Mac SE ROM.
December 12, 2014 - permanent link
I've received permission to add Data Desk 7.0.3 to the software hosted by the Gryphel Project. A tool for Exploratory Data Analysis first released in 1986, Data Desk is one of the oldest Macintosh programs still actively developed and sold (for OS X and Windows). A version for Macintosh 680x0 is now freeware to honor Data Desk’s origin.
There are a few changes in the Mini vMac development version in recent months that I hadn't documented previously:
The Virtual-Key Codes of Microsoft Windows, that are independent of differences in keyboard hardware, turn out not to be independent of the choice of Keyboard Layout. Changing the Keyboard Layout to something other than "US" may scramble the Virtual-Key Codes, strangely enough. Mini vMac will now check the current Keyboard Layout, and attempt to unscramble the codes, so that the Keyboard Layout chosen in Macintosh operating system running within Mini vMac will work properly. There is a new build option to disable this fix, -ikb 0, because this is fairly large amount of code and US only users don't need it. But also because I'm not sure I really understand this. Why has no one complained about this issue in the last decade?
Mini vMac on Microsoft Windows will now recognize the Virtual-Key code of VK_OEM_102, and translate it to the Macintosh key code of 0x0A. This key is used for angle brackets in the German keyboard layout, for example.
A new build system option “-cbt” selects the initial value of Caret Blink Time (Rate of Insertion Point Blinking) in the Parameter RAM.
Added build system option “-t fbpc” for FreeBSD on PowerPC.
Added build system option “-t cpu”, to provide a starting point for compiling a combination of operating system and CPU that is not yet supported.
October 7, 2014 - permanent link
Mini vMac is moving back to its original home: "http://www.gryphel.com/c/minivmac". The web pages from SourceForge should now all be moved, but the file downloads are currently still on SourceForge. A few pages not directly about Mini vMac itself are also moved and accessible from "http://www.gryphel.com/".
There is no longer separate documentation for the current stable version (3.3.3) and the version in development (3.4.0 alpha). There is one set of documentation, that in places notes changes in the alpha version.
Please let me know if you notice anything broken.
July 29, 2014 - permanent link
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 - permanent link
I've added True Clock to the software hosted by the Gryphel Project.
July 25, 2014 - permanent link
Joseph V. Barrile has created and donated a second alternate Mini vMac icon.
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 - permanent link
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 - permanent link
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.
It does not make sense to combine the build options “-magnify 1” (to start with magnification on) and “-mf 1” (to disable magnification), and the Build System now prevents this.
March 9, 2014 - permanent link
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 - permanent link
In today’s development version:
Changed URL displayed in about screen to "../../c/minivmac/alpha.html".
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 - permanent link
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 - permanent link
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 - permanent link
Today’s Mini vMac 3.3.3 is the first beta of the 3.3.x branch. The Changes page lists differences from current stable 3.2.3 version.
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 - permanent link
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 - permanent link
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”.
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, 2013 - permanent link
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 - permanent link
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 - permanent link
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 - permanent link
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 - permanent link
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.
Rob Braun contributed a fix to FDisasm for disassembly of 32 bit offsets for the BSR and BRA instructions. And then he provided code to disassemble certain MMU instructions, seen in the IIsi ROM.
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 - permanent link
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 - permanent link
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.
I've added support for Linux on SPARC (“-t lspr” in the build system), again using a Debian Linux image provided by Aurélien Jarno.
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 - permanent link
Mini vMac 3.3.0 is the first alpha of 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.)
Mike Fort's LocalTalk emulation is included in Variation 182 for OS X of the Example Variations. Some software to try with this variation is hosted on the Macintosh Plus LocalTalk Software page.
April 15, 2012 - permanent link
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 - permanent link
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 added a new section to the software hosted by the Gryphel Project, and added EZChat, Net Othello, and Watch. These are software that work with Mike Fort's LocalTalk emulation.
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 - permanent link
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.