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 > C64 Coding > loading times & drive compatibility
2010-01-12 18:10
Zaz
Account closed

Registered: Mar 2004
Posts: 33
loading times & drive compatibility

Hi all,

I'm working on my first multi-load demo for the C64.
I'd like to have good synchronization between the music and the effects, so I have to take into account loading times.

So the question is, what's a good strategy to do this? Given that loading times will vary between different drive models, and maybe between different drives of the same model.

Is a simple safety margin good enough, and if so, how can I determine how long it should be? Any other issues to consider?

I would like to use Krill's loader, btw.

Thanks in advance.
 
... 39 posts hidden. Click here to view all posts....
 
2010-02-19 13:08
raven
Account closed

Registered: Jan 2002
Posts: 137
I tested my loader (and demo) on about 10 different drives I have here, an additional 5+ at a friend's house, and sent it to _V_ to test on his drive (the only 1541 mkII we tested on).
All worked fine multiple times, but it still didnt stop it from crashing hard on the compo drive...

I was sure I *was* within tolerance, until one drive proved me wrong ;)
(and then a few others, but that doesnt count...)

What I've learned from this: 18 cycles between drive reads is too much, even when trying to "compensate" with a lower cycle count on the next read...
16 is totally safe but 17 should be ok as well.

Another lesson learned: my 128D's internal drive can go up to 19 cycles between reads without problems.
2010-02-19 18:09
doynax
Account closed

Registered: Oct 2004
Posts: 212
Quoting raven
What I've learned from this: 18 cycles between drive reads is too much, even when trying to "compensate" with a lower cycle count on the next read...
16 is totally safe but 17 should be ok as well.

Another lesson learned: my 128D's internal drive can go up to 19 cycles between reads without problems.
Dammit. Time to fix my own work-in-progress loader then, and I guess I really need to find something besides a 128D to test with while I'm at it.

Just to make things clear; I assume you're counting 17 cycles on top of a normal (penalty-free) CLV/BVC loop and four-cycle $1C01 read, right?

I see that in one case you wait a bit after the BVC loop before loading the $1C01 value in order to spread the cycles out evenly among the loops. That's a sweet trick but how long can you safely wait before you risk reading the next GCR byte instead?

Come to think of it perhaps one might occasionally shave off a few cycles in a similar fashion by waiting to clear the overflow flag. Say by replacing that CMP #$80/ROL/CMP #$80/ROL rotation at $04C2 with ASL/ROL/ADC #$00 and omitting the CLV.
2010-02-19 18:24
tlr

Registered: Sep 2003
Posts: 1790
This was also discussed here:
Drive coding: safe maximum time between $1c01 reads?

and here:
Job codes'n buffers
2010-02-19 19:36
Krill

Registered: Apr 2002
Posts: 2980
Raven, doynax: You don't have to sync using the v-flag for every $1c01 read. In my loader, i wait for BYTESYNC only 2 out of 5 times to use the cycles for some more decoding on the fly. This works because the $1c01 reads are within safe bounds for all four speedzones.
2010-02-19 19:42
Krill

Registered: Apr 2002
Posts: 2980
Here's the corresponding code snippet so you don't have to wade through the source. :)
            ; read and partially inflate the gcr digits to 8 bits
           ;ldx #$00
loaddata:   bvc *; 3 cycles variance
            lsr                  ; .0000011
            sta HINIBBLES-$01-0,x; the first write in the loop is actually superfluous
            lda VIA2_PRA         ; 11222223      0 - cycle 13 in [0..25]
            ror                  ; 11122222
            sta LONIBBLES-$01-0,x; the first write in the loop is actually superfluous
            and #GCR_NIBBLE_MASK ; ...22222 - 2
            sta HINIBBLES+$00-0,x
            inx
            inx
            lda VIA2_PRA         ; 33334444      1 - cycle 35 in [32..51]
            clv                  ;                 - cycle 37 in [32..51]
            tay
            ror                  ; 33333444
            lsr                  ; .3333344
            lsr                  ; ..333334
            lsr                  ; ...33333 - 3
            sta LONIBBLES+$00-2,x
               ; 52 cycles in [0..51]
               ; the 3rd GCR byte comes at about cycle 52 with bitrate 11

            bvc *; 3 cycles variance
            tya
            ldy VIA2_PRA         ; 45555566      2 - cycle 8 in [0..25]
            cpy #$80
            rol                  ; 33344444
            and #GCR_NIBBLE_MASK ; ...44444 - 4
            sta HINIBBLES+$01-2,x
            tya                  ; 45555566
            alr #%01111111       ; ..555556
            sta LONIBBLES+$01-2,x
            inx
            lda VIA2_PRA         ; 66677777      3 - cycle 34 in [32..51]
            tay
            ror                  ; 66667777
            lsr LONIBBLES+$01-3,x; ...55555 - 5
            ror                  ; 66666777
            sta HINIBBLES+$02-3,x
            tya                  ; 66677777
            and gcr_nibble_mask  ; ...77777 - 7
            sta LONIBBLES+$02-3,x
            lda VIA2_PRA         ; 00000111      4 - cycle 64 in [64..77]
            inx
            clv                  ;                 - cycle 68 in [64..77]
scanswt0:   bne loaddata
               ; 71 cycles in [0..77]
               ; a 5-GCR-bytes cycle takes at least 129 cycles, 52 + 71 = 123


And here the timing table this is based on:
Cycles at 1 MHz: 0        8        16       24       32       40       48       56       64       72       80       88       96       104      112      120      128      136      144      152      160

Bitrate 00:      00000000.00000000.00000000.00000000.11111111.11111111.11111111.11111111.22222222 .22222222.22222222.22222222.33333333.33333333.33333333.33333333.44444444.4444444 4.44444444.44444444
Bitrate 11:      00000000.00000000.00000000.00111111.11111111.11111111.11112222.22222222.22222222 .22222233.33333333.33333333.33333333.44444444.44444444.44444444.44
Safe areas:      00000000.00000000.00000000.00       11111111.11111111.1111              22222222 .222222                     33333333                            44
2010-02-19 20:29
doynax
Account closed

Registered: Oct 2004
Posts: 212
Quoting Krill
Raven, doynax: You don't have to sync using the v-flag for every $1c01 read. In my loader, i wait for BYTESYNC only 2 out of 5 times to use the cycles for some more decoding on the fly. This works because the $1c01 reads are within safe bounds for all four speedzones.
Wow.. That's beyond awesome :)

I would never dare try it myself but I applaud your efforts in figuring out the safe timings and making it work.

Oh, and while we're on the subject of floppy timing can anyone tell me what the minimum safe time to move the drive head between tracks is? I fear my current project needs a lot of random access...
2010-02-19 21:35
raven
Account closed

Registered: Jan 2002
Posts: 137
@Krill:

That is really nice :)
I was sure the CLV is a must! never seen another loader that doesnt do it after each read.
Where did that timing table come from?

@doynax:

If you mean the delay between stepper-motor steps, I use $18 ($98 written to timer register $1805 in the stepper routine).
You can go lower, but I found that with lower values, if you move the head a long distance, on some drives it has trouble stopping & usually misses the desired track by a step or two ;)

2010-02-19 22:01
raven
Account closed

Registered: Jan 2002
Posts: 137
Also, wouldnt the safe-zone shift in drives with a slightly higher/lower RPM?
2010-02-19 22:18
doynax
Account closed

Registered: Oct 2004
Posts: 212
Quoting raven
@doynax:

If you mean the delay between stepper-motor steps, I use $18 ($98 written to timer register $1805 in the stepper routine).
You can go lower, but I found that with lower values, if you move the head a long distance, on some drives it has trouble stopping & usually misses the desired track by a step or two ;)

So... Two seconds and a bit for a worst-case seek then? That's still a bit much for my tastes, even if much of it can be avoided with carefully laid-out files.

Or perhaps the proper solution is to smoothly accelerate and decelerate during long seeks? I can imagine that people doing demo work have rarely needed to bother with such optimizations but any savings in the seek times would help me a great deal.
2010-02-20 16:14
Krill

Registered: Apr 2002
Posts: 2980
Yes, my loader also implements head acceleration for trackseek. These are the parameters:
.define MINSTPSP                 $18 ; min. r/w head stepping speed on 1541/41-C/41-II/70/71
.define MAXSTPSP                 $10 ; max. r/w head stepping speed on 1541/41-C/41-II/70/71
.define STEPRACC                 $1c ; r/w head stepping acceleration on 1541/41-C/41-II/70/71

Note that the initial speed is $18, this seems to be the maximum safe speed without acceleration.

Raven: I'll write up a detailed account on the workings of the non-sync optimization up there and put it here soonish. :)
Previous - 1 | 2 | 3 | 4 | 5 - Next
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
REBEL 1/HF
DeMOSic/MS^LSD^ONS
kbs/Pht/Lxt
Sepa/OCD
Andy/AEG
MCM/ONSLAUGHT
theK/ATL
Peacemaker/CENSOR/Hi..
New Design/Excess
MightyAxle
LDX#40
algorithm
Guests online: 101
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 No Listen  (9.6)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Triad  (9.3)
Top Crackers
1 Mr. Z  (9.9)
2 Antitrack  (9.8)
3 OTD  (9.8)
4 Fungus  (9.8)
5 S!R  (9.8)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.06 sec.