Some thoughts on further steps:
1. Remember my suggestion about webcam based approach? Well it looks like all the web cams are 30fps and GB is 60 fps so it's not an option. There are probably some faster web cams but they're expensive.
2. I PM'ed Nitro about clock master and here's how he'd go about it:
Nitro2k01 wrote:You need a loop, where you do something like the following. This assumes digital pin 0 is connected to the clock input of the Gameboy.
PORTD |= 1; // Turn on clock signal
(Wait a little and/or do something.)
PORTD ^= ~1; // Turn off clock signal
(Wait a little and/or do something.)
PORTD ^= 1; // Flip clock signal (xor)
(Wait a little and/or do something.)
PORTD ^= 1; // Flip clock signal (xor)
(Wait a little and/or do something.)
If done perfectly, you now get a perfect square wave output. It does not have to be perfect, but...
1) It can't be too fast, or the CPU or cartridge maybe will not be able to do everything it needs before the next clock pulse arrives.
2) A little deviation from the correct clock frequency is tolerable, as long as the long term average is correct. For example, you might send a slightly too slow clock during the period when the data is being sent and a slightly too fast clock during the blanking periods when no data is transmitted. Even though the CPU itself is fine with a slightly varying clock, the audio output may get artifacts from this, like maybe a buzzing or FM type effect.
However he also mentions that he's not sure if after all it can help us to get the video and we gonna need to use assembly. That's a bit discouraging, but ok, let's keep this in mind.
3. FPGA. I personally like this option because at least I'm sure it CAN be done with FPGA. However I have no idea how big a board we gonna need for that (how big = how expensive). A good powerful board (that will most certainly do the thing) will cost around $150. I'd buy one if have no other choice, but at the moment it's cheaper to buy an SNES or its clone and tear it apart and use SGB.
5. VRAM - uXe posted that it is hardly doable (although a number of other things can be done with this approach, so the idea is still brilliant IMO).
Other thoughts.
Now let's look one more time at what we're facing.
- It's a 4MHz (rough estimate, I don't count dead time) 5-channel data flow.
- Even with 2GHz uC (let's assume one exists) we'll have 500 cycles to monitor 5 channels and send data to PC as fast as 4Mbs (or if we're assembling the frame in uC then 2,7mbs but then we need cycles to assemble the frame).
- Even making uC a clock master - we have predictable timing BUT it's still 4M just more precisely measured.
Looks pretty bad now. The only one cheap enough viable option is using SGB. What I don't like about this approach (and rvan has already mentioned this) is that we end up with the de-digitized signal that we'll have to re-digitize. It will work, but it's like turning your night lamp via Internet through a proxy in China (unless you're in China but then replace China with USA).
Apart from that it's either FPGA or some cam-corder type. Thoughts?
