De-installing REXMGR is not a wonderful solution as I want to be able to use it to backup my explorations into assembly language. I expect I'll be causing a lot of unintentional cold boots. ;-)
Regarding the LOMEM problem, you are correct that installing REXMGR after ADSMLO <https://github.com/hackerb9/Living_M100SIG/raw/refs/heads/main/M100SIG/Lib-10-TANDY200/ADSMLO.DO> does seem to work! I did have a temporary glitch where using ^B on the MENU screen did not backup my RAM. It gave me an odd message, "Can't because it's WP!" which I took to mean "Write Protected". I used REXMGR and simply hit Enter on the current image, which refreshed the image from RAM correctly. It was not write protected and using ^B from the MENU has worked after that without issue. Even better, REX# correctly backed up ADSM in the LOMEM area. (When I restore from that image, my MENU now has MSPLAN replaced by ADSM. Yay!) Having no Option ROM selected causes the serial port to read data as line noise, the same as if I had the baudrate set wrong. Why would the lack of a ROM cause _more_ interrupt servicing? I did not realize that REX# has a "healthy processor tax" when I'm just in BASIC. Is that needed to catch calls that might access an option ROM? I don't know much about Model T interrupts, or even what tricks REX# needs to be able to work, but would like to learn more. Is there documentation somewhere about the REX# design and what decisions were made? (The "Technical Information <https://bitchin100.com/wiki/index.php?title=REXsharp#Technical_Information>" section on the Bitchin' 100 Wiki just says "Work in progress!!") Thank you, —b9 On Thu, Feb 26, 2026 at 5:00 AM Stephen Adolph <[email protected]> wrote: > 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 >>>>> >>>>
