| |
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. |
... 39 posts hidden. Click here to view all posts.... |
Previous - 1 | 2 | 3 | 4 | 5 - Next |