The lcd buffer is what "was" written to the lcd chips. It will only be rewritten if the screen is scrolled. And the t200 has hardware scrolling so I am not sure how often it redisplays thing. Ideally as infrequently as possible because it's costly.
You can peek the buffer but usually I think you'd want to use print @ or equivalent to modify the screen. One thing I didn't remember is if the lcd buffer has attributes for each position. Like reverse video. I guess it must. It would affect computations. -- John. On Sun, Jan 18, 2026, 11:24 PM B 9 <[email protected]> wrote: > Okay, I’m very confused now. The memory address labeled “LCD” on the “Cross > Map > <https://bitchin100.com/wiki/index.php?title=Model_T_Cross_Map_RAM_Variables>“ > doesn’t work the way I expected it to if it was a memory mapped screen like > on the Commodore PET. Here’s a program that is supposed to show an asterisk > on the screen which can be controlled by the arrow keys. It completely > fails. > > 10 SC=64048 ' "LCD" for Tandy 20020 R=7: C=1930 Y=PEEK(SC+R*40+C)100 POKE SC > + R*40 + C, ASC("*")110 K$=INKEY$: IF K$="" THEN 110120 K=ASC(K$)125 IF Y>0 > THEN POKE SC+R*40+C,Y129 '27 is Esc130 IF K=27 OR K$="q" OR K$="Q" THEN > END139 '28,29,30,31 is CLOSE,LOAD,DSKO$,OPEN140 IF K=28 OR K$="l" THEN > C=C+1150 IF K=29 OR K$="h" THEN C=C-1160 IF K=30 OR K$="k" THEN R=R-1170 IF > K=31 OR K$="j" THEN R=R+1210 IF R<0 THEN R=0220 IF R>15 THEN R=15230 IF C<0 > THEN C=0240 IF C>39 THEN C=39480 Y=PEEK(SC+R*40+C)490 PRINT @0,CHR$(Y);" > ";495 PRINT Y;" at ";R;", ";C500 GOTO 100 > > Using POKE to display characters doesn’t seem to work at all. Using PEEK > kind of works, but not enough to be usable, yet. I added line 490 which > prints the character under the asterisk in the top left corner and it > appears “LCD” is a rolling buffer of lines that were sent to the chips on > the LCD panel. so the first line on the screen is not the first line in the > buffer. For example, I might see an offset like this: > > - LINE 14 > - LINE 15 > - LINE 16 > - LINE 1 > - LINE 2 > - LINE 3 > - ⋮ > - LINE 13 > > > If there’s a not-too-cumbersome way to ensure the offset is always zero, I > could see using the LCD buffer to check for collisions. I tried using CLS, > but that didn’t help. > > Similarly, I know that TELCOM can quickly switch between displaying the > ALT screen and the normal screen. Would I be right to guess there’s some > machine language routine that updates what the LCD chips are actually > showing given an address in memory (and maybe an offset)? If so, is there a > simple way to call it? My usual resource for such things, Anderson’s PEEKs > and POKEs > <https://archive.org/details/ProgrammingTipsPeeksAndPokesForTheTandyPortableComputers> > only mentions the LCD image buffer as existing, but does not give details. > > —b9 > > On Sun, Jan 18, 2026 at 1:19 PM B9 <[email protected]> wrote: > >> Thank you for error correcting my memory, John! I probably confused it >> with the Model 100's Disk/Video Interface (DVI or MVT100). Or am I >> misremembering that, too, and it does have the screen mapped to RAM >> somewhere? >> >> --b9 >> >> P.S. Twospruce's MVT100 is here: >> https://bitchin100.com/wiki/index.php?title=VT100 >> >> BTW: at the bottom it says the high-ASCII extended character set doesn't >> exist and suggests upscaling from the Model 100's 5x8 font to 6x12 for VGA. >> If that hasn't been done yet, there may be a better starting point using >> the original DVI 8x8 font: >> https://github.com/robhagemans/hoard-of-bitfonts/blob/master/kyotronic/trs80-dvi-8x8.yaff >> >> >> >> >> On January 18, 2026 12:03:40 PM PST, "John R. Hogerhuis" < >> [email protected]> wrote: >> >>> "Again IIRC, the Tandy 200 can’t do that because the screen memory is >>> stored in the LCD driver chips, right?" >>> >>> No, that is incorrect. True, the *pixel image* is not stored in RAM, >>> just in the lcd hardware. But there are two RAM areas where the ASCII >>> characters are maintained, LCD and ALTLCD (for restoring after switching >>> control modes in TELCOM). >>> >>> https://bitchin100.com/wiki/index.php?title=Model_T_Cross_Map_RAM_Variables >>> >>> So I think you should be good for your port. No faking needed. >>> >>> -- John. >>> >>
