Найдены 8791 тактов на вызов блита: uint16_t габарит в pop_blit_b

Точки на цепочку вызовов (libbgi живёт в резиденте W1, адреса однозначны —
пересборка не нужна) разложили постоянные накладные блита:

  pop_blit_b ДО вызова ядра ....... 6 683   <- НАШ код, 77% накладных
  gfx_blit_noclip + _bgi_begin
    + _gfx_blit_sprite_noclip ..... 1 938
  пролог _bgi_blit_rows_raw ....... 457
  строчный цикл ................... 389/строку  (= 198 + 5,96*32, сходится
                                                 с регрессией)
  эпилог + _bgi_end + возврат ..... 1 355
  «вне цикла» ..................... 8 725 при ЛЮБОЙ высоте (h=9..60)

Причина в pop_blit_b, подтверждена чтением .asm: `w`/`h` объявлены
uint16_t, 16-битные значения не влезли в регистры, и SDCC увёл функцию в
14-байтовый стековый кадр (`ld iy,#-14 / add iy,sp / ld sp,iy`), после чего
`w = img[0] | (img[1] << 8)` развернулось в ДВА ДЕСЯТКА IX-относительных
пересылок между ячейками -7..-13 кадра.

Правка: габарит читается БАЙТАМИ.  Корректно по построению — обе ветки и
так требовали w<256 && h<256 (эти проверки теперь убраны как тождественные),
а кадры атласов не крупнее 32x63; формат .atl допускает больше, такой кадр
уходит на общий путь (blit_b_oversize).

Замер A/B на той же детерминированной сцене, те же выборки:
  gfx_blit_noclip  13 679 -> 11 530  (-16%)
  blit_b_clip      18 853 -> 15 340  (-19%)
Стековый кадр 14 -> 6 байт, _CODE -42 Б.  Тайл ~107 000 -> ~95 000.

Все 8 наборов tests-host проходят, комната 23 в MAME рисуется корректно.

Плюс TASKS_OPEN.md: OPT-BLIT — руководство на следующую сессию (где ещё
uint16->uint8, как искать IX-спиллы по asm, что НЕ делать, и грабли с
несколькими экземплярами MAME на один error.log).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

applications/PoP/roomtest/TASKS_OPEN.md

@@ -923,3 +923,86 @@ HP/минуты, номера «особых» комнат и уровней (
   `../docs/ideas_backlog.md` (оба дают доли процента кадра).
 - **OPT-1** (хирургический редрой шва) — решено НЕ делать, стоимость
   транзиентная; разбор в [`BUGS_CLOSED.md`](BUGS_CLOSED.md).
+
+---
+
+## OPT-BLIT — цена отрисовки: чистка кодогена (СЛЕДУЮЩАЯ СЕССИЯ)
+
+Открыто 2026-08-13 по итогам разбора зелёного блока.  Контекст и все замеры
+— в memory `blit_cost_model` и `sdcc_z80_stack_locals_hot_loop`, протокол
+разбора — в коммитах `f89b7dd` / `b27b313` / этом.
+
+**Что уже сделано и чем это подтверждено.**  Цена блита разложена регрессией
+по 339 замерам: `такты = 8791 + 198,2*h + 5,96*(w*h)` (такты MAME = системный
+клок ~21,5 МГц, НЕ такты Z80 — растровый кадр 430 000).  Байт на пределе
+железа (через акселератор дважды по 3 такта), строка ~198, а вот 8 791 на
+ВЫЗОВ оказались нашим кодогеном: `pop_blit_b` держал `w`/`h` как `uint16_t`,
+из-за чего вся функция уезжала в 14-байтовый стековый кадр и `w = img[0] |
+(img[1] << 8)` разворачивалось в два десятка IX-относительных пересылок.
+После перехода на байтовый габарит: noclip 13 679 -> 11 530 (-16%),
+клипованный 18 853 -> 15 340 (-19%), `_CODE` -42 Б.
+
+### а) Где ещё `uint16_t` можно сделать `uint8_t`
+
+Габариты спрайтов и всё, что из них считается.  Признак: значение заведомо
+<= 255, но объявлено 16-битным «на всякий случай», и живёт в горячем пути.
+Начинать с:
+- `blit_b_clip` (`pop_tile.c`) — `dw`/`dh`/`sx`/`sy` объявлены `int`, хотя
+  ядра принимают `uint8_t`; это ВТОРОЙ по частоте путь (33% блитов).
+- `pop_cd_touch` / `cd_cols_of` — четыре `int`-аргумента на вызов.
+- `_gfx_blit_sprite_noclip` и обёртки libbgi: `stride` уже `uint16_t`, а
+  `w`/`h` — `uint8_t`; проверить, не расширяются ли они обратно у вызывающих.
+- Кандидаты в `pop_room.c`/`pop_bg.c`: локальные `int x, dby, dmy` в
+  `draw_tile` — часть из них помещается в байт, но осторожно: координаты
+  бывают отрицательными.
+
+**Как проверять:** после каждой правки смотреть пролог функции в
+`.sprinter-cc-roomtest/*.asm` — исчез ли `ld iy,#-N / add iy,sp / ld sp,iy`
+и сколько осталось `-N (ix)` в теле.
+
+### б) Проход по asm за неоптимальным IX-доступом
+
+Механическая проверка, даёт больше всего за единицу усилий:
+
+```
+grep -c "(ix)" .sprinter-cc-roomtest/*.asm          # где сгущается
+grep -n "ld iy, #-" .sprinter-cc-roomtest/*.asm     # крупные стековые кадры
+grep -n "pop.*\n.*pop.*\n.*push" ...                # чтение спилла через стек
+```
+
+Признаки беды (все три встречались сегодня): пролог с `iy`-кадром больше
+~6 байт; пары `pop bc / pop hl / push hl / push bc` в теле цикла (SDCC
+читает спиленный указатель через стек вместо `ld l,-N(ix)`); повторный
+пересчёт адреса `arr[i]` под каждое поле структуры.
+
+Приоритет по частоте вызова: `pop_blit_b` (сделан) -> `blit_b_clip` ->
+`pop_cd_touch` -> `draw_tile` -> `pop_redraw_needed`.
+
+### Что НЕ делать (проверено сегодня, отрицательный результат)
+
+- **Не откладывать запекание на другой кадр.**  Запекание пишет ОЗУ-копию
+  фона, из которой восстанавливает `heal`; отложенное даёт призрак плиты на
+  месте дыры.  Идея «бюджет одного запекания на кадр» снята.
+- **Не ускорять передачу пикселей** — она на пределе железа (3+3 такта на
+  байт), см. модель выше.
+- **Не искать проблему в W3-скобке** (`_bgi_begin`/`_bgi_end` — по пять
+  инструкций) и не списывать разброс на прерывания (внутри размерной
+  группы разброс 3 такта, код прямолинейный).
+
+### Хвосты этой сессии
+
+- Пакетная пометка `pop_cd_touch` (`pop_cd_batch_begin/end`, скобка в
+  `draw_tile`) — сделана, но выигрыш замером НЕ подтверждён: в захваченных
+  кадрах скобка не срабатывала (блиты шли из холодной отрисовки комнаты).
+  Переснять на кадрах ЗАПЕКАНИЯ.
+- Снять временную оснастку: `pop_dbg_m9..m16`, `pop_dbg_b1..b6`,
+  `pop_dbg_wh`, `pop_dbg_kind`, `pop_dbg_rdmax*`, `mame/v306/run_bridge_log.sh`.
+- Цель по кадру не достигнута: зелёный пик был 792 012 при цели 400 000.
+  После сегодняшних правок не перемерян — начать сессию с контрольного
+  замера, а не с новых правок.
+
+**ГРАБЛИ (стоили сегодня часа):** проверять, что запущен РОВНО ОДИН MAME
+(`pgrep -f mame.arm | wc -l`) — несколько экземпляров пишут в один
+`error.log`, мост говорит с одним, замеры собираются с другого, и точки
+«не срабатывают».  И не обрезать `error.log`, пока MAME его держит: она
+пишет по старому смещению, в начале остаётся дыра из нулей.