| |
Richard
Registered: Dec 2001
Posts: 621 |
Disable software/hardware fastload
Please can you help? Does anyone know how I can program a routine that disables Action Replay cart fastload when loading from a 1541-II disk drive? |
|
| |
AlexC
Registered: Jan 2008
Posts: 299 |
Never thought about it but I guess changing LOAD and SAVE vectors at $0330-$0331 and $0332-$0333 should do it. Why exactly you want to do it if I may ask? |
| |
Count Zero
Registered: Jan 2003
Posts: 1940 |
JSR $FD15 or a copy loop like it restoring load/save vextors at $0330 will disable cart fastloaders.
The turbo-mode-thing on AR freezer just points them back to the cart mode.
l8r
Count Zero/CyberpunX/SCS*TRC |
| |
TNT
Account closed
Registered: Oct 2004
Posts: 189 |
If you use $FD15 then remember that it copies ROM from $FD30-$FD4F to RAM at the same location. It also resets all kernal vectors including IRQ/NMI pointers. |
| |
Richard
Registered: Dec 2001
Posts: 621 |
Thank you :o)
I wanted to be able to disable the fastload software from the cartridge to read end address of a program, after it loads. Then the end address is stored to two zero page bytes, then transferred as an end address to the IRQ loader's tape saver. Well, that's the plan. I think that kind of program could be useful for some people, who I know. :)
|
| |
Stone
Registered: Oct 2006
Posts: 172 |
Shouldn't all well-behaved (i.e kernal replacement) loaders store the end load address in $ae/$af? Doesn't Action Replay do this? |
| |
TNT
Account closed
Registered: Oct 2004
Posts: 189 |
They should also return the end address(+1) in x/y registers. |
| |
Mace
Registered: May 2002
Posts: 1799 |
A bit off topic here, perhaps, but I had to vent it somewhere:
I'd like to see a (turbo)tape copier that can copy auto-run files from tape to disk.
Now THAT would be useful! :-) |
| |
Count Zero
Registered: Jan 2003
Posts: 1940 |
@TNT: yes, trashes memory using $fd15. thats why I mentioned the loop.
I somehow remember that some carts always trashed $ae/$af often with values of $ae $00. (also after machine reset)
That's likely due to abuse of the register, but some quick tests just revealed that all Action Replay based carts properly return low/high end address in X and Y and also at $ae/$af right after loading.
E.g. $9d doesn't seem to influence it either, so I am pretty sure the loader is basically fine and doesn't need to be disabled for such a...hem ... delicate task.
l8r
Count Zero/CyberpunX/SCS*TRC |
| |
AlexC
Registered: Jan 2008
Posts: 299 |
Do I smell some kind of tape mastering system in the works?
Anyway I've tested TRF and FC3 and both store proper values in $AE-$AF. I would assume that even if some multi purpose turbo loader is trashing those values it must still feed proper data into $2B-$2C and $2D-$2E for BASIC to work correctly. This is why $2D-$2E is your safe bet I suppose.
Secondly I really don't get it why you want to bypass AR fastload if you just want to do save on tape later. Why not not just remove cartridge for this task? The only reason I can imagine is that you are already using whole 64kb RAM and you can't squeeze in your save procedure.
If you are working on VICE try out Trilogic Expert cartridge (unless of course you can find the real hardware!) - the default dump comes with monitor that lacks fastloader and unless you need to work with tracks and sectors it will do just fine like AR does.
You might also consider another approach: why not use AR parameters option? That way you can use internal cartridge ram and even use AR procedures for your own tasks while having access to C64 memory.
@Mace: I guess the problem is not how the autoboot works because in most cases it can be moved to disk anyway but the problem is how the boot loads other parts of the game. Unless you are talking about single files - than I think it would be possible to have generic transfer routine. Checkout Fungus tape transfers soruces at codebase64. |
| |
Richard
Registered: Dec 2001
Posts: 621 |
Quote: Do I smell some kind of tape mastering system in the works?
Anyway I've tested TRF and FC3 and both store proper values in $AE-$AF. I would assume that even if some multi purpose turbo loader is trashing those values it must still feed proper data into $2B-$2C and $2D-$2E for BASIC to work correctly. This is why $2D-$2E is your safe bet I suppose.
Secondly I really don't get it why you want to bypass AR fastload if you just want to do save on tape later. Why not not just remove cartridge for this task? The only reason I can imagine is that you are already using whole 64kb RAM and you can't squeeze in your save procedure.
If you are working on VICE try out Trilogic Expert cartridge (unless of course you can find the real hardware!) - the default dump comes with monitor that lacks fastloader and unless you need to work with tracks and sectors it will do just fine like AR does.
You might also consider another approach: why not use AR parameters option? That way you can use internal cartridge ram and even use AR procedures for your own tasks while having access to C64 memory.
@Mace: I guess the problem is not how the autoboot works because in most cases it can be moved to disk anyway but the problem is how the boot loads other parts of the game. Unless you are talking about single files - than I think it would be possible to have generic transfer routine. Checkout Fungus tape transfers soruces at codebase64.
It is because when I use a non fastloader, i'm using a small routine:
lda #<flash
ldx #>flash
sta $0328
stx $0329
cli
maindiskloader ;Rest of program
flash
dec $d020
inc $d020
inc zeropage1
lda zeropage1
bne ignore
inc zeropage2
ignore jmp $f6fe
Unless there's an alternative way....
What I done to the disk loader is outside the fastloader. I wanted the border to flash, during disk loading, and also use the zero pages to get the end address of a program for storing to the tape.
My idea for the disk/tape transfer is based on the Autoboot Turbo loader by Martin Piper (Who will be credited for the turbo in the program's front end credits), but instead of compiling everything with binary/prg files included. The only difference is that the program files will be manually entererd by input and load from disk, then written to tape and the program loaded from tape uses an executable basic run address.
The plan is for the program to load:
- Music ($1000-$2000), Init $1000, Play $1003
- Vidcompaint/Koalapaint picture (Relocate picture data $2000 - bitmap, $4000 - colour ram, $4400 - video ram
- Game (Disk loader will load the runnable game to $4800, and while loaded there, must not exceed $BFFF). Tape loader uses transfer routine to relocate all the data from $4800-$xxxx to $0801, then JSR $A659, JMP $A7AE
The loader's appearence has been changed to a black border with pulsating loader lines (based on the original sprite's flashing).
|
... 6 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 - Next |
