| |
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....
|
| |
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. |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
