| |
Wotnau
Registered: Jan 2002
Posts: 7 |
Using Action Replay's fastloader?
Hi everyone,
I'm using REU+AR/RR for development purposes and am struggling with loading/saving times of bigger files in my own tools.
Is there any easy way to use AR's loader from within my own code? Uncle Google doesn't help on this topic at all.
And one step further, ideally I'd like to be able to load bigger-than-64k files into the REU, which would require a load-a-chunk-transfer-to-REU-load-another-chunk-transfer-to-REU etc. approach. Any idea if the AR loader could be abused for that as well?
The beauty of it would be that with 1541Ultimate, the REU+RR combo is always ready to use. :) |
|
| |
Count Zero
Registered: Jan 2003
Posts: 1821 |
Phew.
As for the latter request I'd have to look it up. A noteable feature we had as plans so far only.
As for loading anything with less than 64k into normal memory you just have to make sure the load-vector is not "restored" using e.g. $fd15. Then the fast loader will stay enabled.
In normal basic you may switch between the available loaders using "on" and "off" _and_ (some people missed that so far) "@k+"/"@k-" (for the 7times speed loader with screen on using a 1541). "on" would restore the load/save-vectors to the cart loader.
Btw - shame on me and only Fungus somewhen last year reported it: it seems the "save file with different start address" feature is completely borked :(
Some new release will follow somewhen though. |
| |
TheRyk
Registered: Mar 2009
Posts: 2062 |
About the first/easier question:
If you stick to KERNAL disk operations, and leave ZP $01 in your code as it is default when having AR/RR loader activated, it should remain active without any conflicts. If you switch $01 to RAM at $E000-$FFFF or try anything fancy like trackloader, the AR/RR loader won't work anymore. |
| |
Wotnau
Registered: Jan 2002
Posts: 7 |
Thank you both for your replies!
@Count Zero: Anything I can do to help speeding up you looking it up, or updating RR, or something of that kind, except for saying that if you do implement it, it will have at least one avid user?
(On a funny side note, currently I'm just rereading Neuromancer after years, C0 will follow. :) ) |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Wotnau: How exactly does your development system look like? Do you need speed-up only when initially loading all required data into the REU before proceeding with the actual development? Or do you also need to continually fastload data into the REU later?
I'm asking because when developing natively using the REU, i usually only needed initial boot speed-up before coding. For that i used a re-implementation of the original AR loader, executed from RAM, which would load all required data (around 128 KB) into the REU quickly.
But having the necessary fastloader already in ROM would come in handy indeed.
Count Zero: How do you plan to implement this?
Will you have a hook vector similar to $0314/15 that can be overwritten to execute a custom-made copy routine whenever a block (or maybe track) has been loaded?
Or will you have a special REU mode enabled with a magic secondary address when calling the loader? |
| |
Count Zero
Registered: Jan 2003
Posts: 1821 |
Wotnau: I have been checking the tables available on AR/RR and only found that you could load a track in to the expanded cartridge ram easily. Without quite a few things required to serially and properly load a chain of blocks into normal or extended memory.
However - it might support Krills original RAM based solution.
Krill: first implementation would go for a monitor solution with additional parameters which could be accessed by external programs with parameters then. I would try to not interfere with the load/save vectors as much as the cart currently does apart from some more sane detection for autostarters.
The current bank layout however suxx so much it's just no fun to do any changes on the code there. The new layout currently fails to assemble as it seems I hit a nice Dreamass bug. :) |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting Count ZeroI would try to not interfere with the load/save vectors as much as the cart currently does apart from some more sane detection for autostarters. For compatibility reasons, maybe it'd be possible to enable the hook vector with a special secondary address. It could then be put in the zeropage or low-mem without compromising programs that are not aware of this functionality. |
| |
Wotnau
Registered: Jan 2002
Posts: 7 |
Why do I get an inferiority complex anytime people start talking about controlling external HW? :) Anyway...
@Krill: I'm thinking of two things here. One is an assembler which would support 1541U, i.e. a cart + 16 MB RAM, getting rid of the 4096 line limit in TASM, and allowing for source codes longer than 64 k. Somehow I could never live with X-development tools, I'd even prefer TASM in an emulator on PC to them. Another idea is a few tools which would support the 1541U, like a charset/sprite editor where you could load a full disk of data into the REU, or a 64 k freeze from a game and then browse the memory with the editor to rip the gfx data. Both these ideas involve loading/saving a lot of data repeatedly, and files could theoretically be longer than 256 blocks.
@Count Zero: Thanks a lot for the info. I'll have to hope that you'll update RR with some coool REU-friendly loading goodies before I get to the stage of really needing huge amount of data. :) Because loading it byte-by-byte would work but lead to a frustrated author, not to even mention users. :) |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Perhaps something like this: http://turbo.style64.org/docs/turbo-macro-pro-overview ?
Maybe not exactly what you want but still. |
