fix: apple2/apple2e shift mod io value

[whscullin]

Shift mod I/O value was inverted:

Real hardware:
Platinum //e

Apple II with shift mod

Before:

After:

[SpecLad]

It seems that this will also invert the effect of the actual button 2 (m_gameio->sw2_r()). I think a more appropriate fix would be

Suggested change

	return ((m_gameio->sw2_r() || (m_kbspecial->read() & 0x06)) ? 0 : 0x80) | uFloatingBus7;
	return ((m_gameio->sw2_r() || !(m_kbspecial->read() & 0x06)) ? 0x80 : 0) | uFloatingBus7;

[whscullin]

It's possibly a little weird that it's checking pb2 at all, since the hardware is tied to the shift key - should that just be eliminated? There's not a lot of hardware that uses pb2 and the interaction of pb2 and a shift key mod could probably best be described as undefined?

[whscullin]

I guess if you were holding down the shift key and then pressed pb2 it might go back to high, so the existing logic is fine.

[arekkusu42]

@SpecLad, I thought so too at first. But:

• the default state of C063 is high (>127) which is different from PB0 and PB1. Apple's documentation is mostly useless here, as it only says things like "the appropriate game input is connected to bit 7 of the data bus" without specifying if that is high or low. But the //c Tech Ref (pg 463) explicitly mentions C063 in context of the shift-key mod and says "pressed is zero".
• Testing (via SWITCHES) shows that both C060 and C063 default to high bit ON, with or without a joystick attached (on a ][+, //e, and IIgs. On a //c, C060 high bit depends instead on the 40/80 switch, C063 is still high.)
• Sather's UTA2E Fig 7.2 shows pull-down resistors on PB0 and PB1, but not PB2.
• Good anecdotal confirmation of what's happening from respected source Michael J. Mahon.

So, I think the simpler fix of just inverting the end result of C063 to 0 : 0x80 is correct.

Note this also applies to C060, on ][, //e, IIgs (but not //c)! Testing shows improved results with cassette loading! (I don't have any tests for IIgs SW3 but Mahon says it applies there.)

[SpecLad]

@arekkusu42 Okay, makes sense. Does this mean that the values on line 486 (the non-Shift-key-mod branch) should be inverted as well?

[arekkusu42]

Yes. In the absence of the shift-key mod (the default state on all Apples other than the IIe Platinum) C063 depends only on PB2, and the default is high. In other words, PB2 (if you could locate a joystick that has that button, mine doesn't) works the same as the inverted mouse button on the //c.

[rb6502]

@arekkusu42 So $C060 should also be inverted?

[arekkusu42]

Yes, Sather describes the LM741 voltage inverting behavior in UTA2E 7-8. My testing here shows that this (surprisingly!) improves cassette LOAD behavior ("hi" quality WAVs that previously failed start working.) I will write up in notes for a new PR.

I am unsure how to propagate that cassette change to clones, though. tk3000 will get it (and I tested it improves the same way) but tk2000? apple3? apple1?

[rb6502]

apple3 doesn't have a cassette. apple1's cassette works somewhat differently and doesn't have issues reading tapes as far as I'm aware.

[whscullin]

Closing in favor of future @arekkusu42 PR

[whscullin]

See #14459