Jump to content


7800Basic - Strange contradictory results evaluating variables/arrays?

2 replies to this topic

#1 Revontuli OFFLINE  


    Space Invader

  • 23 posts

Posted Tue Apr 16, 2019 10:00 PM

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.


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

 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)

  if myTempC > 0 then P1C1=$FF
  if myTempC = 0 then goto __DrawTopWall
  goto __CheckBottomWall


  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 by Revontuli, Thu Apr 18, 2019 10:27 AM.

#2 RevEng OFFLINE  


    Bit Player

  • 5,193 posts
  • Location:bottom of the stack

Posted Wed Apr 17, 2019 9:20 AM

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.

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

  if myTempC = 0 then goto __DrawTopWall

#3 Revontuli OFFLINE  


    Space Invader

  • Topic Starter
  • 23 posts

Posted Thu Apr 18, 2019 10:16 AM

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.

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users