[CSDb] - User Forums - Loading and saving to disk using kernel

Welcome to our latest new user maak ! (Registered 2024-04-18)

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > Loading and saving to disk using kernel

2018-06-13 18:59

JackAsser

Registered: Jun 2002
Posts: 1987

Loading and saving to disk using kernel

Assume: Machine booted from cart. Cart ROM at $8000-$bfff. IO at $Dxxx and KERNAL at $e000-$ffff

What calls do I have to do to use KERNEL load/save?
What RAM and ZP will be trashed by this?
How will it affect my IRQs? (I have CIA1 and raster IRQs running via $0314/15)

2018-06-13 23:37

Scan

Registered: Dec 2015
Posts: 110

I currently use this to load levels in a game I've been working on, but I wouldn't recommend using kernal calls for doing this. If you don't reset the IO vectors first some unexpected results might occur. For example, if you have the Final Cartridge 3 enabled this will blank the screen while loading. This also does not play nice with interrupts.

.const SETLFS = $ffba
.const SETNAM = $ffbd
.const LOAD   = $ffd5

load_level: 	   	lda #fname_end-fname
		        ldx #<fname
		        ldy #>fname
		        jsr SETNAM    // call setnam
		        ldx $ba       // last used device number
		        bne !+
		        ldx #$08      // default to device 8
!:			ldy #$00      // $00 means: load to new address
		        jsr SETLFS    // call setlfs
		        ldx #<level_address
		        ldy #>level_address
		        lda #$00      // $00 means: load to memory (not verify)
		        jsr LOAD      // call load
        		rts
		        // most likely errors:
		        // a = $05 (device not present)
		        // a = $04 (file not found)
		        // a = $1d (load error)
		        // a = $00 (break, run/stop has been pressed during loading) // not used

2018-06-14 01:37

JackAsser

Registered: Jun 2002
Posts: 1987

I know how to load and save and that they toggles interrupts etc. That is not what I’m asking for though.

2018-06-14 07:47

tlr

Registered: Sep 2003
Posts: 1702

Check the reset code here:
https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/C64..

Maybe you can go even more minimal if only load/save is needed.
The kernal touches nothing below $90 if I recall correctly. The screen editor uses quite a lot so skipping $ff5b will probably save you a bunch.

2018-06-14 10:07

enthusi

Registered: May 2004
Posts: 674

You can use vice(monitor) to trace touched areas.
memmapzap (mmzap) to reset stats
memmapshow (mmsh)
Syntax: memmapshow [<mask>] [<address_opt_range>]
(the mask is a single byte with bit flags).
This is quite helpful and would be a good start, I think.
I usually just buffer the whole ZP somewhere before using kernal routines from within a game or such.

2018-06-14 11:08

JackAsser

Registered: Jun 2002
Posts: 1987

Awesome guys, thanks!

2018-06-14 12:40

Flavioweb

Registered: Nov 2011
Posts: 442

In my experience, if we use these kernal subroutines to set/load/save:

$FFE7, $FFBD, $FFBA, $FFC0, $FFC6, $FFCF, $FFC3, $FFCC, $FFC9, $FFD2

kernal uses these zero page locations:

$90, $91, $93, $94, $95, $98, $99, $9A, $9B, $9D, $A3, $A4, $AC, $AD, $AE, $AF, $B7, $B8, $B9, $BA, $BB, $BC, $C1, $C2.

We start from the assumption that system was already setup (using some code like TLR stated above).
Irq flag is set by kernal during all the IEC transfer time, then cleared.
This mean your own IRQ code should be delayed or you may have some unwanted side effects, according to what your code does.
If vectors ram still untouched, you can simply do nothing with locations $031A-$0333 (apart init them at start). Otherwise you need to backup/restore or kernal save/load may crash at some point...
These are my 2 cents =)

2018-06-14 15:12

Oswald

Registered: Apr 2002
Posts: 5017

duh! its KERNAL, not kernel.

2018-06-14 15:15

Oswald

Registered: Apr 2002
Posts: 5017

raster irqs survive kernAl load, but they'll experience lots of SEI periods as big as half or more than a frame rarely.

just start a kernAl friendly music player raster irq which returns to basic, then you can load, and observe how the jsr call is delayed (inc/dec d020 is handy)

2018-06-14 18:55

JackAsser

Registered: Jun 2002
Posts: 1987

Quote: In my experience, if we use these kernal subroutines to set/load/save:

$FFE7, $FFBD, $FFBA, $FFC0, $FFC6, $FFCF, $FFC3, $FFCC, $FFC9, $FFD2

kernal uses these zero page locations:

$90, $91, $93, $94, $95, $98, $99, $9A, $9B, $9D, $A3, $A4, $AC, $AD, $AE, $AF, $B7, $B8, $B9, $BA, $BB, $BC, $C1, $C2.

We start from the assumption that system was already setup (using some code like TLR stated above).
Irq flag is set by kernal during all the IEC transfer time, then cleared.
This mean your own IRQ code should be delayed or you may have some unwanted side effects, according to what your code does.
If vectors ram still untouched, you can simply do nothing with locations $031A-$0333 (apart init them at start). Otherwise you need to backup/restore or kernal save/load may crash at some point...
These are my 2 cents =)

Big thanks. I’ll make ld65 keep those areas clean and try it! :)

2018-06-14 20:44

Danzig

Registered: Jun 2002
Posts: 428

@JackAsser: Don't know if its of any value for you but if you use $ee13 you can jump to $ee20 instead and use

LDA #$00
STA $A5
JSR $EE85
JSR $EEA9
BPL *-3
SEI
jsr $ee20

with moving the SEI below the BPL the routine just rips ~30 rasterlines while loading. One might call it "pretty cheap irq loader" :-D

Org (KERNAL):

.,EE13 78 SEI
.,EE14 A9 00 LDA #$00
.,EE16 85 A5 STA $A5
.,EE18 20 85 EE JSR $EE85
.,EE1B 20 A9 EE JSR $EEA9
.,EE1E 10 FB BPL $EE1B

PS: AFAIR the source of this "trick" was some issue of "64er"

... 23 posts hidden. Click here to view all posts....

Previous - 1 | 2 | 3 | 4 - Next

Refresh

Subscribe to this thread: