Movie Cart

[+Stephen]

Fascinating!  The colours look really good too.  I've not had any luck with Chronocolour stuff I tried.  It always just looks to be a blurry flickery grey mess on every CRT I have tried.

[chad5200]

Not only is this a great technical achievement, I gotta say, you really went all out with the presentation of the game boxes, manuals, and cartridges.

 

An amazing and fun introduction to your accomplishment!

 

[+cvga]

This whole thread has been amazing. I would love to watch a movie on my atari and agree that the presentation is incredible.

[Thomas Jentzsch]

3 hours ago, rbairos said:

In the end, using only R,G,B at this resolution was way too jarring I found, given the Atari's rich palette.

You could define mix colors per frame. Or even per line.

[Thomas Jentzsch]

3 hours ago, rbairos said:

The RGB-grey one does.  Each frame starts with a different component

I suppose the problem is that flicker and color mixing do not work very well together. 

 

Since each pixel is only drawn every 2nd frame, it takes 6 frames (10Hz flicker) to create one pixel (e.g. R, -, G, -, B, -). This may work for static images, but moving objects will suffer badly.

[+rbairos]

11 minutes ago, Thomas Jentzsch said:

I suppose the problem is that flicker and color mixing do not work very well together. 

 

Since each pixel is only drawn every 2nd frame, it takes 6 frames (10Hz flicker) to create one pixel (e.g. R, -, G, -, B, -). This may work for static images, but moving objects will suffer badly.

Yah, that's where I ended up as well. 
Current MovieCart is 60hz of two checkerboard patterns (30hz flicker) but uses full Atari palette, though at a cost of a reduced resolution (10 x 8 = 80 pixels, less two oddly colored ones).
I think with bus stuffing could probably get another cell or even two back, but was more interested in keeping it compatible with all systems.
Funny thing is, as limited as the Atari is, this wouldn't look nearly as nice on ColecoVision or similar systems with very limited 16 color palettes.

 

[+littaum]

Very nice!  Would this allow for something like Dragon's Lair to be on the 2600?

[Thomas Jentzsch]

6 hours ago, rbairos said:

2.  Yup, there were two beginning pixels that don't receive the color update in time, and show the color from 16 pixels back (or so, don't recall exactly).
I felt that was way more tolerable than 6+6 (12 columns) with two entire columns the wrong color.

Here is a kernel which should fix the problem (only P1 VDELed, P0 at position 32/40, timing for position 32):

                        ;       @02
    ldx     #COL0c      ; 2				
    ldy     #GRP0c_1    ; 2

    lda     #GRP1a_1    ; 2
    sta     GRP1        ; 3             VDELed
    lda     #COL1a      ; 2
    sta     COLUP1      ; 3

    lda     #GRP0a_1    ; 2
    sta     GRP0        ; 3
    lda     #COL0a      ; 2
    sta     COLUP0      ; 3

    lda     #GRP1b_1    ; 2
    sta     GRP1        ; 3             VDELed

    lda     #COL0b      ; 2
    sta     COLUP0      ; 3     @36!    end of GRP0a display
    lda     #GRP0b_1    ; 2
    sta     GRP0        ; 3     @41

    lda     #COL1b      ; 2
    sta     COLUP1      ; 3     @46

    stx     COLUP0      ; 3     @49
    sty     GRP0        ; 3     @52

Let me know if it works. Or if you have questions.

[4ever2600]

Yes I was thinking the same thing... tease us and convert the Dragons Lair attract screen, which is about a 30 second trailer that plays on the arcade game until you plop in a quarter...

 

Lose my shiot over here... lol

[+rbairos]

1 hour ago, 4ever2600 said:

Yes I was thinking the same thing... tease us and convert the Dragons Lair attract screen, which is about a 30 second trailer that plays on the arcade game until you plop in a quarter...

 

Lose my shiot over here... lol

well ..big maybe...
included is the 80 pixel colorized and the larger 96 pixel b/w kernel :

I do recall someone was did this on a Timex Sinclair I believe (using a reduced b/w dithered version).

 

 

 

[JetSetIlly]

2 minutes ago, rbairos said:

well ..big maybe...
included is the 80 pixel colorized and the larger 96 pixel b/w kernel :

I do recall someone was did this on a Timex Sinclair I believe (using a reduced b/w dithered version).

 

 

That would be Jim Bagley who converted Dragon's Lair for the ZX81.

 

[+rbairos]

1 hour ago, Thomas Jentzsch said:

Here is a kernel which should fix the problem (only P1 VDELed, P0 at position 32/40, timing for position 32):

                        ;       @02
    ldx     #COL0c      ; 2				
    ldy     #GRP0c_1    ; 2

    lda     #GRP1a_1    ; 2
    sta     GRP1        ; 3             VDELed
    lda     #COL1a      ; 2
    sta     COLUP1      ; 3

    lda     #GRP0a_1    ; 2
    sta     GRP0        ; 3
    lda     #COL0a      ; 2
    sta     COLUP0      ; 3

    lda     #GRP1b_1    ; 2
    sta     GRP1        ; 3             VDELed

    lda     #COL0b      ; 2
    sta     COLUP0      ; 3     @36!    end of GRP0a display
    lda     #GRP0b_1    ; 2
    sta     GRP0        ; 3     @41

    lda     #COL1b      ; 2
    sta     COLUP1      ; 3     @46

    stx     COLUP0      ; 3     @49
    sty     GRP0        ; 3     @52

Let me know if it works. Or if you have questions.

oh wow, this would be huge if it fits.
I obsessed a very long time over these timings, so I'm a little wary.

But basically, you're saying it can produce:

  A-B-C-D-E    where each letter can be its own independent graph value and color? And each - is 8 bit blank.

What I currently have now is:

  A-B-C-D-E
   -F-G-H-I-J



 

[TrekMD]

This is very impressive!

[Inky]

Tomorrow is 4/1.

 

Just saying.

[Thomas Jentzsch]

7 hours ago, rbairos said:

oh wow, this would be huge if it fits.
I obsessed a very long time over these timings, so I'm a little wary.

But basically, you're saying it can produce:

  A-B-C-D-E    where each letter can be its own independent graph value and color? And each - is 8 bit blank.

What I currently have now is:

  A-B-C-D-E
   -F-G-H-I-J

Yes, both, A-B-C-D-E (I name these 0a-1a-0b-1b-0c) and -F-G-H-I-J will work. For the latter you have to shift the code by 3 cycles. I wrote a simple, static test ROM which works perfectly in Stella.

[SPIKE]

@rbairos

HOLY FRACKEN CRAZY!!!!
i just saw the ZPH vid on YouTube!

I NEED AN ATARI COPY OF BLADE RUNNER!!!!

SO FRACKEN AMAZING!!!

[Shawn]

Really cool project. Be sure to chime in when you get around to Star Wars. Even as a novelty it would be really fun to have a copy of the full movie on a 2600 cart.

[+rbairos]

2 hours ago, Shawn said:

Really cool project. Be sure to chime in when you get around to Star Wars. Even as a novelty it would be really fun to have a copy of the full movie on a 2600 cart.

It was the one @ZeroPage Homebrew showcased if that's what you mean:
 

 

Edited April 1, 2021 by rbairos

[+5-11under]

2 hours ago, Shawn said:

Really cool project. Be sure to chime in when you get around to Star Wars. Even as a novelty it would be really fun to have a copy of the full movie on a 2600 cart.

The "despecialized" version, of course.

Also, all these movies:

 

[4ever2600]

15 hours ago, rbairos said:

well ..big maybe...
included is the 80 pixel colorized and the larger 96 pixel b/w kernel :

I do recall someone was did this on a Timex Sinclair I believe (using a reduced b/w dithered version).

 

 

Wow!  Interesting like you said about the difference between animated and non animated.  Still, one huge leap for Stella kind...

 

[+Propane13]

@rbairos How many minutes are recorded on each cart?

Also, is the sound passed through the cart as well?

[+Andrew Davie]

7 hours ago, Propane13 said:

@rbairos How many minutes are recorded on each cart?

Also, is the sound passed through the cart as well?

I can answer that from what I know already...

You can get an awful lot of compressed '2600 video on a SD cart (from where the cart reads its data).

What's the longest movie you know? I'm sure it could easily fit on an appropriately sized SD card. What do they go to these days? 1TB?

You're never going to run out of space.  The sound would be simply a digitial data stream written to AUDV0 and/or AUDV1 I am guessing.

Pretty much both sound and video streamed directly from the SD into RAM on the cart, and then a kernel on the 6507 accessing.

That's my guess. Can't be too far wrong, but I'm sure @rbairos will correct! Just wanted to get you a quick answer.

Edited April 2, 2021 by Andrew Davie

[+rbairos]

Yup.  In this case movies were about 1.5GB for 2 hours, including sound.
Even then my frame format is about 40% unused/reserved.
Could potentially hold closed captioning or second audio for example. (difficulty switches could be used).
And/or duplicate the whole thing for PAL.

One interesting note for the running timecode: 00:12:34 etc.  I don't generate that on the fly.
I just bake it right into the movie at the bottom of each frame and selectively choose when its displayed.
Makes the cart microcontrollers job easier.
 

Edited April 1, 2021 by rbairos

[alex.james]

Never would have thought such a thing possible. Amazing...

[4ever2600]

So, are the possibilities endless with this? Like programming a regular Atari game, say Adventure, and then jumping to a video of something, and then jumping back to the game? Or a second different game etc?