*embarrassed look* I had the speaker pulled when testing most of yesterday.
I find that when I use a drive with the blinking LED, the delay between the boot loader handoff and "starting DOS" usually involves one or two "drive goes off, then on" cycles; This is the OS calling "reset disc system" BIOS call, and this BIOS honouring the request and resetting the CH375/6. (I figure at some point, there will be code that actually uses that to recover from a surprise condition).
You could patch around the SILENT_RESET section of the code, to instead perform the "Send 57, expect A8" check first... then a "wake and sane" CH375/6 can skip the entire reset-and-wait process and go straight to detection, to shave a few seconds.
WRT the clicking: I've tried to adjust it to leave the timer in square-wave mode, which means it (should) count down by twos (so the delay count probably needs to be higher; I've defaulted to 10 for now). I figured maybe it was producing weird results because the timer mode was being changed. I also reduced the amount of poking at port 61, so hopefully less chance of accidentally enabling the speaker. On my setup, it doesn't click right now, but I don't make promises. Part of the reason I have the speaker removed much of the time is that my machine has a not-quite-compatible port 61 implementation that results in the speaker doing weird stuff, mostly staying on unwanted.
Was it a single click, or a "brrrr"? I was able to get "brrrr" by accidentally turning the speaker on in the middle of the delay logic, but I don't think the code was intentionally built that way.
There's also some rework intended to improve the quality of the "get capacity" behaviour, replacing some "spin forever waiting for the right answers" code with some more formal "wait for interrupt and check status" behaviour.
This was triggered when I found at least one model of flash drive doesn't like the DISK_SIZE call and just returns status 82 forever. Apparently some drives will fail the DISK_SIZE call have to have the R_SENSE call performed to get their error status and then they respond correctly. We also have a fallback after enough failures, where it says "if you won't tell us, assume 504Mb". The drive may be borked there, though, since it's probably going to blow up at the next command given.
I note the drive worked fine a while ago, when I was using the CH376 commands, maybe there's enough behaviour or semantic difference that the forced R_SENSE was not needed.
... so anyway, here's
Wonderwall ... v0.83
https://gitlab.com/hakfoo1/v40-bios/-/blob/main/disc.asm
Note the seperate "CH375 adaptations" branch is now merged mainline.