| |
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....
|
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quote: That's bad ofcourse, but if demos crash because the disk is bad or the drive is a lot of shit, then it's ok imo.
I don't think so. The worst that may happen is that the load call never returns because the loader is spinning around an erroneous block or so. Second-worst are too long loading times and bad sync due to that. But never should the demo crash.
Also, what is really bad are loaders not checksumming the header and data, which makes demos quite flaky under data party conditions with a lot of EM fields adding up. |
| |
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.
|
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quoting ravenWhat 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. |
| |
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
|
| |
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. |
| |
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
|
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quoting KrillRaven, 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... |
| |
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 ;)
|
| |
raven
Account closed
Registered: Jan 2002
Posts: 137 |
Also, wouldnt the safe-zone shift in drives with a slightly higher/lower RPM?
|
| |
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. |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
