DumbDD

[Snial]

Hi folks,

I've tried to ask about this a couple of times, with little response except for a suggestion to try FWB. However, in another post I found FWB CD Toolkit crashes with a Type 3 error. So, I thought I'd write (what I imagine to be) a fairly simple utility to do what I want: DumbDD, since as far as I can tell, Classic Mac OS disk copying apps are intelligent things that want to write HFS, MSDOS or ISO images or volumes to partitioned devices (which makes sense) it already understands. I want to write an ISO for a foreign CD image (Debian, PA-RISC as it happens) to a SCSI Hard disk.

DumbDD
.. would be super-simple. It has a File:Open.. dialog to open any file as a disk image file... your fault if you pick a non-disk image file. It has a Dump:To SCSI0 to :SCSI7 menu option to write the image to a given SCSI device as raw blocks.

I've been reading the docs about how to use the SCSI manager:

MacTech | The journal of Apple technology.

preserve.mactech.com

MacTech | The journal of Apple technology.

preserve.mactech.com

I think there are a few others I could use. The first one uses assembler and Forth, but I understand both and I'll convert it to 'C'. I don't need to write a driver.

Is this of any use to anyone?

 

[gsteemso]

“dd” for Classic Mac OS sounds like a great idea! This could help with an issue that was mentioned in a thread somewhere here around 68kmla a couple of months ago... (some versions of?) the Finder and/or OS will write a few obscure bytes to any given volume that make it difficult or impossible to get an exact binary duplicate when working "within the system". (At least, I think that was at the volume level. It _might_ have been individual files, I can't find that thread to verify.) Nobody knows what they’re for, but I can’t imagine it adversely affecting anything to bypass that activity; or you wouldn't, for example, be able to compare two optical discs for having been burned correctly.

tl,dr: This is an idea long overdue. Good thinking!

 

[saybur]

I drafted a small demo program yesterday in response to your first post to do what you're describing: single function, just write a file as a disk image to an arbitrary SCSI ID. Based on testing disk images worked fine. However, the limited number of small CD images I tried did not work, but I'm uncertain if it's a bug or a structural issue with MacOS partition on an .iso, I am ignorant about how those work. I'll mess around with it some more today and post if I get results.

Note what I'm writing is not a true `dd` replacement, that would include (at minimum, IMHO) byte/sector offsets, skips, and all the other super-useful stuff that makes it such a swiss army knife of a program.

 

[gsteemso]

A CD or DVD uses a different partition-map format than a hard drive, and the Mac would not be able to make sense of it unless you wrote it to something it considers to be an optical disc. I'm not sure there's any way to do that with stock software.

 

[Paralel]

I guarantee this would be extremely useful, especially if you could make it so that it worked in reverse, it can create a raw block copy disk image of any given SCSI drive attached to the system.

 

[Snial]

I drafted a small demo program yesterday in response to your first post to do what you're describing: single function, just write a file as a disk image to an arbitrary SCSI ID.

Perfect, well done! I did wonder if someone would beat me to it, but I thought .oO( I might as well fish for a level of interest. Besides, it'll take ages for someone to write something). LOL! [ ".oO( ... )" is my symbolism for thinking, it's an ASCII thought-bubble].

Based on testing disk images worked fine. However, the limited number of small CD images I tried did not work, but I'm uncertain if it's a bug or a structural issue with MacOS partition on an .iso, I am ignorant about how those work. I'll mess around with it some more today and post if I get results.

I thought this was because the disk's driver is stored on a partition within an Apple Partition Map drive. Early SCSI drives couldn't work with a generic SCSI driver, which I think is partly why the second MacTech article is focussed on adapting the demo SCSI driver to work with a 280MB Quantum drive.

So, for example, I think HD SC Setup would install the driver on the drive, or an Apple-formatted drive would already come with a Mac driver installed. This also explains why, certainly in the early days, only approved drives were supported.

It also explains why a CD .iso won't work, since I wouldn't expect it to have a SCSI HD driver on a partition. It wouldn't be a problem for me as I'm writing a foreign CD file system to a disk, a Debian 5 Installation for a PA-RISC system.

Note what I'm writing is not a true `dd` replacement, that would include (at minimum, IMHO) byte/sector offsets, skips, and all the other super-useful stuff that makes it such a swiss army knife of a program.

But it's a great start! I've assumed you've used 'C'. Is it a THINK C, Metrowerks, MPW or Retro68 project? Is it 68K or PPC? Are you happy to publish it here or push it to git (or your preferred online repo)?

 

[gsteemso]

You're quite correct, there's a driver on there too. I'd somehow forgotten that detail. 3rd party drivers that tried to be more performant were a legitimate market for a while.

 

[saybur]

A CD or DVD uses a different partition-map format than a hard drive, and the Mac would not be able to make sense of it unless you wrote it to something it considers to be an optical disc. I'm not sure there's any way to do that with stock software.

Makes sense. I've been spoiled by modern Linux distros being able to `dd` an image and having it "just work" most of the time.

But it's a great start! I've assumed you've used 'C'. Is it a THINK C, Metrowerks, MPW or Retro68 project? Is it 68K or PPC? Are you happy to publish it here or push it to git (or your preferred online repo)?

What I've got so far is just a scuzEMU derivative. The low-level SCSI commands in/out of files was already halfway to what was needed. It's inheriting the THINK C environment and GPL, so source would be available. Assuming I can get it working properly

For @Paralel I've hacked in disk reading in the prototype, agree that'd be useful.