Hardware Hacking Creating a capture card PCB from scratch: open questions

[ArmorKnightPlus]

Was looking into grabbing a capture card for my New 3DS XL, and I started wondering why there weren't more instructions on how to build capture cards. People create custom PCBs for all sorts of things! So I was was a bit surprised that Loopy and Optimize are the only players in town.

So I thought... why not try and build my own from scratch, as a learning experience?

NOTE: I had links in the text below to various references, but I'm too new to post links. I'll try to describe them as best I can.

Looking at the instructions for installing the Optimize New 3DS board (optimize.ath.cx/NEW3DS/install.htm), there are a number of test points to solder the ribbon cable to. Comparing that with 3DBrew's lower screen dump (search for "3DBrew video capture"), it looks like we've got 24bit color with an HSYNC, VSYNC, and CLOCK, and a few other points that I don't know about. Guess I'd need to use an oscilloscope to measure what's going on at those unknown points.

Open questions:

• There's only one set of 24 bits for color, so I'm guessing one of the unknown points uses a signal to differentiate between top/bottom screen? How else would that even work?
  
  
• Even if I can measure the unknown test points, how do I determine what they're actually used for? Guess I'd just need to experiment and figure it out?
  
  
• Since I'm still new to PCBs, I'm not sure what component/chip you'd need to convert the parallel data to a serial stream that can go out over USB. But it looks like something similar to a PISO shift register would do the trick? You can see a reference image to Loopy's current New 3DS XL board on the 3dscapture forums, though they aren't finished yet.
  
  Dunno if there's any info to glean there on what chip would work to do the conversion.

Once you get the serial data flowing through the USB, you just need to write a driver/software on the Windows side to interpret the data, which should be straightforward (maybe you could use the HID api).

Anyone have any experience poking around this area?

Thanks,
-AKP

 

[FAST6191]

https://web.archive.org/web/20071017021146/http://home.comcast.net/~olimar/DS/jumbotron/ (Loopy's version of this for the DS, albeit never commercialised) might also be of interest.

Not sure where to start. You are asking some sensible questions and have an approach that might yield interesting results but also seem to be jumping in at the deep end without a terribly considered approach.

Serial to parallel. Most usually start off with some kind of highly programmable chip (see also the thing above) and then work down from there if they can find a chip capable of doing the deed (varies, and you might get lucky and find it is a common protocol -- Nintendo are not going to design their own custom setup), though modern FPGAs and related chips are actually of a power level, size* and such that they might stop there and deem it acceptable after slimming down the code or adapting it for those devices. It might also depend on what latency you are willing to put up with for this -- capture for storage/streaming can be seconds out and most won't care.

*most old school FPGAs needed a whole bunch of ancillary chips to make it all work, mainly as you had to essentially program it each power on externally, today that is reduced drastically along with power consumption, price and various limitations.

Determining unknown test points. Look for leaked documentation. Look what chips they connect to, find diagrams for those chips and see what it might be. Eliminate based on other things that are known. Stick your scope/data reader on the thing and see what the results are.
Further to that sounds like you might be new to video transfer as a concept. Might be worth a crash course in that.

Is a bit old school as it is mainly going for VGA rather than some of the more modern approaches used in screens but gives a very nice intro to things you might encounter. Go the other way as well and go on farnell, cpc, element14, rapid, aliexpress... and see what screens they offer* and what protocols they use. Another way still is many like to make projectors, or adapt old laptop screens for their purposes. They can have some interesting info.

*as a general note there are two main types of LCD panel manufacturer. Those that do big screens (laptop and larger), and those that do small screens (phones, most tablets, custom for whatever and everything else).

If you are not familiar with video and the various colour spaces and options available for those playing in those worlds -- you don't necessarily have to do some kind of schoolboy answer for what is yv12 and such ( http://avisynth.nl/index.php/Convert ) but luma, chroma and such should be known. I would not knock you being able to also throw down on RF, SCART, component and composite signals even if it is probably not going to be relevant to this (although if asking what there unknown pins/test points/signals do then knowing what also might be a functionality available -- https://lostnintendohistory.github.io/DS-TV-OUT )

As far as top/bottom screen then does it need to be? 2ds is one large screen and frankly a custom virtual resolution sounds a whole lot easier to handle than tying to sync and redirect pulses. I don't know that it is that. Of course you can go the other way and see what happens when you pull things high, pull things low, invert signals, change things in software (software screen swaps exist for the DS, never mind its GBA stuff, not sure what goes for the 3ds, and there might even be games/homebrew that have such a feature).

HID once in windows (or more likely as it leaves the FPGA/board)... a lot of things do like to appear as webcams. You might want to get more exotic though as USB2.0 tops out around 30 megs a second in the ideal case (see also what your external hard drive might transfer at) and that is bugger all when it comes to raw video, never mind if it is using high bit count RGB. USB3.0 and maybe something with USB C could yield something nice, and I would rather do that than have to try to implement video compression in a FPGA. https://www.cmlab.csie.ntu.edu.tw/cml/dsp/training/coding/mpeg1/ ... and that is only the now impossibly ancient MPEG1.

I will leave it there for now.

 

[ghjfdtg]

It's both serial and parallel. Topscreen is serial to reduce data lines (smaller ribbon cable) and bottom is parallel. You won't be able to capture the lines fast enough with some random microcontroller. You need something beefy like an FPGA. And you need USB 2.0 minimum to capture 2 frames + audio fast enough. Audio is 32 + 47 kHz over 2 I2S interfaces. Most capture cards only bother capturing the 32 kHz one.

Side note: The 3DS does NOT use VGA compatible signals.

 

[duwen]

I saw this just a few days ago... looks like a complicated, but impressive, solution...

 

[ArmorKnightPlus]

ghjfdtg​

It's both serial and parallel. Topscreen is serial to reduce data lines (smaller ribbon cable) and bottom is parallel...
Audio is 32 + 47 kHz over 2 I2S interfaces. Most capture cards only bother capturing the 32 kHz one.

I'm assuming both audio outputs are the same, since cards only grab the 32khz audio?
I happened to find a list of test points for the DS over at nesdev, is this what you're referring to with the upper screen video?

TP159 Upper Screen Video Data bit? (200mV) (P6.pin12) TP160 Upper Screen Video Data bit? (200mV) (P6.pin11) TP161 Upper Screen Video Data bit? (200mV) (P6.pin14) TP162 Upper Screen Video Data bit? (200mV) (P6.pin15) TP163 Upper Screen Video Clock (15ns, 100mV) (P6.pin8) TP164 Upper Screen Video Clock' (15ns, 100mV) (P6.pin9)

And I'm assuming this is the audio you're referring to:
CL33 TP149 I2S Word Clock (near AIC, up/left) CL34 TP147 I2S Sound Data Out (near nds-slot) CL35 TP150 I2S Bit Clock (near nds-slot) CL36 TP152 Sys 16.7MHz (also CL55)(near nds-slot) I2S should have 5 pins: SDOUT,SDIN, WCLK,BCLK,MCLK

duwen​

I saw this just a few days ago... looks like a complicated, but impressive, solution...

I'm aware of the optimize boards, and have looked at the instructions for putting those together. The point is that I'd like to make my own board, not use someone else's.

 

[ghjfdtg]

I'm assuming both audio outputs are the same, since cards only grab the 32khz audio?
I happened to find a list of test points for the DS over at nesdev, is this what you're referring to with the upper screen video?

They are not the same. The 32 kHz I2S interface is for most audio. 47 kHz is apparently for microphone and another sound engine called CSND only really used by the browser.
I would not compare with the DS. It's not the same. But the idea is basically one bit of each color channel every clock cycle. The clock must be 8 times as fast to transfer the color bits fast enough.

 

[ArmorKnightPlus]

I would not compare with the DS. It's not the same. But the idea is basically one bit of each color channel every clock cycle. The clock must be 8 times as fast to transfer the color bits fast enough.

My apologies, that list of test points wasn't for the DS. It's for the old 3DS mainboard, and includes whatever new test points the New 3DS has, as well.

I've also posted a thread to an electronics forum, with basically everyone telling me that I should start smaller though it seems like they have some solid advice.

 

[ArmorKnightPlus]

An update!

I talked to some nice folks over at eevblog (an electronics forum). I may end up trying for a bit less ambitious project first, but I think I have most of the general info needed to start.

Long story short, I might be able to use the Cypress CYUSB3017 chip to take in the video data from the 3DS board, and shove it out over USB. If for whatever reason the chip itself doesn't handle the 3DS's video format, I would use an FPGA to take that data, process it, then feed it to the Cypress chip.

I'd post links to some of this stuff, but I'm still getting blocked by this forum's anti-spam NO LINK protection.

 

[ghjfdtg]

I assume it's this one: https://www.eevblog.com/forum/beginners/nintendo-new-3ds-xl-capture-card-making-one-from-scratch/

 

[ack]

make sure to get a for parts 3ds, with a broken screen or something to save money, to develop it on, if you're gonna try this on your main console you're gonna have a bad time. Then, I would connect and lay out all the parts on some foam or something, so you can easily access the motherboard but still be able to boot it and such without having to reassemble it.

 

[ArmorKnightPlus]

I assume it's this one: https://www.eevblog.com/forum/beginners/nintendo-new-3ds-xl-capture-card-making-one-from-scratch/

That's the one! I love researching DIY projects like this, but one of the most difficult parts is not knowing what you're searching for! If you don't know the concepts or terminology, you have to reach around blindly until you happen upon what you're looking for. I'm glad I've been given great advice on where to start, both here and on eevblog.

make sure to get a for parts 3ds, with a broken screen or something to save money, to develop it on, if you're gonna try this on your main console you're gonna have a bad time. Then, I would connect and lay out all the parts on some foam or something, so you can easily access the motherboard but still be able to boot it and such without having to reassemble it.

Yeah not a bad idea. Been looking at some "for parts" consoles, might be able to snag one or two for cheap.

 

[spitzeqc]

I remember seeing some signal information for a 3ds capture card on granthaack.com a while back. Unfortunately it seems like the site has been taken down, but there is a saved version here here . Im not sure how helpful it will be without images, but it has a decent text write up of his process along with some values that may be helpful (signal speeds, total memory needed, etc.)

 

[R9000]

Hi all. Man am I glad to finally find this forum. I sort of half-started a similar project back in late 2020/early 2021, but I went off it until now because I had so many other things to do. I basically want to consolize the 3DS, so have a video out that can be connected to a TV, and controller ports to run it like you would a home console. Practically all my questions were about the top screen. Like ArmorKnightPlus I assumed the top screen used exactly the same pixel bus as the bottom, but I couldn't find any way the system was differentiating between the two. My plan was to use a Texas Instruments TFP410 to just push the signals straight out over an HDMI port. But given that the top screen uses serial comms (thank you ghjfdtg) I guess it'll have to be a more custom solution with an FPGA or at least a chip that can interpret the serial input fast enough. I'm not desperate to capture the bottom screen, to be honest the top is what matters most to me. Indeed, the whole bottom half of the console could be used as the "controller" for the console, with the integrated touchscreen like the WiiU. I've uploaded a pic of what I've found wrt. test points on the board so far, using images from capture card installation and wherever that Japanese source is from. It's not much that AKP hasn't already posted but I guess it's nice to look at? Now, does anyone know how I go about decoding that serial data for the top screen? I have a modest amount of experience with serial communication like SPI and I2C, but considering the 6 pins and being a one-way communication, it appears this is neither of those. Any ideas?