If you think there is a processor chip built into the LCD, then, yes, you
are.

On Sat, 21 Feb 2026 at 10:46, B9 <[email protected]> wrote:

> (Note: I may ALSO be confused about how the Hitachi LCD works!)
>
>
> On February 21, 2026 10:35:00 AM PST, B9 <[email protected]> wrote:
>
>> Sorry, I'm using the wrong words. I may also be confused about Virtual T.
>> Most likely both! :-)
>>
>> By "emulate", I was thinking of a chip-level emulation. When you said the
>> "model" is not 100% accurate, I thought you were talking about a black-box,
>> function-level emulation.
>>
>> Does Virtual-T emulate the processor built in to the LCD?
>>
>> --b9
>>
>> P.S. Can one manipulate the LCD using OUT on Virtual T?
>> https://github.com/LivingM100SIG/Living_M100SIG/blob/main/M100SIG/Lib-10-TANDY200/SCROLL.200
>>
>>
>>
>>
>>
>> On February 20, 2026 8:05:55 PM PST, Kenneth Pettit <[email protected]>
>> wrote:
>>
>>> Umm,
>>>
>>> I'm not sure what you mean.  VirtualT *does* emulate the LCD controller
>>> chips.  Just maybe the timing of BUSY is not modeled accurately.
>>>
>>> Ken
>>>
>>> On 2/20/26 1:53 PM, B 9 wrote:
>>>
>>> Are there hooks in Virtual T so that someday it might be able to emulate
>>> the LCD controller chips? I noticed that the MAME ROMs for the Tandy 200
>>> included the Hitachi ROM, if that was what was holding up development in
>>> Virtual T.
>>>
>>> Besides timing accuracy, there are some esoteric features missing which
>>> Virtual T won't be able to do until it gets full LCD emulation. (If I
>>> recall correctly, smooth scroll and text mode didn't work, I'm not sure
>>> offhand what else.)
>>>
>>> —b9
>>>
>>>
>>> On Fri, Feb 20, 2026 at 11:26 AM Kenneth Pettit <[email protected]>
>>> wrote:
>>>
>>>> Yes, there is no doubt that VirtualT runs too fast wriring to the
>>>> screen.  Even with the 8085 running at 2.4 MHz, it is still fasterr than
>>>> the LCD controller chips.  The ROM polls the LCD controller for "BUSY"
>>>> status after writing new data an will only continue once the controller is
>>>> ready.  I tried to model this in the emulation, but it moster certainly is
>>>> not 100% accurate.
>>>>
>>>> Ken
>>>>
>>>> On 2/19/26 10:28 PM, B 9 wrote:
>>>>
>>>> This may be just more of the same problem, but it appears Virtual T
>>>> runs too fast when printing to the screen as well.
>>>>
>>>> [image: image.png]
>>>>
>>>> I noticed this because the BASIC loader
>>>> <https://github.com/hackerb9/co2do/> I made for .co files is
>>>> superduper slow and the reason is (partly) due to constantly printing the
>>>> status. If anyone knows a fast way to display on the screen, please do let
>>>> me know.
>>>>
>>>> To test, I printed strings of different lengths and measured the
>>>> elapsed time. On my actual Tandy 200, it was a linear relationship for
>>>> strings from 0 to 39 chars: n×16÷9+5. Virtual T seems to be going about
>>>> twice as fast with a speed of about n+3 seconds for printing an n-character
>>>> string 1000 times.
>>>>
>>>> —b9
>>>>
>>>>
>>>>
>>>> On Mon, Feb 9, 2026 at 3:39 PM B 9 <[email protected]> wrote:
>>>>
>>>>> Virtual-T seems to be running too fast for me compared to real
>>>>> hardware (Tandy 200). I could be doing things wrong, so it’d be helpful if
>>>>> other people checked this out as well.
>>>>>
>>>>> Experimentally, my Tandy 200 takes 10 seconds to count to 3535.
>>>>>
>>>>> FOR T=1 TO 3535: NEXT
>>>>>
>>>>> When I do the same thing on Virtual-T’s emulated T200 it takes only 6
>>>>> seconds.
>>>>> Machine Time to count to 3535
>>>>> Genuine T200 10s
>>>>> Virtual-T 1.7 T200 6s
>>>>> Virtual-T 1.7 M100 5s
>>>>>
>>>>> Is the same thing true for other folks with real hardware? What about
>>>>> the Model 100 and Tandy 102 (or other more esoteric of the Kyotronic kin)?
>>>>>
>>>>> Second thing: REX# seems to slow my machine down significantly when I
>>>>> do not have an Option ROM activated. It is completely repeatable. Is this 
>>>>> a
>>>>> known issue? I tried using the emulated REX in Virtual T, but I must have
>>>>> an old version as it only had REX and REX2 listed, not REX#, and those
>>>>> didn’t cause any slowdown.
>>>>> Machine and REX# setup Time to count to 3535
>>>>> Genuine T200 with REX# De-installed 10s
>>>>> Genuine T200 with REX# Installed, but no Option ROMs activated 16s
>>>>> Genuine T200 with REX# Installed and any Option ROM activated 11s
>>>>>
>>>>> Finally, here’s a program that makes it easy to run timing tests
>>>>> repeatedly.
>>>>>
>>>>> 0 REM Speed Check4 COUNT=3535 ' T200 takes 10s to 35355 PRINT"Counting up 
>>>>> to";COUNT6 PRINTTIME$10 T1$=TIME$20 FOR T=1 TO COUNT: NEXT30 T2$=TIME$: 
>>>>> PRINTT2$40 H1$=MID$(T1$,1,2)50 M1$=MID$(T1$,4,2)60 S1$=MID$(T1$,7,2)70 
>>>>> H2$=MID$(T2$,1,2)80 M2$=MID$(T2$,4,2)90 S2$=MID$(T2$,7,2)110 
>>>>> H2=VAL(H2$):H1=VAL(H1$)120 M2=VAL(M2$):M1=VAL(M1$)130 
>>>>> S2=VAL(S2$):S1=VAL(S1$)150 IFS2<S1THENS2=S2+60:M2=M2-1:GOTO 150160 
>>>>> IFM2<M1THENM2=M2+60:H2=H2-1:GOTO 160170 IF H2<H1 THEN H2=H2+12: GOTO 
>>>>> 120180 H=H2-H1: M=M2-M1: S=S2-S1190 PRINT"Ran";COUNT;"loops in";200 
>>>>> PRINTUSING"##h##m##s";H;M;S
>>>>>
>>>>> Please let me know what you find. Thanks all!
>>>>>
>>>>> —b9
>>>>>
>>>>
>>>>
>>>

Reply via email to