Oi vey. Can you figure this one out?

[Fort Apocalypse]

Can anyone see why the screen is going black after game is started? Also, I'm ready to jump into ASM land if it helps me debug this stuff myself. If you can light a candle for the darkness about how you would go about figuring this out step by step it would really be helpful to me and probably a lot of other bB programmers.

 

Also I have noticed that the multisprite kernel is not very forgiving when it comes to compilation. A lot of times you have no idea there is an invalid param name or similar, like when I named a param pfroom instead of proom in a conditional - it didn't say anything during compilation indicating that it was a bad var name. Would be nice if that could be a little better in the next bB version if that is possible.

 

Finally I know I've started up a number of threads on this already, but there is something wierd about playfield collisions both in standard kernel (as I noticed when rewriting sprites in Ultimate Indy 500 that basically made me frustrated enough to quit it for a while) and in the multisprite kernel (in the 2 player Adventure game I'm working on below). It would be really nice if someone at some point could take a look at those also and if those are bB bugs to maybe fix those in a future release also (odds are it is something I'm doing wrong, but I can't see what it could be so I'm leaning toward bB bug for both of those).

 

TIA!!!

 

2padv0.3.bas2padv0.3.bas.bin

Edited October 10, 2007 by Fort Apocalypse

[Robert M]

Can anyone see why the screen is going black after game is started? Also, I'm ready to jump into ASM land if it helps me debug this stuff myself. If you can light a candle for the darkness about how you would go about figuring this out step by step it would really be helpful to me and probably a lot of other bB programmers.

 

Also I have noticed that the multisprite kernel is not very forgiving when it comes to compilation. A lot of times you have no idea there is an invalid param name or similar, like when I named a param pfroom instead of proom in a conditional - it didn't say anything during compilation indicating that it was a bad var name. Would be nice if that could be a little better in the next bB version if that is possible.

 

Finally I know I've started up a number of threads on this already, but there is something wierd about playfield collisions both in standard kernel (as I noticed when rewriting sprites in Ultimate Indy 500 that basically made me frustrated enough to quit it for a while) and in the multisprite kernel (in the 2 player Adventure game I'm working on below). It would be really nice if someone at some point could take a look at those also and if those are bB bugs to maybe fix those in a future release also (odds are it is something I'm doing wrong, but I can't see what it could be so I'm leaning toward bB bug for both of those).

 

TIA!!!

 

2padv0.3.bas2padv0.3.bas.bin

 

As for the blank screen. It looks like you have a return without a gosub. I say this because in Stella after the screen goes black I put it into debug mode and the SP is set to 01. It should be FE, or FC or FA to be at the top of RAM. With a value of 01 it means you underflowed the stack and it is now pointing at the TIA chip registers.

 

The lack of warnings for the multisprite kernel is a bug that Btari knows about and is trying to fix for the next release. What you usually get when that happens is a black buzzing screen in Stella. Hit the ~ key to enter debug mode and scroll down through the assembly code until you hit only BRK instructions. At the point where the assembly code becomes all BRK instructions you need to look at the last few good instructions and map them to your code. They will look like this:

 

 

LDA $AA

STA $BB

 

which in your code will look like:

 

foo = fee ;

 

To know which label in your code corresponds to $AA you need a memory map. Use the attached memory map to map the LDA and STA addresses to a label. If you used a dim statement to change the name of a memory location you must convert it yourself. Then search your code for a matching expression using the labels you decoded. The bad label should appear just after.

 

I hope this helps.

 

bBasicMemoryMap.txt

Edited October 10, 2007 by Robert M

[Fort Apocalypse]

Rob,

 

Thanks!!! That is awesome info!

[Fort Apocalypse]

Actually I think maybe I'm going over the gosub limit. Batari said on Random Terrain's page that only 6 bytes are there for the gosub stack.

 

Update:

 

Robert was right. If anyone ever gets a black screen during the game and can't figure it out, look for somewhere in the code where you are doing something like:

 

if gamebits{0} then gosub handlep1 else chkexitp0

 

instead of

 

if gamebits{0} then gosub handlep1 else gosub chkexitp0

 

(it was missing a gosub, so when it did a goto to that tag, it would return once more than necessary)

Edited October 13, 2007 by Fort Apocalypse

[Robert M]

Actually I think maybe I'm going over the gosub limit. Batari said on Random Terrain's page that only 6 bytes are there for the gosub stack.

 

 

Yes, That six bytes means you can nest gosubs three levels deep without overflowing the stack. The stack fills memory downwards from address $FF, so if you nest gosub too many times you start to overwrite the program variables. As you pop return addresses from the stack the stack pointer moves up towards $FF. If you execute return with SP=$FF the SP will wrap around memory to fetch the contents of addresses $00 and $01 and try to use them as the return address which causes a crash.

 

If you have a variable byte let unused ( try to pick one lower in memory like A or B), you can add the following test to try and determine if you are overflowing or underflowing the stack:

 

Initialize the free variable to 0

Just before every gosub increment the variable.

Just before every return decrement the variable.

If the program crashes, look at the variable in the Stella debugger and see if it is > 0, but less than 128 which means gosub is missing a return. If the value very large like 255 or 254 ($FF or $FE) then you have executed a return without a gosub.

If the variable is zero, then the problem may be something completely unrelated to gosub and return.

Of course the problem is the test will fail if the program goes completely crazy and corrupts all of the RAM including the test variable.

[Fort Apocalypse]

Thanks, Robert! This is really good info!