I have no idea what could be causing this as an issue.
I've gone back to futz with my nametable loading routine just a bit. Everything is working as I'd expect; essentially, I'm making a few case scenarios where of a flag is set, load this, if not, load that sort of thing. Standard.
Got the case done in one instance. Works fine. Got the case done in another, works fine. Got the case done for the third...screen never loads. The screen stays off, as if it's getting caught in some sort of loop and never finishes the subroutine.
So debugging this, here's what I tried:
- pulled third case out completely as a control. It worked fine.
- Put it back in, began altering the case result to see if I could get things to happen. Never loaded.
- Wrote the case line by line, starting with LDA temp...even just with that, never loaded.
- Took out LDA temp again, worked fine.
- Went to a different piece of this subroutine where it wouldn't conflict and added LDA temp...never loaded.
- Went to the end of the subroutine before the RTS and added LDA temp...never loaded.
- Tried LDA temp2 at the end of the subroutine...never loaded.
- Tried STA $07ff at end of subroutine...never loaded
My conclusion is that this subroutine is causing *too many things* to happen (using too many cycles?). But...this is all happening when the screen is turned off, so...I'm not entirely sure why this wouldn't just carry over into the next frame?
Anyone have anything like this happen? Any proposed solutions?
Thanks!
As a stab in the dark: you may be trashing the contents of the stack page.
Try walking through what's happening in a debugging emulator like FCEUX or Nintendulator.
Thanks - I thought about the stack, but I'm not touching it in those instances...literally, if I have LDA temp followed by LDA temp it crashes. Temp isn't using that variable space, it's on the zero page. Checking in FCEUX, nothing is showing up in the stack register. Now, it is completely possible that there is something I'm not comprehending about the functioning of the stack, but I think I have it pretty much under control, and I know nothing is writing to that area, being pushed or pulled from it, and I'm not sure how, say, putting a STA temp2 into the subroutine arbitrarily would affect it in any way. If there's something I need to know on that front, definitely let me know!
**EDIT**
we'll call it a gremlin. I saved an iteration, deleted the code causing the issue and rewrote from scratch. No issues. That's scary....but it seems to be fixed.
Probably you made a tiny, hard to see error, like omitting a # for a LDA immediate.
But, do get to know the debuggers better. Depending on assembler...you can output a label file, which can give you the address to set a breakpoint.
Using ASM6 with FCEUX. Generally, I'll do a write to, say, $07ff of where I think the problem value my be, and then in debugger check writes to that address. This method, and just using JMP RESET to see if portions of code are being reached, has managed to get me pretty far. This one still stumps me, but it's working. Tested 102 times (literally, exactly 102), with no more glitch, so we'll call it fixed even though consciously I didn't determine where the issue was. haha
Quick flyby as I've a dental appointment but wanted to ask: was NMI (VBlank) happening between the lda temp, lda temp statements? I can't see how two LDAs like that would cause any kind of problem, but I can definitely see how something like lda temp, sta temp with NMI happening between the LDA/STA could cause some issues, depending on what your NMI routine does, or cases where, say, carry/negative/zero flags are cared about between instructions (e.g. lda temp, bne somelabel). (Your project is so far along now that I doubt this is the case, but make sure A/X/Y/P are being backed up/restored at the start/end of NMI routine).
I hate code gremlins. Nothing irritates me more than a bug that crops up that I manage to "hack a workaround for" without even understanding what the actual bug was. It always makes me wary of the stability of the program afterward; "there's this thing lurking in the code that COULD happen again, because I don't know what the root cause was..." Hate that feeling.
Thanks for checking in Koitsu - yeah, everything is definitely pushed and pulled for the NMI. And every time I *think* I worked this issue out, it manifests again. This has not been an issue at all to this point, and it manifests at the strangest places. Whenever it does manifest, it seems that when I add commands to the file, anywhere in the file, any command, it occurs. This is what made me think it might be a cycle issue, but in every case, it is tripping when the screen is off, and just never turning back on.
Ugh. Anyhow, thanks for the thoughts. Anyone else ever see something like this?
**ALTHOUGH - that does give me a thought. What if I AM taking too many cycles in the NMI, depending on what is happening at that current moment in the game, and so the restores are never occurring? That might trip this problem....interesting.
What I'd do is execute the program with logging turned on in an emulator (FCEUX or Nintendulator). Then examine the log looking for any oddities. It might take you a while to go through the log, but it could end up saving you time in the end.
JoeGtake2 wrote:
**ALTHOUGH - that does give me a thought. What if I AM taking too many cycles in the NMI, depending on what is happening at that current moment in the game, and so the restores are never occurring? That might trip this problem....interesting.
The effects there would be bad -- the PPU would start accessing PPU RAM etc. and drawing to the screen while the code in the NMI was still going. The results in that case are most commonly screen corruption, but it depends on what the code in NMI is actively doing at the time.
rainwarrior described a methodology he uses determine how much time a section of code (or routine) takes using the colour intensity bits of $2001 (bits 7, 6, and 5). I've used similar techniques on the Apple IIGS. This would be for code *outside* of NMI, since you'd want to tweak the intensity bits while the screen was being drawn (specifically in HBlank, I'd imagine). He describes it here:
https://www.kickstarter.com/projects/11 ... ts/1040806For code within NMI, there have been a couple threads here on the forum about it, but the one I remember is this one -- it's one area where emulators become super handy:
viewtopic.php?t=7878