BeebEm ADFS disc access bug?

want to talk about MESS/model b/beebem/b-em/electrem/elkulator? do it here!
Post Reply
User avatar
jms2
Posts: 1970
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK
Contact:

BeebEm ADFS disc access bug?

Post by jms2 » Mon Jan 15, 2018 10:53 pm

I've been experimenting with using BeebEm to access hard disc images, as a way of transferring files onto my BeebSCSI system. In general it works, and I'm enjoying using ADFS 'properly' for the first time on an 8 bit machine. I'm still not a big fan of it, but we're making progress...!

However I have found what appears to be a weird bug in BeebEm (versions 4.13 and 4.14). I've been using Master mode as it has ADFS built in, mounting Electron ADFS images and using *COPY to move files to the hard disc. I knew that games probably wouldn't work on the emulated Master, but I wanted to see if the floppy-based games would at least start loading properly from hard disk (or did they assume they were running from $). So I tried booting the Electron version of Play It Again Sam. However, it crashes with Bad Program at the first BASIC loader program, called "MENU". This seemed odd.

If, in BeebEm, you mount the Electron ADFS version of Play It Again Sam (from STH), then just try to LOAD"MENU" you get the error "Bad Command". *DUMPing the file shows that it is just random data.

Doing the same thing in either Elkulator or B-Em in Master mode works absolutely fine, and the file is readable BASIC. So they behave completely differently to BeebEm, just in trying to load a BASIC file from ADFS floppy.

Not every file seems to get corrupted in this way - I've transferred Crazee Rider and it plays fine on the Electron. Codename Droid loads the black background is corrupted.

Have I stumbled across an obscure bug here? I'm not having a lot of luck recently!

User avatar
jgharston
Posts: 3062
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: BeebEm ADFS disc access bug?

Post by jgharston » Tue Jan 16, 2018 1:47 am

You're not alone. Every now and then when I use ADFS to access a hard drive image and get Bad directory when mounting. I can't rememebr the exact circumstances when it happens, and I can't remember what I did to fix it. I wonder if it might be when I copy the image to another machine, update it, then copy it back later.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
jms2
Posts: 1970
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK
Contact:

Re: BeebEm ADFS disc access bug?

Post by jms2 » Tue Jan 16, 2018 6:59 am

It's reassuring to hear it isn't just me!
Just to be clear though,
- this bug appears to be totally repeatable (if using this specific floppy image)
- and it doesn't actually relate to the hard disc at all. You don't need to switch hd support on to get the bug to appear.

I'd switch to using B-Em for transferring floppies to beebscsi, but as far as I can see it doesn't support SCSI images.

User avatar
hoglet
Posts: 7126
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: BeebEm ADFS disc access bug?

Post by hoglet » Tue Jan 16, 2018 7:57 am

Can you detail the exact steps to reproduce this error, and also post the disk image you are using?

What version of BeebEm are you using.

It does seem rather weird...

Coeus
Posts: 779
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: BeebEm ADFS disc access bug?

Post by Coeus » Tue Jan 16, 2018 12:45 pm

jms2 wrote:It's reassuring to hear it isn't just me!
Just to be clear though,
- this bug appears to be totally repeatable (if using this specific floppy image)
- and it doesn't actually relate to the hard disc at all. You don't need to switch hd support on to get the bug to appear.

I'd switch to using B-Em for transferring floppies to beebscsi, but as far as I can see it doesn't support SCSI images.
Version 2.2 of B-Em doesn't have SCSI hard disc support but the master branch at https://github.com/stardot/b-em does. I was going to warn you that it is ported from BeebEm but then I notice your issue with BeebEm is with ADFS floppies and the modules for floppy access in B-Em BeebEm were developed independently. There has been no official release that includes this SCSI support, and thus no accompanying Windows executable, but there are a couple of pre-releases on that GitHub that include a Windows build which will contain the SCSI code - either the NULA or M2000 ones. See also my thread on what has changed in B-Em since the 2.2 release.

It would still be good to work out what the bug is, though, so please do respond to Hoglet's request.

g7jjf
Posts: 359
Joined: Sun Aug 07, 2005 7:29 pm
Location: Notts, England
Contact:

Re: BeebEm ADFS disc access bug?

Post by g7jjf » Tue Jan 16, 2018 7:08 pm

The problem seems to be with the disc image.

The image is reporting as a double sided disc although the image is actually single sided.

Changing byte 0xfd of the image from 0x0a to 0x05 converts it back to a single sided image and BeebEm then works fine with it.

Jon

User avatar
jms2
Posts: 1970
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK
Contact:

Re: BeebEm ADFS disc access bug?

Post by jms2 » Tue Jan 16, 2018 8:48 pm

g7jjf wrote:The problem seems to be with the disc image.

The image is reporting as a double sided disc although the image is actually single sided.

Changing byte 0xfd of the image from 0x0a to 0x05 converts it back to a single sided image and BeebEm then works fine with it.
Well done Jon! Although this must surely still be a bug in BeebEm, as it does not affect a real machine or the other emulators.

This is what to do to provoke the bug. The following instructions work equally well in any emulator, so I suggest you try B-Em or Elkulator first just to prove to yourself that the disc image is actually OK! Then try BeebEm. I've used version 4.13 and 4.14.

- Start emulator
- If using a BBC emulator, switch to Master mode and do *ADFS. Elkulator starts in ADFS automatically (well, mine does anyway)
- Insert this disc image into the emulator
PIAS-ADFS_E.zip
(73.4 KiB) Downloaded 17 times
- *MOUNT 0
- LOAD"MENU"
- LIST

On anything except BeebEm this will produce a listing. On BeebEm it will generate 'Bad Program' after the LOAD command.

User avatar
jms2
Posts: 1970
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK
Contact:

Re: BeebEm ADFS disc access bug?

Post by jms2 » Tue Jan 16, 2018 9:01 pm

I've tried changing byte offset FD from 0A to 05, and whilst this does indeed allow MENU to be loaded, it creates another problem which is that *RUN !BOOT gives the message "Bad FS map". *DUMP !BOOT has the same effect, in fact just *ADFS does it as well.

So I think that this image perhaps has other problems. The same occurs in Elkulator so this is something which affects the image, not BeebEm.

Coeus
Posts: 779
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: BeebEm ADFS disc access bug?

Post by Coeus » Tue Jan 16, 2018 10:25 pm

jms2 wrote:On anything except BeebEm this will produce a listing. On BeebEm it will generate 'Bad Program' after the LOAD command.
Interestingly, on the git master B-Em this also produces "Bad Program". In the log it also produces the following:

16/01/2018 21:56:45 INFO Loaded drive 0 with ... discs/PIAS-ADFS_E.adf, format Acorn ADFS L, double-sided, interleaved, 80 tracks, double-density, 16 256 byte sectors/track

If I change the byte at FD from 0A to 05 and reload the disc image it logs:

16/01/2018 22:01:44 INFO Loaded drive 0 with ... discs/PIAS-ADFS_E.adf, format Acorn ADFS M, single-sided, 80 tracks, double-density, 16 256 byte sectors/track

and now loading MENU works. This is because this version of B-Em now tries to work with a larger set of disc formats and looks into the disc contents to infer how the sectors and even the sides are laid out on the disk. In this case, after discounting the new ADFS formats (with the Nick signature), it checks for Hugo at &0201 and again at &06FB. If it finds those it then reads the three-byte sector count from &00FC and looks it up in the following table:

Code: Select all

static const geometry_t adfs_old_formats[] = {
    { "Acorn ADFS L", SIDES_INTERLEAVED, DENS_DOUBLE, 2560, 80, 16,  256 },
    { "Acorn ADFS M", SIDES_SINGLE,      DENS_DOUBLE, 1280, 80, 16,  256 },
    { "Acorn ADFS S", SIDES_SINGLE,      DENS_DOUBLE,  640, 40, 16,  256 },
    { NULL,           SIDES_NA,          DENS_NA,        0,  0,  0,    0 }
};
The number columns to the right are total sectors, tracks, sectors/track, sector size.

At this point, if it were a DFS disc, it would test the location of the side 1/3 catalogue to work out whether the sides of the disc are interleaved in the image file or sequential so interleaved would be side0track0, side1track0, side0track1 ... etc. whereas sequential would be side0track0,side0track1 ... side0track79,side1track0, side1track1... etc. There doesn't seem to an equivalent test for ADFS so it has to assume the two sides are interleaved as this is by far the more common way of storing floppies in an image file.

It is the interleaved sides thing that is causing the issue with reading the wrong data. Essentially anything on side 0 track0 will be readable either way but if the emulator thinks there are two sides interleaved and there are not then anything after that the wrong data will get read. What is worse is that if you then write to the disc the data will be written to the wrong place and then you would find it corrupt even on an emulator that has its geometry correct.

So, back to the question of whether this an emulator bug, you could look at this more than one way. The image file has some inconsistency about in that extension and the size of the image file itself suggest SS/DD but the sector count within it says DS/DD. In this case the extension appears to be correct but that could equally well be wrong on another image in which case the approach taken in the newer B-Em, and probably in BeebEm too, would work and those emulators which rely on the extension would be the ones to have problems.

I am curious as to how the image file happened to get in this state. My guess would be that the original floppy was actually double sided but the amount of data on it would fit on the first side especially after compaction so someone thought it would be sufficient to image only the first side without changing the internal sector count.

Coeus
Posts: 779
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: BeebEm ADFS disc access bug?

Post by Coeus » Tue Jan 16, 2018 11:21 pm

jms2 wrote:I've tried changing byte offset FD from 0A to 05, and whilst this does indeed allow MENU to be loaded, it creates another problem which is that *RUN !BOOT gives the message "Bad FS map". *DUMP !BOOT has the same effect, in fact just *ADFS does it as well.
I realised I had not answered this bit. The "Bad FS map" error occurs because the free space map has a checksum in each of its sectors and the sector count change to force the disc to be considered single-sided is in sector 0, part of that free space map. The checksum at &00FF would need to be re-calculated to include the changed value.

And what do you make of this:
ss.png
This is after changing the "total number of sectors" count to force it to be considered single-sided. The number of used sectors is the result of subtracting the number of free sectors from the total number of sectors and, in this case as the number of free sectors recorded in the free space map is larger than the new total number of sectors this would give a negative number, except here is displayed as unsigned. So in this respect the FS Map very much says double-sided despite the contents of the image file not matching.

Coeus
Posts: 779
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: BeebEm ADFS disc access bug?

Post by Coeus » Tue Jan 16, 2018 11:44 pm

So, after all that try the attached image. This has the sector count back to the original value but has the missing second-side tracks inserted thus:

Code: Select all

$ i=0
$ while [ $i -le 79 ]
> do
> dd if=PIAS-ADFS_E.adf bs=4096 count=1 skip=$i
> dd if=/dev/zero bs=4096 count=1
> let i=i+1
> done > PIAS-ADFS_E.adl
Attachments
PIAS-ADFS_E.zip
(74.95 KiB) Downloaded 16 times

User avatar
jms2
Posts: 1970
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK
Contact:

Re: BeebEm ADFS disc access bug?

Post by jms2 » Wed Jan 17, 2018 12:15 am

Great work, thanks!
I'll try this out tomorrow.

User avatar
jgharston
Posts: 3062
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: BeebEm ADFS disc access bug?

Post by jgharston » Wed Jan 17, 2018 1:26 am

jms2 wrote:It's reassuring to hear it isn't just me!
Just to be clear though,
- this bug appears to be totally repeatable (if using this specific floppy image)
Wait a bit, you said "accessing hard disk images".
jms2 wrote:- and it doesn't actually relate to the hard disc at all. You don't need to switch hd support on to get the bug to appear.
So it *isn't* accessing hard disk images. I've never had problems with ADFS ***FLOPPY*** images, just occasionally ADFS ****HARD**** ****DISK***** images.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
jms2
Posts: 1970
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK
Contact:

Re: BeebEm ADFS disc access bug?

Post by jms2 » Wed Jan 17, 2018 6:35 am

Yes that's right - I have not had any problems accessing hard disk images, only this one specific floppy disk image. As Jon and Coeus have demonstrated, it's actually a corrupt image. BeemEm responds to this corruption a bit differently to the other emulators, which may be a bug.

You brought up the possibility of a bug with hard disk images, which at the time I thought might be related to my issue in some obscure way (which is why I said "I'm glad it's not just me"). However it now looks like these two things are entirely unrelated.

I discovered the problem with the floppy image when transferring files to a hard disk, which is why hard disks got mentioned originally.

User avatar
jms2
Posts: 1970
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK
Contact:

Re: BeebEm ADFS disc access bug?

Post by jms2 » Wed Jan 17, 2018 7:45 pm

The fixed disc image works! More importantly, the games work when put onto the hard disc as well.Thanks everyone :D

Post Reply