Wow, that's cool. It's interesting that he uses the screenshot function. I know that there is one, but I don't know how to use it...
I don't know if VGA or composite is really necessary for what I'm doing right know - it would be also 2 colors. I think you feel the main advantages not before you have a working graphics chip with a library which does all the tedious work (storage, text, plotting, ...) for you and then use serial commands to tell the chip what to do.
Ok, I have rewritten the T6963 library for the Due . The display can now be written a lot faster than before. I also used direct buffer reads to transmit the buffer from the calc (and no delay!). You may gain a bit more speed if you do it in asm, if you care it takes about 304 milliseconds for one screen (sending and displaying).
void setup() { lcd.Initialize(); lcd.clearCG(); // Clear character generator area lcd.clearGraphic(); // Clear graphic area lcd.clearText(); pinMode(CLK,INPUT); pinMode(DAT,INPUT); }
void loop() { taken = false; while (digitalRead(CLK)); for (int y = 0; y<64; y++){ for (int n = 0; n < 12; n++){ int c = 0; for (byte b = 0; b < 8; b++){ while (!digitalRead(CLK)); if (!taken) {start = millis(); taken = true;} c = c << 2; c |= digitalRead(DAT); lcd.n_delay(); while (digitalRead(CLK)); lcd.n_delay(); } c *= 3; pic[n*2+y*60] = c>>8; pic[n*2+y*60+30] = c>>8; pic[n*2+y*60+1] = c&0xFF; pic[n*2+y*60+31] = c&0xFF; } } lcd.DispBuff(pic); t = millis()-start; lcd.TextGoTo(25,15); lcd.WriteChar(t/100+'0'); lcd.WriteChar((t%100)/10+'0'); lcd.WriteChar(t%10+'0'); lcd.WriteChar('m'); lcd.WriteChar('s'); }
Video: (the time needed to transmit and display is shown in the bottom right corner)
For any advanced color display (be it VGA or the the Sharp screen I posted) you need an extremely fast MCU to refresh the screen all along. You would need a graphics chip to handle this, even the arduino due (which finally works with the display! I will post the library later) wouldn't be fast enough too get a decent picture. The Sharp screen came with a graphics card which outputs Digital or VGA, I just don't know how to use it (it's 20 years old ). It's a VAMP535 V1.00.
There is also the teacher version which has an extra parallel port to attach a screen for over head projectors (ViewScreen). Our maths teacher sometimes brings one of these to his lessons to show us how to do something (or let me do that ) And the TI Presenter which outputs a signal for a conventional TV.
It would be slow as heck if it was sending data over the I/O port though. My custom link protocol can send max 2k every second. A color LCD of 320x240 with a color depth of 8 bits would be 76800 bytes. It would take 38.4 seconds to draw the entire screen. (add the time it would take for the arduino to that)
Of course you could never do all the calculations on the calc and display the screen every time. If one had an easy to use graphics library (on the arduino!) for this screen with all the important functions a game needs (sprites, bitmaps, pixel, rectangles, circles, lines, scrolling, text, ...), it could be done I guess
Well, we're still talking about a 96*64 screen here. That's only 768 bytes.
Well who needed a color display that is that small the one I showed in an earlier post is 640*480.... when we go even further - what about an HDMI adapter
Thanks - I don't get how the scaling up works though . You defined write0 and write1 a bunch of times - which one is the correct? It would be also possible to shift two bits left when receiving a byte and then multiplying the whole 16 bits by 3 (to fill in the gaps) :
u_int16 c = 0; for (byte b = 0; b < 8; b++){ while (!digitalRead(CLK)); c = c << 2; c |= digitalRead(DAT);
while (digitalRead(CLK)); delayMicroseconds(1); } c *= 3; //the arduino features an "On-chip 2-cycle multiplier" :) //now the high byte of c is write0 and the low byte is write1
void setup() { lcd.Initialize(); lcd.clearCG(); // Clear character generator area lcd.clearGraphic(); // Clear graphic area lcd.clearText(); pinMode(CLK,INPUT); pinMode(DAT,INPUT); }
void loop() { for (byte y = 0; y < 128; y +=2){ for (byte x = 0; x < 192; x+=2){ while (!digitalRead(CLK)); int c = digitalRead(DAT); lcd.setPixel(x,y,c); lcd.setPixel(x+1,y,c); lcd.setPixel(x+1,y+1,c); lcd.setPixel(x,y+1,c); while (digitalRead(CLK)); delayMicroseconds(1); //Needed for a stable connection, you could also use some asm("nop");
} } }
The axe code is really inefficient, I know. But it can be because the lcd needs that much time. I will use direct buffer access and shift out the main buffer serially in later versions. I just kept that for readability:
StoreGDB FnOff For(I,L6,L6+767) {I}->B For(8) B . 128?0,1 //bitwise and b1000000 to get the MSB ->port For(whatever):End 3->port B*2->B //shift left For(whatever):End End EndIf getKey(15) LnReg
I'm already optimizing Indeed, I'm using an just an atmega168, but it should work with the Due as well. The main problems I see is in the library I'm using. Since the atmega168 has not a single port that is accessible at once, so the lib uses to ports and bitshifts the data. On the due you could use the entire port D (or at least the lower quarter of it). Another thing is that the every pixel is written seperately, which causes a lot of unneeded communication of the LCD with the arduino (calculate the address, get the byte in the lcd memory, mask it with the new pixel, write it again). That are the two points I'm trying to optimize.
You would need at least 3.8 k (240/8*128) of RAM since the displaying process is the bottleneck of this system. I can transmit the data from the calc to the arduino quite quickly, but the plotting takes a lot of time. When I could use the plot functions on a screen sized buffer and shift out the whole buffer at once, it would be a lot faster.
I had an WG240128b graphics LCD (with the famous T6963 chip) lying around and I finally got it working with my 83+ The interface is quite slow at the moment, because the arduino I'm using has not enough RAM (only one k) to store the whole content of the screen, so I displayed it pixel by pixel. I'm sure it can be done significantly faster when I manage my 84 MHz / 96 kB DUE to work with it. The display is 240 x 128 pixels, so I scaled up the screen in both directions by the factor 2.
On the calculator side I made an application with a key hook which transmits the screen serially when you press a certain key (in this case ln) at any point in the OS.
well, the problem with that is the fact that the values each character can take are very limited. If you're using a LUT-String with InString( you can get to 256 different (probably less) values per character. Since 2*3*5*7 is already 210, 4 maps is the maximum to store in a string using the prime factor compression. I'm not sure whether strings are still smaller than matrices when you use two characters for each square. And it would be real mess to code. In case you only need to store two values (1's and 0's) in each map, a binary compression would be a lot more efficient. Each bit of a number would be the value of the square in the corresponding map. With binary compression, you could store up to 7 (maybe 8 ) maps in a string, and a lot more in the matrices. When more different tiles are needed, it can be rather easily changed that a group of 2, 3 or 4 bits represent one tile (same method; explained in the initial post of sjasogun1).
Show Posts
. The display can now be written a lot faster than before. I also used direct buffer reads to transmit the buffer from the calc (and no delay!). You may gain a bit more speed if you do it in asm, if you care 
it takes about 304 milliseconds for one screen (sending and displaying).
. You defined write0 and write1 a bunch of times - which one is the correct?
) :
