SprPoP: звук мигания, равномерные часы, полоса HP после рестарта, надпись ждёт мелодию

Четыре правки прогона 2026-08-31.  Две ПРОВЕРЕНЫ пользователем в MAME
(звук мигания, порядок «мелодия -> надпись»), две ждут проверки — образ
собран.

ЗВУК МИГАНИЯ (проверено).  Упаковщик научился синтезировать ноты PC-
спикера в обычный сэмпл: заголовок с темпом, тройки «частота + длина»,
меандр на нашей частоте вывода.  Берём из нот ТОЛЬКО номера, которых нет
ни в оцифровке, ни среди мелодий, — иначе синтез перекрыл бы музыку,
которую мы играем из MUS/.  На поставке SDLPoP это ровно один номер: 38,
сигнал под мигание «Press Button»; 31, 34 и 42 там пустые заглушки.
Громкость по слуховой проверке снижена вдвое (44 -> 22): на полном
размахе сигнал перекрикивал игру.  EXE не меняется — раскладка читается с
диска, набор занял те же 9 страниц.

НАДПИСЬ ЖДЁТ МЕЛОДИЮ (проверено).  Порядок оригинала: ветка мёртвого
(seg006:1351) на седьмом шаге выходит, пока звук играет, и «Press Button»
появляется только после музыки смерти.  Чтобы ожидание не было
принудительным, три быстрых пути (Ctrl+A, обе быстрые загрузки, пункты
меню) музыку глушат — оригинал при Ctrl+A делает то же (seg000:0617).
Обычная кнопка во время мелодии не действует: она ответ НА надпись.

ЧАСЫ (ждёт проверки).  Тик стоит столько кадров ЛУЧА, сколько их в кадре
режима NORMAL, поэтому FAST/FASTEST больше не ускоряют время.  Считаем
ФАКТИЧЕСКИ прошедшие кадры луча, а не ожидаемый делитель: логический кадр
не всегда укладывается в бюджет, и часы «по делителю» шли рывками (первый
прогон это показал — «несколько секунд быстро, потом притормаживание»).
Вклад одного вызова ограничен, иначе пауза и меню прыгнули бы вперёд.
Четыре новых теста: NORMAL не сдвинулся ни на тик (и вне боя, и в бою),
FAST и FASTEST держат реальное время.

ПОЛОСА HP ПОСЛЕ Ctrl+A (ждёт проверки).  Корень: счётчик считает
СТРАНИЦЫ, а тратился по КАДРАМ — между двумя вызовами переворота может не
быть, и оба прохода уходили в одну страницу, вторая оставалась с
делениями прошлого боя.  Теперь проход тратится только при смене
gfx_get_draw_page().  Плюс полная чистка всей ширины при инвалидации:
старая полоса могла заходить под статус-текст, где щадящая чистка её не
трогала; текст сразу перезапрашивается.

Все 16 наборов host-тестов зелёные, check_bank_calls чист.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011MsUsEFAQfsjjQpJ7RtKVY

applications/SprPoP/docs/BUGS_OPEN.md

@@ -39,7 +39,7 @@
 | [PV-RENDER-BOUND](#pv-render-bound) | сцена с принцессой рисуется дороже бюджета: ~49 тиков/с вместо 60, музыка уезжает от картинки | производительность | **исправлено 2026-08-28**: кадр разложен на блоки по интервалу, удешевлять не понадобилось |
 | [MUS-LEFT-TEAR](#mus-left-tear) | `pop_mus_left` (16 бит, пишет прерывание) читается из главного цикла неатомарно — возможен ложный «трек кончился» | **потенциальный** | открыт: хазард показан рассуждением, в прогоне не проявился |
 | [CLIMB-VS-GUARD](#climb-vs-guard) | Кид подтягивается к стражу этажом выше: у нас удар засчитывается и убивает, в оригинале Кид просто срывается без урона; страж при этом способен провалиться сквозь пол вслед за Кидом | бой/физика | открыт: цепочка удара сверена — совпадает, расходятся входные данные (2026-08-31) |
-| [HP-BAR-RESTART](#hp-bar-restart) | после гибели и Ctrl+A на ОДНОЙ из двух страниц остаётся полоса HP по результатам боя | дабл-буфер/UI | открыт: разбор есть (2026-08-31) |
+| [HP-BAR-RESTART](#hp-bar-restart) | после гибели и Ctrl+A на ОДНОЙ из двух страниц остаётся полоса HP по результатам боя | дабл-буфер/UI | КОРЕНЬ НАЙДЕН, фикс есть, ждёт проверки (2026-08-31) |
 
 ---
 
@@ -1423,6 +1423,15 @@ Ctrl+A у нас — РЕСТАРТ УРОВНЯ (`sprpop_cold.c`, тот же
 середину, там и остаётся.  Полоса стража рисуется справа налево от 314 и
 при большом запасе HP заходит именно в эту незачищаемую зону.
 
+**КОРЕНЬ (2026-08-31).**  Счётчик считает СТРАНИЦЫ, но тратился по КАДРАМ,
+а это не одно и то же: между двумя вызовами отрисовки переворота может не
+быть, и оба прохода уходили в одну страницу — вторая оставалась с
+делениями прошлого боя.  Фикс: проход тратится только когда
+`gfx_get_draw_page()` отличается от страницы прошлого прохода (первый
+проход идёт всегда).  Полная чистка всей ширины при инвалидации добавлена
+там же — старая полоса могла заходить под статус-текст, где щадящая чистка
+её не трогала; текст сразу перезапрашивается, чтобы не пропал.
+
 **Что проверить при взятии в работу.**
 
 1. Значения `POP_STATUS_L`/`POP_STATUS_R` против реальной ширины полос:

applications/SprPoP/docs/TASKS_OPEN.md

@@ -1009,7 +1009,7 @@ tp/10 у факелов таблицей, пустой слот соперник
 
 ## P1 — берётся в любой момент
 
-### <a id="time-speed-modes"></a>TIME-SPEED. Часы бегут быстрее в FAST/FASTEST
+### <a id="time-speed-modes"></a>TIME-SPEED. Часы бегут быстрее в FAST/FASTEST — СДЕЛАНО 2026-08-31, остался вариант 3 (RTC)
 
 **Наблюдение (пользователь, 2026-08-31):** «при режиме FAST/FASTEST время
 начинает бежать быстрее — похоже, время мы считаем в наших логических
@@ -1040,12 +1040,37 @@ tp/10 у факелов таблицей, пустой слот соперник
    минутой в любом режиме, а в бою часы по-прежнему замедляются, как в
    оригинале.  Цена — счётчик-накопитель в `pop_timer_tick`.
 
-**Решать пользователю; по умолчанию — вариант 1** (режимы скорости
-отладочные, а вариант 2 разводит наш таймер с оригинальным на уровне
-механики).
+3. **Часы от RTC** (идея пользователя, 2026-08-31).  Брать время из
+   часов реального времени, а не считать кадры вовсе.
+
+**Почему третий вариант интереснее, чем кажется.**  Погрешность есть уже
+СЕЙЧАС и без всяких режимов: логический кадр NORMAL — 4 кадра луча, а это
+81,93 мс, то есть 12,2 кадра в секунду вместо ровных 12.  Оригинальная
+минута из 720 тиков проходит у нас за 58,99 с — почти на секунду быстрее.
+За час игры набегает около минуты.  Ни один из первых двух вариантов этого
+не лечит: они выравнивают режимы между собой, но обе шкалы остаются
+привязанными к лучу, а луч не кратен игровой секунде.
+
+RTC (`ESTEX $21 SYSTIME`, memory `sprinter_systime_dow`) даёт абсолютную
+шкалу и снимает накопление полностью.  Подводные камни, которые надо
+решить при взятии в работу:
+
+- вызов ESTEX стоит дорого и клобберит регистры — читать раз в тик, не в
+  кадре, и не из горячего пути (memory `estex_bios_abi`);
+- разрешение RTC — секунда, а тик игры — 1/12 секунды: нужен гибрид
+  «кадры внутри секунды, синхронизация по RTC на границе», иначе часы
+  задёргаются;
+- пауза, меню и загрузка НЕ должны съедать игровое время — при часах от
+  RTC это перестаёт получаться само собой и требует явного вычитания;
+- быстрая загрузка/сохранение обязаны сохранять смещение, а не абсолютное
+  время.
+
+**Решать пользователю.**  Порядок по цене: вариант 1 (ничего), вариант 2
+(счётчик кадров луча, лечит только разбег режимов), вариант 3 (RTC, лечит
+и накопление — но требует разобраться с паузами).
 
 
-### <a id="snd-speaker-38"></a>SND-SPEAKER-38. Звук мигания надписи: синтезировать ноты спикера в PCM
+### <a id="snd-speaker-38"></a>SND-SPEAKER-38. Звук мигания надписи — СДЕЛАНО и ПРОВЕРЕНО 2026-08-31
 
 **Постановка (пользователь, 2026-08-31):** «когда надпись Press Button
 начинает мигать — в SDLPoP воспроизводится звук на каждое моргание, у нас