Since 19.0 fullspeedwhenloading affects more than just loading

[sdsnatcher73]

With openMSX 19.0 if fullspeedwhenloading is set to true the following happens:

1. Boot into MSX Basic into a computer with disk drive
2. Insert a disk with some files on it
3. Run the FILES command
4. The MSX will list the files but also some extra new lines are printed (the number varies).

I suspect full speed is turned off too late (when BASIC is already back in control and it still finds the ENTER key being pressed from issueing the FILES command)

[m9710797]

The heuristic to detect loading (from disk) is based on the disk drive motor status.
On some MSX machines the motor-timeout mechanism is controlled via software (instead of a hardware timer). In that case I can indeed imagine the "we're-no-longer-loading" condition is detected too late. I'm not sure we can do much about that. Do you have any suggestion for a better heuristic? (Preferably easily implementable).
I suggest to not use "fullspeedwhenloading" on such a machine (when typing interactive commands).

[sdsnatcher73]

I haven’t tried it again on 18.0 but as I mentioned as far as I remember I never saw this behavior there.

I was using an FS-A1GT at the time (well most of the time).

Wouldn’t ooenMSX know when code is active in the diskROM? And enable full speed then and disable it when code is run outside the DiskROM?

[m9710797]

The idea for "fullspeedwhenloading" was to cover all "loading" code. So for example also the (short) code between loading one sector and the next. Or the part of the code that transfers the sector data from RAM to VRAM., Or decompression of the just loaded data.

In general this idea is not possible to implement exactly. Though the heuristic to keep loading mode active for a short while after the actual disk-transfer often seems to work well.

When reading your first post, I understood you first noticed this problem in version 19.0. But now I have the impression you think it's a regression compared to older releases. If so, it would be very useful if you could pin-point the version. Because as far as I know, we didn't change anything that could alter this behavior (but I'm not saying it's impossible).

[sdsnatcher73]

I have been working on a lot of disk versions that have been over time stored on 720kB disks. I modify the loaders to use the universal poke, use 360kB clean image to store the files. Remove any "cracked by" messages if present. All this to increase the compatibility of the disk version with as many MSX computers as possible. I don't always find the time to do this and there is still quite the backlog... I have been doing this in 18.0 for a while and I never ran into this issue. I noticed it right away when I started using 19.0.

I just downloaded 18.0 and the issue does not happen there, tried several times.

[MBilderbeek]

Hi

I also tried with both 19 and 18, but I see it in both cases.
It also depends how quickly you release the ENTER key.

With 18.0 I get one blank line below Ok, when I press enter the way I do. With 19.0 I get either 1 or 0...

So, if the problem became worse, I cannot reproduce it.

As you can reproduce it, please bisect it to find back the change that caused it.