Is Atari 2600 programming "real-time"?

[qah661]

I have often had a problem wrapping my head around the concept of real-time software vs non real-time software. I understand that real-time software involves time constraints. Can programming the 2600 be considered real-time then? After all, you do have to be careful of how many CPU cycles you take up per each scanline if you want to draw your graphics correctly, and you have to ensure that the sync and blank signals are sent to the TV at the appropriate times. I'm just curious.

[CapitanClassic]

Wikipedia seems to think so
https://en.m.wikipedia.org/wiki/Real-time_computing

 

Quote

• Real-time computing (RTC), or reactive computing is the computer science term for hardware and software systems subject to a "real-time constraint", for example from event to system response.^{[citation needed]} Real-time programs must guarantee response within specified time constraints, often referred to as "deadlines".
•  
• Hard real-time systems are typically found interacting at a low level with physical hardware, in embedded systems. Early video game systems such as the Atari 2600 and Cinematronics vector graphics had hard real-time requirements because of the nature of the graphics and timing hardware.

The Atari 2600 and the programs that run on them cam be considered a RTS. If the program fails to draw the screen at the appropriate time, the graphics will look garbled. If you fail to send a solid scanline count, the screen will jump and/or roll.

 

Traditionally, what you would normally expect in a real-time multitasking system is some sort of scheduler that can guarantee that certain actions are completed within a certain time period ( AndrewDavie has a thread on his scheduler for Boulder Dash). The Atari 2600 isn’t a multitasking system though, and only needs to run the game ROM that it was intended run. As long as your game was programmed to complete all required tasks before it needs to draw the screen, it will not have failed in its real-time task.

[+SvOlli]

Let me throw in my 2 cents as well, as the definition of "real-time" was something that I took a deeper look into being at the university and also worked for QNX for about two years, who sell a "real-time" operating system.

 

The term "real-time" is rather blunt. It just means that you can guarantee a response time. If this response time is one hour, it is still "real-time" as long as you can guarantee it under all circumstances (asides from power-loss, obviously). This includes software as well as the operating system. For the 2600, there is no OS, so only the software running to consider. And I would define "real-time" in this context as the response to the console switches and joystick, paddle, etc. If this happens within a couple of frames, the 2600 is "real-time". ...unless you take games into account a game like Chess, which takes a lot of time to calculate the next move. When during this period the switches are not evaluated, then it suddenly isn't "real-time" anymore.

 

So the answer is neither "yes" or "no" more like "it depends, but typically yes".

 

(In the operating system world "real-time" typically means that the notification of an input, like an interrupt, reaches your code in a "few milliseconds". And "few milliseconds" is a guaranteed precise number, that differs from system to system.)

[Mr SQL]

On 10/15/2020 at 2:41 PM, SvOlli said:

Let me throw in my 2 cents as well, as the definition of "real-time" was something that I took a deeper look into being at the university and also worked for QNX for about two years, who sell a "real-time" operating system.

 

The term "real-time" is rather blunt. It just means that you can guarantee a response time. If this response time is one hour, it is still "real-time" as long as you can guarantee it under all circumstances (asides from power-loss, obviously). This includes software as well as the operating system. For the 2600, there is no OS, so only the software running to consider. And I would define "real-time" in this context as the response to the console switches and joystick, paddle, etc. If this happens within a couple of frames, the 2600 is "real-time". ...unless you take games into account a game like Chess, which takes a lot of time to calculate the next move. When during this period the switches are not evaluated, then it suddenly isn't "real-time" anymore.

 

So the answer is neither "yes" or "no" more like "it depends, but typically yes".

 

(In the operating system world "real-time" typically means that the notification of an input, like an interrupt, reaches your code in a "few milliseconds". And "few milliseconds" is a guaranteed precise number, that differs from system to system.)

Great explanation!

 

There's a wide range as you pointed out, OLTP is a spec I've worked with where the system must respond within a couple of seconds.

In the OS world some of the real-time subsystems can also be slow by design like Lazy-Writer.

 

imo the Atari 2600 is one of the most real-time systems as you define it in response to Joysticks, paddles and switches because it's architecture allows us to work sub-frame at the scanline level and we can write games and demos that require up to 1/60th of a second response time from the Joysticks like my Fluid City Demo and Game from SillyVenture 2019.

 

In demo mode, the BW switch will make the game require an impossible 60th of a second response time, up from the nearly impossible 30th of a second response time in game mode which is near the edge human reaction times.