v0.0.197

rePIU v0.0.197

이전 릴리스 v0.0.195 이후의 변경입니다(Tasks 761–762). v0.0.196은 릴리스 노트 없이 태그만 붙었으므로
여기에 함께 적습니다. Win32에서 pumpit8이 첫 곡을 로딩한 뒤 멈추던 것과 pumpipx3가 시작하자마자 죽던 것을
고쳤고, Glide LFB 고정밀 표시와 첫 인게임 OSD가 들어왔습니다.

고친 것 (v0.0.197, Task 762)

Win32에서 pumpit8이 첫 곡을 로딩한 뒤 멈추던 것. v0.0.191부터 v0.0.196까지 같은 자리에서 멈췄습니다.
게임은 곡을 다 읽은 뒤 타이머 tick 카운터가 1200(5초)이 되길 기다리는데, 그 대기 루프에 tick이 들어가지
않았습니다.

• 원인. Win32(와 Linux i386)는 게스트의 iret을 그대로 실행하므로 엔진이 타이머 핸들러의 복귀를 보지
  못했습니다. 핸들러가 돌아간 코드는 제자리에서 감독 없이 돌았고, 트랩이 없는 루프에 들어가면 다음 tick을
  넣을 자리가 없었습니다. v0.0.190까지는 주입 프레임에 남아 있던 추적 플래그(TF)가 우연히 감독을 이어 줬고,
  v0.0.191(Task 736)이 그 플래그를 빼면서 끊겼습니다. 그 방식을 되살려 보니 다음 실행에서 핸들러가 끝없이
  중첩돼 스택이 320 KiB 내려갔으므로, 되돌리지 않았습니다.
• 수정. 주입한 타이머 프레임이 return pad(실행하면 폴트가 나는 예약 페이지)로 복귀합니다. 엔진이 그
  폴트에서 원래 복귀 주소와 실행 상태를 되돌리고, 제자리 코드는 코드 캐시로 다시 들여보내며, 복귀를 본
  김에 Linux x64에서 검증된 중첩 금지·차례·연쇄 규칙(Task 751)을 Win32에서도 켭니다.
• 결과 (Win32 Release, 입력 스크립트).

실행	v0.0.196	v0.0.197
pumpit8 100초	2,086프레임, 곡 로딩 뒤 멈춤, tick 9,573 / 22,771 (42%)	5,004프레임, 곡 재생 60 fps, tick 22,655 / 22,757 (99.6%)
pumpit8 곡 파일 열기 시점	55초	44초
pumpitea 60초	—	2,500프레임, tick 99.5%, 51.9 kHz → 240 Hz 도달
pumpit2a 60초	—	3,125프레임, tick 99.7%
pumpitpc 60초	—	3,085프레임, tick 99.5%

Win32에서 pumpipx3가 Fatal error: unable to find entry point in DLL.로 죽던 것. 같은 수정으로
사라졌습니다: 30초 실행 3회 모두 완주, 스위치를 끄면 2회 모두 이전과 같이 죽습니다. 이 수정이 겨냥한 것은
아니어서, 타이머 주입 경로가 왜 그 실패를 좌우하는지는 설명하지 못했습니다.

로딩이 길어 보이던 것. 버려지던 tick이 전달되면서 게임의 시계가 제 속도로 갑니다. pumpit8의 곡 파일
열기가 같은 입력에서 11초 당겨졌습니다.

새로 들어온 것 (v0.0.196, Task 761)

• Glide LFB 고정밀 표시. grLfbWriteRegion의 24/32-bit 소스가 565로 양자화되지 않고 표시까지 원본
  정밀도를 유지합니다. 게스트가 읽는 565 버퍼는 그대로입니다. 기본 켜짐,
  REPIU_GLIDE_LFB_HIGH_PRECISION=0|off|false로 끕니다.
• 인게임 OSD. Tab으로 열고 닫습니다(게임 입력에는 전달되지 않음). 항목은 고정밀 토글 하나이며, 바꾸면
  다음 LFB 쓰기부터 적용됩니다.
• PTX 헤더 조사와 버전별 자산 세대를 기록했습니다(pumpitea는 2세대, PNG/PTX 겸용).

새 스위치와 진단 (설정하지 않으면 기본 동작)

• REPIU_TIMER_RETURN_PAD — 0이면 주입 프레임에 실제 복귀 주소를 넣는 v0.0.196까지의 동작입니다(pumpit8이
  다시 멈춥니다). 최종 보고의
  timer return pad pushed/returned/supervised/overflow/unmatched/abandoned/depth-max/depth-at-end 줄이
  복귀를 몇 번 받았는지 말합니다.
• REPIU_GLIDE_LFB_HIGH_PRECISION — 위 참조.
• core probe timer_return_pad, repiu_aot_probe --timer-return-pad.

확인한 것

구성	확인
Win32 x86 Release	pumpit8 100초 ×2, pumpitea·pumpit2a·pumpitpc 60초, pumpipx3 30초 ×3, 스위치 끈 대조 실행
Win32 x86 Debug	빌드, core probe 전부 통과, aot probe(--timer-return-pad, --pic-timer-in-service, --jamma-input-timeline, --shutdown-recovery-policy)
Linux x64 Release·Debug	빌드, core probe 전부 통과, pumpit8 50초(동작 변화 없음)
Linux i386 (WSL)	빌드, core probe 전부 통과, pumpit8 70초 폴트 없음

화면과 소리는 수치로만 확인했습니다. 전 롬셋 조사는 하지 않았습니다.

알려진 것

• Win32 Release 빌드의 core probe가 stack_bridge_contract=false로 실패합니다. v0.0.195의 Release
  빌드도 같아서 이 릴리스에서 생긴 것은 아닙니다. Debug 빌드는 통과합니다.
• pumpipx3가 살아난 기전은 설명하지 못했습니다(위).
• Linux i386은 WSL에서 4~13 fps입니다(이전과 같음).
• 웹 빌드는 확인하지 못했습니다.
• v0.0.194의 "알려진 것"(WSL에서 음악이 느려지는 현상 등)은 그대로입니다.

---

rePIU v0.0.197

Changes since the previous release, v0.0.195 (Tasks 761–762). v0.0.196 was tagged without a release
note, so it is described here as well. pumpit8 on Win32 no longer stops after loading its first song
and pumpipx3 no longer dies at start, and the Glide LFB high-precision presentation and the first
in-game OSD are in.

Fixed (v0.0.197, Task 762)

pumpit8 on Win32 stopped after loading its first song. From v0.0.191 to v0.0.196 it stopped at the
same place: having read the song, the game waits for the timer tick counter to reach 1200 (five
seconds), and no tick reached that wait loop.

• Cause. Win32 (and Linux i386) run the guest's iret as it is, so the engine never saw a timer
  handler return. The code a handler returned to ran in place unsupervised, and once it entered a loop
  without a trap there was no place to inject the next tick. Up to v0.0.190 the trace flag (TF) left in
  the injected frame happened to keep the code supervised; v0.0.191 (Task 736) removed it and the path
  was cut. Restoring that rule made the next run nest handlers until the stack had dropped 320 KiB, so
  it was not restored.
• Fix. An injected timer frame returns to the return pad, a reserved page that faults when
  executed. From that fault the engine restores the real return address and execution state, sends
  code that runs in place back into the code cache and, now that the return is seen, switches on for
  Win32 the nesting, turn and chain rules (Task 751) proven on Linux x64.
• Result (Win32 Release, input script). pumpit8 for 100 seconds: 5,004 frames and the song
  playing at 60 fps with 22,655 of 22,757 ticks delivered, against 2,086 frames, a stop and 9,573 of
  22,771 in v0.0.196; the song's file opens 11 seconds earlier. pumpitea, pumpit2a and pumpitpc for
  60 seconds: 99.5% or more of the ticks delivered.

pumpipx3 on Win32 died with Fatal error: unable to find entry point in DLL. It went away with the
same change: three 30-second runs completed, and with the switch off two runs died as before. The
change did not aim at it, and why the tick injection path decides that failure is not explained.

Loading looked slow. With the dropped ticks now delivered the game's clock runs at its own speed;
pumpit8 opens its song's file 11 seconds earlier under the same input.

New (v0.0.196, Task 761)

• Glide LFB high-precision presentation. 24/32-bit sources of grLfbWriteRegion keep their
  precision to the screen instead of being quantized to 565; the 565 buffer the guest reads is
  unchanged. On by default; REPIU_GLIDE_LFB_HIGH_PRECISION=0|off|false turns it off.
• In-game OSD. Tab opens and closes it and never reaches game input. Its one item is the
  high-precision toggle, which takes effect at the next LFB write.
• The PTX header census and the per-version asset generations are recorded (pumpitea is generation 2,
  PNG and PTX).

New switches and diagnostics (default behaviour when unset)

• REPIU_TIMER_RETURN_PAD — 0 writes the real return address into the injected frame as v0.0.196
  did (and pumpit8 stops again). The final report's
  timer return pad pushed/returned/supervised/overflow/unmatched/abandoned/depth-max/depth-at-end
  line says how many returns were taken.
• REPIU_GLIDE_LFB_HIGH_PRECISION — above.
• Core probe timer_return_pad, repiu_aot_probe --timer-return-pad.

Verified

Configuration	Check
Win32 x86 Release	pumpit8 100 s ×2, pumpitea, pumpit2a and pumpitpc 60 s, pumpipx3 30 s ×3, control runs with the switch off
Win32 x86 Debug	build, every core probe passes, aot probes (--timer-return-pad, --pic-timer-in-service, --jamma-input-timeline, --shutdown-recovery-policy)
Linux x64 Release and Debug	build, every core probe passes, pumpit8 50 s (no change in behaviour)
Linux i386 (WSL)	build, every core probe passes, pumpit8 70 s without a fault

The picture and the sound were checked by numbers only. No survey of every ROM set.

Known

• The core probe of a Win32 Release build fails with stack_bridge_contract=false. v0.0.195's
  Release build fails the same way, so it is not new in this release. Debug builds pass.
• Why pumpipx3 came back is not explained (above).
• Linux i386 under WSL runs at 4 to 13 fps, as before.
• The web build was not checked.
• v0.0.194's known issues (the music slowing down under WSL, among others) remain.