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?

"DO" suggests that your image is (already) using DOS sector ordering. There no change besides renaming to whatever.DSK to make Linapple happy. By way of background... DOS sector ordering is the original mapping of physical to logical sectors; sectors 1, 2, 3, etc. are laid out using a skew factor so that they come flying by the read head not in numerical order, but in the order in which DOS is ready to read them. ProDOS changed this order since it always reads two sectors at once, so they're clustered together differently (and due to some code speedups in the core OS, they're skewed differently as well). If a disk was captured in native ProDOS sector order, it would be correctly suffixed with .PO. The naming scheme of "DSK" is ambiguous - it could be either ProDOS or DOS sector ordered. You won't really know unless you inspect it closely and know what to look for; tools like CiderPress and AppleCommander use heuristics to determine which order an image is likely to be. Most newer emulators automatically make the switch to whatever they need as well.

Take a look at page 7 of your Fine Manual (Figure 1: Selecting "Disk II Assignments" from the menu.). You can pick a set of disks to cycle through on drive 1, and a (potentially different) set of disks to cycle through on drive 2. That's what "Drive1" and "Drive 2" mean on your push buttons - "Drive 1" cycles through disks on the drive 1 list, and "Drive 2" cycles through disks on the drive 2 list. Folder membership doesn't mean anything - images can be assigned wherever they are on your USB or CF media. Only membership that you pre-populate on that configuration screen matters.

Just your time and effort. Have at it!

No, that drive is done, pure and simple. You will not reattach that in a way that it will ever read or write again. Start looking for a replacement.

A picture of the *other* side would be very interesting. If it's all sealed up - it's probably a software protection dongle. Not a particularly common thing to do with the Apple II line, but they did happen from time to time. Not likely for protection of the socket; it's for protection of software. :-)

Looks like you added more information about the hardware failures you're having over on Facebook - will watch that thread over there instead.

What game is it? Have you tried using Passport to crack it?

This device suffers from similar, but different problems as the WiFi32 Modem does: one protocol is hiding behind another. There was some interesting discussion a while ago about the former here: https://groups.google.com/d/msg/comp.sys.apple2/nm3vXZ_8Ml4/IZExrPvqAAAJ This device at least makes slightly more sense than the WiFi32 Modem, but the packets might need tweaking at the server side. And whether or not the packets arriving at the client side will look sane is anyone's guess. I downloaded the user manual: https://s3-ap-northeast-1.amazonaws.com/sain-amzn/20/20-028-100+/20-028-100+User+Manual.zip The English was a little difficult to parse, but I gather that you can set it up to talk to a destination IP address and port. But what this thing does is not what the Uthernet/Uthernet II do: it converts serial to Ethernet. It doesn't remove the need for an adapter card in the Apple II to either generate serial or Ethernet. You still need a serial card - PLUS this thing. It doesn't offer any speed benefits, and nothing will be compatible out of the box with it.

Will you also be targeting the Uthernet II card, or just the first one?

AND the disk needs to be double density, not high density.