Author Topic: Your 83+'s display is too small? (Read 18425 times)

willrandship · « **Reply #15 on:** April 03, 2013, 09:53:48 am »

Here we go! Can't test it myself, as I don't have the screen.

Try it out!

#include <T6963.h>
#include <T6963_Commands.h>

#define CLK 13
#define DAT 12

T6963 lcd(240,128,6);

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+=16){     
		for (byte b = 0; b < 8; b++){
			//Grab a byte of pixels. Ideally you would alter the axe side to make this a single read.
			while (!digitalRead(CLK));{
				byte c;
				c = digitalRead(DAT);
				c << 1; // shifts the pixel to the next slot.
				
				//The necessary clock delay
				while (digitalRead(CLK));
				delayMicroseconds(1);  //Needed for a stable connection, you could also use some asm("nop");
			}
			
		}
		
		
		//This scales it to 2 bytes.
		byte write0 = (c & 0b10000000);
		byte write0 = (c & 0b10000000) >> 1;
		byte write0 = (c & 0b01000000);
		byte write0 = (c & 0b01000000) >> 1;
		byte write0 = (c & 0b00100000);
		byte write0 = (c & 0b00100000) >> 1;
		byte write0 = (c & 0b00010000);
		byte write0 = (c & 0b00010000) >> 1;
		
		byte write1 = (c & 0b00001000);
		byte write1 = (c & 0b00001000) >> 1;
		byte write1 = (c & 0b00000100);
		byte write1 = (c & 0b00000100) >> 1;
		byte write1 = (c & 0b00000010);
		byte write1 = (c & 0b00000010) >> 1;
		byte write1 = (c & 0b00000001);
		byte write1 = (c & 0b00000001) >> 1;
		
		//This section writes all the bytes, hopefully in the right places.
		lcd.GraphicGoTo(x,y);
		lcd.WriteData(write0);
		lcd.GraphicGoTo(x,y+1);
		lcd.WriteData(write0);
		lcd.GraphicGoTo(x+8,y);
		lcd.WriteData(write1);
		lcd.GraphicGoTo(x+8,y+1);
		lcd.WriteData(write1);
        
        //lcd.setPixel(x,y,c);
        //lcd.setPixel(x+1,y,c);
        //lcd.setPixel(x+1,y+1,c);
        //lcd.setPixel(x,y+1,c);
        
        
        
    }
  }
}

MGOS · « **Reply #16 on:** April 03, 2013, 10:41:59 am »

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) :

Code: [Select]

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

Dapianokid · « **Reply #17 on:** April 03, 2013, 12:55:46 pm »

I would pay for this if people could use a color screen on a monochrome calculator. Somebody should program an Axe AXIOM for it

willrandship · « **Reply #18 on:** April 03, 2013, 01:13:39 pm »

OH

Those should be += or |= defines after the first one. But yes, that's the idea.

Keoni29 · « **Reply #19 on:** April 03, 2013, 01:48:11 pm »

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)

willrandship · « **Reply #20 on:** April 03, 2013, 02:00:08 pm »

Well, we're still talking about a 96*64 screen here. That's only 768 bytes.

Keoni29 · « **Reply #21 on:** April 03, 2013, 02:02:12 pm »

It would still take about 0.5 s to update.

willrandship · « **Reply #22 on:** April 03, 2013, 02:04:23 pm »

True. That's where things like partial screen updates need to come in. It would require more work on the calc's part, but the results would be worth it.

DJ Omnimaga · « **Reply #23 on:** April 03, 2013, 03:03:19 pm »

Very interesting. I like it as well.

I wonder if it could be made faster so that even larger LCDs can be used and refreshed nearly in real time for use in front of a math class?

willrandship · « **Reply #24 on:** April 03, 2013, 03:38:02 pm »

well, if you want big LCDs, just use a small one and a projector. The issue is resolution, and the only reason that's an issue is because the transition is being handled by an arduino over a slow serial connection.

With more specialized hardware, this could easily handle far bigger, more colorful screens, as long as you don't mind it running at 1 FPS or less.

Keoni29 · « **Reply #25 on:** April 03, 2013, 03:55:23 pm »

Are there TI calculators with a regular z80 in them? I mean a stand alone processor and not inside an ASIC. That way you could just use I/O functions to drive a color screen which is much faster than driving it over the linkport.

MGOS · « **Reply #26 on:** April 03, 2013, 04:56:17 pm »

Yes the old 83+s had a z80 as seen here.

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.

Edit:

Quote from: Keoni29 on April 03, 2013, 01:48:11 pm

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

Quote from: willrandship on April 03, 2013, 02:00:08 pm

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

Dapianokid · « **Reply #27 on:** April 03, 2013, 06:00:42 pm »

MGOS, that would end up being quite slow to do anything of value hehe

DJ Omnimaga · « **Reply #28 on:** April 04, 2013, 12:02:04 am »

I remember the TI presenter. I think BrandonW made a video of it in action before. It seemed slow, if I remember, and it sold for $399 or something.

willrandship · « **Reply #29 on:** April 04, 2013, 05:05:51 am »

That teacher screen actually hooks directly into the LCD signaling. There's no software interface involved. No way I know of to use that without interfering with the regular LCD.

The TI-Presenter used USB communication instead, so it worked with any calc, but it suffered the same problem this does, just like DJ mentions. It was very slow.

If you really want to get going, why not VGA? Just a few pins with some resistors and you can get a few colors.

Author Topic: Your 83+'s display is too small? (Read 18425 times)

willrandship

Re: Your 83+'s display is too small?

MGOS

Re: Your 83+'s display is too small?

Dapianokid

Re: Your 83+'s display is too small?

willrandship

Re: Your 83+'s display is too small?

Keoni29

Re: Your 83+'s display is too small?

willrandship

Re: Your 83+'s display is too small?

Keoni29

Re: Your 83+'s display is too small?

willrandship

Re: Your 83+'s display is too small?

DJ Omnimaga

Re: Your 83+'s display is too small?

willrandship

Re: Your 83+'s display is too small?

Keoni29

Re: Your 83+'s display is too small?

MGOS

Re: Your 83+'s display is too small?

Dapianokid

Re: Your 83+'s display is too small?

DJ Omnimaga

Re: Your 83+'s display is too small?

willrandship

Re: Your 83+'s display is too small?