Anomaly in Conquest of Mars?

[Zach]

I'm often unable to shoot the center object:

 

http://www.youtube.com/watch?v=PV4ZHCGnGWk

 

ROM is the one from the AA database. It works fine in Stella. My CoM cartridge from the AA store also works well, although I'm unable to know if it has the same ROM.

 

How does CoM work on other people's Harmony Carts?

Edited May 30, 2011 by Zach

[Thomas Jentzsch]

I cannot see any reason why Harmony would behave different here...

 

...except for a bug in the game itself.

Edited May 30, 2011 by Thomas Jentzsch

[+batari]

Did some investigating, and it's a bug in the game. The game has an odd way of checking collisions - it reads a collision register (CXP0FB) and stores it, and although we shouldn't rely on the states of bits 0-5, the game does, and in exceedingly strange ways. The anomaly should only be present on pre-production Harmony carts, but it's not a problem with Harmony, really. The reliance on these lower bits means it won't work on some systems and some regular EPROM carts as well.

Edited May 30, 2011 by batari

[Zach]

Thanks for investigating.

 

Oh well. Can't blame the programmer for missing a bug that wouldn't have shown up during testing.

Edited May 30, 2011 by Zach

[maiki]

So what's the difference between using Stella and Harmony cartridge? I thought one could rely on Stella when testing stuff for the Harmony...

[Thomas Jentzsch]

So what's the difference between using Stella and Harmony cartridge? I thought one could rely on Stella when testing stuff for the Harmony...

Some registers and ZP RAM might be different.

 

Usually that doesn't make any difference, since each game is supposed to initialize all those areas, because they are undefined by definition at start up. However, often they turn out to have a certain value at startup (usually 0), so if a programmers forgets to initialize them correctly, the code still might work 99%.

 

But since Harmony changes these areas for its menu and loading screen, there is a good chance that the bug becomes obvious.

[+johnnywc]

Did some investigating, and it's a bug in the game. The game has an odd way of checking collisions - it reads a collision register (CXP0FB) and stores it, and although we shouldn't rely on the states of bits 0-5, the game does, and in exceedingly strange ways. The anomaly should only be present on pre-production Harmony carts, but it's not a problem with Harmony, really. The reliance on these lower bits means it won't work on some systems and some regular EPROM carts as well.

 

 

Hi -

 

Thanks for pointing this out...the collision detection has always been a bit flaky and I could never figure out why. This was the first Atari game I programmed so I know for a fact I didn't completely understand how to use the collision latches. I do recall that I had to save the collision bit because the bottom display would mess with the collision register and I was checking collisions at the end of the frame.

 

I haven't looked at this code in over 5 years but I'll take a look tonight and see if I can figure out what the issue is.

 

Thanks again!

John

[+batari]

So what's the difference between using Stella and Harmony cartridge? I thought one could rely on Stella when testing stuff for the Harmony...

Some registers and ZP RAM might be different.

 

Usually that doesn't make any difference, since each game is supposed to initialize all those areas, because they are undefined by definition at start up. However, often they turn out to have a certain value at startup (usually 0), so if a programmers forgets to initialize them correctly, the code still might work 99%.

 

But since Harmony changes these areas for its menu and loading screen, there is a good chance that the bug becomes obvious.

This is true, however, this is not the reason for CoM's bug. The bug in this case is because preproduction Harmony carts will always read a 1 for bit 3 on TIA read registers that don't drive this bit. For example, a read to CXP0FB will usually return $02 when no collision is detected, but relying on a value of $02 is not a good idea because some hardware will not work this way as only bits 6 and 7 are actually connected to the TIA, and bits 0-5 could really contain anything. Preproduction Harmony carts will instead return $0A.

 

It's a common issue that most developers run into (usually it happens when a programmer forgets the # on an immediate load.) A while back I discussed the issue with Stella developer Stephen Anthony, and he added a command-line switch to drive some of these bits (which should highlight these bugs.) From Stella docs:

-tiadriven <1|0>

Set unused TIA pins to be randomly driven high or low on a read/peek. If disabled, use the last databus value for those pins instead.

Edited June 2, 2011 by batari