Movie Cart

JetSetIlly · September 11, 2021

1 minute ago, Thomas Jentzsch said:

So the playfield gets a fixed pattern? Colors seems to be updated for BK every line, for PF per frame. Correct?

The PF pattern is fixed.

Colours for PF and BK are set every alternate scanline. For the duration of a scanline, one of the colours will be black and the other will be another colour (possibly black).

1 minute ago, Thomas Jentzsch said:

That means all 4 colors are in use. If none of them is set to permanent black, you cannot hide the background color changes. That leaves VBLANK (two extra TIA writes) or changing the BK (or PF) color twice per line (one extra TIA write).

I would agree with that.

Thomas Jentzsch · September 11, 2021

11 minutes ago, JetSetIlly said:

Colours for PF and BK are set every alternate scanline. For the duration of a scanline, one of the colours will be black and the other will be another colour (possibly black).

This is done to create a checkerboard which is inverse to the sprite checkerboard, right? So the background of each sprite is always black. Or is it vice versa?

Edited September 11, 2021 by Thomas Jentzsch

JetSetIlly · September 11, 2021

4 minutes ago, Thomas Jentzsch said:

This is done to create a checkerboard which is inverse to the sprite checkerboard, right? So the background of each sprite is always black.

That's not my understanding. The playfield/background will show through the gaps in the sprite, giving more colour resolution to the movie per scanline (six colours per scanline by my counting).

Thomas Jentzsch · September 11, 2021

3 hours ago, JetSetIlly said:

That's not my understanding. The playfield/background will show through the gaps in the sprite, giving more colour resolution to the movie per scanline (six colours per scanline by my counting).

So vice versa. One color (PF or BK) being fixed for the whole line, the other 5 are per sprite.

Anyway, that means either PF or BK color is black for a whole line. And one would "only" have to hide the other one.

Hm.. We might be able to use the missiles (at 8 pixel width). They would be positioned right of the movie area and then move in sync with the spites. Then, every line where the PF is colored, we need two extra black color writes (P1 and P0). That's only extra 6 cycles, because we only have to load black once for P0, P1 and PF colors.

~~I am not sure if the first write can happen early enough. Also, while this may work on the right side, it may not work on the left one.~~

See next post.

Edited September 11, 2021 by Thomas Jentzsch

Thomas Jentzsch · September 11, 2021

A much simpler approach would be to change the timing for PF and BK color changes. Changing to color should be done as late a possible, changing back to 0 as soon as possible (directly after the last color write). Timing doesn't look bad.

Thomas Jentzsch · September 11, 2021

A quick idea: How about updating audio 0 and 1 on alternating lines?

I think this might allow for some nice stereo effects. And I think for mono they should sound identical when combined.

+SpiceWare · September 11, 2021

On 9/10/2021 at 2:03 AM, Andrew Davie said:

I just noticed that YouTube is showing this at 30 Hz.

For YouTube 480 and below are 30 HZ, 720 and above are 60 Hz.

So to make the flicker show up you'll need to capture or resize your video to a higher resolution.

Thomas Jentzsch · September 11, 2021

7 hours ago, Thomas Jentzsch said:

A much simpler approach would be to change the timing for PF and BK color changes. Changing to color should be done as late a possible, changing back to 0 as soon as possible (directly after the last color write). Timing doesn't look bad.

Here is my simple kernel demo from above modified. No extra cycles and no flicker left or right anymore.

movie_kernel_v2.bin

JetSetIlly · September 11, 2021

2 minutes ago, Thomas Jentzsch said:

Here is my simple kernel demo from above modified. No extra cycles and no flicker left or right anymore.

movie_kernel_v2.bin 2 kB · 1 download

Nice.

+Andrew Davie · September 11, 2021

50 minutes ago, Thomas Jentzsch said:

Here is my simple kernel demo from above modified. No extra cycles and no flicker left or right anymore.

Remarkable! Well done.

+rbairos · September 11, 2021

1 hour ago, Thomas Jentzsch said:

Here is my simple kernel demo from above modified. No extra cycles and no flicker left or right anymore.

movie_kernel_v2.bin 2 kB · 6 downloads

Sorry I missed a bunch!
Yes your assumptions above are correct.
The current kernel does in fact maintain a background checkerboard pattern that is in sync with the sprite data. (directly behind it)
This is accomplished with a fixed PF pattern, where each scanline, I either color the background, and black the PF (and vice versa on the next line).

Your attached kernel is able to defer/advance that coloring enough to keep the sides blank?

If so: Holy moly.

PS. Do you have the asm file to make porting easier?

Edited September 11, 2021 by rbairos

+rbairos · September 11, 2021

5 hours ago, Thomas Jentzsch said:

A quick idea: How about updating audio 0 and 1 on alternating lines?

I think this might allow for some nice stereo effects. And I think for mono they should sound identical when combined.

Interesting.
Would also be backward compatible. One byte change.
But is stereo expressed anywhere in the atari h/w or emulation world?

+ZeroPage Homebrew · September 11, 2021

10 minutes ago, rbairos said:

But is stereo expressed anywhere in the atari h/w or emulation world?

Stella supports stereo and here's a thread with a list of classic and homebrew games designed for stereo.

- James

image.png.e23fc2efc54f47f384c9fec4d4f86edf.png

Thomas Jentzsch · September 11, 2021

26 minutes ago, rbairos said:

PS. Do you have the asm file to make porting easier?

The changes are quite simple, just move the COLUPF/BK writes.

My kernel is skipping the audio writes, because of the much slower branching. But in your code, you just have to move the existing stuff around a bit. I didn't bother with that. . Here is some adapted code, as you can see, there are more than enough cycles for reenabling audio and timing it well. UNTESTED!

  MAC LEFT_KERNEL ; {graphics index}, {shading value}, {background}
    SLEEP   2               ; 2
    lda     #GRP1a_L{1}     ; 2
    sta     HMOVE           ; 3     @73     -8 pixel
    sta     GRP1            ; 3             VDELed
;---------------------------------------
; 0a - 1a - 0b - 1b - 0c -
    lda     #COL1a_L - {2}  ; 2
    sta     COLUP1          ; 3
    lda     #0              ; 2             undefined
    sta     AUDV0           ; 3     @10
 
    ldx     #GRP0c_L{1}     ; 2
    ldy     #COL0c_L - {2}  ; 2

    lda     #GRP0a_L{1}     ; 2
    sta     GRP0            ; 3
    lda     #COL0a_L - {2}  ; 2
    sta     COLUP0          ; 3

    lda     #GRP1b_L{1}     ; 2
    sta     GRP1            ; 3             VDELed

    lda     #{3}            ; 2
    sta     COLUPF          ; 3

    lda     #COL0b_L - {2}  ; 2
    sta     COLUP0          ; 3     @39!    end of GRP0a display
    lda     #GRP0b_L{1}     ; 2
    sta     GRP0            ; 3     @44!    end of GRP1a display

    lda     #COL1b_L - {2}  ; 2
    sta     COLUP1          ; 3     @49

    stx     GRP0            ; 3     @52
    sty     COLUP0          ; 3     @55     <=@57
                                                 
    lda     #0              ; 2
    sta     COLUPF          ; 3     @60

    lda     #$80            ; 2
    sta     HMP0            ; 3
    sta     HMP1            ; 3     @68
  ENDM

  MAC RIGHT_KERNEL ; {graphics index}, {shading value}, {background}
    SLEEP   3               ; 3
    lda     #GRP1a_R{1}     ; 2
    sta     GRP1            ; 3             VDELed   @76                                  
;---------------------------------------
; - 0a - 1a - 0b - 1b - 0c
    sta     HMOVE           ; 3     @03     +8 pixel
    lda     #0              ; 2             undefined
    ldx     #GRP0c_R{1}     ; 2
    sta     AUDV0           ; 3     @10
    ldy     #COL0c_R - {2}  ; 2

    lda     #COL1a_R - {2}  ; 2
    sta     COLUP1          ; 3

    lda     #GRP0a_R{1}     ; 2
    sta     GRP0            ; 3
    lda     #COL0a_R - {2}  ; 2
    sta     COLUP0          ; 3

    lda     #GRP1b_R{1}     ; 2
    sta     GRP1            ; 3             VDELed

    lda     #{3}            ; 2
    sta     COLUBK          ; 3

    lda     #COL0b_R - {2}  ; 2
    sta     COLUP0          ; 3     @42!    end of GRP0a display
    lda     #GRP0b_R{1}     ; 2
    sta     GRP0            ; 3     @47!    end of GRP1a display

    lda     #COL1b_R - {2}  ; 2
    sta     COLUP1          ; 3     @52

    stx     GRP0            ; 3     @55
    sty     COLUP0          ; 3     @58     <=@60

    lda     #$0             ; 2
    sta     COLUBK          ; 3     @63

    sta     HMCLR           ; 3     @66
  ENDM

Thomas Jentzsch · September 11, 2021

1 hour ago, ZeroPage Homebrew said:

Stella supports stereo and here's a thread with a list of classic and homebrew games designed for stereo.

- James

The settings also exists per ROM. And besides the games mentioned already, Stay Frosty also has this option set.

+Omegamatrix · September 11, 2021

Thats good Thomas! I hadn't seen the actual kernel until now, and yes the solution is quite obvious.

BTW, if the spare cycles are not used then 5 more bytes could be saved between the two kernels. Just set the stack pointer to 0 and use TSX, with STX COLUPF or STX COLUBK. With X=0, the sleeps can be eliminated to make use STA ZP,X taking 4 cycles.

; set SP to 0 instead of $FF
; enter the kernels with X=0


  MAC LEFT_KERNEL ; {graphics index}, {shading value}, {background}
;     SLEEP   2               ; 2
;     lda     #GRP1a_L{1}     ; 2
;     sta     HMOVE           ; 3     @73     -8 pixel
    lda     #GRP1a_L{1}     ; 2     @69
    sta     HMOVE,X         ; 4     @73     -8 pixel
    
    sta     GRP1            ; 3             VDELed
;---------------------------------------
; 0a - 1a - 0b - 1b - 0c -
    lda     #COL1a_L - {2}  ; 2
    sta     COLUP1          ; 3
    lda     #0              ; 2             undefined
    sta     AUDV0           ; 3     @10
 
    ldx     #GRP0c_L{1}     ; 2
    ldy     #COL0c_L - {2}  ; 2

    lda     #GRP0a_L{1}     ; 2
    sta     GRP0            ; 3
    lda     #COL0a_L - {2}  ; 2
    sta     COLUP0          ; 3

    lda     #GRP1b_L{1}     ; 2
    sta     GRP1            ; 3             VDELed

    lda     #{3}            ; 2
    sta     COLUPF          ; 3

    lda     #COL0b_L - {2}  ; 2
    sta     COLUP0          ; 3     @39!    end of GRP0a display
    lda     #GRP0b_L{1}     ; 2
    sta     GRP0            ; 3     @44!    end of GRP1a display

    lda     #COL1b_L - {2}  ; 2
    sta     COLUP1          ; 3     @49

    stx     GRP0            ; 3     @52
    sty     COLUP0          ; 3     @55     <=@57
                                                 
;     lda     #0              ; 2
;     sta     COLUPF          ; 3     @60
    tsx                     ; 2     X=0
    stx     COLUPF          ; 3     @60

    lda     #$80            ; 2
;     sta     HMP0            ; 3
;     sta     HMP1            ; 3     @68
    sta     HMP0,X          ; 4
    sta     HMP1,X          ; 4     @70
  ENDM

  MAC RIGHT_KERNEL ; {graphics index}, {shading value}, {background}
;     SLEEP   3               ; 3
;     lda     #GRP1a_R{1}     ; 2
;     sta     GRP1            ; 3             VDELed   @76                                  

    lda     #GRP1a_R{1}     ; 2    @72
    sta     GRP1,X          ; 4    @76       VDELed   @76,  X=0 and write takes 4 cycles not 3
;---------------------------------------
; - 0a - 1a - 0b - 1b - 0c
    sta     HMOVE           ; 3     @03     +8 pixel
    lda     #0              ; 2             undefined
    ldx     #GRP0c_R{1}     ; 2
    sta     AUDV0           ; 3     @10
    ldy     #COL0c_R - {2}  ; 2

    lda     #COL1a_R - {2}  ; 2
    sta     COLUP1          ; 3

    lda     #GRP0a_R{1}     ; 2
    sta     GRP0            ; 3
    lda     #COL0a_R - {2}  ; 2
    sta     COLUP0          ; 3

    lda     #GRP1b_R{1}     ; 2
    sta     GRP1            ; 3             VDELed

    lda     #{3}            ; 2
    sta     COLUBK          ; 3

    lda     #COL0b_R - {2}  ; 2
    sta     COLUP0          ; 3     @42!    end of GRP0a display
    lda     #GRP0b_R{1}     ; 2
    sta     GRP0            ; 3     @47!    end of GRP1a display

    lda     #COL1b_R - {2}  ; 2
    sta     COLUP1          ; 3     @52

    stx     GRP0            ; 3     @55
    sty     COLUP0          ; 3     @58     <=@60

;     lda     #$0             ; 2
;     sta     COLUBK          ; 3     @63
    tsx                     ; 2     X=0
    stx     COLUBK          ; 3     @60

;     sta     HMCLR           ; 3     @66
    sta     HMCLR,X         ; 4     @67
  ENDM

+rbairos · September 12, 2021

6 hours ago, Thomas Jentzsch said:

The changes are quite simple, just move the COLUPF/BK writes.

My kernel is skipping the audio writes, because of the much slower branching. But in your code, you just have to move the existing stuff around a bit. I didn't bother with that. . Here is some adapted code, as you can see, there are more than enough cycles for reenabling audio and timing it well. UNTESTED!

I could very well be doing something wrong, but it's *almost* there.
See image below. I think the background is being turned back on, one pixel too late?

Here's my port. Please excuse the sloppy style:

       ;;;;;;;;;;;;;;;;;;;;;
       ;;
       ;; right hand
       ;;
       ;;;;;;;;;;;;;;;;;;;;;

; enter at pixel pos 151 / color clock 219
; left_line/right_line kernel adapted by Thomas Jentzsch

right_line

set_gdata6
lda #GDATA6 ; 2
sta GRP1 ; 3 VDELed

;---------------------------------------
; - 0a - 1a - 0b - 1b - 0c
sta HMOVE ; 3 @03 +8 pixel

set_aud_right
lda #AUD_DATA ; 2

set_gdata9
ldx #GDATA9 ; 2

sta AUDV0 ; 3 @10

set_gcol9
ldy #GCOL9 ; 2

set_gcol6
lda #GCOL6 ; 2
sta COLUP1 ; 3

set_gdata5
lda #GDATA5 ; 2
sta GRP0 ; 3
set_gcol5
lda #GCOL5 ; 2
sta COLUP0 ; 3

set_gdata8
lda #GDATA8 ; 2
sta GRP1 ; 3 VDELed

set_colubk_r
lda #$00 ; 2 background color
sta COLUBK ; 3 background color

set_gcol7
lda #GCOL7 ; 2
sta COLUP0 ; 3 @42! end of GRP0a display
set_gdata7
lda #GDATA7 ; 2
sta GRP0 ; 3 @47! end of GRP1a display

set_gcol8
lda #GCOL8 ; 2
sta COLUP1 ; 3 @52

stx GRP0 ; 3 @55
sty COLUP0 ; 3 @58 <=@60

   lda       #$00       ; 2 turn off background color
   sta       COLUBK       ; 3 background color

sta HMCLR ; 3

;;;;

;;;;;;;;;;;;;;;;;;; page 3 - left
org $F980

left_line
       ;;;;;;;;;;;;;;;;;;;;;
       ;;
       ;; left hand
       ;;
       ;;;;;;;;;;;;;;;;;;;;;

;EnterLeftKernel
;---------------------------------------
; 0a - 1a - 0b - 1b - 0c -
set_gdata1
lda #GDATA1 ; 2

;back 8, late hmove ;needs to be on cycle 71
sta HMOVE

sta GRP1 ; 3 VDELed

set_gcol1
lda #GCOL1 ; 2
sta COLUP1 ; 3

set_aud_left
lda #AUD_DATA ; 2
sta AUDV0 ; 3 @10

set_gdata4
ldx #GDATA4 ; 2
set_gcol4
ldy #GCOL4 ; 2

set_gdata0
lda #GDATA0 ; 2
sta GRP0 ; 3

set_gcol0
lda #GCOL0 ; 2
sta COLUP0 ; 3

set_gdata3
lda #GDATA3 ; 2
sta GRP1 ; 3 VDELed

set_colupf_l
lda #$00 ; 2 playfield color
sta COLUPF ; 3 playfield color

set_gcol2
lda #GCOL2 ; 2
sta COLUP0 ; 3 @39! end of GRP0a display
set_gdata2
lda #GDATA2 ; 2
sta GRP0 ; 3 @44! end of GRP1a display

set_gcol3
lda #GCOL3 ; 2
sta COLUP1 ; 3 @49

stx GRP0 ; 3 @52
sty COLUP0 ; 3 @55 <=@57

lda #$00 ; 2 turn off playfield
sta COLUPF ; 3

lda #$80 ; 2
sta HMP0 ; 3
sta HMP1 ; 3 @63

lda #00 ; 2 dummy

; have to re-enter at correct cycle
pick_continue
jmp right_line

Edited September 12, 2021 by rbairos

+Omegamatrix · September 12, 2021

@rbairos determine which kernel is the problem (left or right). It can be fixed by swapping the early loads of X or Y. For example if the right hand kernel is the issue than try this:

  MAC RIGHT_KERNEL ; {graphics index}, {shading value}, {background}
    SLEEP   3               ; 3
    lda     #GRP1a_R{1}     ; 2
    sta     GRP1            ; 3             VDELed   @76                                  
;---------------------------------------
; - 0a - 1a - 0b - 1b - 0c
    sta     HMOVE           ; 3     @03     +8 pixel
    lda     #0              ; 2             undefined
    
;     ldx     #GRP0c_R{1}     ; 2
    ldx     #{3}            ; 2      CHANGED


    sta     AUDV0           ; 3     @10
    ldy     #COL0c_R - {2}  ; 2

    lda     #COL1a_R - {2}  ; 2
    sta     COLUP1          ; 3

    lda     #GRP0a_R{1}     ; 2
    sta     GRP0            ; 3
    lda     #COL0a_R - {2}  ; 2
    sta     COLUP0          ; 3

    lda     #GRP1b_R{1}     ; 2
    sta     GRP1            ; 3             VDELed
;     lda     #{3}            ; 2
;     sta     COLUBK          ; 3
    stx     COLUBK          ; 3      CHANGED
    ldx     #GRP0c_R{1}     ; 2      CHANGED
    
    
    lda     #COL0b_R - {2}  ; 2
    sta     COLUP0          ; 3     @42!    end of GRP0a display
    lda     #GRP0b_R{1}     ; 2
    sta     GRP0            ; 3     @47!    end of GRP1a display

    lda     #COL1b_R - {2}  ; 2
    sta     COLUP1          ; 3     @52

    stx     GRP0            ; 3     @55
    sty     COLUP0          ; 3     @58     <=@60

    lda     #$0             ; 2
    sta     COLUBK          ; 3     @63

    sta     HMCLR           ; 3     @66
  ENDM

Thomas Jentzsch · September 12, 2021

1 hour ago, rbairos said:

I think the background is being turned back on, one pixel too late?

One reason could be, that your timing is off by one cycle (too late).

BTW: Can you share a new test ROM with the Stella team?

Edited September 12, 2021 by Thomas Jentzsch

Thomas Jentzsch · September 12, 2021

Looking at the circle above, I wonder about some colors, which seem to be mixed for antialiasing. Here is an example from the left side:

image.png.be9324a488d9079d56ec013b1036aa3f.png

Why are some pixel in the left column in light blue?

E.g. I suppose the top two light blue lines should indicate that the white of the circle extends a bit (less than one whole pixel) further to the left. But then the coloring of the right part is wrong.

Either the right part should stay white and the left, green part slightly lighter (which seems to be the case already). (2nd row)
Or the right part should be extended one pixel bit to the left. Then the left part should not be lightened and the right part would be a mix of (mostly) white and green. (1st row)

The all blue line seems even worse. Is that a bug or will that be corrected by the 2nd frame which we cannot see here?

Edited September 12, 2021 by Thomas Jentzsch

+MarcoJ · September 12, 2021

Think I better knock, knock, knock on wood(y).

+rbairos · September 12, 2021

Sorry, very early for me, but wanted to dump some more info:

I've committed the stella changes to the github:
https://github.com/lodefmode/stella

The asm changes are listed here:
https://github.com/lodefmode/moviecart/tree/main/asm

This screenshot shows before and after:
Looks like player graphics data is correct.
Also its correct because previous tests with all black background still work properly.

Also included screenshot of just the background colors, and the circle graphics data minus background:

It seems to definitely be in right kernel.
I swapped the assignment of the color background a little earlier, and it filled that black line
as well introduced several pixels of artifacts on the left side.
I haven't tried Omegamatrix change yet, but looks promising.

Finally attaching the mvc file which produces the circle (with 30 seconds of audio).

Thanks everyone!

output_circle.zip

Thomas Jentzsch · September 12, 2021

38 minutes ago, rbairos said:

It seems to definitely be in right kernel.

@rbairos Yup, you are wasting 2 cycles between left and right kernel, so the right kernel executes 2 cycles too late.

The 2 cycles should be wasted between right and left kernel instead.

BTW: Why do you have ORGs all over your code? The video kernel has no branches, so it doesn't need any alignment. And generally e.g. ALIGN $100 is the better choice.

Edited September 12, 2021 by Thomas Jentzsch

+rbairos · September 12, 2021

29 minutes ago, Thomas Jentzsch said:

@rbairos Yup, you are wasting 2 cycles between left and right kernel, so the right kernel executes 2 cycles too late.

The 2 cycles should be wasted between right and left kernel instead.

BTW: Why do you have ORGs all over your code? The video kernel has no branches, so it doesn't need any alignment. And generally e.g. ALIGN $100 is the better choice.

Okay, I'll shift that dummy line.

Reason I have org's everywhere is the hardware version of this was implemented with a 1K dual-port ram.
It monitored line A7 to determine which of the eight 128-byte regions it was in, to know what to update.
The emulator also monitors A7 for the same reason.
Didn't know about the ALIGN macro, though I still have to be very specific where everything lives.

Stay tuned..

Edited September 12, 2021 by rbairos

+Andrew Davie · September 12, 2021

6 hours ago, Thomas Jentzsch said:

BTW: Can you share a new test ROM with the Stella team?

Here's another test ROM that's much larger... (Kong vs Dinosaurs)

https://www.dropbox.com/s/1x4xte4056ulrtb/kong.mvc?dl=0

Edit: and another (Knock on Wood - Amii Stewart)

https://www.dropbox.com/s/na24ontc5pfp4mr/knockonwood.mvc?dl=0

Edited September 12, 2021 by Andrew Davie

Sign In

Movie Cart

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Recently Browsing 0 members