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] >>>> >>>
