Converting 15kHz analog RGB to digital - Page 1
Forum section: electronics / beginners

author: Legion
author_rank: Frequent Contributor
timestamp: June 08, 2014, 01:49:38 pm
content: I recently got my hands on a Sony PVM RGB monitor. It's made my old 240p game systems look fantastic. I'd like to capture the gameplay to my PC. I've found a number of devices that do this, but they always involve some kind of upscaling, filtering, conversion to some kind of broadcast standard, etc. which I don't want. So I've been thinking about making my own capture device.What I'd want it to do is take in the 15kHz analog R, G, B, and composite sync signals, convert it to some kind of framebuffer (ie. Frame 0, Pixel (0,0), R_value, G_value, B_value, Pixel(0,1), R_value, G_value, B_value, etc) and write out that data to a file. I've found some ICs that kind of do part of the process from Analog Devices such as this:http://www.analog.com/en/analog-to-digital-converters/video-decoders/adv7800/products/product.htmlBut they always output to some kind of broadcast standard instead of just providing the raw RGB digital data. The other problem is the package these ICs come in. The one linked above is in a 176 pin LQFP package. Clearly not hand solderable, so I'm not sure how to prototype with it.I was thinking of something along the lines of: analog RGB IN -> Framebuffer IC (ADV7800 or something like it) -> uC -> USB or SD Card.So does anyone know of an IC that's closer to what I'm looking for? Also, how do you prototype with these things?

author: miguelvp
author_rank: Super Contributor
timestamp: June 08, 2014, 09:32:14 pm
content: http://www.analog.com/en/analog-to-digital-converters/video-decoders/products/index.htmlBut I'm not sure they will lock at only 15 KHzAlso since 640x480 runs the pixel clock at 25.175 MHz, where did you get the 15 KHz from? it should be closer to 1/4 of that.Unless you are talking about the vertical refresh rate, but that will have all 320 pixels of the horizontal line per cycle.Best candidate seems to be the ADV7181Chttp://www.analog.com/en/analog-to-digital-converters/video-decoders/adv7181c/products/product.htmlAlthough it might not lock to the 6.3 MHz required for 240p"Line-Locked Output Clock. This pin is for the pixel data (the range is12.825 MHz to 110 MHz)."But I'm not sure the Sony monitor will lock to 320x240 you sure the signal is not VGA?

author: Sebastian
author_rank: Regular Contributor
timestamp: June 08, 2014, 09:35:12 pm
content: I can't help you with finding an IC but LQFP is definitely hand solderable. The only thing you should have is soldermask between the pads, otherwise it could be a bit harder but still not impossible.Fix the IC on one corner and check if it is properly aligned, if it is, fix it one the opposite corner. Then put lots of flux on the pins and drag-solder them, preferably with a hollow tip. Done.

author: Ed Herdman
author_rank: Contributor
timestamp: June 08, 2014, 10:17:59 pm
content: Sorry to spam a link on my first comment here, but did you read about Micomsoft's (and Startech's) RGB capture cards? There is a thread about themhere.Micomsoft has the SC-500N1 (PCI-E) and the XCAPTURE-1 (USB 3.0).Startech has the PEXHDCAP (PCI-E).Drivers for at least some models are interchangeable between manufacturers, I think.Capture and playback on modern PCs is a tricky thing. It might not matter if your ultimate goal is to digitally preserve of the RGBs waveforms - perhaps an oscilloscope capture would do the trick, or something like that (people here know about that stuff).But for playback on a modern PC, you have to deal with a few fundamental differences between the technology types. Resolution is a problem on fixed-resolution monitors (like LCDs), and if the goal is to have 1:1 pixel mapping, you lose the aspect ratio and create something that has little visual resemblance to the original signal. Upscaling is necessary on such devices. Even CRT monitors aren't likely to support arbitrarily-chosen resolutions made for consoles, and if they did, they probably wouldn't look right without tweaking the overscan settings.Framerate is also an issue. On LCDs, you can expect to enjoy tearing and other glitches, even with framerate conversion. MultiSync CRTs won't even sync with the output of some RGB devices, like a standard Raiden II arcade board (though I haven't gone and tested all old consoles - standard NTSC framerate should work better here).I realize that these things might not matter in the long run, if we can assume we get variable framerates and CRT-like monitors without native resolutions. But in terms of preserving the look, 1:1 pixel mapping is not a great compromise.I'm not so big on video encoding stuff, but most of the stuff I know of expects you to use some standard resolutions - old consoles are all over the place here, again. On top of that, I think the most modern (efficient) codecs use 16x16 macroblocks, i.e., the resolution needs to be divisible by 16, not whatever funky resolution NEC or Nintendo came up with. So you likely need to pad the frames slightly - unfortunately now it won't look right once you go back to an appropriate 4:3 source. Upscaling to a standard resolution neatly avoids this potential pitfall.@ miguelvp: You're talking about RGBHV stuff; he's talking RGBs. 640x480 / 320x240 resolutions seem like standard PC resolutions - different from 480i RGB (which is where the 15KHz comes from - compare to other retrogaming standards of 24KHz - rare outside arcades and some Japanese computers - and 31KHz, seen in some progressive scan output consoles like the original Xbox) which determines horizontal resolution by a variety of pulses; actual horizontal (and vertical!) resolutions vary from device to device. Never heard of 6.3MHz required for 240p; should be the standard 3.58MHz assuming NTSC timings. It goes without saying the signal is not making use of the VGA adapter.Hope that wraps it up: Glad to be here, hope some of this is useful.

author: AmmoJammo
author_rank: Frequent Contributor
timestamp: June 08, 2014, 10:20:29 pm
content: RGB to ypbpr, then a ypbpr capture deviceNow... I'm not sure how the capture devices will go with the resulting ypbpr signal, as not all TVs will support a signal like this either....However, converting RGB to ypbpr doesn't require any scaling or processing, its just addition and subtraction of signals, so the resulting image is the same quality as rgb.

author: miguelvp
author_rank: Super Contributor
timestamp: June 08, 2014, 10:33:47 pm
content: oh, 30Hz that makes sense.So he will need some 3 channel ADC that can lock at 3.58MHz pixel clock.I was just dividing the 640x480@60Hz pixel clock by 4 for the timing guestimate.As an alternative you can get yourself a TV Superscan 2 (not sure if it will lock at those frequencies either) and hack it so you can access the freeze frame.I have one laying around and just opened it up, it uses a philips TDA8707 Triple RGB 6-bit video analog-to-digital interface, for retro gaming 6 bits per color should be enough I would think:But it seems no one carries that chip anymore.

author: Ed Herdman
author_rank: Contributor
timestamp: June 08, 2014, 10:45:38 pm
content: @ miguel: Actually 59.94Hz, given that 240p allows each sweep to represent a full frame and not just interlaced fields. But this is if you're only dealing with typical consoles - as noted earlier, there's devices giving RGB outputs for which references to NTSC or other standards don't make sense.@ ammojammo: I think just going with the Startech will be cheaper, unless you are OK with a real cheap YPbPr device with probably lousy drivers, and you are okay with a really cheap RGBs -> YPbPr transcoder, or you get lucky and score a Kramer multicoder / universal transcoder very cheaply. I got a Kramer FC-4040 recently - gonna see how it performs - but it's really more than is necessary for just capture. Still, the flexibility is good to have for using RGB devices on a YPbPr television.

author: miguelvp
author_rank: Super Contributor
timestamp: June 08, 2014, 11:14:48 pm
content: Now i'm confused, 320x240x60Hz = 4.608 MHz and that doesn't take care of the horizontal and vertical front and back porch, that's why I was guestimating the pixel clock to be around 6.3 MHz.Nevermind I did find a source:https://pineight.com/mw/index.php?title=Dot_clock_ratesBTW Ebay has the TDA8707 3 channel 6bit ADC chip from Hong Kong and China, go figuredatasheet:http://pdf.datasheetcatalog.com/datasheet/philips/TDA8707H.pdfOr you can get thishttp://www.ebay.com/itm/Advanced-Digital-Systems-ADS-Model-SFN-100-TV-SuperScan-2-Presentation-Module-/251476666889?pt=LH_DefaultDomain_0&hash=item3a8d2d6a09Or bid on this:http://www.ebay.com/itm/ADS-TV-Superscan-2-VGA-to-TV-converter-/321426344172Not sure how much hacking you'll have to do to access the frame buffer after a capture. And if you want to capture actual video well this thing converts the vga to composite so it's streaming the data internally, it uses a Zilog z86c3012psc mcu but I bet the MCU doesn't play much part on the actual decoding/encodingI'm attaching a picture of the TVSuperScan2 insides, maybe I can trace the digital outputs and see where they get buffered through.Edit: Can't find the power supply

author: Ed Herdman
author_rank: Contributor
timestamp: June 09, 2014, 12:48:26 am
content: Miguel, I still am not sure if you understand that the OP's video source is not a PC VGA monitor. It's 15KHz RGB, similar to 480i standard-definition television in the NTSC spec (you can have RGB for PAL televisions as well, of course, but few gamers care about this - I'm new here and Legion hasn't provided region details, though I note that the Micomsoft and Startech devices happily deal with multiple region formats).re: the pixel clocks - I see where you're getting that number from, but consider that the actual systems the OP is going to be using have totally different resolutions, as you see in that list. Not the PC ones - the ones like Super Nintendo and so on. Here my knowledge is running out - I don't know if having 6.3MHz support is a matter of maximum bandwidth, with support for lower dot clocks, though I wouldn't make this assumption since compatibility in many areas is a minefield.The ADS is just an upscaler - and probably not a very good one for gaming purposes, and totally useless if you can make use of software scaling anyway. Likewise, composite capture is a waste of time when the OP has asked for preserving details. Upscaling / framerate conversion aside, composite is just going to throw out most of those beautiful RGB details.I don't have any familiarity with PC output scalers (the SuperScan 2 seems to have some scaling capability) but I expect they are lousy, all things considered.If somebody did have a VGA capture card (and they were expensive when I checked a few years ago, though getting less so) then they could make use of a standard scaler to convert to 640x480. Micomsoft stand-alone scaler boxes (like the XRGB-2 and the XRGB-3) do this quite well, though once again there is no sense in buying this equipment just for this use, when you can get better control and lower cost from just buying a USB 3.0 / PCI-E capture device which you can plug the source right into, and then do whatever you want with the resulting capture in software.

author: miguelvp
author_rank: Super Contributor
timestamp: June 09, 2014, 01:09:03 am
content: Yes the superscan has scalers (down-scaling mostly) to convert from PC to NTSC, but I was suggesting in hacking the device to take the analog to digital and the buffering parts of the board not to use the whole thing as a solution. SuperScan was made by Micomsoft btw (at least it has it embossed in the bottom of the case as the copyright holder), just older tech that might be able to deal with those lower frequencies.As for the 15KHz RGB I get it, but he can't digitize a whole horizontal line at one time, he needs an ADC that is able to convert the signal at the pixel clock level, all three channels at the same time.I think we need more info from the OP, we don't even know how many bits per color his system produces.

author: Ed Herdman
author_rank: Contributor
timestamp: June 09, 2014, 01:39:43 am
content: Well, what are you aiming to provide? I already gave the standard, affordable yet pretty much top-end choices in my first post, which supports everything without trouble. These already contain all the components necessary to get the highest quality possible, including an appropriate ADC, without hacking. The SuperScaler 2 is a single-purchase solution and cheaper than I thought - just not applicable for this question, especially if you lose RGB and have to go to composite. (I also can't find any reference to Micomsoft having anything to do with the the SuperScan devices, which is surprising if it's true.) If you want to offer a collection of parts in order to approximately build something, that's another matter, but probably more expensive and bothersome compared to getting something that's ready to go off the shelf.This reminds me that I have an older RGB capture card for PCI (not PCI-Express) that I never used and need to get rid of.I think the OP is going to be resistant to these choices out of the belief that 1:1 pixel mapping is desirable and natural (it really isn't).

author: Legion
author_rank: Frequent Contributor
timestamp: June 09, 2014, 01:49:07 am
content: Quote from: Ed Herdman on June 08, 2014, 10:17:59 pmYes. I looked at those first. The problem is they are meant to take a signal from an old console and output it in a format compatible with a TV or monitor. But I don't need the signal output to anything, just recorded. The console connects to the Sony PVM RGB monitor which acts as a display, but the monitor also allows you to pass the signal on to some kind of capture device (I suppose originally some kind of DVCAM deck). I want the 1:1 mapping so I can save the frames as a series of images, maybe PNGs or something like that. Then I can import that into After Effects or Premiere Pro for editing and then output in something like H264.

author: Legion
author_rank: Frequent Contributor
timestamp: June 09, 2014, 01:52:15 am
content: Quote from: miguelvp on June 09, 2014, 01:09:03 amSince I want to use this with multiple consoles, I don't want to worry about the native bit depth of the console. I was hoping to convert each R, G and B pixel signal into an 8-bit value, so 24-bit color.

author: Ed Herdman
author_rank: Contributor
timestamp: June 09, 2014, 02:07:23 am
content: Are you sure you looked? I didn't link the Micomsoft TV upscalers (XRGB 2, 2+, 3, Framemeister, and the lesser-known ones like the XPC-4 and the DISPL) but rather real RGB capture solutions. Their primary purpose is not what you describe, which is more like the upscalers I've listed here.As for what you're using this for - I thought so. TBH, with 1:1 pixel mapping you're just competing with the emulator kiddies (been down that road a ways myself). Again, capture only works if it's usable somehow - by capturing the signals you've already taken them out of their environment unless you have a way of feeding back the analog RGB signals to your PVM. So it's just as well to consider putting it in a format that is presentable; otherwise it's a bear in the woods type scenario. Even so, I think the Micomsoft / Startech capture devices should still give you some flexibility to capture in a smaller format. (Upscaling will prevent the headache of trying to fiddle with resolution output, matching macroblock size if that's a problem, and framerate conversion might also be at issue; post-production packages are not going to solve these problems for distribution of the resulting video because you're still stuck with the applicable computer video formats in terms of framerate if not resolution.)I just recalled another issue that is critically important: Pixel transitions. As miguelvp was hinting (I think) there isn't actually a solid, defined pixel, but rather a data burst with some fuzzy edges. Trying to capture at exactly the internal resolution of the particular system (again, it's totally different from console to console) might not give you a well-defined pixel. If you're going to capture from a Super Nintendo, say, you will find that the edges of an internally defined pixel (as you'd see from output in the Higan SNES emulator by byuu) aren't so sharply defined and may even bleed into each other, especially if you have one of the early revisions of SNES. This is another reason why people often recommend going with a typical capture card, which does not give you a pixel-sharp output.And yet another problem: Many systems switch resolutions on the fly. Square does this for some SNES games, switching from 480i to 240p. Many other titles use 640x480-ish interlaced resolutions for title screens, menus, and inventory screens, but switch to something else for gameplay.1:1 pixel mapping just doesn't exist anymore at the video output step.I'd encourage you to post a question in that forum thread I linked - or I could do it if you wanted (edit: posted with a couple questions for clarification of my own). Just to see if there is a way of getting what you want, and what's going to get most of the way there.

author: Legion
author_rank: Frequent Contributor
timestamp: June 09, 2014, 02:44:09 am
content: Quote from: Ed Herdman on June 09, 2014, 02:07:23 amYes, I've been thinking about that a lot. If picture fidelity is the highest priority then emulation is probably the best way to go since you eliminate A/D conversion and all the opportunities for noise and signal degradation on the analog side. But I also want to film people playing the games and their reactions to what's going on. Filming someone playing SMS on a PC is just... well, my nostalgic side just doesn't like it.I spoke to Joe Redifer over at Game Sack about capturing RGB and he said:QuoteKind of turned me off that type of capture method, but perhaps the XCapture-1 plus XSync-1 doesn't have these problems? I'll have to read more about it.The idea of building my own capture device is a lot less appealing. I had no idea the 8 and 16-bit systems switched resolutions like that.

author: miguelvp
author_rank: Super Contributor
timestamp: June 09, 2014, 02:58:42 am
content: @Legion,Do you have a scope that you could capture a screenshot of a single horizontal line out of that output connector?what model of Sony PVM RGB do you have?Also the problem is that you can't really automatically capture the video no matter what, you need to know the pixel clock, the front porch time the back porch time, the sync time and then when it's done with all the lines there is also frame front and back porchFor example here are the timings of a VGA signal (640x480 @ 60Hz)http://tinyvga.com/vga-timing/640x480@60HzAt the vertical sync signal you have to wait the sync pulse time and the back porch time before digitizing, then you have to digitize each pixel at 39.721946375372393247269116186693 ns intervals (inverse of the pixel clock at 25.175 MHz) then wait for the front porch until you get the next vertical sync.At the end of the frame you deal with the vertical timings pretty much allowing you time to construct your frame.Another problem is that all of those old triple channel ADC chips are now obsoletehttp://www.ti.com/lit/ds/symlink/ths8083.pdfYou might be able to do it with standard ADC chips with multiple channels but it's not going to be trivial if you want to support several clock frequencies. That's why it would be good to know if the model of your Sony PVM RGB and at least some of the consoles.

author: Legion
author_rank: Frequent Contributor
timestamp: June 09, 2014, 03:00:41 am
content: Quote from: miguelvp on June 08, 2014, 10:33:47 pmI'll order one off ebay. Should be interesting to mess around with at the least.

author: Legion
author_rank: Frequent Contributor
timestamp: June 09, 2014, 03:07:37 am
content: Quote from: miguelvp on June 09, 2014, 02:58:42 amI do have a scope, Rigol DS2072A. I'll try taking a snapshot of the signal.It's a Sony PVM-20L2.Consoles are NES, SNES, N64, SMS, Genesis, Saturn, TG16 and PC Engine Duo.

author: Ed Herdman
author_rank: Contributor
timestamp: June 09, 2014, 03:12:16 am
content: AFAIK, Shmups' own upscaler guy (Fudoh) sold off a Blackmagic setup a couple years ago, and I think the reason was that it wasn't really flexible or intended for this kind of application. The Micomsoft and Startech devices (not so sure about the Startech drivers) are, however. There might be some slight issues with the Micomsoft drivers for the SC-500N1 on European computers, maybe - but I think both companies have been at work ironing out the bugs.The good thing about doing the capture the Micomsoft way is that the output looks reasonably close to the original - right aspect ratio, probably many subtleties of the original output are preserved.Nostalgia really shouldn't point you in the direction of the monolithic block pixels. This isn't even like the old engineering adage ("price, performance, quality: pick two"); 1:1 sharp pixel mapping and scanlines are simply incompatible with each other.We can always re-open this discussion if some CRT scanning-like technology (laser displays, maybe) hits the market, but until then, you have to choose@ miguel: Take care not to idealize the situation too much: As I stated, even within single system lines there are real differences in where pixel transitions happen, depending on the revision of system used.

author: miguelvp
author_rank: Super Contributor
timestamp: June 09, 2014, 03:36:40 am
content: Quote from: Legion on June 09, 2014, 03:00:41 amUnderstand that this doesn't capture video but it will do the conversion internally, unless you are talking about ordering the TDA8707 chip and doing your own boardQuoteNote the video is 75 ohm terminated, you'll need a T and a 75 ohm terminator to make it happy. Also if the cable is just an RGB cable the Green carries the Sync signal, unless the connector has separate horizontal and vertical sync.On old monitors that were black and white you would use the green BNC since it ws the one that carried the sync signalBTW I've have hooked VGA BNC's directly to my DS2072 (no A) just reads the voltage higher but I can see the signals fine. Also I think I have at least a Genesis or a Saturn around. Found them but I only have composite out of the Saturn and RF out on the genesis, not sure how you are connecting them to your monitor.Because if you are using composite and RF out the monitor won't convert that to RGB and make it available externally (as far as I know)

author: miguelvp
author_rank: Super Contributor
timestamp: June 09, 2014, 03:46:05 am
content: Quote from: Ed Herdman on June 09, 2014, 03:12:16 amNo worries, the OP wanted to capture the signal directly so that's why i'm focusing on the direct approach, but I think it's not a trivial task nor I'm suggesting it's trivial, capturing data at these speeds of 4-12MHz is not trivial.As for the pixel transitions well they have to follow the clock for the display to display it, it's not like the console is going to change the gun deflection at particular pixels.

author: Ed Herdman
author_rank: Contributor
timestamp: June 09, 2014, 04:01:38 am
content: There's some strange properties of RGB (and other) outputs on this class of devices where pixels bloom or bleed outside their expected boundaries, but yes, the pixel clock should be relatively stable, I'd hope.I'm not sure if the PVM's RGB passthrough will transcode something like Y/C or composite to RGB. I could try it out, one of these days. There are some people who might be able to make use of that, though I suspect it's rare. Many good Y/C and composite monitors should have a comb filter (not sure about Sony's PVM line for security monitors, which are a far lower level of PVM than the L2 series) and many capture setups will just allow you to apply filters as a post-process step.If somebody does need composite or Y/C to RGB transcoding, there are some inexpensive (sub-$50, US dollars) units by Kramer floating around secondhand. Their more flexible transcoders including component to component transcoders (i.e., RGBs to YPbPr) also can do this, and they aren't necessarily expensive either.However it goes without saying that dealing with Y/C or composite this loses all the quality of dealing with RGB.Getting cables appropriate for RGB transmission is a somewhat tortured topic - the people building them assume SCART style connectors (21-pin) are generally a part of peoples' setups, but that just adds more chances for interference and you also have to watch out for pinout differences between the SCART style and JP-21 (Japanese). Additionally, grounding and shielding are sources of trouble. Still, now's as good a time as any to get them. If you go with the eBay sellers, one says shielding doesn't make any difference, while the other gets it. And then there's all those ancient branded RGB cables made by OEMs in the '90s - not worth buying unless you want museum pieces or to do some work fixing them up.

author: miguelvp
author_rank: Super Contributor
timestamp: June 09, 2014, 04:11:50 am
content: That's my take as well regarding RGB out, it's just a loop from RGB in.So it might all be a moot point, I would rather just use a video capture card that is known to work like the link you provided but that's not what he was asking.Myself I have a Hauppauge HD PVR 2 Gaming Edition that can capture HDMI and component and convert it to H.264 directly and with audio, but it won't work for those consoles I think.

author: Ed Herdman
author_rank: Contributor
timestamp: June 09, 2014, 04:27:42 am
content: The talk about composite is even further away from what the OP asked about. The Hauppauge is probably very nice, but certainly not applicable either, even if it does have some kind of component input. Seems mostly HD focused.Many of the old systems supply RGB as standard; all that's required is an appropriate cable.Some can have known modifications that allow RGB output (N64, TurboGrafx/PC Engine).From that list, only the original NES is limited to an A/V connection, though the attention being given to that system has seen it recently derive not only an RGB mod, but there's also another project working to implement the system over HDMI, which of course can provide pixels (at the likely cost of way more pixels being displayed than are needed for simple 1:1 pixel capture, but modern codecs should ameliorate this problem substantially; even 1080p content shouldn't take up much space).The PVM should be able to pass through any of these signals.And again, it's worth pressing back somewhat against the original request when certain aspects of it appear impossible - at best, it's worth questioning to ensure that all the major issues are known, given the limited potential benefits and many downsides. Pixel clock shenanigans aside, you still likely have to deal with framerate conversion and multiple resolution support - all possible, but I don't see the point when you can just whack in a modern capture solution and let it do the hard work.Edit: Well, since I got a bit of pushback on this elsewhere () I want to point out that the key here is not that 1:1 pixel mapping is a bad thing in of itself - rather I fear that it misses the point that these signals must go through an analog-to-digital conversion to be captured. Trying to arbitrarily determine the exact boundaries of a pixel, and define it as a monolithic block, may well sacrifice some desired details.

author: miguelvp
author_rank: Super Contributor
timestamp: June 09, 2014, 05:04:48 am
content: Composite came about because he mentioned the Saturn, and RF out because he mentioned the Genesis as two of the consoles and I happen to have both, I don't have any of his other consoles.I also mentioned that my Hauppauge won't work with those consoles and agreed with you on getting one of those known capture cards that are known to work like in the link you provided.But maybe he wants something better than OK. Surely is possible to get the real timings and hook the ADC to a BeMicro CV FPGA and write the video in the microSD. At 10MHz tops an mcu might be able to deal with it too. Although a class 10 microSD might fall short on capturing 340x240@60Hz at 6 bits per color raw data (10,368,000 Bytes per second). But some can do 14.6MB/s so might be ok.Having the sync timings pre-programmed so that he can change the capture configurations on the fly to match his hardware exactly is not trivial but not extremely difficult.

author: Ed Herdman
author_rank: Contributor
timestamp: June 09, 2014, 05:12:36 am
content: It's in the topic title: Analog RGB. This means a specific variety of component video, which he specified as RGBs later on. No guesswork is required as to what the OP wants.The Saturn and Genesis both support RGB natively. In my previous post I've listed the only exceptions to systems that output RGB natively (assuming the correct cable is purchased, and you don't have one of the less common revisions of a console - there's different SNES and Genesis consoles - the SNES mini and Genesis 3 - that require modification to output RGB, but the resulting output is very good on both, IIRC).I asked elsewhere (at the thread I linked in my first post) about the question - one other user notes that the A/D step is critical, especially if the goal is something like a 1:1 pixel mapping. Do I have any idea what the difficulty is, from an EE standpoint, of doing this? Not really! I do know that it's something that has engaged companies for a while, though, and it doesn't look simply trivial to do, so I am reluctant to try and do something totally from scratch. And it's worth pointing out the workflow challenges too, I think.

author: Legion
author_rank: Frequent Contributor
timestamp: June 09, 2014, 02:32:12 pm
content: I spent a few hours last night combing forums and reading sixfortyfive's review of the XCapture-1:http://www.sixfortyfive.com/streaming/xcapture1.htmlThe whole process looks like an exercise in frustration and compromise. You need a specific USB 3.0 chipset (NEC Renesas) or it won't work. If the resolution changes during capture, it drops out for a few seconds. If it switches between interlaced and progressive your audio goes out of sync. If resolution changes and i/p switches only occurred when switching games or systems it wouldn't be a problem, but if a game switches modes on the fly, it will be. Depending on the source resolution haloing can be introduced into the captured image.I'm not saying I could make something better. I'm sure the engineers at Micomsoft are smart people tackling a difficult problem. It amazes me that old, analog CRTs handle all of this effortlessly, but attempts at digitized capture have so many problems. Maybe I need an analog intermediary to provide a uniform interface to the capture device. Maybe I need... a VCR.

author: Legion
author_rank: Frequent Contributor
timestamp: June 09, 2014, 04:10:33 pm
content: Here's the scope images of the green signal at various zoom levels. Amplitudes will be off since I'm not using a 75R termination.

author: miguelvp
author_rank: Super Contributor
timestamp: June 09, 2014, 04:16:06 pm
content: Quote from: Legion on June 09, 2014, 02:32:12 pmActually not a bad idea.I used to have a multi format VCR that I bought on a trip to Japan in the electronic district. It could handle all formats known to mankind and their derivatives and convert between them.It used some ADCs because it will digitize the image to convert it.It was an Aiwa HV-MX100 and it cost me quite a bit back in it's day, but my family would send me PAL video tapes and this will let me play them on NTSC.They are not even cheap now, and I have no clue what bonanza.com is.http://www.bonanza.com/listings/Aiwa-Worldwide-Video-Ntsc-Pal-Secam-Vcr-Hv-Mx100-U-Mx100-Working-Condition/173558599The quality was so good that the artists at work asked me to bring it too work all the time but capture crisp highres pictures for textures.You could pause it and it would be really crisp. I'm pretty sure my wife threw it away on her routinely clearing up space."you don't need this, you haven't used it for years"It didn't have rbg inputs as I recall but the image in that link shows a scart connector! I guess I never had use for SCART.Edit: I'm going to tell her that she threw away money. Those things seem to hold it's value for a dead techhttp://www.amazon.com/Aiwa-HV-MX100-Hi-Fi-Multi-System-VCR/dp/B00001QGUQEdit: looking at the schematic (page 22), the SCART connector doesn't have the RGB pins connectedEdit again: plus I don't know if this will lock into the console.

author: miguelvp
author_rank: Super Contributor
timestamp: June 09, 2014, 05:57:16 pm
content: Quote from: Legion on June 09, 2014, 04:10:33 pmSeems like it's around 15.625KHz (hard to say) between lines. I eyeballed 13 divisions minus1/5 of a division. so around 64us. Edit: but skipping every other line. (probably because being 240 instead of 480?)the actual visible line seems to be 6 divisions so 30us, what is the horizontal resolution? if it's 320 then it puts the pixel clock around 10.666 MHzWhat system was that one? the SNES or the TG16?Also I don't see any sync signal there, does it have separate horizontal and vertical sync lines?

author: Legion
author_rank: Frequent Contributor
timestamp: June 09, 2014, 06:08:53 pm
content: That was the SNES. I'm not sure what the resolution was for that game since the SNES can have 256 or 512 pixels per horizontal line and 224, 239, 448 or 478 vertically.

author: Ed Herdman
author_rank: Contributor
timestamp: June 09, 2014, 06:31:32 pm
content: Didn't know about the XCAPTURE-1 USB issues - it looks like there's still something going on there.I'd think an old VCR would likely convert the signal to Y/C, since that's the best its tape format can manage. I have heard of people using DVRs to capture game video, though, and you should have some component output ability or even onboard file encoding there (though I don't know what the processing is like there). But I wouldn't spend money on getting one - the StarTech card is only $120-ish on Amazon (before shipping), and I'm not sure how quality will be (probably you are limited to relatively few options there, and it encodes media itself).@ miguelvp: None of these systems have separated sync lines. The kinds of sync used in these systems are composite video as sync (carrying all the other parts of a composite video signal, so artifacts can appear) or composite sync (which is a basic combined h + v sync). A decent reference on this topic is foundhere.

author: miguelvp
author_rank: Super Contributor
timestamp: June 09, 2014, 06:58:58 pm
content: Different approach but it's a one off:http://forums.nesdev.com/viewtopic.php?f=9&t=9561His goal was to do a pixel perfect conversion to VGA.@legion, what kind of dev boards to you have in hand?I'm tempted to an RGB adaptor for the Saturn or the Genesis, what do you use, something like this?http://retrorgb.com/genesisrgbcables.htmlI guess I can just get a couple of DIN connectors and play with at least the Genesis and the Saturn to see what is possible, since I find this interesting

author: Legion
author_rank: Frequent Contributor
timestamp: June 09, 2014, 07:10:02 pm
content: Quote from: Ed Herdman on June 09, 2014, 06:31:32 pmI was actually warming to the idea of using the XCapture-1 until I read about the USB chipset specificity. For me, that kills the primary advantage it had of portability. I liked the idea of a USB device since I could use my laptop. A PCI-Express card would require me to bring my desktop out to the living room for capturing which is cumbersome. If I wanted to use a laptop I'd have to buy a new one with the primary selection criteria being the USB 3.0 chipset which is very limiting.

author: Legion
author_rank: Frequent Contributor
timestamp: June 09, 2014, 07:18:58 pm
content: Quote from: miguelvp on June 09, 2014, 06:58:58 pmI don't have any FPGA dev boards. I had been eyeing that Altera board as a means to learn about FPGAs. Didn't buy one yet as I'm not sure if I have the time to learn how to do anything meaningful with them. For cables I'm using the appropriate cable for each console fromhttp://www.retrogamingcables.com/Each terminates in SCART and then I have a SCART to BNC adapter to go into the Sony PVM:http://www.retrogamingcables.com/sony-pvm-scart-converter-bnc.html

author: Ed Herdman
author_rank: Contributor
timestamp: June 10, 2014, 12:00:10 am
content: If your laptop has an ExpressCard slot, you might be able to use an adapter for the PCI-E cards.

author: miguelvp
author_rank: Super Contributor
timestamp: June 10, 2014, 02:47:23 am
content: So I did fired up the Saturn (RTC battery dead to it did boot to the set time screen, not sure if it still does that once I moved it to my office).Good news is that I identified the pins and there is a dedicated sync pin.Bad news is that SCART cables don't use that pin and use the component signal for the clock.From:http://members.optusnet.com.au/eviltim/gamescart/gamescart.htmHere is the pinout of the SCART connector Notice there is no sync pin so they must use the component signal.The cable you linked uses the Yellow cable (composite probably to derive the sync)Good news is that there is hardware that will split it all up for you if you are so inclinedhttp://members.optusnet.com.au/eviltim/vga2arc/vga2arc.htm#acvidOr you can use the composite signal to get the sync, here is the red signal synced with the composite signal above.But to use the composite signal you will have to find the sync, maybe easy with a comparator.I have not yet researched how the vertical sync is encoded in composite yet, but I will be able to find it, by using the sync pin to see what is going on during vertical refresh.Next I will post captures using the sync pin in the Saturn (pin 1)I will use the same method to look at the composite vertical sync signal.

author: miguelvp
author_rank: Super Contributor
timestamp: June 10, 2014, 02:57:06 am
content: Here is a full frame (kind of a full screen capture) of the Saturn:Here is the vertical back porch measurement:And here is the Vertical back porch plus the visible frame measurement:Finally here is the detail of the vertical sync followed by the vertical back porch:I can use this method to figure out how the composite vertical sync looks like.Forgive the noise, I just have some pin jumpers hooked in the connector so it might be picking up a lot of noise, although they are short breadboard jumpers.Next the horizontal timings (a line of the screen)

author: miguelvp
author_rank: Super Contributor
timestamp: June 10, 2014, 03:07:20 am
content: For the horizontal captures I selected a line that looks pretty uniform on the red channel. Since I have it triggering on a pulse of 5us of the vertical sync I can lock into the same line anytime.First this is the Horizontal sync measured:This is the Horizontal sync plus the back porch:And this is the full line, HSync+back porch+visible line+front porch:I'm going to try to trigger the component vertical sync using this pulse triggering on channel 2.

author: Legion
author_rank: Frequent Contributor
timestamp: June 10, 2014, 03:11:00 am
content: Quote from: Ed Herdman on June 10, 2014, 12:00:10 amUnfortunately it doesn't. It doesn't have USB 3.0 either. It's a decent machine, but I bought it just before USB 3 became widely available in laptops. So I'd likely have to get a new laptop to capture footage regardless, I just don't like limiting my options to a certain chipset.

author: miguelvp
author_rank: Super Contributor
timestamp: June 10, 2014, 03:20:07 am
content: Here is the Sync (pin 1) compared to the Composite signal showing the VSync and the back porch:And a close up of the VSync itself, the bottom one is the composite VSync:Edit: notice the color burst signal after every HSync.Now to try to fire up that superscan and hack it to get the ADC outputs, not sure what to do about the sync, I might need to use pin 1 to make it easy for now.

author: miguelvp
author_rank: Super Contributor
timestamp: June 10, 2014, 08:32:30 am
content: So I re-purposed a spare VGA to DVI adapter (was a pain to hack it apart) then used some spare wires to make the Saturn to VGA to feed into the SuperScan 2, and I found a power supply for the device.Also the chips next to the TDA8707 (Triple RGB 6-bit video analog-to-digital interface) are d42280v-30 2 Mb Field Buffers, so 256K words 8bit FIFOs for a whole one MegaByte worth of buffered data since there are 4 of them.http://www.datasheetarchive.com/dl/Datasheets-SX27/DSASW0041403.pdfNow I want to find a DIN connector that fits the saturn for the home made cable to test this and look if the composite output of the SuperScan displays something.Edit: maybe I got lucky since it seems no one can find sources for the connectors but I think this will work:I'm going to connect the HSync to pin 1 so I don't have to deal with the composite signal for now. Hopefully that is enough to feed the FIFOs.Then I think I will have to lift the chip that controls the fifos outputs (to the right of the board on a picture I posted earlier labeled YUAN EC1000T) so that I can patch some cables to control the fifos from an FPGA to get the data out. Unless I can find something else down the pipe that makes it simpler. There is a pot next to that chip to adjust something, maybe the pixel sampling clock?After that I will have to get the composite signal to split the HSynch and VSynch like in the diagram linked before:http://members.optusnet.com.au/eviltim/vga2arc/vga2arc.htm#acvid.Haven't think about the audio yet, some audio ADC or use the DACs on the Nano with some comparators to make a ramp ADC.

author: Legion
author_rank: Frequent Contributor
timestamp: June 10, 2014, 03:06:21 pm
content: What I'm still not clear on is how to derive your pixel clock. You have an H-sync for each line. But without knowing the resolution of the image, how do you know how to subdivide the signal for sampling?

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: June 10, 2014, 03:29:55 pm
content: Quote from: Legion on June 10, 2014, 03:06:21 pmFor standard formats, I think you can identify which format it is from the sync timings, which gives you the pixel clock, for broadcast type formats, a multiple of the colour subcarrier is normally used.

author: Legion
author_rank: Frequent Contributor
timestamp: June 10, 2014, 03:36:24 pm
content: Quote from: mikeselectricstuff on June 10, 2014, 03:29:55 pmSo the H-Sync timing adjusts based on resolution? Ed Herdman was saying a lot of consoles change resolutions on the fly in game. They also switch between progressive and interlaced.

author: miguelvp
author_rank: Super Contributor
timestamp: June 11, 2014, 01:46:46 am
content: Depends on how you configure the FPGA it should be able to automatically switch on the fly.BTW, source for the connector:http://www.wallcoinc.com/Pan_Pacific_MD_10P_Mini_DIN_MALE_CONNECTOR_10_PIN_p/wal78-md-10p.htmOrdered 3. Also added 3 BNC dust caps, a couple of T BNC connectors a couple of 50 Ohm terminators and a pair of 75 Ohm terminators since their minimum order was $15 so I had to pad my order and I needed those bits. + $8 shipping (the cheapest they offer is FedEx ground)I know, ordering 3 connectors is overkill specially not knowing if it will work, but they are pretty cheap.Oh crap, I should have gotten a couple of regular DINs for the Genesis, oh well too late. and I might have some around, looks like a old PC keyboard connector might do.Oh, btw the SuperScan also outputs s-video as well, not that it helps on anything but just to mention it.

author: miguelvp
author_rank: Super Contributor
timestamp: June 11, 2014, 02:25:38 am
content: Well, Since VGA and RGB SCART have the same signal levels and the same impedence I thought I'll give it a quick test.But the SuperScan wouldn't lock with feeding the Sync signal to just the HSync, I think I have to extract both HSync and VSync from the composite video:Source:http://members.optusnet.com.au/eviltim/vga2arc/vga2arc.htmLM1881 datasheet:http://www.ti.com.cn/cn/lit/ds/symlink/lm1881.pdfAlternatively I can run the combined sync signal to the FPGA and the FPGA can drive the horizontal and vertical sync after separating them by logic.Going to wait for the connector, since using breadboard jumpers is getting already out of hand a bit.

author: Legion
author_rank: Frequent Contributor
timestamp: June 11, 2014, 02:29:47 am
content: Which FPGA are you using? Is it the Altera Cyclone V?

author: miguelvp
author_rank: Super Contributor
timestamp: June 11, 2014, 03:59:59 am
content: On the finalized version I want to use a BeMicro CV (Cyclone V) because it has 1GB DDR3 and microSD. Plus it's only $50.But my plan is to use the DE0-Nano (Cyclone IV) to start with and convert the capture data directly and convert it to VGA to know that I'm getting the right data since I already have a DAC that can handle the output part:Seems I need to feed the sync from the Saturn into the FPGA to derive the HSync and VSync, (unless I go for the hardware approach) to drive the SuperScan device. Also I have to take those vertical sync pulses to generate a VGA compatible VSync. So that will take 3 pins.Once that is done then test the composite output of the SuperScan to make sure it's locking into the signal. I should be able to see the image on a TV via composite indicating that the board is locking into the signal.To capture the data from the SuperScan, so far I have two routes, one is to tap directly into the capture chip (TDA8707), the other is to tap into the FIFO output.If I go for the FIFO approach I need 40 pins all 4 memory modules (8 for data+2 for read input clock and the read clock input per memory module).If I go for capturing directly from the chip I need 6 bits per color (18 total) plus one for the ADC clock to know when there is data so that's only 19 pins.Also I need one to get the synch signal in and 2 for the HSynch VSync to drive the capture board as explained earlier so add 3 to either case.I could use my other bigger devboard (Cyclone V GX starter kit) but then i'm restricted on GPIOs unless I buy a module that adds 3 40 ping GPIO headers, that I will eventually get but not yet.

author: miguelvp
author_rank: Super Contributor
timestamp: June 14, 2014, 03:40:02 am
content: So I've heard from Wallco Inc and they told me that it's going to be 2 to 3 weeks until they can ship my order so I went ahead and asked them to add the 8 pin DINs for the Genesis which they did.In the meantime I decided to use the FPGA to generate the VGA signal to start tapping into the SuperScan2.First thing was to make sure the SuperScan was locking and converting the signal to composite (meaning the data is being captured and converted to NTSC) using the same patern as in the previous post.Then I did push the menu button on the SuperScan and that brought up the OSD driven by an MC141540P4 OSD CMOS (btw that's how I did setup my trigger)This is a single line encoded as composite.Also I took a picture of the back of the FIFO buffer to start mapping the 18 digital signals to the FIFOs where I will have to solder wires so I can feed it to the FPGA. I'm planning to use a IDE 40 pin connector cut so I can just plug it into the FPGA's GPIO (of course avoiding the voltage pins but I will use the ground pins). I added the pinout for the FIFO chips (D42280V), to the right of those is the ADC and to the left is the custom ASIC (where there is some gunk from a label I removed that was hiding traces) that feeds the stream to the rest of the system. By the arrangement it looks like the data is double buffered.My wife is watching TV so I can't see how the composite video looks on the screen, yeah, we only have one TV but I'll test it tomorrow and take pictures.Later I'm going to start looking with the scope the signals on the FIFO pins to see if I can see any data going by. I only need to probe the DO pins the read enable and read reset. Plus the read clock I guess.

author: miguelvp
author_rank: Super Contributor
timestamp: June 15, 2014, 06:04:50 am
content: So I got some progressFirst I wanted to make sure I could see an image out of the composite output of the SuperScan2 so I programmed the DE0-Nano so it will boot to the VGA pattern posted earlier, power it with the TV USB (Service) plug and feed the Composite input from the converted VGA to NTSC.Then I took it back to my office and started to probe the FIFO chips.The Write Clock WCK runs at 25.125MHz, this is what is used to store the data from the 6 bit per color ADC chip into the FIFOs.The Read Clock RCK runs at 12.690MHz, a bit faster than half of the Write clock.The reason for this is that the Write Enable is double buffered so it writes half to the odd chips and the other half to the even chips.The SuperScan2 specs talk about 32bit color, but it really only supports 5/6/5. The ADC is only 6bits per color and they don't use R0 and B0, only the Green channel uses all 6 bits, making it a 16 bit decoder.Now since they double buffered it, it really is using 32bits, tricky bastards.The output buffer (above the top inputs and below the bottom inputs) are read at half the frame rate all four chips at the same time, so the odd chips will have the odd field and the even chips will have the other half of the data.This is what DO1 (Half of R2 output) looks like in a single frame at 60HzThis is a closeup of a single line of DO1 (Half of R2 output) so it flips 16 times for every 256 analog outputs (what you are seeing there is 640 so 256+256+128)Looking at the green channel that uses all 6 bits, cycling from 0 to 255 will cause the inputs to flip these many times per color bit.G5 2 timesG4 4 timesG3 8 timesG2 16 timesG1 32 timesG0 64 timesNow I have some soldering to do. Not sure if I'm going to solder directly in the inputs or the outputs. Using the inputs I can use only 16 wires for the RGB 5/6/5 Then use the Write Clock (one common pin) and Write Enable for each bank (two pins) The DE0Nano would not have any problems dealing with a 25MHz input clock from the chip. Also I can probably solder R0 and B0 to get the full 18 bits RGB 6/6/6. Total pins used 21. I will have to make sure I use a pin for the Write Clock that supports external clocks.The sync signals will already be in the FPGA since i'm going to pass the composite as an input (treated as binary) to extract the HSync and the VSync to feed into the SuperScan. It should not add too much delay compared to the original timing. This will add three pins for a total of 24 GPIOs.If the FPGA adds too much delay then I will have to use the LM1881/74LS221 to get the VSync and HSync by hardware using pin 4 from the Saturn connector to get the 5 volts needed for the chips.Like this:Now to solder and write some code for the capture. I think I'm going to just tap into the inputs since the FIFO buffers don't give me anything that I need since I will have to use twice as many cables to get 16bits color instead of 18bits color.Edit: I take it back the FIFOs give me a nice place to solder my 40 pin connector into the input signals and the clock plus write enableEdit: I just noticed the Read Clock is 5 volts, so that seals the deal to use the input signals and forget the FIFO buffering. Write Enable is over 3.3V (around 4V) so I will have to deal with that too.

author: Legion
author_rank: Frequent Contributor
timestamp: June 15, 2014, 04:56:39 pm
content: Looks like you're making good progress. Are you sure those 8 pin DINs will fit? I bought a few from digikey that looked like they'd fit my Master System. But the top two of the pins on the SMS jack are offset. More like a horseshoe instead of a circular arrangement.

author: miguelvp
author_rank: Super Contributor
timestamp: June 15, 2014, 07:13:13 pm
content: Quote from: Legion on June 15, 2014, 04:56:39 pmWe'll find out in 2 to 3 weeks, for the price I don't mind taking the chance. The 10 pin one looks like it will fit at least the pins not sure about the barrel. The 8 pin one on the back of the Genesis looks like a standard patern,.If it doesn't then I guess I'll have to purchase the adaptor or bend the pins that don't align, or yank them out and drill a hole where they are supposed to go.Before soldering I think i'm going to work on splitting the c-sync signal (pin 1 on the Saturn) so that the FPGA will produce the right polarity HSync and VSync pulses. I'll figure later how to deal with the full composite video to get the signals since they live in the lowerr 500mV of the signal. I might have to resort to the LM1881 since it will give me the back porch information.I don't expect all this to give me the final solution either since the write clock and the sampling clock is determined by the SuperScan board, so it's just to wet my feet. Eventually I think a board that has all the needed hardware and a true 8 or 10 bit ADC decoder so I can control the pixel clock with the HSync VSync and backporch information to make it as pixel exact as I can, maybe even substitute the FPGA eventually with a PSoC 4 or something cheap like that.But if i can get it to record video into the microSD card as a proof of concept then i'm more than half way there

author: Legion
author_rank: Frequent Contributor
timestamp: June 15, 2014, 08:33:51 pm
content: Quote from: miguelvp on June 15, 2014, 07:13:13 pmIf you can get it working with good image quality you should sell them. Those Micomsoft devices go for ~$400.

author: miguelvp
author_rank: Super Contributor
timestamp: June 16, 2014, 03:45:30 am
content: Market is so small that I don't know, but maybe! I always wanted to design a board, this could be a good excuseLittle progress today with some frustrations.This is my triple channel up to 330MHz 8 bit per color VGA DACIt hooks directly into Altera compatible GPIO headers (the BeMicro CV has one as well).By looking at it you will figure that it extends the connector to use the unused pins, right?So I was trying to use pin1 since it's a clock input, and couldn't see the signal at all, played with buffers and all kinds of i/o input configurations, nothing.Hooked the scope to the signal and it was fine but I couldn't see anything if I probed pin 1 with the scope on the FPGA. Then it dawn on me to do a continuity test and NOTHING!.Detached the board look on the bottom:It's not connected at all! why wouldn't they just add the needed traces between the connectors totally escapes me. I mean, they even have the unconnected pins soldered.Well I placed it on pin 1 of the opposite header and that's all it was. What a waste of a Sunday.I can get the signals and they only have 50 ns delay on the rising and falling edge.Bottom one is the original signal top one is the one coming out of the FPGA

author: Ed Herdman
author_rank: Contributor
timestamp: June 16, 2014, 11:37:44 pm
content: @ miguelvp: Sorry for being late, but I believe that sellers of Genesis RGB cables can tailor the sync type. You wanted composite sync, right? I am fairly sure that at least some eBay cable makers will add that for you.Quote from: Legion on June 15, 2014, 08:33:51 pmThe Framemeister does, but not the PEXHDCAP, the PCI-E card, or the older series Micomsoft upscalers (I've owned three of the older Micomsoft scalers myself, and sold one on).I'm interested to see what goes on with this project, but I think that a large part of Micomsoft's money is spent on ensuring compatibility for different devices.Of course, even with the newest Micomsoft upscalers things aren't quite plug 'n' play; there's a dedicated user base that fiddles with the settings to try and find what works best, so if miguelvp's project is flexible enough and priced right it might be worth buying. I'll wait and see how it turns out.

author: miguelvp
author_rank: Super Contributor
timestamp: June 17, 2014, 03:49:15 am
content: Quote from: Ed Herdman on June 16, 2014, 11:37:44 pmThanks for the info,But I figure that the common use is to make it SCART compatible and that uses Composite Video, so I might as well use that.Edit: I can always put a jumper that will select between C-Sync or C-Video. C-Video being the best result since using C-Sync I won't have access to the back porch frame data although I can do it via the FPGA since I will know when data is coming in (by looking at the earliest and allowing for a reset if the frame sync changes.For now I'm going to use the FPGA to generate those signals but I rather have the back porch burst information so the LM1881 is perfect for that. specially since in VHDL I might need to delay my Vertical sync by the width of the horizontal sync. But that should work.HSync is easy I just have to look at the falling edge of the C-Sync and if we are not currently on a VSync.To figure out the VSync I have to wait until it passes the width of the HSync to determine it's a VSync.I'm just going to attempt to get a crude proof of concept with the FPGA, the C-Sync signal and the re-purposed SuperScan2. BTW, I'm including a picture of the back of the device to show that Micomsoft had something to do with it back in 1996.Edit: Just to clarify that after the crude attempt I'm going for a final solution, maybe using a CPLD (Max V) unless I can use the PSoC chip, plus the LM1881 and a better ADC.

author: Ed Herdman
author_rank: Contributor
timestamp: June 19, 2014, 11:51:27 pm
content: Just wanted to bump in a word of thanks for the SuperScan2 picture back. I know some folks will be interested to see that.

author: miguelvp
author_rank: Super Contributor
timestamp: June 20, 2014, 03:30:35 am
content: Quote from: Ed Herdman on June 19, 2014, 11:51:27 pmYou are welcome, sorry for no progress. This work week has been a bear so no much spare time to do anything, I'll resume tomorrow.

author: miguelvp
author_rank: Super Contributor
timestamp: June 22, 2014, 06:34:52 pm
content: I got the HSync derived from the CSync from the FPGA, pretty much I just detect the rising and falling edges, at which time I find the current positive or negative pulses. Also I keep track of the minimum and maximum positive and negative pulses.So on falling edges I initiate the hsync and use the minimum negative pulse as the delta for the sync.Close up to the HSync pulse:Note the voltage levels, the derived one (top) has the right level for the superscan card.Edit: Also I'm currently using a 25.175(or close) MHz clock, I can make the delay of the signal smaller by increasing the clock that I use to sample the rising and falling edges.Now to work on the VSync, I'm planning to derive that from a negative pulse that is bigger than the minimum negative pulse to start the VSync Count, the wait until a negative pulse is back to the smallest negative pulse to end the VSync.I think at the end, this TI chip will make my life easier, seems more versatile than the LM1881http://www.ti.com.cn/cn/lit/ds/symlink/lmh1981.pdf

author: miguelvp
author_rank: Super Contributor
timestamp: June 22, 2014, 09:44:22 pm
content: Now I got the VSync out from the Composite Sync signal. The plan is for the FPGA (eventually the LMH1981) to create VGA level HSync and VSync signals to feed to the SuperScan 2. Then use the Saturn's RGB output to feed the SuperScan 2 RGB signals.Then get the digital version from the SuperScan board and feed that to the FPGA.Here is the VSync derived from the CSync using the FPGA:Here is the detail of the VSync signal and the CSync signal below.I need to wait for the connectors, but I'll start soldering the ribbon to the back of the SuperScan.In the interim I'm going to hard program the FPGA and see if I can get an image out of the superscan to my TV, driven by the derived HSync and VSync from the Saturn's video feed.

author: miguelvp
author_rank: Super Contributor
timestamp: June 22, 2014, 11:02:30 pm
content: Quote from: miguelvp on June 22, 2014, 09:44:22 pmSo I did that fed the CSync from the saturn and use some counters to do some red and green ramps (although I think I have a problem with the green algorithm or noise on one pin).But using the sync and counters it did make the SuperScan lock to the signal and convert it and display it on the TV.Granted there is unused junk on the bottom but I that's because I'm not deriving a pixel clock nor counting the total lines to derive the pattern, just wanted to lock to the signal so that works.Edit: To be clear what this is, the Saturn Composite Sync is driving the VSync and HSync, the FPGA other than deriving the sync signals is just putting some RGB ramps for a horizontal count and a vertical count. The color will eventually come from the Saturn.

author: miguelvp
author_rank: Super Contributor
timestamp: June 24, 2014, 02:55:33 am
content: So last night I did hook up the superscan to the video output of a laptop that lives on the TV (you'll probably seen it tucked under the TV bezel), but I had the resolution set at 1920x1080 and it didn't lock (way above the specs), Then I changed the resolution and it will lock but it's intermittent so I think I mess the superscan up.It does lock but then after 4 seconds or not it jitters all over, then it locks again. The OSD seems fine. Took it back to my office and it seems the clock feeding the ADC is out of whack every so often.Well it does lock at times so even if I busted it, I can keep going with the proof of concept anyways.So today, I soldered the 40 pin header to the back of the board. C-Sync will come from the Saturn and return H-Sync & V-Sync to the VGA cable.R0 and B0 are not connected, the pins for the ADC for those two values are on the other side (not used by the superscan since it does a 5/6/5 RGB), the 5V I left it unconnected and I left another GPIO wire unconnected so the pinout is organized. I checked for shorts and it all looks good.Note that the ground is soldered too, that is the same ground I was using to look at the digital data out of the ADC a week back.Here is how I'm going to wire it up to the VGA and the FPGA. The RGB signals straight from the Saturn to the VGA might not be strong enough but I should be able to see something and then deal with amplifying the RGB signals and change the offset.Edit: Of course I will connect the ground of the saturn (barrel) with the VGA ground and since the VGA plugs into the SuperScan VGA input it will be the same ground for the FPGA.I got an email that my connectors where shipped and it seems they'll be here tomorrow, so just in time for hooking everything up.I will report if the 8 and 10 pin connectors are compatible with the Genesis and the Saturn respectively.Once I have it all hooked up I will make sure I can get digital data out by probing it with the scope.Then I will program the FPGA to capture and translate the data into my 3 channel 8 bit DAC and display the output on a VGA monitor.Then the hard part starts, switching from the DE0-nano to the BeMicro CV, and buffering the data to the SDCard and figure out how to write to it so I can read it on the PC. That last part is going to take a while.Then later on, I'll move into using the LMH1981 to generate the sync signals and capturing the color burst by using the backporch signal in order to derive the pixel clock. But that is way far in the future. I will have to source a good triple channel 8 or 10 bit ADC that respects the clock given to it I did find some but didn't finish my research on that, then substitute the FPGA with a CPLD or maybe a PSoC. But first we'll see if I can get the digital data out of the board.

author: Legion
author_rank: Frequent Contributor
timestamp: June 24, 2014, 10:37:30 am
content: Quote from: miguelvp on June 24, 2014, 02:55:33 amI recently modded my N64 for RGB output. The signals are pretty weak so I used this RGB amp:http://www.ti.com/lit/ds/symlink/ths7314.pdfMight work for you.

author: miguelvp
author_rank: Super Contributor
timestamp: June 25, 2014, 06:22:29 am
content: Quote from: Legion on June 24, 2014, 10:37:30 amThanks that might get handy. I might be able to power it from the console connector.I did get the connector and you were right about the 8 pin ones for the Genesis. They don't match since they are round like forming an O instead of like the Genesis which forms an U.I was able to bend the two upper pins and got them to connect but eventually I broke one pin by trying to be able to plug the connector all the way in (good thing I ordered 3), but back to the Saturn.The 10 pin connector works as far as the pins go, the barrel had to be hacked a little, but I got it to work.So I soldered the connector including the ground and wired it to the VGA out that will go into the SuperScan2 and also wired it to the FPGA so it can derive the H and V sync to the VGA connector.I took a picture on how it will end up with the BeMicro CVNote that I used the wrong header for that picture, the other one is the Altera compatible GPIOHere is a close up of the BeMicro CV, which has enough fast memory and it also has a micro SD card for writing the final thing.So other than rotating the board and writing the final code it's all wired up.Next I'm going to re-attach it to the DE0-Nano and switch the pins to output the HSync and VSync to the other header so it will drive the custom VGA connector.I got also 75Ohm terminators with the same order and some T connectors (and dust caps for my scope) I already had a VGA to BNC (RGB,VSync,HSync) which I've been using for the scope captures, so I have to start a new FPGA project that only does the CSync to VSync and HSync and see what I get on the VGA connector.If it looks ok (with all the video coming out of the Saturn) then I will fire up the SuperScan2 and hook it to the TV via the composite output from the SuperScan to see If I can see a thing.Then I'll work on capturing the digital output and convert it back to VGA on the other header and see if I can get the full video live.Then to the BeMicro CV and writing the buffer and SD card code.Edit: So cautious and I soldered C-Sync to pin 8 (composite video) instead of pin 1 (composite sync). It's late so tomorrow I'll move it to pin 1. was wondering why my HSync and VSync looked wierd, it was picking the video signal of the composite as 1's, there was a pattern but not a good one

author: miguelvp
author_rank: Super Contributor
timestamp: June 26, 2014, 10:59:00 pm
content: So I had the Composite Sync connected to the Composite Video on pin8 instead of pin1I fixed it and hooked everything up including the Saturn. The FPGA uses the CSync to generate VGA Levels HSync and VSync, RGB goes directly to the VGA connector and that is fed to the SuperScan2 VGA input connector. Then i had the scope hooked to the converted Composite Video, meaning that the SuperScan2 is actually digitizing the video.Here is the Composite output with the Saturn Video on it, Not sure what the end of the frame is, seems like uninitialized data.Here is a single frame captured.eyeballing 16.68 ms (12x1.390ms) frame length.Edit: Here is the real direct capture of the Saturn Composite output same timings:Edit: For reference this is a direct capture of the Saturn Composite output at 16.74 ms frame length so about the same, it seems to be doing something weird.Edit: Oh this was the Red output from the Saturn, not the composite output. Added the real thing above.I'm going to move the setup to the living room to see what it shows on the TV, seems like it's only converting half the frame.I'll post a picture of the TV later when I test it.In theory I should be getting all the memory write clocks and data available on the FPGA that's the next step and I'll use the 3 channel 8 bit DAC to convert the digitized data to display it on a VGA monitor so I can tell that I'm actually digitizing the video.

author: miguelvp
author_rank: Super Contributor
timestamp: June 27, 2014, 01:10:41 am
content: So I moved everything to the living room since the composite output on the scope showed there was valid video.This first one is NOT the captured display, this is the Saturn connected directly to the TV using it's own composite.And this corresponds to the signal that we've been seeing all along (because the RTC battery is dead).So I connected the whole contraption using the FPGA and the SuperScan2 to the Saturn, and the TV to the composite output of the SuperScan2Powered it up and:Note the uninitialized data on the bottom, I might be doing something wrong on computing the horizontal sync signal, maybe it's interlaced and i'm supposed to only generate one HSync per composite horizontal sync. Since the original signal after the backporch is exactly twice as big as my synthesized one. But I can deal with that.So I powered cycled the Saturn and the bottom part of the frame buffered got some other values that make it look a bit better.But ever since I tried to push the SuperScan2 to 1920x1080p it looses lock often, it does the same with other VGA inputs as well so It's not due to the FPGA, something went bust but might be on reading the data from the FIFO so I might have a chance to get it stable.But since it's for proof of concept it doesn't really matter as long as I can get the code done and then use designed hardware for it.Next step is to half the horizontal sync signal so I get the full screen (should be easy) then to start writing VHDL to capture the digitized data.Edit: So what I've done so far is to convert the Composite Sync and RGB data into a VGA compatible signal that the SuperScan2 can process.Edit: Seems like the Saturn displays 320x224, that's why it's locking to only half a frame, pretty much is doing a 240p but locking at 480p, but that means that the SuperScan is really capturing the full image but it doesn't really support 240p so it's showing it at 480p

author: miguelvp
author_rank: Super Contributor
timestamp: June 28, 2014, 05:43:24 pm
content: FPGA progress,I finished setting up the top module as far as the top instance declarations and the pin assignments.I'm going to embed a portion of it in the post but also have the full top level schematic attached in the post if anyone wants to know the pins used for the DE0-Nano.The inputs are on the left and outputs are on the right and will describe them at the pin level name instead of the module name.C_SYNC is the Saturn CSync signal that is sampled with the pll clk clock at 25.175MHz (1007/2000 of the on board 50MHz clock). That generates HSYNC2 and VSYNC2 that goes to the SuperScan's VGA input along with the analog RGB from the Saturn (not in the diagram since it's analog and don't go through the FPGAI will use the HSYNC2 and VSYNC2 to GenLock with the FPGA to VGA monitor output (those are all the other outputs in the module) to give me a 640 x 480 @ 60Hz video that is converted back to analog via an up to 330MHz 3 video channel 8 bit DAC.Those signals are: BLANK_N, SYNC_N, VGA_CLK, HSYNC, VSYNC, RED[7..0], GREEN[7..0], BLUE[7..0] (8 bits)Edit: this is the VGA output board that sits on the other header of the DE0 Nano and the pins assigned on the schematic correspond to what this board needs:W_CLK is the ADC driven write clock from the SuperScan, That with WE_ODD and WE_EVEN (both active low) will tell the FPGA that data is available on the MEM_RED[5..0], MEM_GREEN[5..0], MEM_BLUE[5..0] as long as W_RST (active low) is not active.For now I'm just going to pass the digitized values straight to the VGA output and pad them with 0s (Edit: To convert them from 6 bits to 8 bits, I will ground R0 and B0 since they are not connected to the ADC). So I will end up with something similar to what it was on the TV but on a VGA monitor with the difference that now it will actually be displaying the digitized video converted back to analog.Then I will have to write a buffer that can hold a frame so I can double the values (no interpolation) so it outputs 640x480.I'm going out with the wife so I can't work on it until later tonight or tomorrow.

author: miguelvp
author_rank: Super Contributor
timestamp: June 29, 2014, 09:32:37 pm
content: So I wrote some VHDL code that will capture the RGB values (forgot to ground R0 and B0 so they were floating)Code:-- Read RGBprocess (wclk)beginif wclk'event and wclk = '0' thenif (wrst = '1') then -- I think this is causing some trouble.if (weodd = '0') thenred_signal(0) <= '0';red_signal(1) <= '0';red_signal(7 downto 2) <= mem_red;green_signal(0) <= '0';green_signal(1) <= '0';green_signal(7 downto 2) <= mem_green;blue_signal(0) <= '0';blue_signal(1) <= '0';blue_signal(7 downto 2) <= mem_blue;elsif (weeven = '0') thenred_signal(0) <= '0';red_signal(1) <= '0';red_signal(7 downto 2) <= mem_red;green_signal(0) <= '0';green_signal(1) <= '0';green_signal(7 downto 2) <= mem_green;blue_signal(0) <= '0';blue_signal(1) <= '0';blue_signal(7 downto 2) <= mem_blue;end if;elsered_signal <= "00000000";green_signal <= "00000000";blue_signal <= "00000000";end if;end if;end process;Then I used those values for the RGB DAC connected to a VGA to BNC cable to look at the signals:purple cap is a 75 Ohm terminator, green one is a 50 Ohm one.The "English" selection on the screen blinks with a red highlight, in this capture you can see when it's mid redIn this one you can see it at full red.Edit: this is what the original red signal looks like straight from the Saturn connector:Since I was getting digitized data and the signal look kind of ok I hooked it up to my adapted laptop LCD and only was showing this, the OSD reports 698 by 233 @59I think the WRST is forcing the other pixels to go to black (all zeros)The VGA monitor is not quite syncing at that resolution I have to modify the VGA HSync VSync to display at 640 by 480 at 60Hz and Genlock it to the Saturn Vsync.I was expecting a noisier image since it's just a long ribbon cable that is probably picking all kinds of noise. But at least it shows that i'm capturing digital data!Sorry about the crappy camera phone picture but I couldn't use my tablet to take a picture between the Saturn and the display right behind it.

author: miguelvp
author_rank: Super Contributor
timestamp: June 30, 2014, 01:31:17 am
content: So that cutoff reminded me to a previous test I did when displaying a color rampIn the code I have the video disabled after 639 ticks (640 pixels) but I forgot that i'm running the pixel clock at 25.175MHz, so it was truncating the horizontal line after just 25.382us I changed it to 1279 (50.80437 us).The captured signal on the scope now shows more dataAnd the VGA monitor (still locking at 698 by 233 @59) show more video.I have to do some timing measurements to disable the video at the right time since it's still chopping off the very end of the horizontal line but I know now that I'm capturing the whole data.I optimized the capturing memory code, well it does exactly the same but less lines of code.Code:-- Read RGBprocess (wclk)beginif wclk'event and wclk = '0' thenif (wrst = '1') thenif (weodd = '0') or (weeven = '0') thenred_signal <= mem_red & "00";green_signal <= mem_green & "00";blue_signal <= mem_blue & "00";end if;elsered_signal <= "00000000";green_signal <= "00000000";blue_signal <= "00000000";end if;end if;end process;

author: miguelvp
author_rank: Super Contributor
timestamp: June 30, 2014, 04:51:28 am
content: @Legion,Could you fire up your Saturn and go to the set language menu on your Sony CRT and take a picture? I just want to compare the colors since my language selection shows the dot as yellow (composite shows it as pretty much white) and the exit button shows a purple and the composite is more bluish.I just want to make sure my current digitized colors match what it should be on an RGB output.Thanks.

author: Legion
author_rank: Frequent Contributor
timestamp: June 30, 2014, 12:41:19 pm
content: Here you go...

author: miguelvp
author_rank: Super Contributor
timestamp: June 30, 2014, 04:12:43 pm
content: Thanks,That brings a future feature:Intensity grading emulation like the scopes do at the expense of a larger file.

author: Legion
author_rank: Frequent Contributor
timestamp: July 12, 2014, 05:56:09 pm
content: I modded my N64 for RGB output a little while ago. As part of the mod I added a THS7314 amp since the signals off the video chip are pretty weak. The amp only amplifies the R, G and B signals. Sync is not amplified. Sync is pulled from the composite video signal. I was playing some Super Mario 64 and I noticed that whenever the brightness level of the screen was high, say from a white screen, sync would be lost and the picture would distort. It kinda tears the top of the picture to the left of the screen.I'm thinking a sync stripper might help. Maybe a bright picture equates to a large comp signal and it swamps the sync info? I don't really have a good handle on how video signals are encoded. All the info about it just shows timing diagrams. I'd like to see something like a row of pixels and then the video signal below sectioned off to show what each pixel encodes as.

author: miguelvp
author_rank: Super Contributor
timestamp: July 13, 2014, 12:55:05 am
content: Quote from: Legion on July 12, 2014, 05:56:09 pmI think it will help, the color burst part of the composite might be affecting the TV sync, there is a simple lm1881 "circuit" that can probably be hooked up directly. I put circuit in quotes because they just solder the resistor and a couple of caps on the lm1881 and hook it directly to the power on the connector.Here is a picture of the composite signal out of many frames with that red green and blue pattern I've been showing.Here is a picture of a single composite horizontal line (red ramp part) I hope this helps visualize the data a bit. Also I pasted in the picture my trigger setting to lock into the vertical sync so you can see specific lines from your scope by scaling to see one line and scroll with the horizontal position of your scope to the line you want to look at.On the project, I'm still working on the buffer and learning about the Altera's Avalon specification specifically the streaming capabilities, and I also got that Chronos watch, I will try not to let me distract me from this projectTried to make a double buffer to store 2 lines worth of capture data but that puts the FPGA to it's limits so I rather stream the data to the memory and then to the SD card, but it's going to take some learning.

author: miguelvp
author_rank: Super Contributor
timestamp: July 13, 2014, 03:01:47 am
content: Quote from: miguelvp on July 13, 2014, 12:55:05 amFound the link to it:http://retrorgb.com/syncstripper.htmlThat should convert from the bottom signal to the top signal removing the color burst and the composite video.

author: Legion
author_rank: Frequent Contributor
timestamp: July 13, 2014, 04:08:56 am
content: Quote from: miguelvp on July 13, 2014, 03:01:47 amIf it weren't for the power requirement I'd probably do the sync stripper as in the linked article. So I think I'm going to do a little perf board circuit with some BNC jacks and a DC power jack and have that sit behind the monitor.

author: Legion
author_rank: Frequent Contributor
timestamp: July 13, 2014, 04:27:59 pm
content: Quote from: miguelvp on July 13, 2014, 12:55:05 amThanks for those explanatory images. Makes things a lot clearer. So it looks like the amplitude of a given color signal governs it's intensity. I'm guessing the combination of the HSync markers and the correct sampling frequency get you your individual pixel R, G and B values? The big gap between the full frame R, G, B bands is the VSync (front porch/back porch)?Is there any data contained in the initial color burst signal seen before the ramps?

author: miguelvp
author_rank: Super Contributor
timestamp: July 13, 2014, 06:51:01 pm
content: Quote from: Legion on July 13, 2014, 04:27:59 pmIt's a bit more complicated than that, I was displaying 3 color ramp bands first red then green then blue that's why they show nicely on the capture, but if they were combined like any regular pixes normally is, the video signal needs to be split into YIQ or YUV (the difference is just a different coordinate system for the colorspace.http://en.wikipedia.org/wiki/YIQhttp://en.wikipedia.org/wiki/YUVOnce you have the YIQ or YUV you can convert it to RGB using some simple matrix multiplications.This article has a more detailed explanation if you want to dig deeper:http://codeandlife.com/2012/10/09/composite-video-decoding-theory-and-practice/Quote from: Legion on July 13, 2014, 04:27:59 pmOn the signal whole signal it goes this way:Vertical sync | Vertical Back Porch | Video Lines | Vertical Front Porch (repeat next frame)The Video lines consist of the following:Horizontal sync | Horizontal Back Porch (Includes Color Burst) | Visible Video | Horizontal Front Porch (repeat next line)For completion, during Vertical Sync you can put close captioning on the non visible video lines, but that's another story. In Europe they use it for Teletext I think.Quote from: Legion on July 13, 2014, 04:27:59 pmThe Color burst does have information about the intensity of the video signal. it's 40 percent of the maximum value peak to peak, so from zero volts to the top of the color burst signal it represents 20 percent of the video signal value.So the maximum signal will be past the scope screen where I placed the 100.On top of that the Color Burst contains the color subcarrier , that will help you to find out the pixel clock (315/88 MHz for NTSC) and be able to mix different signals to level the colors based on the amplitude of the color burst of both signals and adjusting for pixel clock rates.More info:http://en.wikipedia.org/wiki/ColorburstMore info on dot clock rates (pixel clock) for different gaming systems:https://pineight.com/mw/index.php?title=Dot_clock_rates

author: Legion
author_rank: Frequent Contributor
timestamp: July 15, 2014, 01:38:04 am
content: Thanks for the info. I especially liked the codeandlife article.

author: Legion
author_rank: Frequent Contributor
timestamp: July 19, 2014, 07:37:12 pm
content: I made the sync stripper and it fixed the sync problem on white screens.

author: miguelvp
author_rank: Super Contributor
timestamp: July 19, 2014, 08:18:32 pm
content: Nice,No progress here, other than while adding a 500GB drive to make space for the Xilinx toolchain for when I get my Papilio Duo, my computer wouldn't boot.It's all good now, the memory got unseated when moving it around I guess and it wasn't giving me warnings, nor video and being an old system took me a while to resurrect it.And since I had 2GB laying around I upgraded the memory as well.