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.
>>
>
