Bug in disassembly tab of Disc Image Displayer

[lurkio]

We've received a bug report from a user of bbcmicro.co.uk who was trying to use the Disassembly tab of the BBC Disc Image Displayer for the file $.GAME in the game Uridium:

http://bbcmicro.co.uk/explore.php?id=557

The user wrote:

If you download the game image and view it from any hex editor, the first 16 bytes of the file are 1A C8 91 1A 88 CA 10 E2 60 C0 24 EC 16 B8 5A 34

However when viewing from the screen dump [Disassembly tab] via the web page, the first 16 are 48 BA 86 43 A2 27 9A A5 03 29 20 F0 6D E6 41 D0.

The sane bytes are found at offset 0x1400 when viewed via hex editor. So the first 5120 bytes are missing when viewed from the hex dump [or Disassembly] tab.

... I'm porting the BBC version [of Uridium] to the Atari 8 bit

[richardtoohey]

That's strange - is it just this title or others as well? I'll have a look.

[richardtoohey]

It's the same issue as this one: viewtopic.php?p=281535#p281535

It is mis-identifying the disc type, so it is reading the wrong sectors.

Same sort of fudge works - if I change it to not think too hard about the disc type - it works - so that's definitely the problem.

I've rolled back the change for now, but that definitely made it show the correct data for the file.

dfs/dfscat.js

Code: Select all

function getFileData(catalogIndex)
{
        console.log('getFileData '+catalogIndex);
        var fileData;
        var fileItem = catalog[catalogIndex];
        var track=Math.floor(fileItem.startSector/10);
        var tracksect=fileItem.startSector%10;
        var startOffset;

        fileData = new Uint8Array(fileItem.fileLength);
//ddd=false;    
        if (ddd)
        {

So if I enable that ddd=false line, it will dump/disassemble start with &1A etc.

Looks like I said I'd look at it last year - still on the list, along with fixing some of the disassembly, along with pushing my changes to git. Maybe this year!

[lurkio]

Ah, well spotted! Yes, the two threads seem to be talking about the same issue.

But as far as the disc-images on bbcmicro.co.uk are concerned, isn't the most practical way to distinguish a .SSD from a .DSD just to look at the three-letter filename-extension?

All the .SSD discs on bbcmicro.co.uk have filenames that follow this pattern: DiscNNN-GameName.ssd

And all the .DSDs are DiscNNN-GameName.dsd

[richardtoohey]

I didn't like the idea because it doesn't help fix the shared code (well, somebody else's code, not mine.) Don't want to step on toes - not sure of the polite protocol.

But the more I think about it, why not just try a bbcmicro.co.uk fix that might do in the meantime (as you've suggested), and then take it from there.

So I'll give it a go.

[lurkio]

So I'll give it a go.

Thanks, Richard.

Yes, I think it's the pragmatic solution. And the original code was open-sourced on Github so I'm pretty sure you'll be okay to tweak it, especially as you'll be saving someone else the work! And it'll be a great benefit to all users of bbcmicro.co.uk to have the bug fixed (even if only with a stopgap) and to be able to see accurate disassemblies.

But if anyone has any objections or concerns about what we're discussing in this thread, I'd encourage them to post here and let us know.

[richardtoohey]

the original code was open-sourced on Github so I'm pretty sure you'll be okay to tweak it, especially as you'll be saving someone else the work!

Well, that's the protocol issue I'm concerned about - I'll be changing some code to make it work in one place, of no value (I don't think?) to anyone else using the open source code. The proper solution was discussed on the other thread - tweaking the detection heuristics.

But for people who just want it work on bbcmicro.co.uk I think the file extension will be a pragmatic fudge.

[richardtoohey]

OK, I've fixed fudged as suggested.

dfs/dfscat.js - lines 80 to 88 look at the file extension to decide what to set ddd to.

So I've left the existing logic for ddd there, this just overrides it.

Code: Select all

  76   networkGetBinaryBlob(diskPath)
  77     .then(function ()
  78     {
  79           checkDiskType();
  80             ext=diskPath.substr(-3,3);
  81             console.log(diskPath+' ddd is '+ddd+' ext '+ext);
  82             if (ext=='ssd') {
  83                     console.log('forcing ddd to false for ssd');
  84                     ddd=false;
  85             } else {
  86                     console.log('forcing ddd true for this file');
  87                     ddd=true;
  88             }
  89       decodeDiskCatalog();
  90       displayDiskCatalog();
  91     });

That makes this issue and the other issue (Boxer) go away. I've not tested any other discs.

This is not a proper fix but might be good enough for now.

[lurkio]

Richard, that's excellent. Thank you!