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-01-20 15:26
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.
2010-01-22 21:30
Zaz
Account closed

Registered: Mar 2004
Posts: 33
So what's a good tool to create .d64 and control the layout in detail?
2010-01-22 21:38
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
2010-01-23 06:42
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.
2010-01-23 11:05
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.
2010-01-23 11:09
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.
2010-01-23 11:48
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.
2010-01-23 13:01
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...
2010-01-23 13:30
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.
2010-01-24 00:19
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!
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
CreaMD/React
Nordischsound/Hokuto..
psych
Andy/AEG
tokra/Akronyme Analo..
commodore_freak
Guests online: 98
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 Webmasters
1 Slaygon  (9.6)
2 Perff  (9.6)
3 Sabbi  (9.5)
4 Morpheus  (9.4)
5 CreaMD  (9.1)

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