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
