Crash when loading an Oric .DSK file

[Dbug]

I'm in the process of making physical versions of some Oric games, and since my target system are 3" floppies which have 42 tracks, it was not possible to directly transfer the files since they were made for 3.5" floppies with 82 tracks.

But since these games are only using a fraction of the available storage, my idea was just to format a new floppy in 42 tracks and copy the files, so what I did was to boot Oricutron with SEDORIC3.DSK in drive A, PULSOIDS.DSK (82 tracks) in drive B and UNFORMATED.DSK in drive C.

Then all I did is:

Code: Select all

INIT C,17,42,D
COPY "B-*.*" to C

Then I renamed UNFORMATED.DSK to PULSOIDS-42-17.DSK, rebooted the emulator on this floppy and validated that it worked just fine.

Loading each floppy shows the same content, just different number of tracks:

image_2025-09-12_195200040.png (37.6 KiB) Viewed 374 times

So as far as Oric emulators are concerned, this floppy is valid.

But when I tried to load it in HxCFloppyEmulator.exe or hxcfe.exe it just exploded.

image_2025-09-12_194904981.png (245.12 KiB) Viewed 374 times

I attached the two .DSK files in the zip archive if that can help diagnosing the problem.

[Jeff]

Why the 42 tracks DSK is sized to 1.6MB ? (this is related to the issue)

[Dbug]

Why the 42 tracks DSK is sized to 1.6MB ? (this is related to the issue)

Iss digged in the issue on his side as well: https://forum.defence-force.org/viewtop ... 182#p33182

Basically the problem is that when doing a formatting, the Oricutron emulator does not really know what the size of the file will be, so it allocates as "worth case scenario" disk.

Here are the actual details:
the main issue is in Oricutron - after any write operation DSK's size is automatically extended to:
2 sides * 128 tracks * 6400 bytes + 256 bytes header = 1638656 bytes!

So we end up with a 1.6 meg file with a header that indicates the actual number of tracks.

After patching the "42" to be "128" it loads properly in the HxC tool, but of course now it shows it's a 128 tracks file. I hope that when I try to send that to the Greaseweazle (using the .IMD format) it will just restricts itself to the 42 tracks I mention in the "write" command geometry parameters.

So is the HxC tool crashing because of the discrepancy between what the header says and the size of the file, or something else? I would have expected issues if the header was announcing more tracks than the file actually contained (like truncated file), but here, is it that the tool is trying to process the remaining dummy 86 tracks?

[Jeff]

This format doesn't have explicit track size information, so the software have to compute it from the file size and the number of tracks. if you give him a wrongly sized image there is no way to load this properly.

I agree that the software shouldn't crash. I will add some sanity checks to reject these corrupted images.

[Dbug]

Thanks

[Jeff]

Thanks

A question : Is there any image with a track size different to 6400 ? No protection support ?

Also : No HD support with this format ?

[Jeff]

Fixed :

https://github.com/jfdelnero/HxCFloppyEmulator/

will be included in the next release.

I finally don't reject the image but use the default 6400 bytes track size if something is not matching...

[Dbug]

Thanks

A question : Is there any image with a track size different to 6400 ? No protection support ?
Also : No HD support with this format ?

I checked the tools, they all use 6400:

Code: Select all

Format of a track:
6400 bytes in total
- gap1: 72/12 bytes at the start of the track (with zeroes)
Then for each sector:
- ?:             4 bytes (A1 A1 A1 FE)
- track number:  1 byte (0-40-80...)
- side number:   1 byte (0-1)
- sector number: 1 byte (1-18-19)
- one:           1 byte (1)
- crc:           2 bytes (crc of the 8 previous bytes)
- gap2:          34 bytes (22xAE , 12x00)
- ?:             4 bytes (A1 A1 A1 FB)
- data:          256 bytes
- crc:           2 bytes (crc of the 256+4 previous bytes)
- gap3:          50/46 bytes
  

and

Code: Select all

char header[256];
unsigned char trackbuf[6400];
(...)
  while (offset<6400) trackbuf[offset++]=0x4E;

Roughly the variants we can find for Oric in .DSK format:

• Exists in Single or Double sided variants
• The FDC supports 512 and 1024 bytes per sector, but for practical reasons (6502 processor) pretty much everything is in 256 bytes per sector
• The maximum number of tracks is 42 on Microdisc (3" drives) or 82 (for people who installed a 3.5" drive)
• There's no HD support that I know of.