OK, I just read though the whole thread.

If you want a non FPGA/CPLD approach, use a maple/maple mini. The STM32F103 has enough processing speed to read the video data and send it straight to its USB FIFO buffer, It is the PC's responsibility to read the data out fast enough. It even has enough ram to buffer a few frames to make it all go a lot smoother.

I have clocked the stm32f103 at a reliable 400kbytes/second (There can not be any other peripherals attached to the USB host and best if it is not via a hub) Latency is 1ms on USB high speed which means no handshaking, it'll be a one way street with CRC incorporated.

Reconstructing the video in real time on the PC is beyond me. I tried in Python but i cannot do it fast enough with Tkiniter. PyGame library would help but I found converting from 2bit to a RGB value takes too long.

If capturing is what you want, AV is what you need. a USBCAP chinese thing is only a couple of dollars. A CPLD and buffer to do the frame conversion will be under $10.

Hey,

Yeah its VGA, wouldn't be hard to output composite instead (I've prototyped it though the consensus was VGA instead). Even easier and more accurate would be pure digital into a PC.

There isn't a schematic and it uses a CPLD and lots of ram to buffer/sync the images.

You would need a fast and reliable method of getting data into your PC. 160x144x2bitsx60 frames a second = 2.764800 million bits per second, that is without any packet overhead. This is not something your arduino can do over a serial connection.

~350kbytes/sec is quite fast. You can drop frames and get a teensy to send data to the PC pretty easily but how many dropped frames is acceptable?

I think eBay has VGA video capture boxes, or even VGA to composite adaptors.

Or use some kind of compression, RLE would compress the data stream failry efficiently. Then how would you go about decompressing and reconstructing the video on the PC side?

If you want to record, the easiest solution is a hardware GB to AV out module.

1. This is VGA, I'd like video capture into PC and / or AV
2. I don't see the schematic, I'd like to make it myself instead of buying
3. I didn't know if someone's done something, alternative solutions should not be attempted, but now I know

Don't bother...

http://bennvenn.myshopify.com/products/ … r-your-dmg

Ok, so back to the original idea of video capture / AV without FPGA.

I was browsing the web for some inspiration and found a couple of threads about NES emulation using Parallax Propeller. I am not very familiar with that uC so I don't quite buy that a full blown NES emulator could be made. But I don know that it is powerful enough to make almost SNES like games (e.g. http://www.instructables.com/id/El-Juga … -Console/)

From what I understand it can be clocked to 80MHz and SoC among other things has the video signal generator. With this in mind it appears that it could be used for VGA or NTSC / PAL signal generation for the gameboy. And it costs $8.

Is anyone familiar with Parallax Propeller?
How do you estimate the possibility of realizing this project with Propeller?

PS
Propeller datasheet https://www.parallax.com/sites/default/ … .4.0_0.pdf

Yes, I would like to help test that Luftek.

✪

Great to hear some progress has been made. I think the problem may be that interrupts on the Arduino (or even interrupts on microcontrollers of this speed in general) are just too slow. Have you tried capturing the clock as data on the same port as the actual data bits to verify that you're reading the data bits at least once per the Game Boy's clock cycle?

Well, I gave it a go. A few weeks back I sat down and attempted to read the data bits into my serial monitor. I tried a hundred different sketches using different methods of reading ports, reading pins and using interrupts.

AF one point I was getting a bunch of 0's and 3's which is how a gameboy screen boots when there is no cart inserted (having internal pullup resistors in the data bus) meaning all 1's or 0's. Perfect. The only problem I had was that I was not properly utilizing v or hsync. So the monitor was simply reading anything and everything as quickly as possible.

When I tried interrupts on the clock trace, I couldn't get the to work AT ALL. Not once. I tried everything. I tried with an arduino nano, uno and mega but nothing worked with interrupts.

I think the problem may have been that I was using the port as a data port which also contained the interrupt pin.

In any case, I got data at one point, but nothing useable...yet.

If you haven't seen it already, there is some new interesting discussion about NeX's video out mod here: How is the VHS capture card made?.

Thats good. Yeah, I happily use Bootcamp paired with Parallels for all my Windows Software/Hardware needs. I even got a 32 bit XP virtual machine for all my really old stuff that require 32 bit windows. Running those in Coherence mode I almost forget I'm even virtualizing cause the mac/win apps run side by side.

I'm just saying. I'm gonna use bootcamp or find a PC. This definitely won't stop me from doing the project

Everyone does really. Couldn't you run something like Parallels on your mac or are you rockin' a PowerPC?

So I was wondering which language to use Verilog or VHDL. So for I found a bunch of reading on the former and not so many introductions / tutorials on the latter. Thus for now I'm gonna stick with Verilog...

So it appears that FPGA manufacturers tend to discriminate Mac users