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.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 Check 4 COUNT=3535 ' T200 takes 10s to 3535 5
>>>         PRINT"Counting up to";COUNT 6 PRINTTIME$ 10 T1$=TIME$ 20 FOR
>>>         T=1 TO COUNT: NEXT 30 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 150 160
>>>         IFM2<M1THENM2=M2+60:H2=H2-1:GOTO 160 170 IF H2<H1 THEN
>>>         H2=H2+12: GOTO 120 180 H=H2-H1: M=M2-M1: S=S2-S1 190
>>>         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