Supported disk image formats and detection logic.

User avatar
JamesH
Posts: 56
Joined: Sat Dec 26, 2020 11:41 am
Has thanked: 5 times
Been thanked: 15 times

Supported disk image formats and detection logic.

Unread post by JamesH »

Disclaimer: this is absolutely useless and I am doing all of this due to the excessive amount of free time I had during the long weekend :)

I am not quite good at reading VHDL/Verilog so I'd appreciate any help here. Could someone point me to the code handling various disk images, please? Is it done in the core or in the main MiSTer programme? Specifically, I am wondering how IMG and MGT detected as they have no any kind of magic bytes.

Here is the full story. I was playing with different Plus D configurations and found a curious thing. Knowing how boot.rom is configured, I decided to try BetaDOS and Uni-DOS. BetaDOS worked as expected (yeah, I can see those familiar with BetaDOS chuckling here), but with Uni-DOS I stumbled on a weird issue. No matter what I did I was getting "Sector Missing" error. For G+DOS and BetaDOS I was using MGT images built with FUSE. However I had downloaded Uni-Dos.img, which was an IMG file. And down the rabbit hole I went, exploring IMG, MGT, (E)DSK and TRD image formats. Even wrote my own converter from MGT to IMG because I could not find one.

Both G+DOS and BetaDOS were working fine with both IMG and MGT images. Any combination works, e.g. I can boot G+DOS/BetaDOS from and MGT image, mount an IMG and successfully launch an app. However, a few evenings later, when I was desperately trying all permutations of ROMs and disk image formats, I found a combination which sort of enabled Uni-DOS boot. And I do not understand how it works. So Uni-DOS boots ONLY if I use CPC ESDK format. IMG or MGT, known to work as "tested with FUSE", they do not work with Uni-DOS ROM. But if I use Uni-DOS as an image with (E)DSK format, it boots and at least it reads the root catalogue. It still fails to run programmes accessing disk via the (BASIC) API or using subdirectories, though. My guess is that Spectrum core somehow "misunderstands" that specific image format (because of the Uni-DOS directory structure?) and applies different sector/track reading logic.

Hence, the question: how does the image format detection work? Does it actually try reading G+DOS filesystem (and, thus, incompatible with any other filesystems)?

User avatar
pgimeno
Top Contributor
Posts: 709
Joined: Thu Jun 11, 2020 9:44 am
Has thanked: 277 times
Been thanked: 226 times

Re: Supported disk image formats and detection logic.

Unread post by pgimeno »

I'm not sure, but it appears to be a Main_MiSTer thing.

https://github.com/MiSTer-devel/Main_Mi ... e.cpp#L103

User avatar
JamesH
Posts: 56
Joined: Sat Dec 26, 2020 11:41 am
Has thanked: 5 times
Been thanked: 15 times

Re: Supported disk image formats and detection logic.

Unread post by JamesH »

Oh, thanks. That looks like something related to TR-DOS, though. But I found something suspicious in wd1793.sv, which doesn't appear to be the right place either. Plus hardware is supposed to use NEC 765 (u765.sv), doesn't it?

Anyway, I am far beyond my comfort zone and I am afraid it has zero value for anybody else. I guess I'll keep learning VHDL, then :)

Thanks!

User avatar
pgimeno
Top Contributor
Posts: 709
Joined: Thu Jun 11, 2020 9:44 am
Has thanked: 277 times
Been thanked: 226 times

Re: Supported disk image formats and detection logic.

Unread post by pgimeno »

Maybe post here for help?
viewforum.php?f=28

User avatar
JamesH
Posts: 56
Joined: Sat Dec 26, 2020 11:41 am
Has thanked: 5 times
Been thanked: 15 times

Re: Supported disk image formats and detection logic.

Unread post by JamesH »

Good idea, thanks! Posted a question there.

Post Reply