Andy,
Perhaps I'm missing something, but I've got whole-disk images (Zip 100 Drives) that contain three (3) ProDOS volumes that I can't figure out how to read in CiderPress II.
The images generally are created with 'dd', but sometimes I use Disk Utility on a Modern Mac to image the whole device. (i.e.- the Zip 100 drive).
An examination in a hex editor shows the first 200 bytes contain '00', but after that you can clearly see 'APM' and the following info that's contained in the partition table before the actual volumes start.
Since I know you support multi-partition images, I'm puzzled.
Any ideas? Thanks.
> An examination in a hex editor shows the first 200 bytes contain '00'
That's probably the issue. APM volumes usually start with a Device Driver Record, and CP/CP2 stop looking if they don't find it. They don't really care about the contents -- the C.V.Tech floptical formatter left everything past the initial 'ER' zeroed out, so the contents are considered unreliable -- but the signature is expected.
(...should that be "$200 bytes" rather than "200 bytes"?)
Are the disk image contents something you can share? I should be able to handle it as a special case. As an alternative, set the first two bytes in the image to 0x45 0x52 and see if that allows it to be recognized.
Andy, man you're quick.
Yes, that should be $200 bytes.
Let me try the 0x45 / 0x52 and then I'll get back.
There's nothing top secret on my disk images -- just all the stuff I do for work, and since I work for myself, no one will care if I share it. Plus, I trust you, but I'd probably just give you a link to the image on my website. I doubt you'd want an email with a 100 meg attachment. 😄
OK. I was mistaken.
The first two bytes ARE 0x45 / 0x52. I've attached a screenshot showing that.
The next screenshot begins at $200. It has some verbiage about Apple Partition Map.
BTW, I made that image back three years ago. I can make a current image when I'm back at work tomorrow with Apple's Disk Utility, if necessary.
Thanks for taking a look. It IS New Year's Day, after all.
<img width="413" height="132" alt="Image" src="https://github.com/user-attachments/assets/7c404736-5a57-4854-b5c2-3e8e508fb749" />
<img width="462" height="382" alt="Image" src="https://github.com/user-attachments/assets/7875ce31-a1e7-4c16-b2de-b0f2a76ce1dd" />
The stuff in the hex dumps looks valid. CP2 might be aggressively rejecting it if partitions that come later look bad. The original CiderPress might be more lenient there.
It would help to get access to the image, but I shouldn't actually need anything past the partition map to diagnose the problem. There are 6 blocks in the PM, plus the DDR in block 0, so if you can slice off the first 4KB or so, that should cover it. Having the full image would be valuable for confirming that it actually recognizes the ProDOS partitions.
FWIW, I'm very quick when I happen to be looking at gmail when the bug report arrives. :-)
Andy,
I've attached the first 4K of that multi-partition image that uses APM.
BTW, I use the actual Zip 100 disk from which this image was made on my RamFASTs.
[zip100-4k.dmp](https://github.com/user-attachments/files/24403809/zip100-4k.dmp)
Attached is the Debug Log Screenshot, and also the 7-Zip Screenshot.
When I attempt to open, I receive "Error: unable to recognize contents of 'myimage.raw': file contents do not match file extension (ext='raw')"
Changing the file extension to something else does not seem to help, either.
<img width="972" height="211" alt="Image" src="https://github.com/user-attachments/assets/e9ed77e7-038a-4756-85d5-32c22ba929ae" />
<img width="747" height="212" alt="Image" src="https://github.com/user-attachments/assets/63bb9475-5e9b-4d99-906e-e57aa8e777e2" />
".raw" should work for this type of data.
What's the length of the file, in bytes? Specifically, is it a multiple of 512 bytes? The code that tests to see if a disk image is just a series of blocks or sectors will reject it if the the length is off.
Are you able to open the "zip100-4k.dmp" file you attached earlier?
Doggoneit Andy! You're one sharp guy.
I took my whole-copy Zip Disk image, opened it in my hex editor, padded the end of the file to make it a multiple of 512, and presto, CiderPress 2 opened it perfectly!
I think the image was a few bytes short.
Good work, again. Thanks.
And yes, the "zip100-4k.dmp" file I attached earlier opened just fine in your CiderPress 2 (or is that II).
I just need to determine why Apple's Disk Utility is making its image a little too short. (Unless I just want to manually edit them).
Hooray!
Either you're losing something off the end, or it's adding a few bytes. Either is concerning. CP2 should complain a little if stuff is missing, e.g. if you open the zip100-4k.dmp and select the "APM partitions" item in the Archive Contents pane, you'll see:
```
W Length of partition ('Apple') reduced from 63 blocks to 7 blocks
E Start of partition ('Macintosh') at block=64 is past end of file (8 blocks)
E Start of partition ('untitled') at block=164 is past end of file (8 blocks)
E Start of partition ('untitled') at block=63652 is past end of file (8 blocks)
E Start of partition ('untitled') at block=127140 is past end of file (8 blocks)
E Start of partition ('Extra') at block=190628 is past end of file (8 blocks)
```
CP2 is generally tolerant of mismatches because some CD-ROMs were generated weirdly.