| |
Shadow
Account closed
Registered: Apr 2002
Posts: 355 |
Fastloading alternative
I'm currently working on the loading routine for my DTV demo.
It will read in a packed file, unpack it to DTV extended memory, then read the next file and so on until the entire demo is loaded.
To make it compatible with 64HDD, 1541-III-DTV etc. (not everyone who has their DTV connected to a normal 1541 diskdrive) I'm making one version that uses the standard loading routines, that will be compatible with these. I'm testing using 64HDD and it seems to work.
lda #fname2-fname1
ldx #<fname1
ldy #>fname1
jsr $ffbd // call setname
lda #$01
ldx $ba // last used device number
bne !skip+
ldx #$08 // default to device 8
!skip:
ldy #$01 // not $00 means: load to address stored in file
jsr $ffba // call setlfs
lda #$00 // $00 means: load to memory (not verify)
jsr $ffd5 // call load
bcs error // if carry set, a load error has happened
jmp unpackfile1
error:
rts
unpackfile1: // unpack the first file
// Then load next file etc.
...
fname1: .text "0.*"
fname2: .text "1.*"
...
However, as you all know the built in disk routines are extremely slow, so it will take quite a while to load the demo.
So I'm thinking of doing a version for those that use a real 1541 that uses some kind of fastloading.
My question is if anyone has a code snippet that does the same as the above, but FASTER! :)
I don't need any IRQ loader or any other such fancy stuff, since I do all loading before the demo starts. The only thing I require of the loader is that it leaves the normal text-screen $0400-$07ff visible (I'll use that to show loading progres).
Any ideas?
|
|
... 11 posts hidden. Click here to view all posts....
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
well, there's dreamload for high compatibility. approach doc baccardi with the idea of supporting DTV too :) |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
You can make things simpler for you by allowing the user to select fast load or kernal load at boot.
If there is a lot of data to load and 1541 only + blank screen is acceptable I'd like to mention DTV Speed Load which is quite fast.
It is possible to use this with open screen on the DTV as you can disable badlines, but you'll need to hack a bit to make bit 0 and 1 of $dd00 constant.
Otherwise I second Mv's and Oswald's recommendations. |
| |
Shadow
Account closed
Registered: Apr 2002
Posts: 355 |
Thanks all! I've decided to try to port and rewrite the covertbitops loader to fit my needs. |
| |
Shadow
Account closed
Registered: Apr 2002
Posts: 355 |
Managed to get the covertbitops loader running. However, while it is faster, it is nowhere close to 5x speed.
I timed the loading of my 21kb picture (about 85 blocks or so):
Normal kernal routine: 56 seconds
Fastloader routines: 28 seconds
So I'm getting only a 2x speedup... |
| |
TNT
Account closed
Registered: Oct 2004
Posts: 189 |
Try different interleave values when writing files to disk. This will affect kernal loading speed, but it's so slow anyway that nobody notices... |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Some tools also write with interleave 1 (c1541?) which will slow the loading down. In theory default interleave 10 should be OK for 2-bit fastloading, but I give no guarantee that the 2-bit loader presented in the fastloading rant is in any way optimal, and it's long since I looked at it.. |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
My bad, the speed I get in my old benchmark is 1100 bytes per second (roughly 3x) on the 1541 and 2600 bytes per second on the 1581. I optimized Lasses loader a bit and added custom GCR decoding. To get more speed you need to implement a more efficient handshake with block xfer, and not do a full handshake for each byte. You'll also get a speed boost by doing GCR decoding on the C64 side, with nice big lookup tables.
|
| |
Shadow
Account closed
Registered: Apr 2002
Posts: 355 |
I have to admit that my knowledge of the inner workings of the 1541 are non-existent, so all this about interleave and GCR decoding is total mumbo jumbo to me! :)
Anyway, things seems to work and the fastloader is faster than the original atleast, so all is good. ;) |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
It's simple enough: let's say you load a file that starts at track 17 sector 0. The 1541 loads the first sector into ram, decodes the GCR data, and then sends over the 254 decoded bytes to the C64. It then requests the next sector of the file. As the disk keeps on spinning, the next sector under the read head is not 17:1. When you set the interleave, you try to predict what the next sector will be (with a little safety margin to allow for variance in drive mechs, etc) to minimize the time the 1541 has to wait for the sector to become available. With the coverbitops 2-bit loader a good interleave is somewhere around 10 or 11, iirc - that is after 17:0 the 2nd sector will be saved to 17:10 or 17:11, then 17:20 or 17:2, etc.
As for fast GCR decoding, that's a little more complicated, and a fair amount of work to get right. Basically it's replacing the routine that decodes the 325 bytes bytes read by the 1541 into the 256 bytes that get sent over to the C64. The drive rom routine that does the conversion is notoriously slow.
|
| |
Shadow
Account closed
Registered: Apr 2002
Posts: 355 |
Interesting stuff, I can see how the interleaving can have quite an impact on loading now.
I created my disk by using D64 Editor 0.028 on PC and then writing it to disk with a MMC64. So the question is whether D64 Editor puts the files with a correct interleace or not... |
| Previous - 1 | 2 | 3 - Next |
