> >Actually, the Atari 2600 video computer system (came out in '77) > >tended to > >use a "virtual display system"; the display hardware on that thing is > >dirt > >simple, > > I think it was just a couple of clock generators and a shift register. > Did it have any DMA logic or did the 6502 have to stoke it constantly > during the visible part of the scan? There was no DMA logic, but there was a fair bit more to it than "just a couple of clock generators and a shift register". To be precise, the hardware consisted of the following (BTW, if you have a "COMBAT" cartridge convenient it shows these concepts perfectly) [1] A horizontal-timing generator. No CPU intervention is needed to maintain HORIZONTAL sync, or to show a scan line repeatedly. All of the display circuitry in the 2600 is designed to show one scan line; anything beyond that must be done by CPU trickery. Each scan line consists of 228 dot clocks (colorburst rate); every 3 dot clocks is a CPU clock. [2] A wait-control latch; if the CPU does a store to address $02, it will suspend program execution after the next instruction fetch until the start of the next horizontal blanking interval (i.e. the end of the current scan line). [3] A "playfield" generator; this generates the lores background you see in most games. It stores the left 20 bits, addressed as 3 bytes. For some reason these bits are in rather strange order. The right half of the playfield may be a repeat or mirror of the left (in the tank modes, it's mirrored; in some other modes it's repeated). [4] Two "player sprite" generators; these each have an 8-bit shape register, a buffered shape register, a size/placement register, and a horizontal position counter. Each sprite may be selected to appear in any of the following eight configurations: (a) Once, small; (b) Once, double size; (c) Once, 4x size; (d) Twice, 16 pixels center-to-center; (e) Twice, 32 pixels center-to-center; (f) Twice, 64 pixels center-to-center; (g) 3x, 16-pixels center-to-center; (h) 3x, 32-pixels center-to-center. Either second sprite may optionally be reflected about its axis. Note that unless the shape register is rewritten between instances of a sprite, all will have the same shape. [5] Two "missle sprite" generators, associated with the two players, and a "ball sprite" generator, associated with the playfield. These each generate a single blob 1, 2, 4, or 8 pixels wide unless the correspon- ding player is replicated on the scan line, in which case the missles are as well. [6] A color-control circuit with four color registers: background color, playfield/ball color, player1 color, and player2 color. One of these four colors (or black) is output based upon a priority encoder; either the playfield or player sprites may have priority. In addition, there is a special mode, called "score mode", in which the left half of the playfield is the player1 color and the right half is the player2 color (play "COMBAT" or any other similar-vintage game to see why it's called score mode). Each color is defined by a 3-bit luminance (the chip has 3 outputs which are resistor-DAC'ed) and a 4-bit hue (gray or 1 of 15 colors). This yields a total of 128 distinct output colors, a number which compares quite favorably with other systems. [7] The "hmove" circuit, a hack for controlling the positions of the sprites. Rather than using position registers, all of the sprites have counters. The CPU has the following abilities: (a) Reset a sprite's counter to zero; if this is done mid-scan-line, this will change the sprite's position to the current raster location, more or less (different sprites work a little different- ly). (b) Reset a missle's counter to match it's player's (not really all that useful generally, though Combat uses this ability). (c) Perform an HMOVE in which the video-enable signal is inhibitted for an extra 8 pixels at the start of the next scan line (which would cause each sprite to move 8 pixels to the right) and from 0 to 15 extra clocks are given to each sprite counter (moving it 0 to 15 pix to the left). This allows each sprite to be moved 7 pixels left to 8 pixels right, but causes an 8-pixel-wide black area on the next scan line (readily visible in many 2600 games--ever wonder what all those black bars were?) [8] A full range of collision-detectors, conveniently arranged two per byte in positions 6 and 7 (useful on a 6502 since those bits are most readily tested). [9] A VSYNC gating circuit (which the CPU must turn on and off at the proper times each frame--the CPU is responsible for VSYNC timing!) [10] A RIOT chip which consists of 128 bytes' RAM, I/O for the switches and joysticks, and a TIMER. Not really part of the video circuitry, but it's very important to video generation since otherwise it would be hard for games to keep vertical sync consistent. If you play any of the games before about 1981, you'll see that they all fit the above model pretty well; the only readily apparent common diversion is that the playfield is altered mid-scan when displaying people's scores. A close examination of Space Invaders will reveal that when one of the invaders is shot and others remain on the line, the sprite shape register is actually reprogrammed mid-line to show the explosion. > The really interesting thing is that there was nowhere near enough RAM in > the box to store a whole picture in dot-matrix form at once (128 bytes?). > So the software had to generate each line of video right before it was > displayed. All that was stored in the RAM was the line being displayed, > the one being generated, and game variables like the position of each > object on screen. During the vertical blanking interval, there was time > to make high-level analysis of who is worthy of redisplay in the next > field. Pretty much correct; the display registers are as I indicated above--not a whole lot there, really. Abilities such as the ability to display a hires score were not part of the original Atari concept, but someone discovered that if you put the two sprites 8 pixels apart, set them to display 3 times each, and change the shape registers a bunch of times at just the right points each scan line (everything must be in registers beforehand and there aren't any spare cycles; you even have to put one of the shape bytes in the stack pointer since TSX is only 2 cycles but LDX is 3!). > This combination of big ROM, small RAM, and fast CPU sounds a lot like a > PIC chip. It should be possible to clone many of the 2600 games > (especially simple ones like Pong, Space Invaders, maybe even Pac-Man) > into a PIC, using the SSP to shift video out, making a single-chip game > (not that GI didn't already have dedicated single-chip games). Actually, the 2600's CPU isn't really terribly fast. It runs at colorburst over 3, which is about 1.19MHz and the average instruction time is about 3 cycles (helped by the fact that all the RAM and display registers are in zero-page!). Nonetheless, the paradigm of a virtual display system seems to apply since a typical game will look like: while(1) { do_game_stuff(); wait_for_timer(); /* So we put VSYNC in the right spot */ scan_display(); } where the game stuff sets up the registers for the "virtual hardware" which is embodied in scan_display. Because different games need to display diff- erent things, they can push the hardware different ways. For example, in my "columns" 'game' [unfinished] I display 6 colored gems on each scan line; all the gems are the same shape. To do this, I used a technique similar to that for showing hi-res graphics but I changed the color many times instead. Had Atari simply put in a 48-bit hires mode but not allowed for such close CPU/display synchronization, this would not have been possible. An even more extreme variation upon this idea is Galaxian; this game can show seven striped monsters in formation as well as a swooping monster, all on the same scan line, without flicker. To do this, it has to hit the reset-player-position register once every 5 CPU clocks (for those monsters that are present) but it manages to do that. Majorly cool. By the way, other than a few programs (like Chess) which require a "big think", how many other 2600 carts have you seen that don't manage to always maintain VSYNC perfectly even when you restart the game? The only one I can think of is Tron: Deadly Discs (or whatever it was called) which would glitch the screen when you hit reset. How people managed to pay so much more attention to detail then I have no idea. As for cloning games with just a PIC, I think going beyond PONG would be very difficult without some sort of hardware to handle line scanning. The Cyrix part might be able to manage that stunt better, though its smaller address field (12-bit-PIC-style) would make programming a pain. > In color? If the PIC will go 57.28 MHz, this allows a dot clock of > 14.7456 MHz, allowing several awful shades of color (Why "Cyan" and > "Magenta" rather than nice pure red and blue? Because the phase is > even). A persistent rumor claims the 16C5x parts will wail away at 50 > MHz with external clocking. Otherwise some external color logic may be > needed. Maybe using the USART and the SSP at the same time could > generate 2-bit pixels for the color matirx. If I were trying to to standalone video with a PIC, I'd use some external programmable logic to handle color; probably the horizontal timing as well. Vertical timing could easily be managed by the PIC of course.