It turns out having no Option ROM activated also breaks the serial port, presumably because the baudrate is now too slow. I deactivated the Option ROM because I have been having strange conflicts with a machine language program that places itself in “LOMEM” (A000H), before BASIC.
Without REX# installed, I can use James Yi’s ADMINS <https://github.com/LivingM100SIG/Living_M100SIG/blob/main/M100SIG/Lib-10-TANDY200/ADMINS.SRC> utility to install or uninstall ADSM.CO <https://github.com/LivingM100SIG/Living_M100SIG/blob/main/M100SIG/Lib-10-TANDY200/ADSM.DOC> in LOMEM. That’s a useful feature since it saves a significant chunk of memory and keeps the assembler/disassembler out of the way of other .CO files. Unfortunately, when I tried with REX#, the screen would lock up and only a hard reset would fix it. Are Option ROMs incompatible with LOMEM programs? Could it be an issue within REX# itself? Or could it have something to do with the way the ADMINS program tries to replace the MENU option for ADRESS, SCHEDL, or MSPLAN with an entry for ADSM? Thanks for any help! —b9 On Wed, Feb 11, 2026 at 5:31 PM B 9 [email protected] <https://mailto:[email protected]> wrote: I was trying to figure out why Virtual-T is faster and deactivated the > Option ROM wondering if that could have any impact. I was surprised that > REX# would affect a running BASIC program at all. Even with an Option ROM > activated, REX# still showed a slow down (about 10%) but I didn't > investigate that deeply as I don't have a non-REX Option ROM handy to > benchmark against. > > —b9 > > On Tue, Feb 10, 2026 at 5:13 PM Stephen Adolph <[email protected]> > wrote: > >> Thanks, this is interesting. >> Perhaps I can do something to improve that. >> >> Having no option rom activated seems like an unusual state. Why do you >> have no option rom activated? >> >> Steve >> >> On Monday, February 9, 2026, 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 >>> >>
