ST images with 11 sectors - unreadable

[TzOk83]

ST disk images created in STeEM which have 11 sectors per track appear as empty or garbage in real Atari ST with Gotek/FF, however reported disk capacity is correct. Tested under TOS 1.06D and 2.06D. DD_80_11.zip

[keirf]

Thanks I'll check it out.

[TzOk83]

I don't quite get the SD/DD/HD/ED switching routine in img.c. At first I thought that in 11 S/T you may fall into HD, but from my calculations the limit seems to be 1025kB per disk (if tracklen is in bits). 2 sides, 84 tracks, 11 S/T, and 512 B/s gives 924kB, so it is below threshold. Or am I wrong? Maybe the gap3 value is too short? I don't get how exactly these gaps are calculated, but I think you should read these: http://philipstorr.id.au/pcbook/book4/floppyd.htm http://www.hermannseib.com/documents/floppy.pdf http://www.bitsavers.org/pdf/shugart/_appNotes/Lesea_Floppy_May78.pdf http://nerdlypleasures.blogspot.com.au/2015/11/ibm-pc-floppy-disks-deeper-look-at-disk.html Atari ST uses WD1772 FDD controller, unlike most IBM-PCs, which use NEC uPD765. There are serious differences in gap lengths between them. Especially the post index gap (GAP_1).

P.S. When may I expect the next release? Any roadmap for the releases?

[TzOk83]

I have found another document which gives some other numbers... and realized that they were using HEX, not DEC: http://docs.mamedev.org/techspecs/floppy.html

Each track begins with a header: 80B of GAP (4E) 15B of SYNC (13B of 00 and 3B of C2) 01B of MARK (FC) 50B of GAP (4E) [VARIABLE LENGTH] Then the sectors follow: 15B of SYNC (13B of 00 and 3B of 1A) 01B of MARK (FE) 04B of ADDR (TRACK, HEAD, SECTOR, TYPE) 02B of CRC 22B of GAP (4E) 15B of SYNC (13B of 00 and 3B of 1A) 01B of MARK (FB) 512B of USER DATA 2B of CRC 84B of GAP [VARIABLE LENGTH] _ ' these values are not correctly MFM encoded, the clock pattern is different: C2@14 = 0101001000100100, 1A@0A = 0100010010001001.

This seems to be a document you were using, isn't it? Raw track length is reported as 6250B, yet 300rpm CAV @ 250kbps, gives me 6400B.

If so, then for standard 9 S/T DD disk, each track uses 146B + 9 * 574B = 5312B. So, assuming a raw track length of 6250B the gap3 should be (6250 - 5312) / 9 = 104B or for track length of 6400B it should be 121B. But in fact there are no bytes in GAP, it is only a delay time, for drive logic to sync with SYNC bytes or to process sector data. 1B of GAP is equivalent to 31.25us delay.

[keirf]

I will get round to looking at this next week I think. And start getting releases out again this month after the recent hiatus.

[TzOk83]

If you need any additional data, just ask. I have an Atari STE with a working DD floppy drive, a logic analyzer, and a digital storage oscilloscope. So I may capture some data if you need.

[TzOk83]

Please see this (page 25): Atari-Copy-Protection.pdf

[kodak80]

Not sure if this helps with fixing the .ST issue but I have tried using a HFE disk image with 11 sectors and it works fine with FlashFloppy firmware on my Gotek.

[TzOk83]

.HFE has all the timings inside (I'm not sure, but think it is a raw MFM data), while .ST/.IMG carries only binary sector data, and all the inter-sector gaps and timing have to be calculated by firmware. There is a software to convert .ST to .HFE and it will generate everything what is needed.

[keirf]

Thanks. I have all the info I need. Patience please and I will get back with a patch for testing.

[keirf]

I have fixed a few bugs with 11-sector DD tracks. The main one was that interleaved ordering emitted sector data incorrectly. Please test the following patched firmware. If it works for read then please also test write (if that is supported by ST for 11-sector disks). If it works I will shortly do a release with the fixed included.

ff_st_11.zip

[TzOk83]

Everything seems to work ok. I have not measured times, but it seems to be slightly slower than actual floppy. I don't know why, but FastCopy PRO reports that drive is single sided, yet FastCopy III reads this image correctly.

[keirf]

@TzOk83 It's slower than actual floppy on what operation? Copy, read, write? Is this true only for 11-sector images or for 10-sector images too? We will need to do some digging to track this one down, if there's an issue here.

[TzOk83]

I'll make measurements on reading/writing speeds, but not today.

[keirf]

No problem, let me know as and when. I'm closing this issue, open another for any performance problems.