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