:
Sent: Fri Nov 22 19:47:05 2019
I would like to know if I can get Windows on my android phone?
Do you mean running Microsoft Windows on Android? That is out of the scope of Mini vMac.
But Mini vMac, which runs versions of Classic Mac OS that had windows before Microsoft Windows existed, has been ported to Android. (Note that I am not involved with this port.)
Sent: Wed Nov 20 12:09:42 2019
Mini vMac really really needs the ability to access host drives like basilisk II can, I had to quit using it after 15 minutes because of how tedious it is to pack hfv disks with hfv explorer just to satisfy mini vmac, the emulator is all but cut off from the outside world in it's current rendition.
Also i found that mini vmac did not recognize any of the command line switches you have in your documentation (like -hres and -vres).
Just my thoughts.
Besides HFVExplorer for Windows, my utilities ImportFl and ExportFl can be used to get files into and out of Mini vMac disk images. (HFVExplorer is old and unmaintained, so I have doubts about how well it will continue to work in the future.)
If you have lots of files you want to import, it may be easier to create an archive of them first on Windows (in some format that old Macs can deal with), import the archive, and then extract the archive inside Mini vMac.
If you are just dealing with plain text, the utilities ClipIn and ClipOut may be more convenient. (If you are not dealing with plain text, then you have to deal with the issue of files moved to Windows losing Macintosh specific information like resource forks. Most archive file formats are safe to move between Windows and Mac.)
If you prefer to access host drives in Basilisk II, it makes sense to do that, and use the disk images you create there in Mini vMac. Mini vMac has more emphasis on emulating the earliest Macs, while Basilisk II has more emphasis on later Mac 68k software. Each can run some software that the other can’t.
I wouldn’t completely rule out ever adding a host drive access feature to Mini vMac, but I don’t have much enthusiasm. First, it would require a lot more platform specific code, making Mini vMac harder to port. Second, if I recall correctly, Basilisk II uses hooks for external file systems in the Macintosh OS. These hooks don’t exist in the earliest versions of Macintosh OS. Third, host drive access seems the kind of thing that could mostly work, but frequently run into edge case issues that people would complain to me about, taking up a lot of my time.
People that are new to Mini vMac don’t necessarily need to deal with the import issue much at first, since I provide lots of software already imported into disk image format on my Macintosh Plus software page.
“-hres” and “-vres” are not command line options, they are options to the Mini vMac build system. The few supported command line options are documented in the Mini vMac User Interface page. But the main emphasis in Mini vMac is compile time options, which allows Mini vMac to be smaller and simpler.
The Mini vMac 36 Variations Service makes it easy to try out compile time options, compiling custom versions of Mini vMac in a few seconds. The Text Based Variations Service allows you to directly type in options like “-hres” and “-vres”.
Sent: Sat Nov 9 16:08:11 2019
Hi Paul,
i've implemented a midi bridge for Mini vMac. it hooks into sccemdev.c to forward the serial bytes into a midi packet parsing routine that resides in a separate source file. the parser also provides a bridge to/from the host OS midi ports. a link to an experimental build and discussion is at
https://www.emaculation.com/forum/viewtopic.php?f=7&t=10420
the emulation works really well: no stuck notes and sysex works both ways. however, there's some jitter that i'd like to get rid of, and was hoping if you could point me into the right direction on where to address the issue. when you have a moment, please see this analysis doc for further info:
https://drive.google.com/open?id=1twih0SH3btOSrPsfMHE27NWsg8R35UVO
a fellow Mini vMac user also suggested at the forum that serial io might be beneficial for other scenarios beyond midi. i can easily add a tcp socket to pass raw serial byte streams between mini vmac and the host os. do you see any benefits in doing that ?
thanks,
Jari
I can think of two reasons for such jitter. First, OS X is not a real time operating system. The operating system will give Mini vMac time to run when it feels like it. To get uninterrupted output for the emulation of built in sound, there is a buffer that the operating system can get samples from, even if Mini vMac doesn’t get time for a while. (This buffering results in lag, which can be a problem such as for games, so Mini vMac dynamically tries to figure out just how much buffering is needed.) But this is probably not the main issue you are seeing.
Second, Mini vMac emulates an entire tick, about a sixtieth of a second (more accurately 60.15), all at once. If the operating system feels like it and runs Mini vMac exactly on schedule, this will run every sixtieth (about 0.0167 seconds). Your emulated Midi clock events are supposed to happen somewhat less frequently. So in most ticks one event is emulated, but occasionally there are no events in a tick. Which is exactly what you are observing.
The only way to avoid this would be to have the operating system run Mini vMac much more frequently, and each time emulate small pieces of a tick. This would be much less efficient, and it is doubtful whether many operating systems would even allow this.
If possible, a better option is to buffer output, like the emulation of built in sound does.
Sent: Tue Nov 5 05:00:01 2019
Hi Paul,
Hope you are well? We haven’t seen any updates to your mail archive for a few months.
Regards
Adam
Sorry for the delay. I’m not so good at correspondence, made worse lately by lack of time.
I do read all messages immediately, so the feedback form does work as feedback. It is not working so well for asking questions. I do post messages and replies eventually, but it can be a while.
I’m thinking it may be an improvement to post received messages immediately, and replies later, so that people can at least know their messages have been received.
Sent: Mon Oct 7 06:38:42 2019
Hello Paul
I'd like to port the minivmac to some small
Microcontroller board with display.
Do you mind if I tried to do that?
If no, could you please advise what source
files I should focus on?
Or maybe there's some pouring guide available?
Sincerely yours
Jacek Wywrót
[... email address ...]
That is certainly fine with me. (And anyway, Mini vMac is under GPL license, so my permission is not needed.)
Platform specific code is contained in files starting with “OSGLU”. To port to another platform, you would create another of these files.
Alternatively, if someone has ported SDL (Simple DirectMedia Layer) to your microcontroller, you could use one of the Mini vMac SDL ports, OSGLUSDL.c for SDL version 1 or OSGLUSD2.c for SDL version 2. (At least as a starting point. The Mini vMac port to Apple’s Cocoa was done by porting to SDL for Cocoa, then merging together the source for Mini vMac and SDL, and removing anything not used, and a lot of further cleaning up. Porting this way, I didn’t need to know anything about Cocoa or Objective C before starting.)
Sent: Mon Sep 9 15:27:18 2019
Hi Paul,
This is in response to the issues described by John (Sat May 18 07:41:53 2019) regarding general lag and lack of mouse responsiveness when in full screen mode, after building Mini vMac in Mojave 10.14.x.
I experienced the same issues and eventually stumbled on a solution, which at least works for me. After building Mini vMac, I perform a deep codesign on it, via the terminal. I should add that I don’t distribute these builds to anyone and I retain them for personal use only. I have no idea why this works, but after code signing each build, they work perfectly with no more lag or issues with the mouse playing up or full screen not working correctly.
Maybe this could help you track down the issue? Apple has changed so many security settings in Mojave, even between the initial and later releases. I had to spend a lot of time getting my scripts and other custom built apps to work properly.
Adam
Thanks for the report. That is pretty odd. The old version of VMware Fusion I am using does not support recent versions of OS X, so I will need to set it up on a real computer some time for testing.
Sent: Mon Aug 26 01:14:57 2019
Hello.
I keep getting an issue where, in Full-Screen mode, if I move my mouse
to the bottom-left corner, and then move it around the screen, it skips around!
(it isn't consistent, but it is VERY annoying)
I am using Mini vMac 36.04 on an Early 2015 13-inch MacBook Air
running 10.14 Mojave
Thanks for the report. (Further details of probably the same issue are in a follow-up message.)
Sent: Sat Aug 24 13:43:04 2019
Paul -- Thanks for a great emulation. I used the old versions for a long time but needed to upgrade to x64 before OSX stopped supporting x32.
Anyway, can you tell me the default location for the ROMs? With the old versions, I could leave the ROMs in the same folder as the app, but now it doesn't seem to like that. I do not have vMac in the Applications folder...not sure if that's why.
Thanks!
Rich Cini
The ROM section in the Emulated Hardware Reference describes how Mini vMac looks for the ROM image.
Your problem with OS X is probably due to its recent Path Randomization misfeature. The OS X notes page describes a work around.
Sent: Tue Aug 13 21:32:07 2019
Thanks so much for maintaining this site and copying the system software files from Apple's site when they took them down.
I messed around with Mini vMac about 12 years ago when I was in high school. I forgot about it for a decade, got an Electronic and Computer Engineering degree, now I'm an adult working as a Software Engineer, about to get married, and I somehow remembered that Mini vMac existed and decided that I wanted to save a copy to show my future kids what old operating systems looked like. It took me half an hour of Googling, as I couldn't actually remember the project's name, but I finally found it and I'm so glad the site is still up and maintained, and is pretty much self-contained with no dead links to external sites that haven't worked in years :)
I”m glad you find the links to the system software useful. (Mini vMac doesn’t actually host these, it just provides a link to make them easier to find. Apple seems to have removed any way to find them on their website, but the files are still there.)
Sent: Sat Aug 10 05:45:49 2019
Hello,
First off, I love this emulator!!! thank you for working on it.
I am curious if you are interested in adding a feature.
Fast Boot, where it will start with the speed of allout until the AutoQuit program runs the Startup Program.
I would imagine it could be invoked like this:
minivmac -fb 1
in the above example, it would be all, out, then the disk is inserted and AutoQuit "finder" loads the program, it completes, then triggers the interface to move to x2 speed with "SpeedValue == (ui3b) 1"
I would do this myself, but I have been staring at this code for a while and I barely understand what I am doing, so I have all but given up.
If the timing of this can be this precise, we could also disable the sound and black out the screen until that point as well via command line.
Thanks for such an amazing emulator!
That is a reasonable idea. One issue is that Mini vMac currently doesn’t know when AutoQuit starts. It would be possible to add an extension to Mini vMac that AutoQuit could call.
But I would lean towards a different implementation. An optional extension could be added to Mini vMac to allow Mac software to get and set the speed setting of Mini vMac (which I was already considering for a different purpose). Then a version of AutoQuit could set the speed to 1x when it starts, which could be used with a version of Mini vMac that is compiled to start at all out speed. There could also be a version of AutoQuit that turns the sound back on, which could be used with a version of Mini vMac that starts with the sound volume off.
Sent: Tue Jul 17 22:13:38 2018
Hi Paul,
I made a modification for the Mini vMac setup tool, so that it can directly create the cfg/ and bld/ directories, and directly generate the files in the cfg/ directory (skipping the step of running a Bash script). Here are the changes I made:
https://github.com/Falcury/minivmac/commit/d4ed39935367f1ee7bc0847aa472316e707e1daf
The reason I did this: I use a Windows machine for development, and it has been a bit inconvenient having to execute the Bash script. I also wanted to be able to quickly reconfigure the source and compile from within the IDE I usually use (CLion, with MinGW). The changes to the setup tool made this easier for me to achieve. (Incidentally, CLion uses CMake as its project model, so I also made a rudimentary CMakeLists.txt configuration for building Mini vMac on Windows. It's located in the src/ directory in the repository I linked to above.)
Best regards,
Falcury
Thanks. This may be useful to some people.
Sent: Tue Aug 6 08:50:02 2019
Hi!
I'm trying to track down a actual email address of Michael Hecht...
Best regards, Raphael
[... email address ...]
Even when I know someone’s email address, I would not give it out. I might perform an introduction (pass along your email address) if I have reason to think they would be interested.
Sent: Sun Aug 4 13:47:41 2019
Hello master
I was wondering, is it possible to port old Mac OS game so it will run on the new OSX? (As just a standalone game, not in emulator)
I was thinking about the game [ ... ], please let me know if that is possible, but i am sure you have solution since you can run the whole system in emulator :)
my email is [... email address ...]
Anything is possible with enough time, but porting Mac software to other operating systems is out of the scope of the Gryphel Project.
The Gryphel Project does provide tools like AutoQuit to assist in “wrapping” an application for the Mac Plus, so that you can use it with Mini vMac more as you would a native application for your machine.
Sent: Thu Aug 1 19:49:50 2019
I use two monitors in a side-by-side configuration and when using magnify or full-screen, rather than filling a single monitor, Mini vMac takes over both monitors and places itself in the middle with half of the emulated Mac's screen on the left monitor and half on the right.
Is there something I can do to have it display on a single monitor? The current behavior seems less than ideal.
Thank you.
As far as I can remember, when I was working on the port to X there was no reliable portable way for an X program to detect the setup of multiple screens. Maybe that has changed.
Mini vMac for X does have an optional command line argument “-display [display_name]”. Perhaps some choice of display_name would cuase Mini vMac to display on only one of your monitors.
Sent: Mon Jul 29 19:03:21 2019
Hi Paul,
First of all, thank you for putting together this project. I'm very much a newbie to classic macs (having only worked on them briefly during my school days and not having one at home).
I'm trying to get my feet wet a bit, but have run into several problems that I can't seem to get around. First one: I only have access to Windows PCs at the moment. Although I've been able to get Mini vMac up and running using a few downloads I've found online, any of the additional images I've downloaded give me the "unreadable disk" error. Understanding your concerns about copyrights, I'm not asking for you to provide any links but merely some thoughts: do I need to be running this on a Mac for these files to work correctly? With the exception of the files that explicitly stated something about Windows, nothing I download seems to work in vMac and I'm not sure if it's a filesystem compatibility problem or what.
If you have any advice, suggestions, or know of some communities I could join that would help me learn, I'd appreciate it. If not, thanks for your time. My email is [... email address ...]
Mini vMac should run pretty much the same on OS X and Windows.
Make sure your images are not compressed, as Mini vMac can only handle uncompressed images. All the “.zip” images on the website should be uncompressed to get images with a “.dsk” extensions.
Also, make sure you first mount a bootable disk image. Once you have booted, you can mount other disk images that have no Macintosh operating system files.
Sent: Sun Jul 7 21:49:46 2019
Hi Paul,
I am downloading the Mini VMac but I have problem to locate the ROM folder. Can you assist me with that? My email is [... email address ...]
The ROM section in the Emulated Hardware Reference describes how Mini vMac looks for the ROM image.
If Mini vMac doesn’t find the ROM image in any of the places it looks, you can just drag and drop the image file onto the Mini vMac window.
Sent: Thu Jul 4 12:28:43 2019
I'm trying to understand how I would create a save file for a game of 3 in Three. It seems like I would want to mount a blank, formatted floppy disk in order to enable the save dialog to permit me to save a game (as of now, the save button is greyed out when I select the image containing the 3 in Three game folder. If I understand the manual, there should be a blank volume named disk1.dsk, but I have not been able to locate it.
I hope this isn't too insulting of a question to ask. I'm afraid using emulators is not something I have much experience with.
FYI: The version of mini vMac I installed v. 3.4.1, bundled with the Cliff Johnson games from the Fool's Errand website
Thank you, Paul
-Todd
The Gryphel Project provides a collection of Blank disk images. First unzip the collection, and then unzip the image you want. The “800K” image should be fine.
Sent: Mon Jun 17 04:28:11 2019
Hello, I pad for the sponsor code. Can you please email me the code. Thanks.
[... name ...]
Thank you for your donation! Sorry for the delay. I have been considering that in addition to accepting donations through PayPal, perhaps allowing the direct purchase of a variation service subscription through some e-commerce company, maybe FastSpring. Then sponsor codes could be provided instantly, rather than waiting until I wake up and check my email.
Sent: Tue May 28 10:02:36 2019
Hi Paul,
First thank you for your amazing job on minivmac, i'm enjoying it a lot !
I'm trying to use your sources to add minivmac to Retropie on Raspberry Pi. Retropie OS is based on raspbian and uses SDL2 (not X11). It already includes a minivmac package that can be easily installed. The version used is cloned from vanfanel github (which you merged into your code a long time ago to include SDL2). It's a very old version (3.3.3) and is limited to Macinthosh Plus emulation.
I tried to include the last b36 version from your sources and build minivmac on retropie in command line using SLD2 option. Everything goes fine when compiling but the mac emulation presents a strange behaviour in the display. Indeed, the screen is black everywhere except a square surounding the mouse. And the square follows the mouse movements. When pressing the control key, the whole desktop appears but as soon as the mouse moves, the display is cropped again around the mouse. It seems that everything remains black in the display except what changes on the screen (such as a mouse movement or displaying the minivmac menu). Building differently by changing the target, screen resolution, full screen display and so on didn't change anything.
I have no such a behaviour on debian (x86 PC) or rapsbian (ARM raspberry pi) using SDL2 option, only on retropie OS. I though that the fault was on retropie side, but the old build from vanfanel (https://github.com/vanfanel/minivmac_sdl2) works just fine. Do you have any idea of what changed between these two versions or what could be the origin of this strange behaviour ? Did I miss a specific option ?
Thak you very much!
Louis
Sorry, I do not provide support for Retropie. But if you find the probem, I would be interested to hear.
Sent: Sat May 18 07:41:53 2019
Paul,
I've been building Mini vMac for years I wanted to make make you aware of something I suspect may be a compatibility issue with Mojave (10.14). I generally roll my own every 6 months or so; more often when there is a new version. Earlier this month I decided to give 36.04 a go (I've not compiled since August 2018).
I'd first like to /thank you/ for simplifying the build process. Any time I can avoid the sheer frustration that is Xcode (and more so with the recent versions that break all the old projects) I am pleased. That being said, I built 36.04 and noticed two issues that do not manifest themselves on a 10.13 (High Sierra) machine.
1) Strange lag
Redraw (menu, window) is quite slow. Almost as of the emulation is fine but the rendering aspect of it is in slow motion. The mouse will suddenly jump making it difficult to control at times. My builds of 3.5.8 from High Sierra do not exhibit this behaviour on Mojave. Your variation service build:
m190518_050828_142.bin: 2018/10/07 with options: -br 36 -t mc64 -m SE -mf 3 -magnify 1 -sss 4 -lt
Does not exhibit the menu redraw issue, but the mouse can become completely unresponsive when entering full-screen mode.
2) Fullscreen mode inconsistently breaks mouse input
In both my own build(s) and your variation service build above, entering fullscreen mode (regardless of magnification setting) inconsistently breaks mouse input. Exiting fullscreen mode restores functionality.
In attempt to present you with consistent results I spent some time recompiling and comparing. I build 3.5.8 and 36.04
on both 10.13 and 10.14 using the same flags (a total of four builds). The result is that I think 10.14's clang has a bug or bugs that trigger the forementioned issues.
None of the issues I've reported manifest themselves when 3.5.8 or 36.04 is built on 10.13 with clang (clang-1000.11.45.5).
The only issue I noticed (and one other user reported on your posted feedback) is that the mouse is laggy on 10.14. I can verify this - it's as if it buffers mouse input for a few cycles and then attempts to catch up (making it jump). I believe this has something to do with how 10.14 handles depreciated OpenGL/CL.
Using MacPorts I've installed clang-8.0 on 10.14 and built 36.04. Unfortunately this had no effect. So this may be a combination of libraries and compiler.
I doubt it matters, but I build with:
-br 36 -t mc64 -m SE -mf 3 -sss 4 -lt -speed 4
John
Thanks for the report. I need to get Mojave and see if I can reproduce the issue with the official build of Mini vMac. (other builds, built with other development environments, are not really supported, though I would be interested to hear of bug fixes.)
Sent: Thu May 9 23:43:58 2019
June 5th???? I guess you meant May 5th but thought I would bring it to your attention.
Thanks! I have fixed this.
Sent: Tue Jul 17 22:13:38 2018
Hi Paul
While I'm waiting for the Sponsor Code after donating $10 USD under my PayPal e-mail
[... email address ...]
Can I suggest something for future Mini Vmac release?
While you have got the Macintosh II and IIx and IIci versions. What are the chances of you thinking of doing one of the Macinthosh LC series (LC, LCII and LCIII) port for Mini vMac?
Cheers,
Josh
Macintosh II emulation is not yet complete. That has to be finished first before going on to emulating later computers.
Sent: Mon Apr 29 22:30:38 2019
Hi Paul,
I've found what I think is a bug in Mini vMac. I'm on macOS High Sierra using a custom build of Mini vMac 36.04 built with MacPorts with these options:
-api cco -gse 1 -sony-sum 1 -sony-tag 1 -t mc64 -n 36.04_0-dev-mc64 @ \ -hres 832 -vres 525 -fullscreen 1 -var-fullscreen 0 -magnify 1 -mf 2 \ -gkf 0 -emm 0 -sound 0 -m II -mem 8M -speed 5 -iid 1
I'm using "-fullscreen 1" because I want Mini vMac in fullscreen mode. I'm using "-gkf 0" because I want to be able to Command-Tab out of Mini vMac to other apps. I'm using "-var-fullscreen 0" because when I Command-Tab out, I don't want Mini vMac to automatically exit fullscreen mode.
When I'm in Mini vMac, the macOS cursor is hidden, and the emulated Mini vMac Mac OS cursor is visible. When I want to switch to another macOS app, I press Command-Tab. The macOS cursor reappears, and if I release the keys immediately, before the macOS app switcher appears onscreen, everything is fine: I am switched to the other macOS app and the macOS cursor is visible.
But if I keep the Command key held down, for example because I want to press Tab (or Shift-Tab) a few times to pick a different app to switch to, then the macOS app switcher appears at which point the macOS cursor changes to a hand, and after I release all keys, the macOS cursor hides, even though I don't want it to; I'm now switched to the other macOS app but the cursor is hidden. I then have to find a way to show the cursor again, for example by moving the cursor over the Dock or by clicking the menu bar.
I don't have this problem with any other fullscreen apps, not even those that -- like Mini vMac -- don't use macOS native fullscreen mode (such as VLC, the way I've configured it).
-Ryan
That does sound like a bug. But whose bug could be argued. The hide cursor API in OS X has always been pretty broken. Mini vMac tries to work around it. Really, it is the job of Mini vMac to work around operating system problems, if at all possible. So I should check out the official Mini vMac build on High Sierra, and see if I see the same problem, and if anything further can be done.
(Probably most other programs don't try to hide the cursor. Mini vMac does, because the emulated computer draws its own cursor.)
Sent: Thu Apr 18 15:39:16 2019
Hi,
I've been working on an alternative LocalTalk emulation backend (i.e. an alternative to BPFILTER.H that fulfils the same interface) for Mini vMac which is more portable and requires less privilege than the LocalTalk-over-Ethernet backend already there, which seems in current testing to give basically plug and play LocalTalk emulation in Mini vMac instances on a LAN across OS X and Linux. Is this the kind of thing that you would see value in having contributed back to the main source tree?
If so, or even if not, are there any code style guides around for how code "ought" to be written in Mini vMac, and especially around how to add flags to the build system?
Thanks
Rob
Yes, I think many people would find this interesting.
You needn't worry too much about code style guides. When merging stuff into my version of the code, I extensively edit to suit my tastes, which helps me to make sure I thoroughly understand it.
You also don’t have to worry about the build system. If you’re making a set of source files with a new optional feature, I can take care of adding the option to the build system.
update - follow-up message
Sent: Tue Apr 16 01:57:41 2019
Hi Paul,
Do you think it's within the realm of possibility to make the Macintosh II emulation have a second virtual video card and display? It might not be of general interest, since changing the size of the single virtual display usually suffices, but I'm interested in observing what happens in a multi-display setup when windows zoom, when a window straddles two displays of different depths, and when displays are rearranged. It could also be useful for development to have MacsBug on the second display. If you think it might be possible, do you have any suggestions for what part of your code I should look at to try to implement this?
Thanks as always,
-Ryan
I think the harder part of multiple displays would be making the platform specific code actually display it. This code would need to be extensively rewritten to remove the assumption of a single window. It might make things simpler, and good enough for testing, to have all the emulated displays at fixed positions in a single window.
The emulation of multiple displays in the platform independent code would probably be straightforward if you just duplicate the file VIDEMDEV.c for a second display. (There is already VIAEMDEV.c and VIA2EMDV.c, which I keep in sync with some simple scripts. It might be a bit inelegant, but other approaches would tend to add more complexity.) One thing to watch out for is the hack of allowing larger displays than would really fit in the address space of a single card, by using the address space of other slots.
Sent: Fri Apr 12 14:29:42 2019
Good morning, Mr. Paul,
I have some problems with building minivmac for Windows 7, as it turns out, not even cygwin work when building the latest version of the app. I even got the latest version of gcc and make for cygwin to build minivmac, but the compiling crashes when getting to the end that the makefile for the target is not specified. Could you look into this, please? Any tips would be greatly appreciated. Just so you know, as I said above, I am running Windows 7.
See this previous message. A second previous message also may be relevant.
Sent: Fri Apr 12 13:07:06 2019
Hi, Paul.
I'm using Windows, and Smith Micro only has the Mac version available on their site. Your Alternatives page is absent any non-Mac utilities; so, I perused some questionable sites, downloaded files of unknown integrity, and made a few observations.
Your Getting Started page says that any modern version of StuffIt Expander would be capable of extracting the System Startup from SSW_6.0.8-1.4MB_Disk1of2.sea.bin, but that statement is a bit misleading. Perhaps it holds true for Macs, but it appears that the latest Windows version (v15), dated 2011, only works with .sit and .zip files. The StuffIt Expander from 2009 (v7), however, does work with with the .bin format.
I've also tried, and successfully used, Aladdin Expander (v5.11), dated year 2000.
If you'd like to include links to the utilities on your page, I found them here:
[... url ...]
[... url ...]
As for the trustworthiness of those sites, I cannot say. I use ESET on my system, checked the files in VirusTotal, and ran them in a sandbox without issue. I would suggest checking the files for youself, just to be certain, if you do decide to use them.
I'd also like to say, I've played an old HyperCard game on Mini vMac and it seems to work great. Thanks! :)
Thanks for letting me know that this documenation should be updated.
Sent: Mon Apr 8 02:04:57 2019
Hi there, I'm interested in a custom Mini vMac, but the options on the page are a bit limited. For example, I want it to support B&W, 4, 16, and 256 colours. Is it possible to get that build made? After donating, of course.
Sorry, Mini vMac currently only supports single color depth (plus B&W) per version of Mini vMac. Supporting multiple color depths would be significantly larger and more complicated. It is not that it would be impossible to implement. It is more a question of if there is really a need for it?
The priority of Mini vMac is in making 680x0 Macintosh software usable on modern computers. Is there any software that requires, or be significantly more useful with, multiple color depths?
The intent is to use multiple variations of Mini vMac for different purposes. With the text based variation service, it is easy to make multiple similar variations, such as with different color depths.
Sent: Fri Apr 5 11:25:15 2019
Hi Paul,
Further to my email of (Tue Mar 26 16:44:04 2019), I tried using your advanced variation service, and it now seems to work properly. My build options were:
options : -br 36 -t mc64 -m II -fullscreen 1 -mf 3 -magnify 1 -sony-tag 1 -sony-sum 1 -iid 1 -speed 4
Regards,
Adam
That sounds like it was an issue with that version of XCode. I could try to getting it Mini vMac to work with it. But I’m thinking of going a different direction.
Sent: Mon Apr 1 22:05:25 2019
Hi, it's the guy with the question about building again. The cfg thing was a simple mistake (didn't copy everything over), but now I'm getting errors about mingw32-make and gcc not having permission to access the bld folder and I'm stumped and frustrated. A friend and I spent a solid hour each trying to build it to no avail. I'm simply trying to build a 32-bit Mini vMac for Windows.
Your documentation is fairly unclear, and because the tool.exe outputs a shell script I had to run using Cygwin (and convert the line endings to boot), I'm convinced this is just not meant to be built on Windows. Again, is there some specific setup I should be using here? Another OS? Different compilers?
I’m thinking that I should update the documentation to say that at this time, compiling your own version of Mini vMac is not recommended unless you are a programmer familiar with your chosen development environment and can debug any issues.
In the future, I’m thinking that there should only be a single set of tools to buid Mini vMac, that I would provide, document, and support.
Sent: Thu Mar 28 13:44:03 2019
Hello,
Do you corrects bugs in Mini vMac? I suppose i found a bug when the mini vMac freeze with the flag on the screen?
Regards,
[... email address ...]
Sure, if there is some reproducible path that causes Mini vMac to freeze (not just the virtual Macintosh), that is likely to be a bug in Mini vMac, which I would certainly fix. (Or, if it is a bug in the operating system, and enough people are likely to use that operating system version, then I would try to put in a work around.)
What operating system and what hardware are you using? And what path results in a freeze?
Sent: Thu Mar 28 03:55:35 2019
Hi Paul,
Can you tell about the software/method involved in creating custom desktop icons for apps in System 6/7? I noticed that your Mini vMac HD images have the "Mac Man" icon instead of the stock "HD20" icon.
--Damon.
This does not sound like any disk image that I provide. It sounds like an image that is associated with the original vMac project (not Mini vMac).
Anyway, in System 7, you can set custom icons by selecting an icon in the Finder, choosing the Get Info command, clicking on the icon in the Info window, and then using the Paste command to replace the icon. This requires that an icon is already in the clipboard. You can create an icon in ResEdit and copy it to the clipboard from there.
Sent: Tue Mar 26 16:44:04 2019
Hi Paul,
I have previously compiled version 3.5.8 (macOS 64) and have it working fine under macOS Mojave.
Today I tried compiling version 3.6 with the same settings as my 3.5.8 build, but when I drop the same dsk image into the new build I notice that when I boot up the Macintosh HD is labelled as locked, and I cannot alter the memory settings of any apps or move or delete anything off the hard disk.
I drop the dsk image back into the 3.5.8 build and it works fine again. Why would the 3.6 build be automatically locking my hard disk images? Are there any new settings that I have overlooked?
In addition, when I double click the old 3.5.8 build it opens in full screen with no problems, but with the 3.6 build I get the macOS menu bar appearing along the top of the screen, even in full screen mode. It is like Mini vMac is loading 'full screen' into a window in the background. If I exit and re-open it might work normally, but it is not consistent and it repeats after the 3rd opening etc.
I compiled my 3.5.8 build under Mojave, and I am still on that operating system, so I am at a loss to understand what has changed in 3.6.
Regards,
Adam
I’m not aware of changes since 3.5.8 that are likely to cause these problems. Did you compile 3.6 with the same version of XCode as you did for 3.5.8? If not, if you recompile 3.5.8 with the current compiler, does it have the same problems? Do the official builds I provide have the same problems?
Sent: Sun Mar 24 17:40:54 2019
Will we ever get Proper networking into Mini vMac for all platforms?
Improved support for networking could be a nice feature to have in Mini vMac. I can not say what decade it is likely to be implemented.
Sent: Fri Mar 22 17:34:13 2019
Hi Paul,
What's the most efficient way to build Mini vMac on Windows? I'm using MinGW32 and Cygwin to get the makefile, but it's complaining about config files that aren't being generated when I try to make it:
mingw32-make: *** No rule to make target 'cfg/CNFGGLOB.h', needed by 'bld/MINEM68K.o'. Stop.
I'm genuinely not sure what I'm doing wrong. Is there a better way to build this or should I just use a different development environment?
As briefly explained in the Building Mini vMac page, you need to use the configuration tool to generate the configuration files, as well as the makefile.
Sent: Wed Mar 20 17:17:57 2019
Hi Paul,
Thanks for your amazing work. I'm currently trying to get the exportPS functionality working to print images from an old MacCalligraphy program. I followed your instructions to select the Laser Writer, but I can an error about AppleTalk not being enabled, and from all I could find in your documentation you said that LocalTalk can only be enabled on Mac OS. I'm on Windows does this mean i'm not able to print out images? I could switch over to emulating on a mac if needed.
Many thanks,
Harry
Even though selecting LaserWriter in the Chooser tries to turn AppleTalk, the print to file feature of this driver will work without AppleTalk. So you can just ignore this warning. Choosing Cancel is fine, which leaves AppleTalk off. Choosing OK, which turns AppleTalk on, is also fine.
The standard Mini vMac variation without LocalTalk emulation still tries to correctly emulate the serial port, with no LocalTalk network attached, which is sufficient for turning on AppleTalk. (AppleTalk is the protocols that are used to talk over the LocalTalk network hardware.)
Thanks for pointing out this ommission in the documentation. I have added a paragraph to the printing FAQ.
Sent: Thu Mar 14 15:59:30 2019
Hi
I made a donation to you for $12.
How do I get the Sponsor Code?
I want a custom buid
Thank you
[... name ...]
Thank you for your donation!
I did try to send a Sponsor Code to the email address for that PayPal account at 11:59 AM (an address at earthlink.net). If you are not getting email sent to that address, please tell me another email address to use.
Sent: Mon Mar 11 17:41:02 2019
Over at the 68kmla.org boards there is some initial interest in designing a new video card for actual hardware. I was curious what resources you used in designing the video system for Mini vMac? How true to hardware is it? Have you written up anything like this before?
The book “Designing Cards and Drivers for Macintosh II and Macintosh SE”, which is in my list of Apple Developer Documentation books, could be helpful.
The video system of Mini vMac for Macintosh II emulation doesn’t actually emulate a real video card. It just provides a driver that passes calls to Mini vMac to handle directly. The Basilisk II source was useful to look at while writing this driver. I expect the MAME/MESS source may be even more useful to show how a real video card should work.
Sent: Sun Mar 10 08:53:37 2019
Hi Paul,
Thank you for all your hark work on Mini vMac.
There appears to be a bug of sorts in the standard Macintosh II 36.04 variation available from the downloads section on your site, and it is consistent on both Mac OS Mojave and Windows 10 versions of the build.
There is a noticeable graphical "lag" in emulation; it's a bit hard to explain but you can see it just by moving the cursor around for a bit. It seems to slow down or skip frames. This manifests throughout emulation and becomes especially noticeable when trying to play games.
I never encountered this issue before in any previous versions, and it does not seem to be an issue in the standard Mac Plus variation. Just thought I would let you know.
Best regards,
Hampus
Thanks for the report. I have not been able to reproduce this yet. What operating system are you running on the emulated Macintosh? What are some games where you see this? What hardware are you using? Especially, what CPU? To be specific, do you see this in mnvm0026-36.04-mc64.bin.tgz, but not in mnvm0026-3.5.8-mc64.bin.tgz?
Sent: Sun Mar 10 05:12:41 2019
I've compiled Mini vMac for a Raspberry Pi (Raspbian). It runs successfully and has sound. However, the sound will only come out of the 3.5mm headphone jack (analog output). If I switch the Raspbian output to HDMI, bluetooth audio, or usb audio, Mini vMac doesn't respect the change and will still play via the 3.5mm headphone jack. However, all other applications on Raspbian will reflect the audio output selected in Raspbian.
So for instance, I select usb audio as the output and start playing youtube in a browser and it plays via an attached usb speaker. I start Mini vMac and play sound and it comes out of the 3.5mm headphone jack.
Is there a compile option that I need to set to pick the output source for Mini vMac?
Thanks!
It sounds like Raspbian may not be supporting ALSA sound output too well. Mini vMac does have a run time option, “-alsadev <alsadev_name>”, for picking the audio device used, which might be of some help.
Mini vMac also has a compile time option, “-snd-api ddsp”, to use OSS instead of ALSA. But I don’t know if this would work any better.
Sent: Sun Mar 10 01:21:17 2019
Hello, I suggest updating COPYING.txt to use the new permanent address of the FSF (51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA).
Thank you for noticing this. A complication is that license for distributing this license does not allow any modifications, so I can’t simply update it. But there is a newer version on the FSF website that I can use instead, which has this correction and a few other minor changes.
Another complication is that I can’t update the license file without making a new version of Mini vMac, which I don’t think I would do just to correct this address. So it will have to wait for Mini vMac 37. Similarly for all the Mini vMac extras, which also have a copy of the GPL.
Sent: Mon Mar 4 19:17:12 2019
Hi,
I'm just starting to use this great emulator to play old Mac games.
I am facing one issue however : my Mac has a French Keyboard. Is there a way to switch the Mini vMac keyboard from US to French ? The control emulated control panel doesn't seem to have the needed resource.
Thanks
[... email address ...]
I would guess that to get the French keyboard in the emulated Macintosh, you would need French System Software.
For example, here are download links for French System 7.0.1: Disk_Tools, Fonts, Install_1, Install_2, Printing, and Tidbits.
Sent: Tue Jul 17 22:13:38 2018
Hello Paul, I was quite excited to see Mini vMac and I'm hoping to get it working. I am the happy owner of a 128K, 512ke, Mac Plus, Mac II, Mac SE, PowerMac G5, far too many Mac minis to count, and a few iMacs, most of which are in storage. I have looked through the docs and don't see any answer so I'm wondering if you'd be able to help?
I have downloaded vMac, got a ROM file from [... url ...]. I also go the system software following the link at your site.
Upon launching vMac, I get a grey screen which I assume means the ROM file was accepted. However, I see no ? icon and loading the system image doesn't do anything - the screen just stays grey.
On various versions of ROM files, I get an error that the file is too short, or some such indication from vMac, but this one doesn't report any errors on loading.
Any ideas why I'm not seeing anything other than a grey screen and why loading the System Software doesn't have any result?
Thanks much.
If you are using one of the Standard Variations variations of Mini vMac, it will emulate a Macintosh Plus, so you should use one of the three versions of the Macintosh Plus ROM. My list of 680x0 Macintosh models gives MD5 checksums for these ROMs, that you can check to make sure you have a good ROM image. But Mini vMac does a simpler checksum when starting up, so if doesn't warn about a bad ROM image, this is unlikely to be the problem.
When following the Getting started with Mini vMac guide, make sure to follow the part about uncompressing the disk image, rather than trying to boot from the compressed “bin” file. But if this were the problem you should still have seen the blinking question mark before you dragged in the System image.
Getting to the point of drawing the gray screen, but not to the point of drawing the blinking question mark, is rather strange. Are you using one of the Standard Variations I provide? If you compiled it yourself, perhaps a bug in the compiler could have this result. Otherwise, which Standard Variation are you using, and what operating system version are you running it on? Also, what hardware, especially CPU version?
Sent: Sat Mar 2 21:02:43 2019
Hi Paul,
Is Mini vMac still supported on OpenBSD?
This week, I built three variations of 36.04:
-t ob64 -var-fullscreen 0 -fullscreen 1 -drives 10 -cbt 8
-t ob64 -m II -hres 640 -vres 480 -var-fullscreen 0 -fullscreen 1 -drives 10 -em-cpu 2 -hcr 39321 -hcg 65535
-t ob64 -m II -hres 1024 -vres 768 -var-fullscreen 0 -fullscreen 1 -drives 10 -em-cpu 2 -hcr 39321 -hcg 65535
Applications are crashing, printing generates invalid PostScript, and the print dialogs refuse to recognize Adobe PSPrinter (a virtual printer installed in the Extensions folder).
For what it's worth, the Plus and II variations that I built for my OS9 Mac work exactly as expected, including the aforementioned PSPrinter.
If OpenBSD is still supported, I can spend some more time testing and write a better report, if that would be helpful.
Thanks for all your work on this project.
-Gail
Sorry, OpenBSD is not really supported at this time, because OpenBSD is not supported by the version of GCC that I use for all of my compiles, if I recall correctly. Or it might just be that I didn’t figure out how to get it to work.
I can’t really support other compilers, since there are so many of them, many of which can have bugs. You might try compiling with optimizations turned off, to see if the problem goes away.
I have a plan for getting back support for OpenBSD and other operating systems not supported by my current compile system, but this is likely to take quite a while.
Sent: Thu Feb 21 02:05:21 2019
Paul,
I recently obtained an OLPC XO-1 (an i686 running fedora 18 at the moment), and I decided to try getting Mini vMac running on it.
The 32-bit linux binary was crashing, complaining about an X11 "BadMatch" error while attempting to execute XPutImage(). With some trial and error, I tracked the cause to a mismatch in color depth between x_display (16-bit) and my_image (24-bit) in OSGLUXWN.c. Recompiling with the "-ci 0" flag fixes the problem for me.
I'm a little out of my depth here (if you pardon the pun), but perhaps it would make sense to add a sanity check for this kind of problem at startup, and emit a more suggestive error message before X chokes?
Thanks for creating and maintaining this wonderful project!
-John
It would be nice to support a 16 bit x_display, but I would need to find some hardware to develop it on. I prefer not to write code that I can’t test, because writing almost working code can cause more difficult problems than simply not working at all. Even trying to write code to test for this situation and only give an error message would be risky without hardware to try it on.
Sent: Wed Feb 20 11:24:09 2019
I want run mini vMac in Raspberry Pi
The Linux ARM port (“larm”) on the Download Mini vMac page should work on a Raspberry Pi running Raspbian.
Sent: Thu Feb 14 16:24:20 2019
Hi Paul.
First, let me extend some thanks; I've been playing with Mini vMac and the various utilities you've been developing and maintaining for years.
You can see an enscripten'd version on [... url ...] (not sure if the patches still exist in source form)
and what was to be a "cloud-hosted", remote macintalk synth at [... url ...]
at some point, I also investigated using a webrtp switchboard server for remote localtalk - but I've to admit that I was quite confused by the bpf code, and had trouble finding an headless X server that'd work.
Anyways, for the feedback part. I tried running PlayerPro 4.4.2 (FAT) by Antoine Rosset - a neat sound tracker, and the following happens: hum. period, circa 0.033 sec / freq, circa 3 Hz.
Here's a screenshot of the captured loopback (normalized to -4dB): [... url ...]
If you'd like to repro, there's a copy of Player Pro in the Pres:Apps on the disk image therein.
[... url ...]
I'm really not sure what this is down to; maybe you have a clue ?
My email is [... email address ...]
- please don't publicly post the parts of the message containing URLs to my server :)
Have a nice day,
Arnaud
I happened to already have a copy of this program from a shareware site, but I hadn’t tried it before. It looks pretty nifty, playing the example provided. But otherwise making heads or tails of what the program does seems like it would take a while.
I notice that if the Driver Type is set to “ASC” in the preferences, then setting the Mode to “Mono” does not work. This could well be a bug in the emulation of the ASC, which maybe could be figured out when I have a couple weeks or so to look at it.
Is this the problem you are seeing, or do you have some other reproducible path to misbehavior?
Sent: Thu Feb 14 07:37:11 2019
Hi Paul,
Yes, my MacII.ROM checksum is different -- 0x97221136. I didn't realize your disassembly would be specific to one ROM checksum, though that makes sense. Maybe fdisasm should warn if the checksum isn't what was expected?
The two occurrences of non-ASCII characters are appearing in P_Sony_RdData:
2E906 F1F5 F1F5 L6264: Illegal 2E90A F2F6 F2F6 F3F7 [... garbage ...].L (* + -$D090C07) 2E910 F3F7 Illegal.L (* + -$D090C07)
2E982 6C00 DC.W $6C00 ; 'l ' 2E984 F2E4 80C3 E248 L6271: [... garbage ...].L (* + -$7F3C1DB6) 2E98A 55C6 SCS.B D6
Since that probably won't survive being submitted through this web form, the hex of the values on lines 2E90A and 2E984 is:
F6F2F600 00000F00 00000600 00000600 00000100 00000300 00000000 00000200 0001E400 212F3E00 21397400 213ACC00 356DF200 02F00800 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00002E4C 20282A20 2B202D24 44303930 43303729
E4F2E400 00000F00 00000400 00000400 00000100 00000300 00000000 00000200 0001E400 212F3E00 21397400 213ACC00 356DF200 02F00800 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00002E4C 20282A20 2B202D24 37463343 31444236 29
-Ryan
Thanks, I can now reproduce the issues. The garbage non-ASCII characters are due to a bug affecting disassembling floating point conditional long branches. I have a fix for this.
(Checksum 0x97221136 is actually a Mac IIx ROM, which works with Mac II emulation.)
update 2/18/2019 - A new verion of FDisasm has this fix.
Sent: Wed Feb 13 20:13:47 2019
is possible add a option to increase or setup screen size?
[... email address ...]
Screen Size is a compile time option. You can use the Variations Service to compile a variation with the desired Screen Size.
Sent: Tue Feb 12 06:57:36 2019
Hi Paul,
I was trying out fdisasm 1.2.6 on the Mac II ROM using fdmacii 0.2.2, and I noticed some output that doesn't look correct. For example resource MDEF 0 begins with the remark "; !! field doesn't fit" followed by assembly that doesn't make sense. In comparison, the MDEF 0 code disassembled from the Mac Plus ROM using fdplusv3 0.4.3 looks reasonable.
In the Mac II ROM disassembly, there are 134 occurrences of "; !! field doesn't fit" and also some occurrences of garbled (non-ASCII) output. The Mac Plus ROM disassembly has only one "; !! field doesn't fit" and no non-ASCII characters.
-Ryan
Thanks for the report. I have only been able to partially reproduce this. I get only 7 instances of “; !! field doesn't fit”. This turns out to happen in the most recent version of FDisasm if a label is in the middle of an instruction. In the Mac II ROM, some of these happen because there is a table in the ROM being indexed into after subtracting a constant. And currently, it looks, to FDisasm, like the start of table is shifted by that constant. My preferred solution is to create a mechanism to tell FDisasm about that constant, which will make the disassembly more clear than in previous versions.
By there is one case where an operand in the middle of an instruction is being referred to by other instructions. Ugh. I think I would prefer to put the label at the beginning of the instruction and have the referring instruction have a constant as above, so that Reasm won’t need to deal with labels in the middle of an instruction.
One possible explanation why you are seeing more of these warnings is that you are disassembling a different version of the Mac II ROM. The formatting information I provide is for the ROM with the checksum 0x9779D2C4. If your ROM isn’t very similar, it would get out of sync with the formatting information and there would be a lot more instances of this issue. But I’m still not sure how you would get non-ASCII output.
update - follow-up message
Sent: Sat Feb 2 05:02:26 2019
no ROM image
Is this project active?
I see an executable without need for gcc. When I run './'Mini vMac' an emulated screen appears but the message above is the content.
m190202_045635_010.bin.tgz
and
minivmac-36.04-lx64.bin.tgz
produced similar results.
[... name ...]
To get started with Mini vMac, see the Getting started with Mini vMac page.
For the latest project news, see the Latest news section of the website main page.
Sent: Wed Jan 30 07:21:54 2019
Hello, I noticed that at the top of the latest news page, the newest updates list the year as 2018 rather than 2019.
Thanks! I have made this correction.
Sent: Wed Jan 30 04:04:40 2019
Hi there! I was looking for the Mac OS 9 (PPC) release of Mini vMac and couldn't find it anywhere.
I don't really expect it to still be supported, but I do remember it existing at one point, having used it a bunch to run older programs on my old G3 iBook.
Sorry, the version of GCC I’m now using, for a set of cross compilers, doesn’t support classic Mac OS. I would like to figure out how support classic Mac OS again eventually.
Sent: Mon Jan 21 09:44:44 2019
I don't mean to bother, but it just seems that as I try, I don't see that Mini vMac works anymore with disk images... I tried many different ways to get the disk image to load, or "boot", but it does not function,... I have also tried the .dsk "disk1.dsk" option for it to automatically "mount", but it does not seem to respond.
Is there something that has occurred?
Do you mean that you have disk images that can be mounted with old versions of Mini vMac, but not current versions of Mini vMac? Or do you mean that you have a disk image that you can’t mount with any version of Mini vMac? In the latter case, probably the image got corrupted.