Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #6676 > unrolled thread

Mystified by an Atari 2600 demo.

Back to article view | Back to comp.programming

Contents

  Mystified by an Atari 2600 demo. Chad <cdalten@gmail.com> - 2016-06-08 16:05 -0700
    Re: Mystified by an Atari 2600 demo. Kaz Kylheku <545-066-4921@kylheku.com> - 2016-06-08 23:51 +0000
      Re: Mystified by an Atari 2600 demo. Chad <cdalten@gmail.com> - 2016-06-08 19:10 -0700
        Re: Mystified by an Atari 2600 demo. Kaz Kylheku <545-066-4921@kylheku.com> - 2016-06-09 04:18 +0000
    Re: Mystified by an Atari 2600 demo. Kaz Kylheku <545-066-4921@kylheku.com> - 2016-06-09 00:01 +0000
    Re: Mystified by an Atari 2600 demo. commodorejohn <commodorejohn@gmail.com> - 2016-06-09 09:47 -0700
    Re: Mystified by an Atari 2600 demo. "J. Clarke" <j.clarke.873638@gmail.com> - 2016-06-10 20:41 -0400
      Re: Mystified by an Atari 2600 demo. Daniel Pitts <usenet@coloraura.com> - 2016-06-11 12:47 -0700
        Re: Mystified by an Atari 2600 demo. "J. Clarke" <j.clarke.873638@gmail.com> - 2016-06-12 00:00 -0400
          Re: Mystified by an Atari 2600 demo. Daniel Pitts <usenet@coloraura.com> - 2016-06-12 21:08 -0700
          Re: Mystified by an Atari 2600 demo. Randy Howard <rhoward.mx@EverybodyUsesIt.com> - 2016-06-13 04:12 -0500

#6676 — Mystified by an Atari 2600 demo.

In the demo, the guy enters the coordinates(?) to a sprite. Right after that, this sprite then gets displayed on a screen. Right after that, he is able to do things like type text and clear the screen. This is done without impacting the sprite. 

The question is how can such a primitive system display two things independently of each other? To the best of my knowledge, the system didn't have threads nor multiple processors. The only clue I got was the guy said that hardware based sprite generators were something the engineers came up. 

[toc] | [next] | [standalone]

#6677

On 2016-06-08, Chad <cdalten@gmail.com> wrote:
>
> In the demo, the guy enters the coordinates(?) to a sprite. Right
> after that, this sprite then gets displayed on a screen. Right after
> that, he is able to do things like type text and clear the screen.
> This is done without impacting the sprite. 
>
> The question is how can such a primitive system display two things
> independently of each other? To the best of my knowledge, the system
> didn't have threads nor multiple processors. The only clue I got was
> the guy said that hardware based sprite generators were something the
> engineers came up. 

But that's where you are wrong; there are in fact multiple processors.

One processor is the main CPU.

The other processor is the video display hardware which scans video
memory and generates a signal.

This video display hardware takes into account the hardware sprites that
it is configured with.  As it scans through the pixel positions to drive
the monitor, any position corresponds to some piece of video memory, and
possibly to one or more sprites. It determines what color has to be
displayed: that of the topmost sprite, or else the background from the
video RAM.

The text doesn't interact with the sprite because the compositing
of the sprite is a nondestructive function done in the video pipeline,
and not in video memory. The sprites live outside of video memory
somewhere and are just superimposed virtually. The hardware re-draws
them 60 times a second (or whatever) and tracks their movement
as their position is reconfigured. The sprites show no matter what
the computer does to the video memory, like clearing the screen,
drawing characters or lines or whatever.

[toc] | [prev] | [next] | [standalone]

#6679

On Wednesday, June 8, 2016 at 4:52:00 PM UTC-7, Kaz Kylheku wrote:
> On 2016-06-08, Chad <cdalten@gmail.com> wrote:
> >
> > In the demo, the guy enters the coordinates(?) to a sprite. Right
> > after that, this sprite then gets displayed on a screen. Right after
> > that, he is able to do things like type text and clear the screen.
> > This is done without impacting the sprite. 
> >
> > The question is how can such a primitive system display two things
> > independently of each other? To the best of my knowledge, the system
> > didn't have threads nor multiple processors. The only clue I got was
> > the guy said that hardware based sprite generators were something the
> > engineers came up. 
> 
> But that's where you are wrong; there are in fact multiple processors.
> 
> One processor is the main CPU.
> 
> The other processor is the video display hardware which scans video
> memory and generates a signal.
> 
> This video display hardware takes into account the hardware sprites that
> it is configured with.  As it scans through the pixel positions to drive
> the monitor, any position corresponds to some piece of video memory, and
> possibly to one or more sprites. It determines what color has to be
> displayed: that of the topmost sprite, or else the background from the
> video RAM.
> 
> The text doesn't interact with the sprite because the compositing
> of the sprite is a nondestructive function done in the video pipeline,
> and not in video memory. The sprites live outside of video memory
> somewhere and are just superimposed virtually. The hardware re-draws
> them 60 times a second (or whatever) and tracks their movement
> as their position is reconfigured. The sprites show no matter what
> the computer does to the video memory, like clearing the screen,
> drawing characters or lines or whatever.

How can the hardware redraw the sprites if they aren't in video memory?

[toc] | [prev] | [next] | [standalone]

#6680

On 2016-06-09, Chad <cdalten@gmail.com> wrote:
> How can the hardware redraw the sprites if they aren't in video memory?

Simply because the hardware can be designed to take inputs from
sources other than the memory-mapped frame buffer (or character
buffer) and combine them together to form the resulting image.

Each pixel that you see is a function computed from some inputs. This
function is calculated dynamically, in real time, as the pixel is
clocked out to the video amplifier of the monitor.

In parallel, the pieces of hardware can determine whether the pixel lies
in the middle of one or more sprites, based on the pixel address and the
configuration of the sprites (their position, their transparency mask
and so on). If the pixel doesn't come from the sprites, then it can be
pulled from video memory.  That all happens in real time, as the video
signal is generated.  The sprite generation circuitry can evaluate the
pixel coordinates against the sprite list in real time and report to the
video signal generation circuitry that a sprite pixel should be
generated instead of a pixel from video RAM.

A more advanced sprite implementation could do some blending of
partially transparent sprites: take the underlying pixel value from
video memory as the background, and blend it with the pixel values of
one or more overlaying transparent sprites to produce the final color
value that goes out to the monitor.

To get the gory details we would have to look at the exact schematics of
a particular machine and its video implementation.

We can move sprites around without copying any pixels. This is the basis
for fast, cheap animation in sprite-based video games.  Sprites can
eliminate the need for double buffering, if the background is static.
For instance, imagine Pac Man. There is a mostly static maze, except for
some dots that get eaten. Pac Man and the ghosts can be sprites, which
means we don't have to worry about the background at all when we move
them around. At the vertical refresh cycle of each frame, we just adjust
their coordinates, and they move to new locations as the next frame is
drawn. We don't need any logic to restore the background that is
revealed when a sprite is moved, or spend cycles on it.

(Don't get me wrong; these old 8 bit micros had plenty of good, fast
games that worked without sprites. Apple II boxes didn't have sprites;
yet decent games. The games were quite complicated to develop without
sprites though and a challenge to make performant. For instance, what
about restoring the background when something moves? One trick is to
take advantage of the fact that the piece only moves by a fixed number
of pixels in each frame: say it never makes jump larger than four
pixels. Then, whenever that shape is drawn, a four pixels of the
background can be drawn around it. That takes care of restoring the
background as the shape moves in a fixed way without any special erase
logic.  The moving magnifying glass in Bob Bishop's "Dung Beetles" is
handled like this, I think, for example.)

-- 
TXR Programming Lanuage: http://nongnu.org/txr
Music DIY Mailing List:  http://www.kylheku.com/diy
ADA MP-1 Mailing List:   http://www.kylheku.com/mp1

[toc] | [prev] | [next] | [standalone]

#6678

On 2016-06-08, Chad <cdalten@gmail.com> wrote:
>
> In the demo, the guy enters the coordinates(?) to a sprite. Right
> after that, this sprite then gets displayed on a screen. Right after
> that, he is able to do things like type text and clear the screen.
> This is done without impacting the sprite. 

By the way, this is why those things are called sprites!

They are like ghosts. In popular culture, ghosts can appear to people in
their visual field, but don't interact with objects. They go through
walls and so on.

Your PC probably has a sprite: namely, the hardware-based mouse cursor!

A hardware-based mouse cursor can stay on the screen and appear
smooth no matter what is happening. Rectangular copies of the
frame buffer from one place to another are oblivious to it, etc.

[toc] | [prev] | [next] | [standalone]

#6681

On Wednesday, June 8, 2016 at 4:05:45 PM UTC-7, Chad wrote:
> In the demo, the guy enters the coordinates(?) to a sprite. Right after that, this sprite then gets displayed on a screen. Right after that, he is able to do things like type text and clear the screen. This is done without impacting the sprite. 
> 
> The question is how can such a primitive system display two things independently of each other? To the best of my knowledge, the system didn't have threads nor multiple processors. The only clue I got was the guy said that hardware based sprite generators were something the engineers came up. 
You don't need hardware multithreading or multiple cores/processors to handle more than one task at a time; we've been doing that since the '60s. All you need is a timer interrupt and a routine to save one execution context and restore another, so that you can cleanly switch from one task to another. With a fast enough rate of switching, it reaches the point where it might as well be simultaneous even if technically it isn't.

What's really impressive isn't doing multitasking, it's doing it on the 2600 - because, while it does have all the requisite facilities (a timer interrupt, and a CPU on which it's really easy to save the execution context,) what it *doesn't* have is a conventional framebuffer, or "sprites" in any sense besides the basic definition of "movable video object that is drawn independently of the playfield." The background is generated by changing the value of a 20-bit single-line pattern on the fly as the raster beam moves down the screen - and the "sprites" are similarly limited. All this must be done in *every frame,* which usually means that any other processing has to be done in the vertical retrace period because timing is so crucial in the visible part of the frame. It's worth reading about: https://en.wikipedia.org/wiki/Television_Interface_Adaptor

So the text and the sprite both have to be drawn pretty much by hand, *and* the processing of user input has to be handled. Quite a juggling act!

[toc] | [prev] | [next] | [standalone]

#6682

In article <23c1e131-543c-4654-85b0-f3876f484635@googlegroups.com>, 
cdalten@gmail.com says...
> 
> In the demo, the guy enters the coordinates(?) to a sprite. Right after that, this sprite then gets displayed on a screen. Right after that, he is able to do things like type text and clear the screen. This is done without impacting the sprite. 
> 
> The question is how can such a primitive system display two things independently of each other? To the best of my knowledge, the system didn't have threads nor multiple processors. The only clue I got was the guy said that hardware based sprite generators were something the engineers came up. 

You don't need threads or multiple processors, just an interrupt 
controller.

[toc] | [prev] | [next] | [standalone]

#6683

On 6/10/16 5:41 PM, J. Clarke wrote:
> In article <23c1e131-543c-4654-85b0-f3876f484635@googlegroups.com>,
> cdalten@gmail.com says...
>>
>> In the demo, the guy enters the coordinates(?) to a sprite. Right after that, this sprite then gets displayed on a screen. Right after that, he is able to do things like type text and clear the screen. This is done without impacting the sprite.
>>
>> The question is how can such a primitive system display two things independently of each other? To the best of my knowledge, the system didn't have threads nor multiple processors. The only clue I got was the guy said that hardware based sprite generators were something the engineers came up.
>
> You don't need threads or multiple processors, just an interrupt
> controller.

Which isn't actually how this works at all.

As others have pointed out, it was specialized hardware which controlled 
the video output.  So you had basically two parallel processes going on, 
one on the CPU, and another on the TIA [1]


[1]: https://en.wikipedia.org/wiki/Television_Interface_Adaptor

[toc] | [prev] | [next] | [standalone]

#6684

In article <njhpte$3hn$2@dont-email.me>, usenet@coloraura.com says...
> 
> On 6/10/16 5:41 PM, J. Clarke wrote:
> > In article <23c1e131-543c-4654-85b0-f3876f484635@googlegroups.com>,
> > cdalten@gmail.com says...
> >>
> >> In the demo, the guy enters the coordinates(?) to a sprite. Right after that, this sprite then gets displayed on a screen. Right after that, he is able to do things like type text and clear the screen. This is done without impacting the sprite.
> >>
> >> The question is how can such a primitive system display two things independently of each other? To the best of my knowledge, the system didn't have threads nor multiple processors. The only clue I got was the guy said that hardware based sprite generators were something the engineers came up.
> >
> > You don't need threads or multiple processors, just an interrupt
> > controller.
> 
> Which isn't actually how this works at all.
> 
> As others have pointed out, it was specialized hardware which controlled 
> the video output.  So you had basically two parallel processes going on, 
> one on the CPU, and another on the TIA [1]
> 
> 
> [1]: https://en.wikipedia.org/wiki/Television_Interface_Adaptor

If you're using memory mapped video there is necessarily some device 
transforming the memory map into a video signal.  If you think that the 
1.19 MHz CPU is somehow taking bits from the memory map and generating a 
6 MHz NTSC video signal from them you need to learn a bit about signa 
processing.  The video controller at the time was a fairly dumb piece of 
equipment that nobody considered to be a "processor".  It wasn't like 
modern GPUs that are by '70s standards supercomputers in their own 
right.

See if you can find a Heathkit microprocessor trainer on ebay with the 
manuals, and do the exercises in them.  When you're done with that 
you'll have a _much_ better idea of how things really worked in that 
era.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[toc] | [prev] | [next] | [standalone]

#6685

On 6/11/16 9:00 PM, J. Clarke wrote:
> In article <njhpte$3hn$2@dont-email.me>, usenet@coloraura.com says...
>>
>> On 6/10/16 5:41 PM, J. Clarke wrote:
>>> In article <23c1e131-543c-4654-85b0-f3876f484635@googlegroups.com>,
>>> cdalten@gmail.com says...
>>>>
>>>> In the demo, the guy enters the coordinates(?) to a sprite. Right after that, this sprite then gets displayed on a screen. Right after that, he is able to do things like type text and clear the screen. This is done without impacting the sprite.
>>>>
>>>> The question is how can such a primitive system display two things independently of each other? To the best of my knowledge, the system didn't have threads nor multiple processors. The only clue I got was the guy said that hardware based sprite generators were something the engineers came up.
>>>
>>> You don't need threads or multiple processors, just an interrupt
>>> controller.
>>
>> Which isn't actually how this works at all.
>>
>> As others have pointed out, it was specialized hardware which controlled
>> the video output.  So you had basically two parallel processes going on,
>> one on the CPU, and another on the TIA [1]
>>
>>
>> [1]: https://en.wikipedia.org/wiki/Television_Interface_Adaptor
>
> If you're using memory mapped video there is necessarily some device
> transforming the memory map into a video signal.  If you think that the
> 1.19 MHz CPU is somehow taking bits from the memory map and generating a
> 6 MHz NTSC video signal from them you need to learn a bit about signa
> processing.  The video controller at the time was a fairly dumb piece of
> equipment that nobody considered to be a "processor".  It wasn't like
> modern GPUs that are by '70s standards supercomputers in their own
> right.
>
> See if you can find a Heathkit microprocessor trainer on ebay with the
> manuals, and do the exercises in them.  When you're done with that
> you'll have a _much_ better idea of how things really worked in that
> era.
Did you read about the TIA?  It was also interesting to read about the 
ANTIC, which was even more powerful.

In both cases, the display isn't merely "memory mapped", there is other 
processes going on in the video chips.  I'm not talking about GPU 
processing.

[toc] | [prev] | [next] | [standalone]

#6686

On 6/11/16 11:00 PM, J. Clarke wrote:
> See if you can find a Heathkit microprocessor trainer on ebay with the
> manuals, and do the exercises in them.  When you're done with that
> you'll have a _much_ better idea of how things really worked in that
> era.

Nice to see this come up. Heathkit was a fantastic company back in the
day, I was very sad to see Zenith destroy them, although the death
slide really started with MS stole Gordon Letwin from them.

Built H8, H89, H150 systems, along with stereo amplifiers, ham radio
gear, CRT monitors and a color TV set from them over the years,
perhaps more I've forgotten. All great stuff, wonderfully well-
documented also.

Their self-paced home instruction course materials in electronics,
software development and related topics were all top grade also.

I first learned Z89 assembly under HDOS when I was around 13 years
old. No videos, no web site tutorials, just wonderfully written
learning textbooks with great exercises. The local user group
communities in cities with a Heathkit store in them were all
extremely helpful as well.

We'll never see the like of that again, I'm afraid.


-- 
Randy Howard
(replace the obvious text in the obvious way if you wish to contact me 
directly)

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web