search

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 57 forks source link

Strange OSWORD &7F problems with latest master on model B with Acorn 1770 DFS #169

Open ZornsLemma opened 2 years ago

ZornsLemma commented 2 years ago

I have been seeing some odd behaviour with this; sorry this isn't a nice simple isolated test case but I am in the middle of chasing another bug down so I wanted to raise this ASAP before I forget. It's possible this is a bug in my code but this has been working for a while. I will try to come back to this later and narrow it down further.

Using latest master (199eb4ab1e5f982c3434e80c6d71b3dfb8a628ca), if you boot the attached .dsd on an emulated Master 128 and press SPACE at the menu to load the game, it works fine. If you do the same on a BBC B with Acorn 1770 DFS, it says "DATA not found" when you press SPACE.

Using commit 4999ee3425279310034b6a1f6281e5002a41bab2 (on the sf/autopause branch; this is where I happened to be before I updated to latest master), the game runs fine on a BBC B with 1770 DFS.

What seems to be happening is that OSWORD &7F (which is supposed to be reading drive 0 track 0 sector 0) is returning the wrong data.

the_job_R4.zip

SteveFosdick commented 2 years ago

I think I can see what is happening here. If I enable debug on VDFS, I get this in b-emlog.txt:

27/04/2022 20:45:00 DEBUG vdfs: rom service a=08, x=0E, y=22
27/04/2022 20:45:00 DEBUG vdfs: osword 7F: cmd=53, track=0, sect=0, sects=2, ssize=256
27/04/2022 20:45:00 DEBUG sdf: drive 0: seeking for side=16, track=0, sector=0 to 3584 bytes

Side 16 doesn't look right.

SteveFosdick commented 2 years ago

I have pushed a commit to master which fixes this by taking only bit1 of the drive byte provided in the OSWORD 7F control block as the side rather than the whole of bits 7-1 (bit 0 being the drive).

What this doesn't explain is why VDFS is processing an OSWORD 7F call at all. That is all tried up with one of the 2nd processors, probably the Z80, and the client ROM concerned issuing OSWORD 7F when DFS was not the current filing system possibly ADFS for the CP/M hard disc BIOS. DFS uses some of the shared workspace to process OSWORD 7F even when it doesn't own it which can cause corruption. There are patched versions of DFS that don't do this by not responding to OSWORD 7F when not the current filing system. VDFS can service OSWORD 7F for cases where DFS does not, but if it is in the ROM list above DFS in priority, it ends up doing so even when DFS should be handling it. This probably needs little more refinement.

ZornsLemma commented 2 years ago

Thanks for getting back to me so quickly on this! I've just built the latest master and it fixes the problem for me; I will keep using this and let you know if I find any other problems.