| |
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....
|
| |
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... |
| |
Steppe
Registered: Jan 2002
Posts: 1510 |
When in doubt, use C64copy to create your d64 images. There's an option to set the interleave, IIRC. |
| |
Conrad
Registered: Nov 2006
Posts: 849 |
This post is a bit off-topic, as I don't really want to start new threads about the same bloody hardware ;)
I've coded up such a routine in the drive-code which (or that I wish it WOULD do) read GCR bytes via CLV and lda$1c01 as normal, and then immediately decodes them on the fly.
To make it more understandable:
bvc *
lda $1c01
clv
(gcr decoder code) (about 33 cycles :( )
(store byte into buffer)
bvc *
lda $1c01
clv
(etc...)
Due to GCR bytes being 5 bits for each nybble, the whole subroutine reads $1c01 five times to decode 4 bytes (using 4 different decoder routines corresponding to the GCR bit patterns stored in an 8-bit value), which are then stored in the data buffer to send through the serial.
The problem though is that it's showing weird byte results in the buffer. The GCR-decoder routines work fine as i've tested them separately, so I think the problem is that the routines use too many cycles in between each CLV and $1c01 read, meaning it's dragging in speed. Could someone confirm if this is the true or not?
I'm testing the code on a 1541, so the cpu is running at 1MHz, about the same speed as the spin motor iirc.
EDIT: furthermore, I didn't forget to use the GCR conversion tables (lda $f8a0,x ora $f8c0,x) just to let you know. |
| |
TNT
Account closed
Registered: Oct 2004
Posts: 189 |
Yes, your routine is too slow. Target below 26 cycles on average to be safe. That includes waiting for GCR byte, reading it, clearing overflow flag and storing data byte. |
| |
Conrad
Registered: Nov 2006
Posts: 849 |
Thank you TNT, that's what I needed to know :)
Damn, 26 cycles is a very small limit. One of the GCR decoders I coded sums up to 46. :( Guess I'll have to decode them afterwards. |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
1541 isn't fast enough to decode in realtime. You can do a partial decode though (shift bytes around, etc), so the 2nd pass is faster.
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
krill has many innovative stuff in his loaders. for example interleave independency. a vague attempt to describe it: I guess he first scans the whole track for the sector chaining, then he simply loads the sectors in whatever order they come. on the c64 side the loader puts each sector out with the correct offset. for gcr decoding he doesnt decodes the bytes straight instead he aligns the bits to be sent parallel (2bit irq loadr). so sending a nybble looks like: synch sta whateverreg asl sta whateverreg synch |
| |
Peiselulli
Registered: Oct 2006
Posts: 81 |
Use the Fastloader that is implemented in my kernal.
It is base on TLR's Speed loader and working very well for 1541 and DTV.
Link:
DTV Speed Load
With this, you have a speed-up by factor 25 or so.
But no interrupt loader (is no problem for you, as you said).
EDIT: Sorry, that was posted by TLR before. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
factor 25 sounds too much, iirc even AR warp load is slower. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Correct. The original turbo was named 25x, but the speed is probably more like 16x. It could be made a bit faster on the DTV though as there are faster CPU modes + blitter. |
| Previous - 1 | 2 | 3 - Next |
