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:
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.
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.
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.
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!
