Omnimaga
Calculator Community => TI Calculators => ASM => Topic started by: Hot_Dog on May 17, 2010, 12:30:45 pm
-
I understand that when working with the LCD drive on the Ti-83+ directly, you get immediate updates. Is there a way to control when these updates occur (meaning the screen doesn't update everytime you draw a single point)? If not, what's the advantage to using the RAM over plotsscreen?
-
I understand that when working with the LCD drive on the Ti-83+ directly, you get immediate updates. Is there a way to control when these updates occur (meaning the screen doesn't update everytime you draw a single point)? If not, what's the advantage to using the RAM over plotsscreen?
No, there is not command to that of the LCD driver.
We control when the LCD updates by copying plotsscreen to the lcd ram when we need. plotsscreen can be seen as a back buffer and the lcd ram as the active buffer.
The only advantage is you supposedly you do not need to use plotsscreen as a graphics buffer. We can make routines that display graphics directly to the LCD instead to a buffer.
This is not done for pixels, sprites and text because it is slow to wait for the lcd after copying a byte. But for larger tasks like a tile mapper, you can let your tile mapper work during the delay. You actually gain speed by not wasting time in doing nothing between writes. (Note that normally a good tile mapper like dwedit's, jim_e's or calcmaniac84's copy the old screen to lcd and compute the new screen that will be copied in the next frame.)
-
For larger tasks like a tile mapper, you can let your tile mapper work during the delay. You actually gain speed by not wasting time in doing nothing between writes. (Note that normally a good tile mapper like dwedit's, jim_e's or calcmaniac84's copy the old screen to lcd and compute the new screen that will be copied in the next frame.)
How do you do something during the delay? Is it natural, or does it involve interrupts or another process
We control when the LCD updates by copying plotsscreen to the lcd ram when we need
Oh yeah, I forgot that one could copy just part of plotsscreen.
-
If the LCD was accessed directly, would this cause cross-compatibility issues between each hardware revisions of the 83+, 83+SE and 84+? I think the used LCD is different over the time
-
For larger tasks like a tile mapper, you can let your tile mapper work during the delay. You actually gain speed by not wasting time in doing nothing between writes. (Note that normally a good tile mapper like dwedit's, jim_e's or calcmaniac84's copy the old screen to lcd and compute the new screen that will be copied in the next frame.)
How do you do something during the delay? Is it natural, or does it involve interrupts or another process
Simply put some code before the write. For example dealing with one tile gives more than enough delay. It does not matter exceeding the delay.
One interesting use is output a byte to the LCD and right after clear that byte in the plots screen. It is used in one of the routines here: http://wikiti.brandonw.net/index.php?title=Z80_Routines:Graphic:Fastcopy
It avoids to do this:
call fastcopy
call clearbuffer
If the LCD was accessed directly, would this cause cross-compatibility issues between each hardware revisions of the 83+, 83+SE and 84+? I think the used LCD is different over the time
Yes, the compatibility issue is the amount of delay. Ion fast copy is not safe because it assumes a certain time between writes (less than 60 T-states or clocks, I think) some bad LCDs need more time than usual and go funny if you force them. To make it safe you wait for a flag of the LCD that indicates if it is busy or ready to receive the next byte.
Contrast is also different between calculators but does not pose such a great problem.
-
When xLIB APP was in beta testing, I remember he set the LCD updating commands and stuff to 15 MHz on SE calcs and it showed garbage instead. He had to set them to 6 MHz when ran. I wouldn't be surprised if it was the same reason for Quigibo making the Axe gray commands 6 MHz-only