To send mail to me, use the feedback form.
( - latest - )
Sent: Thu Apr 18 15:39:16 2019
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?
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 making a set of source files with a new optional feature, I can take care of adding the option to the build system.
Sent: Tue Apr 16 01:57:41 2019
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,
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
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
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
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
Do you corrects bugs in Mini vMac? I suppose i found a bug when the mini vMac freeze with the flag on the screen?
[... 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
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.
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
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.
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
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
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.
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
I made a donation to you for $12.
How do I get the Sponsor Code?
I want a custom buid
[... 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
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.
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?
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
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.
[... 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?
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
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
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
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,
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
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
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
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.
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 prefered 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.
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.
For earlier mail, see the mail index.