stardot / b-em

An opensource BBC Micro emulator for Win32 and Linux
http://stardot.org.uk/forums/viewtopic.php?f=4&t=10823
GNU General Public License v2.0
112 stars 56 forks source link

OSWORD &7F read sector is 4x faster on BBC B than Master 128 #179

Open ZornsLemma opened 1 year ago

ZornsLemma commented 1 year ago

The attached .ssd contains a BASIC program which uses OSWORD &7F to read an entire 200K DFS disc's contents sequentially, 512 bytes at a time. Just to show it's doing something it loads the data into the top half of the mode 7 screen RAM, but that's not actually important.

It prints the track/sector numbers as it's going then at the end it prints the elapsed time in centiseconds. I haven't actually used a stopwatch to confirm these times, but it's obvious from watching as the program runs that the effect is real and not due to interrupts stopping TIME incrementing.

Using commit cffa3a5bc593f3d4097a56d6952a9062122aaf9a:

I don't have any real hardware to hand, but I don't think this is realistic. The Master's performance feels about right and the B's feels way too fast.

I don't think b-em should necessarily get too hung up about precise floppy performance emulation, but I do think the BBC B and Master 128 should have roughly the same performance.

(I noticed this while doing some benchmarking on Ozmoo, which uses OSWORD &7F to read the game data in from disc 512 bytes at a time. The progress bar on the loading screen just zooms along on a BBC B, even with 144K of sideways RAM to be filled.)

osword7fspeedtest.zip

SteveFosdick commented 1 year ago

I can reproduce this. What I think is happening here is that VDFS is intercepting the call to OSWORD 7F. Though that may seem a bit odd, the whole thing gets complicated.

You would expect DFS to respond to OSWORD 7F but many of the actual implementations do so even when DFS is not the selected filing system by tramping on workspace they don't own so there are some patched versions that ignore OSWORD 7F when DFS is not the current filing system.

That in turn makes CPM/M unusable with other filing systems. IIRC, I wanted a CP/M disc in drive 0 for CP/M but transfer files between ADFS/VDFS and CP/M. The solution was to have VDFS implement OSWORD 7F, which it can do without the workspace trampling. But, like the rest of DFS, it doesn't restrict the speed in any way.

The reason it doesn't happen on a Master is because the 1Mbit ROM has all the high priority slots. I will have a think about how to enable this behaviour by VDFS to be turned off.

ZornsLemma commented 1 year ago

Thanks for having a look! I am glad you could reproduce it - I was having some non-b-em-related problems with my PC at the time and I had a nagging suspicion it was some really bizarre interaction with those...

I would never have guessed that that was the explanation, but everything you say makes sense. It would be nice to have a "proper" way to disable this behaviour but now I know I guess I can just disable VDFS completely to work around it.

Just a random thought which isn't necessarily easy or correct: would it be possible for b-em to detect OSWORD 7F calls and explicitly save the DFS workspace before handing control to the DFS ROM and restore it afterwards? I suspect wiring that in would require all sorts of special case hacks though, whereas doing it via VDFS in a high priority ROM bank is nicely self-contained. Just possibly this could be detected by checking the program counter/old bank/new bank when &FE30 is used to page ROMs.

Edit: Or maybe b-em could use a patched DFS (if one exists) which doesn't have this bug by default in model B mode instead of the original Acorn version?

SteveFosdick commented 1 year ago

I have implemented a fix in https://github.com/stardot/b-em/commit/9462cf3e928367b2c586f67498af2548ca98ed7d

It looks like it was intended that VDFS should only implement OSWORD 7F if it is the current filing system but the way it knows whether or not it is the current filing system changed at some point and this test was not updated.

ZornsLemma commented 1 year ago

Thanks! I've just built that and Ozmoo no longer loads at turbo speed on a model B. I've also tried the test I attached to the first post in this thread and that behaves more reasonably as well. (I do note that it's faster on a B with 1770 than a Master, and faster still on a B with 8271, but not dramatically so. 42s (B-8271) v 48s (B-1770) v 55s (M128) if memory serves. I don't think this is a big deal, but I thought I'd mention it.)

I'll keep using this build and let you know if it plays up, but I'm sure it won't.