About the pixels computation and the logic computation

[Dong]

Hi, guys.

 

I have some questions about the programming of atari games. 

 

Here is my understanding of atari programming. 

Logically, a game should contains two parts.

First part  is the logic computation which is the internal game logic(such like computing the rewards, relative locations and so on.)

The second part is visualization to player. This part is time-comsuming (which is to scan all the scanlines).

 

First question: Am I right?

Second question: If I am right, Can I remove the part of scaning all the scanlines if we don't want to visualization(which time-consuming)?

 

I heard the people in the forums are very nice. 

Thanks in advance.

 

[+SpiceWare]

1) pretty much - though as part of the visualization you have to generate a Vertical Sync signal in the middle of your game logic, and if you don't do it at the right time the screen will jitter/roll.

 

2) Sure, that's what Video Chess does when the computer makes its move.  On older TVs this was a non-issue, on newer TVs you might encounter a blue NO SIGNAL screen which may, or may not, cause issues.  One way to prevent this is to continue to generate the Vertical Sync at the appropriate time, the player would just see a black screen during the logic.

 

You might like to check out my tutorial, it documents the creation of a 2K game.

[Dong]

Thanks for your reply.

 

Is the jitter/roll caused by the mismatch of clock? t seems that every instruction will cost some clock-circle to exectute. The programmer need to sync it with the visualization process. Am I right?

 

So if we don't want the visualization, we can remove it safely without affecting the real game logic computation.  By the way, does visualization cost the majority time of the whole CPU time?

 

I haven't read the source code of atari games. It seems that the source code is hard to find. 

 

Thanks.

 

[+SpiceWare]

The jitter/roll is caused because Chess does not trigger the Vertical Sync signal, which is required every 262 scanlines for a stable display.

 

Games are designed around 192 visible scanlines, give or take.  There's 262 scanlines total, so about 73% of the CPU time is spent updating TIA to create the display.  Everything in the 2600 is under programmer control so you could shrink the visible portion of the display to give more CPU time to logic.

 

My tutorial includes all the source.  For games from back in the day you can find disassemblies that people have created, such as these at MiniDig. @DEBRO's also been posting disassemblies here at AtariAge, such as these:

 

 

 

 

 

 

 

 

I'm sure there's more, I stopped looking. Perhaps a repository should be done for the disassemblies to make it easier to find them - or maybe a new Club should be created.

 

 

 

[Dong]

Thanks for your detailed reply. Appreciate it. 

 

 

 

 

[JeffJetton]

On 2/11/2020 at 2:06 PM, SpiceWare said:

2) Sure, that's what Video Chess does when the computer makes its move.

 

And, as an aside, some computers like the ZX80 and (when in "fast" mode) the ZX81 would routinely drop the video signal logic when it came time for any sort of intensive calculations.

 

The Gigatron, a contemporary 8-bit computer without a microprocessor, finds a nice compromise by displaying black for a user-selected, alternating portion of the scan lines, depending on whether you want a slow program with a nice picture, or a faster program with a dimmer, striped/striated picture. Sort of similar to the "Venetian Blinds" trick used in Video Chess. Although Bob Whitehead used it there in order to display more objects, rather than to give the processor more time to think about game logic. (I don't think any carts ever used something like that to simply to provide more time for program logic, Gigatron-style, did they?)

 

Another option is to simply reduce the number of scanlines used for the visual part of the game, rather than get rid of them all together. That would give you more time in the overscan and/or vertical blank for "thinking", at the expense of a more "letterbox" image. Didn't a lot of carts use that trick?

Edited March 10, 2020 by JeffJetton

[+SpiceWare]

14 minutes ago, JeffJetton said:

 

And, as an aside, some computers like the ZX80 and (when in "fast" mode) the ZX81 would routinely drop the video signal logic when it came time for any sort of intensive calculations.

 

The 40 column display on the C= 128 would blank out if you switched it from 1 to 2 MHz mode. I wrote an IRQ routine that would turn on 1 MHz mode while the visible 200 scanlines were drawn, then turn on 2 MHz mode for the 62 scanlines that made up Overscan and Vertical Blank.  Basically giving you 324 scanlines worth of processing per frame, about a 23% speed boost. It also worked when running C=64 software on a 128.

 

 

Quote

Another option is to simply reduce the number of scanlines used for the visual part of the game, rather than get rid of them all together. That would give you more time in the overscan and/or vertical blank for "thinking", at the expense of a more "letterbox" image. Didn't a lot of carts use that trick?

 

I've not reviewed the games looking for that, but I did point out once that Draconian used fewer scanlines than my other games.