ProDOS directory sorter (not CAT.DOCTOR)?

8 posts / 0 new
Last post
Offline
Last seen: 4 months 1 day ago
Joined: Feb 6 2021 - 03:34
Posts: 55
ProDOS directory sorter (not CAT.DOCTOR)?

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?

CVT
CVT's picture
Offline
Last seen: 3 hours 13 min ago
Joined: Aug 9 2022 - 00:48
Posts: 954
Strange, I can't see any

Strange, I can't see any problems running CAT.DOCTOR that comes with ProDOS 2.4.2 and the Dan ][ Controller:

 

Offline
Last seen: 4 months 1 day ago
Joined: Feb 6 2021 - 03:34
Posts: 55
Hmmm.  I'm getting a "MLI

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

CVT
CVT's picture
Offline
Last seen: 3 hours 13 min ago
Joined: Aug 9 2022 - 00:48
Posts: 954
BITSY.BOOT works for me

BITSY.BOOT works for me perfectly too. (Tested with the Dan ][ Controller in slot 6 and the Apple II floppy drive in slot 5.)

Offline
Last seen: 4 months 1 day ago
Joined: Feb 6 2021 - 03:34
Posts: 55
Thanks to a lengthy hospital

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

Offline
Last seen: 2 hours 42 min ago
Joined: Jul 5 2018 - 09:44
Posts: 2473
cryu wrote: Thanks to a
cryu wrote: 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

Good work!  ProDOS on a pre-//e or on clones is too often not considered!

 

 

 

Offline
Last seen: 3 hours 7 min ago
Joined: Nov 29 2020 - 19:48
Posts: 124
O-A key?

Is there some opportunity to use a joystick for button0 or some hack to the joystick socket so everything works?

Offline
Last seen: 4 months 1 day ago
Joined: Feb 6 2021 - 03:34
Posts: 55
Yes, plugging in a joystick

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

Log in or register to post comments