Well assuming you mean the guide to TI-83+SE BASIC grayscale, the issue is that this tutorial is for Omnicalc (and now Celtic III, as Celtic does Omnicalc Sprite( command) and the way it does it is pretty much slower than if we used xLIB Real(3 function. But back then xLIB APP didn't even existed at all (if you download the tutorial from Omnimaga, you will notice it even uses a 8xp version of xLIB)

Oh that one, I thought you meant mine from 2004. Actually despite having it in our archives, I think I will repost it directly on forums at one point

Information is already down, and I'm done with what I needed. From the stuff found on this site (linked to by a much earlier post) http://www.junemann.nl/maxcoderz/viewtopic.php?f=5&t=2692
 , I've built a custom 4lv grayscale routine. It actually works out *very* well, on both the emulator and the hardware.

Unfortunately, there was some kind of bug that screwed up the OS in a very subtle way. The kind of problem that I'm at the moment trying to solve via OS reinstallation.

Information is already down, and I'm done with what I needed. From the stuff found on this site (linked to by a much earlier post) http://www.junemann.nl/maxcoderz/viewtopic.php?f=5&t=2692
 , I've built a custom 4lv grayscale routine. It actually works out *very* well, on both the emulator and the hardware.

Unfortunately, there was some kind of bug that screwed up the OS in a very subtle way. The kind of problem that I'm at the moment trying to solve via OS reinstallation.

ouch I do hope a OS reinstall fixes it

it's for double buffering, which offers advantages like artifact reduction and being "smoother"  Keep in mind the active buffers MUST be together.  when the app was originally written, it was realized that 768x2 and some extra bytes were needed straight out of RAM.  RGP is good enough for almost anything you'd normally write.  heck, with a little ingenuity, you can make a game that's looks good and has a lot of action.  but for things like SSB, it's reasonable that tr1p1ea made his own (other than the fact he's a genius). 

I suggest you keep the double buffering unless you really want to allocate plotsscreen and appbackupscreen for other variables. 

blame the LCD controller on all calcs except 86s for not being able to do good gs.  memory mapping would eliminated the port communication that makes gs such a drag.

Doesn't the TI-85, TI-92 and the old TI-89s and 92s also does good grayscale? I do remember some quite nice looking grayscale games on my TI-85, altough it seemed a bit slow.

the LCD on lower number models calcs is a serious issue, though. Even BASIC programmers using libraries to do grayscale has trouble keeping the grayscale from showing a checkered pattern (3 level) because the checkered pattern areas are either inverted too quickly or too slow. A long while ago I had an xLIB routine doing 3 level grayscale and it looked better on my regular TI-83+ than my TI-83+SE.

BASIC doesn't help much for reducing the check effect... It is hard to update the screen enough and in the right timing.
Nor the lcd that really sucks.

I didn't resist to ask. Iambian did you use interlacing in the routine?
[...]
And I hope too that the OS reinstall works.

When you say "interlacing", are you referring to the method that the information is written to the screen or the form the data takes in the buffer? If you are talking about how it's drawn on the screen, yah. That's where the "wavy" effect comes from.

The issue about the OS was resolved. Apparently, doing a "RAM Reset" doesn't do something important to the flag, which was being screwed up. Specifically, IY wasn't being set back to the correct value. In PTI, the RAM reset resolves the issue, so I'm guessing it either might be how the real calc initializes, or that the newer TI-OSes are being made crappier and crappier.

On something similar, the RAM usage reflects that of CaDan, in which the RAM is rearranged such that the strip of RAM between $8000 and $8E00 is free for scratch work. This method works incredibly well for grayscale, since I can flip a bit to refer to the other buffer (with a 256 byte gap in between since the bit flip occurs as 1024 chunks). I do plan on interleaving the data so I can go with a straight 1536 byte buffer so I can completely avoid having to switch buffers. I have the option now of going ahead to vertically align the buffer, which would make tilemapping much easier to speed up.

To avoid mentioned "artifacts", all the tilemapping updates are going to be done in the interrupt between gray drawing cycles. Sure, it *might* be a little slow, but I believe this will work out wonderfully. Since the game's text and menus occur on a grid divisible by 4, that, too, will be handled by an "aligned" 4x4 tilemapper. The timings have already been worked out for that, and I expect it to work great.

EDIT: Just realized that I forgot which thread I was posting in. Since I'm not going to move it, I'll just link to where it was supposed to go: http://ourl.ca/3383/62977