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