With my recent work on Chess, people have been asking me how I make my grayscale so perfect. So here is a tutorial!

First, a little background, most of it can be read in this topic. A while ago, I made a program that displayed 16 level grayscale pictures. It worked pretty well, but it was clearly not flickerless, it had major scrolling patterns and some spots literally flickered. Then I thought, if I can do 16 with 120 refreshes per frame, why not do 64 level grayscale with 100,000 refreshes per frame. This was accomplished using z-addressing and I put 1 pixels in the first column, 2 in the second, 3 in the third, and so on until the screen was full. Then I scrolled that at 100,000 fps. What I noticed was that at certain frequencies, the images would slow down, stop, then reverse direction and go back into oblivion. After a little bit of playing with it, I figured out that the LCD actually has a refresh rate. And that rate is 60Hz.

This little refresh rate is what causes all of the problems with the LCD. Lets say that you quickly change the screen color, if you've used your calculator long enough, you know that there is a diagonal line going up your calculator for a split second while it is clearing. This is caused when you and the LCD driver are updating the screen at the same time.

The LCD driver has two parts, and each part works independently of the other. First you have the LCD ram, which is just like regular ram. And then there is the LCD driver which updates the screen 60 times per second, at a speed of about 100 pixels / (1/60 second) from top to bottom. In common practice, the LCD ram is filled one column at a time, starting at the left, and working your way across. This operation takes about 1/120 second. What can happen is that while you are updating the LCD ram, the LCD driver decides that it is going to start displaying the screen. It displays 1 row at a time, and as it falls down the rows, it displays whatever is currently in ram. So you can see that if you are updating the screen while it is reading it, there will be some spots where you as the writer will cross over what the driver is displaying, effectively making the driver display part of two different frames.

For your average game, this is no problem, a minor graphical glitch that is only present for about 1/60 second and that only happens about 1 time per second. But grayscale is an entirely different case. This graphical glitch is very obvious because it screws up your careful pixel timing. Instead of ON ON OFF ON ON OFF, sometimes you will have ON OFF ON ON OFF ON, which spread over the whole screen, just looks bad. Also, let's say that you don't know about this whole refresh thing and you update the screen at either 80 fps or 40 fps. At 80 fps, some of your frames are never going to even make it to the LCD, you are updating it so fast that you will update it again before the driver has time to display it. And at 40 fps, some of your frames are displayed twice.


After hearing that, I'm sure there are a few of you that could go out and write your own display routines, but there are also those who can't. Here is an example of what we don't want.

You can see that the LCD driver and the displayer are not in sync and scan lines are clearly present. (Technically since that is in wabbitemu, I had to do something entirely different to get that effect, but you get the drift.)

Now, to get away from this, you have to learn the way of the LCD driver, and try to basically run away from its display line. First off, it displays rows, not columns. So we will obviously have to write a 07 to port (10h), and work horizontally across the screen. This does have some speed drawbacks, but that's just how grayscale goes.

Now that that is out of the way, you will notice that your grayscale routine actually looks a lot better, but we're not done yet. The next step is to get in sync with the driver, which is accomplished with the crystal timers. Our goal is around 60 Hz, so the timer that gives us the most flexibility around this range is timer 40h, it runs at 10922.667 Hz. Then you have to apply your multiplier to it 10922/60 = 182, so a counter of 182 will get you 60 Hz. I of course prefer 178 as that is what my calculator is synced to, but to each his own. (The typical range is about 160-180). To put this into code. 40h to (30h), 0 or 2 to (31h), and 178 to (32h).

That's it, do that and you will have perfect grayscale.

And why did I mention 100 pixels / (1/60 seconds)? That's because you can't perfectly match the frequency of the driver and there will always be a small glitch line. But if you do it right, the line is off screen for 1/3 of the time.

Here's an example of implementing what I just talked about. It's commented quite nicely, but I left it up to you to make your own calibration screen (I don't want all the games to look the same )

@Thepenguin77 You are the master of grayscale!

Actually, the grayscale in this one isn't perfect. It's pretty close, but I didn't do it right.

When I first read that, I was like, "Wow, someone really named their program the exact same name as mine." But I never expected to get a news an entire year later. Thanks.

Nice.  You should write it with 8810 bytes of code.  Also, did you fix the icon thing?  It seems like it, but I don't have a real calc to test it with atm.  Also, could you make it so that the cursor returns to your last moved piece?

The icon thing is fixed. It's because I didn't nop a byte on the extra ram page, and then later assumed it was either 0 or 1.

And I just updated the file with the cursor going to the last piece you moved. I had to try to be quick before people downloaded it though because it causes save game incompatabilites.

Ah, do you know why the set and res are there ?

I do. Those allow getKey to return with On also. They occur around the bcall(_getKey) that waits for a key after does the ram cleared screen.

stupid AI noob!!! it keeps cheating! Castling does NOT work that way!!! I found a way to beat it anyways. I put it in checkmate and had my queen on same horizontal line so even if it "castled" it wouldn't be safe. when i took out all of my opponents pieces including the king, the game didn't end.

I know he fixed the fake castling, but what happens when you win? I beat him and took every single piece but nothing happened...

I know, I did that on purpose. I figured that for now, it would be better if you could continue playing on the off chance that the game glitches and pulls a false checkmate. Plus, as soon as you get checkmate, you can just quit.

Hey, for some reason the cursor was messing up pretty badly.  It was some random garbled thing.

OS 2.53 MP. (for integral function, and that's it)

This happens on my friends calculator also. He has 2.43. He said that a lot of other stuff was going horribly wrong too aside from the cursor. Tomorrow, I'm going to completely clear the calculator and see if that fixes it. If not, it must be related to hardware somehow. (Running the program from the homescreen didn't fix it either, so it's not specifically Mirage's fault. And it only uses 1 bcall the entire time, so it shouldn't be OS related either.)

Even weirder, the cursor graphic is not the very last thing in the program. All of the text comes after it. And the displaying routine isn't anything out of the ordinary.

Oh, I see. If you want to get hold of the arguments preparsed, then you need to use the mode 0, and go parse them yourself.

Using those three variables mentioned on the wikiTi page, you can find the information in ram, do what you want with it, and then let the parser go. What I did for some of my parser hooks was to completely relocate the tokens somewhere else. But I think since I didn't put the pointers back to their proper locations, I broke all basic programs.