Disk Jockey, a disk image file maker for your retro stuff - Beta for version 3!

[OneGeekArmy]

Next thing for me is getting an external bluescsi one to hook it up on my GVP controller on my A2000.
I don't think I can use DJ to produce 1GB SCSI-Drives that are usable on the Amiga?

Not at this point, no. But I'm actively working on DJ (I'm slowly getting close to a new release) so that could definitely be in the cards. Lacking an Amiga, my main issue would be testing. I'll still take a look at the Amiga disk format to see how exotic it is. You never know

Edit: Looking into this a little, I see here a blog post where a BlueSCSI user used a blank disk image, submitted it to a formatting utility and off it went. If that's something that could work for you, just tell Disk Jockey the size you want (don't worry about specifying a model), tell it you want an image for Basilisk (so that it doesn't install the Mac partition map and the SCSI drivers), name it to match the BlueSCSI requirements and it should spit out something useable.

If someone could point me in the direction of a known-working hard Amiga disk image, it would be very useful.

 

[drzeissler]

Just ordered a DB25 one. we will see how this turns out

 

[OneGeekArmy]

Version 2 is out! Check out the starting post of this thread to find out what's new!

 

[Kai Robinson]

Oh my science - the disk-o-matic is amazing!

 

[OneGeekArmy]

Oh my science - the disk-o-matic is amazing!

Thank you!

 

[ScutBoy]

Very nice! Thank you!

 

[Garrett]

It just keeps getting better and better! Can't wait to try this out later.

 

[retr01]

Version 2 is out!

Wow! The Disk-O-Matic part of the Disk Jockey is fantastic! The Disk-O-Matic would be a big help, especially if I wanted to create images for one OS installer image from a large volume, such as System 7.1 from the 1999 Apple Recovery CD.

@OneGeekArmy, I have a suggestion. Can you please add a step after clicking on "Create a Volume Image" to allow specifying the image sizes of the new volume? Currently, it is simply creating a 2 GB image, which is usually unnecessary to have a large size. I believe it is possible to identify sizes that will "fit" and suggest other larger sizes to the end-user.

Cheers!

 

[OneGeekArmy]

Wow! The Disk-O-Matic part of the Disk Jockey is fantastic! The Disk-O-Matic would be a big help, especially if I wanted to create images for one OS installer image from a large volume, such as System 7.1 from the 1999 Apple Recovery CD.

@OneGeekArmy, I have a suggestion. Can you please add a step after clicking on "Create a Volume Image" to allow specifying the image sizes of the new volume? Currently, it is simply creating a 2 GB image, which is usually unnecessary to have a large size. I believe it is possible to identify sizes that will "fit" and suggest other larger sizes to the end-user.

Cheers!

That's an interesting idea!

Currently, it creates an image the same size as the volume on the device you're extracting it from (not just a 2 GB one). So, yes, if it's a 2 GB volume that only contains a handful of small files, that's a lot of wasted space.

The issue I'd face is that HFS can (and does) write parts of your files anywhere on the volume. Some bits are at the beginning, some are at the end, and some are in the middle. HFS+ also implements Hot Clustering, which optimizes the location of the most accessed files so that the drive head moves as little as possible. It's the Wild West in there.

Disk-O-Matic could easily calculate the ideal size for your volume, but then it would have to move your files around so that they would fit. And this means actively modifying the Catalog file. I'm not brave enough to implement this, yet.

But I'll keep it in mind. If Disk-O-Matic ever allows users to copy files to and from the disk image (that would be an obvious next step), I'll definitely implement your suggestion.

 

[retr01]

Currently, it creates an image the same size as the volume on the device you're extracting it from (not just a 2 GB one). So, yes, if it's a 2 GB volume that only contains a handful of small files, that's a lot of wasted space.

Aye.

The issue I'd face is that HFS can (and does) write parts of your files anywhere on the volume. Some bits are at the beginning, some are at the end, and some are in the middle. HFS+ also implements Hot Clustering, which optimizes the location of the most accessed files so that the drive head moves as little as possible. It's the Wild West in there.

Yes. Back in the day, it WAS the Wild Wild Silicon West that Apple grew up in.

Disk-O-Matic could easily calculate the ideal size for your volume, but then it would have to move your files around so that they would fit. And this means actively modifying the Catalog file. I'm not brave enough to implement this, yet.

But I'll keep it in mind. If Disk-O-Matic ever allows users to copy files to and from the disk image (that would be an obvious next step), I'll definitely implement your suggestion.

Have you analyzed the source of AppleCider and how it handles moving around inside HFS images? One of AppleCider's features includes HFS support:

Disk Image Support

CiderPress has the ability to identify nearly all Apple II disk image formats automatically. Supported file formats include:

• Universal Disk Images (.2mg, .2img)
• DiskCopy 4.2 (.dsk)
• Copy II Plus (.img)
• Sim //e HDV images (.hdv)
• TrackStar 40-track images (.app)
• Dalton's Disk Disintegrator (DDD v2.1+, DDD Pro v1.1+) (.ddd)
• Raw FDI images of 5.25" and 3.5 disks (read-only) (.fdi)
• Unadorned sector-format files (.po, .do, .d13, .raw, .hdv, .iso, most .dc6)
• Unadorned nibble-format files (.nib, .nb2)
• Any of the above compressed with gzip (.gz) or zip (.zip)
• ShrinkIt (NuFX) compressed disk images (.shk, .sdk)

The image file format, filesystem, and sector ordering are determined automatically for most disks. The settings can be overridden if necessary. Images larger than floppies, such as ProDOS and HFS hard drive partition images, are fully supported.

The recognized filesystem formats are:

• DOS 3.2/3.3 (13, 16, or 32 sectors, up to 50 tracks)
• ProDOS
• UCSD Pascal
• HFS (up to 2GB)
• CP/M
• SSI's RDOS (13-sector, 16-sector, and converted 13-to-16-sector formats)
• Gutenberg word processor

DOS, ProDOS, HFS, and UCSD Pascal filesystems are fully supported. You can view, add, extract, rename, and delete files, as well as create bootable blank disk images. Change disk volume names and DOS volume numbers. Create subdirectories and change file types on ProDOS disks. Files on CP/M and RDOS disks can be extracted and viewed. CiderPress also recognizes the following "meta-formats":

• UNIDOS / AmDOS / OzDOS (two 400K DOS volumes on an 800K disk)
• ProSel Uni-DOS / DOS Master (one or more DOS volumes embedded in an 800K ProDOS disk)
• Macintosh-style disk partitioning (for hard drives, CD-ROMs, flopticals, etc).
• CFFA-style partitioning (fixed-size 32MB/1GB volumes, for Compact Flash cards).
• ///SHH Systeme MicroDrive partitioning (allows up to 16 partitions on IDE hard drives).
• Parsons Engineering FocusDrive partitioning (allows up to 30 partitions).

 

[OneGeekArmy]

Have you analyzed the source of AppleCider and how it handles moving around inside HFS images? One of AppleCider's features includes HFS support:

It never actually occurred to me that the sources for AppleCider were available. That's very interesting, thanks!

I'll definitely take a look, but no promises that I'll ship anything!

 

[rikerjoe]

I’ll second what @retr01 said - the Disk-O-Matic part of Disk Jockey is fantastic! Here is my use case. I started with disk images over a year ago and not knowing what we all know now. I formatted those images using Lido. I also grabbed a number of disk images for which I had no idea how those were formatted or which drivers were installed. Once I saw the posts about performance problems with Lido-formatted images in modern replacements such as BlueSCSI and RaSCSI, I started formatting new disk images with other tools. However, I found issues when mixing images formatted with different utilities which I’m sure you more knowledgeable types would expect to happen, ranging from a failure to mount certain images in a mixed driver environment to death chimes on boot with certain classic Macs. I have a mix of original drives, SCSI2SDs, BlueSCSIs, and a RaSCSI.

I started a painstaking process of creating new blank disk images formatted with something other than Lido, and moving the files from the former images to the new ones using Basilisk II. I got about halfway through that process when I saw Disk Jockey 2.0 dropped with the new (at least to me) feature to read images and tell you about the driver on the image and offer to replace the Lido driver with the classic driver from Apple!

I was able to breeze through the rest of my disk images in a fraction of the time I spent using the brute force method. Now, all my images contain the original Apple driver. Thank you so much for creating Disk Jockey, @OneGeekArmy !

 

[lilliputian]

Wonderful utility!

Any chance of it working with Disk Copy 6 NDIF images in the future?

 

[OneGeekArmy]

I’ll second what @retr01 said - the Disk-O-Matic part of Disk Jockey is fantastic! Here is my use case. I started with disk images over a year ago and not knowing what we all know now. I formatted those images using Lido. I also grabbed a number of disk images for which I had no idea how those were formatted or which drivers were installed. Once I saw the posts about performance problems with Lido-formatted images in modern replacements such as BlueSCSI and RaSCSI, I started formatting new disk images with other tools. However, I found issues when mixing images formatted with different utilities which I’m sure you more knowledgeable types would expect to happen, ranging from a failure to mount certain images in a mixed driver environment to death chimes on boot with certain classic Macs. I have a mix of original drives, SCSI2SDs, BlueSCSIs, and a RaSCSI.

I started a painstaking process of creating new blank disk images formatted with something other than Lido, and moving the files from the former images to the new ones using Basilisk II. I got about halfway through that process when I saw Disk Jockey 2.0 dropped with the new (at least to me) feature to read images and tell you about the driver on the image and offer to replace the Lido driver with the classic driver from Apple!

View attachment 6335

I was able to breeze through the rest of my disk images in a fraction of the time I spent using the brute force method. Now, all my images contain the original Apple driver. Thank you so much for creating Disk Jockey, @OneGeekArmy !

Thank you so much for taking the time writing your feedback.

After spending weeks working on this with little feedback (except from a select few in-the-know co-conspirators), it's thrilling to realize that this is actually helping people like yourself.

And there's more coming

 

[OneGeekArmy]

Wonderful utility!

Any chance of it working with Disk Copy 6 NDIF images in the future?

Thanks!

I'd love to add NDIF compatibility. However, it's a bit more tricky than the other formats, as it involves compression and relies on both the resource and the data fork (which makes it hard to handle on fork-less operating systems like we have these days).

But it's on the to-do list!

 

[retr01]

Hey @OneGeekArmy, there are a couple of other modern HFS file utility programs that you can check out:

• HFVExplorer (Windows)
• FuseHFS (Mac)

 

[OneGeekArmy]

Hey @OneGeekArmy, there are a couple of other modern HFS file utility programs that you can check out:

• HFVExplorer (Windows)
• FuseHFS (Mac)

Thank you. I took on Disk Jockey as a personal challenge, to see how far I could take it (I had a few things I wanted to prove to the 15-year-old I was in the eighties . I didn't look at the existing solutions but I'm sure there's good inspiration to get from them.

By the way, I just released version 2.0.1 which fixes a crashing bug when parsing HFS partitions with many files. Nab it!

 

[rjkucia]

Depending on what your long-term goals are for this project, it might be nice to host it on Github (or some other public repository). Even if you just want to work on it yourself, it might be an easier way to keep track of issues or feature requests. And if you're open to others collaborating, it'd of course make that a lot easier.

 

[OneGeekArmy]

Depending on what your long-term goals are for this project, it might be nice to host it on Github (or some other public repository). Even if you just want to work on it yourself, it might be an easier way to keep track of issues or feature requests. And if you're open to others collaborating, it'd of course make that a lot easier.

Thank you for the suggestion. I'm pretty old-school when it comes to your GitHubs and whatnots and it didn't cross my mind to use it for that purpose. I might open up Disk Jockey at some point, but right now it's a bit of a personal journey and I'd like to keep it that way.

But the issue and feature request tracker would be very useful. Thanks again.

 

[OneGeekArmy]

New version out! Disk Jockey now has a sidekick! Check out the first post of the thread for the details.