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