| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quick loading without an IRQ-loader!
Hey guys!
I know my ways around the various IRQ-loaders normally used today, but what about the non-IRQ-loaders (no music, $d011=0, sei, no-NMIs)?
- Which one can you recommend?
- Are there any that comes with source so that I can easily relocate them?
- How much faster are (can) a non-IRQ-loader be compared to an IRQ-loader?
- Any that perhaps easily can be connected to pucrunch or exo and thus load and decrunch at the same time?
- Is this stupid? Are the modern IRQ-loaders as fast or faster than the old legacy non-IRQ-loaders anyway?
/JackAsser |
|
| |
Radiant
Registered: Sep 2004
Posts: 639 |
Non-IRQ loaders are a lot faster (several multitudes) IIRC. There's one on Plushdos, but as you know, Krill gets mad if you use it. ;-)
|
| |
Ninja
Registered: Jan 2002
Posts: 411 |
The routines getting data from the disk to the drive are not faster, but the transfer to the c64 is speeded up a lot as no handshaking is needed (think of synchronous against asynchronous).
Dunno what you are up to, have you tried thinking about just using the LOAD-vector as most people have some sort of cart (which is probably faster anyhow)? Plus, no compatibility problems then. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: The routines getting data from the disk to the drive are not faster, but the transfer to the c64 is speeded up a lot as no handshaking is needed (think of synchronous against asynchronous).
Dunno what you are up to, have you tried thinking about just using the LOAD-vector as most people have some sort of cart (which is probably faster anyhow)? Plus, no compatibility problems then.
Just fixing old stuff. That old stuff uses some loader but it's quite slow. I did use the LOAD-vector at some places and thought that it would be nice to replace the fast loader with something really quick. But sure, I can change all loading places to normal LOAD and rely on the cart.
/JackAsser |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
In cases of normal fastloading, it is best to rely on the DOS vectors so cartridge fastloaders and other stuff like ide64 etc can be use.
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: In cases of normal fastloading, it is best to rely on the DOS vectors so cartridge fastloaders and other stuff like ide64 etc can be use.
As I do it now I first 'fix' the KERNEL by doing:
JSR $FF84
JSR $FF8A
Then I load using the technique you described in http://www.codebase64.org/doku.php?id=base:loading_a_file i.e. by calling $FFBD, $FFBA and $FFD5.
This works totally fine. Is this 'cart-compatible'? Or should I load via some other soft-vector?
/JackAsser |
| |
iopop
Registered: Dec 2001
Posts: 317 |
It will use the "cart" fastloader if you keep $0330/$0331 intact. |
| |
AlexC
Registered: Jan 2008
Posts: 299 |
I'd opt for cart fast loader as it makes it working with MMC and other (both current and future) hardware extensions possible. Also not everyone is using 1541 (I'm thinking about C128D users for example) as their number 8 disk drive. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
Quote:JSR $FF84
JSR $FF8A
Disables all cartridge fastloaders and hardware drivers.
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Quote:JSR $FF84
JSR $FF8A
Disables all cartridge fastloaders and hardware drivers.
Hmms, ok. So, what do I need to preserve to make sure LOAD works when I need it too (and that it will use the fastloader on the cart)? |
| |
j0x
Registered: Mar 2004
Posts: 215 |
$0330-$0331 should be enough.
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11391 |
make sure you do not reset the vectors, ever :) |
| |
Oswald
Registered: Apr 2002
Posts: 5095 |
you can reinit everything through kernal subs, but god knows which one you need for load. probably easyer to figure tho :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11391 |
Quote:you can reinit everything through kernal subs
NO! if a cartridge is inserted, then calling the kernal functions will reset the vectors to their "normal" values. to be able to use cartridge loaders you must NOT call i/o reset (might disable cartridge), and NOT touch the vectors whatsoever.
said kernal functions beeing called is pretty much the number one reason for cartridge fastloaders NOT working with a lot of programs =P |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Quote:you can reinit everything through kernal subs
NO! if a cartridge is inserted, then calling the kernal functions will reset the vectors to their "normal" values. to be able to use cartridge loaders you must NOT call i/o reset (might disable cartridge), and NOT touch the vectors whatsoever.
said kernal functions beeing called is pretty much the number one reason for cartridge fastloaders NOT working with a lot of programs =P
So what exactly must I do to be safe using the cart loader? Keeping $0330 and $0331 is simple enough, but is that enough? How must ZP and other stuff be set prior to calling LOAD, can it be anything?
/JackAsser |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Quote: Hmms, ok. So, what do I need to preserve to make sure LOAD works when I need it too (and that it will use the fastloader on the cart)?
Do you need to mess with $03xx at all? Not touching them and just using LOAD means that it'll use AR6 or JiffyDOS or whatever.
Emulator users are screwed though. Flirt with GRG and use n0sd0s?
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11391 |
Quote:So what exactly must I do to be safe using the cart loader? Keeping $0330 and $0331 is simple enough, but is that enough? How must ZP and other stuff be set prior to calling LOAD, can it be anything?
- don't touch the vectors (not just load, but also chrin etc, just incase) or restore them
- not call the kernal routines for resetting i/o (these also rewrite vectors, but not with the one that are used by the cart so effectivly they disable cart fastloaders)
- not do any other fancy stuff that stops carts from banking in their ram into i/o area (thats were the vectors point to)
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Quote:So what exactly must I do to be safe using the cart loader? Keeping $0330 and $0331 is simple enough, but is that enough? How must ZP and other stuff be set prior to calling LOAD, can it be anything?
- don't touch the vectors (not just load, but also chrin etc, just incase) or restore them
- not call the kernal routines for resetting i/o (these also rewrite vectors, but not with the one that are used by the cart so effectivly they disable cart fastloaders)
- not do any other fancy stuff that stops carts from banking in their ram into i/o area (thats were the vectors point to)
Hmms ok. Really, is that all?
- Exactly what memory area is 'the vectors'? $03xx?
- What about SEI/CLI? Ok if SEI?
- What about the CIA-chips? Any state they need to be in?
- What about zero page, anything I need to consider there?
- Will is also work without a cart? Iirc the normal KERNEL is quite picky about timers and CIA in general hence my call to reset IO.
It will be quite tricky for me to preserve the whole $03xx area, possible to pin point exactly like how Groepaz started?
And FYI I'm 'cracking' an old demo.
/JackAsser |
| |
chatGPZ
Registered: Dec 2001
Posts: 11391 |
- Exactly what memory area is 'the vectors'? $03xx?
yes
- What about SEI/CLI? Ok if SEI?
not sure, but it should not matter - the kernal routines sei/cli internally and you should expect them to do it too.
- What about the CIA-chips? Any state they need to be in?
probably :) i'd check if it works with normal kernal, then it should be ok with carts too
- What about zero page, anything I need to consider there?
setnam, chkout etc should set up the required ZP ... i think :)
- Will is also work without a cart? Iirc the normal KERNEL is quite picky about timers and CIA in general hence my call to reset IO.
yes. you should always test against the original kernal. cracks often use a clone of the kernals reset-i/o function, with the unwanted stuff removed.
- It will be quite tricky for me to preserve the whole $03xx area
like jox said, only the LOAD vector _should_ be enough. for a demo that only ever uses the load call anyway :)
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: - Exactly what memory area is 'the vectors'? $03xx?
yes
- What about SEI/CLI? Ok if SEI?
not sure, but it should not matter - the kernal routines sei/cli internally and you should expect them to do it too.
- What about the CIA-chips? Any state they need to be in?
probably :) i'd check if it works with normal kernal, then it should be ok with carts too
- What about zero page, anything I need to consider there?
setnam, chkout etc should set up the required ZP ... i think :)
- Will is also work without a cart? Iirc the normal KERNEL is quite picky about timers and CIA in general hence my call to reset IO.
yes. you should always test against the original kernal. cracks often use a clone of the kernals reset-i/o function, with the unwanted stuff removed.
- It will be quite tricky for me to preserve the whole $03xx area
like jox said, only the LOAD vector _should_ be enough. for a demo that only ever uses the load call anyway :)
@Groepaz: Hmmz. :) Thanx for the good input.
Basically I'll take the bits and pieces of information and dis-information from you guys and start experimenting my self. :D I have a good idea what research I need to do know, so thanx!
/JackAsser
|
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
A tool which I am coding uses cartridge for fastloading/saving. Regarding the state of the CIA's I basically just make sure that there is a timer interrupt (Timer A, CIA 1, I believe) which goes off once a frame, pointing to the vectors at $03xx, and I enable the interrupts (dunno if that is necessary).
I don't really know about required ZP variables, apart from the ones you explicitly set up when calling the load/save routines, since I don't touch ZP much in my tool. |
| |
Mace
Registered: May 2002
Posts: 1799 |
In reply to the original question (I haven't read this thread completely): my favourite speedloader was Gigaload.
It's embedded in at least one Secure demo I made.
Don't know where I got it from...
I vaguely remember seeing it on a GEOS disk, once, though. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
Also important: $BA should not be destroyed. It's the last used device number. If someone loaded your program from device 11, your program should continue to do so too. Don't default everything to device 8.
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Also important: $BA should not be destroyed. It's the last used device number. If someone loaded your program from device 11, your program should continue to do so too. Don't default everything to device 8.
Noted. Thanx! |
| |
Oswald
Registered: Apr 2002
Posts: 5095 |
Quote: Quote:you can reinit everything through kernal subs
NO! if a cartridge is inserted, then calling the kernal functions will reset the vectors to their "normal" values. to be able to use cartridge loaders you must NOT call i/o reset (might disable cartridge), and NOT touch the vectors whatsoever.
said kernal functions beeing called is pretty much the number one reason for cartridge fastloaders NOT working with a lot of programs =P
just store / restore 330/331 before after kernal resets :P and dont touch it otherwise. |
| |
j0x
Registered: Mar 2004
Posts: 215 |
To answer your first question in #18: "the vectors" are $0300-$0333, inclusive.
.. and what Graham said. Will it work on device 1 ? :D
> Any that perhaps easily can be connected to pucrunch or exo and thus load and decrunch at the same time?
Loading while decrunching will make better use of the otherwise idle cycles on the c64-side, but may make you more sensitive to nonoptimal sector interleave, since you'll need your data to be loaded in order. A bit of thinking can solve most of this problem, giving you a "semi-inorder" loading scheme that combines loading while decrunching with an interleave-tolerant loader. This explanation is pretty poor -- sorry.
Alsö alsö nöte:
* While many carts init $ba to 8, the original rom init does not. This is only important for your first load, of course.
* If you're finding it difficult to preserve the vectors, it'll probably be hard to find a (decent) fastloader that'll fit in memory.
* When it comes to compatible CIA settings, you can't make sure each and every hard/firmware loader works. Going with default CIA settings is your best bet. The same goes for SEI/CLI. Clearing the flag is your best bet.
|
| |
HCL
Registered: Feb 2003
Posts: 728 |
Loading without IRQ is not "several multitudes" faster really.. Many IRQ-loaders manage to load with a sector interleave of 5 (read every 5:th sector), while a non-irq loader can manage sector interleave of 3 (afaik) without parallell cabele or other HW-extentions.
So.. the multitide there is like 66% faster.
|
| |
Devia
Registered: Oct 2004
Posts: 403 |
if $ba is #$00 you should set it to #$08 otherwise keep it intact as j0x and graham pointed out.
But if it is 00, your program got loaded via "other means" and there might be a physical or emulated floppy device present with the actual content on it, only this device didn't set $ba when it loaded via "other means".
I've seen some devices do this, can't remember which tho ;-) -- maybe 1541U?
|
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
I'd guess IDE64 (I remember stories about compability problems due to no support for STATUS etc). CodeNet also doesn't set $BA.
And concerning using $BA for loading:
LDA #$01
LDY #$01
LDX $BA
BNE .skip
LDX #$08
.skip
JSR SETLFS
does the trick.
|
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
I made a first start on an article about this topic on Codebase, since it is a recurrently asked question here on CSDb:
http://codebase64.org/doku.php?id=base:making_use_of_the_fastlo..
Feel very free to fill in with more details here!
//Frantic |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: I made a first start on an article about this topic on Codebase, since it is a recurrently asked question here on CSDb:
http://codebase64.org/doku.php?id=base:making_use_of_the_fastlo..
Feel very free to fill in with more details here!
//Frantic
I'm currently writing a test program that I want you guys to test on various more or less exotic devices. Then when it works I'll post my findings and the code example on codebase. |
| |
Burglar
Registered: Dec 2004
Posts: 1105 |
things you should ask yourself:
- am I gonna use only that kernel loader or will I use an irq loader later on that breaks compatibility with those mcc/ide64 lamers anyway?
- is the speed gain really that much?
- some cartridge loaders are plain suckage (ie: unable to load under rom, slow and fiddle with more registers that could possibly break your program)
imho using a kernel loader should be an option, not a fixed feature. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
Quote:- some cartridge loaders are plain suckage (ie: unable to load under rom, slow and fiddle with more registers that could possibly break your program)
Never seen a cartridge loader which cannot load under ROM. But most cartridge loaders cannot load below I/O area, just like the kernal loader.
|
| |
Burglar
Registered: Dec 2004
Posts: 1105 |
Quote: Quote:- some cartridge loaders are plain suckage (ie: unable to load under rom, slow and fiddle with more registers that could possibly break your program)
Never seen a cartridge loader which cannot load under ROM. But most cartridge loaders cannot load below I/O area, just like the kernal loader.
yea, you're correct, the d000-dfff bit is the bitch |
