mirror of
https://git.k-space.ee/arti/vt1200.git
synced 2026-11-01 12:14:56 +02:00
arti
8de6d94e84
Spec 8.9 decides the payload may kill the resident OS; this is the first half of that, and it is a rate fix as much as a robustness one. With the OS still ticking, the payload's loop is preempted and the machine accepts ~15 frames/s **whatever the payload size**: a 5-byte one-tile delta measured the same as a 140-tile one (195 frames in 13.4 s, MAME at 100% speed, frames_rx from the payload's own status frames). That is scheduling, not decode -- the loop itself runs ~20k iterations/s. VID_OWN_CPU (default 1) takes one DINT before the main loop and makes vid_eint_() a no-op, so nothing preempts the LANCE poll. Measured on the same one-tile stream: OS ticking (before) 15.0 fps accepted, 400 frames in 15.4 s DINT at startup 24.0 fps accepted, 385/400 frames, drops=0 and, paced differently, 31.5 fps with 387/400 -- the sender, not the terminal, is now the throttle (its socket blocks once the tap's drain rate is exceeded) Consequence stated where it is made: the OS's drivers stop being serviced, so its console and network stack are gone for good. The payload owns the machine once it takes the LANCE either way. The harness reaches the payload through the debugger, not the OS, so the replay modes are unaffected -- verified: modes tiles, delta and replay all RESULT PASS with their pixel checkers after the change. Set VID_OWN_CPU=0 at build time to reproduce the old burst-EINT behaviour for a comparison run.