www.gryphel.com/c/mail/v9 - feedback

Gryphel Project Mail

Volume 9


To send mail to me, use the feedback form.

( - latest - )

permanent link

Sent: Wed Mar 20 17:17:57 2019

Hi Paul,

Thanks for your amazing work. I'm currently trying to get the exportPS functionality working to print images from an old MacCalligraphy program. I followed your instructions to select the Laser Writer, but I can an error about AppleTalk not being enabled, and from all I could find in your documentation you said that LocalTalk can only be enabled on Mac OS. I'm on Windows does this mean i'm not able to print out images? I could switch over to emulating on a mac if needed.

Many thanks,

Harry


Even though selecting LaserWriter in the Chooser tries to turn AppleTalk, the print to file feature of this driver will work without AppleTalk. So you can just ignore this warning. Choosing Cancel is fine, which leaves AppleTalk off. Choosing OK, which turns AppleTalk on, is also fine.

The standard Mini vMac variation without LocalTalk emulation still tries to correctly emulate the serial port, with no LocalTalk network attached, which is sufficient for turning on AppleTalk. (AppleTalk is the protocols that are used to talk over the LocalTalk network hardware.)

Thanks for pointing out this ommission in the documentation. I have added a paragraph to the printing FAQ.


permanent link

Sent: Thu Mar 14 15:59:30 2019

Hi

I made a donation to you for $12.

How do I get the Sponsor Code?

I want a custom buid

Thank you

[... name ...]


Thank you for your donation!

I did try to send a Sponsor Code to the email address for that PayPal account at 11:59 AM (an address at earthlink.net). If you are not getting email sent to that address, please tell me another email address to use.


permanent link

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.


permanent link

Sent: Sun Mar 10 08:53:37 2019

Hi Paul,

Thank you for all your hark work on Mini vMac.

There appears to be a bug of sorts in the standard Macintosh II 36.04 variation available from the downloads section on your site, and it is consistent on both Mac OS Mojave and Windows 10 versions of the build.

There is a noticeable graphical "lag" in emulation; it's a bit hard to explain but you can see it just by moving the cursor around for a bit. It seems to slow down or skip frames. This manifests throughout emulation and becomes especially noticeable when trying to play games.

I never encountered this issue before in any previous versions, and it does not seem to be an issue in the standard Mac Plus variation. Just thought I would let you know.

Best regards,

Hampus


Thanks for the report. I have not been able to reproduce this yet. What operating system are you running on the emulated Macintosh? What are some games where you see this? What hardware are you using? Especially, what CPU? To be specific, do you see this in mnvm0026-36.04-mc64.bin.tgz, but not in mnvm0026-3.5.8-mc64.bin.tgz?


permanent link

Sent: Sun Mar 10 05:12:41 2019

I've compiled Mini vMac for a Raspberry Pi (Raspbian). It runs successfully and has sound. However, the sound will only come out of the 3.5mm headphone jack (analog output). If I switch the Raspbian output to HDMI, bluetooth audio, or usb audio, Mini vMac doesn't respect the change and will still play via the 3.5mm headphone jack. However, all other applications on Raspbian will reflect the audio output selected in Raspbian.

So for instance, I select usb audio as the output and start playing youtube in a browser and it plays via an attached usb speaker. I start Mini vMac and play sound and it comes out of the 3.5mm headphone jack.

Is there a compile option that I need to set to pick the output source for Mini vMac?

Thanks!


It sounds like Raspbian may not be supporting ALSA sound output too well. Mini vMac does have a run time option, “-alsadev <alsadev_name>”, for picking the audio device used, which might be of some help.

Mini vMac also has a compile time option, “-snd-api ddsp”, to use OSS instead of ALSA. But I don’t know if this would work any better.


permanent link

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.


permanent link

Sent: Mon Mar 4 19:17:12 2019

Hi,

I'm just starting to use this great emulator to play old Mac games.

I am facing one issue however : my Mac has a French Keyboard. Is there a way to switch the Mini vMac keyboard from US to French ? The control emulated control panel doesn't seem to have the needed resource.

Thanks

[... email address ...]


I would guess that to get the French keyboard in the emulated Macintosh, you would need French System Software.

For example, here are download links for French System 7.0.1: Disk_Tools, Fonts, Install_1, Install_2, Printing, and Tidbits.


permanent link

Sent: Tue Jul 17 22:13:38 2018

Hello Paul, I was quite excited to see Mini vMac and I'm hoping to get it working. I am the happy owner of a 128K, 512ke, Mac Plus, Mac II, Mac SE, PowerMac G5, far too many Mac minis to count, and a few iMacs, most of which are in storage. I have looked through the docs and don't see any answer so I'm wondering if you'd be able to help?

I have downloaded vMac, got a ROM file from [... url ...]. I also go the system software following the link at your site.

Upon launching vMac, I get a grey screen which I assume means the ROM file was accepted. However, I see no ? icon and loading the system image doesn't do anything - the screen just stays grey.

On various versions of ROM files, I get an error that the file is too short, or some such indication from vMac, but this one doesn't report any errors on loading.

Any ideas why I'm not seeing anything other than a grey screen and why loading the System Software doesn't have any result?

Thanks much.


If you are using one of the Standard Variations variations of Mini vMac, it will emulate a Macintosh Plus, so you should use one of the three versions of the Macintosh Plus ROM. My list of 680x0 Macintosh models gives MD5 checksums for these ROMs, that you can check to make sure you have a good ROM image. But Mini vMac does a simpler checksum when starting up, so if doesn't warn about a bad ROM image, this is unlikely to be the problem.

When following the Getting started with Mini vMac guide, make sure to follow the part about uncompressing the disk image, rather than trying to boot from the compressed “bin” file. But if this were the problem you should still have seen the blinking question mark before you dragged in the System image.

Getting to the point of drawing the gray screen, but not to the point of drawing the blinking question mark, is rather strange. Are you using one of the Standard Variations I provide? If you compiled it yourself, perhaps a bug in the compiler could have this result. Otherwise, which Standard Variation are you using, and what operating system version are you running it on? Also, what hardware, especially CPU version?


permanent link

Sent: Sat Mar 2 21:02:43 2019

Hi Paul,

Is Mini vMac still supported on OpenBSD?

This week, I built three variations of 36.04:

-t ob64 -var-fullscreen 0 -fullscreen 1 -drives 10 -cbt 8

-t ob64 -m II -hres 640 -vres 480 -var-fullscreen 0 -fullscreen 1 -drives 10 -em-cpu 2 -hcr 39321 -hcg 65535

-t ob64 -m II -hres 1024 -vres 768 -var-fullscreen 0 -fullscreen 1 -drives 10 -em-cpu 2 -hcr 39321 -hcg 65535

Applications are crashing, printing generates invalid PostScript, and the print dialogs refuse to recognize Adobe PSPrinter (a virtual printer installed in the Extensions folder).

For what it's worth, the Plus and II variations that I built for my OS9 Mac work exactly as expected, including the aforementioned PSPrinter.

If OpenBSD is still supported, I can spend some more time testing and write a better report, if that would be helpful.

Thanks for all your work on this project.

-Gail


Sorry, OpenBSD is not really supported at this time, because OpenBSD is not supported by the version of GCC that I use for all of my compiles, if I recall correctly. Or it might just be that I didn’t figure out how to get it to work.

I can’t really support other compilers, since there are so many of them, many of which can have bugs. You might try compiling with optimizations turned off, to see if the problem goes away.

I have a plan for getting back support for OpenBSD and other operating systems not supported by my current compile system, but this is likely to take quite a while.


permanent link

Sent: Thu Feb 21 02:05:21 2019

Paul,

I recently obtained an OLPC XO-1 (an i686 running fedora 18 at the moment), and I decided to try getting Mini vMac running on it.

The 32-bit linux binary was crashing, complaining about an X11 "BadMatch" error while attempting to execute XPutImage(). With some trial and error, I tracked the cause to a mismatch in color depth between x_display (16-bit) and my_image (24-bit) in OSGLUXWN.c. Recompiling with the "-ci 0" flag fixes the problem for me.

I'm a little out of my depth here (if you pardon the pun), but perhaps it would make sense to add a sanity check for this kind of problem at startup, and emit a more suggestive error message before X chokes?

Thanks for creating and maintaining this wonderful project!

-John


It would be nice to support a 16 bit x_display, but I would need to find some hardware to develop it on. I prefer not to write code that I can’t test, because writing almost working code can cause more difficult problems than simply not working at all. Even trying to write code to test for this situation and only give an error message would be risky without hardware to try it on.


permanent link

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.


permanent link

Sent: Thu Feb 14 16:24:20 2019

Hi Paul.

First, let me extend some thanks; I've been playing with Mini vMac and the various utilities you've been developing and maintaining for years.

You can see an enscripten'd version on [... url ...] (not sure if the patches still exist in source form)

and what was to be a "cloud-hosted", remote macintalk synth at [... url ...]

at some point, I also investigated using a webrtp switchboard server for remote localtalk - but I've to admit that I was quite confused by the bpf code, and had trouble finding an headless X server that'd work.

Anyways, for the feedback part. I tried running PlayerPro 4.4.2 (FAT) by Antoine Rosset - a neat sound tracker, and the following happens: hum. period, circa 0.033 sec / freq, circa 3 Hz.

Here's a screenshot of the captured loopback (normalized to -4dB): [... url ...]

If you'd like to repro, there's a copy of Player Pro in the Pres:Apps on the disk image therein.

[... url ...]

I'm really not sure what this is down to; maybe you have a clue ?

My email is [... email address ...]

- please don't publicly post the parts of the message containing URLs to my server :)

Have a nice day,

Arnaud


I happened to already have a copy of this program from a shareware site, but I hadn’t tried it before. It looks pretty nifty, playing the example provided. But otherwise making heads or tails of what the program does seems like it would take a while.

I notice that if the Driver Type is set to “ASC” in the preferences, then setting the Mode to “Mono” does not work. This could well be a bug in the emulation of the ASC, which maybe could be figured out when I have a couple weeks or so to look at it.

Is this the problem you are seeing, or do you have some other reproducible path to misbehavior?


permanent link

Sent: Thu Feb 14 07:37:11 2019

[previous message]

Hi Paul,

Yes, my MacII.ROM checksum is different -- 0x97221136. I didn't realize your disassembly would be specific to one ROM checksum, though that makes sense. Maybe fdisasm should warn if the checksum isn't what was expected?

The two occurrences of non-ASCII characters are appearing in P_Sony_RdData:

2E906  F1F5 F1F5      L6264:     Illegal
2E90A  F2F6 F2F6 F3F7            [... garbage ...].L (* + -$D090C07)
2E910  F3F7                      Illegal.L (* + -$D090C07)
2E982  6C00                      DC.W      $6C00           ; 'l '
2E984  F2E4 80C3 E248 L6271:     [... garbage ...].L (* + -$7F3C1DB6)
2E98A  55C6                      SCS.B     D6

Since that probably won't survive being submitted through this web form, the hex of the values on lines 2E90A and 2E984 is:

F6F2F600 00000F00 00000600 00000600 00000100 00000300 00000000 00000200
0001E400 212F3E00 21397400 213ACC00 356DF200 02F00800 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00002E4C 20282A20 2B202D24 44303930
43303729
E4F2E400 00000F00 00000400 00000400 00000100 00000300 00000000 00000200
0001E400 212F3E00 21397400 213ACC00 356DF200 02F00800 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00002E4C 20282A20 2B202D24 37463343
31444236 29

-Ryan


Thanks, I can now reproduce the issues. The garbage non-ASCII characters are due to a bug affecting disassembling floating point conditional long branches. I have a fix for this.

(Checksum 0x97221136 is actually a Mac IIx ROM, which works with Mac II emulation.)

update 2/18/2019 - A new verion of FDisasm has this fix.


permanent link

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.


permanent link

Sent: Tue Feb 12 06:57:36 2019

Hi Paul,

I was trying out fdisasm 1.2.6 on the Mac II ROM using fdmacii 0.2.2, and I noticed some output that doesn't look correct. For example resource MDEF 0 begins with the remark "; !! field doesn't fit" followed by assembly that doesn't make sense. In comparison, the MDEF 0 code disassembled from the Mac Plus ROM using fdplusv3 0.4.3 looks reasonable.

In the Mac II ROM disassembly, there are 134 occurrences of "; !! field doesn't fit" and also some occurrences of garbled (non-ASCII) output. The Mac Plus ROM disassembly has only one "; !! field doesn't fit" and no non-ASCII characters.

-Ryan


Thanks for the report. I have only been able to partially reproduce this. I get only 7 instances of “; !! field doesn't fit”. This turns out to happen in the most recent version of FDisasm if a label is in the middle of an instruction. In the Mac II ROM, some of these happen because there is a table in the ROM being indexed into after subtracting a constant. And currently, it looks, to FDisasm, like the start of table is shifted by that constant. My 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


permanent link

Sent: Sat Feb 2 05:02:26 2019

no ROM image

Is this project active?

I see an executable without need for gcc. When I run './'Mini vMac' an emulated screen appears but the message above is the content.

m190202_045635_010.bin.tgz

and

minivmac-36.04-lx64.bin.tgz

produced similar results.

[... name ...]


To get started with Mini vMac, see the Getting started with Mini vMac page.

For the latest project news, see the Latest news section of the website main page.


permanent link

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.


permanent link

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.


permanent link

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.

:
:
:


www.gryphel.com/c/mail/v9 - feedback
copyright (c) 2019 Paul C. Pratt