v0.0.225

What's Changed

• rePIU v0.0.225: the web page's keyboard and gamepads reach the game with the native key layout (#76) by @nworkers in #77

Full Changelog: v0.0.224...v0.0.225

v0.0.224

What's Changed

• rePIU v0.0.224: pick the ROMs as a folder or separately, and see the CHD unpack's progress on the web page (#72) by @nworkers in #75

Full Changelog: v0.0.223...v0.0.224

v0.0.223

rePIU v0.0.223

이전 릴리스 v0.0.222 이후의 변경입니다(issue #72). 브라우저 호스트 단계 4의 첫 단위입니다. 개발용 웹 빌드가 처음으로
브라우저 페이지에서 게임 화면을 냅니다. 배포 빌드(Windows·Linux)의 동작은 바뀌지 않습니다.

해결된 issue

issue	내용	커밋
#72	웹 이식 2B 단계 4: 브라우저 페이지, Worker의 엔진이 WebGL2 캔버스에 그리기	59f2445

바뀐 것

브라우저에서 pumpitea가 돕니다. 페이지에서 ROM ZIP과 CHD를 고르면 엔진이 페이지의 Worker에서 돌고 WebGL2 캔버스에 그립니다.

• 결과(pumpitea, Chrome): 시작 후 약 4분에 타이틀, 약 400초에 데모 플레이. 처음 약 55초는 CHD에서 게임 파일 428 MB를 메모리에
  푸는 시간입니다. 소리와 입력은 아직 없습니다.
• 파일: CHD는 통째로 올리지 않고 필요한 부분만 읽습니다. 롬은 사이트에 두지 않고 사용자가 고릅니다.
• 화면: 창·GL 문맥을 다루는 부분을 경계 하나로 나눠, Windows·Linux는 SDL 창을, 브라우저는 페이지의 캔버스를 씁니다.
• 실행: 엔진은 한 스레드에서 돌며 프레임마다 브라우저에 잠깐 차례를 넘깁니다.
• 실행 방법: ./scripts/build_web_wasm.sh --build-dir ~/repiu-web --target repiu_browser로 빌드하고 그 디렉터리를
  python3 -m http.server로 연 뒤 브라우저에서 엽니다.

확인한 것

구성	확인
브라우저(Chrome)	타이틀·데모 플레이 화면, Worker 오류 없음
Win32 Debug·Release	렌더 장면 probe 화소 일치, 후처리·레터박스·전체 화면, core probe
Win32 emulated, Linux x64·i386, 웹 Node	빌드, core probe, 실행
CI	Win32 Debug 빌드와 probe

알려진 것

• 소리·입력이 없습니다(다음 단위). 매번 게임 파일을 다시 풉니다(그다음 단위에서 영구 저장).
• 실시간보다 많이 느립니다. 제대로 플레이하려면 CPU 에뮬레이터의 번역 확대가 따로 필요합니다.

---

rePIU v0.0.223

Changes since v0.0.222 (issue #72). The first unit of the browser host's fourth phase. The development web build
puts the game's picture on a browser page for the first time. Release builds (Windows, Linux) behave as before.

Resolved issues

issue	Summary	Commit
#72	Web port 2B phase 4: the browser page, the engine in a Worker drawing to a WebGL2 canvas	59f2445

Changed

pumpitea runs in a browser. Pick the ROM ZIP and the CHD on the page, and the engine runs in the page's Worker and
draws to a WebGL2 canvas.

• Result (pumpitea, Chrome): the title about 4 minutes after start, demo play at about 400 s. The first 55 s or so go
  to unpacking 428 MB of game files from the CHD into memory. No sound or input yet.
• Files: the CHD is never loaded whole; only the parts asked for are read. ROMs are not hosted; the user picks them.
• Picture: the window and GL context work sits behind one boundary, so Windows and Linux use an SDL window and the
  browser the page's canvas.
• Running: the engine runs on one thread and hands the browser its turn once a frame.
• How to run: build with ./scripts/build_web_wasm.sh --build-dir ~/repiu-web --target repiu_browser, serve that
  directory with python3 -m http.server, and open it in a browser.

Checked

Configuration	Check
Browser (Chrome)	title and demo play on screen, no Worker errors
Win32 Debug and Release	render probe scenes pixel for pixel, post-process, letterbox, fullscreen, core probe
Win32 emulated, Linux x64 and i386, web under Node	build, core probe, run
CI	Win32 Debug build and probes

Known

• No sound or input (next unit). The game files are unpacked again every time (persistent storage is the unit after).
• Far slower than real time; playing properly needs wider translation in the CPU emulator, a separate piece of work.

v0.0.222

rePIU v0.0.222

이전 릴리스 v0.0.221 이후의 변경입니다(issue #69). 브라우저 호스트의 세 번째 단계입니다. Glide 렌더러를 OpenGL
3.3 core와 WebGL2(OpenGL ES 3.0)가 함께 가진 기능만으로 다시 썼습니다. Windows·Linux 화면은 예전과 같고, 이제 OpenGL
3.3을 지원하는 GPU 드라이버가 필요합니다(2010년 이후의 거의 모든 GPU).

해결된 issue

issue	내용	커밋
#69	웹 이식 2B 단계 3: Glide 렌더러를 GLES 3 / WebGL2 부분집합으로, 네이티브 GL 3.3 core로 확인	85071ca

바뀐 것

렌더러가 브라우저에서 돌 수 있는 모양이 되었습니다. 지금까지 렌더러는 옛 OpenGL의 고정 기능(즉시 모드, 행렬 스택,
알파 테스트 등)을 썼고, 이것은 WebGL에 없습니다.

• 그리기: 즉시 모드를 버텍스 버퍼로, 투영·점 크기·알파 테스트를 셰이더로 옮겼습니다. 색 결합·안개 계산은 그대로입니다.
• 화면 버퍼: 게임은 화면 밖의 front/back 버퍼 두 장에 그리고, 버퍼 교체 때 완성된 그림만 창으로 옮깁니다. 브라우저가
  표시 뒤 화면을 비우거나 그리다 만 프레임을 내보내도 게임 그림에 영향이 없습니다.
• 후처리(crt·scanline·사용자 셰이더): 화면을 복사하지 않고 바로 읽습니다. 사용자 셰이더 파일은 새 GLSL 문법으로 자동
  변환되어 그대로 쓸 수 있습니다.
• OpenGL 문맥: Windows·Linux는 OpenGL 3.3 core를 요청합니다. 지원하지 않으면 화면 없이 실행되고 이유가 표준 오류에
  찍힙니다.

확인한 것

구성	확인
렌더 probe	포팅 전 렌더러로 뜬 기준 장면 4개와 차이 0화소(Debug·Release)
Win32 Release	pumpitea·pumpit8 화면 전후 비교, 사용자 플레이 확인. vsync OFF 처리량 예전과 같음(약 1,100fps)
Linux x64·i386 (WSL)	빌드, core probe, 4.6 / 4.5 Core Profile로 타이틀 화면
웹(Node)	고정 기능 stub 없이 링크, core probe, pumpitea 30초
CI	Win32 Debug 빌드와 probe

알려진 것

• 브라우저에서는 아직 돌지 않습니다. 다음은 브라우저 페이지를 만드는 단계 4입니다.

---

rePIU v0.0.222

Changes since v0.0.221 (issue #69). The browser host's third phase. The Glide renderer was rewritten to use only
what OpenGL 3.3 core and WebGL2 (OpenGL ES 3.0) share. The Windows and Linux picture is as before, and a GPU driver with
OpenGL 3.3 is now required (nearly every GPU since 2010).

Resolved issues

issue	Summary	Commit
#69	Web port 2B phase 3: the Glide renderer on the GLES 3 / WebGL2 subset, checked on native GL 3.3 core	85071ca

Changed

The renderer now has a shape that can run in a browser. Until now it used old OpenGL's fixed function (immediate
mode, the matrix stack, the alpha test and so on), which WebGL does not have.

• Drawing: immediate mode became a vertex buffer, and the projection, point size and alpha test moved into the shader.
  The color combine and fog calculations are unchanged.
• Screen buffers: the game draws into an offscreen pair of front and back buffers, and only finished pictures reach the
  window at the buffer swap. A browser clearing the screen after showing it, or showing a half-drawn frame, cannot touch
  the game's picture.
• Post-processing (crt, scanline, user shaders): reads the picture directly instead of copying the screen. User shader
  files are converted to the newer GLSL automatically and work as they are.
• OpenGL context: Windows and Linux ask for OpenGL 3.3 core. Without it the game runs with no picture and standard
  error says why.

Checked

Configuration	Check
Render probe	zero differing pixels against four reference scenes captured on the renderer before the port (Debug and Release)
Win32 Release	pumpitea and pumpit8 pictures compared before and after, played by the user; vsync-OFF throughput as before (about 1,100 fps)
Linux x64 and i386 (WSL)	build, core probe, the title on 4.6 / 4.5 Core Profile
Web (Node)	links without the fixed-function stubs, core probe, pumpitea for 30 s
CI	Win32 Debug build and probes

Known

• It does not run in a browser yet. Next is phase 4, the browser page.

v0.0.221

What's Changed

• rePIU v0.0.221: the emulated engine and rex86 built for the web and run headless under Node (#67) by @nworkers in #68

Full Changelog: v0.0.220...v0.0.221

v0.0.220

What's Changed

• rePIU v0.0.220: the emulated model runs the guest and the host on one thread, the browser host's first phase (#64) by @nworkers in #66

Full Changelog: v0.0.219...v0.0.220

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.

v0.0.217

rePIU v0.0.217

이전 릴리스 v0.0.216 이후의 변경입니다(issue #55). 게임패드로 OSD를 열고 조작합니다. 키보드 없는
스팀덱에서도 전체 화면, 비율, 셰이더, 텍스처 같은 게임 중 설정을 바꿀 수 있습니다.

해결된 issue

issue	내용	커밋
#55	게임패드로 OSD 열기와 조작(LT+RT+Y)	33eba35

바뀐 것

게임패드 OSD. 한 패드에서 LT + RT + Y를 함께 누르면 Tab처럼 OSD가 열리고 닫힙니다. 열려 있는 동안은
패드로 조작합니다.

패드	동작
D-pad	항목 이동
A	체크박스 바꾸기, 메뉴(셰이더 등) 열기·고르기
B	열린 메뉴가 있으면 메뉴만 닫고, 없으면 OSD를 닫음
LT + RT + Y	OSD 닫기

OSD가 열려 있는 동안 패드 입력은 게임에 가지 않고, 열 때 눌려 있던 게임 입력은 떼어진 것으로 처리합니다.
닫을 때 누르고 있던 버튼(예: 닫으려고 누른 B = 기본 우하 발판)은 뗄 때까지 게임에 가지 않습니다. 키보드는
지금처럼 OSD가 열려 있어도 게임으로 갑니다. 스팀덱 사용 순서는 런처 업데이트 가이드에
있습니다.

확인한 것

구성	확인
Linux x64·i386 Release	빌드, core probe(새 host_pad_input_osd_chord 포함)
Win32	CI Debug 빌드와 probe
실제 패드(Xbox Series X, Linux x64)	LT+RT+Y로 두 번 열고 닫음, 패드로 비율 유지와 셰이더를 바꿈, 열린 동안 게임에 간 패드 입력 0건, 닫은 B가 게임에 새지 않음

알려진 것

• 스팀덱 실기에서는 확인하지 않았습니다.
• Tab으로 연 OSD도 같은 규칙이라, 열려 있는 동안에는 패드로 게임을 할 수 없습니다(키보드는 됨).

---

rePIU v0.0.217

Changes since v0.0.216 (issue #55). A gamepad opens and drives the OSD, so in-game settings such as
fullscreen, aspect, shader and textures can be changed on a Steam Deck with no keyboard.

Resolved issues

issue	Summary	Commit
#55	Open and drive the in-game OSD with a gamepad (LT+RT+Y)	33eba35

Changed

Gamepad OSD. Pressing LT + RT + Y together on one pad opens and closes the OSD as Tab does. While it is
open the pad drives it: the D-pad moves between items, A toggles a checkbox or opens and picks from a menu (the
shader, for one), B closes an open menu or otherwise the OSD, and LT + RT + Y closes it too. Meanwhile pad
input does not reach the game, and game inputs held as it opens are released; a button still held as it closes
(such as the B that closed it, the down-right panel by default) stays away from the game until released. The
keyboard still reaches the game while the OSD is open. Steam Deck steps are in the
launcher update guide.

Verified

• Linux x64 and i386 Release: builds and the core probe, including the new host_pad_input_osd_chord.
• Win32: the CI Debug build and probes.
• A real pad (Xbox Series X, Linux x64): opened and closed twice with LT+RT+Y, keep-aspect and the shader changed
  with the pad, no pad input reached the game while it was open, and the closing B did not leak into the game.

Known

• Not checked on a real Steam Deck.
• An OSD opened with Tab follows the same rule, so the pad cannot play while it is open (the keyboard can).

v0.0.216

rePIU v0.0.216

이전 릴리스 v0.0.215 이후의 변경입니다(issue #52). 게임패드만으로 게임과 런처를 끝낼 수 있습니다.
키보드도 창 닫기 버튼도 없는 스팀덱을 위한 조합입니다. v0.0.215를 쓰고 있다면 이 버전은 런처의
Update 버튼으로 받을 수 있는 첫 릴리스입니다.

해결된 issue

issue	내용	커밋
#52	게임패드 종료 조합 LT+RT+L3+R3 1초	8d0b378

바뀐 것

게임패드 종료 조합. 한 패드에서 LT + RT + 왼쪽 스틱 누르기 + 오른쪽 스틱 누르기를 1초 동안 함께
누르고 있으면 끝냅니다.

어디서	결과
게임 중	창을 닫은 것과 같이 게임이 끝나고 런처로 돌아감(인자 실행이면 프로세스가 끝남)
런처	런처가 닫히고 rePIU가 끝남(스팀덱에서는 Steam으로 돌아감)

1초가 되기 전에 떼면 아무 일도 없습니다. 오른쪽 스틱 누르기는 기본으로 CLEAR에 묶여 있어, 조합을 누르는
동안 게임에 CLEAR가 들어갑니다. 런처 안내 문구에도 조합을 적었고, 스팀덱 설치 순서는
런처 업데이트 가이드에 있습니다.

확인한 것

구성	확인
Linux x64·i386 Release	빌드, core probe(새 host_pad_input_exit_chord 포함)
Win32	CI Debug 빌드와 probe
실제 패드(Xbox Series X, Linux x64)	게임 중 1초 유지 → 정상 종료 후 런처 복귀, 짧게 누르기와 런처 종료는 사용자가 화면으로 확인
v0.0.215 릴리스 실행	첫 시도에 모든 잡 통과, Node.js 20 경고 없음, Linux x64 host_thread_interrupt 주장 모두 참(#50, #12)

알려진 것

• 스팀덱 실기에서는 확인하지 않았습니다.
• 조합을 누르는 동안 게임에 CLEAR가 들어갑니다(결정에 따른 동작).

---

rePIU v0.0.216

Changes since v0.0.215 (issue #52). A gamepad alone can now quit the game and the launcher, a chord for the
Steam Deck, which has no keyboard or close button. If you run v0.0.215, this is the first release its launcher's
Update button can install.

Resolved issues

issue	Summary	Commit
#52	Gamepad exit chord LT+RT+L3+R3 held for one second	8d0b378

Changed

Gamepad exit chord. Holding LT + RT + left stick click + right stick click together on one pad for one
second quits: in a game it ends the game as closing the window does and returns to the launcher (an argument
run ends the process); in the launcher it closes the launcher and ends rePIU (back to Steam on a Steam Deck).
Releasing sooner does nothing. The right stick click is bound to CLEAR by default, so the game sees CLEAR while
the chord is held. The launcher's hint line names the chord, and the Steam Deck steps are in the
launcher update guide.

Verified

• Linux x64 and i386 Release: builds and the core probe, including the new host_pad_input_exit_chord.
• Win32: the CI Debug build and probes.
• A real pad (Xbox Series X, Linux x64): a one-second hold in a game ended it normally and returned to the
  launcher; the user confirmed the short press and the launcher quit on screen.
• The v0.0.215 release run passed every job on its first attempt, with no Node.js 20 warning and every Linux x64
  host_thread_interrupt claim true (#50, #12).

Known

• Not checked on a real Steam Deck.
• The game sees CLEAR during the chord (the decided behavior).

v0.0.215

rePIU v0.0.215

이전 릴리스 v0.0.214 이후의 변경입니다(issue #48, #50, #12 후속). 런처가 새 릴리스를 알리고 버튼 하나로
업데이트합니다. 스팀덱처럼 릴리스를 손으로 받아 푸는 일이 번거로운 환경을 위한 기능이며, 이 버전부터
다음 릴리스를 런처에서 받을 수 있습니다.

해결된 issue

issue	내용	커밋
#48	런처의 업데이트 확인과 제자리 설치	8a1cc84
#50	GitHub Actions의 Node.js 20 런타임 교체	8a1cc84
#12 (후속, 열린 상태)	Linux x64 릴리스 CI의 간헐적 host_thread_interrupt 실패 진단	8a1cc84

바뀐 것

런처 업데이트. 런처(인자 없이 실행한 repiu)가 열리면 GitHub의 최신 릴리스를 백그라운드에서
확인합니다. 새 버전이면 맨 위에 "rePIU v… is available."과 Update 버튼이 나오고, 게임패드로도 누를 수
있습니다. 누르면 이 빌드에 맞는 아카이브를 받아 GitHub가 알려 준 SHA-256과 같을 때만 풀고, 아카이브에 든
파일만 바꾼 뒤 런처를 다시 시작합니다. roms\, cfg\, nvram\은 그대로이고, 실패하면 기존 파일로
되돌립니다.

항목	내용
받는 방법	Win32는 WinHTTP, Linux는 시스템 curl
다시 시작	Linux는 같은 프로세스가 새 실행 파일로 바뀜(Steam이 계속 실행 중으로 봄), Win32는 새 런처를 자식으로 실행
설치 버튼이 나오는 곳	릴리스 아카이브를 푼 폴더(실행 파일 옆 VERSION이 실행 중인 버전과 같음)만. 빌드 트리는 알림만
끄기	cfg\repiu.ini의 [Launcher] check_updates = 0, 또는 REPIU_UPDATE_CHECK=0

스팀덱 설치, 문제 해결, 시험 절차는 런처 업데이트 가이드에 있습니다.

CI. 워크플로의 action을 Node 24 판으로 올렸습니다(checkout@v7, cache@v6, upload-artifact@v7,
download-artifact@v8). Linux x64 릴리스 잡을 간헐적으로 멈추던 host_thread_interrupt probe는 일곱 가지
주장을 따로 출력하고, 대상 스레드가 두 함수를 번갈아 돌게 해 인터럽트 위치 편향만으로는 실패하지 않게
했습니다.

확인한 것

구성	확인
Linux x64·i386 Release	빌드, core probe(launcher_update 13개 항목 포함), 로컬과 GitHub runner
Win32	CI Debug 빌드와 probe(새 파일에서 경고 없음)
실제 업데이트(Linux x64)	v0.0.212인 척한 시험 폴더에서 v0.0.213으로: 받기·검증·10개 교체·다시 시작, 다음 시작 때 옛 파일 정리, 빌드 트리에서는 설치 버튼 없음
실제 아카이브	v0.0.213의 tar.gz와 zip을 새 코드로 풀어 Python 결과와 바이트 단위로 같음

알려진 것

• 업데이트 기능은 이 버전부터 들어 있으므로, 실제로 런처에서 업데이트되는 것은 다음 릴리스부터입니다.
• Win32의 실제 교체·다시 시작과 스팀덱 실기는 확인하지 않았습니다.
• #12는 한 번의 통과로 해결을 단정하지 않고 열어 둡니다. 다음에 실패하면 새 출력이 어느 주장인지 알려 줍니다.

---

rePIU v0.0.215

Changes since v0.0.214 (issues #48, #50, a #12 follow-up). The launcher announces a new release and updates
with one button, for setups like the Steam Deck where downloading and unpacking a release by hand is tedious;
from this version on, the next release can be taken from the launcher.

Resolved issues

issue	Summary	Commit
#48	Launcher update check and in-place install	8a1cc84
#50	Move GitHub Actions off the Node.js 20 runtimes	8a1cc84
#12 (follow-up, still open)	Diagnosing the intermittent host_thread_interrupt failure in the Linux x64 release CI	8a1cc84

Changed

Launcher updates. When the launcher (repiu with no arguments) opens, it checks GitHub's latest release in
the background. A newer one shows "rePIU v… is available." with an Update button at the top, reachable by
gamepad, which downloads this build's archive, unpacks it only when it matches the SHA-256 GitHub reports,
replaces only the archive's files, and restarts the launcher; roms\, cfg\ and nvram\ stay, and a
failure puts the old files back. Win32 downloads through WinHTTP and Linux through the system curl; Linux
turns the same process into the new executable (so Steam sees it still running) and Win32 runs the new launcher
as a child. The button appears only in a folder unpacked from a release archive (a VERSION next to the
executable equal to the running version); a build tree only gets the notice. [Launcher] check_updates = 0 in
cfg\repiu.ini or REPIU_UPDATE_CHECK=0 turns it off. Installing on a Steam Deck, troubleshooting and a test
procedure are in the launcher update guide.

CI. The workflows' actions moved to their Node 24 versions (checkout@v7, cache@v6, upload-artifact@v7,
download-artifact@v8). The host_thread_interrupt probe that intermittently stopped the Linux x64 release job
prints its seven claims separately, and its target alternates between two functions so a biased interrupt
position alone cannot fail it.

Verified

• Linux x64 and i386 Release: builds and the core probe (including launcher_update's 13 checks), locally and on
  GitHub's runners.
• Win32: the CI Debug build and probes, with no warning from the new files.
• A real update on Linux x64, from a test folder pretending v0.0.212 to v0.0.213: download, verify, 10 files
  replaced, restart; old files cleaned at the next start; no install button in a build tree.
• v0.0.213's real tar.gz and zip unpacked by the new code byte-identically to Python's.

Known

• The update feature ships in this version, so an actual update from the launcher first happens with the next
  release.
• A real Win32 replacement and restart, and a real Steam Deck, were not checked.
• #12 stays open: one pass does not settle an intermittent failure, and a later failure will name its claim.