friendofmegaman
Offline
CA

I was just about to post the update version, but yours is almost identical (but a but better since you made functions for signal reading). But I made minor changes since then:

1. Instead of sending a frame in a loop I send it as array by single Serial.write(frame, 5670) and then memset frame to 0
2. The frame separator now is 0x1E001E00 as opposed to 0x1E00 (it was mixed with actual data a couple of times). Which actually raises a problem - what's the best way to separate frames?

Here's the pastebin http://pastebin.com/Crs2FVE1

Jazzmarazz
Offline
Michigan

I think you pasted the wrong one. tongue

friendofmegaman
Offline
CA
Jazzmarazz wrote:

I think you pasted the wrong one. tongue

Oh, no I just updated your code with the aforementioned changes I made

Jazzmarazz
Offline
Michigan

Hah, yeah. I copied the wrong one. tongue

Jazzmarazz
Offline
Michigan

Hm...there has to be a better way of separating the frames. Chances are that the new separator could still become mixed with data. Slimmer, but still not 100% mix-proof.

OH! Describe to me what is happening on the PC-end. step-by-step. I am not familiar with that software.

Last edited by Jazzmarazz (Apr 25, 2014 12:00 am)

friendofmegaman
Offline
CA

I think I'm starting to penetrate why my script doesn't work and why I'm missing bytes. The problem is that it doesn't wait for the signal to come, while it should. Although the Teensy frequency is 24 times bigger than GB's still a clock signal from GB may come when Teensy is busy doing something else (checking edge for example, or writing to serial port). This I believe might be the root of the missing bits problem.

The solution may be using interrupts, however rvan reported he was unsuccessful. Also rvan, could you please share you code?
The interrupts based workflow may look like this:

1. Interrupt for CLOCK signal, the handler will read pixel data from the respective pins and update pixel offset counter
2. Interrupt for HSYNC, the handler will reset offset counter
3. Interrupt for VSYNC, the handler will send the frame to PC and reset offset and line counters

Another approach will be using Teensy as mere logic analyzer, then the workflow will be somewhat simplified version of the above. Each interrupt handler will send a byte to pc. In case of data it's a pixel byte in case of sync signals it some byte like F0 for VSYNC and E0 for HSYNC.

There's one more concern though. What if a signal arrives while Teensy is handling the previous interrupt? This may me the reason why rvan's attempt didn't succeed. But I'd really like to see the code in order to avoid wasting time on re-doing something that has been done already.

Last edited by friendofmegaman (Apr 25, 2014 12:21 am)

friendofmegaman
Offline
CA
Jazzmarazz wrote:

Hm...there has to be a better way of separating the frames. Chances are that the new separator could still become mixed with data. Slimmer, but still not 100% mix-proof.

OH! Describe to me what is happening on the PC-end. step-by-step. I am not familiar with that software.


Sure.
I use python for prototyping or testing ideas it's a very easy to use multi-paradigm (to some extent) language.

Anyways you need to install python 2.7 and PySerial library

Then you need to check the pseudonym for your serial devise where Teensy is. For *nix systems it should be something like /dev/tty.usbXXXX where XXXX is some string. I've no clue how it's addressed in Windows though.

Then this is code I'm using

# Plug in serial lib
import serial

# Define some parameters
port = '/dev/tty.usbmodem34521'
speed = 4000000

# Buffer length doesn't affect the result much
buflen = 100

# Create instance of the Serial object (it's part of the serial lib that's why it's called serial.Serail())
ser = serial.Serial(port, speed)

# Open the file to dump recorded data to
fd = open('screen_data.bin', 'wb')

# Set up the reading loop through the KeyboardInterrupt exception handler so we could stop it by pressing CTRL+C
try:
    while True:
        # Read data from serial
        data = ser.read(buflen)

       # Write to the file
        fd.write(data)
except KeyboardInterrupt as e:
    print 'Shutting down'
    # Close file handler
    fd.close()

    # Close serial communication
    ser.close()

And then I suggest you use your favorite plotting / visualizing software to build a frame. Let me know if you need more details.

This is of course a temporary thing to verify consistency of the data. Once it's done I'll be using SDL to show the actual video.

Last edited by friendofmegaman (Apr 25, 2014 12:21 am)

Jazzmarazz
Offline
Michigan

~snip~

Last edited by Jazzmarazz (Apr 25, 2014 12:37 am)

friendofmegaman
Offline
CA
Jazzmarazz wrote:

Hm...there has to be a better way of separating the frames. Chances are that the new separator could still become mixed with data. Slimmer, but still not 100% mix-proof.

The only 100% solution is make each pixel data byte start with 0, and then delimiter start with 1. I have some ideas how it can be done, need to check.

Another question is has anybody benchmarked the USB serial speed of Teensy 3.1? According to this page: http://www.pjrc.com/teensy/usb_serial.html it is not very big and we need to keep data to transmit as small as possible as I'm trying to do by packing it into an unsigned char array.

Last edited by friendofmegaman (Apr 25, 2014 12:43 am)

nitro2k01
Offline
Sweeeeeeden

One of these days I'll give this a shot using a microcontroller as the clock master for the DMG. Should solve any and all timing problems.

friendofmegaman
Offline
CA
nitro2k01 wrote:

One of these days I'll give this a shot using a microcontroller as the clock master for the DMG. Should solve any and all timing problems.


Oh, neat idea! If my current research directions fail, I'll get to it too.

Last edited by friendofmegaman (Apr 25, 2014 12:46 am)

rvan
Offline
friendofmegaman wrote:
Alley Beach wrote:

a pi wouldnt work?
I have a beaglebone and an XMOS pcb i can donate if you think you can make it happen on one of those

It probably would, but until we know why exactly a 96MHz microcontroller cannot handle LCD data it's just trial and error sad
Thanks for an offer though smile

I would actually be quite keen to try things out on a BeagleBone, one reason being that a board like this would allow for some interesting video out possibilities (such as with the DVI Cape), but as friendofmegaman says, this should by rights be doable on a Teensy (although I haven't gone and computed clock cycles thoroughly).  And I suppose friendofmegaman gets first dibs on hardware.

Jazzmarazz wrote:

I have another project using one of the Teensy's so once mine arrive, I'll jump in to this mess.

Great to hear you're on board.

Jazzmarazz wrote:

2. Pins default to input, so your for pinMode for-loop is unnecessary.

I just tested this on the Teensy, and this seems to not be the case.  This is possibly different from Arduinos.  Explicitly declaring pins makes for more readable code, too.

Jazzmarazz wrote:

Hm...there has to be a better way of separating the frames. Chances are that the new separator could still become mixed with data. Slimmer, but still not 100% mix-proof.

I had a think about this, and I think the only foolproof way is to store only three pixels per byte and use the remaining two bits to store new line and/or new frame markers.  Another option would be to simply count pixels (assuming we always begin sending at the start of a frame) and hope we don't drop any bytes, but that is not as robust.

Jazzmarazz
Offline
Michigan
rvan wrote:

I just tested this on the Teensy, and this seems to not be the case.  This is possibly different from Arduinos.  Explicitly declaring pins makes for more readable code, too.

Well, what the hell? That is very good to know, but very disappointing at the same time...

rvan wrote:

I had a think about this, and I think the only foolproof way is to store only three pixels per byte and use the remaining two bits to store new line and/or new frame markers.  Another option would be to simply count pixels (assuming we always begin sending at the start of a frame) and hope we don't drop any bytes, but that is not as robust.

I like that, 3 pixels per byte and a 2-bit marker. Serial is sure fast enough to handle that.

rvan
Offline
friendofmegaman wrote:

Also rvan, could you please share you code?

I will do so tonight, at which point I also hope to have caught up with this thread.

nitro2k01 wrote:

One of these days I'll give this a shot using a microcontroller as the clock master for the DMG. Should solve any and all timing problems.

This is a very interesting prospect; I think I will try this out quite soon (when I have time; not a lot over the next few days as I have a friend visiting).  Nice to see you're following along by the way, nitro.  On a side note, do you know how the Game Boy Camera behaves at low clock speeds?  I can confirm it works at half speed, but I am interested in how far it can be underclocked.

friendofmegaman
Offline
CA
Jazzmarazz wrote:
rvan wrote:

I just tested this on the Teensy, and this seems to not be the case.  This is possibly different from Arduinos.  Explicitly declaring pins makes for more readable code, too.

Well, what the hell? That is very good to know, but very disappointing at the same time...

rvan wrote:

I had a think about this, and I think the only foolproof way is to store only three pixels per byte and use the remaining two bits to store new line and/or new frame markers.  Another option would be to simply count pixels (assuming we always begin sending at the start of a frame) and hope we don't drop any bytes, but that is not as robust.

I like that, 3 pixels per byte and a 2-bit marker. Serial is sure fast enough to handle that.

Guys, have you actually benchmarked USB serial in Teensy? I'm a bit worried because of this page http://www.pjrc.com/teensy/usb_serial.html. It doesn't show very high speed which means we might need to keep our data as small as possible.

Jazzmarazz
Offline
Michigan

I was thinking that your baud was a little crazy. Care to reduce it to something more common?
No, I have not benchmarked a teensy.