Reading a GCC UltraDrive driver formatted disk

[IPalindromeI]

I got a Mac SE with some very interesting contents on the disk, so I plugged a ZuluSCSI into it into initiator mode. Now I have a disk image. Great!

...except for the fact I can't get this image to mount at all. If I look at a hex dump of the disk, I see some stuff that implies it's using a GCC UltraDrive driver. That's curious, since it's the stock 20 MB disk. The end result is I can't seem to mount it, at least on an emulated Quadra 800 running 8.1. I've tried B2 and Mini vMac as well, but neither of them want to mount it, or claim it needs to be initialized.
I'm wondering what to do with this. Is there an emulator that'll emulate a compact with SCSI, and let me maybe try to boot it the way it expects? Alternatively, can I replace the driver somehow? Or some other way to get to the partition inside, be it mounting it or recovering it?

 

[NJRoadfan]

Some APM docs here: https://github.com/fadden/CiderPress2/blob/main/DiskArc/Multi/APM-notes.md

Looks like GCC's formatter filled out some of the APM header fields wrong. I'd give CiderPress or CiderPress II a shot. The good news is that it appears to be a APM formatted disk, and not something weird. On a Mac, maybe try Mt. Everything to force mount the device?

EDIT: OK, it got weirder going further down the image. This seems to be an old Mac Plus SCSI Partition Map with a APM header tacked on. See: https://github.com/fadden/CiderPress2/blob/main/DiskArc/Multi/MacTS-notes.md

The "TS" at the start of block 1 is the dead giveaway. If you strip off the first 512k of the image, it should mount on a Mac Plus and likely mini vMac.

EDIT 2: Looking at line 4104, I can see the "TS" and partition header again. Maybe that is the actual start of the data partition? I'd try trimming there and mounting that image as well. Whatever GCC did. its not a standard APM disk.

 

[IPalindromeI]

Mt. Everything hangs badly trying to mount it. It does seem to recognize the structure of it. Norton Disk Editor also seems to recognize that there's a partition there.

What did work is using CiderPress 2 (not the original) - it does recognize the weird encapsulation just fine. I was able to extract the HFS part out of it, and I can pass that to Mac emulators that work against the raw HFS partition like Mini vMac.

WRT Edit 2, I think you're looking at the machine code for the driver, which references those as constants. (I have a feeling it's 68k since there's Nu everywhere.)

 

[NJRoadfan]

Yeah, the drive is formatted using the earlier Mac Plus SCSI Partition Map. The 128k Mac Plus ROMs recognize it, and the SE ROM clearly does too. Wonder if/when that support was deprecated in later ROMs and OSes. What OS was on the drive?

 

[IPalindromeI]

6.0.5.

 

[NJRoadfan]

I suspect the legacy partition table format got cut in 8.0. Just a guess as that is when MFS was removed. This formatting can't be too common as APM showed up in 1987 in Inside Macintosh V.

 

[Arbee]

MAME of course emulates both the Plus and SE with SCSI as well, so this image should work there too.

 

[bigmessowires]

You could also search for the letters "BD" (0x4244) appearing on a 512-byte boundary near the beginning of the image. That's the beginning of the actual HFS partition and everything else is just noise. If you delete everything before "BD" then you'll have an HFS image that will work in Mini vMac, Basilisk II, etc. If you want to use it with ZuluSCSI then you can use Disk Jockey to make a new device image containing your HFS image.

EDIT: Sorry I goofed. Your HFS image will begin 1024 bytes before the "BD" marker. This location will have "LK" stored there if it's a bootable disk, otherwise it may be zero.