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.

 

[Snial]

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.

I guess there are PC ROM BIOSes (or EFI, or UEFI) to do that. On the Mac side we had direct ROM support for the Sony FD, then SCSI (but not specific SCSI media, as discussed earlier) and this took us to the cheapo 2-bpp, PowerBook 150 which I think was the first Mac to support IDE. The PB150 is also a spiritual cousin of the Neo so I should add a comment on that thread.

Then some other 68K Macs started supporting IDE in ROM (e.g. the Q630/Performa 630 & PB190), but then IDE support took off with early PPC Performas. Then we entered the Open-Firmware era, which allowed more boot-up media support while IDE migrated to PowerMacs (PM4400) and G3 PowerBooks and PowerMacs. Then New World took over, which made no difference as HFS/ HFS+, SCSI, IDE and now USB were now supported in OF (and every Mac from the iMac G3/DV can boot from USB with some hacking). In all these eras, booting into Linux with a foreign file system (e.g. ext2) meant providing a minimal HFS partition with a boot file, which then jumped into the Linux FS.

In the Intel era we united with PC conventions by adopting EFI, so literally the same mechanism for booting PCs worked for Macs.

Apple Silicon has another ROM architecture.

But anyway, the upshot is that all System and media Expansion ROMs on Macs, PCs, historical Unix Workstations (Sun/SGI/HP/IBM) and SBCs, provide a basic sector handling driver from which more sophisticated drivers can be located via the boot block.

Going back in time to the minicomputer era, primary bootstraps were media-specific, 10 instruction (or so) programs toggled into core that could load the boot block from the specified media and in turn bring up the OS.

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.

So, upshot: should I have a crack at writing my own, or are you likely to release yours before I'd get anywhere? I'm actually wondering if I could write it using infinite Mac's Dingus PPC emulator ( @mihai, @joevt - are mounted drives or Saved HD SCSI drives, with proper SCSI hardware emulation?).

 

[adespoton]

Here's a question: NDIF supports raw image files. Which means that, at least theoretically, if you can write something into NDIF format, Disk Copy should be able to write it out to disk. The problem currently is that Disk Copy tries to be "intelligent" about how it images a disk into NDIF format.

I like the idea of MacDD too (and a fully featured MacDD would be AWESOME), but has anyone tried writing something out via the NDIF spec yet?

 

[saybur]

Here's the prototype. This can either read SCSI devices into images (File:Read Disk) or write images to SCSI devices (File:Write Disk). Pick a SCSI ID and then a file to write/read. This is very much an alpha and it may eat all your data, please use with great caution. There are many, many caveats:

• Testing has been performed only in MAME, no real hardware yet. I haven't tested on big devices.
• Support is limited to <2GB image files, no big drives here.
• No support for multiple SCSI buses, whatever ID maps to the old SCSI manager routines is what is used.
• Volumes with blocksizes != 512 are untested but should theoretically work.
• The name scuzImager is a placeholder, please give suggestions (or icon resources)

If anyone wants to live on the edge feel free to try this out.

EDIT: another warning: this will happily execute write commands to mounted drives (or to your boot volume if you pick that ID). Always reboot after using the write feature.