search

keirf / flashfloppy

Floppy drive emulator for Gotek hardware
Other
1.33k stars 193 forks source link

TR-DOS SCL image format #145

Open xolod79 opened 6 years ago

xolod79 commented 6 years ago

Please add support SCL (ZX-Spectrum TR-DOS) image format. Description of the format Headline: +0, 8 bytes - SINCLAIR signature +8, 1 byte - number of files Data: Headers of files (14 bytes from the directory without track / sec): Title of the 1st file Heading of the 2nd and subsequent files (if any) File data: Code block of the 1st file Code block of the 2nd and subsequent files (if any) The last 4 bytes are the control sum (the arithmetic sum of all previous bytes). HxCFloppyEmulator_soft has the support of converting this format to HFE format. PRINCEPE.ZIP

keirf commented 6 years ago

Not really as this is not a block image format. Can you convert SCL to TRD using HxC software?

Alternatively I would need to do this conversion dynamically in firmware. Unlikely to happen.

xolod79 commented 6 years ago

Yes hxc software converts scl to trd. the scl format is very similar to trd and differs only in the first track which contains a list of files in which there is no only CHR location on the disks. and information about disks (9 sector).

xolod79 commented 6 years ago

TRD_Format.pdf Directory list simple copy from .scl 14 byte from every file and add: One byte - start sector (0..15) One byte - start track. And generate 8 sector(count from 0) directory specification. First 225 byte fill zeros +225 offset: first free sector - calculat +226: first free track - calculat +227: disk type = 22 (DS/80) +228: file count - max 128 +229: free sectors - 2 byte calculated +231: TRDOS ID - always 16 +232: 2 bytes zero +234: 9 bytes space (32) +243: 1 byte zero +244: 1 byte - deleted files - set statically zero +245: 8 bytes - disk label - set statically FFloppy +253: 3 bytes zero

For test purposes all calculated byte may set statics

Volutar commented 6 years ago

Non block images such as SCL still can be used as readonly images with ease. And SCL images actually are not meant to be writable.

Maybe it's not bad idea to support some formats in readonly mode?

xolod79 commented 6 years ago

I agree with you, readonly is enough.

Volutar commented 5 years ago

The main "issue" with SCL, is the absence of track/sector location for each file, and absence of "disk specification" sector (0:8). The length in sectors is enough, to calculate "original" actual file location. Since TRDOS file data is always starting with track1 sec0 (it is the rule), so the rest can be filled in on the fly. Disk type is always treated as 80 tracks 2 sides, but actual track number that SCL can give access to is not limited to 84 (so it can pass track number 210, which exceeds TRD format capability, and some images use that). Disk label can be taken from the image file name (or just filled with spaces, as most of emulators do), and first free track/sector also can be calculated (but in case of readonly mode it's irrelevant, as like as "free sectors").

Adding extra file to SCL image would require catalog area expanding, to fit extra 14 bytes for the file header, and CRC recalculating after adding actual file data to the end. So, generally, it would require whole image file rewrite (which is impractical). Thus it would be much more effective to add forced "readonly" mode for certain image types (SCL in this case). By the way, it would also make easier introducing of other disk image formats in "native" mode (simply by skipping writing mechanic - in most of cases readonly mode is enough).

SCL specs can be taken from here: http://www.zx-modules.de/fileformats/sclformat.html TRD (for comparison) is here: http://www.zx-modules.de/fileformats/trdformat.html