"Sad Mac" crash when starting A-Max 1.0/2.0 with cartridge emulation

[superfrog]

When I start A-Max version 1.0 or 2.0 in WinUAE using the emulated ROM cartridge, A-Max crashes with a "Sad Mac" screen and the error code 0F0002, immediately after loading the ROM and entering "Mac mode." I get the same result if I apply the "Fast A-Max" patch to either version, which copies the ROM from the cartridge to a file and patches the A-Max executable to load the ROM from the file.

A-Max version 2.5 works when loading the ROM from the cartridge, and also works with the Fast A-Max patch. A-Max versions 1.0 and 2.0 both work if I use a hacked copy where the Mac ROM has been integrated into the A-Max executable.

I compared the logs from the cartridge ROM versus the hacked disk ROM and did not see any noteworthy differences. I know the Mac ROM I am using for cartridge emulation is good, as it works with A-Max 2.5, works with Mini vMac, and its checksum matches its own internal checksum as well as the published checksum for this version of the Mac Plus ROM.

Attached here is my log output, and in the Zone are my config and hdf that contains the original cartridge ROM-based and the hacked disk ROM-based copies of A-Max 1.0, 2.0, and 2.5 in the A-Max drawer:

http://eab.abime.net/zone/WB%201.3%2...%20-%202.5.zip

Also included in this archive are my 128k Mac Plus ROM and an Extended ADF of a System 6.0.3 boot disk.

Prior reference was actually made to this problem several years ago by mark_k in an old thread here, but was never addressed or further discussed, to my knowledge:

http://eab.abime.net/showpost.php?p=996627&postcount=46

[mark_k]

Do you get the same sad Mac screen if you run the Fast A-Max-patched version when WinUAE is configured to not have an A-Max cartridge present?

I wonder if there is some incompatibility between WinUAE's cartridge emulation and real hardware. And there were at least two versions of the A-Max hardware.

[superfrog]

Yes, the sad Mac screen appears even without the emulated cartridge enabled. The Fast A-Max docs state that even with the ROM patch applied, A-Max still won't work without the cartridge, as it was not their intent to facilitate piracy with their program. Whether this is true or just a CYA statement I'm not sure. It is possible that the patched A-Max with disk-based ROM is failing in the same way as it would on real hardware without the cartridge plugged in. And if that is the case, then perhaps both the patched and unpatched copies of A-Max are failing in WinUAE with the emulated cartridge enabled for the same reason--there is some aspect of the cartridge's function that serves to prevent A-Max from running without the cartridge plugged in that goes beyond simply not being able to access the ROMs.

I am quite certain the issue is not the ROM image itself. I compared md5sums of the original ROM against the ROM images supplied with various cracked copies, and they are all identical once you strip off the short headers that some cracked versions attach to the beginning of their ROM files. And if I add the 4-byte header that Fast A-Max attaches to its extracted ROM to the ROM used by one of the working cracked copies, it still crashes when used with the Fast A-Max patched version. In like fashion, the ROM that fails with the Fast A-Max patch works with the cracked versions once the expected header is added.

My guess is there is something else besides the ROM that the un-cracked A-Max is checking the cartridge for in order for the emulated Mac to boot successfully. Given that A-Max 2.5 was intended to work with both the cartridge and the Zorro-II board versions of A-Max hardware, they may have chosen to remove any extra cartridge check from this version of the software. If that were true, it might help to explain why 1.0 and 2.0 fail with the emulated cartridge, while 2.5 works.

Do you know of anyone who has used the un-cracked versions that are commonly available with a real cartridge and still got the sad Mac crash?