:
Sent: Tue Jul 17 22:13:38 2018
Paul,
I've recently been looking into why the 1985 game "Winter Games" from Epyx freezes at the splashscreen in Mini vMac. Michael Juneau ("Mu0n" at the 68kMLA) told me he contacted you about this very problem way back in 2004. Our active discussion on the matter is at the following URL, with a quote from the email that was exchanged with you in 2004:
https://68kmla.org/forums/index.php?/topic/59618-epyx-winter-games/&do=findComment&comment=636944
Would you be able to comment on your findings since then?
Thank you,
James Wages (JDW)
status : work pending
I see it is said that Winter Games can work in MESS (now merged with MAME). Which changes things. For software that never worked in emulation, there is no clear path to figure out the problem. One could look at it for weeks with no guarantee of solving it. If software used to work in Mini vMac, and now doesn’t (called a regression), it is pretty straightforward to figure out which change broke it, and figure out why. If software works in a different emulator, that is open source (such as MAME), then I can think of a way to proceed that would be guaranteed to find the answer. Unfortunately, that method could take weeks or months.
Thinking further, I can think of an approach for helping to track down difference in the CPU emulation between emulators. That could be worth trying.
Sent: Tue May 5 15:58:56 2020
Hi again!
I've been remaking my 3DS port, and I'm interested in integrating it into the new build system.
How easy/hard is it do implement?
Currently I have to target SDL and manually edit the files with each options change.
So far the port itself performs well with sound on the New3DS model.
status : responded
The build system is a bit messy, since it is dealing with the messiness of numerous development tools. Also I am contemplating making some extensive changes to it.
I could merge your code into my version of the source, including the setup tool. But changing it to strictly follow my conventions would probably make it something you wouldn’t want to work with, and so not useful.
It may be easier to just create a shell script that makes needed changes to the output for SDL. A possibly useful option to the build tool is “-l” which makes it generate a list of source files, which might or might not be easier than extracting from the generated make file.
Sent: Thu Apr 30 08:28:48 2020
Hi Paul, thanks for vMac. However, I have a problem with a 35 year old program. The program provides for writing and reading files on disk. By executing the program in which the OPEN "R", # 1, "inventory" instruction is included, it stops and the writing: Disk Write Protected appears. How can I get around this?
Thanks
status : responded
That’s still not really much information.
First question would be, is the disk actually writable? You could try duplicating a file in the Finder to test this.
If that isn’t the problem, it might be some incompatibility. If it really is 35 years old, from 1985, that is before the Macintosh Plus came out. You might need to use the Macintosh 128K emulation. You might need to use an MFS disk image instead of HFS. (The “Blanks” archive has some.) You might need an earlier system version than 6.0.8, the earliest currently available from Apple.
Sent: Mon Apr 27 02:24:50 2020
Hi Paul C. Pratt,
I want to translate your application into Indonesian :)
Regards,
Tsaqib
status : responded
Thank you for the offer. Translations are most welcome. Some information is on the Mini vMac Localization page. Basically, you can just create text corresponding to existing translations, and send it to me via the feedback form, or else upload it somewhere else on the web and send me a link.
I see that according to Wikipedia, the Indonesian alphabet “consists of the 26 letters of the ISO basic Latin alphabet without any diacritics”, which makes it particularly easy for Mini vMac to support.
Sent: Sat Apr 25 16:27:44 2020
HI, sorry my english. My name is Cristian, i did a custom build in mingw + XP 32bits
Everything is working fine, but i cant disable FPU emulation in Mac II
Any way to disable FPU emulation? Wolfenstein 3D is not working with current fpu emulation, and i need mac II for color display
thanks
status : responded
A Macintosh II will not work without the FPU. In the Macintosh IIsi, the FPU is optional. But Mini vMac does not emulate the IIsi yet. And it doesn’t look so simple - according to Apple’s developer note it is using the built in MMU of the 68030 CPU to remap memory. Emulating an MMU seems like even more of a headache than emulating an FPU. In particular, mid-instruction bus errors.
Sent: (via email) Thu, 23 Apr 2020 03:40:07
Hi Paul,
Thanks for the Sponsor Code. I gave the custom build utility a try, and, while a little bit daunting to figure out what is what and in aiming to recreate the default binary's setup for the most part, it's quite useful/good.
My suggestion is to start with the default setup as a template, and allow the user to custom edit only those 'advanced' features that concern them, in an expanding fashion. This will make the user interface of the builder a lot less daunting and a lot more user-friendly.
Your documentation on the site is noothing short of excellent! The best I've seen in recent years -- really well written! Concise, yet provides almost all key information efficiently.
I do have one problem with Mini vMac out of the box, so to speak:
While running HyperCard on System 7.1, I've encountered a number of complete system freezes while the software was playing back audio *and* changing/transitioning an image at the same time.
At first I thought the ROM may be responsible, but after trying a few different dumps, it seems to me that this is actually some sort of bug/problem with the emulation. Have you received any reports of this yet?
One thing I am thinking of trying tomorrow is to build a custom binary with the sound completely disabled, and see if the freeze still occurs. (Going by process of elimination to find the cause.)
Two instances where these freezes are more or less consistent is the changing of the ballerina poses in the HyperCard Tour feature, and the opening and closing of drawers repeatedly in "the Manhole".
Both events cause the system to completely freeze, even though Mini vMac is still responding with its hover menu.
I am forced to forcibly quit the emulator, as the system is rendered completely useless/stuck, with no end in sight and no means to get control back.
Let me know if you need more details. I hope there's a solution for this problem. Looking forward to hearing from you.
Kind Regards,
Bryan
Sent: (via email) Fri, 24 Apr 2020 22:00:56
Hi Paul,
A follow-up on this:
After running a few tests, it seems this is not sound or graphics, but emulation related. On lower emulation speeds the freeze occurs less often.
More interestingly, the emulation speed will suddenly change for a brief moment, and run at full speed (making the visual transition instant), regardless of my speed setting in the emulator. I believe this is what's messing with the software and causing it to freeze. I'm not sure if this is a bug of a feature of the emulation. Is it playing catchup?
I am running Mini vMac version 36.04 on a 64-bit Linux Debian 9 (Stretch) machine, with the following setup:
-br 36 -t lx64 -fullscreen 1 -magnify 1 -drives 16 -bg 1 -as 0 -svl 5
Here's how to reproduce the problem:
1. Run HyperCard, click on the HyperCard Tour icon.
2. Click through the introduction.
3. Select "Looking at HyperCard".
4. Keep clicking the "Next" button until you reach the ballerina
(after the parrot).
5. Click the ballerina position labels to play the image transition and
sound. Do this a few times going through the positions. Chances are
instant transitions will begin occurring and the software (in fact the
whole System) will freeze after that.
This sudden snap-transition should not be happening. The software is not programmed to allow for it -- so it's an unexpected emulation inconsistency.
If you get this email, let me know if you're interested in seeing/testing it in action, and I'll send you a zipped live package with my virtual hard disk and setup (with System 7.1 and HyperCard installed).
Let me know if you have any settings tips/tweaks regarding emulation speed and accuracy that may help solve this mystery/problem.
Thanks.
Kind Regards,
Bryan
Sent: (via email) Fri, 24 Apr 2020 22:52:08
Hi Paul,
Found a workaround!
I had to make a build with "-ta 0" added, and run the emulation at 1x speed.
The cycle estimation ("Timing Accuracy") is what's messing with the software and causing the whole system (including the mouse cursor) to freeze.
Forcing the emulator to not skip anything ("least accurate timing", but highest emulation accuracy) and to run everything at real-time speed (1x) eliminates the issue.
I see from the documentation that the "Timing Accuracy" (cycle estimation) is still something you're working on and perfecting, right?
It's nice to have the old system running swift at 8x speed, but this shouldn't come at the expense of emulation/software errors.
Hope this helps.
Cheers,
Bryan
status : fixed in alpha version
Thanks for the bug report. I can reproduce this issue with the HyperCard Tour stack and the Manhole, when running at faster than 1x speed. I’m not seeing it when running at 1x speed, regardless of timing accuracy. Are you sure you are seeing it in that case?
If it is only not working at faster than 1x, that is not exactly a bug, just an incompatibility. It is to be expected that some software would not work with what is inherently inauthentic. Perhaps some changes to exactly how the how the extra cycles are added might allow some programs to work better, but then may break other programs.
There have been only a few known incompatibilities with 8x speed in nearly 2 decades, and defaulting to 1x speed would make Mini vMac much less usable. So I think the 8x default should stay. For people who feel otherwise, it is a compile time option (“-speed z”).
But I should document somewhere known incompatibilities
Regarding the Variations Service, if you say that it is not clear to you, then you are right by definition, and I should make try to make it clearer. But I’m not sure how.
The form does say “The above choice is the only one required. Change at least one of the options below to customize your variation.” So nothing needs to be done to “recreate the default binary's setup”. Just don’t change anything. I guess I should say that explicitly in the directions.
Regarding the many options, the intent is that people should try the Basic service first, which has only a few options. After seeing how that works, they should have more confidence in using the Advanced variations service.
As for grouping similar options together, which then could have a control to expand/collapse, that can’t be done with basic HTML. A design constraint of the website is that it should be usable with the earliest web browsers that can run on a Macintosh Plus. (Admittedly this constraint is mostly an excuse for me to not have to keep up with web fashions.) Anyway, I’m not convinced that such a control would actually make this page easier to use.
update 4/25/2020 - I’ve tried to make the Variations Service Directions clearer.
update 4/26/2020 - After reviewing the source code and fiddling with it, I’ve changed my mind. Better behavior is possible.
In the latest Mini vMac Development source snapshot, the emulation of VIA timer 2, used for playing sound, has been modified when running at greater than 1x speed. There is no correct behavior in this case, it is just a matter of picking what has the best compatibility with the greatest number of programs. This change fixes the reported issue with HyperCard, as well as playing alert sounds in the Sound control panel, and the "Try Scale With Sound" command of ResEdit. However it also no longer passes the Clock/Interrupt Test of MacCheck. Which seems a good trade off, unless further issues are found. (A program to test hardware *should* notice that something is strange when run at greater than 1x speed.) The specific change made is that timer 2 now continues to run during extra cycles only for the duration of a short timer interval, rather than continuing to run in this case until the end of the extra cycles. (Normally, the timer is paused for the extra cycles.)
Sent: Sun Apr 19 20:52:53 2020
Hello,
Thank you for minivMac which is an excellent piece of software!
However there is one bug that bothers me: the emulation of 68020+ bit field instructions' handling of Z and N flags is broken in minivmac 36.04
This causes an issue in the Macintosh versions of the game 'Dungeon Master 2' where doors won't open. See here: http://dmweb.free.fr/?q=node/70
This emulation bug was identified and fixed in WinUAE a long time ago, so I took inspiration from the WinUAE fix to apply it to minivMac source code.
I'm 100% positive this is an emulation bug and that the proposed fix below does fix the door opening issue in the game: I compiled a version of minivmac with the fix included and now doors do open normally. However I'm not at all certain that the proposed change won't have any unwanted side effect. I'll let you check into this issue and validate the fix because I'm no expert at all in emulation.
I fixed the bug by applying the following changes in file MINEM68K.c (source code of version 36.04):
Remove the line containing:
NFLG = Bool2Bit(((si5b)tmp) < 0);
Remove the line containing:
ZFLG = tmp == 0;
Find this line:
if (newtmp != tmp) {
And add these two lines right before (adapted from the WinUAE source code) to replace the two removed lines above:
NFLG = (newtmp & (1 << (width - 1)) ? 1 : 0);
ZFLG = (newtmp & ((1 << width) - 1)) == 0;
I hope you'll include this fix in the next version!
Best regards,
Christophe
[... email address ...]
status : fixed in alpha version
Thanks for the bug report, link, and patch.
My initial thought was that this is not the behavior documented by the M68000 Family Programmer’s Reference Manual, and it is not behavior that would make sense. But then I realized that BFINS is different from the other bit field instructions, and Mini vMac is not following the documentation for BFINS. Looking at a version of WinUAE source I had (from 2017), it indeed handles condition codes for BFINS differently. So the initial patch in the message was later fixed.
So I will make the change for BFINS, and hopefully that will fix the problem with “Dungeon Master 2”.
update 4/23/2020 - fixed
Sent: Wed Apr 15 15:57:13 2020
Please add a 32MB/64MB option to the Macintosh II version of minivmac. A lot of people need more ram when they are doing 2k or 1080p resolutions.
status : responded
For the most part, the amount of main memory used in a Macintosh II is not affected by the resolution. The resolution affects the Video RAM needed, which is separate. Mini vMac can emulate up to 4MB of video RAM, using a bit of a hack. (Normally a video card can only have 1MB of the 24 bit address space.)
More main memory could be emulated, but it wouldn’t work. See this previous message.
Sent: (via email) Mon, 13 Apr 2020 00:14:50
Hi Paul! Thank you very much.
I tried out the variations service to make a few builds--it works great, but I noticed that the "Auto Slow: [ ] Start Off" check box doesn't seem to have any effect. Regardless of the setting for the build parameters, Auto Slow seems to always start in the "off" state when I run the executable that's produced. I'm making builds for Windows x86-64, if that makes any difference.
It's also possible that I'm just making a mistake or doing something wrong or misunderstanding something!
status : fixed
Thanks for the report. For the Macintosh Plus emulation, and for most other models, Auto Slow defaults to on, and this option changes that. But for the Macintosh II emulation, Auto Slow defaults to off, and this option could have no effect. I have changed the advanced variation service (both stable and alpha) to make this option a default/on/off pop up, instead of a checkbox.
But for Macintosh II emulation, I wrote that AutoSlow is disabled by default because “may need some further tuning to work well with Mac II emulation”. I should look into what the issues are and see if they can be fixed.
update 5/3/2020 - AutoSlow is now enabled by default for Macintosh II emulation, matching the default for emulation other Macintosh models. To try to make this work properly, for Macintosh II emulation it now waits 60 ticks rather 34 ticks for AutoSlow to activate.
Sent: Mon Apr 13 13:17:31 2020
I'm having some graphical issues with vMac 36.04. I've got a nice setup for Dark Castle & Beyond Dark Castle. Here's the settings I used to compile 3.5.8:
-t imch -magnify 1 -bg 1 -ta 2 -speed z -sss 4 -svl 6
-n "minivmac-3.5.8" -maintainer "Silicon Beach Software, Inc.".
This produces a pixel-perfect image.
I figured I should update to 36.04. Here are the settings I used to compile 36.04:
-t mc64 -magnify 1 -bg 1 -ta 2 -speed z -sss 4 -svl 6 -n "minivmac-36.4"
Yet, with those options in 36.04, the image is not pixel perfect. It's completely blurred. I'm not sure what I'm missing here. Also, has the -maintainer option been replaced with some other compile option in 36.04 or has it been removed completely? Any help would be greatly appreciated.
Thanks!
Alex
status : fixed, maybe
It has been reported that Mini vMac does not compile correctly with recent XCode. I have been meaning to looking into it. The issue is that recent XCode requires recent OS X, which does not run on the version of VMWare Fusion on my main machine. A new SSD drive should arrive today on which I can install modern software on a spare mac (which has a broken internal drive).
The “-maintainer” option has been replaced by the “kMaintainerName” compile time definition for the “CONFIGUR.i” of the Setup Tool.
update : It turns out the old Mac can’t run recent OS X without a firmware upgrade, and a firmware upgrade requires a working internal drive.
update 5/9/2020: I think I have a fix, in the latest alpha, for some drawing issues when compiled with recent XCode. I’m not sure those issues include “blurred”.
Sent: Thu Apr 9 14:29:43 2020
Hi Paul,
First of all, I want to say you have one of the easiest Mac emulators I have ever used. I've used it a lot primarily for demonstration reasons and to show the differences between the operating systems, since on the surface they all looked the same.
With that said, I ran into a bit of a predicament. Every time I attempt to connect a virtual hard disk drive to the emulator running System Software 6 or earlier (not a floppy disk), it shows up with an icon of the floppy disk with the V on it. This might be a silly question, but is it possible to have it default to the original hard disk drive icon?
Thanks in advance,
R. King
status : possible feature pending.
Mini vMac does not actually emulate hard drives, it is more or less emulating floppy drives (though not really, it is replacing the floppy driver in ROM with something more or less compatible). If Mini vMac did not provide its own icon for large size images, then in System 6 or earlier they would just get a floppy icon. (In System 7 they get a generic document icon.) It would be possible for Mini vMac to provide a different icon, as a compile time option. I’m not sure there really is a single default hard drive icon. I don’t see any such resource in the System or Finder files. I suspect that various driver software just provided their own icon.
Sent: Tue Jul 17 22:13:38 2018
Thanks Paul for vMac. I have a problem that I can't solve. I have a program that reads and writes archive data to disk. When I execute the Open or Put instruction to read or write data on disk I cannot run the program. How can I do? Thanks
status : responded
I’m sorry, you have have not provided enough information for anyone to help you.
Sent: Tue Apr 7 02:45:47 2020
Hi Paul -- I'm one of your devoted followers as Minivmac allows me to continue running a program I created -- wow -- 28 years ago. I just tried and found that I can no longer run Minivmac under Mac Catalina (10.15.4) so I had to fall back on my Powerbook G4. I have a couple of questions ..
* Are there any plans for Minivmac to be updated to run under Catalina?
* I understand that Minivmac can be compiled to run under IOS (iPad Pro) ... unfortunately the instructions seem to be designed for developers. Can you point folks to some "for dummies" instructions regarding compiling for IOS?
If you've retired from this project, I understand. Thank you for making this program available. I'm sure many have been amazed and humbled by your dedicated efforts (and good humor).
Sincerely,
Todd Katz
Sent: Tue Apr 7 02:57:07 2020
Todd Katz here again .. after reading other comments I went back and re-installed minivmac. Works fine on Catalina. I'm so happy. Thank you again. Sending $25.00. Cheers,
status : responded
I’m glad it works for you. Thanks for your donation.
As far as I know, Mini vMac should work fine in Catalina. If you have any idea why it didn’t for you at first, that might help other people avoid the problem. I could improve documentation and/or improve error messages in Mini vMac.
There is a port of Mini vMac to iOS (see the Ports page), but I am not involved in it, and the code is not merged into my version of the source.
Sent: Sun Apr 5 17:59:00 2020
hi, I am having such a hard time getting any emulator to work. I am not gifted technically but I do know to allow unknown apps to open thru my security settings. But I am getting the cannot find ROM image error message. I have a mac sierra 10.12.6, my email is [... email address ...] I would truly appreciate any help. Thank you!
status : responded
Please see the Getting Started with Mini vMac instructions.
Short answer: drag your ROM image file onto Mini vMac. If you don’t have a ROM image, see the FAQ section about ROM images.
Sent: Tue Mar 31 02:33:28 2020
Howdy Paul. Seems every time I build an Alpha w/ Local Talk set to On ... The Macintosh II vMac crashes when loading any 7.1+ System (7.1, 7.11, 7.5.3) - including install disk images which usually load on anything. "Sorry, a system error occurred. divide by zero". Temporary disabling extensions does not help, as I mentioned - it happens even when just loading the System install disks as well (not a full OS). When not checking the box for LocalTalk - all works as expected. Thanks! Petar: [... email address ...]
status : open bug report
Thanks for the bug report. I have verified this issue. (Regressions in emulation, thing that used to work and now don’t, can always be fixed. For things that never worked, there is no straightforward path to a fix.)
Sent: Sun Mar 29 20:27:52 2020
you cant mount zip files
status : responded
Yes, this is mentioned in the Floppy Drives section of the Emulated Hardware Reference.
First, this is “Mini” vMac, and code for unzipping is a bit complicated. Second, I don’t think zip files can be randomly accessed, so to support zip files would mean unzipping the whole thing first, which wouldn’t have much advantage over doing this manually.
Sent: Sat Mar 28 18:39:19 2020
thank you for Mini vMac! I use it a lot.
Unfortunately your variation service seems to have a problem at the moment. Every time I try to generate one I get "Sorry, I failed to compile this variation"
I'm just trying to make pretty much standard variation, just running in 800 x 600 resolution.
status : believed fixed
Thanks for the report. I’ve confirmed that Macintosh OS X PowerPC builds were broken. I think it is fixed now.
I believe I broke this while recovering from a drive failure in the build server in the beginning of February. I verified the integrity of the cross compilers and their supporting files, but the Macintosh builds use some files from the host system. And one wasn’t adjusted for a change I made in how the replacement drive was configured.
Sent: Thu Mar 26 16:59:18 2020
One user wrote:
"I'm curious as to the behavior of fullscreen mode when invoked by ctrl-f versus the compile option. I have a 13" MacBook air and use macports to build mini vmac with screen size option -hres 704 -vres 450 (exactly half the vertical screen height)."
Doesn't HRES and VRES have to be a multiple of 32? In this case 450 isn't and may be the source of the problem.
status : responded
Thanks for the suggestion. But only “-hres” has this constraint, not “-vres”, so that is not the issue in this case.
I believe the issue is as previously stated, and a fix is pending.
Sent: Tue Mar 17 08:15:41 2020
Hi Paul,
please stay healthy. And thanks for your wonderful work.
- Karl
status : responded
Thanks. Sneezing with no fever for a few days, which is over now, almost certainly means cold. And at age in low 50s, with no known condition, I’m not at that high risk. But living with people at much higher risk means trying now to stay healthy at all costs.
Please try to stay healthy yourself, and same to other readers.
Sent: Tue Mar 17 04:12:16 2020
A question? Can this virtually also operate on Android mobile?please send answer to [... email address ...] appreciated thank you for your time.
status : responded
There is a port of Mini vMac to Android, though I am not involved with it. See the Ports page.
Sent: Sun Mar 15 21:18:59 2020
Sent: Sun Mar 15 22:54:09 2020
Sent: Mon Mar 16 00:15:02 2020
Hi Paul,
I've been working with building the Mini vMac source from scratch. I'm emulating a Mac 128k. The Mac's screen on the version I build seems blurry compared to the standard 128k variant I can download from your site, almost like the version I'm building isn't optimized for my Retina MacBook Pro. Is there an option in the code somewhere that will fix this low-res issue?
Thanks!
status : work pending
See the disclaimer recently added to the Building Mini vMac page.
But I do intend to look into a number of different issues reported with recent XCode. A hold up is that it requires a recent version of OS X, that won’t run on the version of VMWare that I have set up on my main computer. I do now have a spare computer for doing this, but some set up is needed.
Sent: Fri Mar 13 20:46:09 2020
Hi, there, Mr. Pratt. I've read the FAQ and trawled through the boards without finding my answer. Here's what's happening on my MacBook Pro (2015 model) under OSX 10.13.6
Launch Mini vMac OSX UB 3.0.4 or Mini vMac (imch) 3.4.1 -- doesn't matter which, result is the same: black window with white "Unable to locate ROM".
Type C to clear the notice, drag my vMac.ROM onto the window. Result: Nothing. Window remains black.
Drag vMac.ROM onto the window again. Result: "Disk Image in use. I can not mount the Disk Image because it is already in use by another application or already open in Mini vMac."
Type C to clear the notice. Window is plain black from then until forever.
Any idea what I might be doing wrong?
Thanks kindly.
status : responded
Dragging the ROM image onto the Mini vMac window to recover from an “Unable to locate ROM” situation is a feature added in Mini vMac 36, the current stable version.
Mini vMac 3.4.1 and 3.0.4 are really old versions, and not available from www.gryphel.com. Downloading Mini vMac from somewhere else is not recommended and not supported.
So please get the current version from the Download Mini vMac page.
Sent: Sun Mar 8 18:07:32 2020
Paul,
I'm curious as to the behavior of fullscreen mode when invoked by ctrl-f versus the compile option. I have a 13" MacBook air and use macports to build mini vmac with screen size option -hres 704 -vres 450 (exactly half the vertical screen height). Using ctrl-f automatically magnifies it to the vertical screen height of the MacBook. When I include the '-fullscreen 1' option at compile time, it does not magnify the window at boot up. I have to add the '-magnify 1' option. I was wondering why the two methods are seemingly inconsistent?
-Mark
Great emulator btw. Enjoy using my classic software that has been collecting dust.
status : work pending
Thanks for the bug report. This happens because the code that automatically chooses whether to magnify or not is located in the code for the Full screen toggle command, and so doesn’t get called for the initial boot up in Full screen mode.
Sent: Sun Mar 8 10:26:58 2020
Hello
I noticed that recent versions of "mini vMac" built with Xcode 11 toolchain on macOS Catalina doesn't support "retina displays" properly - with screen crop 1/4 inside the window and some artifacts. Switching app to "low res mode" in Finder info panel fixes the issue. Build was made with magnification turned on by default.
Here's screenshot: https://imgur.com/a/yuM7kV4
Official build available to download or the ones from "build service" seems to be ok, so I assume there's something in recent versions of Xcode.
BR
Konrad Kołakowski
status : received, reply pending
Sent: Sat Mar 7 06:59:08 2020
I have my sisters tablet and its running Android 7.0 I will give you the details of it:
MODEL_HUAWEI
TYPE_HUAWEI_MEDIAPAD_T3_10
Okay I will tell you a problem with minivmac
when I load a 896k named disk with Mac OS system 6.0.2 It didn't work!
That was the problem so bye!
status : responded
I am not involved with the Android port of Mini vMac. If you have access to a Macintosh, Windows, or Linux computer, you could first try using Mini vMac there. Once you are familiar with Mini vMac, that may make it easier to figure out the Android port.
Sent: Fri Mar 6 16:42:31 2020
"I have not previously merged in serial port code into Mini vMac because of concern that the emulation is the easier part, that the platform specific code for every platform for talking to every kind of serial hardware would likely be an enormous amount of work to develop, maintain, and support. One person getting it to work for their own particular hardware is just the very beginning. And since I’m not sure that very many people would make use of it, it has been a low priority so far."
I don't think we need to develop host-specific hardware, instead, create a PPP connection through the serial port via a TUN interface on the host machine.
http://www.toughdev.com/content/2016/11/pcemacplus-the-ultimate-68k-classic-macintosh-emulator/
Another solution would be to write a simple host-side terminal application (maybe in Python as to use standard libraries) to connect to the emulated Mac for file transfers using the old kermit, xmodem, ymodem, and zmodem protocols!
status : received, reply pending
Sent: Tue Jul 17 22:13:38 2018
Hello there, I am Avedis Ghazarian and I have enjoyed your Mini Vmac program and has opened to me a whole lot. I was wondering since you are working on a Mac II version, will there be scsi disk support rather than adding floppies on startup? Thank you.
status : responded
It would be nice to add working SCSI emulation at some point (which would also be for a Macintosh Plus too). But it would not seem to greatly advance the primary goal of preserving early Macintosh software, and so hasn’t been a high priority yet.
Sent: Thu Mar 5 00:54:03 2020
Why re-invent the wheel?
Found out that "Previous", a NeXT computer emulator, has available a complete debugged 68030 MMU emulation code based off Hatari and indirectly, WinUAE. PCE/macplus also has a functional serial port emulation.
All that needs to be done is "borrow" their code and merge it into Mini vMac! Easier said than done but the ingredients are all there... a Macintosh IIx with a IIfx ROM upgrade, 128MB RAM and serial port is totally possible! (IIfx emulation is not possible because it has different hardware from II/IIx)
We can leave FPU as SoftFPU via F-line opcodes at this time since it is already quite fast. I'm hacking my brain just trying to figure out your 68020 emulation code... my only experience in emulation is writing an Apple ][ emulator in Python! Only the 6502 CPU, disk drive, keyboard, and video... it beeps too! I don't emulate clock at all... always full speed ahead!
https://unix.superglobalmegacorp.com/previous/newsrc/src/cpu/cpummu030.c.html
https://www.bigmessowires.com/mac-se30-with-upgraded-rom/
http://www.hampa.ch/pce/pce-macplus.html
status : responded
Thanks for the links.
Since different programs have different architectures, it is not as simple as copy and paste, but it can still be helpful to look at their code.
Licenses must be considered, but both are GNU General Public License version 2, same as Mini vMac, so it is not a problem here.
I have not previously merged in serial port code into Mini vMac because of concern that the emulation is the easier part, that the platform specific code for every platform for talking to every kind of serial hardware would likely be an enormous amount of work to develop, maintain, and support. One person getting it to work for their own particular hardware is just the very beginning. And since I’m not sure that very many people would make use of it, it has been a low priority so far.
For MMU emulation, one concern is that it might take a major reworking of the CPU emulation to emulate bus errors properly (aborting mid instruction), and it may be difficult to do without being significantly slower. At the very least, the code has to be structured so that it is not slower than it currently is when compiling a version where bus error emulation isn’t needed.
Sent: Tue Mar 3 02:35:45 2020
Hi Paul,
I assume you wrapped the CJ-Classics download for Cliff Johnson? When I open the app I noticed the disks are locked so I can't save a game in progress. I took a peek inside the package and it looks like you're running an AppleScript to select which mini vmac build (Intel or PPC) to open, but the disk files themselves are not locked. Have any idea how they are being locked?
status : responded
No, that isn’t mine. In general, if it is not on “www.gryphel.com”, I can’t vouch for it.
(There is also “www.gryphel.org”, with the same content from the same web server, but using http instead of https, for very old web browsers that can not handle https. But no one else should use it, because it is less secure.)
After looking at the current download files, I have removed the links to these games from my website, for not complying with copyright law (by including System Software and a ROM image). Also, I would prefer that other people don’t distribute a copy of Mini vMac, when that copy won’t be kept up to date. (And though it is probably not the issue in this case, I would generally prefer that people don’t download Mini vMac from other websites, when it might actually be malware, which I have received complaints about in the past.)
Anyway, the disk image “disk2.dsk” seems to contain the games, and when using my own copy of Mini vMac and System Software, I don’t see that it is locked. (And I’m certainly not about to run the included copy of Mini vMac.)
Sent: Sat Feb 29 12:26:07 2020
I found a minivmac II project for Windows RT and Windows 10 on ARM:
https://github.com/friedkiwi/minivmac
Please add it to your ports page.
What is the ETA on ARM Windows being on your variations service?
status : responded
Thanks for the link. While the Ports page does have a disclaimer that I take no responsibility for these ports, nonetheless I would prefer that the author of pages I link to at least say what it is supposed to be.
Official support for a platform, including being in the Variations Service, requires existence of a portable cross compiler for it, such as GCC.
Sent: Sat Feb 29 05:50:21 2020
Hi Paul,
When running LucasArts adventures games, namely Monkey Island 2 and Indiana Jones and the Fate of Atlantis, everything seems fine at first, but then the iMuse midi music tends to get bogged down - i.e. the instruments go slowly out of sync and/or stutter and skip.
Is this due to the specific drawbacks of emulating a Mac II, or is it something that I could address with some settings adjustments?
Similar issues occur in SheepShaver with all LucasArts games, and I put it down to enforced virtual memory in that environment.
Regards,
Adam
status : open bug report
Thanks for the bug report. Next time I’m fiddling with the ASC emulation code, I can test if changes have an affect on this. (Regressions in emulation, thing that used to work and now don’t, can always be fixed. For things that never worked, there is no straightforward path to a fix. Often, one isn’t even sure it ever worked on the real hardware. I have a real Mac II, but not conveniently accessible.)
Sent: Fri Feb 28 00:16:16 2020
Hi there I followed the windows method of using HFVExplorer to add files to a new blank disk image. The files are adding to the disk image fine but when I open the disk image and try to execute the files in minivmac that I added to the new disk image the files have become corrupted and won't open..Why so? It doesn't matter whether I add a .sit image or if I add a .dsk image to the new blank disk no matter what kind I add when I go to open the files in minivmac they have been corrupted once they have been transferred using HFVExplorer to a blank disk. Trying to figure out what is wrong and why the files are becoming corrupted once I transfer them to a new blank disk image with HFVExplorer. I am using a 24MB blank disk image and transferring files to it that are smaller. Thanks
Sent: Fri Feb 28 02:37:36 2020
If I use HFVExplorer or ImportFl no matter what kind of file I import I can't open the file in Minivmac and I get the message "The application is busy or missing" everytime even if I just import a .dsk file. What's wrong? Thanks
status : responded
I have revised documentation to say that HFVExplorer is no longer recommended. And I have revised documentation for ImportFl to try to make these issues clearer. And further, I have made an update to the ImportFl application so that it will set the creator type to “SITx”, so that double clicking on the imported file will open it with Stuffit Expander, which is most often what is desired.
Sent: Thu Feb 27 04:06:46 2020
"For Macintosh II emulation, the hardware can accept more ram than 8M, but the operating system can not handle it. (The ROM is not 32 bit clean) The additional software MODE32 is said to allow use of more RAM, but a PMMU is required, that Mini vMac does not emulate yet."
How feasible is it to load a clean ROM (i.e. a 512K ROM from a IIfx) into the emulated II and then do a simple patch to the System Software 7.5.5 to boot up correctly? I've read people successfully using this system patch on real hardware replacing their dirty ROM with a clean ROM.
"Following are methods for installing OS 7.0.1, 7.1, 7.5.3, 7.5.5, 7.6.1, 8.0, or 8.1 on an SE/30 with a IIsi or IIfx ROM SIMM. With these ROM SIMMs Mode 32 is not required and should not be installed. Minimum hardware requirements: 16 MB RAM, 44 MB free space on hard drive."
I've also read that MODE32 v7.5 works on a II without a PMMU.
"Mac II without a 68851 PMMU running System 7.1 or newer won't hang on restart."
Sent: Thu Feb 27 15:03:50 2020
Going back with the idea of using a IIfx clean ROM (version 4147DD77), I did some hex search and compare for Sony_DriverBase and found it to be at offset 0x06c3e0. I am going to edit the source to load your patch at this location and also bypass the ROM checksum routine for the IIfx ROM. I am hoping that the 512K ROM (instead of II's 256K ROM) will load up just fine... is this going to work? Do you have any other thoughts to make Mini vMac IIfx ROM compatible? It just occurred to me that IIfx ROM may actually have 68030 code embedded because the 30/SE and IIx has a 030 CPU... vMac may need 030 emulation which I believe it doesn't, which also brings to mind that the 030 also has an internal MMU but since I'm not expecting more than 16MB RAM it shouldn't be necessary to emulate yet. The 030 has almost the same instruction set as the 020:
(CALLM) Removed
PFLUSH Invalidates specific entry in the address translation cache (ATC)
PFLUSHA Invalidates all entries in the address translation cache (ATC)
PLOAD Load an entry into the address translation cache
PMOVE Load an entry into the address translation cache
PTEST Get information about a logical address
(RTM) Removed
(*) Almost forgot... I also have to find the location for the video driver patch as well...
status : received, reply pending
Sent: Wed Feb 26 09:23:45 2020
Hi Paul,
Just f.y.i, I've downloaded a 3.7 branch alpha mac II using the text variations service with these parameters:
-br 37 -t mc64 -lang ger -m II -vres 400 -magnify 1 -sony-sum 1 -hcr 39321 -hcg 52428 -hcb 65535
and
-lt
... on start, it begins to load the OS (7.1.1 German) and then crashes with an error 4 (division by 0).
Thanks for your great work!
Have a great day,
Karl
status : work pending
Thanks for the bug report. I will look into it.
update 3/15/2020 - I can reproduce this issue. The options that matter are “-m II -lt” with System 7. Booting with System 6 does not have this problem. But there is the same problem when boot with System 6, turn on AppleTalk in the Chooser, restart and boot with System 7. Can have same problem even without the “-lt” option by turning on AppleTalk and restarting. The last path can be done in Mini vMac 36 with the same result. The only relevant change in Mini vMac 37 is that the “-lt” option now enables the AppleTalk setting in PRAM, making the problem immediately obvious.
Sent: Wed Feb 26 08:24:23 2020
Hi there. How can a place .sit files onto the hard drive disk image so I can open them with Stuffit? I can't open them in the emulator to add them to the hard drive image using the open in either file menu, so I am trying to figure out how I would possibly add to or edit the hard drive .dsk file so I can add the .sit images to the hard drive so I can see them and open them with Stuffit in the emulator and not loose their forks. Thanks
status : responded
The Mini vMac extra ImportFl allows you to import files into the emulated computer from the real computer.
Sent: Tue Feb 25 20:57:21 2020
Paul,
I'm trying to get mini vMac to automatically load disk1.dsk which has System 7.5.5. According to the docs "In the Mac OS X version, if the mnvm_dat folder exists it will look there, in the same way it looks for the ROM image." I placed the MacII.ROM in /Users/[UserName]/Library/Preferences/Gryphel/mnvm_rom/ and disk1.dsk in /Users/UserName/Library/Preferences/Gryphel/mnvm_dat/. The ROM loads fine but not disk1. Is this a bug or should it be placed somewhere else?
status : responded
Mini vMac will only look for a “mnvm_dat” folder inside the “Contents” folder within the application bundle (control click on the application and choose “Show Package Contents”). It does not look for a “mnvm_dat” inside the Preferences folder.
The Preference folder applies to all copies of Mini vMac on the computer, which makes sense for ROM images. It does not make sense for all copies of Mini vMac to open the same disk images.
Sent: Tue Feb 18 23:07:17 2020
Hi Paul,
Tried to run the latest Alpha (2 times) on Windows computer..but the two doesn't seem to "see" each other. Tried it some time ago on Macos and it worked. Is there no LocalTalk on Windows?
Regards MacTjaap
https://68kmla.org/forums/index.php?/profile/894-mactjaap/
status : responded
First, Mini vMac needs to be compiled with the “-lt” option to enable LocalTalk emulation. This option is available in the Advanced Variations Service and also the Text Based Variations Service.
Second, if you attempt to enable this option for Windows in previous versions of Mini vMac, you will get an error, that it is implemented only for OS X.
However, the very latest Alpha version now implements this for Windows. It is not at all well tested yet.
Sent: Fri Feb 14 01:46:56 2020
Paul,
I'd like to verify that Adam's reply to my initial query about "the mouse behavior and other oddities in full screen mode on macOS 10.14+" does appear to work.
Amusingly enough, signing the app took me a few tries so I thought I'd show everyone the command line that worked for me. This needs to be run in the same directory as minivmac.app.
I suspect that a majority of users are not paying for a developer's license. However, as long as they have a Developer Account they can still sign. I was able to find the right command line by using Keychain Access. The user@domain.com is your Developer account (often your AppleID) and the YXXXYFSGN4 is from my Apple Developer cert, found using Keychain Access -> My Certificates -> Apple Development.
sudo /usr/bin/codesign --verbose --deep --force --sign 'Apple Development: user@domain.com (YXXXYFSGN4)' minivmac.app
While this appears to resolve the crazy mouse syndrome, it does not seem to help the graphical issues. Redraw is still very laggy; in particular window closing/opening highlights the difference. I've built the same release (36.04) on both 10.12 and 10.14 with the exact same options. The graphical performance of the 10.12 build is considerably faster. If you would like binaries I can provide them, but I suspect that since you have a newer Mac you don't need them.
I still find it rather strange that the compilation OS makes a difference. Since the libraries are dynamically linked the behaviour should be the same, regardless of the compilation host. Perhaps this is something as trivial as a bug in clang...
John
Sent: Fri Feb 14 02:10:45 2020
Paul,
This is a follow-up to my last message at 'Fri Feb 14 01:46:56 2020'. I've discovered even more oddities regarding the compiles and signing. While building on macOS 10.12 resolves poor graphical performance on 10.14+, it does not help the crazy mouse issue. The mouse is still randomly jumpy with the 10.12 build. Furthermore, if I sign the 10.12 build on the 10.14 machine it actually makes the mouse even worse (really). It's so bad that you pretty much cannot use it - but only in full screen mode, oddly enough. This is probably starting to get confusing so I've made a small chart:
build OS | mouse | graphics | sign | fullscreen ------------------------------------------------ 10.12 jumpy fast no yes 10.12 unusable fast yes yes 10.12 OK fast yes no 10.12 OK fast no no 10.14 jumpy slow no yes 10.14 OK slow yes yes 10.14 OK slow yes no 10.14 jumpy slow no no
I suspect as more users move to 10.14 and later the issue will become more noticeable.
John
status : work pending
I suspect the issue with the jumpy mouse could be a problem with CGWarpMouseCursorPosition. This can be tested by trying the “-emm 0” option.
Real Soon Now, I should set up a recent version of XCode to look into this myself.
Sent: Wed Feb 12 12:25:26 2020
What about Mini vMac in Polish?
status : responded
There is a Polish translation of the Mini vMac user interface, by Przemysław Buczkowski. It is a compile time option, so the easiest way to use it is with the Variations Service.
Sent: Tue Feb 11 17:00:01 2020
there is a Windows RT build found here:
https://www.windows-arm.com/index.php/desktop-apps-for-windows-rt/720-mini-vmac-for-windows-rt
Please add it to your 3rd party ports section.
I tested it and it works but it is based on a non-FPU build so seems pretty useless for modern use. It also has some issues on tablets in full screen mode. There is no minivmac II yet so I will try compiling one.
If you'd like, I can take some screenshots. This kind of software is desperately needed on this platform as the only productivity software for it is Office 2013.
status : responded
Thanks, I have added the link to the Ports page.
Sent: Mon Feb 10 11:47:57 2020
I need more native resolutions for the variations service like 400x240, 240x400,480x272, Why can't you add on the fly resolution switching?
Also, ImportFl does not import on Pocket PC anymore.
How soon can we expect Appletalk on Windows?
status : work pending
You can type in other resolutions in the Advanced Variations Service (and also the Text Based Variations Service). There are some constraints, such as the horizontal resolution being a multiple of 32 (so 400 and 240 are out, but 480 is fine).
Changing the resolution while the emulated computer is running can not work before the Macintosh II, the software is really not set up for that. For the Macintosh II, the video driver has a list of supported modes, so it would be possible to support multiple resolutions. But I feel this would add too much complication for too little benefit for “Mini” vMac.
Thanks for the ImportFl bug report.
Rob Mitchelmore states that his code ought to work on Linux, so I plan to try that sometime. If that works then sometime I could try to take a look at what is involved for Windows. If someone else who knows actually knows something about networking, and about Windows programming, took a look at it, it might happen faster.
Sent: Mon Feb 10 08:44:36 2020
Can you please add more RAM options to your variations service like 16, 32 or 1GB?
status : believed answeredOther than Macintosh II emulation, Mini vMac by default emulates the maximum RAM the computer can handle.
For Macintosh II emulation, the hardware can accept more ram than 8M, but the operating system can not handle it. (The ROM is not 32 bit clean) The additional software MODE32 is said to allow use of more RAM, but a PMMU is required, that Mini vMac does not emulate yet.
By the way, I looked into altering the Macintosh Plus ROM so it could be moved in the address space to allow more than 4MB of memory, but it wasn’t feasible, because operating systems, specifically ROM patches, rely on the exact location of the ROM.
Sent: Sun Feb 9 20:57:45 2020
update - follow-up message
Please don't take away my ability to compile with the newer and older Visual Studios.
You already support Windows CE ARM. You just need to modify the Windows CE project file (vcw/vcp) to have more processors to cross compile to. A few years back I went through your involved project file generation process and successfully compiled minivmac for x86 Windows CE and others. MIPS and SH4 should be the same simple process. Must I provide the binaries I compile myself for you to host as official versions?
As for Windows RT, you can purchase a Microsoft Surface RT or Microsoft Lumia 950 for around under $50-$69 on eBay. The Raspberry Pi 3 also works. Use WoA Deployer for Raspberry Pi and find an ARM64 Windows 10 1909 on pastebin to install.
If you need help, I can maybe provide binaries too but I'd really like to see an option for this and more CE architectures on your variations service.
Thanks to your variations service, I just got Word 6.0 working on my Pocket PC at 800x480 and Millions of colors. I thought I'd have to compile a new one manually again to get this working.
Some suggestions: Please always set Mouse Emulation Accuracy to "Less" on Windows Mobile/Pocket PC/Windows CE builds because it is impossible to click anything with it enabled.
Can you tell me why the color MacII is slower than Black and White mode?
status : work pending
There is no plan to remove the ability to compile with Visual Studio.
To clarify there are two different kinds of “supported” here. There are compiled binaries that I provide, both the standard variations and the Variations Service, using my chosen set of compilers. And then there is the ability for people to compile their own variations with their own compiler, using the Mini vMac build system.
Both are supported, but they are not supported quite the same. The variations I provide are much better tested, and much better optimized. Compiling your own is not recommended, unless you already are a programmer familiar with the C language and your chosen development environment. For all other compiler besides the set I use, the build system just tries to configure it for maximum chance of working correctly, and not for performance. If you want reasonable performance, you will need to try out various compiler options and then thoroughly test.
Thanks for offering to send compiled versions. But I prefer to only host versions I’ve compiled myself. I do though link to other people’s ports of Mini vMac.
re: Windows RT. I do have a Raspberry Pi 3. Finding a cross compiler is still an issue. I could at least look at properly supporting it in the build system compiling with Visual Studio.
re: Mouse Emulation Accuracy to "Less". Ok, I will look into that.
re: color MacII is slower. Pushing around up to 32 times more information (for millions of colors) is slower. That was also true running on the real hardware.
Sent: Thu Feb 6 18:45:23 2020
Hello Paul,
is there a way to change the Control Mode key from "ctrl" to something else?
Thanks,
Antonio
status : believed answered
Yes, this can be done with the “-km” (Keyboard Remap) option, which can be used with Text Based Variations Service.
There is also the simpler “-ccs” option, which just swaps the emulatated Control and Command keys. This is available in the Advanced Variations Service (and also the Text Based Variations Service).
Sent: Thu Feb 6 02:02:19 2020
Hi! I'm trying to get Galax to run but am failing to get Stuffit Expander to funcion. Any ideas? :)
[... url at abandonware site ...]
status : believed answered
Like many archives on that site, it can not be opened with Stuffit Expander 4.0.1. It can be opened with Stuffit Expander 5.5 in the Macintosh II emulation of Mini vMac. (Version 5.5 can be downloaded from my Stuffit Expander page.)
Sent: Thu Jan 30 05:14:21 2020
update - follow-up message
Please add Pocket PC or Windows CE MIPS, SH3, SH4 and Intel to your next compile list. If you need more processors, use the Windows CE Standard SDK 4.20 or 5.0
I would also suggest you add Windows RT ARM32 Windows NT versions. It already compiles with our Visual Studio. Use Visual Studio 2017 or 2019. We just need an official build.
The Microsoft hardware vendors are already selling new hardware with this OS like the Microsoft Surface Pro X. Compile ARM32 so the ARM32 and ARM64 users can benefit with the same binary.
status : responded
Thanks for the suggestions.
But there are a couple issues. The official builds of Mini vMac for all of the currently supported platforms are built with cross compilers, from a single version of GCC. One advantage is that this helps to avoid compiler bugs, and Mini vMac bugs that only some compilers trigger, on platforms that I don’t test myself all that much.
For a future version of Mini vMac, I’d be willing to give up that advantage and use a different compiler to support an additional platform. But I’d still require that it be a command line cross compiler, that can at least run on OS X. (And preferably runs on Linux too, and open source.) There does seem to be a Visual Studio for Mac, but it doesn't support compiling for Windows in C.
Another issue that to officially support a platform, I need access to that platform, at least in emulation. Apparently Windows 10 for ARM will run in QEMU, but I don’t know if it works well enough and accurately enough to test running Mini vMac. Microsoft Surface Pro X looks too expensive for me to buy at this time.
Sent: Mon Jan 27 03:38:51 2020
Hello, I want to participate in the localization of vMac. I can handle both Simplified Chinese and Traditional Chinese translations. My email is: [... email address ...]
status : responded
Thank you for offering to translate the Mini vMac user interface strings to Chinese. Unfortunately, as mentioned on the Mini vMac Localization page, displaying Chinese characters is not currently feasible for Mini vMac.
It is possible that some future version could make use of a Chinese translation. If a pinyin romanization of a Chinese translation would be useful to anyone, that could be handled by Mini vMac now.
There is currently a Serbian Latin translation, by SerbXenomorph, and also a Serbian Cyrillic translation for possible future use.
Sent: Sat Jan 25 19:08:55 2020
"For more emulated disk space, you can get a new blank disk image from the “Blanks” archive. I suggest using the “003M.zip” archive. Unzip it to get “003M.dsk”, and drag this onto the Mini vMac window to mount it. Once you import your “.sit” file into the new blank disk image, you need to expand it, with Stuffit Expander."
Brilliant. That worked perfectly. Thank you. Last question (at least for now :) I was wondering if it is possible to save a configuration of MvM so next time you launch it has the same setup as when you quit? In the case of doing some development (DH is a dev environment) I suppose I could look into exporting stuff before quitting and then importing after (as the process may require several sessions)?
Cheers,
Mark
Follow up sent: Mon Jan 27 16:46:12 2020
Hi Paul, not sure if I send something like this or not... kudos on the Mini vMac. Brilliantly done. I followed your instructions and everything worked perfectly. I did have a question about "losing" work after shutting down but have since discovered that it appears all disks are mirrored to the real computer and everything is stored. Again, absolutely brilliant and amazing. I am still just "discovering" these features as I mess with it, but so far fantastic. PS I have seen suggestions of contributing to Gryphel as that is what supports Mini vMac development. I'll be looking further into how to do that.
Thanks
Mark
status : received
Sent: Fri Jan 24 17:30:24 2020
Hi Paul, I dloaded an old piece of Mac software I wanted to revisit from [... abandonware site ...]. The page says if emulating it should run fine on Mini vMac. So, downloaded v36.04, SS 6.0.8, roms of course, and installed, all works well. Dloaded and installed ImportFl-1.2.1 which is a disk image, very lovely. Launched ImportFl. Now, when I drag the Double_Helix.sit file on to it, it provides an option to save (not sure if this means it reads and processes the .sit properly or not) and when I click Save I get a "Disk is full" error. Ahhhh, so close :) Wondering if there is some other route I should be going down. The .sit file is about 1.1 MB. Thanks so much. [... email address ...]
For more emulated disk space, you can get a new blank disk image from the “Blanks” archive. I suggest using the “003M.zip” archive. Unzip it to get “003M.dsk”, and drag this onto the Mini vMac window to mount it. Once you import your “.sit” file into the new blank disk image, you need to expand it, with Stuffit Expander.
Sent: Thu Dec 12 18:06:31 2019
Hi,
I'm the person who emailed you ... 9 months ish ago about LocalTalk over UDP. Apologies it's taken me so long to get back to you, life happened in large quantities and I had to work out how to do the paperwork to release the code.
I can now send you some code, if you would still like it. My email address is [... email address ...] [obviously please redact if this is put on the mail archive!], as it's probably easier to send code and stuff via email than a web form :-).
I've documented the protocol here:
https://windswept.home.blog/2019/12/10/localtalk-over-udp/
Thanks
Rob
Sure, I would be interested in merging in your code. I have sent you an email.
update 1/14/2020 - received code Archive.zip (info)
update 2/4/2020 - initial merge of code into latest Mini vMac Development source snapshot
Sent: Fri Dec 6 16:31:47 2019
Hi,
I'm trying to build Mini vMac on a MacBook Pro running Catalina. Everything works well except the display is messed up (image hosted here https://ibb.co/2Yhhhpr). This can be fixed by opening the app in low res mode but your pre-built versions don't use this 'hack'. So I was wondering I you could tell me what arguments you typically use for your builds... Here is mine: -t mc64 -lang eng -m Classic
I get the same problem with any model.
Thanks in advance!
Regards, LD
I wonder if it is related to this previous message. If so, signing might help.
I’m thinking of buying a Mac Mini to test recent Mac OS versions. (Or actually, buy a Mac Mini to replace an older computer in use, and then use the older one for testing.)
Sent: Wed Dec 4 00:23:07 2019
Hi Paul,
There's a bug in the Mini vMac 36.04 disassembly function (build with "-dis 1"), specifically for the BCHG/BCLR/BSET/BTST instructions. The disassembly shown by Mini vMac when running ROM code doesn't match the disassembly of the ROM file itself.
For example, this is the actual code in the Mac II ROM from 12/1987, according to fdisasm:
E87A 082E 0005 0016 BTst.B #$5, $16(A6)
I see the same when disassembling using MacsBug within Mini vMac, so I think that's correct. But Mini vMac's own disassembly shows the wrong register:
4080E87A BTST #5, 16(A4)
Another example: the ROM disassembly is:
6C00 0929 0004 BTst.B D4, $4(A1)
But what Mini vMac claims it ran is:
40806C00 BTST D4, 4(A4)
Again, wrong address register. As far as I can tell, this fixes it:
https://github.com/ryandesign/minivmac/compare/master...disasm
Thanks,
-Ryan
Thanks for the bug report and fix. I should figure out how to merge the code for this disassembler in Mini vMac with the code of FDisasm, which by now is fairly well tested, and testable. The disassembler in Mini vMac is not so easily testable.
Sent: Sun Nov 24 13:41:36 2019
how,s the mac II doing, i,m looking up to a complete mini vMac II, or at least one with the floating point
status : received