Jump to content
IGNORED

A Programming CHALLENGE


Andrew Davie

Recommended Posts

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;

 

Atari2600_NTSC_simulation.png

 

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

 

Atari2600_NTSC_palette_sample_image.png

 

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?

 

Link to comment
Share on other sites

post-7074-0-26515700-1381679808_thumb.png

 

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.

 

 

post-7074-0-06083700-1381680553_thumb.png

 

14_ColorVertBars.zip

 

 

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

 

post-7074-0-06046800-1381680986_thumb.png

 

14_ColorVertBars(scroll).zip

 

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

  • Like 3
Link to comment
Share on other sites

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

Link to comment
Share on other sites

 

attachicon.gifparroty.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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...