| |
Jammer
Registered: Nov 2002
Posts: 1289 |
TURBO loaders/savers
as in the topic - i really need some information on good turbo loaders and savers. irq ones don't count. it would be also great if they were tass sources, optionally with any relocator. what do you recommend? :) |
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11136 |
what exactly do you want to use them for and what are required features (is a plain t/s loader ok?) |
| |
yago
Registered: May 2002
Posts: 332 |
iirc, Plushdos has also a turbo-loader (and saver), besides the irqloaders. No sources, though. |
| |
Jammer
Registered: Nov 2002
Posts: 1289 |
they are needed for tools.
the main requirements are that they should be relatively fast, work without errors and cannot hang up the drive.
turbo loader:
- possibilitiy of forcing loading adress for the file
turbo saver:
- possibility of forcing loading address for the saved file
they should work without disabling the screen thus nothing that pokes around $d011.
they cannot watch memory bank setting all the time (explorer's turbo loader/saver does this way).
they should work without problems or hang ups with another drives (up to drive 11).
it would be nice if rom related procedures were executed by kernal jumps, not directly in rom addresses (for compatibility)
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11136 |
these requirements sound like something you have to write yourself =) |
| |
enthusi
Registered: May 2004
Posts: 675 |
or use TurboTape |
| |
Frantic
Registered: Mar 2003
Posts: 1628 |
Just wanted to say that I also think it would be nice if someone wrote routines like this... precisely for tools.
Codebase64 wants you! ;) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11136 |
just code those tools to properly use kernal calls and they'll work just fine with whatever speeder is installed. problem solved :) |
| |
AlexC
Registered: Jan 2008
Posts: 293 |
Just use action replay ;) Jokes aside I think you will need to write one by yourself. I'd take a peek at Covertbitops loader system and dreamload. |
| |
MagerValp
Registered: Dec 2001
Posts: 1059 |
Another vote for "just use kernal calls". Trust the user to have a fastload system installed. Everyone has some kind of fastload system - be it AR6, JiffyDOS, or warp mode. |
| |
Frantic
Registered: Mar 2003
Posts: 1628 |
You're all right about the kernal call stuff. Anyway, what would be really nice is if someone wrote a small little fileselector with dir/load/save capabilities and some options to enforce load/save adresses. It is easy to do, of course, but it would still be nice to have this in public, since it would be reuseable for all tool coding purposes.
Anyway... One benefit of actually having custom turbo load/save routines is that you could load a single file into split memory segments, rather than having to load it in a single chunk in C64 mem. Not a big issue in most cases, perhaps, but at least that is something that put a stop to the plans of using Kernal calls for load/save for me at one time. |
| |
hevosenliha
Registered: Sep 2008
Posts: 48 |
Quote: Another vote for "just use kernal calls". Trust the user to have a fastload system installed. Everyone has some kind of fastload system - be it AR6, JiffyDOS, or warp mode.
Or IDE64, please stick to the kernel calls! |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
If you read the file byte-by-byte with Kernal calls (open/chrin etc.), you can split the data into memory just like you wish, turbo not needed for that.
|
| |
Frantic
Registered: Mar 2003
Posts: 1628 |
@Cadaver: You're right, of course... :) (...but then you won't have the benefit of turbo-speed inherited from a plugged in cartridge of course.) |
| |
Krill
Registered: Apr 2002
Posts: 2852 |
If you need sources, i can give you all my stuff, including the current loader (the multi-drive protocols aren't implemented yet), and those of Plush-DOS yago mentioned, although that is quite outdated stuff. |
| |
ready.
Registered: Feb 2003
Posts: 441 |
As I need a saver routine for my gfx editor as well and I spent some time in trying to implement it, here is what I came up with using Kernal routines:
*=$c000
;setnam
lda #(name1-name0) ;name length
ldx #<name0
ldy #>name0
jsr $ffbd
;setlfs
lda #$01 ;logical file number
ldx #$08 ;device number
ldy #$01 ;secondary address
;save
lda #<data0
sta $fb
lda #>data0
sta $fc
lda #$fb ;zero page pointer
ldx #<data1
ldy #>data1
jsr $ffd8
rts
name0 .text"CIAO"
name1
*=$c100
data0 .byte 0,1,2,3,4,5,6,7,8,9
data1
this saves the file "CIAO" to disk #8. The file contains the data 0,1,2,3,4,5,6,7,8,9 starting at $c100.
It might be obvious for somebody but I must say it was not for me at the beginning how to use Kernal routines. Useful reference:
http://noname.c64.org/csdb/release/?id=83305&show=summary#summa..
I tried with Krill's loader but I must say I got a headache quite soon. Sorry Krill, I need some time to figure out how to use it. I just needed a quick solution.
|
| |
Oswald
Registered: Apr 2002
Posts: 5025 |
http://codebase64.org/doku.php?id=base:saving_a_file
use codebase people, it already has a wealth of information :) Graham's handling of device Nr is more transparent take a look, otherwise it looks to be the same. It's better to use the kernal correctly, than an own save routine, because that way you'll be compatible with all kind of devices. (just dont hardcode #8 :) |
| |
ready.
Registered: Feb 2003
Posts: 441 |
yes you are write Oswald...I just got driven by enthusiasm when I noticed my code worked. But Codebase should be The Reference. |
| |
ready.
Registered: Feb 2003
Posts: 441 |
back to this topic again.
I succesfully used the load/save kernal calls under basic and some assembler code under $c000 area to call the kernal routines and setup the needed file parameters.
But...when it comes to using these calls under an assembler program that is in the basic area ($a000-$bfff) troubles show up. So far I tested only the save routine and after calling it, it gets lost somewhere after
JSR $FFD8 ; call SAVE
for some reason it looks like it tries to re-enable the interrupt vectors at $0314-$0315. It never makes it back after the JSR $FFD8
before calling the kernal routine I set $01 to $36, so Kernal is enabled and also give a SEI to stop the active IRQs.
any help is very welcome!
regards,
Ready.
|
| |
Oswald
Registered: Apr 2002
Posts: 5025 |
the save routine may contain a cli and/or there might be a routine in the basic area thats called in the process. you'll most probably have to use a custom save routine to save from under the roms. |
| |
Stryyker
Registered: Dec 2001
Posts: 465 |
The load/save routines should work under the BASIC ROM. Can you test in VICE with some triggers to call the monitor? |
| |
ready.
Registered: Feb 2003
Posts: 441 |
ok, found the problem.
Since I have a $d012 raster interrupt active for sprite multiplexing, I thought a SEI was enough to disable it before invoking the save routine:
SEI
LDA #fname_end-fname
LDX #<fname
LDY #>fname
JSR $FFBD ; call SETNAM
LDA #$00
.....
but since the saving routine after:
JSR $FFD8 ; call SAVE
has some CLIs inside, this would re-enable the raster interrupt and do the mess.
Now I added:
SEI
LDA #$00
STA $D01A ;VIC Interrupt Mask Register (IMR)
LDA #fname_end-fname
.....
and now it works.
By the way: basic ROM can be disabled. |
| |
Frantic
Registered: Mar 2003
Posts: 1628 |
I added some notes regarding the issues that READY came across to codebase now. I guess it may help someone else..
http://codebase64.org/doku.php?id=base:dos_examples |
| |
Angel of Death
Registered: Apr 2008
Posts: 210 |
From the posts I assume we are talking about disk (fast) loaders savers.
Slash design has used kernel-based load/save/disk-command in his Characterize V0.03 which (as I found out) are quite safe and sturdy.
Used as a basis they should pick up any other cartridge/external based fastloader.
But, then again, if the files are not too big why waste precious memory on fastloaders?
Should be better uses for that in an application...
|
| |
terric
Account closed
Registered: Feb 2009
Posts: 47 |
I actually made a glitching irq loader with the kernel routines. Using a source from codebase64 and some facts from this thread. It is not fast, 1byte per frame.
Used
before
sei
lda #$00
sta $d01a
lda #$37
sta $01
" loading one byte "
and afterwards
sei
lda #$01
sta $d01a
lda #$35 // whatever you like
sta $01
cli |
| |
ready.
Registered: Feb 2003
Posts: 441 |
@Frantic: thanks for adding the issue to Codebase |
