Issues with the new 8 drives per slot feature of ProDOS8 2.5

[LuiZ-80]

It's not actually a bug, but one issue I've run into while testing both the A2D 1.2 pre-alpha 8 (which is incredibly awesome, BTW) and the ProDOS8 2.5 alpha 7 on my Apple //e is that A2D does not play nice with the new feature of more than 2 drives per slot of ProDOS 2.5 (https://github.com/ProDOS-8). It fails rather gracefully in that it justs duplicates the first two partitions of my CFFA card (that has 4 partitions). Although it seems to recognize that partitions 7/3 and 7/4 exist and are not currently remapped to slot 4 (as in every previous version of ProDOS, including 2.4.2), it apears to get confused and mounts partitions 1 and 2 twice on the desktop. Everything else works perfectly, and I had no issues launching any of the apps on my Selector List (they're all on the 1st and 2nd partitions), I just don't have access to any partitions beyond the first two.

ProDOS 2.5 is still in alpha, so only those users on the bleeding edge of Apple II software (a rather quaint concept in 2019) are likely to run into this issue for now, and it's not like anybody should be relying on pre-release software anyway (for the record, I only tried ProDOS 2.5 by booting from a floppy, my regular configuration boots 2.4.2, the stable release, and A2D 1.2-8 works fantastically with that).

This is more of a humble 'heads up' than a feature request or a bug report, seeing as both projects are currently in development, that perhaps it would be interesting to contemplate the new ProDOS features (2.5 also introduces support for lowercase file and volume names, and removes the 51 files limit on the root directory, though I didn't run into any issues with that in my limited testing), since it's likely that both projects share the same target audience.

[inexorabletash]

Are there docs on the new unit number scheme?

There is a fair bit of code in A2D that assumes the top nibble of unit numbers is 3 bits for slot and one bit for drive, as in previous versions of ProDOS, and uses this to index into the 16-entry driver entry point table. So... this will probably be a lot of work to support.

[JohnMBrooks]

Bit layout for P8 2.5 unitnum: 76543210 DSSS00XY

Where DSSS are Drive bit 0 and Slot bits 2:0 like previous P8 versions. X is Drive bit 2 and Y is Drive bit 1.

To calc the drive # (1-8) from a P8 2.5 unitnum in Acc: ASL AND #7 ADC #1

The internal /RAM drive in slot 3, drive 2 has a unitnum of $B0 (vs $BF in 2.4).

P8 2.5 now supports up to 37 drives stored at $BF32-$BF56, with a $00 terminator at $BF57.

All 8 drives per slot use the per-slot driver handler at $BF12-$BF1F with the 'drive 2' driver unused. However the internal /RAM driver is still called through the 'slot 3, drive 2' handler at $BF26 for compatibility with apps which disconnect /RAM in order to use aux memory.

[inexorabletash]

Thanks. Well... that will be a lot of work. 😬

• A2D uses the low nibble of unit numbers to determine drive type. This is technically wrong, but it mostly works through 2.4. We'll need a protocol to identify drive type (5.25, RAM, or SmartPort; the latter can use the SP protocol to further distinguish)
• There are copies of the device table used, e.g. when /RAM is disconnected and later restored, and some mapping tables from index in device table to other data structures
• There's only storage for 13 volume icons; this would need to be increased.
• There's the whole Disk Format overlay which hasn't been fully disassembled/updated; it shows a drive selector which will probably do horrible things in 2.5 until it is updated
• Is there room on the desktop for 37 icons!?!?!? I mean, really....

So... good to track this, but I can't imagine getting around to it. PRs welcome, of course! And I'm happy to chat with anyone to answer details about how DeskTop works internally where it's not obvious from the code. (I can suggest starter bugs, like wiring up P8 2.5 date handling #169 ...)

[JohnMBrooks]

Well... that will be a lot of work. 😬

I am not surprised. Copy II Plus has needed a fair amount of rework too. My thinking so far has been to fork the app code so the P8 2.5 version can expect to have extended dates, clock drivers with second/millisecond precision, 8-drives per slot, lowercase names, '../' paths, etc. Trying to support both 2.4 & 2.5 in the same app runtime would be hard/large.

Q: 1) How does A2D use drive type? 2) Why is the device table copied? Or is it just the S3D2 entry at $BF26/27 that is copied? 3) Any other changes/fixes to P8 that would help A2D?

Apps can choose to support fewer drives. 37 is just the max space available under P8 2.5.

[inexorabletash]

Other unit number uses:

• Add Format/Erase to the list of overlays that enumerate devices. That one is mostly disassembled.
• Determining SmartPort dispatch address: https://github.com/a2stuff/a2d/blob/master/desktop/desktop_main.s#L10364

How does A2D use drive type?

• I've factored out a common routine that distinguishes types; the code does slightly more than what was there originally, including probing network shares and guessing 800k disks based on capacity: https://github.com/a2stuff/a2d/blob/master/desktop/desktop_main.s#L8795
• Used for determining the icon to show (can happen any time): https://github.com/a2stuff/a2d/blob/master/desktop/desktop_main.s#L8994
• Used for populating a list of drive names for use by copy/format/erase (fixed at startup, I think): https://github.com/a2stuff/a2d/blob/master/desktop/desktop_main.s#L16199

Why is the device table copied? Or is it just the S3D2 entry at $BF26/27 that is copied?

S3D2 is the main reason. The table is backed up, then restored on exit:

https://github.com/a2stuff/a2d/blob/master/desktop/desktop_main.s#L15550

But additionally, if creating an icon for a device fails with DEVICE_NOT_CONNECTED it is removed:

https://github.com/a2stuff/a2d/blob/master/desktop/desktop_main.s#L16174

And, for some reason, SmartPort devices mapped to Slot 2 get special treatment:

https://github.com/a2stuff/a2d/blob/master/desktop/desktop_main.s#L15692

Any other changes/fixes to P8 that would help A2D?

Open ended question...

• As implied above, "determine device type" e.g. using the SmartPort table
• And along those lines, determining whether or not is a smartport device is pesky. An MLI call?
• Or really... anything relating to SmartPort usage could be simplified; ideally MLI calls would cover most of the SP usage: "is there a disk in the drive", "eject disk", "check status"... I think that's it. But even just an MLI call to get SP dispatch address (or fail) would be nice.
• Format/Erase require a chunk of code. Probably not room in P8. Those live in an overlay anyway
• Cracking datetime fields into minute/hour/day/month/year would be handy code to be able to reuse (new MLI call?)

[inexorabletash]

Correctly following https://prodos8.com/docs/technote/21/ would a good initial patch here - stop using the low nibble of the unit_num at all, but continue to distinguish the common drive types (Disk II, RAM, etc).

[inexorabletash]

Hmm, that's actually mostly done. The low nibble appears to be used only for the Disk II case which is redundantly handled later anyway.

[inexorabletash]

Hmm part deux: distinguishing non-$CnXX drivers will still require heuristics, e.g. RAMdisk at $FF00 and Disk II at $D000. I guess we trust the SSS bits at that point, ignore slot 3, and use firmware bytes from that point.

[inexorabletash]

For posterity: updating UNIT_NUM_MASK for a P8-2.5-specific build will be necessary. This is 11110000 to mask off DSSS, for a variety of reasons:

• Filling DRIVER_UNIT_NUMBER before a driver call
• Preparing params for an ON_LINE call
• Comparing against DEVNUM
• Looking up a driver address in DEVADR (mask then LSR 3x)
• Extracting the slot and drive (high bits are DSSS)

Some of these should "just work" if the mask is changed to 11110011 or 11111111, since presumably the APIs (driver, ON_LINE, DEVNUM) will consume the new form, and DEVADR lookups can just throw away the low bits.