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]
