7800Basic - Strange contradictory results evaluating variables/arrays?

[Revontuli]

EDIT: Fixed! I was not updating the screen properly in some circumstances, and restorescreen was reverting the walls back to an earlier state. So the DrawWall sections were still being skipped, but the screen buffer still remembered the old screen.

 

Greetings!

I'm making a foray into coding for the 7800, and porting a 2600 game I have over to it. I'll just say that I'm excited by both the 7800 and 7800Basic, before moving on to asking for help on bug that's currently driving me crazy.

I'm using an array to store level data in the form of "rooms," and check adjacent rooms to see if I should place a wall or not (using the character/tile system, poke-ing at the screen data). I did a fair amount of debugging, printing variable amounts to the screen, etc. etc. but I think I got the code snippet to a place where I can summarize my problem.

In short:

Here's the code section in plain text, with some more comments:

 rem if we're on the top boundary well automatically wall off the top
 if _MazeLocY = 0 then goto __DrawTopWall

 rem otherwise we'll check the next row up

 rem reset color to normal
  P1C1=$12

 rem check array element above this one
  myTempA = _MazeLocY - 1
  myTempB =_Maze[myTempA]

 rem AND the element with our _MazeLocX (a binary value, with a "1" where the player is amidst 7 other zeros)
  myTempC = myTempB&_MazeLocX 
  
  rem I print the value, if it's 0 then we have wall, otherwise it's open.
  rem For the record, it can print something like "32" while still evaluating to "0" for the purposes of drawing the wall...
  debugprintD = converttobcd(myTempC)

  rem THESE NEXT TWO LINES CAN BOTH HAPPEN IN THE SAME LOOP!
  if myTempC > 0 then P1C1=$FF
  if myTempC = 0 then goto __DrawTopWall
  
  goto __CheckBottomWall


__DrawTopWall


  pokechar screendata 6 0 20 12 12
  pokechar screendata 7 0 20 12 12


 rem etc...

To explain a little more - My level data is 8 bytes, or an 8x8 set of 1's and 0's. I do a binary AND operation to see if the array above me has a room (i.e. see if the appropriate binary digit is a "1"), and decide to draw a wall if there isn't. Sometimes the wall appears when it should, sometimes it doesn't. It often doesn't work in very specific places - that are not boundaries (note that I check in the top line).

There are a few quirks about the bug, but to start simple, I distilled the code down to these few lines, I decided to ask for help. Plus - the code snippet is a little strange on its own, right?

The color palette change is a debug effect to see if I can have to contradictory things happen at once. This part of the code is only called once per room generation (I made a counter variable earlier to make sure), so as far as I can determine, "myTempC" is both equal to zero AND greater than zero for the purposes of drawing a wall and changing the color palette.

The thing is, the code works great -most- of the time (and has been ported from my 2600 code, which as far as I know works just fine), but there are a few times when this odd behavior occurs.

I doubt it's uninitialized memory - the places in the game where this bug occurs are reproducible, and I made some effort to make sure the variables are all set properly. While this is sort of complex array stuff, the code works on the 2600 Batari Basic, and again, seems to work 90% of the time on the 7800. I've a feeling the code would crash or behave much more erratically if this was -too- far out of line in terms or array usage.

It's either something -really- stupid on my part, or some quirk of 7800Basic and/or the 7800 in general I'm missing.

Any help would be greatly appreciated!

Edited April 18, 2019 by Revontuli

[RevEng]

Yeah, those would be mutually exclusive, for sure. The only way I'd see them both run in one pass is if you're modifying myTempC in an interrupt (ie. a topscreen routine.) or you accidentally "return" after a goto. (causing a random'ish jump)

 

If that's not the case, maybe share the generated .list file? (PM if you don't want to out the source code just yet)

 

Also, just to be 100% sure on your theory, I'd add something like this, and see if the game freezes and displays a red background.

  myTempZ=0
  if myTempC > 0 then P1C1=$FF:myTempZ=1
freezecode
  if myTempC = 0 && myTempZ=1 then BACKGRND=$38:goto freezecode

  if myTempC = 0 then goto __DrawTopWall

[Revontuli]

Fixed! An error on my part - I missed a place in the code where I should have updated the screen, so calling restorescreen (later, in the main loop) brought back the previous graphical state.