dfscat bug fixed

[pau1ie]

Thanks to Shawty for passing on a report of a bug I had introduced to dfscat (AKA the explore button). It only supported ssds, so I was trying to introduce support for dsds. In the process I broke ssds, meaning long files had bits missing out of the middle. I think I have fixed that bug now.

[joachim]

I'm still seeing an issue similar to this. If you go to Boxer (http://bbcmicro.co.uk/explore.php?id=148) and view the hex dump of $.BOX, you can see the dump of the game instructions but they appear to cut off suddenly at &0700 after the text "Every time you get three falls" and are followed by garbage. But if you load the disc into jsbeeb and *DUMP $.BOX then you can see that the instructions should continue past this point.

[richardtoohey]

It's working for me - the $.BOX hex dump - displays fine after &700 to the end of the file.

Maybe somebody has fixed something? Or I'm looking at the wrong thing?

EDIT but now it's not working or I was imagining things!...

EDIT it seems to decide this is a double-density disc which is wrong. But I'm not sure what this code is doing so need to do some more R&D.

Just before the end of the function - if I force ddd=false (double density/sided(?) disc) then the $.BOX hex dump works fine.

Code: Select all

function checkDiskType()
{
        checklocs = Array(parseInt('0x001',16),parseInt('0x002',16),parseInt('0x003',16),parseInt('0x004',16),
                                          parseInt('0x005',16),parseInt('0x006',16),parseInt('0x007',16),parseInt('0x008',16),
                                          parseInt('0x009',16),parseInt('0x00A',16),parseInt('0x100',16),parseInt('0x101',16),
                                          parseInt('0x102',16),parseInt('0x103',16));
        var dfs=true;
        var imgsz;
        var j,k,l,m,o,p;
        var offset=parseInt('0xA00',16);
        ddd=true;
        for (i=0; i<checklocs.length; i++) {
                j=getEightBitValueFromBinary(checklocs[i]);
                if (j > 127 || ( j > 0 && j < 31 )) {
                        dfs=false;
                }
                j=getEightBitValueFromBinary(checklocs[i]+offset);
                if (j > 127 || ( j > 0 && j < 31 )) {
                        ddd=false;
                }
        }
        j=getEightBitValueFromBinary(parseInt('0x105',16));
        k=getEightBitValueFromBinary(parseInt('0x106',16));
        if (j&7 || k&parseInt('0xCC',16))
        {
                dfs=false;
                ddd=false;
        }
        l=getEightBitValueFromBinary(parseInt('0x105',16)+offset);
        m=getEightBitValueFromBinary(parseInt('0x106',16)+offset);
        o=getEightBitValueFromBinary(parseInt('0x107',16));
        p=parseInt('0x100',16);
        if (l&7 || m&parseInt('0xCC',16) )
        {
                ddd=false;
        }
        imgsz=(o+256*(k&3))*p;
        console.log("Image size: "+ binaryDiskBlob.byteLength + "; Sectors*Tracks: "+imgsz);
        if (dfs) console.log("DFS Disc");
        ///ddd=false;
        if (ddd) console.log("Double sided disc");
}

[joachim]

Thanks Richard. At a glance it looks as if that code is doing a few light checks to see whether sectors &A and &B look like a valid DFS catalogue, which they would need to be if it's a .dsd image and they are the sectors &0 and &1 of side 2.

But it's only checking whether the disc title is made of printable characters, plus a few more bits in the catalogue header which are unused and supposed to be zero, so there's a significant risk of false positives (especially since I think a run of zeros would pass the tests).

[richardtoohey]

Thanks; definitely false positives.

I'm trying to marry up the code with what you've said and this: http://beebwiki.mdfs.net/Acorn_DFS_disc_format

[lurkio]

I'm trying to marry up the code with what you've said and this: http://beebwiki.mdfs.net/Acorn_DFS_disc_format

I wonder if this is of any use? It's something I emailed Mike Wyatt ages ago when he asked if I had any ideas for improving Win BeebEm's detection of DSDs masquerading as SSDs, which was resulting in some false positives at the time (and maybe still does?) -- so I came up with this crazy idea:

I just thought of another thing you might add to the battery of tests that look for a DSD disguised as an SSD.

The Advanced Disk User Guide by Colin Pharo says that byte 05 of the second catalogue sector of a disc-side should contain eight times the number of files on that side of the disc.

If we can be sure (dunno if we can) that the unused bytes in the catalogue sectors will be zeroed out, then, provided that the disc-side contains less than the maximum number of files, we can count the number of "file entries" in sectors 0 and 1 (which should obviously be the same) and then compare that number with byte 05 on the second catalogue sector.

Sounds like the idea might be flawed in that it relies on the catalogue not being full..? Not sure. Maybe it's rubbish. Anyway, just thought I'd mention it.

[richardtoohey]

See also: viewtopic.php?p=307299#p307299