Movie Cart

[Thomas Jentzsch]

BTW: The movie cart would be a really good entry for the "Wild" compo at Revision 2021. There still are a few hours left until deadline.

[JetSetIlly]

10 minutes ago, Thomas Jentzsch said:

BTW: The movie cart would be a really good entry for the "Wild" compo at Revision 2021. There still are a few hours left until deadline.

 

I was thinking that earlier but one of the general rules is that a demo can't have been released before. The showing on ZPH earlier this week might have disqualified it. But it would have been a strong contender for the win IMO.

 

It might be worth @rbairos asking for a pass. Even if it's not eligible for a competition, that audience would love to see it.

Edited April 2, 2021 by JetSetIlly

[pacman000]

On 3/31/2021 at 9:35 AM, rbairos said:

Thats a public domain animation?
Very cool.
In the end though, I found cartoon animations didn't translate as well.  
The solid patches of colors beside each other didn't lend well to 8-pixel color boundaries unfortunately.
Best was people's faces, houses, driving cars, etc.

The encoder is all on the github and a clip showing the encoding process can be found here:
 

 

Not public domain; just under a permissive license. You still need to give credit to the film's makers.

 

This is a cool project, by the way. Reminds me of recreations of late 20's/early 30's TV.

Edited April 2, 2021 by pacman000

[Thomas Jentzsch]

20 minutes ago, JetSetIlly said:

 

I was thinking that earlier but one of the general rules is that a demo can't have been released before. The showing on ZPH earlier this week might have disqualified it. But it would have been a strong contender for the win IMO.

 

It might be worth @rbairos asking for a pass. Even if it's not eligible for a competition, that audience would love to see it.

I got my game VROOM! accepted too, even though it was in public before. So I suppose this might work too. Maybe just with an new movie. And/or the fixes I posted above.

[+rbairos]

9 minutes ago, Thomas Jentzsch said:

I got my game VROOM! accepted too, even though it was in public before. So I suppose this might work too. Maybe just with an new movie. And/or the fixes I posted above.

Sorry I don't really know much about this community.
Couldn't get a physical cart in Germany by tomorrow, so it would be a digital recording of the movie cart?
Unfortunately, they seem pretty strict:

Entries have to be free of third party rights unless you have a legal license to use the given content. This means no ripped music or vocal samples, no movie snippets, no closeups of trademarked logos, etc. Violations will result in immediate disqualification. 


 

[Thomas Jentzsch]

Just contact the organizers and ask. If the material you use is free to use, you should be fine.

 

hotline-2021@revision-party.net

Edited April 2, 2021 by Thomas Jentzsch

[gambler172]

and it was 1 st april ?

[keithbk]

The first Flash Gordon serial remains copyrighted, but the compilation made of the second serial, and the third serial itself are in the public domain.

 

Flash Gordon on an Atari Cart might be a suitable entry, if either of the later two versions are used. Of course, these are black and white, but they would be cool on the unit.

[+rbairos]

3 hours ago, keithbk said:

The first Flash Gordon serial remains copyrighted, but the compilation made of the second serial, and the third serial itself are in the public domain.

 

Flash Gordon on an Atari Cart might be a suitable entry, if either of the later two versions are used. Of course, these are black and white, but they would be cool on the unit.

Well I sent them a message earlier today but no response.
Flash Gordon is interesting, but having a look through the footage, I suspect it won't translate that well.
There's some interesting stuff on public domain, if you search long enough, but I'm suspecting its too late to contribute at this point.

Thanks for the suggestions though,
Rob.
 

[Thomas Jentzsch]

5 hours ago, rbairos said:

Well I sent them a message earlier today but no response.

I suppose they are all busy with the party now. Maybe this morning, fingers crossed, 2.5h remaining...

[+Andrew Davie]

Just make a submission, with attached note.  Either it gets disqualified or it doesn't.

 

[Thomas Jentzsch]

Here is a quick and simple demo (no movie!) which shows my fixed kernels in action. It should be rather easy to replace the current kernels with these and remove the timing problems (vertical black lines left and right) that way.

 

 

BTW: There seems to be enough free CPU time to allow stereo audio.  

 

movie_kernel.bin movie_kernel.asm

Edited April 3, 2021 by Thomas Jentzsch

[+rbairos]

3 hours ago, Andrew Davie said:

Just make a submission, with attached note.  Either it gets disqualified or it doesn't.

 

I guess I slept through the final submission, but still no reply to my original inquiry yesterday.
I can only imagine they're swamped and/or not interested in flirting with any copyright workarounds.
Oh well, maybe next time.

[+Andrew Davie]

2 minutes ago, rbairos said:

I guess I slept through the final submission, but still no reply to my original inquiry yesterday.
I can only imagine they're swamped and/or not interested in flirting with any copyright workarounds.
Oh well, maybe next time.

I wasn't thinking about the copyright, actually. That's a flat-out "no". I was talking about the fact that it's already been demo'd.

Oh well, was not to be. Next project maybe

 

[+rbairos]

1 hour ago, Thomas Jentzsch said:

Here is a quick and simple demo (no movie!) which shows my fixed kernels in action. It should be rather easy to replace the current kernels with these and remove the timing problems (vertical black lines left and right) that way.

 

 

BTW: There seems to be enough free CPU time to allow stereo audio.  

 

movie_kernel.bin 2 kB · 2 downloads movie_kernel.asm 8.72 kB · 2 downloads

Could have used this a couple years ago!
Still have to sit down and spend some time plugging it in to my controller loops.
Takes me a bit of time to make sure its horizontally centered, and audio is being updated same pixel offset etc.
This will be so awesome.  I spent weeks and weeks trying to find reasonable kernels for this.

Is your Vader screenshot from Stella?
I started cleaning up support for it, but if you've got something better thats cool too.

EDIT:

In terms of stereo, I thought about that, but the 2600 never made that second audio port available, so Im okay with sticking to that.
If there was enough cycles, next thing I would do is modify background color.

Right now, things are best on a black background, but the dithering algorithms wrestle badly when for for example its two non-black colors.
eg: yellow credits on a red background for dragons lair title screen.   Being able to set the 'off' color each scan line would be crazy.


Cheers,
Rob




 

Edited April 3, 2021 by rbairos

[+rbairos]

12 minutes ago, rbairos said:

Right now, things are best on a black background, but the dithering algorithms wrestle badly when for for example its two non-black colors.
eg: yellow credits on a red background for dragons lair title screen.   Being able to set the 'off' color each scan line would be crazy.
 

I think before I get too exacted, I'll simulate this, without any TIA constraints to see what the best-case results would be.

 

Edited April 3, 2021 by rbairos

[Thomas Jentzsch]

16 minutes ago, rbairos said:

Is your Vader screenshot from Stella?

No, just taken from the ZPH stream. So your code is still needed.

16 minutes ago, rbairos said:

In terms of stereo, I thought about that, but the 2600 never made that second audio port available, so Im okay with sticking to that.

Makes sense.

Quote

If there was enough cycles, next thing I would do is modify background color.

Right now, things are best on a black background, but the dithering algorithms wrestle badly when for for example its two non-black colors.
eg: yellow credits on a red background for dragons lair title screen.   Being able to set the 'off' color each scan line would be crazy.

I think that should work. Just like audio it takes only 5 cycles/scanline. 

 

From your code I am not sure how you exit the loop. How many cycles does that take?  

Edited April 3, 2021 by Thomas Jentzsch

[Thomas Jentzsch]

15 minutes ago, rbairos said:

Takes me a bit of time to make sure its horizontally centered, and audio is being updated same pixel offset etc.

That should be the case in my code.

[+rbairos]

19 minutes ago, Thomas Jentzsch said:

No, just taken from the ZPH stream. So your code is still needed.

Makes sense.

I think that should work. Just like audio it takes only 5 cycles/scanline. 

 

From your code I am not sure how you exit the loop. How many cycles does that take?  

I'll have to review, but it was close to full.
I've attached it here, from my github. (original version, without your updates):
important part:   right_line  and left_line. (badly named but each fills in 5 cells of the 10)
left_line has a JMP statement normally back to right_line.

Note also I have to be on cycle 71 for each HMOVE (for the 8 pixel shift) further constraining things.
And made sure audio update was on same pixel clock *** Though I think this can be relaxed as the Atari just updates the audio on its own specific pixel clock anyways?

Im remembering now I couldn't quite manage to add a spare store, keeping all these constraints, but that might open up with your kernel change.
Even updating background every second line would open up possibilities.

@JetSetIlly incidentally just finished successfully porting this to the Gopher2600 emulator

 

core.asm

Edited April 3, 2021 by rbairos

[Thomas Jentzsch]

2 minutes ago, rbairos said:

Note also I have to be on cycle 71 for each HMOVE (for the 8 pixel shift) further constraining things.

Not sure how you count, my cycle count is always after the instruction. And there @73 and @74 are both doing the same. I choose @73, because then you can use WSYNC or have 3 cycles for an extra register write.

 

2 minutes ago, rbairos said:

And made sure audio update was on same pixel clock *** Though I think this can be relaxed as the Atari just updates the audio on its own specific pixel clock anyways?

In my code it is always @10. It is better to have it constant.

 

2 minutes ago, rbairos said:

Im remembering now I couldn't quite manage to add a spare store, keeping all these constraints, but that might open up with your kernel change.

Between kernels there are 13 and 12 cycles (without using WSYNCs), minus the time required for the JMP. That should be more than enough.

[+rbairos]

34 minutes ago, Thomas Jentzsch said:

Not sure how you count, my cycle count is always after the instruction. And there @73 and @74 are both doing the same. I choose @73, because then you can use WSYNC or have 3 cycles for an extra register write.

 

In my code it is always @10. It is better to have it constant.

 

Between kernels there are 13 and 12 cycles (without using WSYNCs), minus the time required for the JMP. That should be more than enough.

I might have other constraints for entering/exiting consistently, but I'll give it a shot soon.
 

[Ed in Rancho]

Star Wars. A 1977 movie playing on a 1977 home video game system. Mind-blowing technical sorcery, that...!

[+MarcoJ]

I had a quick look at the kernel in operation. It's fast. It is able to use all of A, X, Y with immediate loads(2 cycle) to zero page stores (3 cycle) at precisely the right time to get GRP0/GRP1 to have the right colour and data. It has no dedicated need for using X or Y for tracking the scanline number, nor for using indexed reads with the +2 cycle penalty.  I haven't looked into the hardware, but i'm guessing those immediate load arguments get swapped out on a line by line basis by the hardware. 

[+Andrew Davie]

4 minutes ago, MarcoJ said:

I had a quick look at the kernel in operation. It's fast. It is able to use all of A, X, Y with immediate loads(2 cycle) to zero page stores (3 cycle) at precisely the right time to get GRP0/GRP1 to have the right colour and data. It has no dedicated need for using X or Y for tracking the scanline number, nor for using indexed reads with the +2 cycle penalty.  I haven't looked into the hardware, but i'm guessing those immediate load arguments get swapped out on a line by line basis by the hardware. 

CDFJ does all this. It replaces indexing on lines with a "jump" data stream, too, so you only need a 3-cycle "jmp" on every scanline, and the exit-condition is handled automatically by a jump outside the kernel loop, without any compares.

[+MarcoJ]

5 minutes ago, Andrew Davie said:

CDFJ does all this. It replaces indexing on lines with a "jump" data stream, too, so you only need a 3-cycle "jmp" on every scanline, and the exit-condition is handled automatically by a jump outside the kernel loop, without any compares.

Ah, I wondered about this prospect. I recall CDFJ being able to take advantage of fast swapped immediate loads from its data bank/selection logic. The part I was unsure about was if CDFJ could be able to source the dataset from SD card, rather than only its internal paged ram bank/ data bank.