"Here's the layout of a standard low-level pattern on a 1541 disk. Use the above sample to follow along. 1. Header sync FF FF FF FF FF (40 'on' bits, not GCR) 2. Header info 52 54 B5 29 4B 7A 5E 95 55 55 (10 GCR bytes) 3. Header gap 55 55 55 55 55 55 55 55 55 (9 bytes, never read) 4. Data sync FF FF FF FF FF (40 'on' bits, not GCR) 5. Data block 55...4A (325 GCR bytes) 6. Inter-sector gap 55 55 55 55...55 55 (4 to 12 bytes, never read) 1. Header sync (SYNC for the next sector)"
F589: 20 10 F5 JSR $F510 ; find block header
F58C: A2 09 LDX #$09 Jump from $F58E, $F592: F58E: 50 FE BVC $F58E ; byte ready? F590: B8 CLV F591: CA DEX F592: D0 FA BNE $F58E
F594: A9 FF LDA #$FF F596: 8D 03 1C STA $1C03 ; port A (read/write head) to output F599: AD 0C 1C LDA $1C0C F59C: 29 1F AND #$1F F59E: 09 C0 ORA #$C0 ; change PCR to output F5A0: 8D 0C 1C STA $1C0C F5A3: A9 FF LDA #$FF F5A5: A2 05 LDX #$05 F5A7: 8D 01 1C STA $1C01 ; write $FF to disk 5 times F5AA: B8 CLV Jump from $F5AB, $F5AF: F5AB: 50 FE BVC $F5AB ; as SYNC characters F5AD: B8 CLV F5AE: CA DEX F5AF: D0 FA BNE $F5AB
F5B1: A0 BB LDY #$BB Jump from $F5BD: F5B3: B9 00 01 LDA $0100,Y ; bytes $1BB to $1FF to disk Jump from $F5B6: F5B6: 50 FE BVC $F5B6
F5B8: B8 CLV F5B9: 8D 01 1C STA $1C01
That layout is what is written on formatting, from a quick look it seems accurate. When you later write a sector, then you read the header and then switch to write in time for the data block. Due to there being pipeline delays for both read and write this switch has to happen some time earlier than expected to make the write end up on the correct spot.
you should not rely on either gap nor sync lengths in your loader
I second Sparta with the observation that the BVC at $f5b6 without any update on $1c01 causes the 6th sync byte.
Quoting tlrThat layout is what is written on formatting, from a quick look it seems accurate. When you later write a sector, then you read the header and then switch to write in time for the data block. Due to there being pipeline delays for both read and write this switch has to happen some time earlier than expected to make the write end up on the correct spot.If that were an issue, any successive save would have to have shorter and shorter gaps. I think that the difference in format vs. save is just an oversight.
If any one has hardware to read raw flux data it should be easy to see if all rewritten sectors have a longer sync at the start of the data block.
I'm not sure you are commenting on this exact phrasing, but I'm thinking there might be a byte delay somewhere in the read or write paths. If there is, then the switch to write mode needs to be done a bit in advance to in practice happen on the right spot on the media.
My other statement was about freshly formatted disks for the tests. This only matters if you by mistake write using a very short gap before the data block. If you then later write using a normal gap to that sector you might end up with a double sync with some data bits inbetween.
