Specification/docs/example code for A-Max .amhd drivers?

[mark_k]

Hi,

Does anyone know where I could get hold of specifications or documentation for writing A-Max .amhd drivers?

Versions of the A-Max Mac emulator from 2.0 to 2.56 used special ".amhd" drivers for accessing SCSI drives. This is necessary since the emulator takes over the system, so scsi.device, gvpscsi.device etc. can't be used. There were several different ones on the A-Max disk, and some SCSI controller manufacturers included a .amhd file on their install disks.

Having the specs would allow .amhd drivers to be written for the A600/1200 & A4000 IDE controller, A4000T SCSI and even WinUAE.

I'm planning to trace the schematic of the A-Max cartridge to allow it to be emulated in e.g. WinUAE. It wouldn't need to emulate a Mac floppy drive (though that would be possible), but would allow the original, unmodified A-Max to run. (A-Max reads the Mac ROM data from chips in the cartridge.) A-Max can use very early Mac system software, so is useful for historical interest in playing with old Mac software. Also, the Atari ST emulator "Chamaeleon" by Maxon may well use a very similar cartridge.

[Toni Wilen]

Emulating the cartridge should be quite easy by tracing the software, even without schematics (it was connected to parallel port, right?)

Special UAE driver is pointless, IDE/SCSI hardware emulation is already there (and I'd expect A-Max to have at least A590/A2091 driver), also there isn't any real interface to uaehf.device's "low level" part.

This is one of those pointless but interesting and fun things to emulate. I will add A-Max cartridge emulation sooner or later

[mark_k]

Originally Posted by Toni Wilen

Emulating the cartridge should be quite easy by tracing the software, even without schematics (it was connected to parallel port, right?)

No, the cartridge connects to the floppy port. There is a pass-through port for connecting an external Amiga floppy drive, and a 19-pin D connector for connecting a real Mac 800K drive.

It occupies one "unit"; if you have it connected directly to an A500 say, an Amiga floppy drive connected to it will appear as DF2: not DF1:.

Interestingly (or not) the ROM data as read from the cartridge (on the /RDY line) is scrambled; both address and data lines are mixed up. Maybe that was done to make it harder for people to write ROM-dumping programs? Or maybe just to make routing tracks on the PCB easier. (I've figured out how to descramble by looking at the A-Max code.)

To fully emulate the cart will require tracing the schematic. Sure, it would be possible to emulate it to the extent that A-Max works though. For example, there's no way to tell which ROM chip is selected without tracing the schematic. (A-Max doesn't care which ROM is in which socket since its code checks a certain byte in each ROM and reads "the other way round" if necessary.) Luckily there are only 4 standard 74-series TTL ICs plus one resistor and 5 diodes, so the hardware is quite simple.

Originally Posted by Toni Wilen

Special UAE driver is pointless, IDE/SCSI hardware emulation is already there (and I'd expect A-Max to have at least A590/A2091 driver), also there isn't any real interface to uaehf.device's "low level" part.

Well that's what a uaescsi.amhd would be for

I do think a WinUAE .amhd driver could be useful. It would work with >4GB drives (scsi.amhd might not) and you could possibly make it work better, e.g. supporting drives with more than 512 bytes per sector.

Originally Posted by Toni Wilen

This is one of those pointless but interesting and fun things to emulate. I will add A-Max cartridge emulation sooner or later

That would be cool. I don't agree with you that it's pointless though.

There's a good page with a lot of A-Max info including user manuals and DMS disk images at http://crossconnect.tripod.com/AMAXHOME.HTML

[Toni Wilen]

Originally Posted by mark_k

No, the cartridge connects to the floppy port.

Right, I forgot about that..

I do think a WinUAE .amhd driver could be useful. It would work with >4GB drives (scsi.amhd might not) and you could possibly make it work better, e.g. supporting drives with more than 512 bytes per sector.

SCSI already can do both (There is no SCSI 4G hardware limitation, 4G limitation is due to Amiga trackdisk-style devices taking offset and size in bytes, not in blocks like SCSI does)

I'd expect more problems with limits in upper level, like in Mac OS itself.