Saturday, May 24, 2014

VCSMC - A Media Player for the Atari 2600

I recently resigned from my position as Technical Lead of the Game Consoles team at YouTube. I loved my time there, I spent 3 years in that role and built the team from 2 people to 12 while working on various game consoles, old and new.

When my wife and I purchased a home in the Santa Cruz mountains, however, I knew that my days of commuting to San Bruno were numbered. So I had to resign that position and move to Mountain View to work on Google Chrome for Windows.

As a parting gift my manger gave me an Atari 2600 console which he had customized with the YouTube logo and colors. A long-standing pipe dream on my team while developing on other game consoles had been that we would eventually port our work to the Atari. The painstaking care that he had taken in building this console was really touching. It made me think, why not try to develop a media player for it? And thus the dream was born. I've been working hard on the project for over a month now so I figured it was time to (briefly) lift my head up from the code and talk a little about my design, plans, progress, and next steps.

Please understand that I am doing this on my spare time and on my own personal computer hardware, outside of the context of Google Inc and YouTube. As with all content on this blog my actions, thoughts, and opinions expressed here are mine alone and in no way represent the policy or plans of my employer. All trademarks and copyrights are owned by their respective owners.


When studying the Atari 2600 Video Computer System (VCS) hardware it quickly became apparent that my original vision of porting enough of a web browser to render the YouTube HTML5 TV client was probably beyond the scope of work that I could accomplish in the space of a couple of months in my free time. Additionally, there's a rich homebrew scene for the Atari 2600 and one of the primary aesthetics of it is a real respect for the capabilities of the hardware and not trying to exceed that or expand it, but rather to use it creatively to create the best experience possible within those constraints.

My plan now is to develop an Atari 2600 program that can render arbitrarily long video content. This content has been preprocessed by a few host computer programs that convert input still images and sound into 6502 bytecode, largely instructions to the Atari to manipulate the TIA state machine to generate the resultant output. I call this suite of host computer programs, and the Atari cartridge rendering software VCSMC, in joking homage to the excellent XBMC.

I preprocess a video using ffmpeg to demultiplex the audio and individual image frames. Each frame is processed by a program I am calling picc, short for picture compiler. Most of my development effort has been focused here so far, I am saving sound work for later. The sound compiler program would logically be called sndc. The output of picc is asssembly code or 6502 binary bytecode that when executed on a VCS renders an individual frame. A final program called ldav will link the individual frame codes with the audio code into a single binary blob usable by the host console program.

This is where I have allowed one concession to myself for modernity - I am placing no limits whatsoever on code size. Original VCS programs where limited to 4 kilobytes of program size. Several bank-switching tricks emerged during the product life span of the VCS which pushed that number as high as 8 or even 16K. Homebrew developers have subsequently devised new bank-switching strategies that can push ROM size to 32K (with DPC+or even 64K on simulators (like 4A50).

While I could allow some restrictions on code size this would ultimately result in making additional sacrifices with the quality of the image rendered. As I am already losing a lot of capability when trying to render complex imagery at 60 frames per second on the Atari I didn't want to have to worry about losing even more. Plus even with the most extreme compression and loss of quality imaginable I calculate that making the entire program fit into ROM size restrictions would only allow for a few seconds of video. 

Since I want to push the graphics capability of the VCS to its very limit I want to be able to use every instruction available on every scan line. Assuming an average storage cost of 1 byte per machine cycle that means a single frame is over 13K! My plan is to modify an existing or build-alike something similar to the Harmony Cartridge that will allow for arbitrary simple program size. There is one catch, of course, which is that these programs can't jump or call subroutines without great dificulty, but this is not a problem for my design as it is essentially streaming video and audio, so doesn't need to do any branches. This means that ldav will most likely output a simple blob format that a runtime program will be able to provide to the appropriate banks for 6502 execution at runtime.

That pretty much sums up my overall approach to the problem. Feel free to check out the code on GitHub. I'll talk more about my progress rendering video content in subsequent posts. Happy hacking!

No comments:

Post a Comment