alexandClaude Sonnet 5
168d6a71bd
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>
49 lines
2.4 KiB
Batchfile
49 lines
2.4 KiB
Batchfile
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 (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
|
|
set path=%SDCC%\bin;E:\zx-evo-master\pentevo\tools\hex2bin;%path%
|
|
|
|
if not exist obj md obj
|
|
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 wc_api.lib -o obj/out.hex
|
|
if errorlevel 1 pause & exit
|
|
if exist obj/out.hex hex2bin obj/out.hex >nul
|
|
|
|
for %%i in (obj/out.bin) do set sz=%%~zi
|
|
set /a sz=(%sz% - 1) / 512 + 1
|
|
|
|
REM A WC plugin page is exactly 16KB = 32 512-byte blocks (WALK in WCVW.ASM
|
|
REM loads N_BLK0 blocks straight off disk into the #C000-#FFFF window as
|
|
REM one contiguous chunk - anything past 32 blocks overflows that window).
|
|
REM This is what broke ftview's [PLUGINS] autoload (33 blocks needed, only
|
|
REM 32 available) - fixed there by moving --data-loc from 0xAE00 down to
|
|
REM 0xA800, applied here too for consistency and headroom as xmplay grows.
|
|
if %sz% GTR 32 (
|
|
echo ERROR: build needs %sz% x 512-byte blocks, but a single WC plugin page holds only 32 - shrink the code or lower --data-loc's headroom above it.
|
|
pause
|
|
exit
|
|
)
|
|
|
|
REM Pad obj/out.bin up to a whole number of 512-byte blocks (sz*512 bytes).
|
|
REM hex2bin only emits the bytes actually present in the hex file, which
|
|
REM generally is NOT block-aligned, while N_BLK0 above always rounds up -
|
|
REM technically short of what the header promises, though not the cause
|
|
REM of the overflow bug above.
|
|
set /a padded=%sz% * 512
|
|
powershell -NoProfile -Command "$fs=[System.IO.File]::Open('obj\out.bin',[System.IO.FileMode]::Open,[System.IO.FileAccess]::Write); $fs.SetLength(%padded%); $fs.Close()"
|
|
|
|
sdcc -DN_BLK0=%sz% -Isrc -I../lib/sdk --no-std-crt0 -mz80 --std-sdcc11 --opt-code-speed src/wc_h.c -o obj/hdr.hex
|
|
if errorlevel 1 pause & exit
|
|
if exist obj/hdr.hex hex2bin obj/hdr.hex >nul
|
|
|
|
copy /b obj\hdr.bin + obj\out.bin xmplay.wmf >nul
|