Instruction error $D8F00306 - Problem when starting level too soon

I noticed that annoying little bug a few days ago, experimented a lot, and am still lost. Description:


I put MJ's new fade-in/out routine in my hack. The routine itself works perfectly, but there seems to be a conflict somewhere.


When the routine is being used in "Level:" (the game mode routine), and if I press start to make the game start as soon as possible, the screen fades out, the game stops (music plays properly) and an error message is displayed (instruction error $D8F00306).


Here's some data I collected so far about the issue:


- it will always happen with the new routine if I press start before the title screen's palette is completely loaded


-> otherwise it won't happen if I wait a bit more before pressing start,


- it won't happen if I use the original routine instead,


-> but it will happen if I don't use any routine at all,


- it will always happen if I use the original level select,


- it won't happen if I use my new level select screen,


->and it won't happen if I harass the start button to launch the level before the palette is completely loaded on that new level select screen either.




Level: ; XREF: GameModeArray


bset #7,($FFFFF600).w ; add $80 to screen mode (for pre level sequence)


tst.w ($FFFFFFF0).w


bmi.s loc_37B6


move.b #$E1,d0


bsr.w PlaySound_Special ; fade out music


loc_37B6:


bsr.w ClearPLC


bsr.w Pal_Neutral_FadeFrom ; << this is the only place where it's causing the issue as far as I know


tst.w ($FFFFFFF0).w


bmi.w Level_ClrRam



I tried to disable many parts of the beginning of the level routine, to no avail. I also enabled/disabled interruptions in several places, but no result either.


Last but not least, I don't know how to read that error message...


Any help is welcome

 

I guess that error means it's trying to jump to an instruction outside the rom addressing area. Maybe the new fading code is leaving a value in a register that you need to clear before calculating a jump somewhere else?

 

I recall that long-word value being the address after the instruction that crashed the processor, if it's true in this case, then that address is way out of its place. Without being able to assemble and thoroughly examine this myself, I'm afraid I don't have much of an idea of what is going on.


The information about the crash is saved into the stack before running the error exception routines, I can't remember off the top of my head what info is what, but it's worth checking out.


I also recall that some people have had an issue with the palette fade control values at 00FFF626 and 00FFF627, and that setting them to 003F when fading had finished seemed to correct some crashing error they had (still haven't researched into what it was or why though, but it's worth checking out if you're fresh out of ideas).


Sorry I can't be much of a help =$

 

It does help, thank you both. It confirms it's probably an address in the form of an a+d=wrong address.


So, I found what one could call a fix, but I'm not satisfied with it at all since I don't know why it's fixing the problem.


I only have to clear d2 after the fading routine, and all runs fine again.


Now what I don't like with this is I couldn't find where d2 is being used after the fading in the level routine, so I can't actually fix the d2 really causing this where it's being used yet.


edit: changing line "andi.b #$E0,d2" to "andi.w #$E0,d2" in deccolor seems to fix it.