AnachronautandClaude Opus 5
df50c2f0f8
0x64 counted only the RECORDED pads. So a controller plugged into Voyager reported its buttons perfectly, and every game asking whether there was a controller was told no - which is exactly what Lunar Porter asked, once, at startup, before falling back to the console for the rest of the run. The cause is worth naming: a front end calls padSet every frame for every pad, so "held nothing" is the commonest thing it says and cannot also mean "there is no pad here". Connected is said separately now. Pad nought is always there behind a window, because the keyboard is behind it - which is the useful answer rather than the literal one. And Pad.asm, which is what should have existed before any of that guessing began. It prints a line whenever a pad changes, and tells apart the three states that look identical from inside a game that will not respond: one nobody noticed, one mapped to nothing, and a mapping that is wrong. WHY A PROGRAM AND NOT A PRINT IN THE FRONT END: because the question is what the MACHINE can see. A front end reporting what it thinks it is sending answers a different question, and the gap between those two is the whole of this bug. It also found that osPrintNumber takes A as the HIGH half - the same way round as the shift register and every other pair here, and not what a byte in A wants. Every value came out 256 times too big. Gravity is one frame in ten rather than six. The ratio between thrust and gravity is the feel; how often the tick comes round is how fast that feel arrives, and one in six was still touchy. Same lander, more time to think. And the verdict waits for a key. It printed and left immediately, taking the screen with it - so the one thing worth seeing, the lander sitting on the ground it had just reached, was gone before it could be looked at. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E2JrLzFvuFX9fgi1LDRjrW
101 lines
3.5 KiB
C
101 lines
3.5 KiB
C
// pad.c
|
|
// Game controllers for the Voyager.
|
|
// Written by Anachronaut
|
|
|
|
#include "pad.h"
|
|
#include "video.h"
|
|
|
|
// What each pad is holding, and where each one gets it from.
|
|
static uint8_t held[PAD_COUNT];
|
|
static FILE *recorded[PAD_COUNT];
|
|
static uint8_t live[PAD_COUNT];
|
|
static int connected[PAD_COUNT];
|
|
|
|
// ---- The frame the recordings advance on ----
|
|
//
|
|
// The screen's frame, and it is the same one on purpose: a game reads its pad once a frame
|
|
// because that is when it draws, so a byte a frame is a byte a poll for anything written the
|
|
// ordinary way - without making it a byte a READ, which would answer a game that asked twice
|
|
// differently from one that asked once.
|
|
//
|
|
// On the machine's clock, so a recording plays back the same over the same cycles however
|
|
// fast the host ran.
|
|
static unsigned long lastFrame;
|
|
static int started;
|
|
|
|
void padReset(void) {
|
|
for (int n = 0; n < PAD_COUNT; n++) {
|
|
held[n] = 0;
|
|
live[n] = 0;
|
|
connected[n] = 0;
|
|
// The files are NOT closed or forgotten. They were named on the command line and
|
|
// outlive a reset, the same as a disk image does: a machine that restarted itself
|
|
// and lost its controllers would be a strange thing to debug.
|
|
}
|
|
lastFrame = 0;
|
|
started = 0;
|
|
}
|
|
|
|
void padFromFile(int which, FILE *file) {
|
|
if (which < 0 || which >= PAD_COUNT) {
|
|
return;
|
|
}
|
|
recorded[which] = file;
|
|
}
|
|
|
|
void padSet(int which, int isConnected, uint8_t heldNow) {
|
|
if (which < 0 || which >= PAD_COUNT) {
|
|
return;
|
|
}
|
|
connected[which] = isConnected;
|
|
live[which] = heldNow;
|
|
}
|
|
|
|
void padTick(unsigned long now) {
|
|
// The first tick sets the clock rather than counting a frame from nought, or a machine
|
|
// that started late would take a run of bytes all at once.
|
|
if (!started) {
|
|
lastFrame = now;
|
|
started = 1;
|
|
}
|
|
while (now - lastFrame >= VIDEO_FRAME_CYCLES) {
|
|
lastFrame += VIDEO_FRAME_CYCLES;
|
|
for (int n = 0; n < PAD_COUNT; n++) {
|
|
if (recorded[n] == NULL) {
|
|
continue;
|
|
}
|
|
const int byte = fgetc(recorded[n]);
|
|
// ---- The end of a recording is nothing held ----
|
|
//
|
|
// Not a pad that vanishes and not the last frame repeating for ever. A recording
|
|
// that ran out and left a direction pressed would send whatever it was driving
|
|
// off the edge of the world long after the test meant to stop.
|
|
held[n] = (byte == EOF) ? 0 : (uint8_t)byte;
|
|
}
|
|
}
|
|
}
|
|
|
|
uint8_t padRead(uint8_t port) {
|
|
if (port == PAD_PRESENT) {
|
|
uint8_t there = 0;
|
|
for (int n = 0; n < PAD_COUNT; n++) {
|
|
// A recording is a pad, and so is anything the front end says is plugged in.
|
|
// Counting only the recordings meant this said nought on the one machine that
|
|
// has real controllers, which is the only machine where the answer matters.
|
|
if (recorded[n] != NULL || connected[n]) {
|
|
there |= (uint8_t)(1u << n);
|
|
}
|
|
}
|
|
return there;
|
|
}
|
|
const int which = port - PORT_PAD;
|
|
if (which < 0 || which >= PAD_COUNT) {
|
|
// Everything else in the block is reserved and reads as nothing, which is what a
|
|
// port block being kept for later should do.
|
|
return 0;
|
|
}
|
|
// A recording wins over a live pad, so a test is not at the mercy of whatever somebody
|
|
// is leaning on while it runs.
|
|
return (recorded[which] != NULL) ? held[which] : live[which];
|
|
}
|