Okay, a more interesting experiment in user-friendliness:
GitLab.com
gitlab.com
Built as a separate branch because it's a bit of a high-risk offering.
At initialization, instead of having one or two drive ports hard-coded, it scans a list of them in the ROM and detects until it finds (at most) two drives. It currently looks on E0/E4 (where the Homebrew8088 boards load one), 260/262 (mostly so I had a known failure in between good detections to test that use case), 270/272 (where my AliExpress board that's been wired to support double-wide addressing lives), and 360/362 (so we could confirm that once we get to two good drives, we stop searching). This is sort of filler data until I can review the discussion and different cards boards and prepare a better list
This is nice, if (for example), you have one drive mounted internally, always there, and another with a drive that you remove sometimes and it shouldn't pretend there are always two drives, or so you don't have to burn a new ROM for every possible card. More practically, it means one or two ROMs (8-bit wide/16-bit wide) would support almost everyone out of the box, rather than having to reassemble for different port numbers only.
You still need to decide if you want 8- or 16-bit mode, and the real sin, however, is that we have to buy some RAM space to store the list of ports that actually contained CH37x units.
I chose to use some space in the BIOS data area 40:C0 through 40:C7 which is described as part of a 16-byte "NMI Scan Code Buffer (Convertible)" in
https://stanislavs.org/helppc/bios_data_area.html . Hopefully this means that as long as we're not on a PC Convertible, we're safe. Most of the real Convertibles seem to have been attacked by the Keyboard People already.
It could be done as a "steal 1kb of conventional RAM" but that seems an awful big cost to store 8 bytes of data.
The usual "this may catch fire and break everything, I take no liabilities and explicitly disclaim any warranty" disclaimer applies.
Note that this may also initialize a bit differently; so I didn't have to spend forever waiting for initialization to spin on the ports that don't have CH37x units, it a check-for-life that was normally done 200x only 2x. Still seems to work for real hardware, but maybe it should be a tunable later.
Note this also adds a bit to the ROM size, to where it's about 4115 bytes before packing. It should be possible to golf it down below 4095 again, but the default build has been allocating 6kb for quite a while.
Potential extensions would involve storing info for more than two CH37x units, which might involve changes to the logic that decides "is this a drive we service, or do we pass it back to the floppy controller INT13 handler" and "calculating the number of drives for INT13 function 8" stealing more RAM somewhere (4 bytes per device).