This feels like we're mostly done. The card fixed, the architecture understood, and we've pushed past limits of the original intended system pretty far already. But can we go further?

Yes. Yes, we can.

Let's start with the logical swap. In theory, if I had two ProFile hard drives I could boot off of one, swap the cable to the other, and read it just fine. There's no hard drive cache for us to defeat; we'd just have to chance that the electrical swap didn't accidentally fry anything. (Yes, that's a real possibility; I would definitely not perform this swap if I were you. But theoretically it's possible.)

Yes, I built it - specifically for ProDOS, it's possible to hot-swap volumes. And something more that I'll save for the end.

When thinking about whether or not this is possible, the first question is - what is the interface that allows us to do this? The BMOW FloppyEmu does the same, when you press buttons on its screen; but the current emulator has no buttons nor screen, nor do I want it to have that complexity. My first thought was that maybe we could build a new command to pass through to the emulator. It has a simple command byte structure - 00 for read, and so on; perhaps I could add some magical $ED (mnumonic for "eject disk") command that the emulator would honor, and be able to do something with. But the ProFile ROM defeats this. For us to send that command, I'd either have to write a complex program that directly drove the card, or I'd have to write a replacement ROM. Neither of those sounded very appealing (but both very possible).

Instead, I opted for a bit of modern trickery: knocking.

A ProDOS volume is, at most, $FFFF blocks (16-bit); where the ROM turns anything $FF00 or over into $FFFFxx on its assumption that you're asking for some sort of control block data. So I built a pattern: if you read the four blocks $FF41 $FF32 $FF45 $FF44 in that sequence, over a short time, the emulator notices that it happens and triggers ... some behavior. This is safe for a physical ProFile drive - it should calmly return I/O out-of-range errors. And it's unlikely that someone will ask for those four specific blocks from an arbitrary hard drive image (although it is possible, and if it were to happen, I could extend the knock sequence). A little bit of assembly...

kloop:  (re-point BUFL/BUFH to INFOBUF)
        lda ktab,x              ; $41 $32 $45 $44
        sta BLKL
        jsr drvcall             ; errors ignored: a real drive refuses these
        ... x4

        (re-point) lda #$C0 / sta BLKL
        jsr drvcall             ; info block
        bcs nodev
        lda INFOBUF+4
        cmp #$A5                ; the emulator's signature byte
        bne nodev

        lda #$C1 / sta BLKL     ; fetch the boot blob...
        lda #$00 / sta BUFL
        lda #$08 / sta BUFH     ; ...to $0800, where the ROM would have put block 0
        jsr drvcall
        bcs nodev
        ldx unitsv              ; X = slot*16, the boot-block entry convention
        jmp $0801               ; and enter it exactly as a boot would

... performs the knock, checks that the returned data looks like it should, and then runs the same picker menu that the bootloader uses. Boom - in-OS, runtime, re-selection of what drive is connected.

That's great if we're doing it by hand, but the actual use case I have is: moving files between two images. And to do that, it needs to be automated in some way. ProDOS really isn't command-line-ish, but how close can we get?

This is an excerpt of PICK, a binary that performs the knock, transfers file names from the emulator as data blocks, prints them onscreen, takes input to choose one of them, and then performs the swap.

After the knock, the info block ($FFC0) gives a count; and each catalog page ($FF80 + (idx>>3)) is an ordinary 512-byte block payload with 64-byte records. Those records were cached by the emulator at its startup, so there's no extra overhead; it's just data transfer couched in special terms, overloading block numbers near the end of the device within a short time frame. Wait too long and you get the normal disk block instead.

Great; I can now load something from one volume, use a command to swap to another volume, and save it manually again. Works, but it's not exactly automatic. I'd much prefer that.

This one is really the icing on the cake.

ProDOS has extensible drivers, right? And it allows SmartPort drives to do seemingly impossible things by assuming the identity for a volume based on a slot number that has no drive on it. And the theory I had is sound: it *is* possible to create a driver that registers two different volumes with ProDOS - with overriden names "/D1" and "/D2" for clarity - attach different images to each, and then, behind the scenes, swap which we're talking to dynamically.

The drive name override is done by hijacking reads of the master volume information block and rewriting it on the fly; safe, only because the driver is ProDOS-specific as is the behavior. The selector, as far as ProDOS is concerned, is a drive choice. With the card in slot 5, /D1 is S5,D1 and /D2 is S5,D2.

This works as an Applesoft BASIC-proven interface. Using it in other contexts is possible, but keeping the driver protected and resident is sort of a challenge; I'm sure it's a nut that can be cracked application-by-application, and whether or not there's a better way to register the driver in memory space that won't be eaten by a program is a problem to be solved later.

The important thing is that I can copy my files between two volumes now as I like.