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 )

Nice tutorial. I think I'll move this to the ASM help sub-forum, though, since it's ASM-related. Hopefully it should be helpful for grayscale game programmers. I myself unfortunately didn't mess with grayscale much, as I mostly did TI-BASIC and never went far with Axe. The only grayscale games I made are Reuben Quest series and the RickRoll Tunnels.

I guess Quigibo could Update his greyscale routine, but unless we use Hex, theres really no way Axe could change its greyscale...

speaking of which, you should learn Axe, thepenguin, you'd release games way faster that way. 
IMO, games don't take as long to make in Axe.  but thats just me. 

Yeah I agree with Thepenguin. I personally prefer higher level languages, but if someone is pretty good at ASM and likes its freedom, it's gonna be hard to go back to higher level languages afterward.

Yeah in TI-BASIC you got slower code, but for new programmers it's easier to get used to and you can do some stuff easier like using floating points. Same goes with ASM libs, but I think xLIB syntax is hard to memorize, so on the spriting side I find Axe easier to use (although tilemaps can be harder in some cases)

Nice explanation At some point I'll have to implement that.

Wow, I've never actually put that all into words. It feels good to actually say it though. And sorry if I offend anyone who likes axe, axe is great, it's given power to the people, I just prefer asm.

I agree. All languages have their good points and bad, and just because someone likes one language doesn't mean it's the one for everyone else. And different languages suit different situations: BASIC is slow, but it's great (nice and small and compatible) for less intensive programs; Axe is fast and really easy to use, but it has its own problems, like with all languages; and ASM is ... well, once you get it it just feels good to program in, partly because you know it's your own code that you made yourself. Plus it lets you have complete control of everything, and power is nice

IMO the best language to use is just the one you're comfortable with that works best in that particular situation

Anyway, this is a great tutorial! We seem to be lacking in advanced ASM tutorials that go beyond the stuff in 28 Days.

Yeah a tutorial about advanced tricks would be nice.