Vic Chwe

Attached is the latest revision, rebased on top of d386d2017a741a537c74382cc1f01546e1eb287c (libspectrum codebase). rw-multiple-block-r3.diff is just a diff, and the ZIP contains a proper commits generated by git format-patch.

+1 to that :) While #442 is not perfect, I keep using it and just rebased on top of 1.10.0.

Latest patch, less changes than I wanted to add. Yet, I am using it to develop ZX MIDI Player and MRF with physical hardware. Rebased on top of 43810279d09cd40f46907d7d1d902c4e5ee4648a, which is the current HEAD as of Oct 18th, 2026.

Tested official Windows build inside Wine. It's tricky to get working, but once configured properly it works as expected. In addition to "2048 bytes long; expected 16384 bytes" bug, I was not able to use command line to launch FUSE, it constantly says "couldn't find ROM 'uspeech.rom", and no, full path did not help. I'll post all details on SC forums shortly. TL;DR: configure ROMs using GUI and only after that turn on uSpeech.

I think it still works. At least for me. It was the first thing I tried once I've got 1.7.0 flatpak installed. It needs ROMs, and I think the name for sp0256 ROM has changed slightly, but once they provided it works. I'll see if I can get to SC forums. The best way to test would be something like (assuming both ROMs are in the current directory): fuse -m 48 --tape Booty.tzx.zip --uspeech --romsp0256 sp0256-al2.rom --romuspeech uspeech.rom $ sha256sum Booty.tzx.zip 68f87e7f94f36cd7e054d179279dff42ce0cc978ea0f76896c1cce4bb763d612...

I have totally missed the fact that IF1 ULA detects the falling edge of the byte leader pulse, thus providing hardware synchronisation for every byte. With that in mind, "playback" works and broadcast transmissions are working, too. Code is nice and clean and I like it. However, there is a significant (~5 msec) delay before the receiving machine sees inbound data and it breaks everything because at the time receiver sends ACK back to the sender the sender has already started re-transmission. Latest...

Most of the programmes (I've seen so far) utilising CMD18 and CMD25 seem to expect Z-Controller SD card interface, and those appear to be using quite a lot of SPI mode commands. Next revision of the patch, adds basic support for CMD16 and CMD59.

SD Card: multiple block read/write support