| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
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 |
|
... 23 posts hidden. Click here to view all posts....
|
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
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: 716 |
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: 401 |
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: 1627 |
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: 1989 |
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: 1031 |
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: 1031 |
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 |
| Previous - 1 | 2 | 3 | 4 - Next |
