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 > 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)
 
... 23 posts hidden. Click here to view all posts....
 
2018-06-15 06:13
Grue

Registered: Dec 2001
Posts: 145
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"
2018-06-15 07:23
JackAsser

Registered: Jun 2002
Posts: 1987
Yeah, I keep it simple and blank the screen. Speaking of alternative Kernels... what about their memory footprint while loading/saving?
2018-06-15 08:49
Flavioweb

Registered: Nov 2011
Posts: 442
To avoid problems with the pletora of alternative fl, you can just backup/reset/restore the vectors.
But should be interesting to investigate this...
2018-06-15 14:48
JackAsser

Registered: Jun 2002
Posts: 1987
Quote: To avoid problems with the pletora of alternative fl, you can just backup/reset/restore the vectors.
But should be interesting to investigate this...


The vectors are one thing, but I would imagine an alternative kernel to perhaps reserve a 256 byte sector buffer for speed etc no? Or are they all "compatible" to each other? Or is it simply assumed that ZP and $200-$3ff is a no-go for own code when it comes to kernel compatibility?
2018-06-15 15:29
cadaver

Registered: Feb 2002
Posts: 1153
I go by the assumption that any alternative kernal will not use at least more memory or more ZP locations, may come to yet bite my ass :)

Outside ZP starting your own memory use from $0334 should be OK, no need to avoid $0334-$03ff range unless you use tape IO.
2018-06-15 18:26
ChristopherJam

Registered: Aug 2004
Posts: 1370
Quoting Oswald
kernAl

And Betty when you call me you can calllll, meeeee, Al :)
2018-06-19 11:54
Martin Piper

Registered: Nov 2007
Posts: 631
Code used for Berzerk Redux. I used the disk drive for hiscore storage with an optional custom load/save: https://github.com/martinpiper/C64Public/blob/master/BerzerkRed..

Citadel2 cartridge code, works with kernal replacement and CBM80 boot carts (EF and GMod2). Also tests cart banking: https://github.com/martinpiper/C64Public/blob/master/Citadel2/C..
2018-06-19 11:55
JackAsser

Registered: Jun 2002
Posts: 1987
Quote: Code used for Berzerk Redux. I used the disk drive for hiscore storage with an optional custom load/save: https://github.com/martinpiper/C64Public/blob/master/BerzerkRed..

Citadel2 cartridge code, works with kernal replacement and CBM80 boot carts (EF and GMod2). Also tests cart banking: https://github.com/martinpiper/C64Public/blob/master/Citadel2/C..


Awesome Martin! Thanks!
2020-04-05 18:31
Rastah Bar

Registered: Oct 2012
Posts: 336
I saved a file with this routine from codebase:
https://codebase64.org/doku.php?id=base:saving_a_file
That works fine.

But when I want to load it again via
https://codebase64.org/doku.php?id=base:loading_a_file
it never returns from JSR $FFD5. It gets stuck in some loop at $EE30.

I'm not using any ZP adresses above $8f. But I did disable timer interrupts earlier:
lda #$7f
sta $dc0d    
sta $dd0d
lda $dc0d
lda $dd0d

Enabling them before calling the load routine doesn't seem to help. I also disabled raster IRQs before calling the routine:
sei
lda #0
sta $d01a
inc $d019
lda #$37
sta $01   ;I used $fffe and $ffff, so this should be fine

The call to the load routine is done from main.
Does anybody have an idea why the load routine doesn't return and/or suggestions what I could try?
2020-04-05 18:36
chatGPZ

Registered: Dec 2001
Posts: 11089
i'd try calling the IORESET (or whatever its called) kernal call before, if that does the trick strip it down :)
Previous - 1 | 2 | 3 | 4 | 5 - 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
kbs/Pht/Lxt
JCH/Vibrants
theK/ATL
MCM/ONSLAUGHT
Freeze/Blazon
Guests online: 178
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 No Bounds  (9.6)
7 Uncensored  (9.6)
8 Wonderland XIV  (9.6)
9 The Ghost  (9.6)
10 Bromance  (9.6)
Top onefile Demos
1 It's More Fun to Com..  (9.9)
2 Party Elk 2  (9.7)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.5)
5 Rainbow Connection  (9.5)
6 TRSAC, Gabber & Pebe..  (9.5)
7 Onscreen 5k  (9.5)
8 Dawnfall V1.1  (9.5)
9 Quadrants  (9.5)
10 Daah, Those Acid Pil..  (9.5)
Top Groups
1 Oxyron  (9.3)
2 Nostalgia  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top NTSC-Fixers
1 Pudwerx  (10)
2 Booze  (9.7)
3 Stormbringer  (9.7)
4 Fungus  (9.6)
5 Grim Reaper  (9.3)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.052 sec.