Perhaps to Michael's chagrin
Thanks for adding that word to my vocabulary. Rare enough, but sometimes I have to pick my dictionary, and the (also stylistically) matching translation would be "Verdruss" in German.
Being a big boy, I'll get along with it. No, honestly, it's not a big issue, and you said you have a recent release in parallel. I'd just like to add some points that I find important to say:
In general, software is evolving, and features are added, removed, or fixed over time. Using an old release means that you deliberately stick to some past snapshot of the software. If you find issues, maybe instabilities, a missing feature that was later added, you could wish to have your particular release amended to your wishes. This may sound much easier than it actually is. Some features may have become obsolete by changes in the core, other may have become available just because the core was updated. Not only for open-source software but also for typical, commercial software, backporting is a difficult job, and in most cases it cannot be done, at least not with considerable efforts. These efforts multiply when people even have different past releases. It should therefore be understandable that on every encounter of an issue, my first question will be: Are you using the latest release?
A critical point is the data exchange. Formats have changed over time, and they may be unusable for one or the other release. Floppy formats like HFE were added, track dumps fixed, sector dumps did not change, hard disk formats have changed from sector dumps to CHDs of version 4, then version 5. Data processed on one release may be unreadable on a much older or newer release. For instance, you may be unable to use hard disk images in the old releases that have been recently created, and vice versa. Only the sector dump images of floppies remain for exchanging data. As I said in 1., I cannot backport these formats to the old release, mainly because they depend on other features in the core.
Most of us are writing software or creating hardware with no or little refund for the efforts, apart from the appreciation of others. It is not always clearly visible from the user perspective what has actually changed, so a user tends to evaluate it from his own view - what has improved for me? I'll not cite MAME's mission again, already sounding like a mantra ... I'd be happy if people remember it when there are changes that are not primarily improving their personal usage experience.
Concerning the floppy emulation, the primary objective was not to make it as slow as in reality. In fact, there are systems with quite sophisticated copy protections - we already talked about that. In particular, some systems measure the time between the index hole and a specific sector they are locating on the track - in milliseconds. One of the developers - not me - rewrote the floppy emulation and developed this highly precise system, which I consider one of the most brilliant parts of MAME. He even used a "time machine" which can travel back in time to synchronize events, at least on that current track. In consequence, the disk controller chips could be rewritten to allow for a precise emulation of their internal behavior with all state machines and so on. Hence, floppy systems run at their exact speeds, and cannot be sped up like before (unless you added a complete second path with stripped-down controllers, simplified data paths etc.).
The floppy sounds were only possible after the drives were ensured to run at real speeds, of course. It took me some weeks to write the support, and hours of recording samples of a floppy put into a cardboard box, together with a high-quality microphone. On Ninerpedia I reported about the difficulties to get a somewhat realistic output from these samples, since the first attempts were, let's say, not really satisfying (sucked completely). As I said elsewhere, I may now have a good chance to recreate the samples at different step rates in a quiet environment (without a running PEB). I'm not sure whether some people believe that the samples make the emulation slower, but this is clearly not the case; when you turn them off, they won't speed up, it's just quiet. Actually, I'm thinking about recording sound from my ST-512 MFM drive also. Maybe we can arrange that when time has come, the first response to me will not be "how can I turn them off?". This can be done the same way like turning off the floppy drive sounds. Talking about appreciation.
I wonder how much time you actually save by the untimed floppy access in the old releases, compared to the MFM drive connected to the HFDC in modern releases. I've been doing some development as well, and I never really felt uneasy during the assembling process - maybe because I expect the process to take exactly that time (I would feel bad if it was much faster, as I do now after learning that the v9938 emulation is significantly faster than on real iron.) Sometimes I believe this is similar to people sitting in their cars on a congested street, having a feeling like this should be going much faster, even when they are not heading for an appointment.
Consequences? I'll be continuing as before. Currently I'm sitting at the HX5102, and I already made it load a program on the 99/8 (internally), but it failed to send it over the Hexbus. I think it will not take too long until we can save Extended Basic II programs. On recent MAME releases, of course.