Author Topic: Using the Toshiba RAM directly  (Read 10074 times)

0 Members and 5 Guests are viewing this topic.

Offline Hot_Dog

  • CoT Emeritus
  • LV12 Extreme Poster (Next: 5000)
  • *
  • Posts: 3006
  • Rating: +445/-10
    • View Profile
Using the Toshiba RAM directly
« 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?

Offline Galandros

  • LV9 Veteran (Next: 1337)
  • *********
  • Posts: 1140
  • Rating: +42/-10
    • View Profile
Re: Using the Toshiba RAM directly
« Reply #1 on: May 17, 2010, 12:59:02 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?
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.)

Hobbing in calculator projects.

Offline Hot_Dog

  • CoT Emeritus
  • LV12 Extreme Poster (Next: 5000)
  • *
  • Posts: 3006
  • Rating: +445/-10
    • View Profile
Re: Using the Toshiba RAM directly
« Reply #2 on: May 17, 2010, 01:30:50 pm »
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

Quote
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.
« Last Edit: May 17, 2010, 01:33:19 pm by Hot_Dog »

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55943
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: Using the Toshiba RAM directly
« Reply #3 on: May 17, 2010, 02:03:12 pm »
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

Offline Galandros

  • LV9 Veteran (Next: 1337)
  • *********
  • Posts: 1140
  • Rating: +42/-10
    • View Profile
Re: Using the Toshiba RAM directly
« Reply #4 on: May 17, 2010, 02:14:25 pm »
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.
Hobbing in calculator projects.

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55943
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: Using the Toshiba RAM directly
« Reply #5 on: May 17, 2010, 02:18:58 pm »
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