Crispy

I've been working on this project off and on (mostly off) since 2010. It's still a work in progress, but it's far enough along now that I feel comfortable in sharing it. The original goal of the project was to recreate an Atari 2600 in an FPGA, but as things progressed the project goals became more ambitious. What I ended up with is an FPGA based Atari 2600 that uses HDMI instead of RF for its television interface, and USB for a slew of implemented and planned features, all wrapped up in an enclosure that is styled to resemble a Walkman. For those who are interested, I wrote the RIOT and TIA cores in Verilog from scratch, and used the FPGA Arcade branch of Daniel Wallner's "T65" 6502 CPU core. Special thanks to Mike Johnson and Wolfgang Scherr over at FPGA Arcade (www.fpgaarcade.com) for updating the T65 core, and for sharing their work. Features Atari 2600 hardware faithfully recreated in an FPGA. HDMI video/audio output for connecting to modern TVs. Analog audio line output for use when connecting to a DVI monitor that doesn't have sound. Full support for most Atari 2600 peripherals. Enclosure styled to resemble a Walkman for total immersion in nostalgia. Pause button that will freeze the game for those times when you need to take a break. USB connector for upgrading the firmware, and also for a multi-protocol communications bus. Test pattern generator that can be used to aid in adjusting your TV settings. Planned Features Capture screen shots to FLASH, and then transfer to a PC via USB. Capture live game video and audio to a PC via USB. Save and recall machine states. PAL timing and palette. Wish List Complete debugging/monitor environment on PC via USB with flexible user specified triggering for trapping any hardware condition. Other things I have yet to think of. Specifications HDMI Video Formats 640 x 480 @ 59.94 Hz 800 x 600 @ 59.94 Hz 1024 x 768 @ 59.94 Hz 1280 x 720p @ 59.94 Hz 1600 x 1200 @ 59.94 Hz 1920 x 1080p @ 59.94 Hz 1920 x 1200 @ 59.94 Hz Audio Formats48 KHz linear PCM, 2 channels Analog Audio 940 mV P-P into 47K ohms 360 mV P-P into 600 ohms Test Patterns H Ramp V Ramp H grayscale bars V grayscale bars 100% color bars 75% pseudo SMPTE color bars 16 x 16 cross hatch H burst Photos View of the rear side: HDMI and joystick connectors. Another view of the rear side. View of the left side: buttons, USB connector, B&W/Color switch, left and right difficulty switches. Another view of the left side. Top down view of the main PCB. All ready to go. Just press PLAY.

A quick check here shows that the video is stable on my hardware.

Yes, there is definitely a lot of vertical jitter when playing this game on real hardware. The jitter appears to be confined to the playfield area because the lines used to display the score at the bottom of the screen are stable. The black lines above and below the green area where the "Doom Patrol" logo is drawn jitter slowly, with the bottom line faster and more frequent than the top. The gradient near the bottom of the playfield has the most jitter. It bounces up and down very quickly and frequently. It appears the the jitter accumulates from top to bottom. I looked at the syncs on a scope, and your vertical timing is stable, so your cycle count from frame to frame must be constant. I just tried the game on Stella, and it's perfectly stable, which kind of surprises me. I don't recall ever having seen any differences between Stella and real hardware in the past.

I stumbled across the Suncom Slik Stik years ago at a Toys R Us, and have been using them ever since. Brand new, out of the box, they are the most responsive, best feeling joysticks I have ever used. Unfortunately, they get rather sloppy after a couple of months of use. I wish I would have bought a couple hundred of them when they were still being made.

High Score: 2276 I shouldn't have had that after dinner mint, even if it was waffer thin.

High Score: 11321 Excellent game! Good level design and responsive controls. Very fun. I can't say the same for Springer.

Wow, really? It's a 60 second clip from a 45 minute TV show used to illustrate a question posted in a public forum. How is that going to drive Universal to financial ruin?

I caught this while watching an episode of Airwolf from the box set I just acquired. https://youtu.be/JhdoLq-BECQ Thanks Universal. My guess is Atari 5200. Let's try this with a different approach. http://www.orangetreehosting.com/~crispy/video/admiral_pacman.mp4

Bonus - The rising (or setting) sun in Seawolf.

Score: 1518 I would have tried for a higher score, but my inner video game critic won't allow me to play this game again.

That's a good idea, but not without a couple of drawbacks. First, because of the large capacitance on the line, I would have to use a small value resistor in order to get a reasonable rise time. If I chose 330 ohms, then the rise time would be about 23 us, which is pretty slow. I don't like driving logic with such long rise times, so I'd definitely want to run it through a Schmitt trigger before it hits the clear input of the counter. The other concern is the high current due to the small value pull-up resistor. If the pull-down FET in the TIA has an on resistance of a few ohms, then the current through the resistor is a little over 15 mA when the FET is on. I know it's not a big deal, but I usually like to keep the current in pull-up circuits in the 1 mA range. On the upside, it reduces the component count in the design. Using the dump signal from the TIA would remove the need for the octal open-collector buffer and the two quad AND gate chips that the current design uses. I'd like to know more about this. I believe it would. I think in the case of paddles you would want to use an 8-bit counter instead of a 4-bit counter in order to get a reasonable sample of the paddle position. Going with Alex's suggestion, the dump line could be used to select between the upper and lower nibbles of the 8-bit word. Doing this would provide the ability to read an 8-bit value over the 4 bits on one joystick port, and would allow for supporting two paddles.

It's unfortunate that many of the games that would benefit from trackball control are designed to use the joystick instead, and there's a good reason for this. Polling the trackball requires a huge amount of CPU time. In order to get an accurate picture of what the trackball is doing, it has to be polled every few scan lines, and preferably, every scan line. Doing this incurs a lot of overhead, and would simply be impossible to implement in a game that employs a lot of graphical embellishment. I started thinking about this subject the other night when I was getting annoyed by the sluggish response of the joystick control in Centipede. At first I was looking for a way to improve the joystick response in Centipede, which I found, and then a thought occurred to me. If the trackball polling can be offloaded to external hardware, a lot of games that could benefit from trackball control would be able to have it. My first idea was to design a cartridge that includes the polling hardware and a connector for the trackball on the cartridge itself. I still like this idea, but I came up with another one that I implemented as a proof of concept. Using one of my FPGA dev boards that I had laying around, I created a design that polls the trackball, and then outputs the results to the two joystick connectors on the 2600. The drawback with this design is that it uses both joystick ports which makes it possible to plug in only one trackball. Theory of operation The method described here for polling the trackball only works with trackballs that use the CX-22 type of signaling. Fortunately both of my CX-80 trackballs fall into this category. The idea is fairly straight forward. The signals from the trackball drives two 4-bit counters: one for the X axis, and one for the Y axis. The pulse train from pins 2 and 4 of the trackball connector drive the clock inputs of the two counters, and the direction signals from pins 1 and 3 are used to determine whether the counters count up or down. The outputs from the two counters are fed into the two joystick connectors on the 2600, and these values are read by software from address $280 once every frame during blanking. The 4-bit values are formatted as two's-complement signed numbers, and indicate the number of trackball ticks that have occured since the last time the counters were read. A negative value indictes that the trackball was moving left or up, and a positive value indicates rightward or downward movement. The counters are cleared by setting the joystick port pins as outputs, and then writing a $00 to $280. From there it's up to the game designer to decide what to do with the count values read from the joystick ports. As I mentioned earlier, my current design is implemented in an FPGA, but this solution is much too expensive for this type of product. Instead, this design could be implemented with a handful of discrete logic, or even a PLD. For those who are interested, I have a video on Youtube that demonstrates my hardware with a hacked version of Centipede. https://www.youtube.com/watch?v=C59hY8XhsfY I'm not sure how much interest there would be in a product like this, so for now I'm just treating as a fun exercise in interfacing to the 2600.

Looks good. The AD9984A is a good choice for the video ADC, and the ADV751x is really the only reasonable HDMI solution out there right now. Is there some reason you went with Lattice instead of Xilinx? I really like the Spartan 6, but then again I haven't looked at Lattice or Altera in a long time.

It looks like the OP's question has been answered, but just to add to the discussion, Centipede uses STA to do its bank switching. It made me nervous when I first discovered what they were doing, but apparently it's OK since I haven't heard of masses of 2600 consoles melting down into piles of sculptured plastic after running Centipede.

I'm not sure if the pixel clock frequency is different between PAL and NTSC systems. If so, then you will have to replace the crystal on your board with with a 3.579545 MHz crystal. I was going to suggest looking at the frequency marked on the crystal, but I just looked at the one on my NTSC board, and it is stamped with a manufacturer part number instead of the crystal frequency.