| |
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: 11101 |
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: 11101 |
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: 1987 |
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: 2827 |
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: 11101 |
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 :) |
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
Quote: 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 :)
Fascinating! Was this ever mentioned in the reference manuals? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11101 |
i dont remember it being mentioned anywhere at least |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Quote: 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.
I had back in the days playing music with inc/dec d020 player, and loading directories. the kernal load delayed the raster irq like 8-10 chars max and on average about half of that, but take that with a pinch of salt :) |
| |
S.E.S.
Registered: Apr 2010
Posts: 19 |
This is really interesting, I hadn't heard about that before. Can anyone shed some light onto why the standard kernal routines can't cope with several sprites but on the other hand work correctly with badlines? |
| |
Krill
Registered: Apr 2002
Posts: 2827 |
I believe it's a tipping point thing.
The 1540 designed to go with VIC-20 was infamously too fast for the C-64 to keep up due to VIC badlines.
Thus, 1541 was invented, which added a few waitstates to the serial protocol.
Now, enable a few sprites and it all becomes pretty fragile again, as sprite DMA is added to regular badline DMA. =) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1370 |
Clearly the solution is to put all your sprites in the upper and lower borders :D |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Quote: I believe it's a tipping point thing.
The 1540 designed to go with VIC-20 was infamously too fast for the C-64 to keep up due to VIC badlines.
Thus, 1541 was invented, which added a few waitstates to the serial protocol.
Now, enable a few sprites and it all becomes pretty fragile again, as sprite DMA is added to regular badline DMA. =)
too fast? Badlines broke the timing simple as that VIC20 didnt have it. also the CIA which should have shifted the bytes bit by bit itself to the serial bus was broken. Tramiel gave 2 days for the guy to make loading happen, so we got this :) |
| |
Krill
Registered: Apr 2002
Posts: 2827 |
Quoting Oswaldtoo fast? Badlines broke the timing simple as that VIC20 didnt have it. also the CIA which should have shifted the bytes bit by bit itself to the serial bus was broken. Tramiel gave 2 days for the guy to make loading happen, so we got this :) Yes, "too fast" with regard to serial protocol timings. C-64 side badlines introduce delays the protocol as implemented by the drive simply doesn't tolerate.
And it is the drive's VIA that has broken hardware shifting, not the C-64's CIA. Interestingly, CMD apparently worked around that years later and made do without CIAs, using VIAs in the FD drives for burst transfers. =) |
| |
Perplex
Registered: Feb 2009
Posts: 254 |
Quoting ChristopherJamClearly the solution is to put all your sprites in the upper and lower borders :D
Or turn off badlines and use sprites only. ;) |
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
Quote: Quoting ChristopherJamClearly the solution is to put all your sprites in the upper and lower borders :D
Or turn off badlines and use sprites only. ;)
Not when IRQs are postponed 40 rasterlines randomly. ;) though a quicky NMI routine might just do it, as long as it doesn’t block longer than a normal badline. |
| |
Krill
Registered: Apr 2002
Posts: 2827 |
Quoting JackAsserNot when IRQs are postponed 40 rasterlines randomly. ;) though a quicky NMI routine might just do it, as long as it doesn’t block longer than a normal badline. I got that down to about... 16-ish lines or so with strategic reimplementation of some KERNAL calls. (And without violating the protocol.) :)
And you can always mask sprites with an interrupt handler block (while observing the slack). |
