On Fri, Feb 27, 2026 at 9:51 AM Stephen Adolph <[email protected]> wrote:
> I think to minimize REX CPU tax, you should just have TS-DOS active. > Will do. I had only deactivated the Option ROM because things weren't working and I had hoped it would help. > 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. > Oh! That sounds ideal. Weirdly, on my T200 REX#, F7 is labelled "DeIn" and hitting it deinstalled everything — "All REX software is removed. Press any key to restart laptop." — and REXMGR is no longer available. If I hit TAB, the DeAc menu option shows up on F6, but it only works for Option ROMs, not REX. Now that I've found out that I *can* use my REX# with LOMEM programs, I hope I won't have any further need to de-activate or de-install REX. > 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. > First, thank you for the thorough explanation! This is helpful to me (and I hope others) to understand REX . It's wacky that this architecture requires having an always active timer just to run on power-up, but also kind of amazing that you figured out a way to do it. Having done a quick readthrough of Mo's "Secrets of ROM" book, I had thought there was a way for Option ROMs to activate automatically ("OpOn"), but clearly the situation is more nuanced. Perhaps what I'm misunderstanding is the word "power-up"; does "OpOn" not get run after a "warm start"? > 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. [...] > I'm probably showing my ignorance here, but couldn't REXMGR program the CPLD to return bogus data if the Option ROM is deactivated instead of returning the REX ROM data? I tried to simulate that by setting my option ROM to be 32KB of the character DFh and it sort of worked. (It did require me to hit the reset button after selecting it as I believe REX was automatically trying to start the "ROM".) Speed was okay, which is what I expected since it didn't have the magic bytes so REXMGR's timer handler ignored it. Or is this not possible because of how REXCPM is providing a full 64KB RAM address space? 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. > Again, thank you for the thorough answer! I think I understand now that, when power-cycled, the CPLD doesn't remember what Option ROM it is supposed to be showing and so it needs to be initialized by something. In this case, that "something" is REXMGR via a hook on the timer interrupt. Here's a part I'm not quite clear on, but let me know if I am understanding it right: The CPLD's memory is not battery backed up and so even a simple warm start requires it to be reprogrammed to show the correct Option ROM image. When REX is first installed, it adds a hook in RAM so that REXMGR is called by the timer interrupt. The RAM in a Model-T is backed by the battery and so it is not lost during a normal "power off" and "power on", and thus REXMGR is able to reprogram the CPLD as needed. Is that all correct? Okay, my ignorance is going to be on display here, so please be forgiving: Aren't there alternatives to using the timer interrupt that would work and not affect BASIC? I had thought the Model T would have a warm-start routine or interrupt one could hook into for when the device turns on. Is there no such thing? Since the MENU program is run automatically on power-up, would it be possible to hook into that instead? Or, if a timer interrupt is absolutely required, couldn't REXMGR be set to only check once every second instead of 256 times? > 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. > Please don't go out of your way to create documentation. Yes, I'm curious about the internal workings of the REX chips and would love to read more, but only as it fits with your life. I'd much rather see you following your genius and building the next great Model T upgrade. —b9
