This year I've been working on a design for a 6502-based game console. I'm targeting a whole list of (admittedly arbitrary) requirements including sounds, custom controllers, cartridges, and most importantly... color composite video. In addition, I'm trying to stick to parts still being made today (for reproducibility), and avoid black-box programmable components (for educational/challenge value, and not counting cartridge ROMs).

I recently hit a technical milestone I'm very excited about, but for the sake of context it seems prudent to start the story from the prototypes I did in the Winter/Spring. To cover, like, what kinds of problems I already ran into and learning that had to happen along the way.

I started by studying the schematics to the original arcade Pong to generate sync signals, then diverged to use the sync counters as addresses and feed the contents of an EEPROM through a shift register to output a black and white image on a TV screen:

The circuit used a 28C64 (64 kbit) EEPROM for image storage as a stand-in for the dual-port RAM I'll eventually use. The image format was 1bpp 256x256 bitmap, which can be exported from Photoshop and de-headered with a simple script.

This was maybe like the third PCB I had ever designed, which is the excuse I now give for the flaws such as missing bypass caps and wacky traces. The circuit design itself also had the flaw that I was starting reading each row of memory at HSync, leaving the first several columns off-screen. I compensated by moving the image to the right, with wrap-around, and wiring the address pins so that the image would repeat horizontally. This roughly centered the image on screen, but showed extra tiling on the sides.
I next designed a version that tested out my ideas for a cartridge pinout. (Though without yet tackling the image positioning)
The circuit is mostly the same, but I forgot the autorouter and remembered the bypass caps.

On a whim I had included certain, er, subtle design flourishes on the shell. It was shortly afterward I started calling my project the "GameTank"


Following this prototype I set video aside for a bit to work on address decoding and audio. But those will get separate a separate post.
During the last couple of months I had returned to video, with renewed obsession. Thinking about addressing made me think about what kind of memory I was going to use; and thinking about memory had me thinking in a more concrete way what kind of image specs I would target. I really wanted to add color, and to have more than one color. This ruled out 1bpp. I would have to either decrease resolution or increase memory. For a while I thought that I was going to do 2bpp and have four colors. I even made space for four palette registers in my memory map.
However, I decided that dealing with multiple pixels in a byte would introduce more overhead than I really wanted to contend with. Plus, I also had some DMA ideas brewing that I'll get into later. So ultimately I decided to go with 8bpp, and 128x128 resolution.

Simultaneous with the memory thinking, I also considered how to generate the color carrier. I learned that the color part of a composite signal is controlled by a 3.58MHz wave concurrent with the brightness information. That the TV set expects a short "burst" of this signal just after HSync, and that it compares the phase of the carrier to the burst to determine the hue.
I read somewhere, though I can't find the source, that the NES generates its colors in the HSL composite domain rather than RGB, and it does this by clocking a shift register at 8x the color carrier frequency. This is the approach I ended up taking.



I rebuilt my monochrome video breadboard as a starting point. The new parts included a 28Mhz oscillator to replace the previous 14Mhz, a shift register, and an 8-way selector/multiplexer. The 28Mhz square wave clocked the shift register, and a 3.5Mhz division was used as the data. By changing the select bits on the multiplexer, I was successfully able to choose from eight phases. After some analog trial-and-error with resistors and opamps, I convinced the TV that this was indeed a color video signal.

This pattern isn't just for being fancy, either. Between a pair of resistor-ladder DACs and the multiplexer, I had 3 bits for each of Hue and Luminosity; as well as 2 bits for saturation. By hooking these control bits up to the sync counters I could cycle through all possible values, and continue fiddling with resistors until I was satisfied with the range of colors. This small dashboard screen for backup cams was also the most temperamental of all the screens I'd tested on, so it made a good baseline for compatibility.

Finally, my most recent addition has been to connect a ROM and take a swing at the image positioning problem I had before. I connected two more 4040 counters on an additional breadboard, which followed the same clock as the sync counters but used HBlanking and VBlanking as their reset signals. This way their counts would be zero until reaching the "picture" part of the screen. Or at least a lot closer to it.

At first I thought I was going to have to write a custom converter to put photos into my hardware's 3:2:3 Hue-Saturation-Luminosity format. However, by generating a color table file I was able to leverage Photoshop once again. When converting an image to Indexed Color, Photoshop looks at each of the original pixels and finds the closest matching color in a provided table. This pixel gets saved to file as a single byte, normally interpreted as the index of the color in the table. Thus I generated a colors file containing the colors my board could display, ordered such that each one's index matched its HSL representation.
Currently the image only puts 80-ish pixels on the screen horizontally and 60-ish vertically. When I get home I next want to try shifting the horizontal address counter up by 8 to the 28Mhz and then back down by 5 with a 74HC161 in div-by-N configuration to get the image to more closely align to the screen.
After that I'll do a test with dual-port RAM then start prototyping the DMA scheme I alluded to earlier. Essentially I'm hoping to set off memory transfers between VRAM and a dedicated Graphics RAM bank that run independently of the 6502, transfer rectangles instead of contiguous memory ranges, and transfers at 1-2 cycles per byte instead of the cycles it takes for the CPU to fetch instructions, load and store registers, and perform loop comparisons. But that feels like a writeup for a separate post.

Thanks for reading!

Aw geez I didn't realize the images would get blown up so big. :O

My plane is about to take off so I can't fix this immediately, but I can hopefully do it during my layover in about an hour...

On this forum you're allowed to attach images with your post. This eliminates the need to use a third-party site such as Imgur. And, forum software will automatically provide a reduced-size preview.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Yes, please reduce them to something like 800 dots across. Thanks.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I had uploaded these already and thought I could save a few seconds. That's what happens when I combine lazy and hasty!



Got it!

Been reading through your 6502 Primer a lot, by the way. It's been very helpful to my planning this project, reasoning about the 6502 bus, and trying to design these peripherals. So also a very big thank you for writing all that up and sharing that knowledge!

You're welcome. There would be even quite a lot more material on the site if time were no object. The site has been there for 7½ years, and I wrote a few of the major features years before I even had a site to post them on. I can't promise to double it in the next 7½, but I'll do what I can. I do regularly do small edits on what's there. I'd also like to offer more modules. It's all a not-for-profit effort to promote the interest. The last I checked, visitors were doing close to to a thousand page downloads per day. I wrote the material on the site at times when my work was slow, which it definitely has not been in the last couple of years. And thanks for the picture edit.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Agumander, nice work.

When I did monochrome video with TTL, I had cheated by generating the display address and the sync signals by using a lookup table in an EPROM.

Three things had bloated my design a bit:
Being able to drive a CRT plus a LCD in parallel, a mixed text plus graphics mode,
and getting around using dual port RAM by snooping the 6502 bus for write cycles to $0400..$07FFF to be "mirrored" into the display RAM.

Didn't know as much about the 6502 bus timing as I know now, and passively snooping the bus for writes won't work well with a 65816.

Looking forward to watching the progress of your project.

Had some success re-aligning the image horizontally by using a 161 to scale the pixel clock, and another to pulse the reset line of my X address counter just before the start of the visible screen region. For now I’ve got the leftmost image pixels repeated for a few columns at the start of the scan line, and 2-3 columns on the right that repeat the image.
I think I’d rather have all 128x128 addressable pixels be on screen than try to eliminate visible borders. The stretched edge pixels are kind of cool, so I’ll try to fix the right side border to match.

I’ve also got a few more rows lost to the top and bottom of the screen than I’d like... 36 scans above and 20 below. Though since scan lines are a discrete quantity there might not be much I can do about it. Each pixel will occupy two scanlines, so that’s a total of 28 pixels lost in vertical resolution. Given how close to square my pixels ended up so far I think I can live with 128x100.

(Edit: The previous prism image may *look* aligned, but that's because I manually shifted the padding in Photoshop. The cat image attached to this post has better horizontal resolution, by about 30 pixels)

Picture looks 99% the same today, but I did want to post that I did indeed get the right side border to match the left instead of starting to repeat the row of pixels.
From the 4040 counter used to generate the lower 7 address bits, I connected the next highest bit to an unused NAND gate to invert it, and then to the 161 that scales the pixel clock.

For the moment this solves the problem without adding any additional ICs, but it does mean that the right border matches the left *exactly* instead of matching in the sense that it stretches the rightmost image column.
Using an 8-input NAND should stop it a column earlier. Not sure just how badly I want separate control over the side border colors.

The current configuration is arguably 127x100 + a byte on each row that decides border color. If I add the 8NAND I'll essentially have 126x100 + two byes per row for the left/right border colors.

I've finally prepared a schematic for this video board. This sheet, unlike the breadboard, uses a dual-ported RAM.
The other port of the RAM module will be controlled by my DMA project, so once I've hammered out the details with that I'll order a board and hopefully see an improvement in signal stability.