P77 picks up the thread from P76. Batching input made the Tetris demo playable, but the chip still only learned about input when the game tick polled the FIFO. Today we wired the FIFO to machine external interrupt and proved the bare-metal runtime can take that trap while AtomVM is running.
The hardware side added an input IRQ control register at 0x10001010.
Bit 0 enables the source. Bit 1 acks and disables it. The source is
level-like enough to catch queued input, but the handler can shut it off
so a nonempty FIFO does not retrap forever.
The runtime side added a small M-mode trap handler path for cause
0x8000000b. It saves a few caller-scratch registers through
mscratch, increments p77_input_irq_count, records
p77_input_irq_seen, writes the MMIO ack/disable bit, restores
registers, and returns with mret.
AtomVM still drains input from the game tick with chip:input_events/0.
That NIF now re-enables the IRQ source after draining the FIFO. This is
not yet a real scheduler wakeup or Erlang event-source port, but the
low-level interrupt path is no longer theoretical.
Verification:
cd projects/77_atomvm_input_irq/test
make all
make verilator-run-input-smokeThe passing smoke delivered six host events, drained them as one batch,
reported input irq count: 1, returned FIFO status to 0, rendered one
frame, and halted PASS after 14,774,406 post-load cycles.
Honest status: RTL simulation only. AtomVM scheduler wakeup from input IRQ was NOT RUN. F/D compliance was NOT RUN. LibreLane hardening was NOT RUN.