Strange score corruption

[bjbest60]

Hello all,

 

I'm working on my next game, and I'm encountering a very strange score corruption. If the ones digit is 2, 3, 6, or 7, the tens digit will be off by one line, displaying the bottom of the next number in sequence and the top seven lines of the correct number after that. If the tens digit is any number, it won't corrupt the hundreds digit. But if the hundreds digit is 2, 3, 6, or 7, it corrupts the thousands digit. (I imagine this has something to do with how the score is broken into three separate parts?)

 

This only happens on my Harmony cart. On Stella, everything is fine. Is this somehow a Harmony bankswitching issue even if there's one bank?

 

I'm at a loss. I've attached a bare-bones version of the code I'm using. Press up to increase the score. I'm also attaching my score_graphics file; I've been working on a custom font, but in this example I'm using Retroputer and I'm still having the same issue. I don't think I've directly edited score_graphics, but maybe the problem is there?

 

Thanks for any help you can give. I'm baffled.

score_weirdness.bas.bin

score_weirdness.bas

score_graphics.asm

[+Random Terrain]

I'm sure that someone with a bigger brain will have an answer, but they'll probably want to know if you are using the latest version of batari Basic first:

 

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

[bjbest60]

Yes, everything's up to date. bB version is reveng40. Stella is 5.0.2, where, again, the score is fine. I've tried replacing the score_graphics.asm with a new copy from a fresh download and that hasn't helped, either. Harmony BIOS should be fine, as I got the cart last year.

 

To be sure, I just reinstalled bB, Visual bB, and Stella. I get the same result on the cart.

[bjbest60]

I am getting the same issue with the absolute minimum code (also attached):

 score = 134700 :  scorecolor = $08

main
 if joy0up then score = score + 1
 drawscreen
 goto main

I've chosen the weird score to show the problem. The 1 in the hundred thousands and the 4 in the thousands are corrupted.

 

I'm running this on an Atari Jr.; I have no idea if that would impact anything. It never has in the past.

score_weirdness_minimal.bas

[+stephena]

I am getting the same issue with the absolute minimum code (also attached):

 score = 134700 :  scorecolor = $08

main
 if joy0up then score = score + 1
 drawscreen
 goto main

I've chosen the weird score to show the problem. The 1 in the hundred thousands and the 4 in the thousands are corrupted.

 

I'm running this on an Atari Jr.; I have no idea if that would impact anything. It never has in the past.

 

Please create a ROM for this, so we can test further.

[bjbest60]

Here's the .bin for the minimal example. Thanks for looking into it!

score_weirdness_minimal.bin

[DirtyHairy]

I don't have time to investigate more right now, but I remember seeing precisely what you are describing in 6502.ts at some point. Stella displayed the score regularly, so I naturally assumed it was a bug in 6502.ts (it never occurred to me to check on real hardware). I investigated and tracked the issue to differences in the handling of an illegal opcode that was used by BBasic for score display. I adapted the implementation in Stella, and the problem was gone. Now I am wondering whether 6502.ts (or neither of the two) was actually correct

 

I'll investigate more later, but from my commit history, I think the issue was the behavior of carry in the implementation of ALR.

[+stephena]

I'll check on my light sixer when I get home, to determine if it's a hardware-specific issue (some Jr's do behave differently than older consoles).

 

EDIT: Neither z26, mess nor Javatari exhibit this problem. And obviously it's not happening in Stella or Stellerator either. Will be interesting to see what's causing it ...

[DirtyHairy]

I can't reproduce this on my PAL Jr. However, my memory was correct: if I change the way carry is handled in ALR, I can produce similar effects (although I get the corruption when bit 0 of a BCD is hight, while it seems you get corruption when bit 1 is high). To me, it seems that ALR is unstable or works differently on your CPU. I should add that I also checked ALR in visual6502 and, remarkably, it doesn't work there at all, so it might really be a fragile opcode.

Edited December 13, 2017 by DirtyHairy

[DirtyHairy]

I can reproduce exactly the same pattern of corruption if I set carry from bit 1 of A before doing the AND-and-shift (the unmodified code sets carry from bit 0 after the AND):

function opAlr(state: CpuInterface.State, bus: BusInterface, operand: number): void {
    const i = state.a;
    state.a = (state.a & operand) >>> 1;

    state.flags =
        (state.flags & ~(CpuInterface.Flags.n | CpuInterface.Flags.z | CpuInterface.Flags.c)) |
        (state.a & 0x80) |
        (state.a ? 0 : CpuInterface.Flags.z) |
        ((i & 2) >>> 1);
}

This is what I get for the minimal testcase:

 

I think this proves that, at least on your CPU, ALR behaves differently. It would be interesting to get more data on how this test case behaves on different consoles, maybe the problem is more widespread.

Edited December 13, 2017 by DirtyHairy

[+stephena]

Not that we need to worry about this for 5.1, but I wonder how we could handle this going forward? Perhaps have different variations of the 6507 emulation??

 

I just checked on my light sixer, and it's working fine there too.

[+stephena]

The documentation I've read seems to imply that ALR is an illegal opcode, but not an unstable one. But I guess after reworking the TIA, we know how much documentation can differ from reality.

[DirtyHairy]

Not that we need to worry about this for 5.1, but I wonder how we could handle this going forward? Perhaps have different variations of the 6507 emulation??

 

I just checked on my light sixer, and it's working fine there too.

 

I'd be interested in how widespread this issue is before taking any action at all. Maybe it is just a glitch in this individual CPU, who knows.

 

The documentation I've read seems to imply that ALR is an illegal opcode, but not an unstable one. But I guess after reworking the TIA, we know how much documentation can differ from reality.

 

 

Exactly my reasoning.

[bjbest60]

I can reproduce exactly the same pattern of corruption if I set carry from bit 1 of A before doing the AND-and-shift (the unmodified code sets carry from bit 0 after the AND):

 

This is what I get for the minimal testcase:

Bildschirmfoto 2017-12-13 um 22.34.20.png

 

Yes, that's exactly the corruption I'm seeing.

 

Thanks for the info so far. I've got two other systems at home and will check on them as well. The Jr. has been a little finicky for me in general, so who knows what's going on under the hood. I'll report back once I can test the others.

[bjbest60]

So, it turns out the issue occurs only with my Jr. Both my light sixer and Vader have no problems. Thanks so much for talking through this; I'm glad to know I wasn't completely off-target, and of course I'm glad that I can get back to developing.

 

The Jr. has been finicky, but has never shown any obvious malfunctions before. So I don't know if it is indicative of any larger problem or if it's just the unit itself (which came in a dusty box from a garage sale). But if it's of any use, the serial number is A1 79 1401095.

 

Thanks again!