Download
|
News :
June 28, 2009 There is now a Mini vMac 3.1.1 alpha. The Mini vMac Variations service has been updated to use the new version. The new version corrects some minor problems found in the previous alpha. I've removed a warning message about "read verify" mode that I recently put in to see whether this mode is used. It turns out that it is, such as when using the Finder to copy files to an 800K disk. So sometime I should implement this mode correctly in the replacement disk driver used by Mini vMac. For now it just continues to treat it as a normal read, which isn't correct, but doesn't cause problems. The Windows call SHGetSpecialFolderPath doesn't seem to be supported in some development environments, so I've made Mini vMac dynamically load the routine instead. Mini vMac is using this routine to support finding ROM images from a central location, and to support activation of Mini vMac Variations. As reported by "macgeek417", the "-m pb100" option wouldn't compile. It will now compile, but still not do much. Making sure it compiles may help prevent bit rot until I get back to Powerbook 100 emulation. The "-min-ext" option also wouldn't compile. I've fixed this, so Mini vMac Variation number 157 is now available. The build system will now work properly from a locked disk when exporting an archive, if there is an output folder preference. (The archive is placed in the output folder, rather than in the folder containing the application.) The build system can now resolve aliases of folders, such as the output preference folder. So the output can be directed anywhere, such as to another disk. I previously incorrectly documented the output preference folder. The build system looks for "System Folder:Preferences:Gryphel:Build:output", not "System Folder:Preferences:Gryphel:output". The build system can now handle multiple sets of options at once, separated by ";". I use this in the process of compiling the set of Mini vMac Variations. To allow this to work, the build system no longer replaces the entire output folder on each run, but just replaces folders within the output folder. I've removed the "-pk" option of the build system to restrict the program to a more manageable scope. And anyway I find it more convenient to handle post processing in external scripts. The build system now has an "-an" option, for changing the programs abbreviated name, from the default "minivmac". So the Mini vMac variations are compiled with say "-an mnvm0001", instead of "-n mnvm0001-3.1.0-umch". The abbreviated name must be 8 characters or less, and should only include lowercase letters, numbers, and underscores. The Mini vMac Variations that require an activation code now have a new command: Control-P. This copies a string to the clipboard of the real computer that contains version information and an encoding of the activation code. This could be used for a scheme to allow people to "register" the variations they use, and in effect allow them to vote for what variations they think are important. June 5, 2009 I've added some more variations to the Mini vMac Variations service. Also, "macgeek417" points out that I haven't previously announced the addition of the build system option '-m SEFDHD', for emulating a Macintosh SE FDHD. It is currently identical to the Macintosh SE emulation, except for expecting a different ROM (which should be named 'SEFDHD.ROM'). This was added last year in May, thanks to reports from Steve Secker and David Sibley. June 3, 2009 The Mini vMac Variations service, which I described last week, is now live. May 27, 2009 There is now a Mini vMac 3.1.0 alpha. I've decided to make a new stable version soon, without waiting to complete the Macintosh II emulation. Since that is where most work has been done, this will be a fairly minor update. Still, the current stable version is getting old - I'd prefer any possible future derivative projects to be based on more recent code. Also, I'd like to experiment with offering a new service. A lot of the power of Mini vMac comes from the variations that can be compiled, such as emulation of different Macintosh models. However, no matter how easy I try to make it to compile variations from the source code, it has become clear that most people aren't going to do this. So I've decided to try offering some compiled variations as shareware, which people can download, try out, and purchase if they find them useful. I'm currently thinking maybe $5 for the set all of available variations (until the 3.2.0 release), perhaps using the Kagi payment processing company. If this is successful enough, it will motivate me to do it again - compiling, packaging, testing, uploading, and verifying variations of the 3.2.0 release of Mini vMac. This will be just an additional service - the default compile remains free, the source remains free (and by the GPL license must always remain available), and anyone can compile variations themselves, if they spend a little time to figure out how. Also, people can of course still make publicly available versions that they compile, and I'm pleased when they do so. To demonstrate how this might work, the alpha download page includes an "activation demo". This is a variation of Mini vMac with the larger screen hack (not all software is compatible with this, but much is), support for file tags when using disk copy 4.2 format, and allowing up to 16 mounted disks. So far it is available for Mac OS X and Windows. (Linux users are presumed to be more comfortable with compiling from source.) When first launched it prompts for an "activation code". A temporary code is provided right on this prompt - "281 953 822 340". If you type in this sequence of digits, the prompt goes away, but comes back again on the next launch. It is expecting you to type digits (0-9). You can type the spaces, but they are ignored. You can correct mistakes with the backspace (delete) key. The only penalty to using the temporary code is having to enter it on every launch - the program otherwise works as normal, and there is no time limit. If you instead type the sequence "275 227 140 839", it saves this in a preference file, and should not ask again. (I'd be interested in hearing if this doesn't work, especially on Windows Vista, where I haven't tested.) I think it is ok to have this activation demo on SourceForge, since the activation code is provided. I'll put the rest of the variations elsewhere. The source code dealing with activation is also provided, and it's not especially sophisticated. It is only intended to be a little harder to get around than it is to figure out how to compile Mini vMac from source. Beside the activation code stuff, there are also a few other new things since the last source snapshot. If Mini vMac, on Mac OS X or Windows, doesn't find the ROM file in the folder containing the application, it will now also look in a specific central location. In OS X it checks in "/Users/[your_UserName]/Library/Preferences/Gryphel/mnvm_rom/". In Windows XP, "C:\Documents and Settings\[your_UserName]\Application Data\Gryphel\mnvm_rom\". Windows 98, "C:\WINDOWS\Application Data\Gryphel\mnvm_rom\". And in Vista, I think "C:\Users\[your_UserName]\AppData\Roaming\Gryphel\mnvm_rom\". Usually "mnvm_rom" would be an alias (on OS X, on Windows this is called a short cut) to where ever you keep your ROM collection. This avoids having to create an alias to the ROM image for each emulated Mac you use. There are also some assorted clean up of the emulated video and disk drivers. Also, thanks to an anonymous tip, I cleaned up some code that may cause compiler warnings about security dangers. (I believe it was ok as actually used, but poor style.) "macgeek417" pointed out that the Mac Plus emulation will work with 128K memory, so the build system now allows "-m Plus -mem 128K". The alternate keyboard mode option now gives a visual indication of the current keyboard mode, intended to be easy to see in peripheral vision, without covering up where text is normally typed. The build system will now check if the folder "System Folder:Preferences:Gryphel:output" exists, and if so direct output there, instead of "minivmac:output:". This is useful if you keep the minivmac source disk image on a flash drive, avoiding excessive wear. April 2, 2009 Todays Development source snapshot merges in code sent by "zydeco" from his iPhone/iPod Touch port that improves support for the Disk Copy 4.2 disk image format, using information found in the Lisa Emulator Project by Ray A. Arachelian. I've also tried adding support for file tags to Mini vMac. There has been no further progress in Macintosh II emulation since the last snapshot. And I haven't been keeping up with correspondence. But the good news is that I think I'm gradually getting my health back. The code from zydeco means that Mini vMac will now get the correct size of the data in a Disk Copy 4.2 disk image, and will identify such an image even if it is not in HFS or MFS format. Also, with the build system option "-sony-sum 1", Mini vMac will update the checksum in a Disk Copy 4.2 disk image when it is unmounted. This prevents other programs that deal with such images from complaining about an invalid checksum. (I didn't include this by default, because it makes Mini vMac slightly bigger and slower.) With the build system option "-sony-tag 1", Mini vMac tries to support file tags. There are an additional 12 bytes for each 512 byte block on a 400K or 800K floppy disk, containing some additional information that was supposed to aid in recovering damaged disks, but was never actually used much. The Disk Copy 4.2 disk image format can support these tags. (The more usual raw format, such as found in Blanks, does not.) The build system also now has the option "-sony-dc42 0" to completely disable support for disk images in disk copy 4.2 format. This could be useful when trying to compile the smallest and simplest version of Mini vMac possible for some specific purpose. It should not be used when compiling a version of Mini vMac for general distribution, because a primary goal of Mini vMac is that disk images that work with any past version of the program should also work with the current and any future version (at least when default compile options are used). To make it easier to support file tags, and also easier to make (and debug) other changes, I've moved most of the logic of the replacement disk driver out of the 68k code and into the main Mini vMac program. This actually is moving back closer to how vMac works. But it still avoids having the main program try to call back into the 68k code, which I never got to work reliably. I've made a number of small changes to the replacement disk driver that I think make it act closer to original Apple versions. (But which don't make any known observable difference.) One more change in this snapshot is that it supports Microsoft Visual Studio 2008 Express, using "-t wx86 -ev 9000" in the build system. January 24, 2009 For the 25th anniversary of the Macintosh, I've greatly expanded the "Books about Macintosh 680x0" section, by a factor of 10, to over 600 books. I've also put back in the Amazon links to make it easier to acquire them. The hope is to encourage preservation of these books by helping to encourage a market for them. Also, buying books through the Amazon links will help support the maintainence and further development of Mini vMac. December 19, 2008 I am travelling for about a month mostly without internet access. December 6, 2008 The latest Development source snapshot supports color in the Windows version for the Mac II emulation. (Previously color only worked in OS X.) It currently uses StretchDIBits for all color drawing in Windows. I'm not sure if this will give adequate performance on all versions of Windows on all hardware. It seems to work ok in Windows 98 running in VMware Fusion, which is all I've tried so far. As a reminder, these development snapshots are not betas, or even alphas, they are just work in progress. I'll accept bug reports, but I'm not particularly interested in having people test the snapshots. Most people should stick with the stable version. The reason for the snapshots is to conduct development more openly, since Mini vMac is open source. The main practical uses for the snapshots are to assure people that Mini vMac is actively developed, and for backup. There have been complaints about the rarity of the Macintosh II. So this snapshot also supports emulation with the Macintosh IIx ROM, using '-m IIx' in the build system. The ROM image should be named 'MacIIx.ROM'. (The ROMs in the IIcx, II FDHD, and the SE/30 are supposed to be identical to the one in IIx. Actually I don't own a IIx, I have a IIcx, donated by Lil and Sherm Sundet.) This doesn't really emulate a Macintosh IIx yet, it just accepts the IIx ROM and emulates the Macintosh II hardware, which seems to work ok. I haven't looked closely yet at what the differences should be. (One main difference is that a IIx should have a 68030 instead of 68020 CPU.) There is a new memory allocation scheme in this snapshot, so the the platform dependent code doesn't need to know about each allocation made by the platform independent code. This made it simpler to fix a problem with compiling the CPU emulation code for Macintosh 680x0. The build system now supports Xcode 3.1, using the option "-ev 3100". Mini vMac compiles without warnings, which wasn't possible with the SDK that comes with Xcode 2.4.1. The build system can now be compiled with the final version of MPW, still available from Apple, rather than only with MPW 3. Unfortunately, the final MPW doesn't quite work yet in Mini vMac, but I hope to make this work in the not too distant future (by implementing the FPU in the Macintosh II emulation). I also went further, as far as porting the build system to the Xcode tools on Intel OS X, but I'm not sure that I'll keep this. In unrelated news, thanks to ClockWise of Emaculation, for pointing out that Gemulator is now open source. Or at least the source is available. Looking at it so far, I can't tell under what license. The copyright notices seem to just say "All Rights Reserved." Also, the interesting (to me) bits seem to be missing. The "mac.vm" folder, which I would guess should implement the Macintosh emulation, just contains empty files. Anyway, Gemulator is supposed to be able to emulate a Macintosh Plus in addition to Atari computers, and in this release also emulate later models such as the Macintosh II. But so far I didn't get it to work in Windows 98 in VMware Fusion (specifying a disk image seems to be broken), I might try later using a later version of Windows. November 20, 2008 "zydeco" has made "an iPhone/iPod Touch port of Mini vMac, for jailbroken iPhone OS 2.x devices". Thanks to David Sibley for pointing out this news. I have been ignoring the iPhone myself, since my understanding is that Apple's restrictions on non hacked iPhones mean that emulators (and perhaps also GPL licensed software) are not welcome, and I have no interest in going against the wishes of Apple. But even I find this port interesting and useful, since it may make it much easier to port Mini vMac to the Cocoa API for OS X, as may eventually be necessary (Apple is ever more strongly discouraging use of the Carbon API that the current OS X port is based on). October 17, 2008 Thanks to "Gord" for pointing out to me the news that the source code for Executor has been released. I think that an interesting use of it could be to create an open source ROM replacement for Mini vMac. Unfortunately, I can't work on this myself since I have looked a lot at Apple's ROMs. (Executor is a "clean room" emulator.) October 13, 2008 Today's Development source snapshot adds color to the Mac II emulation. So far this only works in OS X, with other platforms to be implemented later. The desired color depth is chosen at compile time, with the "-depth" option in the build system. "-depth 0" is black and white (the default for now), "-depth 1" is 2 bit color (4 colors), "-depth 2" is 4 bit color (16 colors), "-depth 3" is 8 bit color (256 colors), "-depth 4" is 16 bit color (thousands), and "-depth 5" is 32 bit color (millions). These options only work with the Macintosh II emulation ('-m II'). Color depth is a compile time option, instead of run time option, to help keep Mini vMac simple and small. However, regardless of the chosen color depth, Black and White is also available, and can be selected from the "Monitors" control panel. (In fact, you may not see color until selecting it from the "Monitors" control panel.) The FPU and ASC are still not implemented, which sharply limits what programs will work without crashing (which I may not have made clear enough before). Two programs that will work nicely, in color, are "Slime Invaders 2.0.7" by Ingemar Ragnemalm and "Glider 4.10" by John Calhoun, which are both listed in the Arcade Games page. Besides adding color, this snapshot also patches out the RAM checking at start up code from the Macintosh II ROM (as is already done for other models), and initializes the PRAM more suitably for a Macintosh II. Together, these allow the Macintosh II emulation to start up much faster. September 6, 2008 The next Development source snapshot fixes the cursor display issue in the Mac II emulation (by implementing the VBL interrupt in the emulated video card). So now this emulation can be perfectly useable for long stretches of time, until it attempts to play sound or do any floating point arithmetic. The FPU and ASC emulation need to be worked on. It is still black and white only for now. (The build option for Macintosh II emulation is '-m II'.) Besides the documentation from Apple (such as "Designing Cards and Drivers for Macintosh II and Macintosh SE"), the source code for the Basilisk II emulator has been a useful reference. Thanks. Also thanks to Jonathan and Shelly Pratt, for making possible this work. There are a number of other changes besides the cursor display fix. The Mac II emulation can now support other screen sizes, at compile time with the -hres and -vres options. The default is 640x480, but 800x600 for example can be selected with '-hres 800 -vres 600'. The MacsBug debugging software operates correctly, unlike when using the larger screen hack implemented for other Macintosh models. (The video card ROM, which lists the available modes, is now created dynamically at startup. Only the driver code is precompiled. The source to this driver is now included in the snapshot. I forgot to include it in the previous snapshot.) The Mac II emulation can now use 8M of memory, twice the 4M limit on all previous versions of Mini vMac. The build option is '-mem 8M'. It can also use '-mem 5M', '-mem 4M', '-mem 2M', and '-mem 1M'. The '-m' option now checks that it's argument is valid for the machine being emulated. So the Mac II for example has two banks of memory, each of which can contain 1M or 4M or none (or higher on the real machine, but that isn't useful with 24 bit memory addressing). By the way, the Mac II emulation in Mini vMac does implement 32 bit addressing, as it is required to even boot, but the emulation is optimized for 24 bit addressing. The 32 bit addressing mode is significantly slower. The Mac II emulation now implements the automatic power off at shutdown. That is, Mini vMac will quit automatically. Besides all the Mac II emulation work, this snapshot also has an initial port to Gtk. This will allow the Linux version to better match the other ports, with menus and an open file dialog. It also will make possible a port to Maemo, which is based on Gtk. The build option is '-t lx86 -api gtk'. (The build system now optionally allows you to choose what API to use, instead of automatically setting it from the selected target.) August 3, 2008 Emaculation.com, which years ago was the first to announce the existence of Mini vMac, now has an illustrated guide to "Setting up System 6.0.8 on Mini vMac for Windows", written by ClockWise. He has also updated the vMac page on Emaculation with information about Mini vMac. June 10, 2008 The latest Development source snapshot has the Mac II emulation getting close to useable. The video now works, but there is still an issue with cursor display. I have an idea of what to fix next, as time permits. My year of mostly working full time on Mini vMac has ended. I intend to continue development of Mini vMac, but it is likely to be slower. April 25, 2008 Thanks to prompting from Steve Secker, I've revised the AutoQuit documentation to try to make it clearer. I also have repackaged the AutoQuit archive (and also the EjctQuit, DAOpener, DAFKEY, and Gryversi archives) to conform to my currently preferred format (zipped hfs disk image with checksum). There is no change to the software. April 22, 2008 Today's Development source snapshot can now emulate a Macintosh II, sort of. It doesn't emulate a video card yet, so it is not too useful. But it does successfully boot System 6.0.8, run an application, and then run AutoQuit. Mostly it demonstrates that progress is being made. (The build option is '-m II'.) The snapshot also contains the work done so far on PowerBook 100 emulation. (The build option is '-m PB100'.) It gets as far as waiting for an ADB interrupt. I may get back to this some day (after getting the Mac II emulation fully working). March 27, 2008 PowerBook 100 formatting information for FDisasm is now available. (Also, the original Macintosh Portable ROM is said to be identical.) In some ways it is half way between the Macintosh SE and the Macintosh II, so it may, or may not, be a useful stepping stone. It has already been useful in identifying some more bugs in the emulation of the VIA chip (that don't seem to affect the computers emulated previously.) But the emulation of the Power Management Unit protocol, while it looks doable, might be too much to bother with just right now. March 16, 2008 The latest Development source snapshot can now use a Macintosh Classic ROM, thanks to assistance from David Sibley and "Gord". The build option is '-m Classic'. Though it runs, it is not necessarily an accurate emulation of a Mac Classic. A Mac Classic is supposed to be nearly identical to a Mac SE, but there are a few minor differences. There may be more differences that I don't know about. I can't really work on this much further until I own a Mac Classic. Getting the Mac Classic emulation to work to this extent involved fixing some issues in the emulation of the VIA chip, which could save time in emulating later Macintosh computers, which was my motivation for working on this now. One thing to be aware of is that the Mac Classic ROM should be 512K. Apparently some ROM acquisition programs only save the first 256K. The CopyRoms program should save the correct size. Another change in this snapshot is that the build system now has a separate argument for the memory size of the emulated machine ('-mem'), instead of including this in the model ('-m'). Possible values are: '-mem 128K', '-mem 512K', '-mem 1M', '-mem 2M', '-mem 2.5M', and '-mem 4M'. Thanks to a tip from William Nolan, Mini vMac now has, when accessing the emulated computer's memory, a special case for little endian processors that allow unaligned access (such Intel), similar to the existing special case for big endian (such as PowerPC). This makes it a bit faster. When Mini vMac is in full screen mode, it tries to send all key events to the emulated computer, instead of any normal meanings they would have in the host operating system. But I've decided that it went too far with this. So now in OS X, in full screen mode, it will no longer disable force quit (command-option-escape). This was just too dangerous, especially during development of Mini vMac. You can still send command-option-escape to the emulated computer, using the F1 and F2 keys, which are mapped to 'option' and 'command'. After using the “Alternate Keyboard Mode” for a while, I've made some refinements to make it better suit how I use MPW (which is what Mini vMac is really for). I don't expect anyone else is using the Alternate Keyboard Mode, and anyway I warned that changes were likely. Typing ';' now locks the mode on, there is no temporary state. (I found holding ';' while typing other keys too much strain.) Typing 'm' now leaves the mode. (I find 'm' slightly easier to hit than 'u', and it is no longer needed for entering the mode.) The 'shift' and 'option' keys now override the mode like the 'command' key does. (So anything except lowercase letters can be typed without leaving the mode.) When compiled with the Alternate Keyboard Mode, Mini vMac now starts up with the mode on rather than off. (I think I've reinvented what I've read about the vi editor. You are normally in command mode, and only use insert mode temporarily.) A number of the mappings are changed: 'a' - semicolon, 'b' - backslash, 'e' - backspace, 'h' - equal, 'n' - minus, 'o' - ], 'r' - return, 't' - tab, 'u' - [, and 'p' and 'w' are now not used. February 29, 2008 Macintosh II ROM formatting information for FDisasm is now available. (Which is what all the work on disassembly the last couple months has been leading to.) The disassembly tools and the formatting information for the other ROMs have also been updated. The disassembler now better supports 68020 code, but it still has no support for FPU or MMU instructions. There are only a few uses of the MMU in the Macintosh II ROM, and the FPU is used only in PACK 4 and PACK 5. February 16, 2008 The Mini vMac bounties page has a new simple and informal system. [This has been suspended.] I have decided to transition away from using microPledge, because, after working with it a while, I feel that what it offers doesn't really match what I wanted to use it for. On the positive side, they have just fixed a bug I had noted with removing pledges from a developer started project. February 9, 2008 Macintosh Plus ROM formatting information for FDisasm is now available. Also FDisasm and FindCode have been updated. (One notable change is that they now consistently use hexadecimal notation instead of decimal.) And also there is a new tool FindRes to get information about Macintosh resources such as are found in the Macintosh Plus ROM. In other news, John-Robert La Porta has created a guide (pdf) to using Mini vMac to play Dark Castle and Beyond Dark Castle. January 28, 2008 FDisasm 0.2.0 is the second public development release of the formatting disassembler. The Macintosh SE ROM formatting information is now in a separate disk image, and there is also now formatting information available for the Macintosh 128/512 ROM. (The Macintosh Plus information is still to come.) FindCode is a new tool to help create some of the formatting information used by FDisasm. January 18, 2008 “Lazyone” has released the third version of his port of Mini vMac to the Nintendo DS. January 17, 2008 FDisasm is a formatting disassembler for Motorola 680x0 code. It makes it possible to distribute the means to create an annotated disassembly of copyrighted code (such as Macintosh ROM images), without distributing that code or files derived from it. FDisasm 0.1.0 is an initial public development release, and so not yet of too much interest. For that matter, I don't expect very many people to be interested in it even when it's done. January 8, 2008 "interrobang" reports (with pictures) that the default Linux Intel version of Mini vMac works on the XO-1 laptop from OLPC. I've made a microPledge project for people to express interest in an improved port, better integrated into the Sugar user interface. December 30, 2007 John-Robert La Porta just sent me a link to the Dark Castle Forum, about the game Dark Castle and sequels. Dark Castle and Beyond Dark Castle are among the most popular reasons why people use Mini vMac. December 22, 2007 Today's Development source snapshot has more accurate mouse and keyboard event handling, by using an event queue to communicate between the platform dependent code and the platform independent code. Previously, the the platform dependent code would tell the platform independent code every emulated sixtieth of a second the current mouse position and up/down state of the mouse button and keys. If the host computer was very busy, or just slow, then a down and up pair could end up being processed in the same emulated sixtieth, and they would cancel each other out and be lost entirely. Also a mouse button state change might not be processed until well after it happened, and the mouse position might be different by then. (Though if Mini vMac is not getting time every sixtieth of a second, so that these problems can be observed, then sound emulation isn't likely to work either, emitting horrible noises. But it is possible to compile Mini vMac without sound.) And also if the host computer is a device without a keyboard, such as using handwriting recognition, then there might not be separate key down and key up. The X version now uses mouse motion events when possible instead of XQueryPointer, which is alleged to be inefficient. (Especially if the program is using the display on another computer, so that XQueryPointer requires a round trip over the network. I've never tried this. I don't know if anyone has.) The Macintosh SE emulation, in full screen mode, will now emulate the ADB protocol for mouse movement, instead of just poking the changes into emulated low memory. This turned up a bug where apparently emulated ADB devices were responding to commands too quickly, before the emulated Mac was ready. I increased the constant that specifies the delay. December 10, 2007 You can now increase the priority of features that you want added to Mini vMac, and support their development, by pledging bounties. [This has been suspended.] This is done through microPledge, which looks to be the most suitable bounty system I've found on the web. "zorzal" has already pledged towards the Maemo port, and also offers to contribute a Nokia 800. December 8, 2007 This week's Development source snapshot has two fixes to the 68020 emulation (In distinguishing between long DIV and MUL, and in bit field operations with width of 32.) Not too big a change, but it involved a major project to identify the bugs. The 68020 emulation is probably now accurate enough to emulate a Mac II. But this isn't too useful yet, as Mini vMac doesn't emulate a Mac II, and almost no software that requires a 68020 doesn't also a require color quickdraw. December 1, 2007 I've decided to try to make development of Mini vMac 3.1 a bit more open than in previous versions. The Development page has source code snapshots of the work in progress. There is no promise that it works correctly. Most people should wait for the first alpha, at least. The main feature of today's snapshot is a hack to support larger screen sizes, with the build system options '-hres' and '-vres'. For example '-hres 640 -vres 512' makes the emulated screen take a quarter of my lcd monitor, so it uses the entire monitor in full screen magnify mode. Be warned this is very much a hack, involving numerous ROM patches (and somewhat different patches on the Mac Plus, the Mac SE, and the Mac 128/512). It emulates a computer that never existed, so there will definitely be compatibility issues with some software. Also keep in mind that most games that will work on the Mac Plus are designed for 512x342, and don't benefit from a larger screen. (The original vMac supported larger screen sizes also, with related method that doesn't directly work in Mini vMac.) You can also set the emulated screen smaller than 512x342, which could be useful on portable devices, but that will really cause compatibility issues. Another change is that the alternate CPU emulation of Mini vMac 3.0.4 is now the main and only emulation. More testing is needed to become confident about it. The PowerPC assembly code version has been revised to match the new emulation. Also the build system now generates this assembly code for the selected development environment, instead of keeping separate copies of this source for the two previously supported environments. This made it possible to also support using assembly code in PowerPC linux, with a new build system target, '-t lppc'. (Which about doubles the speed.) This so far has only been tested in Ubuntu 6.06. In response to this patch, I've tried to start cleaning up type definitions so as to be better able to work on non 32 bit CPUs. I've merged in changes from Fabio Concas's Pocket PC port version 2.8.2, and used a suggestion by Yuhong Bao to use _tWinMain instead of WinMain in the Windows version. The build system now supports using the command line tools of the LCC compiler ('-e lcc -cl'), supports the Sun c compiler ('-e snc'), and supports compiling the Pocket PC version with Microsoft Embedded Visual C++ 4 for ARM and the emulator ('-t wcar' and '-t wc86'). November 15, 2007 Mini vMac 3.0.4 is now officially released (with no change from the final beta, as usual). New since the previous official release, 2.8.2, is support for importing and exporting the clipboard and files, a new build system, localized versions for Dutch and Spanish, and more. Also there are some bug fixes, such as that the PowerPC version now works in Mac OS X 10.5. The Changes file in the documentation gives a more complete list. November 9, 2007 There is now a Mini vMac 3.0.4 beta, which fixes a bug in the PowerPC Macintosh OS X version that made previous versions incompatible with Leopard. It changes only 10 bytes of code from 3.0.3, so I'm optimistic it won't introduce further problems. The same fix is in the PowerPC version for Macintosh OS 9 and earlier. There is no change in the Intel Macintosh OS X version from 3.0.3, or the versions for other operating systems, other than to change the version number. I've also updated to 3.0.4 the '-im 1' version of Mini vMac with David Sibley's icons installed. Besides the icons, David Sibley has now also contributed a t-shirt design for Mini vMac. Buying a T-shirt or other item with this design is one way to help support the maintenance of Mini vMac. [This is no longer available.] OLD NEWS - Previous release notes |