Posted By
TLC
on 2021-06-03
10:13:47
|  Re: Let’s JoyTest! :)
@BSZ it looks like a case of perfect match so far, doesn't it? 
@crock Sure!
TL;DR: probably, the most convenient method is to misuse the TED idle fetches to supply the joystick selector bits. A.k.a.:
sei
sta $ff3f
lda #$d2
sta $ff13
lda #*selector byte* ; usually $fb or $fd
sta $ffff
*** wait until the next statement runs in a TED idle fetch period, like, in the vertical border, also avoiding memory refresh cycles ***
lda $ff08 ; you got the joystick's state byte
...
Explanation:
The TED keyboard latch becomes "transparent" when it's damaged, at least that's what we have thought. Apparently, that's not the entire truth. As it looks, the TED keyboard latch is designed in a way that it'd do a port latching in every bus cycles (i.e. in every CPU double clock cycles, or, twice in every single clock cycles), but this operation is inhibited, and only effectively done when the $ff08 register is written. With a damaged port, this inhibition is "gone". Using an oscilloscope, it looks evident that a "bad" TED keyboard port in fact samples the K0-K7 inputs once in every bus cycles, regardless to writing $ff08 or any other operation done. The point here is that the port doesn't become "transparent" in the true sense, sampling is still done in every bus cycles. It's known from other MOS port designs (including the 8501 CPU port), that port input sampling is typically done at least one bus cycle before a read operation can read this particular value from the input register. In the case of the "bad" TED, that means that the value read from $ff08, is always sampled one bus cycle _prior_ to reading $ff08. With the joystick selector bits having to be supplied at the time the TED samples the keyboard port, this means that the selector byte is in fact the byte, that happens to be on the data bus one bus cycle prior to reading $ff08. This bus cycle is either performed by the CPU (in double clock mode), or the TED (in a single clock mode). For a deterministic result, a deterministic byte must be "supplied" at the right time, i.e. in the bus cycle prior to reading $ff08. For that, as said, probably the most convenient way is to switch to single clock mode, write the "selector" byte to $ffff (from where the TED idle fetches are done), wait until the TED performs idle fetches, and read $ff08. For a counter-test, I have also created code that performed the read in double clock mode (having the CPU read a pre-set byte before it performed the read from $ff08... it used a jmp ($ff07), with $ff07 set-up purposely), but that method is probably not convenient to use in practice.
The only remaining question for me, is how (on Earth...) ESD only typically breaks the latch "inhibition" feature, not the port inputs. Surely haven't seen anything similar before.
|
