REXMGR has to be the lowest .BA in RAM, and changing the Lomem setting at a minimum breaks the installed REXMGR program. IIRC you should be able to install REXMGR on top of something in LOWMEM, but I can't say I have tested that recently.
My suggestion to you is to de-install REXMGR when you are feeling adventurous! Sounds like that is really what you need. You don't want REXMGR interfering with these other programs. De-installation will leave the selected option rom in place but that should be fine. If you find the option ROM is further causing trouble, a power cycle should return REX to default state with it's own ROM code present, which won't do anything if you don't CALL 63012. There isn't really a use case for having no option rom selected/activated. It made REXMGR more robust in the case of REXCPM because the device starts life as a blank piece of ram. Original REX and REX#/REXCPM differ in how much work they do with interrupts, and these changes were to improve interop with option ROMs. That's why they perform differently. Getting the interrupt behaviour to meet all requirements has been the biggest challenge with REXes. When you say having no ROM selected breaks the serial port, is it that the serial port cannot keep up or is it totally non responsive? You observe a healthy processor tax due to heavy timer interrupt servicing, causing the slowdown. It would make sense that a busy serial port could then cause an interrupt storm. The obvious fix is to either de-install or de-activate REXMGR and remove the timer interrupt taxation. cheers Steve On Thu, Feb 26, 2026 at 1:14 AM B 9 <[email protected]> wrote: > 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 >>>> >>>
