chipmusic.org is an online community in respect and relation to chip music, art and its parallels.
You are not logged in. Please login or register.
ChipMusic.org / Forums / Posts by friendofmegaman
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.
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.
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.
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.
I think you pasted the wrong one.
Oh, no I just updated your code with the aforementioned changes I made
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
Looking through your code and ... I have a few comments.
1. Not naming your pins drives me nuts and I worry that just having them numbered could mix them up with variables.
2. Pins default to input, so your for pinMode for-loop is unnecessary.
3. And as always, COMMENT UR SHIT! haha....
Yah, it was just a quickly hacked PoC code (that didn't even work), but you're right I need to clean it up and comment.
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 
Thanks for an offer though 
With my simple testing code (as follows) I think it was the ISR being called which took too many clock cycles (I recall reading 10 cycles of overhead somewhere). Getting away from the Arduino code will hopefully reduce this.
Let us know the results, because in theory I don't see how this is faster. The Arduino sketch is merely a wrapper for what you've written. It puts contents of setup() to main() and the contents of loop() inside the for(;;) loop in main. Of course I might be wrong
Nice. Where are we losing the clocks then... I mean, 96Mhz, how much time it takes to read data and send it to PC...
The idea I'm going to look into once I get home from work is to reduce the baud rate. Maybe it's a stupid assumption but I think that 4M baud rate takes quite some clock cycles. I'll let you guys know... I'm writing it here in case someone more competent reads it and verifies I'm on the right track (or otherwise).
I briefly looked at direct port access to read pin value like so (PIND & (1<<2))?1:0;
In terms of the .hex size it's no different from digitalRead(). What else can be done to optimize the code I don't know yet
While a new awesome voltage regulator from Thursday Customs is on its way are there any other solutions?
Can I use say 2 voltage regulator chips and set them to 5 and -19V?
This is just a thing that happens. The backlight didn't affect it in the other cases. They just go bad over time. You just need to replace the regulator board. This is why I'm working on developing a new one.
Oh great news man! This will save loads of GBs thanks for sharing
I have a couple of DMGs whose power regulator is always overheating, not much, but enough to tell that something's not right there. I know people reported the same problem several times here, but they had backlight panel installed while I have no mods whatsoever. Does anybody know what the cause of the issue might be?
Thanks!
I counted the average number of clocks between HSYNC's. It's approximately 800 and 800/144 = 5.5 which is exactly how many (in average) pixels I read for each line.
Little piece of hope is that there's something wrong in my code/setup because the picture I get doesn't make sense even for these 5 pixels per line (it's supposed to be the piece Tetris' frame).
As rot suggested I could optimize the thing by using plain C without Arduino overhead. I've no idea yet how much of overhead Arduino's ARM compiler puts there, but for some AVR chips it slows down up to 10 times.
ChipMusic.org / Forums / Posts by friendofmegaman
