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
Good work so far, friendofmegaman.
I've started writing some Teensy code which uses interrupts, and hope to have my DMG wired up tomorrow. I'll also test your code on my setup once the hardware side is ready.
Awesome! I'm curious to know how interrupts will do 
Currently I see two directions of research:
- Writing C code directly without Arduino
- Optimizing or overclocking the board
But right now I'm demoralized so fuck it me goes to bed
So when decrease the clock speed on Teensy I observe worse readings of HSYNC... It appears that clock speed is still not big enough...
You could try ignoring HSYNC and just start a new line manually every 160 pixels? I also wanted to suggest sending the data after the 144th line where it looks like there is a nice gap in the timing, rather than on VSYNC?
Good point, however I'm receiving the full frame all right, so this part seems to be fine.
As for ignoring HSYNC... not sure it's a good idea it should work as is. It seems that Teensy clock can't handle it. But hell it's 96 MHz, it should suffice to take care of 4MHz data.
Well... I see that Teensy only reads 5-6 pixels of each line. As if bloody HSYNC comes too frequently. Don't know what the fuck can I deduce from that 
In the previous pictures actually CLOCK should be swapped with DATA1, but that doesn't change the point.
I double checked the way my bits are packed - it's fine. Now I tend to think that I push data to serial when the frame is not ready yet. I have no idea why is that...
I confused pins in my Arduino code. However simply fixing them didn't solve my problem so I started in depth analysis
I threw together a dirty script that would turn a Teensy in sort of a logic analyzer.
Here's the result:
Data looks pretty reasonable. We see CLOCK, DATA0, DATA1 go high pretty frequently
HSYNC on each new line, VSYNC on each new frame
It appears that I was getting most of 0 bytes because of the way I pack data in the Teensy. Now I need to resolve that and hopefully I'll get a frame. If it won't work after that I'll get into state of demoralization.
Ok, I had spare 10 minutes at work and started analyzing the problem.
First things first I downloaded the dataset provided by FlashingLEDs (here) and tested my algorithm ont it. I found a couple of minor errors, but for the most part it works fine.
So the problem is either I don't read correct data from the Teensy for some reason or my uC code has some error I haven't noticed yet. We'll see...
Here's also a fragment of hex dump:
00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000000a0 00 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000c0 00 00 00 00 00 00 00 00 00 c0 00 00 00 00 00 00 |................|
000000d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000110 00 00 00 00 00 00 00 00 00 c1 00 00 00 00 00 00 |................|
00000120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000140 00 24 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |.$..............|
00000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000160 00 00 00 00 00 00 00 00 00 c0 00 00 00 00 00 00 |................|
00000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000190 00 c2 03 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000001e0 00 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
This is why I get black screen (apart from the stripe on the left). Almost all the pixels are zeroes. I think the problem is timing. The clock signal is falling edge, but maybe I'm reading data bits too soon... EDIT Nah, it's a stupid assumption - falling edge is falling edge. Ass!
So, my first experiment was a failure.
The objective was to capture a screenshot of LCD. What I did:
1. Checked how FlashingLEDs guy processed bit data to build the screenshot (here)
2. Implemented it in the Teensy
3. Collected frame data via serial
4. Tried to visualize it
And here's the result:
and it was supposed to be Tetris
I receive consistent data on the PC - each frame has 144*160 pixels, which is a good sign. Now I need to analyze the results thoroughly and double check everthing. I definitely am missing something here.
My Teensy code (rather dirty since I was too eager to see the result, didn't have time to do it by the book):
http://pastebin.com/1GUhf2nR
On the PC side I used pyserial to collect data:
import serial
port = '/dev/tty.usbmodem34521'
speed = 4000000
buflen = 100
ser = serial.Serial(port, speed)
fd = open('screen_data.bin', 'wb')
try:
while True:
data = ser.read(buflen)
fd.write(data)
except KeyboardInterrupt as e:
print 'Shutting down'
fd.close()
ser.close()
Then I parsed it and built a scatterplot using matplotlib: http://pastebin.com/AS4uesLh
Hopefully I'll find some time this week to play with it more, but currently I'm a bit loaded with my actual work. Anyways if you guys have ideas what is wrong with my code I'd appreciate if you shared. Cheers!
My Teensy will arrive tomorrow and I can finally start experimenting. I ended up purchasing Teensy 3.1 because it's the most powerful one. We'll see how much I'll be able to do with it.
In the meanwhile I prepared this breakout port:
It basically provides LCD pins 3 to 19. I decided to take out all the pins required to drive the the front PCB display and get input from buttons (already tested and it works).
I thought about interrupts as well. I don't see any difference in terms of performance between two ways of processing the signals, however I'm a bit concerned with cascading interrupts. It will probably work out fine, not sure though.
As for dead time I though to put the condition something like if (line<144 && offset<160)
Sending frames or pixels does not make big difference either with teensy. It's rather matter of taste. I just prefer taking as much as possible from the microcontroller. On the other hand, we may need to save clocks and outsource frame building to the PC.
Anyways experiments will show what's better.
Thanks for sharing. Yah, webcam protocol is way too long to implement (although not completely impossible).
As for signal processing. I have this in mind now:
1. Get the signals to Teensy (I haven't ordered it yet though, but I'm playing with Arduino UNO as proof of concept)
2. Update line and offset (a pixel in a line) as needed. Edges can be detected as clock==0 && clock_prev==1 (for rising edge) the other way around would be for the falling edge.
3. And then I'm hoping to be able to make a frame inside the microcontroller this way we'll save on bandwidth (which is not that relevant of course if we have 12 MBps) and take some work off the PC (which again maybe not necessary given the computational power of the modern PCs). To make a frame we need 160*144*2 bits, which can be represented as unsigned char buffer[5760] or unsigned int buffer[1440]. I'd go with a one dimensional array holding a frame as an unfolded matrix. Two dimensional is possible but it will take more RAM (since each pointer will take 1 byte in case of Arduino) and I want to preserve as much as possible in case I need it.
4. On the PC side I'm thinking of using (at least kick start with) pyGame - an SDL binding for python. Looks cross-platform enough for me. PySerial can be used to grab data from USB.
But I need to have my Teensy to test that
also check out the rectangular shaped thru hole LEDs, cover one side with electrical tape to prevent hot-spotting, and you can hot-glue it inside the case! done this myself, looks really great
Tried that and it's great indeed, but I want to try something different now
Thanks for the advice!
Hi there,
I know this topic popped up already (can't find where exactly) but I couldn't find the details I wanted. I'd like to use SMT LEDs and therefore I'm gonna need to place them inside the button. They're tiny enough to fit inside, which is good news, but how do I fix them in place?
Naturally I'll have to cut button holders (and maybe buttons themselves) for the wires. Wires will kind of hold LEDs in place but still it will be flaky I think.
So I'd appreciate any advice on that Thanks!
Oh, BTW, I remember someone mentioned that silicone buttons are easier to backlight - why is that?
gameboy weiß / weiss on ebay.de too
Oh, interesting Didn't consider that.
I'm pretty sure there are Japanese auctions or some Craiglist equivalents where you can get a lot of them for less than $100
ChipMusic.org / Forums / Posts by friendofmegaman