Does this mean that is is not possible to capture a continued data stream with a typical logic analyser
This is in itself another possibility. You could use say a Saleae USB logic analyzer and their API for getting data. As long as you are able to record and convert the logic stream uninterrupted on the PC, you have recording right there.
friendofmegaman wrote:Next - Nitro's suggestion to use uC as clock master. I don't understand how (in case of Teensy at least) it solves the issue of only 24 clocks available to do something with the data? 24 is an optimistic estimate.
This would probably require underclocking the Game Boy (unless using a faster microcontroller). Obviously, this isn't ideal. However, if the Game Boy is driven by a clock signal synthesised by the microcontroller, then pixels will arrive at a predictable cycle relative to the work loop, and can be read directly, with no need for polling or interrupts. Has anyone (nitro, most likely) tried single-stepping the Game Boy's processor? Being able to do so would aid in designing a solution using this approach.
Nailed it. The advantage is the predictability. Once you know display data is about to come, you can send CPU clock pulses and blindly scoop in the data at the correct intervals until the end of the line. I'm claiming this to be doable with, not a 96, but with a 24 or maaaybe even 12 MHz AVR, and I'd be up for the challenge, if I can be bothered.
Details: Back of the envelope calculation of the data rate: 160*144*60*2=2764800 bits per second. An FT232 can handle up to 3 Mbaud communcation. Accounting for 1 start bit and 1 stop bit, that becomes 3000000*8/10=2400000 bits per second actual transfer rate. Too slow, darn. So the choices are to underclock the CPU to 87% of it's regular speed, or come up with some form of compression. RLE compression should work well enough to most situations, as a typical game screen will contain at least 13% repeated data. (That is, the same tile repeated multiple times vertically.) This leaves one problem, though, which is that the screen data isn't sent at the same rate from the GB CPU. It's done in bursts, one line at that time, and then takes a break in the HBlank and VBlank periods, so you would need a serial data ring buffer. But meh, should be easy enough. (Famous last words.)
As for the teensy code. I'm not familiar wiuth how it works, but mostly likely the CPU will be busy for a short while, while the USB processing code is running. In that period, you're missing display data. And also, please don't use interrupts for this. Interrupts are great when you need the CPU to do something else, and still have the ability to be interrupted, but each interrupt does have an overhead which means that they're not suitable for this project. Use a polling loop instead. (For example.)
