| |
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? |
|
... 11 posts hidden. Click here to view all posts.... |
| |
chatGPZ
Registered: Dec 2001 Posts: 11108 |
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: 2839 |
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: 1378 |
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: 2839 |
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: 1989 |
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: 2839 |
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). |
Previous - 1 | 2 | 3 - Next |