DumbDD

[gsteemso]

true. I didn't know about the other partitions but I agree completely with your assessment.

 

[Phipli]

true. I didn't know about the other partitions but I agree completely with your assessment.

I could be incorrectly crossing over two separate discussions, but that was what I was trying to work out. A bit of jiggery-pokery on a modern machine to pre-tweak the image and a raw disk write could be the solution to all this.

 

[saybur]

On that note, for my purposes, it would be great if I could run this in System 6, 7 or 8.1 at VERY latest. saybur, what’s the minimum OS your very alpha version will run?

Should run in 6.0.4(ish) and up but it's untested on anything other than 7.5.5

if I'm then running this on a PB1400 that boots from IDE (and has the .iso on a PCMCIA->CF card), then there's no chance it'll overwrite my boot volume?

Well it shouldn't but this is hot code so I'm not comfortable saying it definitely will not. It seems unlikely unless the OS maps IDE devices onto SCSI IDs or something like that.

Would be prudent to have anything important backed up just to be on the safe side, but obviously that advice applies to any system (not great about following it myself)

 

[Phipli]

Re-reading the other thread, the disk image should be already converted into a single multi partition disk. So that's good news

 

[Snial]

it sounds like his Whole Disc Image includes the partition table. That would cause any system that mounts the drive to ignore the unused space because it is not mapped, but should not cause any actual problems.

Correct!

The .iso will include an ISO <whateverthestandardnumberis> partition map, just as any other optical disc. If the PA-RISC system can boot from a CD it shouldn't have any trouble reading it.

That's the idea.

In the other thread Snial was talking about appending two other disks, so the data that would be ignored in that scenario would be two other disks, including their partition tables and data partitions. Unless the image he is writing has already been modified to have a valid partition table for all three partitions, or he is only writing the image from a single CD.

The whole installation is on 3 CDs. So, the first .iso would contain the normal .iso partition table and the PA-RISC system should boot from it and won't see the other CDs, but that's fine.

For the Debian installation, I understand that the first .iso is the core installation and the other(s) are additional packages. So, I think it should be possible to mount those on reboot based on the sector offset and then install the packages.

So, I was thinking this would be reasonable, because I did something similar when playing with a MAME-based SparcStation 1 emulator on my Mac mini 2012. I couldn't get the FD to work, but I could create a HD image with a missing partition; then mount that missing partition from within SunOS and dd to it. Then I could shutdown and from the host side, dd the data back out. It was very crude, but worked. In the future I plan to use the emulated ethernet to transfer data, now that I have a better grasp of how to link it up to virtual network interfaces on the Mac.

But thinking about it again, I might be wrong, or at least a bit wrong. I would need to mount the other .iso images as .iso's so that the target (the PA-RISC system) understands their partition maps too. Maybe that's reasonable: the other .iso s on the HD won't be on partitions on the HD, so it's not like it's partitions within partitions.

It does mean that DumbDD needs to be able to specify the target offset, which I hadn't considered earlier... though I could get around that too just by joining them all together. However, I might not do that as I might not want to write 2GB in one go, just 644MB at a time.

 

[Phipli]

Correct!

That's the idea.

The whole installation is on 3 CDs. So, the first .iso would contain the normal .iso partition table and the PA-RISC system should boot from it and won't see the other CDs, but that's fine.

For the Debian installation, I understand that the first .iso is the core installation and the other(s) are additional packages. So, I think it should be possible to mount those on reboot based on the sector offset and then install the packages.

So, I was thinking this would be reasonable, because I did something similar when playing with a MAME-based SparcStation 1 emulator on my Mac mini 2012. I couldn't get the FD to work, but I could create a HD image with a missing partition; then mount that missing partition from within SunOS and dd to it. Then I could shutdown and from the host side, dd the data back out. It was very crude, but worked. In the future I plan to use the emulated ethernet to transfer data, now that I have a better grasp of how to link it up to virtual network interfaces on the Mac.

But thinking about it again, I might be wrong, or at least a bit wrong. I would need to mount the other .iso images as .iso's so that the target (the PA-RISC system) understands their partition maps too. Maybe that's reasonable: the other .iso s on the HD won't be on partitions on the HD, so it's not like it's partitions within partitions.

It does mean that DumbDD needs to be able to specify the target offset, which I hadn't considered earlier... though I could get around that too just by joining them all together. However, I might not do that as I might not want to write 2GB in one go, just 644MB at a time.

Are you sure the merge script doesn't just extend the first image and move the package files onto it?

 

[saybur]

Are you sure the merge script doesn't just extend the first image and move the package files onto it?

The Debian script it looks like it merges all .isos into a single readable image, complete with combined package lists and the like.

 

[Snial]

The Debian script it looks like it merges all .isos into a single readable image, complete with combined package lists and the like.

Aaah, OK. I'd looked at the web page talking about this and then forgot about it. So, perhaps that solves one problem: it results in a merged .iso . In this case, the .iso would be about 1.932GB I think, less than 2GB. Sorry about that.

This is from:

Post in thread 'How do I write Macintosh CD images to physical CD's?'

Mar 4, 2026

OK, I have a related question: I'm planning to put 3x 650MB Debian .iso's onto a single 2.1GB SCSI HD (an actual SCSI HD) as a single image. There's a web page telling me how to merge the .iso's:

MergeDebianIsos - Debian Wiki

wiki.debian.org

However, my PowerBook 1400 is my only properly working SCSI Mac. So, the workflow is:

DebianIsoDownloads -> Mac mini i5 -> CF Card -> PowerBook 1400c -> External SCSI HD.

Now, with Mac OS X I could use dd to copy the .iso's block by block. I'm not sure what I should use with Mac OS 8.1. I certainly don't want a partition table...

• Snial

Of course, where it says: "I certainly don't want a partition table", it means I don't want an Apple Partition Table, the original .iso partitions are fine and expected.

 

[Phipli]

The Debian script it looks like it merges all .isos into a single readable image, complete with combined package lists and the like.

I was thinking it would be strange if it didn't and the description on the page sounded like it did.

 

[joevt]

So, if I created a blank .img without a partition map I should be able to mount it on Dingus PPC; then run @saybur 's scuzImager to write a .iso to it. We don't know if it'd save it properly, but I could use scuzImager again to write it to another .iso and then compare them?

It should save properly, as it would be interpreted as an entire disk.
If the iso is from a CD, then the resulting .img might be suitable only as a CD.
I would examine the partition map of the disk image using dumpvols.sh on macOS to see if it makes sense for a CD or HD.

CDs might have block size of 2048 while HDs have block size of 512.
I've seen partition maps that support both block sizes.

 

[finkmac]

Something like this would be great and very useful. I need to get an image of a real spinning disc A/UX SCSI volume to zigzagjoe for testing/debugging purposes and currently there is no way for me to do that with the setups I have at my disposal.

honestly for that specific task i'd suggest using a Zulu-Compatible SCSI Emulator in initiator mode

 

[Snial]

For fun I wrote a version of DumbDD in THINK C 5. It's <4kB and fairly crude. I transcribed the Forth routines from MacTech I linked earlier, but I have almost certainly made mistakes. I tried it on miniVMac with the actual SCSI writes blocked out (and a delay of 2/60ths of second between each sector) so I could watch it update, but the version of Dd and the project attached would do it for real (find the #if 1 in the .c and turn it to #if 0 to reenable dummy writes). I tried to try it on InfiniteMac emulating a PM6100, but I mucked something up and now it won't boot properly with Saved HD. It thinks there could be another instance in a different tab using it, but there isn't another Infinite Mac tab and I don't know how to find and delete the Saved HD cache file ( @mihai , @joevt I'm sure you know). Also the BlueSCSI support crashes now, so I don't think I can get anything in or out. I'm not yet brave enough to try it on a real Mac.



You can quit mid-way by choosing File:Quit, or by closing the window. Progress updates every 0.5s. I think I'll change Dd:Copy to Dd:Transfer, because obviously Copy belongs on the Edit menu, but I didn't want Dd to be considered an 'Edit'. You can do stupid things like switch the SCSI device mid-transfer and it will happily trash another disk half way through, so take care! In future updates I would disable those menu options during transfer, add a Filename and SCSI ID to the window update (and maybe a progress bar). I would also support Option+'.' to stop a transfer without quitting and/or Dd:Stop .

Here's the app and project as it currently stands.