2600 in 2006

The first demo was nicely structured, with evenline and oddline that start on cycle 0-4 and end on cycle 0 precisely; they take a parameter indicating what cycle they're starting on, and parameters for each item to be displayed on the line.

 

To free up the necessary cycles to make the left column work on a real 2600 I'll have to push things around so they won't be nearly as nicely structured. They'll probably start on cycle 6-10 and end on cycle 6, and four of the parameters the evenline macro will be shape data that should appear on the next oddline macro. Still, I expect to be able to get the left column working.

Still, I expect to be able to get the left column working.

 

Nope. Don't think I'll manage it, unless I figure out some new trick. I still think it may be possible if I give up even/odd coloring. Would that be worthwhile trade-off?

This is incredibly cool. I can only see it lined up properly on the real thing via Cuttle Cart. You should have Stephen look at this because Stella doesn't even come close to rendering it properly.

Still, I expect to be able to get the left column working.

 

Nope. Don't think I'll manage it, unless I figure out some new trick. I still think it may be possible if I give up even/odd coloring. Would that be worthwhile trade-off?

 

It might be to someone. In general I think status type information is better left above or below the bitmap. Even though it constrains the total resolution, the score will then be solid instead of flickered which would be prettier. But you never know.

 

Personally I'd like to see how playfield could be mixed in somehow.

 

In a Chimera environment you shouldn't ever have to worry about how much calculation or memory it takes. As long as the TIA can generate the display hardcoded, assume the game is doable.

Glad you like the demo. Uses up a good chunk of 32K just to show a single static screen (well, flickering pair of screens)

 

It might be to someone. In general I think status type information is better left above or below the bitmap. Even though it constrains the total resolution, the score will then be solid instead of flickered which would be prettier. But you never know.

 

Personally I'd like to see how playfield could be mixed in somehow.

 

Depending upon what is being drawn on the display, having the score/status be solid rather than flickering could be a good or bad thing. And for those where a solid score/status display would be good, one could use my ten-digit score routine which shows two groups of five full-size digits (or 2x10 small ones). In any case, the rightmost two "outside" sprites in that kernel are "freebies" which have to show up to make the other 14 sprites work; they either have to show something or be blanked. One could save two cycles by blanking them both with #0, but otherwise one may as well use them.

 

On the other hand, there may very likely be some games that really don't benefit from the even/odd coloring, and bashing out another byte of display may be fun.

 

It should be no problem doing 96 pixels "reverse video" with a full playfield overlay and full even/odd coloring (I've worked out timing to do 96 pixels of "reverse video" with even/odd coloring of COLUPx only using ABS,y mode for most stuff; going to immediate mode will make even/odd coloring trivial). Doing 104 pixels of non-reverse video would be easy, but probably not as useful. Pushing out to 104 pixels of reverse video may or may not be workable.