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.
2010-01-12 18:38
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
2010-01-12 20:28
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?
2010-01-13 07:33
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.
2010-01-14 20:22
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.
2010-01-14 20:59
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.
2010-01-14 22:15
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.
2010-01-18 20:01
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!
2010-01-18 23:35
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...
2010-01-19 11:27
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.
2010-01-20 15:21
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
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
zscs
rexbeng
Paulko64
iceout/Avatar/HF
Peacemaker/CENSOR/Hi..
Guests online: 104
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 Triad  (9.3)
5 Censor Design  (9.3)
Top Original Suppliers
1 Derbyshire Ram  (9.7)
2 Fungus  (9.3)
3 Black Beard  (9.2)
4 Baracuda  (9.2)
5 hedning  (9.1)

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