Your "long-winded" answer is greatly appreciated! Thank you for the tip on removing the REX hook. After hitting ^X at the MENU, my SPDCHK.DO program is back down to 10 seconds (instead of 11 with an Option ROM installed).
I presume you've already tried configuring the CPLD in the MENU hooks and it doesn't work. Do you recall what the issue was? When I hit Power Off while running an Option ROM, like T-Word, it always seems to go to the MENU when I press Power On. Is that not the case with all ROM programs? Could the problem be that Option ROMs can also hook into MENU and may run before REXMGR gets a chance to configure things? Does the Model T try to continue running Option ROM code when it powers on, similar to how it continues BASIC? I'm thinking that that can't be right because then even checking 256 times a second wouldn't be fast enough for REXMGR to prevent catastrophe. So what is REXMGR racing against? Is it the hooks that an Option ROM has left in RAM? I know you're reluctant to revisit it, but if you happen to remember why the standard Power On hooks were unreliable, it might be helpful to others who could run into the same problem in the future. Could it be that some Option ROMs use the Power On hooks as well? —b9 P.S. This is probably a silly question, but have you considered using a hardware interrupt to the 8085 when the CPLD first powers on? On Mon, Mar 2, 2026 at 5:43 PM Stephen Adolph <[email protected]> wrote: > Long winded thoughts below. > > BTW I misspoke, sorry if I caused confusion. > CNTL-X removes the timer hook but leaves REXMGR in place. > DeIn fully removes REXMGR and removes the timer hook. > DeAc de-configured an active optrom image. > > > On Mon, Mar 2, 2026 at 4:56 AM B 9 <[email protected]> wrote: > >> >> >> . >> 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. >> > > There are power-up and power down hooks that should have been usable. > When I explored trying to use the power-up hook as a way to > auto-configure, I recall being disappointed that it didn't work. I found > that the power up hook wasn't always run! Although I have no explanation > for why. I just recall that I could not rely on using that hook, which is > too bad. > > >> >> 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"? >> > > As far as I know, the main ROM has a way to detect if an option rom is > installed. It does not auto-start the option ROM. > > What does happen is (see section 5) the main ROM copies memory from 40-47 > in the option ROM to address FAA4. Then it looks at the first two bytes > and checks for "AB". > > "AB" is a special sequence for T200 and T102 but it is not the same > sequence for M100. Bit of a pain. > > 0389 = 4354 = TC (M100) > 0389 = 4142 = AB (T102, T200) > > Regardless, this routine is used to detect presence, not actually start > the ROM. > > Also, this code at F605 is typically re-used by an actual Option ROM for > their own purposes. > You can see this in virtualT- > > Compare locations at F605 before and after TSDOS is installed. > > Here is a key constraint - REX has to work in such a way that, when an > actual option ROM is in use, REX is unaffected and vice versa. > > All the mechanisms used by option ROM products must be avoided. REX has > to operate in an independent way. > > >> >> 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. >> >> > I think you are suggesting a way to differentiate two conditions. > 1) I've just powered up, all registers are default, and I've never been > configured, and REXROM is active, so attempt to configure "active ROM". > 2) I've just powered up, and I've seen already that there is no "active > ROM" to set up, and REXROM is active, therefore do nothing. > > I think to do this, there would have to be a dedicated register in the > CPLD. It would have to be a flag to indicate condition (2) above. > > Without thinking about it a whole lot, it would be doable REX# because > there are enough resources. In REXCPM it isn't clear because REXCPM CPLD > is above 95% utilized. > > In reality, I defined the firmware for REX# and REXCPM *before* I found > this need for a de-activated option ROM state. > > I haven't churned the firmware ever since introducing these things, > because I want a common hardware base for software to work with. > > >> >> >> 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? >> > > sounds correct. > The CPLD is "off" when the machine is off, to save battery. the CPLD is > logic and flip flops, and all the flip flops are reset on power up. > The registers store the config data for which option ROM is active. > > REXMGR in RAM, plus the timer hook, are what allow REX to be re-configured > again on power up, independent of any installed option ROM software. > TS-DOS, ROM2, SuperROM, UR2 all do different things to the laptop, and > have their own signature in RAM that has to be unaltered by REX. > > >> 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? >> >> > > Emphasis in REX is to reconfigure as quickly as possible. That means on > the very first possible timer hook. > Today, I don't attempt to reduce the frequency of timer hooks that are > intercepted. > > But yeah I can imagine there might be a way to grab the very first timer > hook and then every 256th one after that. It is a bit tricky because > REXMGR doesn't really know when a power up occurs. So how to tell the > difference between a timer hook that matched the "256th" test when in > reality it was post power-up and you need to act on the first timer > interrupt you see? > > Actually I think that's the problem. REXMGR cannot tell the difference > between the "very first timer" after a power up, and any other timer. One > would need to use the so-called "power down hook" to reset the counter, but > as Ive already found, the power down timer is somewhat treacherous. I don't > use either the power up or power down hooks at all. > > I've spent SOO MANY DAYS messing with how the hook program works and > interacts with the system, I am kinda reluctant to open the can of worms > again. But maybe I will become bored in my retirement. > > >
