Nintendo DS Screenshots / Video Capture

It's not a fpga solution, but I think there are a number of PC emulators, of these game consoles. Using a PC emulator, would give a simple way to capture screens.

If you do want a HW path, you will need access to an oscilloscope, to check the details, but a FPGA+Memory would certainly have the horsepower to do this.

-jg

If you look at the project page, you'll see that the Neal used a Spartan

3 Starter Kit, available from Xilinx for $149 (same price as the Spartan 3E Starter Kit). Or, you can buy the Spartan 3 Starter Kit direct from the manufacturer for $99 - for some reason Xilinx raised their price, which used to be $99. I suspect they are trying to move folks to the newer 3E parts.

For a newbie such as yourself (or even an oldie like me) and a project such as this, I highly recommend the S3 kit over the S3E kit, for a number of reasons.

1. The expansion connectors on the S3 are standard 0.1 inch pitch headers, while the S3E board uses a Hirose fine pitch connector for most of the FPGA I/O. There are some 6-pin 0.1 inch connectors on the 3E board, but the total number of I/O available on these connectors is a small fraction of the FPGA I/O. It is much easier for a hobbyist (or even a professional) to connect stuff to the 0.1 inch headers.
2. The RAM on the S3 board is SRAM, while the S3E board only has DDR2 SDRAM. It is orders of magnitude easier to implement a frame buffer (which you will need for your project) in SRAM than DDR2 DRAM. The DDR2 requires a controller, while the POSR (Plain Old Static RAM) just requires you to hook up the address and data lines.
3. The LED display one the S3 board is very easy to use, while the LCD on the S3E requires more circuitry to initialize and send data to the display. The only thing you need for the LED display is some matrix scanning code, which is provided by Xilinx in their demo code (which is written in VHDL, not verilog). The LED display is very handy for debugging.
4. The S3 board has 8 slide switches and 4 pushbutton switches for general use, while the S3E board primarily uses a rotary encoder which needs to be decoded. Switches are also great for debugging and changing operating modes easily.

Here's the link to Digilent page for the S3 kit.

For the S3 board, all you need for connectivity are breakaway male header strips, which are quite inexpensive and readily available. These will plug directly into the S3 I/O connectors. TIP: Buy header strips where the pins are extra long, which will making probing the signals easier.

and pop the RGB + DCLK + VSYNC

I suspect the signal levels at the DS are 2.5V or 3.3V. Since you are only receiving signals at the FPGA, you can set the input standard to LVTTL and you should be fine.

You definitely need GNDs, and preferably more than one.

I'm not a verilog person, but here's the basic functional flow.

1. Implement a counter with a count length of 263 (counts from 0 to

262). This will be used to determine the horizontal position of the pixels.

1. Detect either the rising or falling edge of VSYNC - pick one and only one edge.
2. Use the detected VSYNC edge to load your horizontal counter with a specific value, initially to zero. If your image is shifted horizontally after you grab a frame, then adjust this preload value to get the image properly horizontally positioned.
3. Implement a second counter which keeps track of the line number of the screen image. Clear this counter with the detected VSYNC edge generate in step 2.
4. Increment the vertical counter from step 4 whenever the horizontal counter value is 262 (max count).

After you sample the data, you have to do something with it. In this case, you need to write it to the S3 SRAM. The SRAM is 32 bits wide, and the LCD data is 18 bits (based upon the Sharp data sheet provided on Neal's project page). So, one pixel will fit, with room to spare, in a single 32 bit SRAM word.

The next question is, to which address in SRAM should it be written? Now is where we will use our horizontal and vertical counters.

The easiest thing to do is to concatenate the counters to form the SRAM address. This will waste a lot of the memory, because the horizontal counter has a max value of 262.

Why? Because you must use 9 bits of address to count up to 262, and the space between counts 263 through 511 will be unused. But, who cares - you have plenty of RAM so don't worry about it. But, your software will have to know where to find the 256 pixels (out of the 512 allocated memory words) for each line of the image. You can make this easier by selecting the preload value in step 3 so that the 256 pixels of the image are in the first or last 256 of the 512 locations.

If you want to simplify the code (not by much, though) in step 3, you can clear the counter instead of preloading it. Then, your software can read the SRAM and unwind the data. This is a classic tradeoff of whether a part of the functionality should be implemented in software or hardware. In this case, the hardware cost is minimal. But, in 1980, there was difference in price - in dollars and pin count - between a TTL counter chip with clear only, and a TTL counter chip with preload.

By convention, the horizontal counter is usually connected to the lower order address bits, although it is not required. Maintaining this convention, the SRAM address bits would be connected to the counters as follows.

A A A A A A A A A A A A A A A A A SRAM

1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | V V V V V V V V H H H H H H H H H COUNTERS 7 6 5 4 3 2 1 0 8 7 6 5 4 3 2 1 0

This should allow you to capture the screen data. So, you'll need to add some way (using a PB switch, maybe) to trigger the screen capture. Or, you could detect activity on the serial port to trigger the capture.

After the capture is finished, you'll need to dump the data out of the S3 board to your PC. The serial port is probably the easiest way to do this. You can leave all of your counters that you used in your capture process connected. Just switch the clock and VSYNC counter inputs from the DS signals to an internal set that first generates a psuedo VSYNC, then generates a clock after each pixel has been transferred over the serial port. Note that since each pixel is only 6 bits, you can send a pixel to the PC using 3 consecutive bytes.

The author of the page already mentioned points out that

I hope I didn't spoil you project by giving too much info.

Urbite

Nintendo DS emulation is still in relative infancy, with only a handful of commercial games running - and rather poorly at that. You also need to acquire additional "grey" hardware to dump the roms or source some pirate copies... :(

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, 
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

First of all thanks for all the great advice I've got thusfar, quite outstanding!

Jim, I had already tried the emulation route and as Mark has already pointed out the emulators really are not of a standard that makes it worthwhile. As for not being an FPGA project I only have this page...

as ANY sort of guide to doing something similar. The thought process really is that if Neal is almost able to do what I'm trying to do then maybe some similar equipment is not a bad idea! That siad I'd love to hear how an earth I'd even think of approaching this say with a PIC chip or similar???? Remember, electronics noob alert!

Austin, I read your post in complete fear lol I see I have a LOT to learn here but I'm commited and if it takes some serious book reading and playing then I will do so, thank you very much for taking the time to give me some information! In fact I almost relish it in a strange way as its like jumping back in time and going back to writing 68k assembly code for the Atari St and Amiga. All right I know its different but its certainly good to get hands 'dirty' so to speak as I've become lazy as a .NET developer. I still remember my old VSYNC code for the Atari ST and the little tricks you could pull to get rid of that annoying border at the bottom and top of the screen, ahhh bliss!

Urbrite, thank you for your excellent advice and information. Again, I see there is a lot to learn here but you have answered a lot of the odd questions.

One thing I'm really quite worried about is blowing up the board or Nintendo DS cause I've done something stupid with how I connect them both. I envisage something like this....

Nintendo DS (Soldered wires on PCB) Spartan 3 Board

Red [0-5] ---->

A book that is not too tough to get through, and is a golden reference on the subject:

"High Speed Digital Design: A Handbook of Black Magic" by Howard Johnson

I highly recommend it to anyone, hobbiest or professional, who ever has to connect more than two wires together (and expect them to work).

Once you get the wires connected, programming the FPGA to capture the data is the next hurdle, but one that is more "software" than "hardware."

Screw up the "software" and you just change the verilog, or VHDL code, and make a new bitstream.

Screw up the hardware, and you are chasing gremlins potentially forever.

For a reasonable reference (there are hundreds) on writing VHDL or verilog for FPGAs,

"FPGA Prototyping by VHDL Examples" or "FPGA Prototyping by Verilog Examples" by Chiu (he has a series of books that solve problems in VHDL, and then identically in another book, in verilog)

He also uses the Digilent Spartan 3 boards to do all the examples.

I would buy the books, and read them FIRST, and then get the appropriate Spartan 3 board. You could also write the VHDL, or verilog, simulate it, and test the code before you even have the Spartan 3 board using the Xilinx (free) Webpack software.

Austin

There's something close to a rite of passage in writing a Hello World on each new system. Lighting an LED and making it spin with an encoder wheel sounds about right for embedded stuff. ;)

I can heartily second the recommendation for Chiu's book. The pace is right for someone with some software and a little digital background. Even so, there's a tendency to not notice the full importance of some concepts in the understandable rush to expand your language "vocabulary." Respecting the need for a clock would have saved me a few headaches early on.

I'd venture to make a further suggestion along these lines. What you want to achieve isn't exactly noob stuff - there's a reasonably steep learning curve ahead. As such I'd suggest...

• Buy your FPGA starter board but don't connect it to anything!

• Lighting a LED is a pretty good start

• You need to familiarise yourself with video generation before you start sampling and regenerating other sources. I'd suggest you play around with generating some VGA video on the board itself - emulation of a simple bit-mapped arcade game (Space Invaders) would be a good start and there's plenty of examples to get you started.

• Once you've "mastered" video generation, then you can start looking at connecting to the DS and sampling video. For extra credit:

• Write your own ARM cores and emulate the DS in the FPGA itself, doing away with the need to sample video! ;)

That should keep you busy for the best part of a week! :P

Just my AUD$0.02 worth...

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, 
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Thanks again for all your responses. I'm always amazed at the help available and the time people put in to help others it really is appriciated. Yes, books it is, some orders for them already made on Amazon. Just installing the ISE suite to start 'playing' there and yes, I think your all totally right, LED's and Hello Worlds are the order of the day for now! lol @ Mark, when I write the ARM9 cores and the relevant emulation code I'll be sure to upload it and tell the world !!!! :) :) :)

Thanks again chaps I'll keep you all updated so you can have a good chuckle at watching a noob stratch his head and do lots of stupid things :)!!!!!

Actually the simplest thing to do may be to do a one-dimensional recording of as many bits as will fit in the SRAM, triggered by the vsync. Dump the whole thing over the serial port and sort it out with software on the PC where you can more easily see what you are doing. If this proves to be inadequate, you can then re-design the fpga logic to do a more targeted aquisition based on what you've learned. For example, if there's a lot of dead time between lines (it's not a CRT with a beam that needs to retrace, but I suppose this could still occur) you'd be wasting memory recording that, but you might still have enough.

I'd build a circuit that's 'armed' by any activity on the RS232 RxD line, is 'triggered' by the VSYNC, and once it's data is available dumps all of it over the RS232 TxD. You can find example RS232 transmitters online, and in this case you don't need a real receiver in the fpga, just something that you can arm by having your computer send an arbitrary character to it, after which it will reply with the next available frame.