oh I see, that answered a lot of my questions. I would like to know more about staggering the updates then, like if adjacent pixels should not be updated at the same time, how would you go about updating some from each buffer in such a way that adjacent ones do not end up getting updated? also I will probably need help with timing stuff when I get that far.

First of all, to do this you're going to need to write your own routine to copy the screen buffer(s) to the display.  (To get good performance, the routine will need to be seriously optimized, which is a huge topic unto itself.)  Normally, a routine like that would just read the bytes from one buffer, in order, and write them to the LCD driver.  Instead, what you want to do is alternate between the buffers somehow.  You can do this on a byte-by-byte basis (say, read one byte from buffer A, one from C, one from B, two from C, one from B, and one from C, and repeat.)  Or you can do it on a bit-by-bit basis, so each 8x7-pixel block contains pixels from all 3 buffers, arranged like this:
ACBCCBCA
CBCCBCAC
BCCBCACB
CCBCACBC
CBCACBCC
BCACBCCB
CACBCCBC
(note that this is just one possible arrangement - you can design your own.)  If you rotate this pattern by one bit (or one row) each time the screen updates, you'll see that in 7 updates, each pixel is set to its 'A' value once, its 'B' value twice, and its 'C' value four times.

So, for instance, for the first line above, if your 3 buffers contain the byte values x_A, x_B, and x_C, the value you want to display is (x_A AND 81h) + (x_B AND 24h) + (x_C AND 5Ah).  I'm not sure what the fastest way would be to compute this; it might help if you used the buffers to store bitwise differences (XORs) between the bit planes, instead of the "actual" x_A, x_B, and x_C values.

You'd probably find this easier if you tried writing a 4-level version first.

You could ask Calc84maniac for Chips Challenge 83+ source.

Seconding this.

Are you asking about 8-level grayscale specifically, or grayscale in general?  Using 8 levels isn't intrinsically any different from 4 levels; it's just that with smaller differences between the levels, any flickering becomes more noticeable.

In general, to display grayscale, you turn pixels on and off very rapidly, and rely on the eye to "average" things out.  A pixel that's turned on continuously looks darker than one that's only turned on 67% of the time, which looks darker than one that's turned on 33% of the time.

The most common way of doing this is to have two (or more) separate screen buffers with different "weights".  So for 4 levels you'd have two buffers, where buffer B is displayed twice as often as buffer A (which is to say, buffer B is displayed 67% of the time, and buffer A 33% of the time.)  For 8 levels, you'd add a third buffer, C, that's displayed twice as often as buffer B (so, buffer C is displayed 57% of the time, B 29% of the time, and A 14% of the time.)

It tends to look better if adjacent pixels don't change at the same time; to avoid that, you can stagger the updates, so instead of displaying one entire buffer at once, 57% of the pixels are being displayed from buffer C, 29% from buffer B, and 14% from buffer A; and you're rotating these sets with each update.

For minimal flickering, you want to synchronize your updates with the LCD driver's refresh rate.  This is rather difficult to do.  Some clever folks (not me) have mostly solved this problem for the 83+ SE and 84+, using the programmable timers.  On the 83+ BE, I don't think it's really possible without carefully tuning your entire program.

I could go on, but which of these subjects in particular are you curious about?

Returning to WikiTI:

This topic is inside the Assembly Programming Forum... WikiTI is for Assembly only?

I'm quite confused now, since I made Axe Parser's page :S

WikiTI is for whatever we make it.   It is mostly focused on assembly programming because that's where third-party documentation is most needed - TI's documentation barely scratches the surface of what assembly language can do.  But there's no reason to exclude other languages.  I don't think there's a need to document the Axe language itself - that's what the official documentation is for - but programming tips, example code, and tutorials would be very much welcome.

By the way, TI-73 OSes need to be patched before installing them on TI-83+ hardware, and TI-83+ OSes need to be patched too before installing them on TI-73 hardware.

Why? Are those patches needed only because of the different boot codes, or is there something different with the ports?

If there is something different with the ports, it may come from the same thing that is making thoses ASICs operate in 83 mode here...

Mainly it's the boot code differences.  But there are some very minor hardware differences in ports 2 and 16.

Back to the subject of the USB hardware, I've added my documentation for port 91h.  It's quite complicated, so I'd very much appreciate any comments or criticism, if there's anything that's unclear.  Of course, a lot of the complexity is just because USB itself is horribly complex.  But I'd still like to make the documentation as accessible as possible.

I think maybe what we need is, in addition to the detailed port documentation, a nice overview or tutorial to the USB system as a whole.  I'd volunteer to write this myself, but, sadly, I doubt I'll have time to do it in the near future.  If somebody else wanted to get started, I could probably help fill in some of the details.

Ouch, yeah, that is problematic.  The TI-73 Explorer with an 84+-style case (as seen here) doesn't look so bad, though.

I don't know, but I guess a logical next step would be to compare that picture with the PCB from a newer 83+ or 73.