Game runs incorrectly on 6 switch

[gauauu]

Al just let me know that my game Anguna doesn't work quite right on a couple of sixers that he tried it on, although it works properly in Stella and on other devices (Jr, 4-switch, 7800, etc). Does anyone know of any differences in the sixers that could cause it to run differently there? (the main character doesn't animate on the six-switch version -- he just moves around without changing frames).

 

Attached is the latest build of the game, which works fine everywhere I've tested (except for sixers), in case that helps. (The full source code is here, although i wouldn't expect anyone to randomly dig through the entire source code to help me).

 

My current plan is to work on trying to pare down and get a most minimal version that can reproduce the problem, although it will be slow going, as I don't have a sixer to test on myself. Maybe I need to go find one....until then, if anyone knows what might cause differences, let me know! (Or if there's any way to get stella to act like a sixer instead of a 4-switch!)

 

Thanks!

anguna.bin

[alex_79]

If you turn on the "Drive unused TIA pins randomly on a read/peek" in the TIA tab of the Stella debugger (alternatively, you can do that from the command line with the "tiadriven 1" option), you'll see the same behaviour in Stella.
This most probably indicates a zero page access instead of immediate (or the fact that you're relying on the value of bits 0-5 when reading a TIA read-only register).
When the resulting address is a write-only TIA register, the resulting value is most of the time the same as the intended one (see here for a good explanation), so that's a bug difficult to track down, and therefore many games, both commercial and homebrews, have it.

Check for missing "#" symbol in front of constants.
And ALWAYS set that option in Stella when developing or testing someone else's code, as it makes that bug evident and allows you to correct it before you put a game for sale.

Edited May 1, 2017 by alex_79

[Thomas Jentzsch]

And ALWAYS set that option in Stella when developing or testing someone else's code, as it makes that bug evident and allows you to correct it before you put a game for sale.

Yup, I that would have been my first option too.

[+Propane13]

This thread has me wondering something. In 7800-land, I had worked a game that is pretty much on hold due to freezes that would happen on actual hardware, but not during emulation.

 

For the breakages listed in this thread, are they immediate (i.e. game won't power up), or is it during gameplay?

i.e. how long does it take such issues to manifest? Immediate/seconds/minutes?

Just trying to think if I may have a similar cause.

 

Thanks

-John

[Thomas Jentzsch]

If you made a similar mistake, the chances of a read failing are quite high per read. So if your code is executed frequently, it should be a matter of a few frames only.

[gauauu]

Awesome, thanks guys. I'll check out that setting, and dig around to find where I'm missing a # or something similar.

[Mr SQL]

This thread has me wondering something. In 7800-land, I had worked a game that is pretty much on hold due to freezes that would happen on actual hardware, but not during emulation.

 

For the breakages listed in this thread, are they immediate (i.e. game won't power up), or is it during gameplay?

i.e. how long does it take such issues to manifest? Immediate/seconds/minutes?

Just trying to think if I may have a similar cause.

 

Thanks

-John

 

It can take 20 minutes, an hour or even 20 hours for the breaks to showup depending upon what location you used:

 

http://atariage.com/forums/topic/259166-flashback-portable-needed-controller-hacks/?p=3732322

 

The location I had used above (decimal 24) changed value when paddles were plugged in (or sega pad) to break the game immediately or by itself over a long duration.

[gauauu]

Oops.

            lda ANIMATION_TIME          ;reset the frame counter
            sta PlayerSpriteAnimCtr

Thanks for pointing me in the right direction.

[Thomas Jentzsch]

Good you found the problem!

 

One more suggestion:

 

Inside your macros, you don't precede the parameter with a # and instead use the # for the parameter provided. E.g.:

  MAC SetFlag
    lda MiscFlags
    ora {1}
    sta MiscFlags
  ENDM
  ...
  SetFlag #MISC_FLAGS_ITEM_GOTTEN

Unless you plan to use variables as parameters, I would use the # inside the macro ( ora #{1} ). That reduces the chance of errors.

 

BTW: The code doesn't compile for me. (player.asm is missing and some constant definitions like BG_REFLECT)

Edited May 2, 2017 by Thomas Jentzsch

[RevEng]

If you made a similar mistake, the chances of a read failing are quite high per read. So if your code is executed frequently, it should be a matter of a few frames only.

I believe this floating read type bug is only that plain on certain consoles. I made a similar mistake in the 21 Blue core, and it was only found late in the testing cycle, despite being quite obvious when actually triggered - it messed up the score on a tester's system, when it showed up. I couldn't replicate the result on any of my consoles.

 

Haunted House also has the same sort of bug in it's player positioning routine. At $F44F the game is subtracting using the value in $0f, instead of subtracting using #$0f. On most consoles HH works just fine, since they'll return the last value on the bus for a floating read. (The last opcode byte) If you run HH in stella with "-tiadriven 1", you'll see the player's character randomly move all over the place.

[gauauu]

Inside your macros, you don't precede the parameter with a # and instead use the # for the parameter provided. E.g.:

  MAC SetFlag
    lda MiscFlags
    ora {1}
    sta MiscFlags
  ENDM
  ...
  SetFlag #MISC_FLAGS_ITEM_GOTTEN

Unless you plan to use variables as parameters, I would use the # inside the macro ( ora #{1} ). That reduces the chance of errors.

 

Yeah, this bit me in a couple places as well. When writing it, I debated both ways, but eventually decided that consistency from the calling end was more important. But after finding a few bugs of this sort, I'm in agreement with you (For next time! (although next time I think I'll switch to cc65 instead of dasm))

 

 

BTW: The code doesn't compile for me. (player.asm is missing and some constant definitions like BG_REFLECT)

player.asm no longer exists (I forgot to take out the include for it, although I have dasm set to just throw a warning. Thanks for the reminder to clean that up).

 

BG_REFLECT is in the vcs.h that's in the repository (I added register-specific constants to the bottom of my vcs.h) Maybe you're including a different version of vcs.h that you had from somewhere else?

[Thomas Jentzsch]

Yea, that solved the problem.

 

BTW: Can you test more games/demos on those critical sixers? I know quite some games and demos which react with problems with the option enabled in Stella.

 

E.g. Air Raid, Alien, Centipede, Codebreaker, Fatal Run... Gehirn and TomJones demos...

[gauauu]

 

 

BTW: Can you test more games/demos on those critical sixers? I know quite some games and demos which react with problems with the option enabled in Stella.

 

 

 

I can't -- these were systems that Al had, he was testing it. Changing that setting in Stella helped me find and debug the issue (and interestingly, showed other issues that I guess didn't even appear in the sixers, but were still worth fixing), but I was depending on Al to verify that they worked.

 

That said, I think the problem appeared on every sixer he tested on, not on one or two special machines. (I only had tried it on a Jr and 4-switch, I don't have access to a sixer)

[TheHoboInYourRoom]

E.g. Air Raid, Alien, Centipede, Codebreaker, Fatal Run... Gehirn and TomJones demos...

Liquid Candy misbehaves too.

[Thomas Jentzsch]

Warlords and Stargunner too.

[DirtyHairy]

Add Edtris to the list.

 

Unrelated, but as it was mentioned: Liquid Candy also is missing a CLD during initialization