Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > CSDb Entries > Release id #203868 : Sparkle 2
2021-05-06 16:44
Sparta

Registered: Feb 2017
Posts: 34
Release id #203868 : Sparkle 2

While working on Sparkle’s hi-score file saver function, I ran into an issue and I thought I’d share it here.

I initially based the drive code on the detailed description of the header and data blocks of a sector in the G64 document: http://www.unusedino.de/ec64/technical/formats/g64.html
From this document I learned that the header gap consists of 9 $55 bytes which is preceded by the header info (10 bytes) and is followed by the sync bytes (40 1-bits) then the data block:

"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)" 


However, when my code followed this layout and skipped 9 header gap bytes after the header info, before writing 5 sync bytes, my 1541-II kept reading back junk. So, I checked the 1541’s ROM code here: http://unusedino.de/ec64/technical/aay/c1541/ro41f575.htm, and found two discrepancies between these 2 online sources.
First, while the 1541 ROM does skip 9 $55 bytes, in reality, this includes the last two bytes of the header info, so the actual length of the header gap is 7 bytes. Modifying my code accordingly, solved my issue.
The other “issue” I noticed is related to the length of the data sync. The 1541 ROM code writes 48 1-bits (6 $ff bytes), not 40 (even though the comment in the ROM document describes “write $ff to disk 5 times), but this is of course not a show stopper, and 40 1-bits work just fine. :)
2021-05-06 19:20
tlr

Registered: Sep 2003
Posts: 1606
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.

Also note that if you are experimenting with the delays, make sure you always start on a clean formatted track. Otherwise your previous write test will affect the required timing for the next test.

Interesting about that supposed 48-bits sync. Does it really end up 48-bits on rewritten sectors? As you say, it doesn't matter that much if it's 40 or 48.
2021-05-06 20:32
Groepaz

Registered: Dec 2001
Posts: 10434
Are you sure about the sync length?

I'd not trust any of it before we have a test program that measures it :)

(you should not rely on either gap nor sync lengths in your loader - within the allowed limits - anyway... unless you also provide a formatting tool and a way to master a disk with specific properties)
2021-05-06 22:07
Sparta

Registered: Feb 2017
Posts: 34
The above is based on simply interpreting the 1541's ROM code at http://unusedino.de/ec64/technical/aay/c1541/ro41f575.htm and counting BVCs.
Here is the pertinent part:

F589: 20 10 F5  JSR $F510       ; find block header

The code at $F510 converts the 8 header bytes to 10 GCR bytes, then waits for the synch mark, after which it reads 8 bytes from the disk (not 10) and compares them to the first 8 of the 10 GCR bytes.
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

Indeed, we are skipping 9 bytes here, but counting starts right after the first 8 of the 10 header GCR bytes. Thus, it also includes the last 2 bytes of the header, which are also $55, anyway. So, technically, the actual gap is only 7 bytes long.
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

So far we have written 5 sync bytes (BVC No. 1-5). NB. The first sync byte gets written min. 36 cycles after the last (7th) gap byte was read.
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

And this was BVC No. 6. Thus, a total of 6 synch bytes written before the value of Data Port A gets changed.
F5B8: B8        CLV
F5B9: 8D 01 1C  STA $1C01

So in short:
1. Wait for header sync mark
2. Read and compare the first 8 GCR bytes of the header
3. Skip 9 $55-bytes
4. Write 6 sync bytes before data is being written.

If I am not mistaken. But of course, I lack deeper knowledge about how the actual data gets written on the disk.
2021-05-07 00:57
Krill

Registered: Apr 2002
Posts: 2441
I second Sparta with the observation that the BVC at $f5b6 without any update on $1c01 causes the 6th sync byte.

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

Quoting Groepaz
you should not rely on either gap nor sync lengths in your loader
I think it was the ROM loader already that had problems reading the blocks with 9 instead of 7 gap bytes. I suspect those were caused by the fact that it wasn't a freshly-formatted disk (with 9 gap bytes) the saver wrote to, but something written to already (transferred disk image), with 7 gap bytes.
My theory is that when you then come along and wait 9 instead of 7 gap bytes before writing a sync, this wait will run into the existing sync and skip it entirely (carry isn't cleared until sync is over, and a sync is 10 1-bits in a row already) before switching to write mode and writing the intended sync. In between old and new sync, 0-bits will appear, causing the second sync to be read as data.

Btw., for my own saving purposes, i simply copy the ROM routine at $f575 and slap an RTS to the RAM equivalent of $f5d9, then JSR to the routine in RAM. Should work, and i think (hope, in fact) that no custom drive ROM dared to move or change that routine. :)
2021-05-07 10:59
tlr

Registered: Sep 2003
Posts: 1606
Quoting Krill
I second Sparta with the observation that the BVC at $f5b6 without any update on $1c01 causes the 6th sync byte.

It might be. 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.

Quoting Krill
Quoting tlr
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.
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.

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.
2021-05-07 12:23
Krill

Registered: Apr 2002
Posts: 2441
Quoting tlr
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.
The GCR Format Editor in Maverick 5.04 / Renegade V2 measures sync lengths and might be accurate enough to see a significant difference on average.

Quoting tlr
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.
Okay. Then i misinterpreted your statement to mean that the shorter gap with saving after format is intended due to these delays.

Quoting tlr
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.
Seems like we have the same theory there. :) Shortening such a gap is "okay" within bounds, lengthening isn't reliably possible with the standard ROM approach.
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
kbs/Pht/Lxt
curtcool
Scooby/Gā˜…P/Light
š˜š—”š—š/FairLight
TheRyk/MYD!
Mike
honza/Hondani
Matt
Guests online: 79
Top Demos
1 Trapped Love  (9.7)
2 Edge of Disgrace  (9.6)
3 Coma Light 13  (9.6)
4 Bromance  (9.6)
5 E2IRA  (9.6)
6 Uncensored  (9.6)
7 Comaland 100%  (9.6)
8 Incoherent Nightmare  (9.5)
9 Lunatico  (9.5)
10 Memento Mori  (9.5)
Top onefile Demos
1 Copper Booze  (9.7)
2 Barry Boomer - Trapp..  (9.6)
3 Dawnfall V1.1  (9.5)
4 Daah, Those Acid Pil..  (9.5)
5 Offering  (9.5)
6 Onef1ler 2  (9.5)
7 Lovecats  (9.5)
8 Plasma Ninja  (9.5)
9 Someone Somewhere  (9.5)
10 Aurora Dreams - The ..  (9.5)
Top Groups
1 Booze Design  (9.4)
2 Oxyron  (9.3)
3 Censor Design  (9.3)
4 Crest  (9.3)
5 Maniacs of Noise  (9.3)
Top Original Suppliers
1 Derbyshire Ram  (9.3)
2 hedning  (9.2)
3 Jazzcat  (9.0)
4 Irata  (8.7)
5 Baracuda  (3.9)

Home - Disclaimer
Copyright © No Name 2001-2022
Page generated in: 0.046 sec.