friendofmegaman wrote:Sure, sorry guys I'm just loaded with work lately so things keep slipping off my mind. Here's the code (I know Jazz won't approve):
(Teensy only, won't work on Arduino)
Timer based
uXe has more or less said this, but I realized while I was out today that the reason your code doesn't work is probably because calling the timer ISR takes too long -- it will suffer from the same problems as external interrupts.
friendofmegaman wrote: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.)
This is right, but this code will (probably) only work on an actual Arduino. PORTx is emulated on the Teensy, and so slow. GIPOx_PTOR is what would be used on a Teensy, as uXe describes.
friendofmegaman wrote: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.
Yes, we're certainly going to need assembly for this approach.
friendofmegaman wrote: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.
If you're thinking about the SGB, do also consider the AGB + TV Adapter. And I'm fairly confident that some post-processing on the PC side can give us an image very close to the original.
friendofmegaman wrote:Apart from that it's either FPGA or some cam-corder type. Thoughts?
Using an FPGA sounds like the approach that is most likely to succeed, but I personally know nothing about FPGAs. The learning curve seems more daunting that ARM assembler.
Other thoughts: Is there another means of getting the raw data (the five lines straight out of the Game Boy) into the PC?
uXe wrote:Maybe direct control over the clock would be easier to achieve by having the microcontroller generate a variable signal that can be fed into the standard variable clock mod chip (what the potentiometer normally does - not sure if it is wired as a voltage divider or a variable resistor though?) as well as start / stop control over the clock mod - at least then there would be predictability?
I don't think that this would give us enough predictability. What we need to know is more or less at exactly which clock cycle on the microcontroller the Game Boy pixel lines are ready to be read. The microcontroller needs to clock the Game Boy relative to itself, rather than simply to a specific speed, as any clock drift would cause the data to potentially not be ready at the right time.
uXe wrote:...or try PWM for the clock?
The Arduino's PWM frequencies are in the 1-10 kHz range, so I don't think this is much use to us. I understand that the Teensy can reach at least 2 MHz, but that's pushing it. I have no idea how much CPU it uses.
uXe wrote:Also, don't forget that even though the Teensy 3.1 is 5V tolerant, it only outputs 3.3V - which the GameBoy CPU may or may not like?
A logic lever converter should work fine here, right? Is there any issue with switching them at high frequencies?
friendofmegaman wrote:Let's also get back to Flashing LEDs solution - there he used 2-SPI bus uC. We could try that. Although I'm not sure we'll be able to send data to PC at the necessary speed...
Getting the data into the microcontroller would still be a significant step forward. What are good options on cheap microcontrollers with two SPI buses?
friendofmegaman wrote:rvan, you've mentioned that when you put a byte to the array it takes a lot of time. Have you tried sending data directly to PC? This might work but also might introduce some delays (e.g. buffered USB data sent later)
I haven't tried this, but I don't imagine Serial.write((uint8_t)GPIOC_PDIR)
being faster than line[i]; = GPIOC_PDIR. I'll see what happens, though. I also
thought about unrolling the for loop and hardcoding the array item addresses,
but I think I would probably need assembly to make this worthwhile. (This
paragraph exists in a code box thanks to a BBCode bug.)
friendofmegaman wrote:You can call me crazy but uXe's old idea with Play Station eye doesn't seem that bad now. This thing (well, PS3 version for sure) can record data with 60fps. And they are ridiculously cheap these days I've just ordered 2 for $20. They are heavily used by computer vision guys - this is exactly what we need. There are drivers for multiple platforms. So it's an interesting thing to mess with. But I'd call it a spin off of this project.
I'm interested in seeing how this works out. Good luck!
