Fix esp32 wait-timing race, rename wc_api.lib, keyboard: Enter-to-advance

esp32.c: two-phase esp_wait_busy() so a stale non-BUSY status right after
esp_cmd() isn't mistaken for completion (fixed a real TRACK_PLAY/0x88 race
on heavier XM files); added single-phase esp_wait_not_busy() for
esp_send_dma()'s per-chunk wait, which never actually sets BUSY and was
timing out on every chunk under the two-phase version.

vgm_wc_api.lib renamed to wc_api.lib (build.bat updated to match).

Keyboard: tried replacing wc_key_esc/pgup/pgdn/space with a raw PS/2-FIFO
reader (matching how VGMPLAY.WMF's own player reads keys) so Enter could
also advance to the next file. Reverted after two confirmed hardware
regressions (esp32 transfers failing with ESP_ERR_INV_XM, and the keyboard
going unresponsive once WC's own PS/2 scanning was disabled to stop it
competing with the raw reads) - VGMPLAY's approach relies on a full custom
interrupt handler xmplay has no equivalent need for. Back to the simple
wc_key_*() wrappers, plus wc_key_enter() so Enter now advances too, and
wc_key_wait_release() (called after wc_gedpl()) to debounce the Enter/F3
that launched the plugin itself.

Also: About window now centers dynamically for all three WC text modes
(90x36/80x25/80x30) instead of a fixed position, and matches the main
window's color scheme.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
2026-09-07 12:40:36 +03:00
co-authored by Claude Sonnet 5
parent ecf52d60c8
commit 168d6a71bd
16 changed files with 4471 additions and 3841 deletions
+2 -2
View File
@@ -2,7 +2,7 @@ REM NOTE: xmplay pins its OWN SDCC version here, independent of the rest of
REM ft812sdk (which stays on 4.0.0 for ABI reasons - see project memory on
REM the earlier shared-lib ABI mismatch incident). 4.6.0 is needed here
REM specifically for --sdcccall 1, required to link demyanenko-d/
REM VGMPLAY.WMF's wc_api library (vgm_wc_api.lib) - our own hand-rolled
REM VGMPLAY.WMF's wc_api library (wc_api.lib) - our own hand-rolled
REM PRSRW+PRIAT implementations corrupted esp32 file loading in three
REM different shapes and were abandoned in favor of their tested code.
set SDCC=E:\SDCC\4.6.0
@@ -14,7 +14,7 @@ del /q /s obj >nul
sdasz80 -o obj/crt0.rel src/crt0.s
if errorlevel 1 pause & exit
sdcc -Isrc -I../lib/sdk -I../../../esp32/src/main -mz80 --sdcccall 1 --std-sdcc11 --opt-code-speed --no-std-crt0 obj/crt0.rel --code-loc 0x8003 --data-loc 0xA800 src/main.c vgm_wc_api.lib -o obj/out.hex
sdcc -Isrc -I../lib/sdk -I../../../esp32/src/main -mz80 --sdcccall 1 --std-sdcc11 --opt-code-speed --no-std-crt0 obj/crt0.rel --code-loc 0x8003 --data-loc 0xA800 src/main.c wc_api.lib -o obj/out.hex
if errorlevel 1 pause & exit
if exist obj/out.hex hex2bin obj/out.hex >nul