Well, the point of DISK_IN_BOUND was to be able to blow up early in a request if you asked for a sector beyond what the disc's reported geometry included. It may not be necessary, but I feel like it's reasonably appropriate, in case you have stupid software that says "I want to seek to cylinder 1000 of a 600-cylinder drive and I expect to get a rejection". I'm suddenly thinking of how (I think) Commodore drives would home themselves by just seeking a fixed number of tracks forward, even if it just caused the drive to bang against the end of its travel.
Since I have a day off, I spent way too much of it on some fairly significant retooling:
GitLab.com
gitlab.com
Highlights:
* It includes some of the speedup suggestions for 8088. A quick disktest run on a 4.77MHz, no wait states, no double-wide mode, on a nearly empty ~440Mb partition, gives ~139k read/write. YMMV; I've found that the IOPS scores in particular are very dependent on filesystem-related overhead (empty discs are faster). I wonder if smaller discs are faster for a similar reason.
* HUGE internal renovations to disc operations. It passes a lot of temporaries and variables relative to the stack at the moment we enter a function. This gives us much more flexibility to define extra "parameters" and "variables" without running out of precious registers.
* It tries to combine setup and teardown stuff for read/write/format calls. I had hoped this would reduce duplication, but I think we didn't save that much space. With full bells and whistles, I see 4416 bytes :/
* Rather than supporting a single command/data port pair, it tries to remain aware of DL (the drive selected), and look up referenced ports based on it. The short-and-long of this is that you can
try to configure it to support two CH37X modules. This was inspired by several people mentioning considering building dual-CH37X cards.
If you set COMMAND_PORT_2 and DATA_PORT_2, it will treat that as a "secondary" drive-- BIOS drive 0x81 requests will try to hit it. Note that it still expects COMMAND_PORT and DATA_PORT for a "permanent" drive, mostly because the detection logic is pretty basic and doesn't bother to try the second slot if the first one doesn't detect.
This is super-experimental because I cannot currently properly test it at the moment. The motherboard I use can accommodate one CH37X module onboard, and I'm waiting on an ISA card in the mail.
When I set both devices to the same ports, I was able to boot and see the "real" drive at C and E and the "second" one at D and F, but I'd be very hesitant to try playing with formatting or writing the drives in this scenario, as I suspect DOS would be surprised to see changes on one drive mysteriously appearing elsewhere. If someone has two CH375 cards, or a card and an EMM mainboard with CH37X module, they may be able to get a more realistic result.
I suspect it may be *marginally* slower than the original version, because the cleanup/teardown of read-write calls is a little more complex, and reading port stuff from the stack is a few clocks slower than reading immediates, but I'm hoping it's not noticable; the big I/O loop should still be the bottleneck. Since it;'s such a big change, it's in a seperate branch, and if it turns out a nightmare, we can ignore it.