Even worse, in the T200, the LCD controller has an 8K RAM which is more
than needed to display 240x128 pixels (only 3840 bytes needed). Not
only does the ROM have to update the LCD controller RAM with what is in
the LCD buffer, it also moves that 3840 byte "screen" around in the 8K
LCD controller RAM at times, typically when a screen changes completely.
Ken
On 1/18/26 11:54 PM, John R. Hogerhuis wrote:
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 200 20 R=7: C=19 30
Y=PEEK(SC+R*40+C) 100 POKE SC + R*40 + C, ASC("*") 110 K$=INKEY$:
IF K$="" THEN 110 120 K=ASC(K$) 125 IF Y>0 THEN POKE SC+R*40+C,Y
129 '27 is Esc 130 IF K=27 OR K$="q" OR K$="Q" THEN END 139
'28,29,30,31 is CLOSE,LOAD,DSKO$,OPEN 140 IF K=28 OR K$="l" THEN
C=C+1 150 IF K=29 OR K$="h" THEN C=C-1 160 IF K=30 OR K$="k" THEN
R=R-1 170 IF K=31 OR K$="j" THEN R=R+1 210 IF R<0 THEN R=0 220 IF
R>15 THEN R=15 230 IF C<0 THEN C=0 240 IF C>39 THEN C=39 480
Y=PEEK(SC+R*40+C) 490 PRINT @0,CHR$(Y);" "; 495 PRINT Y;" at
";R;", ";C 500 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:
o LINE 14
o LINE 15
o LINE 16
o LINE 1
o LINE 2
o LINE 3
o ⋮
o 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.
