MAME's Tandy 200 emulation has a ROM for the LCD chip, which I mistakenly thought meant it had an emulated processor. Turns out the ROM is just for the built in character generator. (And it might not even be the right LCD driver as it is for the HD61830 not the HD61100.)
https://git.redump.net/mame/tree/src/devices/video/hd61830.cpp --b9 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 >>>> >>>
