Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > Disable software/hardware fastload
2009-09-13 14:03
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....
 
2009-09-14 13:16
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! :-)
2009-09-14 17:36
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
2009-09-14 18:37
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.
2009-09-14 20:10
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).


2009-09-14 20:54
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.
2009-09-14 21:00
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
2009-09-14 22:18
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.
2009-09-14 22:28
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.


2009-09-15 07:14
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.
2009-09-15 16:13
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
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
grass/LETHARGY
Yogibear/Protovision
Airwolf/F4CG
Mibri/ATL^MSL^PRX
CA$H/TRiAD
E$G/HF ⭐ 7
REBEL 1/HF
Guests online: 119
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.6)
4 Coma Light 13  (9.6)
5 The Demo Coder  (9.6)
6 Edge of Disgrace  (9.6)
7 What Is The Matrix 2  (9.6)
8 Uncensored  (9.6)
9 Sprite Bukkake 2  (9.6)
10 Comaland 100%  (9.6)
Top onefile Demos
1 Layers  (9.7)
2 Cubic Dream  (9.6)
3 Party Elk 2  (9.6)
4 Copper Booze  (9.6)
5 Dawnfall V1.1  (9.5)
6 Rainbow Connection  (9.5)
7 Morph  (9.5)
8 Libertongo  (9.5)
9 Onscreen 5k  (9.5)
10 It's More Fun to Com..  (9.5)
Top Groups
1 Booze Design  (9.3)
2 Oxyron  (9.3)
3 Performers  (9.3)
4 Triad  (9.3)
5 Censor Design  (9.3)
Top Crackers
1 Mr. Z  (9.9)
2 OTD  (9.8)
3 Antitrack  (9.8)
4 Fungus  (9.8)
5 S!R  (9.8)

Home - Disclaimer
Copyright © No Name 2001-2025
Page generated in: 0.057 sec.