AnachronautandClaude Opus 5
fed1453e6e
The console says WHICH KEY WENT DOWN, which is the right shape for typing and the wrong one for playing. A game wants to know what is being held, this frame, possibly several things at once, and a stream of presses cannot say that: a key that is down and staying down sends nothing at all. Lunar Porter's thrust is a burn per press for exactly that reason. So a pad is its own device on ports 0x60 to 0x6F, reporting a LEVEL. One read gives every button at once, holding is the natural thing to express, two directions together cost nothing, and reading does not consume it - a game may ask twice in a frame and be told the same thing both times. Four of them, because a party is four. They cost a port each and nothing at all when unused. The directions are the low nibble so "which way" is an AND with 0x0F; the buttons are the high nibble for the same reason. 0x64 says which are really there, so a game can ask for a controller rather than sitting silent while somebody presses things at it. They never interrupt: a game polls once a frame because that is when it draws. KEY-UP ON THE CONSOLE WAS THE OTHER WAY TO DO THIS AND WAS REJECTED. A terminal hands over characters and can never report a key coming up however it is asked, so it would have been a thing that worked behind a window and silently did not down a wire. A separate device can honestly say it is not there. Voyager drives pad nought from the keyboard as well as from any real controller, OR-ed rather than chosen between, so a game written for a pad is playable on a machine with none and unplugging one mid-game does not leave somebody holding nothing. And a recorded path, which is what makes any of it testable: --pad names a file of one byte a frame, and the manifest has an eighth column for it. A BYTE A FRAME AND NOT A BYTE A READ - a level asked twice in one frame has to answer the same both times, and a file that advanced per read would depend on how the program happened to be written. Voyager's own tests run headless with nobody holding anything, so without this the device would be exercised only by somebody playing: the state the console's line editing was in when it broke twice in two days. 0x50 is the timer, not free. The block this went in was chosen after looking rather than before. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E2JrLzFvuFX9fgi1LDRjrW
52 lines
1.2 KiB
NASM
52 lines
1.2 KiB
NASM
; Asks the machine what its controllers are doing.
|
|
;
|
|
; A pad reports a LEVEL and not an event: one read gives every button at once, holding is the
|
|
; natural thing to say, and reading does not consume anything - so asking twice in a frame
|
|
; gives the same answer twice, which this checks by doing exactly that.
|
|
;
|
|
; The recording behind it is one byte a frame. It presses up, holds it a second frame, adds
|
|
; right, lets go of up, lets go of everything, then presses A and B together - which is the
|
|
; case a console's key-at-a-time stream cannot express at all.
|
|
;
|
|
; Written by Anachronaut
|
|
|
|
#Program
|
|
|
|
start:
|
|
INA 0x64
|
|
OUTA 0x00 ; Which pads are there: one bit each, so pad nought alone is 1.
|
|
RSTA
|
|
SETD.0 Count
|
|
STA.0
|
|
|
|
everyFrame:
|
|
INA 0x30
|
|
INIB 0x01
|
|
AND
|
|
BRQ everyFrame ; The frame the recording steps on.
|
|
|
|
INA 0x60
|
|
OUTA 0x00
|
|
; And again, without a frame in between. A level does not go away when it is looked at.
|
|
INA 0x60
|
|
OUTA 0x00
|
|
|
|
SETD.0 Count
|
|
LDA.0
|
|
INCA
|
|
STA.0
|
|
INIB 0d6
|
|
CCF
|
|
SUB
|
|
BNQ everyFrame
|
|
|
|
; A pad that is not there reads as nothing held, which is honest rather than an error.
|
|
INA 0x63
|
|
OUTA 0x00
|
|
HALT
|
|
|
|
#Data
|
|
|
|
Count:
|
|
0x00
|