I've been using CAT.DOCTOR to sort the root directory on my ProDOS floppy boot volume, to specify which particular system files are loaded.
However, CAT.DOCTOR appears to be incompatible with Dan's Apple2Card. I'm not in front of my Franklin at the moment, so I can't report the exact error that it throws when I try to read in the root directory -- but it does bomb out.
Before I start reverse-engineering CAT.DOCTOR, is there a workalike that I can test to see if it works?
Strange, I can't see any problems running CAT.DOCTOR that comes with ProDOS 2.4.2 and the Dan ][ Controller:
CATDoctor.jpg
Hmmm. I'm getting a "MLI Error: $46 file not found" for all operations the first time, and for subsequent attempts it's error $00.
For what it's worth, BITSY.BOOT doesn't appear to work when booted from the Dan ][ either. Perhaps there's something slightly wrong with my card (although everything beside those two appears to work okay). I'm not running it in a //e; it's in a Franklin so all bets are off.
Thanks for the input :)
BITSY.BOOT works for me perfectly too. (Tested with the Dan ][ Controller in slot 6 and the Apple II floppy drive in slot 5.)
Thanks to a lengthy hospital stay and recovery, I finally got around to debugging the issue with BITSY.BOOT not working on the Franklin (and probably anything that doesn't have open-and-closed-Apple keys).
The problem is in the keypress parsing loop. It's checking for the open-Apple key being pressed down, branching to the exit-BITSY.BOOT routine if it is, and then parsing for boot volume if it is not.
The check for O-A key being held down appears to be always true if nothing is plugged into the game port on the Franklin (and, thus, pre-//e machines).
The fix is to either NOP out "bit RDBTN0 / bmi QUIT" (which completely disables O-A, not desirable but functional) or move that to the end of the keypress loop.
I've forwarded this finding to John Brooks, and have put source code and binaries at https://codeberg.org/cryu/ProDOS_Snippits
Good work! ProDOS on a pre-//e or on clones is too often not considered!
Is there some opportunity to use a joystick for button0 or some hack to the joystick socket so everything works?
Yes, plugging in a joystick or adding pulldown resistors to the game port will achieve the same goal, as the root cause is that unconnected TTL inputs are logic high.
However, adding hardware to address what is clearly a software issue is distasteful.
Re-ordering the logic (and, man, I really wish the AppleFritter comment engine would let me use <code></code> or the markdown/BBCode equivalent without frying, so that I could paste the routine here) is much more elegant, does the right thing regarding O-A, uses MACHID properly, is actually one byte shorter than the original, and doesn't require any hardware changes to work on pre-//e machines.
But, hey, to each their own :)