v0.0.218

rePIU v0.0.218

이전 릴리스 v0.0.217 이후의 변경입니다(issue #58). PIU10 게임에서 화살표가 플레이 중 뒤로 튀거나 음악보다
늦어지던 증상을 고쳤습니다.

해결된 issue

issue	내용	커밋
#58	플레이 중 화살표가 멈추거나 뒤로 가거나 앞으로 튐: 곡 시계의 MP3 위치 보정	27677cb

바뀐 것

MP3 위치를 tick 시각으로 답합니다. PIU10 게임(pumpipx3 등)은 타이머 tick으로 곡 시계를 올리고, MP3 칩의
frame-sync 비트가 바뀐 횟수로 곡 위치를 세어 256프레임(약 6.7초)마다 곡 시계를 그 위치로 맞춥니다. 화살표는 이
곡 시계를 따릅니다. 실제 기계의 타이머는 4 ms마다 고르게 돌지만, rePIU에서는 tick이 늦게 몰려 들어갑니다(Windows
vsync에서는 프레임당 4개를 한꺼번에). 그러면 게임이 같은 순간의 비트를 여러 번 읽어 변화 두 개가 상쇄되고, 곡
위치를 52 ms씩 잃어 다음 보정 때 화살표가 뒤로 튀고 그 곡 내내 늦었습니다.

이제 게임이 타이머 처리 안에서 읽으면 그 tick이 원래 왔어야 할 시각의 비트로, 밖에서 읽으면 마지막으로 받은 tick
시각의 비트로 답합니다. 입력 키를 tick 시각으로 답하던 방식과 같습니다.

측정(Windows, pumpipx3, 300초)	보정 때 화살표 이동
이전, 화면 캡처를 같이 돌림	−194.6 ~ +5.4 ms
이번, 같은 조건	모두 +1.1 / −2.9 ms(tick 하나 안)
이번, 직접 플레이 8곡	47회 중 46회 +1.1 / −2.9 ms(나머지 1회의 원인이던 race도 수정)

REPIU_PIU10_FRAME_SYNC_REPLAY=0이면 이전 동작입니다.

진단. REPIU_PIU10_SONG_CLOCK_LOG=1이면 보정 때마다 화살표가 몇 ms 움직였는지 찍고, 종료 보고에
PIU10 song clock …와 프레임당 tick 분포 PIU10 song frame ticks …가 나옵니다(꺼져 있어도 8 ms 이상은
찍힘). REPIU_TIMER_LATENCY_TRACE=<경로>는 tick이 어디서 늦는지 기록합니다.

확인한 것

구성	확인
Win32 Release	빌드, core probe(새 piu10_song_clock_census, piu10_frame_sync_history 포함), JAMMA timeline probe, 자동 플레이와 직접 플레이
Linux x64 Release(WSL)	빌드, core probe

알려진 것

• Linux 실기와 스팀덱에서는 플레이로 확인하지 않았습니다(WSL에서는 MP3 재생이 진행되지 않음).
• tick이 프레임당 한 번 몰려 들어가는 구조 자체, 게임이 수백 ms 멈출 때 tick이 버려져 화살표가 앞으로 튀는 경우는
  #59에서 이어집니다.

---

rePIU v0.0.218

Changes since v0.0.217 (issue #58). In the PIU10 games the arrows no longer step back during play or fall
behind the music.

Resolved issues

issue	Summary	Commit
#58	Arrows stall, step back or jump during play: the song clock's MP3 position correction	27677cb

Changed

The MP3 position is answered at tick time. The PIU10 games (pumpipx3 and others) advance a song clock on timer
ticks, count the song position by the changes of the MP3 chip's frame-sync bit, and every 256 frames (about 6.7 s)
set the song clock to that position; the arrows follow the song clock. The original timer runs evenly every 4 ms,
but in rePIU the ticks arrive late and bunched (four at once per frame under Windows vsync). The game then read the
bit at one instant several times, two changes cancelled, and the song position fell 52 ms behind each time: at the
next correction the arrows stepped back and stayed late for the rest of the song.

A read inside the game's timer handler is now answered with the bit at the time its tick was due, and one outside
with the bit at the latest tick the game received, the way the input keys already are.

Measured (Windows, pumpipx3, 300 s)	Arrow move at a correction
Before, with a screen capture running	−194.6 to +5.4 ms
Now, the same	all +1.1 / −2.9 ms (within one tick)
Now, eight songs played by hand	46 of 47 at +1.1 / −2.9 ms (the race behind the other one is fixed too)

REPIU_PIU10_FRAME_SYNC_REPLAY=0 restores the previous behavior.

Diagnostics. REPIU_PIU10_SONG_CLOCK_LOG=1 prints how far the arrows moved at every correction, and the final
report gives PIU10 song clock … and the per-frame tick histogram PIU10 song frame ticks … (moves of 8 ms or more
are printed even when it is off). REPIU_TIMER_LATENCY_TRACE=<path> records where ticks are held.

Verified

• Win32 Release: builds, the core probe (including the new piu10_song_clock_census and piu10_frame_sync_history),
  the JAMMA timeline probe, automated plays and a hand-played session.
• Linux x64 Release (WSL): build and the core probe.

Known

• Not played on Linux hardware or a Steam Deck (on WSL the MP3 does not advance).
• Ticks still arrive bunched once a frame, and when the game stalls for hundreds of milliseconds dropped ticks can
  move the arrows ahead; both continue in #59.