Search options (Page 11 of 19)

The subject says columns, you say rows. What is it you can not fix - rows or columns? Columns are fixed by heating ribbon cable below the LCD. I'm not sure rows can be fixed that way since the vertical ribbon cable responsible for horizontal pixels is tricky to get to and a big risk to burn the thing.

The image on the screen is built pixel by pixel by the LCD. So if the problem was connection between the pcb boards you'd likely to see some random dots or nothing at all.

I though about deploying a logic analyzer. What they do (if understand it correctly) is record a sample to the memory (e.g. flash) and then you read it to PC. A good thing would be to know how to build one and use for real time data processing.

Another option is FPGA. The way it works allows really fast signal processing. In fact in can be clocked by the gameboy and still be able to send data to PC. This is what a guy named Snesy did. I tried to contact him through several sources, but without any luck.

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.

Finally - DSP. I think logic analyzers are built upon these. However I've no idea where even start with that.

Any other options?

Before diving into the next idea it would be great to figure which of them will (given enough effort) guarantee success. Not some ugly hacked code that will fail 50% of time, but neat and reliable solution. We know it was done on FPGA.

Pros: it will solve this problem, it should suffice to have even more outputs (VGA and composite) and it can be even used as an adapter to plug a controller - so the whole "desktopification" module can be done with one (probably quite big though) board. Since it can have multiple clock domains, and programmed to do virtually everything (no teleportation though).

Cons: Prototyping boards from Atmega (as an example) cost around $80, not only they are programmed in very strange way I can't find any good comprehensive introduction in programming FPGA.

I need to reflect on this... and wank...

Thanks for sharing. It's definitely an interesting reading, but still 24 clocks guys, don't be overoptimistic

It's still 10:30 on the west coast

I actually tend to think that this idea was doomed from the very beginning. Let's theorize a bit. In order to read the data correctly we need to wait for each clock signal to come and then process it. Clock comes 4M times per second. Teensy over-clocked frequency is 96MHz. 96M/4M = 24.  At the very best we have only 24 cycles to handle our clock data. Is it enough with all other things intact (other interrupts etc)? I'd say no it is not.

Loop is empty because the workflow is based on interrupt handlers. And they work fine otherwise I wouldn't get any data. In fact I tried to put some constant value there and I can see it appear in my hex dump. So this is not the problem. The code works just fine. And it seems that the only explanation of missing clocks is one I mentioned in the previous post.

I can only detect 70 clocks between two HSYNCs...

The sketch:

#include <avr/io.h>
#include <avr/interrupt.h>

const int pVsync = 2;
const int pClock = 3;
const int pData0 = 4;
const int pData1 = 5;
const int pHsync = 6;


volatile unsigned char pixels_in_line = 0;

void setup(){
  Serial.begin(1);
  
  pinMode(pClock, INPUT);
  pinMode(pHsync, INPUT);
  pinMode(pVsync, INPUT);
  pinMode(pData0, INPUT);
  pinMode(pData1, INPUT);

  
  attachInterrupt(pClock, readClock, FALLING);
  attachInterrupt(pHsync, readHsync, RISING);  
}

void loop() {}

void readHsync(){
   Serial.write(pixels_in_line);
   pixels_in_line = 0;
}


void readClock(){
  pixels_in_line++;
}

The hex dump I receive on PC side:

000009a0  45 45 41 44 44 44 44 44  44 44 43 44 44 44 44 44  |EEADDDDDDDCDDDDD|
000009b0  44 44 44 44 44 44 44 44  44 44 44 44 44 41 44 44  |DDDDDDDDDDDDDADD|
000009c0  42 41 44 44 44 44 41 44  44 44 44 44 44 44 43 44  |BADDDDADDDDDDDCD|
000009d0  44 44 44 45 45 45 46 46  46 45 46 44 44 45 45 44  |DDDEEEFFFEFDDEED|
000009e0  44 45 44 44 44 44 44 44  44 44 44 41 44 44 44 44  |DEDDDDDDDDDADDDD|
000009f0  44 44 44 44 40 44 44 44  44 44 44 44 43 44 44 44  |DDDD@DDDDDDDCDDD|
00000a00  42 42 44 44 44 43 44 44  44 44 44 44 44 44 44 44  |BBDDDCDDDDDDDDDD|
00000a10  44 44 44 44 44 44 44 44  44 43 44 44 44 44 44 44  |DDDDDDDDDCDDDDDD|
00000a20  44 44 40 46 46 46 46 46  46 46 46 41 45 45 45 45  |DD@FFFFFFFFAEEEE|
00000a30  45 45 45 43 44 44 44 44  44 44 44 44 44 44 44 44  |EEECDDDDDDDDDDDD|

Please tell me there's an error in my code that gives me this discouraging results

There's no problem Just checking and pointing out that we need to pack our data and can't afford 144x160 byte array.
Also it's not 5760 bytes anymore. We need error-free frame delimiter so it's gonna be 7680, i.e. 85 fps. I'll share the code later, need to check it first.