Renamed as zc_sd_driver.asm/zc_sd_driver_body.asm (no relation to Wild
Commander). Fixes a stale-IX bug where core_mkfile's filter_name_to_83
left IX pointing into driver memory instead of restoring it, causing
zifi.asm's save_downloaded_file to read the wrong page/address for
every SAVE512 call after MKFILE. All CORE dispatch entry points now
preserve IX across the call. Also fixes a body/#2000 jump-table
overlap, sdbuf DMA word-alignment, and a load_ram_page staleness race
in zifi.asm's own download bookkeeping.
The in-progress standalone SD/FAT32 driver work was interfering with
ZiFi's own screen output (garbled text) and had grown too large to
keep iterating on inside the main client. Reverting zifi.asm to its
pre-diagnostic state; the SD driver experiments continue as a
separate standalone test program instead.
The closed WDFCVBI2.COD driver's short-name generator can assign the
same 8.3 name to two different long-name directory entries, corrupting
the FAT directory structure (confirmed live on hardware via chkdsk:
2026_09_01 and 2026_0~1.--0 are the same day, split across two colliding
entries). Since the driver ships as a binary with no source, documented
the issue in README and started writing an open replacement SD/FAT32
driver from scratch.
This commit adds the in-progress diagnostic scaffolding for that new
driver (test_sd_raw/test_sd_raw2 in zifi.asm, marked with ;DIAG:
comments): a standalone SD-card SPI implementation (ports CONF=#77/
DATA=#57) that inits the card, reads sectors via CMD18+CMD12, and
parses the FAT32 boot sector/root directory independently of the
closed driver. Still under active debugging - the command handshake
(R1/token) checks out correct but the bulk data payload comes back
wrong, root cause not yet found. Not wired into the real boot path
beyond the diagnostic hook, and not ready to replace the closed driver.
FILE_NAME is a fixed 48-byte buffer, but the loop copying the
filename parsed from the download URL had no length check, so a
filename longer than 48 characters would overflow into adjacent
variables (FILE_INI, DIR_zifi, DIR_download, DIR_date). Bound the
copy loop to 48 bytes.
Verified on hardware via a temporary diagnostic test (since removed):
folder/file creation with long names and write+read-back through the
FAT32 driver both work correctly, and downloads/<date> is confirmed
write-only (playback/viewing always reads from memory, never disk).
Documented the fix in README.md.
zifi_input_fifo_check now tracks inactivity in frame-counted quanta
(~5s @ 50Hz, so independent of CPU/turbo clock): after ~10s of total
silence from the server on a request, it's retried automatically (up
to 3 times, resending the already-built request). If retries are also
exhausted: for a music download, skip to the next track in the list
(capped at 8 consecutive dead tracks so an unreachable network doesn't
spin through the whole playlist forever); for anything else, fall back
to the existing manual-cancel path.
Confirmed working on hardware.
Uncommenting it in int_text_on didn't fix the mouse cursor clipping
above the bottom panel (confirmed on hardware), and it was commented
out in the original code for presumably a good reason. Not worth
carrying an unexplained hardware-register change with zero upside.
Bottom control panel sat a couple pixels too low relative to the top
panel (pre-existing, not a session regression) - nudged GYOFFSL in
int_text_off from 47+240-1 to 47+240. Confirmed correct on hardware.
Also uncommented the TSU_SEN write in int_text_on so hardware sprites
(mouse cursor) are enabled during text mode too, not just graphics
mode. Doesn't fix the known cursor clip right above the bottom panel
(that appears tied to a fixed screen row, independent of panel
position or this bit - left as a known issue, documented in README).
show_now_play_link (blinking highlight for the currently playing track
in the list, plus the end-of-track autoplay/parse_url check) still ran
inside int_text_off via pt_play, doing its own extra page switch
(set_Textpage_lite) and an 80-byte write - on top of the analyzer this
was the remaining source of the vertical stripe flicker, specifically
when the playing track is scrolled into view. Split it out of pt_play
and call it from the main loop alongside the analyzer; the player tick
itself is untouched.
Confirmed on hardware: no flicker left, including across autoplay to
the next track.
The AY volume-bar indicator (music_analizator) ran inside int_text_off,
the same precisely-timed interrupt chain that switches between text and
graphics video modes. Its DMA clear + page switching + drawing could
overrun that timing budget on dynamic tracks, causing visible vertical
stripe flicker. Moved it to the main loop (once per frame, after
wait_frame) instead, leaving the player tick (pt_play) and its tempo
timing untouched inside the interrupt.
Also waits for the DMA clear to finish before drawing bars into the
same memory (previously a write race).
alex