ProDOS8 2.5.0 alpha6 not working

[tomcw]

John Brooks gave me a heads up about this issue:

There have been some compatibility problems reported with Applewin running the new P8 2.5 alpha. The problem appears to be specific to Applewin since P8 is being tested on real hardware and the various Mac-based emulators without problem.

Can you take a look, or pass it on to someone who can investigate?

Bug report:
ProDOS-8/ProDOS8-Testing#26

P8 2.5.0a6 info & disk image:
https://prodos8.com/releases/prodos-25/

[tomcw]

Hi Nick (@sicklittlemonkey ) you are going to love this one...

NB. P8-2.5.0 only runs on 65C02/816, so not 6502.
EDIT: P8-2.5.0 runs on all: 6502/65C02/816.

There is this code to enable LC write:

$bfc2: inc $c08b

And on this Twitter post here, you and John discussed this false read behaviour for RMW and RMW,X!

We did discuss supporting false-reads (for 6502) in #404, but decide not to do this, as (at the time) nothing was exploiting this behaviour... well now it is.

[sicklittlemonkey]

Ha, nice. Targeting the real hardware is fair game!

[tomcw]

I got this clarification from John...

My skype post was about using the 6502 & 65816 false-read (cmp $c08b,x) to trigger LC write mode, though that technique did not work on 65c02 which omits false reads for load ops.

But with P8 2.5 I am using a plain absolute addressing mode INC read-modify-write which (on all CPUs) reads $C08B one time which sets LC pre-write, then accesses $C08B a second time doing the store. The 2nd access to an odd $C08x address switches the LC RAM into write mode since the first read access had already set pre-write mode. Because the 2nd access was a store, it also turns off the pre-write mode, but since writes have now been enabled, pre-write is no longer relevant.

I don't know why the INC $C08x method wasn't used by Woz, etc back in the day. It is smaller and faster than 2x BIT $C08B. Sather mentions that a write access to an odd $C08x address with pre-write enabled will switch into write mode, but he does not include any read-modify-write instructions in his examples.

I've tested INC $C08B on real IIGS and real II+ hardware and it correctly enables LC write mode on both.

I haven't gotten around to testing it on a real IIc or 65c02 IIe, so I suppose there is a chance it would not work correctly there, but ABS-addressing read-modify-write is the same on all 3 CPUs as far as I know (unlike the false-read cycle which is absent on 65c02 indexed loads).

I just checked INC $C08B on a 65c02 Platinum IIe. It works fine there too.

[tomcw]

So by extension that means all other common (ie. exist for all 6502/65C02/618) RMW opcodes will behave the same: ASL, DEC, LSR, ROL, ROR.

Also TSB/TRB on 65c02 & 65802/65816.

[tomcw]

A filthy fix(!), but it's localised to just the LC code, so emulation speed won't be affected. Whereas a more generalised fix in the 6502 emulation code would cost in speed, and mean a much greater engineering effort to implement & test.

[tomcw]

NB. An Apple II/II+ with a Saturn card (in slot-0) already works without any change, because the pre-write mode isn't predicated with a read-access (ie. it can be set on a write too).

[tomcw]

I'm not 100% convince by the 6502 version of INC <abs>.
Sather (UTAIIe 5-23) says:

• "PRE-WRITE and WRITE can be thought of as a write counter which counts odd read accesses in the $C08X range."
• "if the write counter reaches the count of 2, writing to high RAM becomes enabled".

Sather (UTAIIe 4-23) says ASL $5772 (row 17) does this:

• R<abs>, W<abs>, W<abs> ; cycles 4-6

NB. the 65C02 version (UTAIIe 4-27) is fine as it does:

• R<abs>, R<abs>, W<abs> ; cycles 4-6

On UTAIIe 4-25, Sather describes INC $C081,X (X=0) as being "more cute than valuable".

I will test on a 6502...

[tomcw]

OK, I tested on my real hardware: an unenhanced //e 6502 (not 65C02), and this fails with a BRK:

300:ad 80 c0 ad 0 d0 ee 0 d0 cd 0 d0 d0 12
30e:ee 8b c0 ad 0 d0 ee 0 d0 cd 0 d0 f0 8
31c:2c 81 c0 60 2c 81 c0 0 2c 81 c0 0

0300-   AD 80 C0    LDA   $C080
0303-   AD 00 D0    LDA   $D000
0306-   EE 00 D0    INC   $D000
0309-   CD 00 D0    CMP   $D000
030C-   D0 12       BNE   $0320
030E-   EE 8B C0    INC   $C08B
0311-   AD 00 D0    LDA   $D000
0314-   EE 00 D0    INC   $D000
0317-   CD 00 D0    CMP   $D000
031A-   F0 08       BEQ   $0324
031C-   2C 81 C0    BIT   $C081
031F-   60          RTS   
0320-   2C 81 C0    BIT   $C081
0323-   00          BRK   
0324-   2C 81 C0    BIT   $C081
0327-   00          BRK   

So (unless my code is wrong) INC $C08B doesn't write enable the LC for a 6502.

[tomcw]

Testing ProDOS_2_5_a6_143k.po on my real unenhanced //e 6502, I consistently get this hang:

              Apple ][



PRODOS ERR=4
..

NB. I also get the same ERR=4 with ProDOS_2_5_a4_143k.po.

[tomcw]

John (and various people on Slack) confirmed INC $C08B doesn't write-enable the LC for 6502 machines.

He's now looking at INC $C08B,X (X=0), which is #404.

[sicklittlemonkey]

It's 5 years since I looked at this stuff (for that old c.s.a2 thread), and there are still nooks unexplored till now! Looks like INC $C083,X is a winner, but I wonder if he can still win in bytes if X has to be 0. That's sometimes painful. Cheers, Nick.

[tomcw]

Closing as 1.29.3 is released here.

[tomcw]

NB. The P8-2.5.0-alpha6 & AppleWin status is:

• Enhanced //e (65C02): now works
• //e or II+ or II (6502) with Apple LC: hangs during boot
• II+ or II (6502) with Saturn "LC": works

I'm expecting John to release a new P8-2.5.0 that fixes the issue with the 6502-based machines.