New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ST images with 11 sectors - unreadable #40

Closed
TzOk83 opened this Issue Dec 20, 2017 · 14 comments

Comments

Projects
None yet
3 participants
@TzOk83

TzOk83 commented Dec 20, 2017

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

@TzOk83 TzOk83 changed the title from ST images with 11 sectors - unredable to ST images with 11 sectors - unreadable Dec 20, 2017

@keirf

This comment has been minimized.

Show comment
Hide comment
@keirf

keirf Dec 21, 2017

Owner

Thanks I'll check it out.

Owner

keirf commented Dec 21, 2017

Thanks I'll check it out.

@TzOk83

This comment has been minimized.

Show comment
Hide comment
@TzOk83

TzOk83 Jan 4, 2018

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 commented Jan 4, 2018

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

This comment has been minimized.

Show comment
Hide comment
@TzOk83

TzOk83 Jan 6, 2018

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.

TzOk83 commented Jan 6, 2018

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

This comment has been minimized.

Show comment
Hide comment
@keirf

keirf Jan 6, 2018

Owner

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

Owner

keirf commented Jan 6, 2018

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

This comment has been minimized.

Show comment
Hide comment
@TzOk83

TzOk83 Jan 6, 2018

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 commented Jan 6, 2018

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.

@keirf keirf added the bug label Jan 8, 2018

@TzOk83

This comment has been minimized.

Show comment
Hide comment
@TzOk83

TzOk83 Jan 8, 2018

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

TzOk83 commented Jan 8, 2018

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

@kodak80

This comment has been minimized.

Show comment
Hide comment
@kodak80

kodak80 Jan 12, 2018

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.

kodak80 commented Jan 12, 2018

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

This comment has been minimized.

Show comment
Hide comment
@TzOk83

TzOk83 Jan 13, 2018

.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.

TzOk83 commented Jan 13, 2018

.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

This comment has been minimized.

Show comment
Hide comment
@keirf

keirf Jan 13, 2018

Owner

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

Owner

keirf commented Jan 13, 2018

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

@keirf

This comment has been minimized.

Show comment
Hide comment
@keirf

keirf Jan 15, 2018

Owner

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

Owner

keirf commented Jan 15, 2018

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

This comment has been minimized.

Show comment
Hide comment
@TzOk83

TzOk83 Jan 15, 2018

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.

TzOk83 commented Jan 15, 2018

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

This comment has been minimized.

Show comment
Hide comment
@keirf

keirf Jan 15, 2018

Owner

@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.

Owner

keirf commented Jan 15, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@TzOk83

TzOk83 Jan 15, 2018

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

TzOk83 commented Jan 15, 2018

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

@keirf

This comment has been minimized.

Show comment
Hide comment
@keirf

keirf Jan 16, 2018

Owner

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

Owner

keirf commented Jan 16, 2018

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

@keirf keirf closed this Jan 16, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment