david__schmidt

Ah, interesting observation. So, what used to happen was the old DOS-based ADT would be built and included in the "disks" directory. It effectively mirrored what was in the official ADT repository (used to be Berlios.de for those with a long memory), but had some settings tweaked to be more in line with ADTPro (faster default speed comes to mind). Over time, the more-or-less official repository for DOS ADT moved to GitHub (https://github.com/david-schmidt/adt) and while the code is still shared and built, ADTPro doesn't add the disk in its distribution any more. So that's what exactly is meant by "integrated." It's partly a holdover from a different time, and it's partly an oversight for not bundling the disk (which is no longer strictly needed). The reason DOS ADT is relevant at all is because it runs in 48k (where ADTPro does not), and there are some legacy servers for DOS ADT that go where ADTPro server can't (MacOS 8.x and earlier, PC DOS, etc.) I used to say speed was DOS ADT's advantage too chiefly because it turns the drive motor on preemptively; but now ADTPro's client does that too, and the tunable payload size gives ADTPro a much greater speed advantage. Edit: I just remembered, yes, you can push EsDOS as well as the DOS ADT client via serial bootstrapping operations. So while the actual disk doesn't get included in the distribution, the virtual image of the program itself is available to push over the wire. That version is 2.41.

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.

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.

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.)

It's your cable. It truly needs to be a "printer" cable in order to work.

Find and remove the .kext file it laid down... I'm not an expert on where that is exactly, but that's the extent of it. It's likely got some relationship with the name in the profiler.

Yep, that's consistent with lots of other Mac users. FTDI-based USB adapters are the way to go.

Either of those could work; there's no reason to pick one over the other. Prolific has historically been poorly cloned and drivers are notoriously bad on a Mac, but that might work for you.

I don't see the Mac listed as a supported platform (i.e. for drivers) on Digi's documentation for the Edgeport set of products. Are you sure you've got drivers installed for either device you have plugged in? It's a separate step you have to explicitly do in the Mac world.

What's the USB device's name that shows in the profiler?

Don't use the app launcher - use the adtpro.command file instead. (And don't move the RXTX files around, either - you will want to undo whatever you did there.) I'm making an assumption that 1) you have a USB-serial adapter plugged in to your Mac, and 2) it's got the correct driver installed so it's visible to the system.

Ummmm... yes? https://drive.google.com/drive/folders/0Bzvt4aKblfWUYmh3RTVxQzBmRUU

.PO - maybe. .NIB - no. Nibble images are their own thing; either an emulator supports them as-is, or it doesn't.

Sounds like a hardware problem with the IIe's memory. You might want to run internal diagnostics (see this if you have an enhanced IIe) or create a diagnostics disk and run that.

What are the symptoms? Can you describe what happens when you try?