Hi Steve, I've actually had DeIn work fine, as well as cold-start the machine. So it's kind of a mixed bag. Also what corrupts it every time regardless is a Bank switch. Is there anything REXMGR does when we switch banks? When I come back to Bank #1 where I have USC200.co installed, things are in a weird state.
Anyway I'll take your suggestion and we can chat offline about it. I'm sure there's a path forward to get them to play nicely together. Gary On Thu, Sep 10, 2026 at 6:35 AM Stephen Adolph <[email protected]> wrote: > "create default flash" does not necessarily give you the same REXMGR > installation. Check versions. AFAIK the last version of REX software has > not been integrated into VirtualT. > > Also, when problems arise from interrupt timings, I have found VirtualT > and real machines have different behaviours. You may see interactions in > one place and not the other because interrupt driven events may or may not > execute in the same way relative to other processes. > > I think the question you can answer however is - how is it possible for > REXMGR and Ultrascreen co-exist? In current REX software, REXMGR.(BA) is > the "first .BA" program in RAM. It heavily relies on ALTLCD to operate. > REXMGR also makes use of defined M100/T200 hooks to operate. So there are > lots of sources for conflict. > > I expect there is some conflict. I suggest we take the discussion offline > to try and piece together how REX# and Ultrascreen can be made to work > together, or at least understand why REX Classic seems to break it. > > With REX installed, try de-installing REXMGR using F7 in the REX > application. Then see if the problem persists. > > Steve > > > On Thu, Sep 10, 2026 at 12:17 AM Gary Weber <[email protected]> wrote: > >> Aha! I didn't see the option before now but the "Create Default Flash" >> button in VirtualT was staring right at me. >> So I did, and now I do have a functional REXMGR in VirtualT for the T200. >> >> Still, the conflict doesn't manifest in VirtualT. It's only on my >> physical Tandy 200 where I can experience the problem, so I'm still stumped. >> >> On Wed, Sep 9, 2026 at 9:11 PM Gary Weber <[email protected]> wrote: >> >>> I'm trying to track down a weird issue on a real physical Tandy 200 that >>> also has a REX Classic installed. >>> Anyone out there have that combo? >>> >>> I don't know specifically if it's a REXMGR conflict with Ultrascreen200, >>> but all of the following works great in VirtualT: >>> >>> * I can run REXMGR and install option ROMs like TS-DOS or SARDOS, and >>> use them. >>> * I can run CLEAR 0, 57397 from BASIC in order to load USC200.CO, which >>> worked fine. >>> * I run the USC200.CO from the menu and it installs fine. >>> * Once the Ultrascreen200 resident part installed, everything renders >>> fine and I can run all kinds of programs. >>> * As soon as I try to run any CLEAR <value> from Basic, other than the >>> uninstall values (CLEAR 0, MAXRAM), I get ?OM Error. >>> >>> Again, I can do all of this stuff in VirtualT. My biggest challenge is >>> my "*VirtualT/T200*" folder lacks the 1mb *rex_flash.bin *file that I >>> would need in order to run an emulated REX Classic within VirtualT, and so >>> I'm lacking strong troubleshooting tools. >>> >>> Anyway if anyone out there has a REX Classic in your Tandy 200 and are >>> willing to test the above, I want to find out if this is a systemic issue >>> in *all* Tandy 200s configured this way, or something is up with my setup >>> specifically. >>> >>> I appreciate it, >>> Gary >>> >>> >>> >>> On Tue, Sep 8, 2026 at 1:13 AM Gary Weber <[email protected]> wrote: >>> >>>> That's what I get for getting up in the middle of typing out a message, >>>> coming back to it and thinking I'm done.... >>>> The three things: Typing in the TEXT editor is finally usable, a long >>>> delay when you create a new .DO file has been eliminated, and a nasty cold >>>> start bug from v1.0 has been fixed. >>>> >>>> I'd love to hear from real Model 200 owners on this list who can help >>>> out with testing USC200.CO on real hardware. I do have real hardware >>>> as well but would love extra eyes on this. >>>> >>>> Gary >>>> >>>> >>>> On Tue, Sep 8, 2026 at 1:01 AM Gary Weber <[email protected]> wrote: >>>> >>>>> *New version: *Ultrascreen 200 v1.1 >>>>> >>>>> I've just posted the v1.1 version of Ultrascreen 200 which now uses >>>>> shadow buffering logic. Compared to v1.0 it delivers three things: first, >>>>> the TEXT editor is finally usable on real hardware: a 60×21 character >>>>> shadow buffer lets the renderer skip re-blitting any cell that hasn't >>>>> changed, so typing keeps up with the keyboard. This is quite a bit better >>>>> than Ultrascreen 100, and I may be considering back-porting the logic to >>>>> improve the experience on the Model 100. >>>>> >>>>> Download can be found in the Ultrascreen download area on Web8201 >>>>> <https://www.web8201.net/default.asp?content=/Files/body.asp%3Fname=Ultrascreen%20for%20the%20M100/T200/NEC%26url=Ultrascreen>, >>>>> as well as my Personal Library on Club 100 >>>>> <https://www.club100.org/memfiles/index.php?direction=0&order=&directory=Gary%20Weber&;> >>>>> . >>>>> >>>>> Gary Weber >>>>> Web8201 >>>>> >>>>> On Sat, Sep 5, 2026 at 8:05 PM Gary Weber <[email protected]> wrote: >>>>> >>>>>> On paper, porting Ultrascreen100 to the 200 should have been the easy >>>>>> one. After all, the T200 is the M100's big brother, right? Same >>>>>> Microsoft >>>>>> ROM lineage, same feel. So a lot of Ultrascreen's original console logic >>>>>> could come along for the ride, in a way it never could on the very >>>>>> different NEC. Except that the Tandy 200 has one enormous advantage over >>>>>> the Model 100, and it lives in the exact piece of hardware a display >>>>>> driver >>>>>> cares about most: the screen. It's bigger, and it's wired completely >>>>>> differently. (More on that in a minute!) But today I can say >>>>>> Ultrascreen200 is done, and it's the best Ultrascreen yet. >>>>>> >>>>>> Here's the headline: Where Ultrascreen100 and UltrascreenNEC give you >>>>>> 60 columns by 10 lines, Ultrascreen200 gives you 60 columns by 21, and >>>>>> that's 20 with the function-key labels showing.) That's more than double >>>>>> the lines on screen. BASIC, TEXT, TELCOM, ADDRSS and SCHEDL all run in >>>>>> that >>>>>> roomy 60-column display; SCREEN 0 and SCREEN 1 flip between 40 and 60 >>>>>> columns on the fly; and it installs and uninstalls cleanly with a "REMOVE >>>>>> Ultrascreen? (Y/N)" confirmation, handing all its memory back. The Tandy >>>>>> 200's taller LCD is the gift! But collecting that gift meant throwing out >>>>>> the single most important routine in the original code. >>>>>> >>>>>> 1. The rendering engine: the screen was turned sideways. This is the >>>>>> big one. >>>>>> >>>>>> The Model 100 and the NEC organize their LCDs the same way: >>>>>> column-major. A byte you write to the display is a vertical stack of >>>>>> eight >>>>>> pixels, and the screen is carved into 8-pixel-tall horizontal bands, each >>>>>> reached through its own chip-select. Daniel Born's entire small-font >>>>>> blitter is built around that geometry; to place a small character on a >>>>>> screen where the character rows don't line up with the 8-pixel bands, it >>>>>> shifts the glyph's bits vertically and smears them across two neighboring >>>>>> bands. That vertical bit-shifting blitter is the beating heart of >>>>>> Ultrascreen100, and it's why the small font looks so crisp. >>>>>> >>>>>> The Tandy 200's LCD is the exact transpose. It's row-major and >>>>>> linear: a byte is six pixels laid out horizontally, and the address of >>>>>> any >>>>>> point on the screen is simply the pixel row times 40, plus the column. No >>>>>> vertical bands, no chip-select straddling. Which meant the one routine I >>>>>> most wanted to reuse was completely useless to me. Every assumption it >>>>>> made >>>>>> was rotated ninety degrees. The vertical shifting was meaningless. Where >>>>>> the Model 100 straddles two bands vertically, the Tandy 200 straddles two >>>>>> bytes horizontally, whenever a character doesn't begin on a byte >>>>>> boundary. >>>>>> >>>>>> So I rewrote the rendering engine from scratch for the transposed >>>>>> layout: build each small glyph as a set of horizontal row-bytes, mask and >>>>>> OR it into place across the horizontal byte boundary, and lay it down one >>>>>> row at a time into that linear grid. Scrolling had to be rebuilt on the >>>>>> same principle: instead of shuffling 8-pixel bands around, I copy pixel >>>>>> rows straight up the linear framebuffer. This was, by a wide margin, the >>>>>> hardest and most finicky part of the whole project, and it's the part >>>>>> that >>>>>> makes those 21 lines possible. There's even an unexpected bonus: because >>>>>> the framebuffer is linear, the function-key label row stays rock-solid >>>>>> during a scroll, where on the Model 100 and NEC it flickers. >>>>>> >>>>>> 2. A self-tracked console, and everywhere it bit me. >>>>>> >>>>>> Because I'd replaced the renderer anyway, it made sense to let >>>>>> Ultrascreen200 track the cursor itself: my hook draws the small glyph at >>>>>> my >>>>>> own row and column, then "neutralizes" the character so the ROM doesn't >>>>>> also stamp it out in 40 columns. That's a tidier model than following the >>>>>> ROM's cursor the way Ultrascreen100 and the NEC do, right up until you >>>>>> remember how much work the ROM's positioned output was quietly doing for >>>>>> free: laying out the function-key labels, addressing the cursor in TEXT, >>>>>> drawing the app screens. My self-tracking threw all of that away, and I >>>>>> spent a long stretch of this project rediscovering, one feature at a >>>>>> time, >>>>>> that the fix was almost always to sync back to the ROM cursor the way the >>>>>> original code did. Nearly every strange bug in an app, i.e. a banner >>>>>> getting painted over, a stray marker, the cursor blinking in the wrong >>>>>> spot... traced straight back to that one architectural decision. >>>>>> >>>>>> 3. The one I couldn't have: MSPLAN. >>>>>> >>>>>> The Tandy 200 has something the Model 100 never did: MSPLAN, the >>>>>> built-in spreadsheet. I would love to tell you Ultrascreen200 drives it >>>>>> in >>>>>> 60 columns too, but it doesn't, and after tracing through the ROM I'm >>>>>> confident it can't, at least not from Ultrascreen's side. This one is a >>>>>> strict technical incompatibility, not a bug waiting to be squashed. >>>>>> >>>>>> The reason is how MSPLAN runs. BASIC, TEXT, TELCOM, ADDRSS, SCHEDL >>>>>> all live in the standard ROM, and Ultrascreen works by hooking that ROM's >>>>>> console output. MSPLAN doesn't play in that sandbox. It bank-switches its >>>>>> own 32K ROM in over the standard one and takes the machine over entirely. >>>>>> While it's running, Ultrascreen's hooks are never even called: MSPLAN >>>>>> drives the display through its own banked code and never touches the >>>>>> paths >>>>>> Ultrascreen lives in. There's simply nothing for Ultrascreen to hook. >>>>>> Making MSPLAN render at 60 columns would mean modifying MSPLAN itself >>>>>> (patching its ROM), and I'm not about to ask anyone to swap ROM chips in >>>>>> their Tandy 200, nor am I signing up to reverse-engineer Microsoft's >>>>>> spreadsheet, at least not today. :-P >>>>>> >>>>>> There's a memory wall on top of that. MSPLAN carves its work area out >>>>>> of the very top of RAM by lowering the memory ceiling itself, and it >>>>>> refuses to start if it finds anything already parked up there. That's the >>>>>> "MP work area in use" message. That isn't an Ultrascreen bug either. It's >>>>>> simply how Multiplan claims memory, and it will fight any resident >>>>>> program >>>>>> the same way. Not being someone who lives on a Tandy 200 day to day, I >>>>>> hadn't bumped into this limitation until now. >>>>>> >>>>>> So for the moment the answer is the manual one: uninstall Ultrascreen >>>>>> (CLEAR 0,MAXRAM), run MSPLAN, then reinstall. What I likely can do is get >>>>>> the two to coexist peacefully so that Ultrascreen steps out of the way on >>>>>> its own when you launch MSPLAN and you're spared the uninstall/reinstall >>>>>> dance. Sixty-column MSPLAN isn't in the cards, but a clean, automatic >>>>>> handoff is. >>>>>> >>>>>> So that's Ultrascreen200. It leans on the original Ultrascreen code >>>>>> far more than the NEC port ever could, as the Tandy 200 really is the >>>>>> Model >>>>>> 100's cousin, and yet the thing that makes it special, that big 60-by-21 >>>>>> screen, came out of the one place where the two machines couldn't be more >>>>>> different. More than double the lines of the original, on hardware from >>>>>> the >>>>>> mid-1980s. >>>>>> >>>>>> You can find *USC200.ZIP* available for download up in the Ultrascreen >>>>>> download area on Web8201 >>>>>> <https://www.web8201.net/default.asp?content=/Files/body.asp%3Fname=Ultrascreen%20for%20the%20M100/T200/NEC%26url=Ultrascreen>, >>>>>> as well as my Personal Library on Club 100 >>>>>> <https://www.club100.org/memfiles/index.php?direction=0&order=&directory=Gary%20Weber&;> >>>>>> . >>>>>> >>>>>> -- >>>>>> Gary Weber >>>>>> [email protected] >>>>>> >>>>>
