DD disc Track Structure / Kryoflux image.

[willyvmm]

Hello folks.

 

I need to know a logical structure of DD atari floppy track.

 

I found some info here: http://www.ataripreservation.org/websites/freddy.offenga/megazine/ISSUE6-FDTECH.html.. but it seems that is somehow wrong.

As SD and ED looks reliable (SD/ED uses ca. 97% of theoretical capacity.), DD track exceeds theoretical limit of bytes on the track.

 

Theoretical capacity is 6510 bytes/track for MFM encoding, alnd half of that for FM encoding.

 

for DD track:

51+18*(112+256)=6675, its 165 bytes more that theoretical capacity ...

Is there someone who can explain that?

 

Or

 

Could someone upload Kyroflux image of DD track ? (perfectly would be get it as MFM decoded stream)

 

Or any other idea ?

 

Br.

willy.

 

 

 

[phaeron]

Yeah, uh, that doesn't seem right. I'm pretty sure that the various 1050 expansions don't format double density disks exactly the same way. Moreover, the XF551 formats index-to-index while the 1050 bypasses the index sensor, so they have to use different Write Track streams -- the 1050 has to have the variable gap at the beginning while the XF551 has it at the end. The FDC is also flexible about what formats it can support -- the hard requirements are around the gaps leading up to the address marks, and beyond that it depends on how much drive speed tolerance is needed.

 

Here's what I'm seeing in Altirra when running a double-density format command with full drive emulation:

 

US Doubler

 

• 514 x $4E
• For each sector:
  • 10 x $00
  • 3 x sync
  • 1 x $FE (IDAM)
  • 6 x ?? (sector ID field + CRC)
  • 22 x $4E
  • 12 x $00
  • 3 x sync
  • 1 x $FB (DAM)
  • 256 x $FF (sector data)
  • 2 x ?? (data CRC)
  • 22 x $4E

Total 6562 raw bytes written in Write Track command of which 36 are CRC commands, so 6598 raw bytes truncated down to ~6512. The lead-in at the beginning will be partially overwritten when the track format overlaps itself.

 

XF551

• 60 x $4E
• For each sector:
  • 12 x $00
  • 3 x sync
  • 1 x $FE (IDAM)
  • 6 x ?? (sector ID field + CRC)
  • 21 x $4E
  • 12 x $00
  • 3 x sync
  • 1 x $FB (DAM)
  • 256 x $FF (sector data)
  • 2 x ?? (data CRC)
  • 24 x $4E
• ?? x $4E

The end of track gap is variable because the firmware simply formats from index to index.

[willyvmm]

Thanks. It makes sense.

I took a qiuck peek into 1050 ROM, and can say that info provided in link from 1'st post is absolutelly fabricated... maybe it match its bigger brothers drives (ST) but not 8bit, specially 1050.

So i'll have to examine 1050 ROM, and TopDrive (easiest) ROM to find the proper track layout.

or

Just hook logic analyzer to my 1050 and have some fun

[sup8pdct]

I believe usd 1050 closely follows the FDC279x data sheet for DD format. Also indus appears to be very similar.

 

James

[phaeron]

Not that I can see -- the format produced by the USD firmware has different gap byte counts from the docs except for between the ID and data fields, where the FDC has strict requirements.

 

I modified my emulator to log a compact version of the Write Track data and tried it with various drive/firmware combinations -- 1050 matches for SD/ED formats, but they're wrong for the XF551, which uses different gap sizes and doesn't write an index mark.

 

810 SD (rev. C firmware) - 3379 encoded bytes:

• 256 x $00
• 1 x index mark
• 11 x $00
• For each sector (18, 1, 3, 5, ..., 17, 2, 4, 6, ..., 16):
  • 6 x $00
  • 1 x $FE (IDAM)
  • 6 x ?? (ID field + CRC)
  • 17 x $00
  • 1 x $FB (DAM)
  • 128 x $FF (sector data)
  • 2 x ?? (CRC)
  • 9 x $00
  • 3 x $FF (except last sector)

 

810 SD (rev. E firmware) - 3361 encoded bytes:

• 256 x $00
• 1 x index mark
• 11 x $00
• For each sector (18, 1, 3, 5, ..., 17, 2, 4, 6, ..., 16):
  • 6 x $00
  • 1 x $FE (IDAM)
  • 6 x ?? (ID field + CRC)
  • 17 x $00
  • 1 x $FB (DAM)
  • 128 x $FF (sector data)
  • 2 x ?? (CRC)
  • 8 x $00
  • 3 x $FF (except last sector)

 

1050 SD (rev. L firmware) - 3361 encoded bytes:

• 174 x $00
• 1 x index mark
• 4 x $00
• For each sector (1, 3, 5..., 2, 4, 6...):
  • 18 x $00
  • 1 x $FE (IDAM)
  • 6 x ?? (ID field + CRC)
  • 17 x $00
  • 1 x $FB (DAM)
  • 128 x $FF (sector data)
  • 2 x ?? (CRC)
• 68 x $00

 

1050 ED (rev. L firmware) - 6721 encoded bytes:

• 402 x $4E
• 12 x $00
• 3 x index sync
• 1 x index mark
• 18 x $4E
• For each sector (1, 3, 5..., 2, 4, 6...):
  • 32 x $4E
  • 12 x $00
  • 3 x sync
  • 1 x $FE (IDAM)
  • 6 x ?? (ID field + CRC)
  • 22 x $4E
  • 12 x $00
  • 3 x sync
  • 1 x $FB (DAM)
  • 128 x $FF (sector data)
  • 2 x ?? (data CRC)
  • 18 x $00 (except last sector)
• 1 x $00
• 62 x $4E

US Doubler SD - 3299 encoded bytes:

• 257 x $FF
• For each sector (17, 15, 13..., 18, 16, 14...):
  • 1 x $FF
  • 6 x $00
  • 1 x $FE (IDAM)
  • 6 x ?? (ID field + CRC)
  • 11 x $FF
  • 6 x $00
  • 1 x $FB (DAM)
  • 128 x $FF (sector data)
  • 2 x ?? (CRC)
  • 7 x $FF

US Doubler ED - 6728 encoded bytes:

• 514 x $4E
• For each sector (1, 3, 5..., 2, 4, 6...):
  • 12 x $00
  • 3 x sync
  • 1 x $FE (IDAM)
  • 6 x ?? (ID field + CRC)
  • 22 x $4E
  • 12 x $00
  • 3 x sync
  • 1 x $FB (DAM)
  • 128 x $FF (sector data)
  • 2 x ?? (data CRC)
  • 49 x $4E

US Doubler DD default - 6598 encoded bytes:

• 514 x $4E
• For each sector (18, 17, 16..., 1):
  • 10 x $00
  • 3 x sync
  • 1 x $FE (IDAM)
  • 6 x ?? (ID field + CRC)
  • 22 x $4E
  • 12 x $00
  • 3 x sync
  • 1 x $FB (DAM)
  • 256 x $FF (sector data)
  • 2 x ?? (data CRC)
  • 22 x $4E

XF551 SD - 3268 encoded bytes:

• 28 x $00
• For each sector (1, 3, 5..., 2, 4, 6...):
  • 18 x $00
  • 1 x $FE (IDAM)
  • 6 x ?? (ID field + CRC)
  • 17 x $00
  • 1 x $FB (DAM)
  • 128 x $FF (sector data)
  • 2 x ?? (CRC)
• 126 x $00 (variable lead out)

XF551 ED - 6536 encoded bytes:

• 60 x $4E
• For each sector (1, 3, 5..., 2, 4, 6...):
  • 12 x $00
  • 3 x sync
  • 1 x $FE (IDAM)
  • 6 x ?? (ID field + CRC)
  • 22 x $4E
  • 12 x $00
  • 3 x sync
  • 1 x $FB (DAM)
  • 128 x $FF (sector data)
  • 2 x ?? (data CRC)
  • 24 x $4E
• 912 x $4E (variable lead out)

XF551 DD default - 6536 encoded bytes:

• 60 x $4E
• For each sector (1, 7, 13, 6, 12, 18, 5, 11, 17, 4, 10, 16, 3, 9, 15, 2, 8, 14):
  • 12 x $00
  • 3 x sync
  • 1 x $FE (IDAM)
  • 6 x ?? (ID field + CRC)
  • 22 x $4E
  • 12 x $00
  • 3 x sync
  • 1 x $FB (DAM)
  • 256 x $FF (sector data)
  • 2 x ?? (data CRC)
  • 24 x $4E
• 320 x $4E (variable lead out)

Indus GT SD (firmware 1.2) - 3730 encoded bytes:

• 599 x $FF
• 6 x 00
• 1 x index mark
• 11 x $00
• For each sector (1, 3, 5..., 2, 4, 6...):
  • 6 x $00
  • 1 x $FE (IDAM)
  • 6 x ?? (ID field + CRC)
  • 17 x $00
  • 1 x $FB (DAM)
  • 128 x $FF (sector data)
  • 2 x ?? (CRC)
  • 9 x $00
  • 3 x $FF (except last sector)
• 2 x $FF

Indus GT ED (firmware 1.2) - 6897 raw bytes:

• 1296 x $4E (!)
• 12 x $00
• 3 x index sync
• 1 x index mark
• 22 x $4E
• For each sector (1, 3, 5..., 2, 4, 6...):
  • 12 x $00
  • 3 x sync
  • 1 x $FE (IDAM)
  • 6 x ?? (ID field + CRC)
  • 34 x $4E
  • 3 x sync
  • 1 x $FB (DAM)
  • 128 x $FF (sector data)
  • 2 x ?? (data CRC)
  • 24 x $4E (except last sector)
• 23 x $4E

Indus GT DD (firmware 1.2) - 7489 raw bytes:

• 1296 x $4E (!)
• 12 x $00
• 3 x index sync
• 1 x index mark
• 22 x $4E
• For each sector (1, 3, 5..., 2, 4, 6...):
  • 12 x $00
  • 3 x sync
  • 1 x $FE (IDAM)
  • 6 x ?? (ID field + CRC)
  • 34 x $4E
  • 3 x sync
  • 1 x $FB (DAM)
  • 256 x $FF (sector data)
  • 2 x ?? (data CRC)
  • 24 x $4E (except last sector)
• 23 x $4E

 

[+Stephen]

Not that I can see -- the format produced by the USD firmware has different gap byte counts from the docs except for between the ID and data fields, where the FDC has strict requirements.

 

I modified my emulator to log a compact version of the Write Track data and tried it with various drive/firmware combinations -- 1050 matches for SD/ED formats, but they're wrong for the XF551, which uses different gap sizes and doesn't write an index mark.

 

 

810 SD (rev. C firmware) - 3379 encoded bytes:
256 x $00
1 x index mark
11 x $00
For each sector (18, 1, 3, 5, ..., 17, 2, 4, 6, ..., 16):

6 x $00
1 x $FE (IDAM)
6 x ?? (ID field + CRC)
17 x $00
1 x $FB (DAM)
128 x $FF (sector data)
2 x ?? (CRC)
9 x $00
3 x $FF (except last sector)



 
810 SD (rev. E firmware) - 3361 encoded bytes:

256 x $00
1 x index mark
11 x $00
For each sector (18, 1, 3, 5, ..., 17, 2, 4, 6, ..., 16):

6 x $00
1 x $FE (IDAM)
6 x ?? (ID field + CRC)
17 x $00
1 x $FB (DAM)
128 x $FF (sector data)
2 x ?? (CRC)
8 x $00
3 x $FF (except last sector)



 
1050 SD (rev. L firmware) - 3361 encoded bytes:

174 x $00
1 x index mark
4 x $00
For each sector (1, 3, 5..., 2, 4, 6...):

18 x $00
1 x $FE (IDAM)
6 x ?? (ID field + CRC)
17 x $00
1 x $FB (DAM)
128 x $FF (sector data)
2 x ?? (CRC)


68 x $00

 
1050 ED (rev. L firmware) - 6721 encoded bytes:

402 x $4E
12 x $00
3 x index sync
1 x index mark
18 x $4E
For each sector (1, 3, 5..., 2, 4, 6...):

32 x $4E
12 x $00
3 x sync
1 x $FE (IDAM)
6 x ?? (ID field + CRC)
22 x $4E
12 x $00
3 x sync
1 x $FB (DAM)
128 x $FF (sector data)
2 x ?? (data CRC)
18 x $00 (except last sector)


1 x $00
62 x $4E

US Doubler SD - 3299 encoded bytes:

257 x $FF
For each sector (17, 15, 13..., 18, 16, 14...):

1 x $FF
6 x $00
1 x $FE (IDAM)
6 x ?? (ID field + CRC)
11 x $FF
6 x $00
1 x $FB (DAM)
128 x $FF (sector data)
2 x ?? (CRC)
7 x $FF



US Doubler ED - 6728 encoded bytes:

514 x $4E
For each sector (1, 3, 5..., 2, 4, 6...):

12 x $00
3 x sync
1 x $FE (IDAM)
6 x ?? (ID field + CRC)
22 x $4E
12 x $00
3 x sync
1 x $FB (DAM)
128 x $FF (sector data)
2 x ?? (data CRC)
49 x $4E



US Doubler DD default - 6598 encoded bytes:

514 x $4E
For each sector (18, 17, 16..., 1):

10 x $00
3 x sync
1 x $FE (IDAM)
6 x ?? (ID field + CRC)
22 x $4E
12 x $00
3 x sync
1 x $FB (DAM)
256 x $FF (sector data)
2 x ?? (data CRC)
22 x $4E



XF551 SD - 3268 encoded bytes:

28 x $00
For each sector (1, 3, 5..., 2, 4, 6...):

18 x $00
1 x $FE (IDAM)
6 x ?? (ID field + CRC)
17 x $00
1 x $FB (DAM)
128 x $FF (sector data)
2 x ?? (CRC)


126 x $00 (variable lead out)

XF551 ED - 6536 encoded bytes:

60 x $4E
For each sector (1, 3, 5..., 2, 4, 6...):

12 x $00
3 x sync
1 x $FE (IDAM)
6 x ?? (ID field + CRC)
22 x $4E
12 x $00
3 x sync
1 x $FB (DAM)
128 x $FF (sector data)
2 x ?? (data CRC)
24 x $4E


912 x $4E (variable lead out)

XF551 DD default - 6536 encoded bytes:

60 x $4E
For each sector (1, 7, 13, 6, 12, 18, 5, 11, 17, 4, 10, 16, 3, 9, 15, 2, 8, 14):

12 x $00
3 x sync
1 x $FE (IDAM)
6 x ?? (ID field + CRC)
22 x $4E
12 x $00
3 x sync
1 x $FB (DAM)
256 x $FF (sector data)
2 x ?? (data CRC)
24 x $4E


320 x $4E (variable lead out)

Indus GT SD (firmware 1.2) - 3730 encoded bytes:

599 x $FF
6 x 00
1 x index mark
11 x $00
For each sector (1, 3, 5..., 2, 4, 6...):

6 x $00
1 x $FE (IDAM)
6 x ?? (ID field + CRC)
17 x $00
1 x $FB (DAM)
128 x $FF (sector data)
2 x ?? (CRC)
9 x $00
3 x $FF (except last sector)


2 x $FF

Indus GT ED (firmware 1.2) - 6897 raw bytes:

1296 x $4E (!)
12 x $00
3 x index sync
1 x index mark
22 x $4E
For each sector (1, 3, 5..., 2, 4, 6...):

12 x $00
3 x sync
1 x $FE (IDAM)
6 x ?? (ID field + CRC)
34 x $4E
3 x sync
1 x $FB (DAM)
128 x $FF (sector data)
2 x ?? (data CRC)
24 x $4E (except last sector)


23 x $4E

Indus GT DD (firmware 1.2) - 7489 raw bytes:

1296 x $4E (!)
12 x $00
3 x index sync
1 x index mark
22 x $4E
For each sector (1, 3, 5..., 2, 4, 6...):

12 x $00
3 x sync
1 x $FE (IDAM)
6 x ?? (ID field + CRC)
34 x $4E
3 x sync
1 x $FB (DAM)
256 x $FF (sector data)
2 x ?? (data CRC)
24 x $4E (except last sector)


23 x $4E

 

I see a nice addendum to your Altira Hardware Manual

[ijor]

Not that I can see -- the format produced by the USD firmware has different gap byte counts from the docs except for between the ID and data fields, where the FDC has strict requirements.

 

Indeed the gap II (between the header and the data) will almost always be standard because it is modified by the FDC itself whenever you write. If the sector was never written it might be somewhat different, it doesn't have to be exact as recommended by Western Digital. This is not that uncommon on other platforms, such as ST copy protections. But standard drive firmware normally follows the standard.

 

The other gaps, mainly the gap between sectors can be almost any size.

[phaeron]

Yeah, I discovered that when debugging the Happy 1050 copy software. It doesn't even bother to write the data field during formatting, it just leaves padding there and then relies on the sector write to do the rest.

 

Attached is the result of testing all of the different disk drive firmwares that I could emulate. There's quite a lot of variation in sector spacing and interleave, and some WTFs (like Indus GT formatting double density as 9:1 by default).

 

diskformats.pdf

[willyvmm]

Hi.

Thanks.

Again, great job.

I just started to do the same, ... but i will only complete the data.

I did analyzed only MFM mode, so the following covers only ED and DD.

Following FDC279x datasheet, all gaps ($4E bytes) , except one, between IDAM and DAM, can be shortened to be as short as 2 bytes. But, it is not recommended because of PLL synchronization.

And the only critical structure is sector layout.

All firmwares, are creating identical sector layout (using different software).

IndexDatamark is optional, and is not required.

SyncMarks, are special bytes, wroten with missing clock bit - its FDC special feature, "commands" F5 and F6.

F5 "command" write A1 byte with missing clock bit. (pre DAM sync mark)

F5 "command" write C2 byte with missing clock bit. (pre IndexMark sync mark)

F7 "command" write 2 bytes CRC, calculated by Hardware

In every case sector layout is identical, and is achieved by using different software tricks.

MFM sector layout:

• 12 x $00
  
• 3 x PRE DAM sync (F5 "command")
  
• 1 x $FE (IDAM)
  
• 1 x Track number
  
• 1 x Side number
  
• 1 x Sector number
  
• 1 x Sector Length ($00 = 128, $01 = 256, $02 = 512, $03 = 1024)
  
• 2 x CRC (F7 "command")
  
• 22 x $4E (GAP - may not be shorter)
  
• 12 x $00
  
• 3 x PRE DAM sync (F5 "command")
  
• 1 x $FB (DAM)
  
• xx x DATA (128 or 256 bytes of data, it could be also 512 or 1024)
  
• 2 x CRC (F7 "command")
  
• 24 x $4E (PostData Gap) (this varries, and is sometime located in leadin area, usually 24 bytes.)
  

All firmwares are using long track LEAD-IN, that is overlapped by last bytes/sector leadout, it is (i guess) to erase any remaining data on track. Thats, not true for xf551 - because of using Index hole.

IndexMark, and PreIndexMark Sync are optional, and not required by FDC.

I think this should help to explain all.

Btw. I could not find any info, that 1050 is not supporting $4E/$4F commands.

[ijor]

Yeah, I discovered that when debugging the Happy 1050 copy software. It doesn't even bother to write the data field during formatting, it just leaves padding there and then relies on the sector write to do the rest.

Yeah, I know, but I wasn't talking exactly about that. I guess I didn't express myself correctly. I meant that sectors created during format time, but never rewritten as individual sectors, can have a gap size quite different than the MFM standard 34 bytes long, and still recognized by the FDC. There is a minimum and a maximum size, but it doesn't have to be strictly 34 bytes.

 

Following FDC279x datasheet, all gaps ($4E bytes) , except one, between IDAM and DAM, can be shortened to be as short as 2 bytes. But, it is not recommended because of PLL synchronization.

• 22 x $4E (GAP - may not be shorter)
• 12 x $00

There is no requirement whatsoever of being 22 bytes of $4E. A gap might be all $00 bytes, it could even have random bytes. The only requirement, regarding the content of the gap, is a couple of 0 bits before the syncs.

 

The other gaps might be even shorter than 2 bytes. If the track is read only, just a couple of 0 bits before the syncs is good enough.

[1050]

Btw. I could not find any info, that 1050 is not supporting $4E/$4F commands.

You went there so I can't resist really.

You also can't find those commands in the 1050 source

code.

http://www.langesite.com/atari/holmes/Holmes%202/Sources/XL_XE%20HARDWARE/1050%20OS%20Source%20Code/

 

And by omission then, they are not supported. I converted

that source code to MAC/65 and assembled it as basis for

this post:

http://atariage.com/forums/topic/156462-1050-roms/?do=findComment&comment=1921475

 

I may have to do it again, but this time with full assembly

report that makes hunting an issue like this one down at least

somewhat doable. In the meantime just take our word for it,

the stock 1050 doesn't know what a percom block are.

 

That's why it needs the special ED format command 22h.

[ijor]

And by omission then, they are not supported. I converted that source code to MAC/65 and assembled ...

 

Great job there, but please call things by their proper name. That is not the source of the 1050 firmware, it is a disassemble. Not trying to make a semantic argument. But just to make clear that it is not the original Atari (or Tandon?) source code, that unfortunately, it is still missing. At least, AFAIK, it is not publicly available.

[1050]

Fair enough, I see where you are going and you are

right to call notice to the fact that this code is

not from Tandon/Atari origin for those that might be

relatively new to the game. It is based only on the

disaassembly of 1050 OS rom code and from that this

source code is created and then filled in richly by

comments from esquires Michael Pascher (Abbuc-Buch)

and W. Derks to which I'm very grateful as they did

a wonderful job of it and fixing the self test errors

found within.

 

I too have no knowledge of actual Tandon/Atari source

code or even a rumor of it existing.

 

But we do have this, and I feel like sharing.

FLOPOS.zip

[repetto74]

Hi 1050

 

FLOPOS looks very interesting. So this is a 4K OS to be burn into ideally 2732 eprom or can I use any 27c256 or 27c512? (merging the 4k program as much time as there is room into the eprom). Are they pin compatible?

[+Nezgar]

2732 is a 24pin chip, but 2764 and up are all 28 pin chips, so it won't fit in the 1050 ROM socket, or will at least hang off the end of the socket....

 

According to this attached diagram, if you put a 27C256 directly into a 2732 socket, Vcc would be connected to A13 (zappo). So you'd need to bend out that pin, wire vcc to the one hanging off the end of the socket, and do something with the extra address lines like pullup resistors to ground. Probably best done with an adapter board, I'm not sure of a pre-made one for this.

[BillC]

2732 is a 24pin chip, but 2764 and up are all 28 pin chips, so it won't fit in the 1050 ROM socket, or will at least hang off the end of the socket....

 

According to this attached diagram, if you put a 27C256 directly into a 2732 socket, Vcc would be connected to A13 (zappo). So you'd need to bend out that pin, wire vcc to the one hanging off the end of the socket, and do something with the extra address lines like pullup resistors to ground. Probably best done with an adapter board, I'm not sure of a pre-made one for this.

Why would having A13 tied to +5V kill the EPROM, aren't the address inputs +5V tolerant?

I would think it would just keep that address pin high.

[_The Doctor__]

many titles also had old cracks applied to fix timers or slow down for 60 hz on top of drive cracks...