| | JackAsser
Registered: Jun 2002
Posts: 1995 |
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....
|
| | enthusi
Registered: May 2004
Posts: 675 |
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. |
| | JackAsser
Registered: Jun 2002
Posts: 1995 |
Awesome guys, thanks! |
| | 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 =) |
| | Oswald
Registered: Apr 2002
Posts: 5031 |
duh! its KERNAL, not kernel. |
| | Oswald
Registered: Apr 2002
Posts: 5031 |
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) |
| | JackAsser
Registered: Jun 2002
Posts: 1995 |
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! :) |
| | Danzig
Registered: Jun 2002
Posts: 430 |
@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" |
| | JackAsser
Registered: Jun 2002
Posts: 1995 |
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. |
| | Flavioweb
Registered: Nov 2011
Posts: 447 |
Quoting JackAsserI 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... |
| | Grue
Registered: Dec 2001
Posts: 153 |
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" |
| Previous - 1 | 2 | 3 | 4 - Next | |
