| |
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.
|
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
use a framecounter. I used to have a routine and the counters always in the memory:
yourirq
...
jsr playmusic
...
...
rti
playmusic
jsr musicstart
inc framecountlo ;this is always in memory, and music is always called through this
bne *+5
inc framecounthi
rts
framecountlo .byte 0
framecounthi .byte 0
checking for some frame:
effectloop
...
...
lda #hival
cmp framecounthi
bcc notreachedyet ;(might be bcs? I use trial and error to decide:)
lda #loval
cmp framecounthi
bcc notreachedyet
jmp nextpart
notreachedyet
jmp effectloop |
| |
Zaz
Account closed
Registered: Mar 2004
Posts: 33 |
Thank you Oswald. I had been thinking of the counter solution, but it's good to know that nothing more complicated is really needed. So the difficulty would be to decide the safety margin.
jmp nextpart ;; fail if part is not loaded due to slow drive
I don't have much equipment to test on, only my 1541C and VICE. Can you recommend a favourite delay? |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
you *must* know that loading is finished, hence the loader routine will return control to you trough an rts, wherever you have called it from :)
so it would look like this in reality:
jsr loadsomefile
jsr loadsomemore
lda framecounter
bcc *+..
you cant reach the bcc before loading has finished, and if you're late from the desired frame the bcc (bcs?) will take care of it :)
btw a tip to load while displaying an effect:
call your effect from an irq which runs once a frame:
irq:
...
lda isitrunning
bne yes
inc isitrunning
cli ;6502 sets the I flag, must clear it to allow irqs
jsr effect
dec isitrunning
yes
rti
make sure to use the stack to save registers $01 state etc, as the irq may be entered more than once. depends on how much frame your effect needs to be finished. after your effect is finished in the remaining time until the raster hits your irq again, the loader gets some free time, or you even may add a counter to call the effect more rarely.
edit: btw, drive speed differences should not be a big problem IMHO around 1-2 tenths of a second at max. per load. never measured, but also neverheard of it being noticably big. |
| |
Zaz
Account closed
Registered: Mar 2004
Posts: 33 |
Hm, with that solution there's the other side of the problem: if the loading is slow and the demo waits for it to finish, the effects will start to lag behind the music, by some tenth of a second for each file loaded.
1-2 tenths of a second, that's at most one revolution at 300rpm, which we could expect if the head is over a random sector when the load starts, so looks like the variation is very small. Do you know how this relates to the 1581, is that drive always faster?
With this info, a safety margin of 20 frames should be plenty.
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
"Hm, with that solution there's the other side of the problem: if the loading is slow and the demo waits for it to finish, the effects will start to lag behind the music, by some tenth of a second for each file loaded."
you should have a feel for loading speed, or use trial and error, and set up your the framecounter timing so, that this wont happen.
watch a few trackmos with an eye on the drive led. there's always a LOT of time for safety margins. this is not a problem at all. also your first concern is to keep a synch with music, and its highly unlikely the music will change mood/etc exactly around the few frames where your load has finished, and you also want to skip to the next part there.
btw, in a demo we had an animation whose depack we have started when it wasnt even fully loaded yet. it was loaded just before it was fully displayed/depacked. Noone reported tho this demo crashing there due to slower drive mechanism. |
| |
Ninja
Registered: Jan 2002
Posts: 411 |
1581 should be faster, significantly. For example, it caches the whole track. With Dreamload, also the transfer to C64 is much faster, because the drive can work at 2MHz.
If it works on 1541, the other drivers work, too. |
| |
Zaz
Account closed
Registered: Mar 2004
Posts: 33 |
Okay, I think I may have overestimated the problems. I'll try it on the 1541 and assume it works on other drives. Probably the music will provide any safety margin needed. Thanks guys! |
| |
Mr Wegi
Account closed
Registered: Jul 2009
Posts: 25 |
You can try save files with other interleave ($0069 in RAM drive 1541 determinated it stand. #$0a, AR set on #08 try from #$01 to #$10), but if You heave small rastertime for loader - always will be slow... |
| |
ready.
Registered: Feb 2003
Posts: 441 |
I have a feeling that 1541 or 1541-II with belt drive mechanism (Mitsumi mechanism) are not so good for multi-load demos, in fact many of multi-load demos crash on these drives. I wonder if it is a problem of how much time the drive is given to load the data (if it had more time, would the demo still crash?) or something else.
Anyhow I always use a 1541-II with Chinon direct drive system. I rarely had any problems with that. |
| |
raven
Account closed
Registered: Jan 2002
Posts: 137 |
All my drives are belt-driven 1541, never had problems with loaders failing or demos crashing, unless the loaders were buggy...
If the loader you're using is interleave-based (most are - Krill's loader works differently though) the loading speed for each file can be optimized greatly.
Simply choose the ideal sector interleave according to the free raster-time you have while loading the file.
Also be clever about it, pre-load whenever you can, even if you have to keep the file in memory & depack at a later time.
I second Oswald's advice about paying attention to drive activity while watching demos. |
| |
raven
Account closed
Registered: Jan 2002
Posts: 137 |
Another speed-related advice:
Save the files in a "linear" way, in loading order.
Make sure the drive head never has to travel more than a single track, within files or between them.
This greatly increases loading speed, especially if you're loading several files back to back. |
| |
Zaz
Account closed
Registered: Mar 2004
Posts: 33 |
So what's a good tool to create .d64 and control the layout in detail? |
| |
WVL
Registered: Mar 2002
Posts: 902 |
I recommend cc1541.exe by jackasser and krill.. there's also my cd1541.exe tool, which basically does the same but isn't fit for release yet.. :P |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
using krill's latest loaders you dont have to mind about interleave or loading order.
the loader before reading a track will check for the sector link order and then will load sectors in the order of appearance under the drive head. in the memory it will place then each sector into it's correct place as they come, thus the load order will be not linear, but as it can catch the sectors.
secondly it has a mechanism, that will position the read head over the next file's track. next file=next one in the directory listing, thus you only have to make sure that the files are copyed to the disk in load order. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Even when loading the blocks out of order, the interleave seems to play a role, albeit somewhat smaller than when loading the blocks sequentially. I believe the file's first and last tracks being the reason. They are usually not fully occupied by the file to be loaded, and so these sparsely filled tracks need to hold the file blocks in a somewhat even distribution so that the loader doesn't have to skip over too many irrelevant blocks. This means that the interleave should be what the loader can handle optimally under the actual cpu time it is given, would it load the blocks sequentially. At 100% cpu for the loader this is an interleave of at least 5 blocks. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
The 16-bit framecount compare would look something like this:
lda framecountlo
cmp #<frametoreach
lda framecounthi
sbc #>frametoreach
bcc notreached
Please note that cmp is working just like sbc, including setting/clearing carry according underflow, except that it doesn't store the result in the accu and doesn't need the carry being set prior to operation. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
so changing the 2nd sbc to cmp should work too? edit:or maybe not as it wont care about the prev. carry. |
| |
Radiant
Registered: Sep 2004
Posts: 639 |
I usually just do something simple along the lines of
lda framecounter
cmp #<target_frame
bne not_there_yet
lda framecounter + 1
cmp #>target_frame
bne not_there_yet
Not as elegant as Krill's suggestion, but I've never had to hunt for individual bytes/cycles in those places, and I reckon it's a bit easier to follow... |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
its easyer to follow, but in plastic kiss at a tightly timed place someone reported that due to his slower drive it manages to be a bit late and then he has to wait 65536 frames to get the demo move on ;) bcc takes care of such a situation. |
| |
raven
Account closed
Registered: Jan 2002
Posts: 137 |
@Oswald:
Even if the head is positioned for the next file as soon as one finish, the head still needs to move x tracks to that position.
When loading files back-to-back, you will get less of a delay between the files if x=1 :)
Also, if all files are saved in a linear way (same as saving one big file that contains everything) you will get zero delay when loading back-to-back.
In tight timing situations, this will help quite a bit! |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
indeed, you're right there. it's also a good idea to load all your data in one file tho. I doubt there's zero delay. |
| |
Zaz
Account closed
Registered: Mar 2004
Posts: 33 |
So what's a reasonable way to handle load errors? Just crash? |
| |
WVL
Registered: Mar 2002
Posts: 902 |
I think all of the things I ever did just crash :) Good enough to show the viewer that something is wrong ;) |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
I'm using:
lda #2
sta $d020
eor #8
jmp * - 5
|
| |
raven
Account closed
Registered: Jan 2002
Posts: 137 |
@Zaz:
It depends on the application I guess.
In my loader I didnt include any error checks/feedback, I figured its quite useless in a "trackmo" style demo where timings are usually tight, no time to re-load if something goes wrong! :)
(Also, it saves precious cycles!) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
If your demo crashes because there's not enough slack with loading times, you are doing something wrong though. A loader is not a raster effect.. :) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quote: So what's a reasonable way to handle load errors? Just crash?
That's bad style. At least there should be some error-indicating screen, like Magervalp suggested. Best would be a human-readable error printout, i think. |
| |
WVL
Registered: Mar 2002
Posts: 902 |
Quote: If your demo crashes because there's not enough slack with loading times, you are doing something wrong though. A loader is not a raster effect.. :)
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. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
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 would usually refrain from calling a particular drive a "lot of shit".
Perhaps there are loaders that break on drives that are within spec?
This is a mechanical device. Lots of things have a wide tolerance range.
You have to test it on a multitude of configurations to be anywhere near sure.
|
| |
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. |
| |
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. :) |
| |
raven
Account closed
Registered: Jan 2002
Posts: 137 |
Thanx Krill :)
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
what & how can go wrong when the speed is too high? how does acceleration fix this ? |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: what & how can go wrong when the speed is too high? how does acceleration fix this ?
You can end up on the wrong track/half track.
Acceleration allows faster operation because it takes advantage of the mechanical intertia of the drive head mechanism.
When it is already moving it takes less force to keep moving and more force to stop it. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
so it's a matter of timing to end up on the right track? |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: so it's a matter of timing to end up on the right track?
It's not, but if you try to go too fast some steps might not happen correctly.
If you go very slow it will always work.
EDIT: some useful info here: http://en.wikipedia.org/wiki/Stepper_motor |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Following is an explanation of why my optimization as described above works. Refer to the timing table for clarity.
The actual low-level read/write circuitry is clocked at 16 MHz. According to which of the four track zones is selected, 13 to 16 ticks of that clock or less are counted until a clock pulse for the decoder is generated. If no flux reversal (magnetization sign flipping) within the duration of this time has happened while reading, the read value is considered a 0. If there has been a transition of magnetization sense, the value is a 1, and that counter is reset to count 13-16 ticks according to the track zone, syncing the circuit by cutting off the current time slice and starting the next one. (*)
Now, a raw bit is made up by four such periods (where the value of the first period decides on the bit value). This allows a rough general speed estimate of 4 cycles per bit cell.
Also, that yields a somewhat more accurate upper bound of the time needed to read a raw byte on a given track zone (note that this is independent from each drive's individual rotation speed and flutter): On an outermost track (1-17, zone 11), a maximum bit time of 13 cycles at 16 MHz equals 1 cycle at approximately 16 / 13 = 1.23 MHz, which makes 4 * 8 (bits) / 1.23 (MHz) = 26.02 cycles to read a complete byte. This means waiting at least 26 cycles after the last BYTESYNC signal (v-flag set) until reading from the VIA port at $1c01, to safely fetch the next byte in $1c01 without syncing to its corresponding BYTESYNC event. On an innermost track (31+, zone 00), this upper bound is 4 * 8 / 1.00 = 32.00 cycles. (**)
This means that waiting 32 or a few more cycles is safe regardless of the selected track zone. How many more cycles to wait are safe is determined by the next minimum amount of safe wait cycles on the outermost tracks. This is simply 2 * 26.02 = 54.02 cycles, and in reality a bit less than that. (***)
Reading the $1c01 values as soon as possible according to this theory, but of course not too early, is advised.
I hope this explanation is sufficient and explains it well enough. :)
(*) The duration of a time slice is shorter (13 ticks) on the outer tracks (1 and up-/inwards) and longer on the inner tracks, giving the outer tracks more blocks than the the inner tracks. As the same angular distance on the rotating disk equals a shorter arc passed on the inner tracks compared to the outer tracks in the same amount of time, more bits can be safely stored on outer tracks because the bit density is constant on the whole surface, but a longer distance is covered.
(**) Note that the actual maximum amount of time needed is somewhat smaller, as no raw byte is made up entirely of 0's, and 1's are slightly "shorter" on a track due to the nature of the encoding scheme as described here. There can be only two 0's in a row because more than two will make the read circuitry go out of sync, since the counter is not reset at the definite start of a time slice denoted by a transition, i.e., a 1. The "lengthiest" GCR nibbles are those which have three 0's, and two 1's.
(***) Again, less than that also because the existence of 80% 1's (4:1) in a "shortest" (again, in the time domain) GCR stream. |
| |
lft
Registered: Jul 2007
Posts: 369 |
Krill, your explanation and time table is very helpful. There's one thing that I feel needs clarification, though.
You mention that the loop must fit into 130 cycles (actually you say 129, but I assume that's an off-by-one error), because that's how fast a complete 40-bit word swooshes past the read head in the outer tracks. This is of course 5x26 corresponding to the five bytes. In fact your loop executes in 124 cycles if every bvc falls through, giving a slack of 6 cycles.
But if the disk was written with a slow motor and is read back with a fast motor, then the image of each sector on the disk will appear shrunk by a factor corresponding to the difference in motor speeds. (This will cause the 1 bits to arrive earlier than expected, resetting the bit timer.) So if a nominally 130 cycles long part of the sector is allowed to shrink to 124 cycles, that allows for a motor speed factor of 130/124 between writer and reader, which is about 1.05, that is 5%. If we center this interval around the nominal 300 rpm, we get a span of 293-307 which is safe.
Here's a handy table of loop tightness versus motor speed margin:
130 cycles: No margin; exactly same motor speed required of writer and reader.
129 cycles: 299-301 rpm
128 cycles: 298-302 rpm
127 cycles: 296-303 rpm
126 cycles: 295-304 rpm
125 cycles: 294-305 rpm
124 cycles: 293-307 rpm
But this is nowhere near the reported speed difference of 320/280 mentioned in another thread. Either those rumours were exaggerated, or nobody has tried to move floppies between such drives and calibrated ones.
Or do I miscalculate?
For comparison, the 1541 ROM routines use 95 cycles, which allows a speed range of 253-346 rpm. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
5% is already quite much.... from my experience with floppy drives considering ~ +/- 2% is safe. .... the huge margins supported by the 1541 probably comes from the oldish PET drives, where you can be lucky if its in the 5% margin =) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
lft: You were right, i was off by one and have actually maxed out the loop to 130 cycles a few loader versions ago.
No problems have been reported so far (and i believe aging drives tend to spin the disk slower, which is alright as it makes the loop less tight). But we'll see... :) |
