| |
alwyz
Registered: Dec 2011 Posts: 31 |
Kernal IO routines and Color Ram Conflicts?
Having a weird issue that's been bugging me for a few days on a game crack i'm doing so I'd figure I'd post here to see if anyone has insight.
I have a game that uses charrrom and color ram at $d000 area. To load file from disk, using standard kernal routines, I'm shutting off interrupts with usual
sei
lda #$7f
sta $dc0d
sta $dd0d
lda $dc0d
lda $dd0d
lda #$00
sta $d015
sta $d01a
sta $02a1
$01, $dd00 and $d011 is also saved to memory for restore later
load file to $1000 - $3d00 using jsr $ffba, $lda #$00 sta $9d jsr $ffd5
lda #$34
sta $01
transfer $1000 etc etc to $d000 etc etc
restore $d015, $d01a, etc etc
cli
rts
level seems fine, but looks like part of the color ram is corrupted. If I freeze into action replay cart, and load $d000 file directly to memory, then go back into the game, everything is perfectly fine.
Changing exit routine, omitting restore variables, or omitting cli, will change the way the corruption happens - the parts of the screen that are affected, but i can't eliminate it altogether.
It also loads one file after this file, so i was thinking a disk operation afterwards was affecting it.
Any ideas? |
|
| |
Compyx
Registered: Jan 2005 Posts: 631 |
Maybe it's part of the protection? |
| |
chatGPZ
Registered: Dec 2001 Posts: 11110 |
sprites left on screen while loading? |
| |
Compyx
Registered: Jan 2005 Posts: 631 |
Yeah, you might be able to avoid DMA by moving sprites to the right. No too much though. |
| |
Oswald
Registered: Apr 2002 Posts: 5017 |
there should be an inc $d019 too ? also color ram = $d800 is corrupter, or level data which is for $d800 ? |
| |
chatGPZ
Registered: Dec 2001 Posts: 11110 |
disabling the IRQ is only cosmetical and not required - kernal routines wrap critical code into sei/cli anyway. when the loading appears to work but data gets corrupted -> sprites |
| |
Oswald
Registered: Apr 2002 Posts: 5017 |
sprites seem to be turned off here, maybe a bug in the copy code. |
| |
alwyz
Registered: Dec 2011 Posts: 31 |
Ah i got it, it used some empty old loader area for a scratch pad and i didnt fill it properly with 00's. But thank you all for chiming in. It definitely helped me look at other things, and yes I had $d015 set to $00 but groepaz, that is good to know about corruption even though the load appears to be ok. That's something good to keep in mind! |
| |
JackAsser
Registered: Jun 2002 Posts: 1989 |
Quote: disabling the IRQ is only cosmetical and not required - kernal routines wrap critical code into sei/cli anyway. when the loading appears to work but data gets corrupted -> sprites
Doesn't the kernel loader supports sprite DMA to be active? Or did I miss some prerequisite here? |
| |
Krill
Registered: Apr 2002 Posts: 2839 |
Quoting JackAsserDoesn't the kernel loader supports sprite DMA to be active? Or did I miss some prerequisite here? No, sprites aren't supported natively. The KERNAL loader MAY tolerate one or two enabled sprites, but i wouldn't risk it. You can run interrupts, though (with a lot of slack), so you can mask the sprites with a raster interrupt handler. |
| |
chatGPZ
Registered: Dec 2001 Posts: 11110 |
Quote:Doesn't the kernel loader supports sprite DMA to be active?
nope, it works mostly but sometimes you get broken data. it's a common problem with cracks made by people who used speeddos - because that DID work with sprites enabled :) |
... 11 posts hidden. Click here to view all posts.... |
Previous - 1 | 2 | 3 - Next |