Never seen this error before

[pacgreg]

So I was working on my newest game and run out of space in bank 5, so I split it into 5 and 6, and it compiles fine, but when I try to run it, it shows a pink screen with flashing black lines down the left side. What is this, what does it mean, and how can I fix it?

 

PS. If you do fix it, please try not to spoil what the game is yet because I didn't really want to show it off until I got more of it done but this is a weird error that I don't know how to fix

Thanks

Greg

pfreadretry.bas

[RevEng]

In bank 6 you have what looks like a cut and paste error...

 

vl1
    if !vm{1} then goto skipvm1
   pfvline 22 9 10 on
   pfvline 23 9 10 on
   pfvline 24 9 10 on
   pfvline 25 9 10 on
skipvl1

...skipvm1 is a label in bank 5. Since you didn't tell bB to bankswitch, it's trying to jump to that rom location in bank6, which is causing the crash.

 

Changing to "skipvl1" fixes the crash, though it looks like you probably have some other issues to work through.

[pacgreg]

Sweet, and do you have any ideas why the colors go out every other move or so?

[pacgreg]

Game's not playing nice now, tried to fix some of those issues and now it compiles into a black screen. Does turning the same part of pf on over and over cause problems?

pfreadretry.bas

[+Gemintronic]

The only thing I noticed is that smartbranching should have had something at the end.

 

set smartbranching

 

should have been

 

set smartbranching on

 

or

 

set smartbranching off

 

Since I haven't used DPC+ I'm not much more help.

[pacgreg]

Ok so fixed smartbranching but still have black screen.

[RevEng]

You have a blank screen because you deleted the "bank 5" designation, but you have goto destinations that bankswitch there.

 

Also, this code will potentially put your game in an infinite loop.

 

cm4
   if p0x<4 then cm{4}=1 : goto cm4 

The colors and the semi-random crashing are likely because you're sending DPC+ functions values that are too big and cause it to plot outside of the screen, in other memory.

 

DPC+ doesn't protect itself from bad input due to performance considerations.

[pacgreg]

New code does not compile at line " goto draw *bank5*"

And what are the DPC+ function value's you're talking about?

pfreadretry.bas

[+Random Terrain]

New code does not compile at line " goto draw *bank5*"

 

He said in his post that you don't have a bank 5. You can't jump to a bank that doesn't exist. Take a look at this template:

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#dpc_harmony

[pacgreg]

I re-added the bank and fixed the loop he talked about, but I get a weird syntax error on the first goto that jumps to bank 5

Edit: toyed around with the bank a bit more and now it works without black screen but there's still a flicker and occasional black screens from standing in certain areas. new file attached

pfreadretry.bas

Edited February 27, 2014 by pacgreg

[RevEng]

And what are the DPC+ function value's you're talking about?

I'm talking about the pf* commands. If you call them, for example, with an X that is bigger than 31 you'll cause them to modify memory that's off-screen and used for other things.

[pacgreg]

I checked and I'm not doing that anywhere. I found the slight flicker and slowdown from adding extra drawscreens to help with both the black screens and the grayscale flashing. Now I'm closer to getting it done enough to walk around in and for some reason I get a black screen for turning too far left or right at all. Can someone look at the movement stuff in bank 2 to see if there's any crossed lines or anything I'm messing with?

pfreadretry.bas

pfreadretry.bas.bin

[pacgreg]

Found the problem: game crashes when p0d=4

Can not find solution! Can someone please do some detective work here because I followed it all the way through and see no infinite loops or anything that should stop p0d from being 4, but it crashes every time. It can be tested by changing the value in the line with p0x p0y and p0d under the dim's. Once this gets fixed I can go back to working out the perfect pfvlines for each ray.

Thanks,

Greg

pfreadretry.bas

pfreadretry.bas.bin

[pacgreg]

Nobody in that 7 sees anything? I keep looking it over and nothing comes up. Any oversized values? Nothing seems crash worthy to me.

[RevEng]

In "assign4" you have the following line which uses round brackets for bit-access instead of curly brackets, which isn't going to work.

 

if cl(1) then vl{1}=1

Fix that and the turning crash goes away.

 

You can also save tons of space in bank 3 by adding the following sub at the end of it...

 

dopfread3
   if pfread(p1x,p1y) then temp1=1 else temp1=0
   return thisbank

...and then replacing each "if pfread(p1x,p1y) then..." in bank 3 with...

 

  gosub dopfread3
  if temp1 then ...

This also has the benefit of allowing you to put in a debugging handler that will check p1x and p1y for valid values before calling pfread, skip the pfread if they're bogus and instead set score=999999. If you see 999999 show up, you'll know you've triggered the bug without dealing with an ARM emulation crash.

 

Right now the pfread values look clean after the previous bug is fixed, but it's something to keep in mind if the crashing returns after more code changes.

[pacgreg]

That's amazing. How would one accomplish the valid p1x checking because attempting the obvious way still lets the game crash when I touch the westmost wall. Interestingly enough I may not need that extra left pixel for maps seeing as how deep I tested the game will run the playfield below the screen, causing for massive potential maps.

[RevEng]

To add p1x checking for calls from bank 3, modify dopfread3 like...

 

dopfread3
   if p1x>31 then score=999999:temp1=1:return thisbank
   if pfread(p1x,p1y) then temp1=1 else temp1=0
   return thisbank

Tracking down the source of the p1x problem is another matter.

 

To find the last issue I started commenting out relevant subroutine calls at the higher levels. When I found the subroutine that caused the crash, I then re-enabled it and commented half out half of the sub. If the crash persisted I knew the problem was in that uncommented section, and if the crash went away I knew it was in commented section. Repeat and rinse to divide the problem section in half, over and over again, until you narrow it down to the line that causes the crash.

 

This technique isn't universal because commenting out half of the suspected code isn't usually an option. But for your routines that call pfread it was a workable approach.

 

You may be able to find this one using the same method.

 

[edit] Actually, if you modify the calling routines to identify themselves by setting temp2=[unique number] before the "gosub dopfread3", you could us that to figure out where the error is coming from. In that case, instead of "score=999999" in dopfread3, you could use "score=990000:score=score+temp2". Just be sure to use BCD numbers when setting temp2. (eg. temp2=$11 rather than temp2=11)