Differences hardware vs emulation

[+nanochess]

Hi everybody.

 

Just I've uploaded a new version of Space Raid with stable scanline count.

 

http://atariage.com/forums/topic/217250-space-raid-2600/page-5?do=findComment&comment=2863278

 

But I discovered something strange although small and probably non worthwhile.

 

In the title screen I've a small delay while it ignores button, well, when this small delay is running (half second,) the bottom line with my name is displaced vertically by one line downwards.

 

It only happens with real hardware in Coleco Expansion Module #1 (I couldn't test with a real Atari, because my prototype board doesn't fit because of wires)

 

Both Stella and Z26 doesn't show this weird behavior and I've counted cycles a lot of times and I cannot find the cause

Edited November 9, 2013 by nanochess

[Omegamatrix]

I would suggest building yourself a test rom that alternates background colors on each scanline so that you could count the lines on the screen. I would also not expect 100% compatibility on a clone. I have a Gemini and it is horrible on a lot of games.

 

 

I went to try your game to see the problem, but I'm not sure which rom to try as there are both 8k and 4k in the zip file. I also wouldn't be able to tell if the line is lower or not without a reference, like alternating two or more background colors.

 

 

Sometimes the scanline problems are very hard to find. In other cases it something simple like VDELxx being on when you thought it was off. Recently I came across this, where the emulation was not right:

 

http://atariage.com/forums/topic/218205-a-couple-of-games-with-display-gfx-issues-on-real-2600-jr-pal/?p=2859559

[+nanochess]

I would suggest building yourself a test rom that alternates background colors on each scanline so that you could count the lines on the screen. I would also not expect 100% compatibility on a clone. I have a Gemini and it is horrible on a lot of games.

I suppose that at the end I will need a Harmony cart to test in my Atari 2600.

 

I went to try your game to see the problem, but I'm not sure which rom to try as there are both 8k and 4k in the zip file. I also wouldn't be able to tell if the line is lower or not without a reference, like alternating two or more background colors.

The 8K version. Good idea the alternating colors.

 

Sometimes the scanline problems are very hard to find. In other cases it something simple like VDELxx being on when you thought it was off. Recently I came across this, where the emulation was not right:

 

http://atariage.com/forums/topic/218205-a-couple-of-games-with-display-gfx-issues-on-real-2600-jr-pal/?p=2859559

Interesting info! I'll give a try.

Edited November 9, 2013 by nanochess

[Omegamatrix]

One thing you might consider for your game is how you handle reset. Older Atari games will often roll and produce screeching sounds when reset is being used.

 

My preference for handling the reset switch is to take action only at its release. So you save the state of the reset bit, and compare it each frame. Once it transitions from 0 to 1 then you know the reset switch has been released. I typically look at the reset switch at the beginning of overscan, after the timer for overscan has been set. This way you get no screen bounces at reset, no screeching sounds, etc...

 

I banged out some code to explain what I am talking about. I'm using 2 clear loops as it is only 9 bytes by itself. I haven't actually tested the code below, but it's very similar to what I usually do.

.

.

Start:
    cld
    ldx    #0
    txa
.loopClear:
    dex
    txs
    pha
    bne    .loopClear
    lsr    SWCHB
    ror    flags                    ; bit 7 is used for reset switch

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
    
MainLoop:
    lda    #$0E
.loopVsync:
    sta    WSYNC
;---------------------------------------
    sta    VSYNC
    lsr
    bne    .loopVsync

    lda    #TIME_VBLANK
    sta    TIM64T
    
    
    
;.... bunch of code, Vblank, Kernel, etc...
    
    
    sta   WSYNC
;---------------------------------------
    lda    #2
    sta    VBLANK                   ; start of overscan
    lda    #TIME_OVERSCAN
    sta    TIM64T
    
    lsr    SWCHB
    bcs    .resetNotBeingHeld
    asl    flags
    lsr    flags                    ; clear bit 7
    bpl    .continueOverscan
    
.resetNotBeingHeld
    bit    flags                    ; Was reset held last frame?
    bmi    .continueOverscan        ; - No reset not being held, and bit 7 of "flags" is already set...
                                    ; - Yes, reset switch is released now. Do a clear for reset.
                                    
    cld                             ; Second clear loop, but just 9 bytes. 
    ldx    #0
    txa
.loopClearReset:
    dex
    txs
    pha
    bne    .loopClearReset

    sec
    ror    flags                    ; because reset switch not pressed...
    jmp    .waitOverscan            ; timer will run out as normal, no bounces, audio has been killed

    
.continueOverscan:

;.... bunch of code for overscan


.waitOverscan:
    lda    INTIM
    bne    .waitOverscan
    jmp    MainLoop

.

.

I never do this:

.

Start:
    cld
    ldx    #0
    txa
.loopClear:
    dex
    txs
    pha
    bne    .loopClear

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

MainLoop:

.waitOverscan:
    lda    INTIM
    bne    .waitOverscan

    lda    #$0E
.loopVsync:
    sta    WSYNC
;---------------------------------------
    sta    VSYNC
    lsr
    bne    .loopVsync

.

.

I never do that because when you first start the game you might get a really big bounce on your TV as it waits for the timer to run out. To avoid it you would have to spend a few more bytes to jump over the .waitOverscan or to initialize the timer. I think it's better not to wait at all for the timer and get the TV synced up as soon as possible so you get the least possible bounce. This is why I use two clear loops. You could also easily make the clear loop a subroutine and save some more bytes.

[+nanochess]

Currently I handle Reset at end of overscan and it goes directly into the title screen message, so the synchro shoud come in seamlessly.

 

Anyway I'll give a look, I don't have tested this.