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