ADTPro for Macs!?! (I swear this is Apple II related)

[DistantStar001]

Did anyone know that you can use ADTPro, and an Apple //e to write 400k, and 800k Macintosh disks? I recently tried this, and much to my shock, it worked. The images had to be in .img, or .image format, .dsk didn't work, which is weird since nearly all the Apple II disks I've written were in that format, but for some reason it won't work for Macs. Also, the disks had to be formatted on my Mac, before they could be written. Still, I thought that was really trippy when I tried it, and now I can play Star Wars on my Mac Plus!

 

So now I am wondering, has anyone else tried this? If so, did you try a High Density (1.44MB) image? (Presently I don't have the equipment.) And do you think it would be possible to write disks for other platforms, like Atari, IBM, or Commodore? I mean I know it's been Apples to Apples for me so far, but maybe someone out there has thrown in an orange?

 

[david__schmidt]

The recording/sector layout is the same between 800k disks on the Mac as on the II line, so as long as you have the bits lined up the way the Mac likes them, ADTPro will lay them down for you. I think the 1.44MB Mac format uses a more PC-like sector arrangement (also not Continuous Angular Velocity and all that). The II is unlikely to be able to write anything at 1.44MB via ProDOS that the Mac could read. A high-density 3.5" drive on an Apple II was a rare thing indeed.

 

Oh, and no, all the other non-Apple systems have mutually exclusive reading and writing capabilities. (Well, OK, the 1571 could do MFM as well as GCR, so technically the Commie and IBM could cross-breed somewhat... but none of that has anything to do with ADTPro and the reading/writing capabilities of ProDOS.)

Edited August 5, 2018 by david__schmidt

[DistantStar001]

Thanks!

 

Also I was told that the .dsk files were likely made by DiskCopy, and that's why ADTPro has trouble with them. Is there any way to convert them to a more ADTPro friendly format?

[david__schmidt]

The suffix ".dsk" means many different things. It doesn't offer a lot of clues by itself. If it's Mac related and .dsk, it could be DiskCopy, or any of an array of programs that created (and potentially compressed) disk images. So depending on what it really is, you'd have to unwrap whatever envelope and/or compression was surrounding it and get it into a more plain form. How to do that will depend on what it really is. A pointer to the actual .dsk in the wild would be helpful here.

[DistantStar001]

I'll have to go through them. I've only tried a handful so far, and when they didn't work, I moved on to what did. I honestly don't recall which files they were, as I removed them from my directory after they failed. (It probably would have been a good idea to keep track of that.)

 

However, If I'm understanding you correctly, then there is a chance that .dsk files that are uncompressed might still work. If so, is there a size range I should be looking for to identify compressed images? So far the .img files that have worked were 819k to 820k, however similar sized files that I've tried did not work in .dsk.

 

Nearly all these files that I've tried (wether ADTPro will write them, or not) mount on either vMini Mac, BasiliskII, and SheepShaver, and often all three. With BasiliskII, and SheepShaver the files were all mounted with DiskCopy. Only Star Wars gave me problems on BasiliskII, and SheepShaver (a .image file), using DiskCopy, but ADTPro wrote the "original" without a problem. The "cracked" version had mis matched blocks, and was ultimately unreadable by any of my macs, but it still wrote. The problem I'm having with .dsk files is that they freeze at some point in the writing process (apparently on the mac end). On 800k images this usually happens after half the blocks had already been written.

 

I did finally manage to get Star Wars to work, but I had to go though some hoops to do it. I ended up using vMini Mac to mount the "cracked" image, and transfer the files to a new .dsk (1MB was the smallest I could make, and I had to use BasiliskII to do it), then I mounted it on SheepShaver, and used DiskCopy to make a writeable 800k .img. From there, I dragged, and dropped the contents of the .dsk into the blank .img. The resulting .img file did write, and was readable by my Mac SE, but wouldn't boot on my Mac Plus (even with all the help of Norton). I was eventually able to fix this by archiving the "cracked" application on my SE's HD, then re formatting, and rewriting the disk with the "original" .image on ADTPro, and replacing the "original" app with the "cracked" version on my SE. Would a similar method (minus the App swap) work for other .dsk, or otherwise unwritable files? And if so, how do I make the resulting .img file bootable?

 

On a side note: do you think I can use ADTPro to archive Mac disks, like I have with some Apple II's?

Edited August 6, 2018 by DistantStar001

[david__schmidt]

An unadorned disk image will be 143,360 bytes if it's 140k, and it will be 819,200 bytes if it's 800k. Anything else other than those numbers means it's something else; there's some other wrapper, or some compression going on. ADTPro knows how to handle a .2mg header, and it knows how to handle ShrinkIt .SDK and DiskCopy 4.2 images (http://adtpro.com/historyolddetail.html#a1.2.3). So again, having a look at an image that causes trouble might be interesting to examine.

 

As for the hoops you described - man, I don't know. It sounds like you're doing a lot of work to make disks that could be much more simply reconstituted with a compact Mac. I'm not sure reforming every random Mac disk image out there into a more raw form that ADTPro understands is the right way to go.

 

ADTPro will archive 800k Mac disks just fine (except when copy protection is involved), and it'll write a very plain, standard, ProDOS image that every Mac emulator under the sun will understand.

Edited August 7, 2018 by david__schmidt

[DistantStar001]

Thanks