mirror of
https://git.k-space.ee/arti/vt1200.git
synced 2026-11-01 12:14:56 +02:00
arti
9139322892
Spec 8.3's hoist, and the 60 fps work showed it was the per-tile cost that mattered, not the per-frame one. Every tile_blit() call used to save 8 B registers, load B1/B3/B4/B7/B8/B9 and write 11 I/O registers (PSIZE, CONVSP, CONVDP, PMASK, the CONTROL read-modify- write and its read-back) -- all constants. The user's guide marks only SADDR and DADDR changed by PIXBLT, and the TMS34010 agent's reading of it confirms B1/B3 survive, so those two are the only ones a per-tile call has to reload. vram_tile.asm now exports tile_init_() (the constants, once per frame, called from paint_tiles/paint_delta) and a tile_blit_() that is setf, two pushes, two register loads, pixblt, two pops, rets. Measured on the real 140-tile deltas at a 60 fps send, same window, terminal's own status frames: before the hoist 162 accepted after the hoist 231 accepted (+43%) and the one-tile stream (where tile cost is nil) already runs at 60 fps with DINT: 600 frames sent at 59.8 fps, 579 accepted (96.5%), drops=0. Pixel verdicts unchanged: modes tiles, delta and replay all RESULT PASS with tile_check; 155 unit tests pass. What the remaining gap is, for the next reader: MAME's PIXBLT moves about 3.4 us per destination word (0.22 ms per 32x32 tile, measured from the accepted rate) against the unit's measured 0.40 us/word for FILL. A 140-tile delta is 8,960 words, i.e. ~30 ms of MAME CPU against a 16.7 ms frame -- so 60 fps for this content is bounded by the emulator's pixel engine, not by the design. Whether the unit can do it turns on the one number nobody has measured there: PIXBLT B,XY's per-word rate (spec 10, risk table).