Nintendo DS Screenshots / Video Capture
adwor...@r720.co.uk
I'm starting to look at building something that will allow me to take
screenshots and do video capture of both of the Nintendo DS screens.
Amazingly there is actually nothing available that you can buy to do
this (publically anyway), so why not build it!
I knew I was onto something when I found this...
http://home.comcast.net/~olimar/DS/jumbotron/ That was enough to prove
to me that if the creator of that is able to grab a screenie so am I
(in theory )! Unfortunaltly the creator is either not picking up mails
from that address or is being hammered with similar questions and is
not responding which leaves a noob like me a bit lost....
Anyway, undetered I'd like to capture a screenshot from one screen and
squirt it through an RS232 connection where I can have a simple home
made .NET app listening (I'm a .NET developer in the day ) to create a
simple *.bmp or similar.
I've been eyeing up the Diligent Spartan 3E Starter Board to help out
with the project as it has a few handy bits already onboard (namely
RS232, VGA (3 bit only I think?) for some simple downsampled ouput and
some memory to buffer a frame should I need to).
I've isolated the RGB (6 bit each) solder points and found the VSYNC
and DCLK (data sampling clock?) solder points as well. According to
the page I've found I can simply count the clocks (263 exactly) to
find the HSYNC.
For reference heres a link to the specs of an LCD that is appently
very close to the Nintendo DS ones... http://www.sharpsma.com/Page.aspx/americas/en/part/LQ030B7DD01/
However, I am a total noob (both FPGA + General electronics) and I
have some basic questions before proceeding if anybody can help
(crosses fingers! )
1. I'm guessing I just buy the 100 pin breadboard module for the
Diligent Spartan 3E Starter Board and pop the RGB + DCLK + VSYNC
straight into it? Do I need to check the voltage first or anything to
make sure its safe? Will I need to put a ground pin in as theres a GRD
solder point on the Nintendo DS PCB?
2. When 'counting clocks' for the HSYNC I'm assuming the author of the
page already mentioned was talking about counting the clocks of the
DCLK, agree? How would I go about that in Verilog?
3. To build up the frame of data do I just sample the RBG pins every
clock cycle? The author of the page already mentioned points out that
the bottom screen is read on the rising clock edge and the top on the
falling, how do I go about sampling on each edge?
If theres ANY other advice you have PLEASE do mention it. Good book
etc are always welcome...
Pete
austin
First, you need a common reference between the boards (a "ground") so
that they both know what is expected of them.
Next, you need to know what the logic voltage levels are: LVCMOS, HSTL,
SSTL, What? Are they "rail to rail" (and if so, is that 0 to 3.3
volts? or 0 to 2.5 volts?). This assumes everything is single-ended.
If differential, then forget it (too many signal integrity issues ...
see below).
Then, you need some way to get the signals from point A (the source) to
point B (the sink). This is likely to be a ribbon cable, arranged as
signal, ground, signal, ground, signal, ground...and so on (basically a
whole bunch of 50 ohm transmission lines between source and sink).
The Vcco for the Spartan IO bank that is the sink (receives these
signals) has to be the same voltage as was used to send them (3.3V,
2.5V, 1.8V, or 1.5V).
The IO standard used on the inputs must be one that will "hear" the
signals coming down the cable. I would start with LVCMOS, only because
for a single ended output, it is pretty basic, and usually works.
Now that you have a chance of having the signals get from A to B, find a
clock in A that you can use to sync everything at B, and send it over there.
If attaching the cable breaks the source, then there are signal
integrity issues (loading, and/or reflections), and the problem is
harder as you will need a set of buffers right at A to isolate and drive
the cable to B.
Synchronous design is what you need, asynchronous design using FPGAs is
just masochism (and will only result in tears).
Just the hardware,
Austin
Jim Granville
> Hi All,
>
> I'm starting to look at building something that will allow me to take
> screenshots and do video capture of both of the Nintendo DS screens.
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
Paul Urbanus
> Hi All,
>
> I'm starting to look at building something that will allow me to take
> screenshots and do video capture of both of the Nintendo DS screens.
>
> Amazingly there is actually nothing available that you can buy to do
> this (publically anyway), so why not build it!
>
> I knew I was onto something when I found this...
> http://home.comcast.net/~olimar/DS/jumbotron/ That was enough to prove
> to me that if the creator of that is able to grab a screenie so am I
> (in theory )! Unfortunaltly the creator is either not picking up mails
> from that address or is being hammered with similar questions and is
> not responding which leaves a noob like me a bit lost....
>
> Anyway, undetered I'd like to capture a screenshot from one screen and
> squirt it through an RS232 connection where I can have a simple home
> made .NET app listening (I'm a .NET developer in the day ) to create a
> simple *.bmp or similar.
>
> I've been eyeing up the Diligent Spartan 3E Starter Board to help out
> with the project as it has a few handy bits already onboard (namely
> RS232, VGA (3 bit only I think?) for some simple downsampled ouput and
> some memory to buffer a frame should I need to).
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.
http://www.digilentinc.com/Products/Detail.cfm?Prod=S3BOARD&Nav1=Products&Nav2=Programmable
>
> I've isolated the RGB (6 bit each) solder points and found the VSYNC
> and DCLK (data sampling clock?) solder points as well. According to
> the page I've found I can simply count the clocks (263 exactly) to
> find the HSYNC.
>
> For reference heres a link to the specs of an LCD that is appently
> very close to the Nintendo DS ones... http://www.sharpsma.com/Page.aspx/americas/en/part/LQ030B7DD01/
>
> However, I am a total noob (both FPGA + General electronics) and I
> have some basic questions before proceeding if anybody can help
> (crosses fingers! )
>
> 1. I'm guessing I just buy the 100 pin breadboard module for the
> Diligent Spartan 3E Starter Board
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
> straight into it? Do I need to check the voltage first or anything to
> make sure its safe? Will I need to put a ground pin in as theres a GRD
> solder point on the Nintendo DS PCB?
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.
>
> 2. When 'counting clocks' for the HSYNC I'm assuming the author of the
> page already mentioned was talking about counting the clocks of the
> DCLK, agree? How would I go about that in Verilog?
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.
2. Detect either the rising or falling edge of VSYNC - pick one and only
one edge.
3. 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.
4. 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.
5. Increment the vertical counter from step 4 whenever the horizontal
counter value is 262 (max count).
>
> 3. To build up the frame of data do I just sample the RBG pins every
> clock cycle?
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
> the bottom screen is read on the rising clock edge and the top on the
> falling, how do I go about sampling on each edge?
>
> If theres ANY other advice you have PLEASE do mention it. Good book
> etc are always welcome...
I hope I didn't spoil you project by giving too much info.
>
> Pete
Urbite
Mark McDougall
> 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.
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, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266
adwor...@r720.co.uk
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... http://home.comcast.net/~olimar/DS/jumbotron/ 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] ----> <---- I/O Pins Male Header Spartan 3 Board
Green [0-5] ----> <---- I/O Pins Male Header Spartan 3 Board
Blue [0-5] ----> <---- I/O Pins Male Header Spartan 3 Board
DCLK - Data Sampling clock ----> <---- I/O Pins Male Header Spartan 3
Board
GSP1 - Vertical Sync ----> <---- I/O Pins Male Header Spartan 3
Board
VGND - Assuming this is ground! ----> <---- I/O Pins Male Header
Spartan 3 Board
I have a multimeter here, should I do any voltage checks first etc or
am I barking up the wrong tree as obviously digital signals will be
rapid 'highs' and 'lows'? Also, how do I identify to the Spartan 3
Board that one of the pins is ground, is that just done as part of the
pin assignment in ISE??
Sorry about the stupid questions, its difficult for a super noob to
find his feet lol If anybody would like to work together on this I'm
more then willing to make it worth their while :) Email me at
pedwards
at
funkygamer
.co.uk
or just reply on here with how I can contact you!
Thanks again guys.
austin
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
MikeWhy
news:g4gos5$4l...@cnn.xsj.xilinx.com...
> 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.
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.
Mark McDougall
> 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'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...
adwor...@r720.co.uk
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 :)!!!!!
cs_po...@hotmail.com
> 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.
> 2. Detect either the rising or falling edge of VSYNC - pick one and only
> one edge.
> 3. 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.
> 4. 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.
> 5. Increment the vertical counter from step 4 whenever the horizontal
> counter value is 262 (max count).
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.
Ste
>chuckle at watching a noob stratch his head and do lots of stupid
>things :)!!!!!
>
Sorry for reviving an old thread, but I'm curious about how your project
went. I need to start getting ready for my own senior design project (May
2011), and I'm thinking of something similar with the DS but not exactly
the same. My goal would be to get an analog RGB/YPbPr output at 480i/p.
Although getting the output is quite the task, my project's main focus
would be various selectable screen output modes. For example:
Mode A) Top Screen only, 256 x 192 centered with black borders all around
Mode B) Bottom Screen only, 256 x 192 centered with black borders all
around
Mode C) Top Screen only, 256 x 192 resized to 640 x 480
Mode D) Top screen above Bottom screen, no gap between screens
Mode E) Top screen above Bottom screen, 64-line gap filled with
interpolated data from both screens and/or motion predicted pixels
and so forth....
This brings me to a few questions directed at anyone willing to answer.
With all the extra DSP aspects of my desired features, would the Spartan-3
still be a good candidate for this project? Or will I need something more
powerful? I would like to be taking FFTs to help with the video scaling,
so I would prefer something capable of that. But, I can avoid the
frequency domain altogether if the price difference for that capability is
too large. Also, I would probably need to buffer more than one frame for
the gap interpolation, so wouldn't I need more RAM? If I do need something
more powerful, then what is recommended?
I was actually looking at these two kits before I found this thread:
http://www.xilinx.com/products/devkits/HW-SPAR3A-SK-UNI-G.htm
http://www.xilinx.com/products/devkits/HW-SD1800A-DSP-SB-UNI-G.htm
Also, to add:
I've never used FPGAs before, but just like the author (of this thread) I'm
willing to put in most of my free time since I'm not able to take the FPGA
course at my school until Spring 2011 (which is too late). A major goal of
this project is to learn about FPGAs.
Any tidbits of help on this would be greatly appreciated. Thank you.