I wonder about grayscalage.

JS Lemming · Post by **JS Lemming** » Mon 14 Feb, 2005 2:25 pm

I'm no genius at asm let me tell you. But recently I've been wondering how this "gray scale" thing everyone is talking about works. When I look around for info on the matter, i hear interupts alot. Are they really necessary? Here is my most likey flawed idea for gray scale'n.

First you would need say 3 screen sized areas in memory for use as buffers i guess you would call them (if we wanted 3 different shades of black). Each buffer would hold its gray, like buffer 1 holds the very light gray color. It wouldn't actually hold "gray", it would be like a normal buffer, you know, the 010000110 stuff. Oh crap, I'm not makeing any since.

OK! 3 buffers. Each will be a place to store the areas that will be either light gray, gray, or black depending on the buffer. Your sprite or graphics routine would place the values in the respectable buffer. When it comes time to "flip" the buffers onto the LCD, you would do the following:

(loop)
Draw buffer 1 (the light gray buffer)
Draw buffer 2 (the gray one)
Draw buffer 3 (the black one)
--clear screen
Draw buffer 2
Draw buffer 3
--clear screen
Draw buffer 3
--continue game code
(/loop)

Now, wouldn't that create a gray scaleish effect??? Sorry if I sound stupid.

CoBB · Post by **CoBB** » Mon 14 Feb, 2005 3:24 pm

The basic idea is indeed this, but there's a clever extension: show the buffers for time periods proportional to powers of two. This way you can get 2^n different shades with n buffers, i. e. two buffers are enough for four levels of grey. If you show buffer A for 1 unit of time and buffer B for 2 units, you can get white (both white), light grey (A black, B white), dark grey (A white, B black) and black (both black). With 3 buffers you can get 8 levels by basically counting in binary base. Then there are other tricks to make the flicker even less apparent, by mixing the contents of the buffers while keeping the timing the same for each pixel rather than alternating whole screens. Of course this requires more CPU time.

Jim e · Post by **Jim e** » Mon 14 Feb, 2005 4:25 pm

Further more, the main reason greyscale sucks so bad for the 83 is it's crappy refresh rate. If you try to draw out of sync with the lcd's refresh rate then thats where you'll get your flicker.
And if you try to update the lcd fast enough, you actually never see grey but rather a kinda of rolling black?? I've learned this hard way.

So if you draw one buffer then another imediately afterwards, the lcd won't even try to display those first pixels you drew, remember this is all going to a ram in the lcd driver.

Shadow Phoenix · Post by **Shadow Phoenix** » Mon 14 Feb, 2005 4:48 pm

i'll stick with black and white for now =D

Duck · Post by **Duck** » Mon 14 Feb, 2005 8:57 pm

CoBB's explanation is right but I understand if it is a bit hard to follow for beginners. There'll give some more extensive explanation whenever i finish these grayscale docs.

EDIT:
Jim e, I dont know of any interrupt that syncs with the LCD's display. It would be wonderfull if you could find the formula though

CalcKing · Post by **CalcKing** » Mon 14 Feb, 2005 9:30 pm

Although it was written specifically for the 68k calculator hardware, this did a very good job of explaining grayscale to me. I'm glad TIGCC exists.

Jim e · Post by **Jim e** » Mon 14 Feb, 2005 11:29 pm

The TI-89/92+ contains a timer chip which regulary triggers some interrupts

I was hoping that the 83 would have that, but sadly no.

Trying to sync up on an 83 is nearly impossible. On the SE you have complete control over the interrupt frequency. 83 however, has 2 timers that tick even when the interrupts are disabled. The goal is to update the lcd between 60-64 hz, To achieve no noise what so ever this has to be very accurate.
I do have a formula to try to achieve the least noise possible
Using the second timer on the 83, set at 1024hz I skip the interrupts i don't need to try to draw at 62hz.
1024 / 62 =~16
So every 16 interrupts i'd update the screen, sounds simple, but no.
See the timer keeps on ticking so from that number you have to subtract how long you grey routine takes, the better color from your GPP takes about ~67000

Code: Select all

 /   16               67000    \
|  -------    -   ------------  | * 1024  = 4  How many interrupts to skip
 \  1024            6,000,000  /

Heres an example using you routine, just using my timing.

http://www.geocities.com/jimm09876/FASTGREY.zip

That was meant to run on 83+, because the se slows writes to the driver, the timing is different. I want to have a grey package that can run on any 83(4) calculator as flawless as possible, but I'm still studying the hardware.

Duck · Post by **Duck** » Tue 15 Feb, 2005 12:27 am

Wow, you've been looking into this seriously. I never thought anyone would try to sync with the LCD. How did you find the LCD's refresh rate of 60-64 Hz?
What is the second timer you're talking about? Must be approachable by some port? And by the way, the "better color" version in the GPP only produces better color in some occasions, most of the times the regular version of the interrupt creates the best color balance. I think the "better color" version should actually be removed. So you will get a different and maybe better pattern with the regular interrupt.

Okay, I checked FASTGREY on my 83+ and it looks very good!

Jim e · Post by **Jim e** » Tue 15 Feb, 2005 1:17 am

For the LCD's refresh rate, after seeing that displaying to fast causes black and white instead of grey, it was really just a matter guessing and checking with the se timers.

The second timer does not seem to be documented at all. I found it when I studying the hardware. Heres something I keep next to my interrupt code.

Code: Select all

;------------------------------
;Interrupt info
;
;Port 3 controls what hardware will generate an interrupt.
;  Bit 0 - If the ON key is pressed
;  Bit 1 - First hardware timer (runs at 512hz)
;  Bit 2 - Second hardware timer (runs at 1024hz)
;  Bit 3 - Lcd Status (turning the calc on and off, HALT must follow)
;  Bit 4 - Link port (if pushed in)
;  Bits 5-7 - untested
;
;Port 4 controls the frequency at which interrupts occur with bits 1-2.
;Send 6 sets to it's slowest speed, and sending 0 sets it to it's fastest speed
;it also tells which hardware generated the interrupt
;  Bit 0 - ON key interrupt
;  Bit 1 - 512hz timer interrupt
;  Bit 2 - 1024hz timer interrupt
;  Bit 3 - ON key pressed
;  Bit 4 - Link cable inserted
;  Bit 5 - 1st crystal timer
;  Bit 6 - 2nd crystal timer
;  Bit 7 - 3rd crystal timer

;This table tells what should be outputed in what port at the end of the interrupt
;these are aproximate, varying 1-2hz (except 1024 & 512 those are the most accurate.)
;------------------------------
;port 3	|port 4	|HZ
;-----------------------------
;$0a		|$06		|108
;$0a		|$04		|156
;$0a		|$02		|227
;$0a		|$00		|512
;-----------------------------
;$0c		|$06		|216
;$0c		|$04		|315
;$0c		|$02		|455
;$0c		|$00		|1024
;-----------------------------
;$0e		|$06		|323
;$0e		|$04		|473
;$0e		|$02		|682
;$0e		|$00		|1536
;-----------------------------

;Example
IntStart:
 ex af,af'
 ld a,$00     ;fastest speed
 out (4),a
 ld a,$08     ;reset generated interrupts
 out (3),a
 ld a,$0C     ;1024hz
 out (3),a
 ex af,af'
 ei
 ret

What surprises me is how undocumented this is. 28 days didn't have any info on it, most guides say to jp to $3a. Even Michael V's port reference doesn't say anything.

Bit 2 - unknown, something to also do with the hardware timer

Surprising really. I should probably officially document this on ticalc. But i'm lazy.

JS Lemming · Post by **JS Lemming** » Tue 15 Feb, 2005 2:51 am

Wow! Very interesting. Sweeeet gray scalage Jim e. But yeah, I'll probably stay away from it if I ever get time away from developin on mai trusty dream cast. There is just something about asm that always brings me back though.

Duck · Post by **Duck** » Tue 15 Feb, 2005 12:08 pm

You did great research!

;------------------------------
;port 3 |port 4 |HZ
;-----------------------------
;$0a |$06 |108
;$0a |$04 |156
;$0a |$02 |227
;$0a |$00 |512
;-----------------------------

These are the frequencies the GPP runs on. I checked the quality of 64Hz grayscale in your demo, and (on my calculator with half battery life) it is somewhere between the 108Hz and 156Hz frequencies in GPP. That is some major improvement you achieved there.
Flickering is still quite visible though. Have you tried a frequency of 120-128 Hz yet?

EDIT: The flickering a mentioned is mostly seeable in lightgray. Darkgray hardly flickers.

JS Lemming · Post by **JS Lemming** » Tue 15 Feb, 2005 1:33 pm

Strange, it had zero flickering on my calculator. Maybe its the fact that I haven't changed my batteries in like a year and a half.

So batterly life effects that kind of thing? Hmm... I bet there's no easy way to guage the power left in them thar acid buckets either.

Jim e · Post by **Jim e** » Tue 15 Feb, 2005 5:57 pm

See this is my issue. On my old 83+ you'll see a small line move through the dark grey, and the light grey is flawless(~). ON my SE though, the dark grey is near flawless and the light grey has a considerable amount more noise moving through it.
And now you two telling me similar issues on different calculators. This is a real pain.

I'm not a 100% but I think I can rule battery life as the culprit. When I did these test I included bad batteries in few trials, no major affect on frequency. It's more likley bad batteries slow the processor allittle than anything else.
There 2 things that come to mind now, the issus with the newer drivers that has poped up and the fact that the interrupt clock(whatever it's called) may not be evenly spacing the interrupts. One test I did was, I'd have sound generate from the link port every time an interrupt occur and I was recording it from my computer, I then looked at spikes with Audacity and it seemed to not be spaced properly. But I was having problems with it so I gave up. So Until I get my hands on a TI83+ with a bad driver and an 84+, I'm really just shooting in the dark here.
But this does still seem to be a far compromise for speed to quality.

I am such a nerd.

Post by **tr1p1ea** » Tue 15 Feb, 2005 6:47 pm

Yeah i know what you mean. I have messed with grayscale a little and find that the results vary on different calculators. I have 2 83's and its kind of difficult to balance decent grayscale and decent speed for both.

It gets really annoying :S.

But my link cable broke so i cant test the routines any more

.

Jim e · Post by **Jim e** » Wed 16 Feb, 2005 7:26 am

First I have to buy a hat, then I got to tip it to you Duck, you just gave me a great idea.

Your gpp just showed me how much it actually reduces the noise compared to byte interlacing or drawing the fullscreen for grey, I tried the gray routines I WAS going to use for my SE gray package with the timing being discussed here and the noise was horrendously greater compared to yours.
I then realized that with the SE's extra speed, I could accurately bit interlace with a 1:2 ratio without using any writeback (thats important to me) and STILL be under the needed clocks to write to the LCD. A quick test proved that bit interlacing is by far the best method for gray on the 83+. It did such a great job that I had trouble seeing a difference when I tried to tune it, meaning I probably won't need tuning any more.
Wish I could show you guys the results, but I know how few people have SEs so releasing anything at the momement is pointless.

Thanx for the inspiration man. *insert worship emoticon*

I still keep working on improving sync'ing for the 83+ though

How do you spell gray(grey)?