| |
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? |
|
... 6 posts hidden. Click here to view all posts.... |
| |
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).
|
| |
AlexC
Registered: Jan 2008 Posts: 299 |
Maybe you should consider small autostarting boot file that will overwrite IRQ vectors and than load the rest from tape using own turbo routine?
Out of curiosity: are you also considering using fake decryption loop as in mentioned example? It is a neat trick and many people even today have problems with CIA internals. |
| |
Richard
Registered: Dec 2001 Posts: 621 |
Quote: Maybe you should consider small autostarting boot file that will overwrite IRQ vectors and than load the rest from tape using own turbo routine?
Out of curiosity: are you also considering using fake decryption loop as in mentioned example? It is a neat trick and many people even today have problems with CIA internals.
Didn't the original source in codebase do that (Kernal Boot, then turbo) I'm sure it did.
I wasn't planning on fake decryption. I'm not too familiar with CIA tricks etc |
| |
MagerValp
Registered: Dec 2001 Posts: 1078 |
WTH does that code do? You're redirecting the STOP vector and jumping to FILE OPEN error?
Anyway, to make all users suffer through slow loading just to blink the screen, simply SETNAM/OPEN/CHKIN/CHRIN/CLOSE/CLALL, aka using kernal I/O exactly as described in the PRG. It would of course be preferable to just use the LOAD vector as is so people can enjoy fast loading, or install an irq loader so people can watch something interesting on the screen while the game loads. |
| |
chatGPZ
Registered: Dec 2001 Posts: 11392 |
richard, please. not this FUGLY loading code again. *sigh*
really. what magervalp said. i think on codebase there are even examples (if not, there some in the PRG i think).
also use LOAD, really :) unless you really *need* to read byte per byte (because you are depacking on the fly or something like this) then dont do it. especially not only to do some silly 1986 style border flashing.
and besides, there is no reason to disable any fastloaders for all this in any case. just dont use this goddamn fucking ugly loader "code". infact forget that it ever existed, and where it came from, and destroy all other traces of its existance.
|
| |
AlexC
Registered: Jan 2008 Posts: 299 |
I also agree with MagerValp unless I still don't fully get what you are trying to do. Anyway for mastering tape purposes I'd do it on PC today instead on real thing. That way I can get proper tap file within seconds instead of hours. |
| |
Richard
Registered: Dec 2001 Posts: 621 |
@Groepaz, I agree. That loader code used, was pretty ugly. I have found a better way to handle the disk system following one of the old forum posts, and implementing the load address routine into the prog. |
Previous - 1 | 2 - Next |