In the README they're described as follows:
Code: Select all
000f serialRaw New raw serial read 0011 buttonState Edge-triggered and resettable input bits
serialRaw is the raw value of the 74HC595 shift register U39 as sampled 60 times per second. It reads 255 when idle or when there's no device connected. It reads an ASCII code when a key is pressed. Game controllers send byte values that are normally different from ASCII codes (but not always: the classic counterexample is that action button [A] is sent as 127, and that is also ASCII Delete).
The BabelFish software in Pluggy McPlugface normally sends ASCII codes 3 times in succession, so that even slower software doesn't have to miss a key while auto-repeat still works. It maps cursor keys to game controller bit patterns, and it sends those for as long as those keys are pressed down. BabelFish has a few more such tricks so that PS/2 keyboards not only work properly, but also act as a functional game controller replacement.
The game controller buttons are normally mapped to bits as follows:
- bit 0: buttonRight
- bit 1: buttonLeft
- bit 2: buttonDown
- bit 3: buttonUp
- bit 4: buttonStart
- bit 5: buttonSelect
- bit 6: buttonB
- bit 7: buttonA
First of all, buttonState typically follows serialRaw, but all the way back since ROM v1 it had an extra featue. [$0010] is an internal variable that hints at what's going on:
Code: Select all
0010 (serialLast) Previous serial read (used for edge detection)
- you detect a 0 bit, indicating a button was just pressed down
- you take your action for that button
- you reset only that bit to 1
- re-enter your I/O processing and handle the other bits
- even if that button is still pressed down, you see it as released until the next press down
New game controller types...
Second, and the main reason for posting this now: as of recently we're supporting a second type of game controller. These controllers look and feel exactly the same, except they have a different chip inside that sends different raw signals. The vastly oversimplified story is: to keep software compatible, the input handler recognises these game controllers automatically, and converts their values to the "old" values in buttonState. But it doesn't do that for serialRaw, because then keyboards wouldn't work anymore. And with that, the bits in serialRaw and buttonState don't have the same meaning anymore...
- If you want to process game controller buttons: look at buttonState: peek(17) or LD $11
- If you want to process ASCII input: look at serialRaw: peek(15) or LD $0f