I only have 128 bytes of RAM available and I want to hook it up to the screen. I know this is doable since the Atari 2600 did it with the same amount of memory, but I don't know how screens work or whatever.

LCD modules have their own screen memory. So hooking up one of those wouldn't use up any of your 128 bytes. Though the access code of course would.

The 2600 used a technique called "racing the beam". Although it had a small amount of RAM, it also had up to 4K of ROM. The ROM contained the bitmaps for the various sprites or tiles to render. During the horizontal blank the 6502 used the ROM to compute the bit patterns needed for the current scan line, and deposit it into the RAM. That way only a line buffer, not a frame buffer, was needed. It was the job of another chip to use that buffer to draw the current scan line.

The Uzebox is a retro console using an ATmega644 that does something similar, but because it runs at 28.6Mhz (8 times the NTSC color burst frequency), it can use software to generate the video signals, rather than external hardware. I've also seen this done with the Propeller microcontroller as well, but it has significantly more RAM.

Oh, but how did the images actually get rendered? The way I've been doing it is by having a register for each column, if the screen was, say, 32x32, I would have 32 registers, each 32 bit. How did the 2600 did it in that case?

The video registers in the 2600 had to be reprogrammed during the time period when the beam is flying back from one line to the next. The Stella(?) chip layers the two player sprites and the missile sprites over the background and detects collisions (when bits in the sprites are 'on' in the same location).

Its worth reading a full description of the 2600 hardware. Its really very basic and there is not an image of the complete video picture anywhere on the machine. It all has to be generated dynamically and must be done within the timing restrictions imposed by the TV signal generation. Its one of the times when you really MUST count the cycles in every instruction.

Its a lot easier generating a composite video or VGA image using a microcontroller if you keep the resolution low. Colour encoding can be tricky, especially on PAL. VGA is a better 'international' solution.

Some of my attempts at generating terminal displays have used 'racing the beam' approaches as the microcontrollers I used didn't have enough memory for a full bit map of the display. My 40x24 terminal on a PIC 18F and 80x24 on a PIC24EP both kept the screen as an array of 16-bit character and attribute values in memory and worked out the pixels for the next character while shifting out the current one (using SPI on the 18F and by hand on of the 24EP).

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

That was the job of the Television Interface Adaptor (TIA) chip, and a good write up of how it works is on Wikipedia:

https://en.wikipedia.org/wiki/Television_Interface_Adaptor

To understand it from 50,000 feet, visualize the Pong game. It has a play field (the lines forming the court), two paddles (vertical lines), and a square ball. One internal register describes the play field for that scan line, while the other registers describe the location of the plays (paddles) and missile (ball). The video rendering is done by TIA, and if your program halted TIA would keep rendering the current register values which distorted the image.

The Atari eight bit home computer line extended the TIA chip into CTIA (later GITA), and paired it with the Antic chip "racing the beam". This allowed for fully bit-mapped graphics, plus a doubling of the players to four, and increasing the missiles to four as well.

There is a wealth of detailed information here:

http://www.atariage.com/2600/programming/

Mike B.

Yeah, a full read-up on exactly how little 2600 programmers had to work with is well worth the time. It's astonishing what they managed to do with the thing.

Let's not forget that "racing the beam" is one of the coolest programming expressions ever. I read on more than one occasion that many of the insanely talented programmers back then got "inspiration" from all kinds of substances. LOL

I guess you had to be a little crazy and on something to master the 2600. Probably why it is still so popular today among game programmers.

_________________
Cat; the other white meat.

This is exactly the kind of hint I’ve been looking for. I’m at a fork in my project, deciding between building my clock dividing, video address generating and character ROM circuits, ala Apple II and /// in hardware or in software within a micro controller of some sort. In order to do a micro controller, I’d need to have it also generate positive and inverse 14mhz, 7mhz, 3.5MHz and more signals. A stock 16mhz Arduino Mega won’t cut it, but something in the 28MHz range would be ideal (at least for timing generation).

Chris

No idea what sort of image you're after but a stock ATmega at 16Mhz is more than capable of video generation - even a '328 with 2KB internal RAM can generate character based 40x25 composite video. My own system has a ATmega 1284p @16Mhz and that does 320x240 monochrome pixel based composite video, but do lookup Daryl Rictoors stuff here and on his own website.

(And another stand-alone ATmega project that does video is the FigNation system - great if you like Forth, also search for the Arduino TVout libraries and projects, or read up on the Sinclair ZX80 for a home computer which bit-banged video via a 4Mhz Z80 and had just 1K of RAM)

The trick is to know that a scan line is 64µS - or in reality less than that as you can trigger the horizontal sync early giving you more time for your other code to run (if needed), so a 64µS interrupt is all you need to clock out the pixels for each line.

The hard part then is getting the data from the 6502 into the ATmega - my approach is a 256 byte shared RAM area, but others have used parallel buses or even serial.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

The "more conventional" approaches to this problem include:

- Use a display module which comes with its own memory and can self-refresh. There are many examples with varying capabilities out there.

- Use a character generator, similar to the SAA5050, to make a few bits go a long way. The BBC Micro used an SAA5050 and a 6845 to turn a 1KB memory area into a 40x25 colour text and low-res graphics display. The 6845 was used *without* the SAA5050 for the high-res graphics modes, which used much more RAM.

You could reasonably use the latter technique in concert with "racing the beam" to make it work within your very limited RAM. Given 40 character cells per line, you could use one byte per cell for "attributes" and another byte per cell for character or direct-raster data. Character data would serve as an address to look up in a ROM, whose data would then be dumped into a shift register; raster data would be dumped straight into the shift register and used directly. Attributes could include not only a text/graphics flag but foreground and background colours, which you could in turn feed through a CLUT array if you were feeling ambitious.

But at some point it's just easier to put in some extra RAM.