hi B 9, see comments below. I think to minimize REX CPU tax, you should just have TS-DOS active. I also think you should be able to disable REX so that the timer hook is removed. This should allow the T200 to operate as if REX was not installed at all. Then when you want to back things up, just re-run REXMGR and you can do what you want to back up your RAM.
On Fri, Feb 27, 2026 at 5:15 AM B 9 <[email protected]> wrote: > 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. ;-) > Why not? just disable the interrupts via F7. REXMGR remains in RAM. When you want to do a backup, re-run REXMGR, which allows you to do a backup. De-activate removes the timer hook. <-- this is probably what you want. De-install removes everything including REXMGR. > 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!) > > Yeah there might be a bug lurking in there somewhere. Glad the lowmem tolerance feature is still working. > 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? > The only way REX interferes with the serial port is through competition for interrupt time. I suspect that the UART is getting a new byte before the CPU is allowed to pull the last byte out. This is because when REXMGR is active, it disables interrupts. And when REXMGR is doing a lot of stuff, the UART may be signalling "hey I have a byte! please take it" but the CPU is ignoring the port. > 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? > The timer interrupt is central to how REX works. The timer interrupt is intercepted by REX constantly. The simple reason is that the only way to autoconfigure after a power cycle is to rely on the timer hook to trigger REXMGR to inspect the system and switch the option rom (and other things). The CPLD used in REX has no permanent memory, and configuration does not survive a power cycle. So when the machine starts, the timer interrupt is the only reliable way to get the REX software to activate. Since the timer hook has to run on power-up, that means it must remain active at all times, so that it is always available. There is not a reliable way to re-enable the timer hook on power-down. So, the timer hook is constantly doing some homework while the laptop is running. What is that homework? Job 1 is to see what is configured. There are 2 possibilities. It can either be the REX ROM image, or it can be any of the other blocks in REX. The REX rom image is easy to detect; address 0x0004 contains "REX#". This is a really quick check, very low tax on the timer interrupt. If it does not see "REX#" then it assumes the correct option ROM is configured. Done, return to the timer regularly scheduled programming. If REXMGR sees "REX#" it knows it has some work to do. * jump into REX ROM * read the directory to see what the active option ROM is * program the CPLD to switch the option ROM to the active one * detect if M100 is in "MENU"... if so, install the CHGET and CHPUT hooks. If not in "MENU" remove the CHGET and CHPUT hooks * jump back to the timer interrupt regular process When there is "no active optrom" REXMGR leaves the REX ROM active. This means this homework item is ALWAYS running when you don't select an active option ROM. Here is your answer for why there is MORE processor tax when there is no option rom selected. It is due to the way the timer hook program reacts to seeing that the REX ROM is present/active. On the other side of this, REXMGR does the *bare minimum* to ensure that REX is always configured when an active option rom is defined, and is able to quickly reconfigure on power up. 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 > 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!!") > It would be a large activity to document how REX works. I'm retired now so maybe I have the time. > > Thank you, > > —b9 > > >
