To send mail to me, use the feedback form.( - latest - )
Sent: Sat Feb 21 12:26:35 2015
Hello again, sorry to bother you with this.
Mini VMac for Linux segfaults when trying to compile a new version using the build system, or to export a file with the ExportFl program. I can reliably reproduce this segfault with both the 32bit and 64bit versions, with vmac running either system 6 or system 7. Host system is Ubuntu Studio 64bit.
Many thanks for any help you could give me on this,
- Éric. (Montréal, Canada)
Thank you for the bug report. I have found a bug that may have caused this.
In the Linux version, when exporting a file, Mini vMac will normally try to save it to a folder named “out” in the application directory (creating the folder if it doesn't exist). If file permissions are set so that Mini vMac can't find or create this folder, it will crash, due to not properly handling errors in the routine “FindOrMakeChild” in the source file “MYOSGLUE.c”.
I'll make a new development source snapshot with this fix. In the mean time, you can work around this problem by changing file permissions on the application directory, or by using the “-d command line option” to tell Mini vMac to use a different directory.
Sent: Fri Feb 13 09:41:04 2015
from - [... email address ...]
subject - New outfit for Gryphel!
Hey there MrPratt! Im a young web developer from Portugal, and i just want to say:
Mini vmac really changed my mind about computers: experiencing the reality of old 68k days... thats awesome.
But i have a question: why is this page so ugly? Sure, it is a experiment, but i think it would be a really good challenge for me to tweak a little bit the Gryphel Project's website, don't you think?
Im looking forward for your response(and, with luck, your aproval!).
Live long and prosper,
Tomas [ ... last name ... ]
Thank you for your offer.
However, a major redesign of the website would inevitably require a lot of my time, which unfortunately isn't available right now. Even if I just accepted a new website that you hand me, to maintain it and add new content would still require learning about modern web technologies, which would take time.
The current design of the website is intended to work on very old web browsers that will run on a Mac Plus. Which is a logical constraint for the Gryphel Project. But it is also just an excuse to avoid spending time chasing current web fashions. Myself, I'm a fan of this school of web design (warning: vulgar), and disregard the bit about it being satire. I'll admit though that for the good of the Gryphel Project, I should consider what is most effective for the intended audience, not just my taste.
By the way, using the original HTML technology, these pages basically just contain the text and a few hints. What it looks like is up to your web browser. Perhaps you could try a different web browser. Or see what preferences there are in the browser you do use, especially default font preferences.
Sent: Sun Feb 8 18:38:07 2015
i`m looking for an old mac plus software like "Mac Flow" ...
Do you have any idea ?
BEcause i have some old files and can`t open it with newer apple software.
Christian from Germany
[... email address ...]
I provide links to some Macintosh Plus software. The “other” section has a link to the MacFlow 5.0 Demo. The Mainstay website is still up and seems to still be offering to sell MacFlow. (Though the copyright date on the pages is 2010.)
Sent: Sun Jan 25 17:45:58 2015
Hi, I sent the bug report about the disks not mounting.
I'm running Mini vMac 32 bit on a Windows 7 Professional 64 bit system. All the Mini vMac version 3.3.3 variations are having this problem. Older versions of Mini vMac are not having this problem. Example version 3.2.3 mounts all six disks just fine.
While experimenting I've discovered something new. Originally I was trying to auto mount disk1.dsk and disk2.dsk and only disk1.dsk was showing up in the finder. I extended that to disk3.dsk and it would not show up in the finder either. So, I tried to mount all six disks. disk1.dsk, disk4.dks, disk5.dsk, and disk6.dsk all auto mount and show up in the finder disk2.dsk and disk3.dsk do not show up in the finder but if I try to manually mount them it says they are in use. Also this does not happen if I try Mini vMac version 3.2.3. It mounts all six disks just fine.
I've also tried booting different Mac OS versions 6.0.8, 6.0.5, 7.5.3 etc... they all have the same problem on version 3.3.3 but not on 3.2.3 too.
This is not just happening with the Mini vMac versions from the Variations Service but I also compiled and built my own versions using lcc-win32. They all have the same problem too.
My email is [... email address ...]
Thanks for the further information.
I'm not seeing this in 64-bit Windows 7 Home Premium N running in VMWare. I'll try this on a real machine later. Also I should try applying all available Windows updates in the virtual machine, it's been some years since I set up that VM.
Since you can build from source, you might try changing MinTicksBetweenInsert in the file SONYEMDV.c, and see if that changes the number of images that are not properly mounted.
Also, if instead of naming disk images "disk1.dsk", "disk2.dsk", etc., you specified images to mount on the command line, do you get the same behavior?
Sent: Sat Jan 24 17:08:07 2015
I'm having a problem with the latest builds from the Variations Service. They won't automatically mount more than one disk on startup. disk1.dsk mounts fine and the emulated computer boots up but disk2.dsk, disk3.dsk, etc... don't automatically mount. If I try to open disk2.dsk manually it says the disk is already in use and it won't let me mount it. It's as if it is partially mounting disk2.dsk but it is not showing up in the finder.
It tried building my own variations but they all have the same problem. Is this a bug in the software?
Thanks for the bug report.
I'm not seeing this behavior. What specific variation number(s) have you tried? What operating system are you running it on?
What software is in "disk1.dsk"? Does a fresh install of System Software have the same problem? (Perhaps some 3rd party software could temporarily put a Macintosh into a state where it doesn't accept disk insertions.)
I assume if you rename disk2.dsk to something else, and then launch Mini vMac, it works to manually mount it after booting?
Sent: Thu Jan 22 15:56:49 2015
I am currently using mini vmac II on my android rca pro 10 tablet. I would like a version custom built to work on my tablet. I have os 7.5.3 running on it now at 640x480 res. It only has 8,192k Total memory which is too small for my Hypercard apps. My tablet has a quad-core processor and it is android 4.2.2 jelly bean. Can you make me a custom mini vmac with a larger screen and larger Total memory to fit my tablet? I have many roms and os's 1.0 to 9.2.2. I would like to run an os as high as it will run and be stable and dependable. If you can do this for me, I would be very greatful, please let me know. [... email address ...] Thanks, Dale
Sorry, I'm not involved in the Android port of Mini vMac. I don't how to compile a program for Android. Within a year or so I may learn more about it, for my paid work.
Also the incomplete Macintosh II emulation of Mini vMac does not support more than 8M of memory. The Macintosh II ROM is not 32 bit clean, so even a real Mac II will not normally support more than 8M of memory. There is some additional software available that allows more memory, which presumably replaces ROM routines, but it doesn't work in Mini vMac for reasons not yet known.
Sent: Mon Jan 19 21:09:39 2015
[quote]Still, for Mini vMac to be practical, the host should generally be about 50 times faster than a Mac Plus. (Modern computers are thousands of times faster.) I don't know if a 68060 based Atari qualifies. It might be fun to play with anyway.[/quote]
Taking the fairly unscientific measurement, I'm assuming the Mac Classic is powered by an 8MHz 68000 at around 1.4 MIPS. I guess that fancy Amiga-like custom chips and graphical accelerators don't enter into things too much. I've also completely left things like FastRAM out of the picture as well.
A standard unmodded Atari Falcon with a 16MHz 68030 has 5.76 MIPS, so an uninspiring factor of four CPU power over a Mac Classic.
My other accelerated Falcy, with a 50 MHz 68030 can whip up a storm of 18 MIPS, which translates to 12-13 times the original - Slow, but just about useable.
However, the CT60 in its bare minimum configuration can throw in 96.8 MIPS, which is more than adequate.
Some crazy people overclock this further, so a value of 147 MIPS at 100 MHz is not impossible (with a revision 6 '060!)
So it looks like we're good to go with the 060 :-)
(previous message in thread)
Sent: Sun Jan 18 17:28:51 2015
This error happens on VMac 2 (ll) and it says that The program had no files. I put the files there but keep annoying me saying that I do not any files.
What is the exact wording of the error message? Does it include “I can not find the ROM image file MacII.ROM”? If so, see the FAQ section about ROM images. Also, see the page about “How to get started with Mini vMac”.
Sent: Fri Jan 16 22:42:24 2015
MinvMac ported to Atari Falcon.
This might be of interest to you. The MinivMac emulator has been recently ported to the Atari ST family, specifically the Atari Falcon.
The interesting stuff starts halfway down the thread. It is an SDL port, so not massively optimised. I think it was compiled and found to run decently on a 68040 environment. The target hardware is really Atari Falcon with a 68060 accelerator card. The starting hardware probably something like a fast 68030. (It runs under another emulated environment, Hatari, but slowly with a lesser processor spec.)
The working proof screengrab is by me, from an emulated Atari clone, 'Aranym' (Mac version naturally!) Which would be on an 040 base. So an emulation nesting within another emulation.
The next interesting link is for a demo purported to run on Mac Classic.
There is a downloadable file, with a PC executable, and data files to transfer to a Mac Classic. It is not set up as a .dsk image at this point.
If you want to say hi, my email is [... email address ...]
Interesting. This seems to related to the same port described in the previous feedback.
Posts in the forum you link express concern about speed. The C version of the 68000 emulation in Mini vMac is more concerned about simplicity and maintainability. The 2 existing assembly language versions (for x86-32 and PowerPC) tend to be about twice as fast. A 680x0 assembly version of emulating a 68000 could probably do even better, because it can directly use the 68000 instructions for math, after setting the status register and then saving it again.
Still, for Mini vMac to be practical, the host should generally be about 50 times faster than a Mac Plus. (Modern computers are thousands of times faster.) I don't know if a 68060 based Atari qualifies. It might be fun to play with anyway.
Sent: Thu Jan 8 21:54:43 2015
Just a word to said I have port mini vMac for Atari Mint 68K computer, it was very easy to compil. I use this options to extract source code:
-t slrs -api sdl -no-asm
and modified makefile I just need add the library gem with -lgem link option.
I will look if I can do better port with specific interface for mini Vmac under GEM but like it work fine.
Thanks a lot for this very good application
[... email address ...]
Thanks, that is interesting. I could add this as a target to the Mini vMac build system.
Instead of “-no-asm” would the new -cpu 68k option in the development version work?
If I wanted to try this, is there any emulator you recommend? And software to run on it? Perhaps Hatari running FreeMiNT?
Starting with the SDL port, you could make a more native port by combining the source code for Mini vMac and SDL, removing everything that isn't needed, and then cleaning up the result. I did this for the OS X Cocoa port. It takes a while, but is straightforward.
Sent: Thu Jan 8 04:13:15 2015
Some nice work here. Many years ago we used a program called McCad to create PCB files of boards that we built. We used a Macintosh II with the two disk drives. It was running system 6.0.7. We are now trying to resurrect those old files and modify them. McCad can't help us. What we have is an old SCSI drive which is bootable and has system 6.0.7 on it and the software. We are looking an emulator that might support this drive or through some method transfer the system and software to the emulator. I picked up on your comments about maybe working to create a Macintosh II emulator. Any suggestions would be appreciated. Best Regards, Dennis Wilson email [... email address ...]
Some other Macintosh emulators that I know of are listed on the Mini vMac Alternatives page.
How to transfer the files to a modern machine, depends a lot on what hardware you have available. People on one of the related forums may be able to help.
If you still have a working Macintosh II, or other old Macintosh, the Macintosh Floppy Emu could be useful.
Also, I have a list of Old Macintosh Disk Conversion Services. I made the list with floppy disks in mind, but some of those companies may also be able to handle a SCSI drive.
Sent: Sun Jan 4 16:20:42 2015
hmmm... It works on your setup eh? Anyway I use Windows laptop with Win 8.1, JIS keyboard, with Japanese Keyboard checked in on language selection (with English display, but that shouldn' matter). I tested both Mac systems KanjiTalk 6.0.7 and KT7.5.3, with the former patched with JIS resources (Roman-JIS and such) copied from the latter using ResEdit.
English inputs are perfectly matched with my kbd with my submitted ikb patch, and on US systems 6&7.5 as well.
Except KT7.5.3 seems to have a Kotoeri bug with JIS kbd; the key layout remains US layout no matter what I do in the Control panel or Kotoeri setting...i gave up.
KT6.0.7 works well with both roman and kanji inputs. (In both systems KANA input doesn' work; they both have different key/font assignments.) Anyway thanks for checking out my code. And BIG BIG thanks for minivmac!!
Since you’re using actual Windows hardware with an actual Japanese keyboard, your report should count for more than my use of VMWare. The problem is that if I use your patch, besides not working for me, it might not work for other people too. It would be much better to know how Mini vMac can distinguish between your set up and mine.
Sent: Sat Jan 3 09:23:29 2015
OK here's a better one so that you can separate myvkmapa and assignonemackey:
case 0x00000411: /* Japanese */ /* MyVkMapA[??] = ??; */ /* JIS keyboard */ MyVkMapA[myVK_Equal] = myVK_SemiColon; MyVkMapA[myVK_SemiColon] = myVK_SingleQuote; MyVkMapA[myVK_SingleQuote] = myVK_Equal; MyVkMapA[myVK_Grave] = myVK_LeftBracket; MyVkMapA[myVK_LeftBracket] = myVK_RightBracket; MyVkMapA[myVK_RightBracket] = myVK_BackSlash; MyVkMapA[myVK_BackSlash] = VK_CONVERT; MyVkMapA[VK_CONVERT] = myVK_Grave; MyVkMapA[myVK_OEM_102] = VK_FINAL; AssignOneMacKey(VK_CONVERT, VK_APPS); // AssignOneMacKey(myVK_OEM_102, 0x5e); AssignOneMacKey(VK_FINAL, 0x5e); break;
Seemingly VK_FINAL isn't used on JIS keyboard so just take it for granted. VK_CONVERT is still a hack (no grave key on JIS kbd).
Thanks for the patch. Unfortunately the Japanese layout is one that I had already tested and found did not change the Virtual-Key Codes, compared to the US layout. So that suggests that looking at the result of GetKeyboardLayoutName is not sufficient to unscramble Virtual-Key Codes.
What version of Windows are you using? What kind of keyboard? I'm not sure what other details might help to distinguish from my set up. (I just retested with Windows 8 set to use the Japanese Language and Microsoft IME, running on VMWare Fusion 6, on a MacBook Air with an Apple USB Wired Compact Keyboard.)
Sent: Fri Jan 2 13:13:08 2015
Is there any way to have a magnification factor between 1x and 2x?
No, this is not supported. On some platforms it would not be that hard to modify the source code for other scale factors. Other platforms don't provide routines for scaled drawing, so you'd have to implement your own.
In any case, non integer scale factors would unavoidably look very bad. Particularly for the gray pattern commonly used on the early Macintosh.
Sent: Thu Jan 1 13:12:57 2015
my ikb contrib :)
case 0x00000411: /* Japanese */ /* MyVkMapA[??] = ??; */ /* JIS keyboard */ MyVkMapA[myVK_Equal] = myVK_SemiColon; MyVkMapA[myVK_SemiColon] = myVK_SingleQuote; MyVkMapA[myVK_SingleQuote] = myVK_Equal; MyVkMapA[VK_CONVERT] = myVK_Grave; MyVkMapA[myVK_Grave] = myVK_LeftBracket; MyVkMapA[myVK_LeftBracket] = myVK_RightBracket; MyVkMapA[myVK_RightBracket] = myVK_BackSlash; MyVkMapA[myVK_BackSlash] = VK_CONVERT; AssignOneMacKey(VK_CONVERT, VK_APPS); /* hack */ AssignOneMacKey(myVK_OEM_102, 0x5e); break;
The hack before the last line is necessary as JIS keyborad doesn't have a Grave key.
(follow up message)
Sent: Wed Dec 31 08:31:08 2014
[...] I still have my original Mac 128, and being in-the-money for a while at the time, bought an Australian produced RAM upgrade board for it. The board was the same size as the motherboard and sat above it, connected to the mother-board with a tower of stiff wiring, all sitting on strong pillars/posts. It was covered with 16k chips, and all told gave me an extra 2 MEGA-bytes of RAM. [...]
[...] I used the RAM as an SSD in effect, then known as a RAM-disk, and allocated 1MB to the System files plus iData, WriteNow, Excel 1, Word 1 and Draw 1.9.5. They plus a selection of fonts and control panels then worked in the remaining 1MB of RAM, plus the original 128kb still there. [...]
[...] The 128 still powers on, (the RAM board no longer, but finding the dead chip should be easy) but nothing I have tried (I don't know much) will induce it to boot up. If that *could be done, perhaps there may be info available on how ‘they’ did it, to allow software 'RAM' to be increased in your fab app? [...]
I have previously found that a Mac Plus cannot be upgraded beyond 4MB of RAM just by patching the ROM and moving it elsewhere in the address space. The Macintosh System software, in particular the part that installs bug fixes for traps that otherwise would be implemented ROM, assumes and depends on the exact address of the ROM.
But I hadn't considered whether the original Mac ROM could be upgraded beyond 512K RAM. Your report proves that it is possible. It might just be a matter of patching the part of the ROM that detects the amount of RAM. If that doesn't work, then it might be interesting to run CopyRoms on your machine.
By the way, I worked on early version of FDisasm with the development tools on a RAM disk, on a Mac 512K.
Sent: Sat Dec 20 06:55:21 2014
Hi Paul, I've got hundreds of floppy disk images I made years ago, as .img files. I try to pull them into vMac and it says that the floppies aren't formatted properly. Any idea how to get them working correctly? I can mount them just fine in SheepShaver
One way which would certainly work is to, in SheepShaver, copy the contents of your disk images to new blank disk images that are known to work in Mini vMac (see Blanks).
Otherwise, it would depend on what the problem is with your images. If they somehow ended up formatted as HFS+ rather than HFS, that will not work in Mini vMac, which only runs System 7.5.5 and earlier.
If it is the disk image format that is the problem, perhaps the Covert command, in the Images menu of Disk Utility of OS X might be useful, to convert to a 'read/write' image without encryption. This might not be much faster than copying the contents in SheepShaver. (It would be possible to automate this with hdiutil on the command line.)
What version of what software did you use to make the '.img' files? And what settings did you use?
Sent: Wed Dec 10 21:32:13 2014
I downloaded the vmac.rom file but now the app just shows floppy disks with a question mark! What to do?
See the Getting Started with Mini vMac instructions.
Oops, Apple's older software page has finally disappeared. I have updated the Getting Started page to use direct links to the System 6.0.8 software, which still work.
Sent: Mon Dec 8 22:32:04 2014
hey man ... using importFI ... is a really cool app man!
just one thing though... any vintage mac with an ASC Apple Sound Chip, has the ability to play AIFF Files, with a program call SFplay... 22khz, 8bit, mono witch from mp3's don't sound that bad. anyways, Using importFI to get AIFF's onto a image, for some reason it breaks the aiff file. if zip it, then import, then unzip all is fine. Ira nor big deal really, but i was thinking it would be nice to import aiff's with out all the steps... anyways keep up the good work.
How is the AIFF broken? As mentioned in the ImportFl page, it only imports the data fork of a file, and a work around is to use the “Compress” command of OS X to make an archive to import, which I guess is what you are doing.
If the only problem for your AIFF files is in losing the Macintosh file type, then you could use software such as Finder Info or Creator Changer to fix it, which might save a few steps.
Sent: Sun Nov 30 12:12:46 2014
Are there instructions for compiling the SDL port of Mini vMac for DOS please?
No, sorry, I don't know anything about DOS.
I'd suggest first following instructions on the “Building Mini vMac” page to learn how to build Mini vMac for one of the supported platforms. Then use the “-api sdl” option to build Mini vMac using SDL on a platform where it is known to work, like Linux or OS X. Then compile on DOS some other program entirely that uses SDL and supports DOS. (Perhaps just one of the example programs for SDL.) Then you might know everything you need to compile Mini vMac on DOS using SDL. If you get it to work, please let me know how you did it.
Sent: Sat Nov 29 10:55:57 2014
Any chance of a DOS port of Mini vMac please?
The SDL port of Mini vMac could probably be compiled for DOS.
Sent: Sun Nov 16 16:39:42 2014
Could I add an item to your Mini vMac .zip folder.
What? Please elaborate.
Sent: Thu Nov 13 18:10:15 2014
I've made some patches to the FPU code you may or may not want to include. I can't take credit for any of the code -- it was all adapted from recent WinUAE source (a lot of work in the FPU code there is apparently being driven by the NeXT emaulator, previous). Changes include:
* Support for packed decimal real -- Claris Resolve now launches correctly in Mac II emulation.
* Fix for "unnormalized" numbers that was causing the emulator to hang in MacDraft 4.0 on an FDIV (number with nonzero exponent+ zero mantissa was being passed in to estimateDiv128To64).
* Changed myfp_REM to use iee754_remainder, and try to save quotient byte. My change fixes an issue where DYOH Architecture was generating nonsensical dimension measurements in Mac II emulation, though I'm not sure the code is 100% correct.
If you're interested let me know how to get the changes to you.
(BTW - I can build and debug in XCode 6.1 just fine by changing the architecture to "32-bit intel (i386)" )
-Jason R. Kersten
[... email address ...]
Sure, I'd like to merge in your changes. I'll send you an email that you can reply to with your version of the source attached.
Sent: Mon Nov 3 15:20:54 2014
I'm using Xubuntu 14.04, and I've been experiencing the "smudged" appearance when using Mini vMac. It had worked flawlessly on an older version of Linux. Would be nice if there were some kind of workaround.
Yes. This sounds similar to a previous report.
Sent: Sat Oct 25 23:20:59 2014
I wrote to you last year I think, about graphical glitches under Linux - kind of a 'smudged' appearance when the screen redraws. This was under X11/Gnome and intel HD3000.
The problem still persists, but of interest, doesn't occur under the new Wayland display server (a replcement for X11 currently in development and expected to roll out in the next year or so).
It's nice that this bug may be getting fixed. (Whether it is in X11, or drivers, or limited to certain Linux distributions. It definitely doesn't show up in all Linux installations.) As I said before, a work around might be for Mini vMac to use a different drawing method, but that could potentially be much less efficient on some systems.
Sent: Mon Oct 20 02:12:25 2014
[...] I wish i could hack a vMac Plus to have color [...]
It turned out to be fairly simple to hack the Macintosh Plus ROM to support a larger emulated screen. But supporting color that can be used by existing old Macintosh programs requires Color QuickDraw, which is found in the ROM of the Macintosh II and other color Macintosh computers. And if you require the ROM from a Macintosh II, then you might as well emulate a Macintosh II.
Sent: Sat Oct 11 03:44:16 2014
how to use mini vMac II,
on my android 4.1 phone
I wouldn't know, I don't have much to do with the Android port of Mini vMac.
You might first try getting started with Mini vMac for OS X, Windows, or Linux. Then using the Android version might become clearer.
Sent: Fri Oct 3 13:54:06 2014
Just curious, would it be possible to make Mini vMac into a kernel for the Raspberry Pi? I am working on a Macintosh Pi, and I can run Mini vMac within Raspbian, but I think it would be faster to directly run the code rather than run it through Raspbian, kind of like what Scott Hutter did with his Commodore Pi project.
Anything's possible if someone spends enough time on it. Not me, certainly.
Rather than making a version of Mini vMac that runs directly on the hardware, a somewhat more feasible path would be to create a stripped down operating system for running a single program, which a standard Mini vMac could then be run on. Perhaps a version of Mini vMac compiled to run on SDL. The SDL API rather than XLib API may be more appropriate for this purpose. You could start with the source code for the Raspbian linux kernel, SDL, etc., and then start stripping out anything not needed. Since this stripped down OS would run a program that can also be run and compiled on the standard Raspbian, that would avoid an enormous amount of work in maintaining a compiler and other development tools.
This could be a fun project, but I doubt the result would run Mini vMac any faster. That is, even if you did find a way to make it run Mini vMac faster, that change could probably be made in the full Raspbian.
One way Mini vMac could be made to run faster on the Raspberry Pi is to make an ARM assembly language version of the 68000 emulation. (There are currently assembly language versions for PowerPC and x86-32.)
Update: Though it probably wouldn't help with speed, an operating system optimized to run a single program may help in other ways. Not sharing time with other processes may allow smoother emulation. There might also be opportunity to reduce latency, that is, time between keypress or mouse click, and the result showing up on the screen.
An operating system to run a single program could be useful for other emulators and games, and so attract more people to help than making a version of Mini vMac. (But not me, though it is an interesting idea.)
Sent: Sat Sep 27 22:52:41 2014
Mini vMac is not displaying properly on my Arch Linux x64. When I move the mouse on the screen the display will be "contaminated". And when I press the control key the display will "clean up" and become normal.
Xorg version 1.16.1
This sounds similar to a previous report.
(Due to travel, and hosting problems at the same time, this message was lost for a while. Sorry.)
Sent: Tue Sep 23 02:41:33 2014
How can you expand .sit files with mini vmac stuffit 4.1 On mini vmac. The application doesn't see the files. Basilisk Opens them up right away but they don't work on system 7.
I expect the Macintosh file type isn't set. See my page about Stuffit Expander.
Sent: Tue Sep 23 00:26:57 2014
unable to locate ROM image
See the Getting Started with Mini vMac instructions.
Sent: Sun Sep 7 15:25:29 2014
Hi - I'm just messaging you to confirm that minivmac can be compiled for FreeBSD/powerpc - at present you only support linux-ppc and freebsd-x86 and freebsd-amd64 ...
using the endianness stuff from the lppc CNFGGLOB and updating directories from /usr/X11R6/(include,lib) to /usr/local/(include,lib) were sufficient to get minivmac to compile with not-too-much trauma.
I must ask, though - isn't it a little odd to need to use minivmac or a mac to bootstrap the minivmac build? Couldn't it be made to function with a more traditional configure script based solution?
Thanks, I'll add FreeBSD/powerpc to the build system.
About the build system - See the topic in the FAQ - “What format is the Mini vMac source code in, and why don't you use something more standard?”. Sure, I could make the source into a format easier to use in FreeBSD, but then it would be harder to use on some other platforms supported by Mini vMac. Platforms come and go, the only platform guaranteed to exist for as long as Mini vMac does is Macintosh 680x0.
Another thought is that if Mini vMac used a standard unix configure script, and for whatever reason it didn't quite run on your machine, it would be nearly impossible to debug the configure script, that thing is massive and messy. But when the Mini vMac build system generates something that doesn't quite work on your machine, it is relatively easy to fix, as you did.
Sent: Mon Sep 1 01:26:20 2014
Just set up Mini vMac on a Raspberry Pi. Works brilliantly. Installed Word 5.1a with no problems at all - this seems impossible on Basilisk II but went without a hitch on Mini vMac. Great fun. The next best thing to time travel! Thank you very much. The only problem is that I didn't own a Mac Plus - any chance of emulating a Mac LC, my very first Mac?
I'm glad Mini vMac works well for you. In theory there is some chance of eventually emulating the Mac LC - see the topic in the FAQ - “Emulation of a Mac LC475 or Quadra650 or IIci or ...?”. But for present reality, see this earlier question.
The MESS emulator may be making progress at Mac LC emulation, see the Mini vMac Alternatives page.
Sent: Sun Aug 31 07:56:57 2014
I would like to translate the gui to hungarian, please drop the details.
Regards, Viktor varga
[... email address ...]
Thank you for the offer. The Mini vMac Localization page (which you may have already seen) has a few details, and links to the text of 7 existing translations. You can send corresponding text for a hungarian translation, either posting it to the feedback page, or email it to me.
I'll add your translation to the Localization page, and make a new 3.4.0 development version that you could test.
Sent: Fri Aug 22 12:37:58 2014
Thanks for sharing your project code. I'm learning vintage Macintosh programming. Thus, I'm reading your CopyROM program. I want to know why some files with post fix *.i. It looks like C code. But there are some Macro such as LOCALPROC and etc.
Are there any reason do it in this way? I tried to compile them MPW 3.1. But it exclude them from Make.
For most of the Mini vMac extras (but not Mini vMac itself), I'm not following the normal C convention of a program consisting of a bunch of separately compiled files held together by a Make file. Instead, there is a single file to compile, "app.c", that includes ".i" files holding code. This makes it easy to compile with a variety of Macintosh development environments, which may not even use Make files. For simple programs, with Mini vMac set to All Out speed, speed of compiling is not an problem (the main original motiviation for separate compilation).
See the Compiling Macintosh 680x0 Applications for (incomplete) documentation on how to compile the Mini vMac extras.
“LOCALPROC” is defined in “COREDEFS.i”. It is just a convention I adopted long ago when first moving from Pascal to C.
Sent: Wed Aug 20 21:20:35 2014
Hi Paul, I love Mini vMac and am reconstructing what is beginning resemble my favourite computer, the PowerBook 100. I'm getting close with one of your "custom builds" (wider screen, full screen, magnify, speed 2x) on my MBAir.
Thank you for Mini vMac.
I currently need to set the caret blink speed in the control panel each time I start Mini vMac as the PRAM isn't saved. Could you perhaps offer the saving of PRAM as a switch on your custom build page? That would be awesome!
Have a great day and
I'd rather have build system options to change the initial PRAM settings. (See the topic in the FAQ - “Save PRAM?”.)
Sent: Tue Aug 19 13:51:36 2014
Your generated make file for Linux is well written. I don't need to modify anything to make it compile in my odroid U2 arm board. But note that it is not cross compile form my x86 64 box.
BTW, what kind of tool you used to generate different build file for XCODE, Linux and etc? That's one of unique build process I have ever seen.
The build system is just a program for Macintosh writtten in C. The source code for the build system is included in the Mini vMac source archvie.
Sent: Mon Aug 18 14:48:30 2014
Sorry, I didn't read through your whole page. No wonder I don't need to enter my email address to receive your reply.
In any case, I have trouble to run mini vMac ARM version in my odroid U2 board which uses hard float X11 library for performance purpose.
I figured out how to compile mini vMac on my board. It loads correct version now. Please let me know if you want a binary copy of compiled binary.
Ricky@odroid:~/Downloads/minivmac-3.3.3-lx64$ ldd minivmac
I'm glad you got it to compile. I would be interested to know if any changes were needed to the source code or make file which were generated by the Mini vMac build system.
Sent: Thu Aug 14 14:50:37 2014
does macweb work? i saw someone on youtube use a old mackintosh system (i don't know if its a SE) and they used mac web i don't know if you already have it or didn't add it yet.
Since it is not available from the copyright holder, MacWeb doesn't qualify to be linked to from my software list. It could qualify to be hosted there. I found a page about browsers for black & white Macs, and it sounds like it ought to work in Mini vMac's Mac Plus emulation, except of course that Mini vMac doesn't emulate internet access. A web browser could still be used to view local files.
Sent: Sun Aug 10 06:57:01 2014
Hello, Your vMac is really greate ! But, I try to compile a vMac with 1Mio RAM with Xcode 5.5.1 (I can't found now the antica version of 2.2.1), but I've an error when I compile : "Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang failed with exit code 1"
I haven't much cared for recent versions of XCode, and haven't paid attention to it lately, but yes, Mini vMac should support them. I'll look into it (but this may take a while).
Sent: Sun Aug 10 05:13:18 2014
i got gryphel GUI on my computer,
is it a PC emulator?
can i get games/Apps for it?
let me know
I guess you are referring to the Gryphel Graphical User Interface Implementation Illustration, which predates using the Gryphel name and website entirely for Mini vMac related stuff. It is unrelated, has nothing to do with emulation, and has been moved to different domain (“.net” instead of “.com”). Below the latest news on that page is a brief description of what it is about.
Sent: Sun Aug 10 05:00:58 2014
I have an idea,
an app that compile a mini vMac, within the mini vMac,
and have the ready to use app, show up on the desktop of the host computer.
the app is operated with survey style interface,
rather than command line.
will you make it?
i photoshop that idea and fed it to the site below
it make it so much easier to compile the mini vMac
Hi again. We've discussed something similar before. Sorry, it is not feasible. (Cross compilers are not trivial, and then there are other needed tools and API files.)
Sent: Sat Aug 9 19:03:30 2014
Adam Rosen from the Vintage Mac Museum here. I was just checking out your site, and appreciate the fact that you've listed my file conversion services on your list of vendors. If there's anything I can do to help with Gryphel or Mini vMac, please don't hesitate to ask!
You're welcome, and thank you for the offer.
Sent: Sat Aug 9 16:24:26 2014
Thanks for sharing this wonderful project. I donated $10 to support your on-going effort.
Is it possible to compile in ARMHF version? I have trouble to figure it out how to cross compile in ARM.
Thank you for your donation!
I guess you missed the previous reply?
For earlier mail, see the mail index.