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

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: 1989

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)

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

2018-06-14 11:08

JackAsser

Registered: Jun 2002
Posts: 1989

Awesome guys, thanks!

2018-06-14 12:40

Flavioweb

Registered: Nov 2011
Posts: 447

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: 1989

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: 429

@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"

2018-06-14 21:05

JackAsser

Registered: Jun 2002
Posts: 1989

Quote: @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"

Thanks! I’ll keep it simple and just clear the area where the IRQ was needed though. I have a multiplexed sprite overlay which will get distorted even with the trick u mentioned. So let’s forget about IRQ and focus on Kernel memory footprint.

2018-06-14 22:27

Flavioweb

Registered: Nov 2011
Posts: 447

Quoting JackAsser

I have a multiplexed sprite overlay which will get distorted even with the trick u mentioned. So let’s forget about IRQ and focus on Kernel memory footprint.

Mmmm... if you have 8 sprites in a row on the screen, Iec transfers goes out of sync, even without any Irq code running...
Is safe turn off all sprites during save/load...

2018-06-15 06:13

Grue

Registered: Dec 2001
Posts: 146

While these tricks are nice and clever keep in mind that it will break compability with alternative kernals.

Quoting Danzig

@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"