I designed the L-Star that cbmeeks already linked to, so I second his motion for that approach of course.
One advantage of L-Star is that it can be used to implement (and study) various approaches to displaying video.
For example, the Apple-1 was basically a terminal attached to a simple 6502 system, so all that the 6502 had to do to put a character on the screen was to write a byte to a port and read the port back until bit 7 changed, indicating that the terminal had processed the character. There was no way to read characters back from the screen, and there was no reason to do so: the Apple-1 was designed in the time when printing terminals were the norm and video terminals were an improvement because they were faster. Software was still mostly written in a way that matched paper terminals: you type in a command and the computer prints the result of that command. After a while, old stuff that gets removed from the top of the screen is lost, but programs were designed to recall information to deal with that (for example, in a game of chess, the program would just draw the updated chess board after each move).
The OSI Challenger (aka Superboard II, aka UK101), which can also be emulated with the L-Star, had direct access to the memory that represents the characters on the screen. There was 1K of video memory and each byte represented a character. The processor can change any character on the screen simply by writing bytes into the display memory area, and it can read what's on the screen by reading memory. The original hardware would read the video memory byte by byte and would use a character ROM to show the glyphs that belonged to the value of each byte. The OSI uses a 256 character font with lots of graphics. Other computers such as the PET2001 (which the L-Star will also be able to emulate in the future) used a 128 character font and used bit 7 of each character to signify that the glyph was to be shown in reverse video.
Another way to generate video is to let the 6502 generate it. This is done (sort of) on the Atari VCS2600 but the disadvantage is that the 6502 is basically doing video most of the time, and it has almost no time to do anything else, except during the vertical blanking. This saves a lot of memory (the Atari had only 128 bytes of RAM!) but it makes it very difficult to program even the simplest things.
Bitmapped graphics are a bit of a problem with the 6502 because even if you only assign 1 bit to each pixel, the amount of memory that's needed for a graphics screen, quickly goes out of hand (320x200 pixels in monochrome is almost 8KB). Texas Instruments solved this by developing the TMS9918 which was already mentioned by Martin_H and cbmeeks. It's sort of a compromise between all the methods above. The video controller takes care of generating text or graphics in color, and even refreshes dynamic RAM that stores the pixels. You use commands to make the video controller write text to the screen or draw pictures.
Anyway, back to the L-Star and the Propeller. On L-Star, the Propeller is connected to the 6502 with 26(!) pins: 16 for the address bus, 8 for the data bus, one for the clock and one for R/!W. That only leaves a few pins available for the serial port (which is needed to download the Propeller firmware), the I2C port (which is used to control the EEPROM that holds the Propeller firmware and, optionally, other stuff), and other I/O. Because of this, the L-Star can currently only generate monochrome video, and it uses a trick to generate 3 levels on a binary output pin, which is a problem with some (most?) LCD monitors.
I have plans to design an expansion board that will have color video, based on the Propeller or something else. The basic VGA configuration for the Propeller uses 8 pins, and in NTSC or PAL mode it uses 3 pins. I'm not sure how I'll do this and I don't want to make any promises I can't keep, so that's all I want to say about that for now.
I've also been thinking of the possibility of designing a Teletext encoder (that's an ENcoder, not DEcoder), not for the L-Star project but as a separate proejct. Most TV's in Europe from the late 1980s and early 1990s have a Teletext decoder which uses digital information from a video signal to generate a screen with 40x23 characters of 7 color text and (blocky) graphics. The BBC computer and the Philips P2000 also had Teletext fonts. It should be relatively simple with a modern microcontroller such as the Propeller to generate the Teletext video signal that those TV's can use. It would only take one or two pins; the only problem is that the Propeller doesn't have much internal memory...
===Jac
Login
Register
FAQ
Search
