AppleWin
AppleWin copied to clipboard
$C010 should not read the keyboard latch on Apple II and Apple II+
$C010 should not read the keyboard latch on Apple II and Apple II+. On these early Apple II models, reading the $C01x range asserts nothing on the data bus. AppleWin's Apple II acts like an Apple //e and reads the keyboard latch for the $C01x range (minus the D7 flags). It should be reading a floating bus value.
Sather illustrates this on page 5-10 of UtA2. https://archive.org/details/understanding_the_apple_ii/page/n101/mode/2up
300: AD 10 C0 20 ED FD 4C 00 03 N 300G
The above should fill the screen with "random" video feedback not keyboard latch values.
Expected:
Actual:
Thanks (and it's amazing how long some of these bugs go unnoticed!)
I only noticed it because my own Apple //e emulation was not reading the keyboard latch at $C01x which prevented Castle Dain from starting a keyboard game. I never knew you could read the latch that way. Sather mentions it in the text of UtA2E but his schematics don't seem to show it (or I have been unable to find it. EDIT: I did eventually spot it in a schematic, and in at least two tables, in addition to the text). I almost always go to AppleWin to test things before pulling out the real hardware, and that's when I noticed the problem.
This also revealed a bug in Castle Dain when running on an Apple II. Because it is reading vapor at $C010, there is a non-zero chance it will interpret a "K" on the screen as a keypress, and spontaneously start a keyboard game (which ironically is not supported on those machines).
Hmm, this new demo (Five Finger Punch's "THERE-IS-NO-i-IN-APPLE") uses some floating-bus video sync code reading $C010: https://www.pouet.net/prod.php?which=95900
This is our demo for Apple II europlus with 48KB memory and PAL expansion card.
...and it doesn't work (it just hangs).
If I change the 5x CMP C010
to CMP C051
then it starts working (until it hits another video sync with $C010).
Closing, as this is fixed in AppleWin 1.30.18.0.