A Programming CHALLENGE

[+Andrew Davie]

OK, the fairly SHAMEFUL entry for 2600 palettes on Wikipedia at

http://en.wikipedia.org/wiki/List_of_video_game_console_palettes#Atari_2600

and in particular the parrot images therein;

 

 

kind of annoyed me. We all know that's not a reasonable indication of what a '2600 can do!

 

 

The above is what the picture is supposed to be. Ha!

OK, this makes the '2600 look pathetic. I'm sure we can do better. Well, we can... but how much better?

 

The image given is quite interesting; it's attempted to use background colour changes and playfield colour changes to display the parrot picture. It doesn't work really well, but extending that concept; given both BG and PF colour changes on every scanline, just how good (or bad) a representation of the parrot can we get? Surely we could have a tool/utility which could optimise just a single BG and PF colour change on each scanline, along with selection of which pixels are on/off.

 

Or some other method. Anything must be better.

 

So, I'm throwing out a general programming CHALLENGE to anyone willing to strut their stuff. Do better. Fix up that dreadful Wikipedia entry for the '2600 palette. Let's show the world what our platform CAN do

 

In short, can YOU produce a better image using '2600 as the host?

 

[enthusi]

Maybe you should add that it has to be static, non-interlace I think

Oh and yes, I super-agree on that.

Edited October 13, 2013 by enthusi

[LS_Dracon]

I'll try something...

[Thomas Jentzsch]

Andrew, haven't we solved that problem before? Mixing colors is probably the best solution.

 

And if we are not limited to PF only, we should be able to increase the horizontal resolution.

[Omegamatrix]

 

Parrot.bin

 

 

 

Not my work though. This is from Tjoppen's utility. I resized the picture to 18x75 bitmap and ran the utility. Then I added a few lines to vblank and overscan to make it 312. Tjoppen's kernel uses STA, STX, STY, and SAX zeropage in rapid succession. So you can get color updates every 9 pixels. This limits it to 4 colors a line, but gives quick updates. Using bus stuffing there would be no hold bars and you could do any color.

 

 

I did find another technique to get 14 different colors per scanline. This technique is faster then doing LDA #immediate and STA zeropage. It uses a little stack abuse. It is limited by the address space you can jump into to run code. So you can do colors $1x, $3x, $5x, $7x, $9x, $Bx, $Dx, and $Fx no problem. Some other colors are possible by jumping into zero page ram and running code from there.

 

 

 

14_ColorVertBars.zip

 

 

Then I wrote another demo to make the screen scroll horizontally:

 

 

14_ColorVertBars(scroll).zip

 

I'm not prepared to make that into an utility though.

[enthusi]

Haha, nice method, Omega.

[+Gemintronic]

[+nanochess]

 

parroty.jpg

 

 

Oh my! one alien has just escaped from someone stomach!

[Bit Expander]

I have a different proposal, would be happy to hear your thoughts.

 

The idea is to create a RAM kernel (code attached) that can display 8 colors per line for 192 lines in a frame (from a table, not speed code).

 

Then, do the same for the next frame, but shift the picture 1/2 a color column width (around 10 color clocks) horizontally. This will gain us two advantages:

 

1. Apparent 16 columns x 192 lines resolution

2. Ability to mix colors together, achieving 8-9 bits of color (simulated)

 

The main challenge, from my perspective, is to correctly convert a full color RGB picture in 16x192 resolution into an optimal set of colors for the 2 frames. Nothing to see in the picture yet, since I did not do a proper conversion.

 

Any thoughts?

 

Adam

9bitmap.zip

[Tjoppen]

 

parroty.jpg

 

lol. Add a second color to it!

 

Bit Expander: You're wasting lots of time doing table lookups. Since you have almost limitless ROM to do this just do LDA #Imm + STA COLUBK repeatedly. That should net you 11 samples per line (similar to the plasma in Stella Lives). With staggering this becomes 22 apparent samples every two lines.

[Bit Expander]

lol. Add a second color to it!

 

Bit Expander: You're wasting lots of time doing table lookups. Since you have almost limitless ROM to do this just do LDA #Imm + STA COLUBK repeatedly. That should net you 11 samples per line (similar to the plasma in Stella Lives). With staggering this becomes 22 apparent samples every two lines.

 

Thought of that, easier that a RAM kernel and all. The problem is the ROM size, assuming we are limiting the discussion to 4KB ROMs.

 

Say I want to do what you suggest, I get 4 bytes per color setting (LDA + STA) times 11 colors per line => 44 bytes.

 

I want the high resolution: 44 bytes times 192 lines => 8448 bytes

I want to interleave 2 frames: 8448 times 2 => 16896 bytes , clearly a NO GO.

Even going for 1/2 the resolution, still too much ROM.

 

This is why I'm suggesting a table with tight, self-modifying code.

[+Andrew Davie]

The challenge is to produce the best quality image. Use as much ROM as you want.

Any tricks/hardware valid, as long as it runs on the '2600.

[+Andrew Davie]

 

parroty.jpg

 

 

Well, it's better than the Wikipedia one... I'll give you credit for that

[SeaGtGruff]

Ooh, I like this challenge. I'll try something later tonight.

[+Gemintronic]

My efforts nearly killed an epileptic.. sigh.

 

parroty48.bin parroty96.bin

[enthusi]

Hm, is interlace valid? I dont think so actually.

At least for the original purpose of portraying the machines capabilities and color schemes?

[+Gemintronic]

Hm, is interlace valid? I dont think so actually.

At least for the original purpose of portraying the machines capabilities and color schemes?

 

Nothing I do in this topic is valid. You guys are the experts I'm merely cobbling together what RevEng, SeaGtGruff and batari worked so hard on.

 

The 48x96 one is not interlaced. They both alternate R G B each frame, though.

[Thomas Jentzsch]

Without flicker the options are limited.

 

Besides the obvious 48 pixel sprites or a 160 pixel playfield only (both with color changes each scanline), we could try to mix the playfield with sprites and missiles. Instead of 4 pixel resolution we could get down to 2 pixel then. The quite high vertical resolution should be used to mix colors like in Boulder Dash.

 

Maybe I will give it a try, but my time is quite limited now.

[+Gemintronic]

My only other idea is to still use a 48x96 bitmap but alternate R G B every line. One could then make 3 frames that switch which line gets red, green or blue. That's way too much work for a lunch break, though

[RevEng]

Nice. You should call your new system Chronocolour!

[Tjoppen]

You should do proper interlacing instead progressive flickering. That way it should look nice on TVs, and work nicer with Stella even when phosphor is off (sort of).

[+Gemintronic]

Nice. You should call your new system Chronocolour!

 

LOL! Damn, I was hoping Andrew would pick up the irony first

[+Andrew Davie]

 

LOL! Damn, I was hoping Andrew would pick up the irony first

 

I did, but my lawyers advised they wouldn't have the lawsuit ready till tonight, and I should refrain from responding.

Cheers

A

 

[+Andrew Davie]

Without flicker the options are limited.

 

Besides the obvious 48 pixel sprites or a 160 pixel playfield only (both with color changes each scanline), we could try to mix the playfield with sprites and missiles. Instead of 4 pixel resolution we could get down to 2 pixel then. The quite high vertical resolution should be used to mix colors like in Boulder Dash.

 

The "obvious" 160 pixel playfield with colour changes each scanline might not be so obvious if you try to choose an optimal colour for each line, rather than repeating the same three colours over and over. Then you get interactions between pixels, their colour, and the presence or not of pixels on previous and next lines, and the colours of those lines. A tool which could optimise all of this would be pretty handy/interesting.

 

As to interlacing, I think this is a perfectly valid way of displaying an image, so the challenge will accept interlaced/interleaved entries. Anything that can be screen-grabbed via Stella, or photographed on an actual TV is just fine. Ultimately we're looking for an image that we can add to that wikipedia page to show the best that a '2600 can do, and replace those awful attempts that are there now.

[enthusi]

As much as I hate to disagree with you, I'd consider an interlace image major cheating with respect to Wikipedia.

Any machine can do basically truecolor with interlace

Interlace would neither represent the machine's palette nor its capabilities (except for, yay, it can display different things at different frames).

There are even emulators around that blend 5 frames, so there is no logical limit once you go that road.

But maybe that's just me.

Yet, seeing a picture on wiki that cant be done within one frame, I'd pity the 2600 even more than people do right now seeing the current representation.