There is a retro-computing enthusiast in the UK named Sarah Libman who came up with LibRom, a TRS-80 Model 100 replacement system ROM that has Teeny embedded in place of the cassette load/save code. Teeny is a very lightweight Tandy Portable Disk Drive client originally from Ron Wiesen, which takes around 750 bytes of RAM. The LibRom port of Teeny is actually called Teeny+ as it has some conveniences added, like the ability to just type "L FILE.BA" and not have to do a bunch of space padding.

After reviewing the construction of LibRom 1.1, I took on the task of implementing a similar thing for the NEC PC-8201A. In my implementation of LibRom (which I'm calling WebRom), I've added directory navigation using the directory mode extensions supported by Backpack, LaddieAlpha, mComm, and others. In addition to supporting the "L FILE.BA", "S FILE.DO", "K FILE.CO" type of commands that the LibRom flavor of Teeny+ implements, in WebRom you now also can navigate folders with "CD FOLDER", "CD ..", as well as list files with "LS", giving you a usable shell-like interface. To fit all of this, in addition to nuking the cassette code, it required also excising the WAND: support routines. As I never use cassette for storage nor use a bar-code reader, it made sense to remove that stuff in favor an actual command line interface for loading/saving files.

After you're done you just type "m" to exit back to the main menu. This makes my NEC main menu incredibly useful, and now I no longer have to have a dedicated disk-rom like TS-DOS or SARDOS loaded. That's a great thing because, these days, I'm loving using my new SuperROM-NEC option rom. I'm still doing a ton of testing with this but I do plan to make WebRom available to the NEC computing public sometime soon! Just giving you a sneak peek for now.

For a while now I've been porting SuperROM, PCSG's classic 32 KB option ROM for the TRS-80 Model 100, over to the NEC PC-8201A and PC-8300. It's far enough along now that all four applications run without any flaws I've hit yet, so I want to tell the whole story: how it started, why it was harder (and, in one crucial way, easier) than it looked, and, because this is where I need help, where it stands and how you can pitch in.

What SuperROM is

SuperROM is a single 32 KB option ROM that puts four applications behind one menu on the Model 100 (and Tandy 200):

• Lucid: a spreadsheet
• Write Rom: a word processor, with printing
• Thought: an idea / outline processor
• Lucid Data: a relational database with forms entry and searching

The NEC PC-8201A and PC-8300 are close cousins of the Model 100: same 8085 CPU, and the same 32 KB Kyocera system-ROM architecture underneath. That family resemblance is the whole reason a port is even thinkable, but the differences, as always, are where the work lives.

How it started

It began as just an investigation of all of the math routines that Stephen Adolph was trying to find in the NEC system ROM, during his first attempts at exploring creation of a SuperROM for the NEC. It was clear early on that shims would be needed for all of the math routines, because the two machines store floating-point numbers in different internal formats (and at different precision). SuperROM is a fixed 32 KB image that can't grow, so the scary question was whether there'd even be room for the shims without sacrificing something, like one of the four apps (shudder!).

As I dug into SuperROM itself, I started finding pockets of dead space: small runs of unused 0xFF bytes scattered through the ROM. It gradually became clear there was probably just enough room to hand-write the shims the NEC needed.

And then, OCD took over:

The one mechanism everything rests on

Here's the good news that makes the whole project tractable. An option ROM is banked in over the bottom 32 KB of memory, which means that while it's running it can't actually see the system ROM it needs to call. SuperROM solves this the classic Kyocera way: a tiny pair of stubs that live in RAM (which stays visible in either bank state). SuperROM reaches every system routine through a single disciplined mechanism: a software interrupt (RST 1) with the target address written inline right behind it. That lands in a handler that flips the bank latch to swap the system ROM back in, calls the routine, then swaps the option ROM back in and returns to the caller with all registers and flags intact. From the calling side, a banked-out system call looks completely local.

Because there are essentially no other ways SuperROM calls the system ROM, the port is, on paper, a giant find-and-replace: swap every Model 100 ROM address for its NEC equivalent, swap every RAM variable address, done. That's genuinely true for about 90% of the bytes. It's the other 10% that turned into a months-long detective story.

(Porting the trampoline itself was step zero. The mechanism is identical on the NEC, but the bank latch isn't: the Model 100 writes one I/O port and keeps a shadow copy in RAM, while the NEC writes a different port and can read the latch straight back. I padded the NEC stub with a couple of no-ops so it stays byte-for-byte the same length as the Model 100's, which quietly turns every reference into those stubs into one uniform offset instead of an edit at every site.)

Why "just find-and-replace" is a trap

The catch is that an address only looks like a system call in the places an automated tool actually walks. SuperROM is full of code that hands the CPU a system address by other means: trampolining "by hand" (pushing a target and jumping straight into the bank-out stub, with no RST 1 for a scanner to notice), writing an address one byte at a time as two separate immediate loads, or storing a whole table of addresses that some later computed jump indexes into. None of those look like a system call, so they sail through untranslated, and then the ported ROM calls a Model 100 address on a machine where that address is something else entirely.

That's exactly how the clock-tick interrupt handlers, the Write Rom editor launch, and new-file creation all ended up bouncing into the wrong NEC routine. Each one was a runtime-only bug (a crash or a garbage screen), and each needed its own little detective story (and often its own purpose-built scanner) to find.

My favorite: 7 + 2 came out 7. Lucid dispatches every arithmetic operator by looking its routine up in a hidden table of addresses and jumping there. That table was untranslated, so on the NEC "add" jumped to whatever happened to live at the Model 100's "add" address, which did nothing, and the second operand just evaporated. It presented as a floating-point bug. It was really a jump table hiding in plain sight as data.

The floating-point wall that wasn't

Floating point was the scariest item going in, and many of you will know exactly why. Not only do the two machines store numbers differently, they run different Microsoft BASIC dialects, assembled at different times from different sources, so the entire math library came out arranged differently. Add, subtract, multiply, divide, compare, the integer/float conversions, number-to-text formatting, and the whole transcendental set (square root, log, exp, sin, cos, tan, arctangent, random) all sit at different addresses on the NEC, and several are different implementations with their own calling conventions. There is no 1:1 table you can just apply.

If Lucid did its own math on the raw number bytes, this would have meant re-implementing an entire floating-point engine by hand. It turned out Lucid is smarter than that: it delegates all the actual math to the system ROM and only ever touches raw numbers to move them around or to pull out a plain integer. That one fact collapsed "rewrite floating point" down to a short list of surgical fixes:

• The routines that copy an 8-byte number around had no NEC equivalent, so I hand-wrote a ~35-byte one into unused ROM space and pointed the copy sites at it.
• The 16-bit integer that lives inside a floating-point number sits at a different offset on the two machines, so a dozen spots had to reach two bytes further over.
• Negating a number flips a sign bit that lives in a different byte on each machine (an early wrong guess had −A1 proudly returning +7).
• There's no power routine that fits SuperROM's calling convention, so X^Y is computed the classic way, EXP(Y × LOG(X)), in another hand-written stub. That one ate a good chunk of the contiguous free space I had.

None of that is a rewrite. But finding the boundary (which byte-level touches are format-safe and which aren't) was most of the work, and it only became clear by auditing every single place Lucid reaches into a number. Proving each math routine then meant running it: 7+2 = 9.00, SQR(7) = 2.65, EXP(1) = 2.72, and on down the list. I've also verified the spreadsheet functions: +SUM(A1:A4), +REF("other-sheet.CA",F6), even the +TBL() lookup.

When the machines simply disagree

Some differences aren't address swaps at all; they're genuine design disagreements that needed a small bridge of new logic:

• No internal modem on the NEC, so Write Rom's auto-dial is switched off, but the actual file transfer, which goes over the serial port, keeps working.
• "A RAM file" is a different device number on the two machines, which quietly derailed creating a new document until a nine-byte stub asked for the right one.
• The main-menu file list looked for a long time like it lived in CPU registers on the NEC, and that wrong belief defeated several attempts at file auto-launch. It was wrong: the routine that actually launches a selection reads the cursor straight out of memory, exactly mirroring the Model 100. The port had simply mapped one variable to a garbage address. Once I stopped trusting the belief and disassembled the system's own launch routine, the fix was about 40 bytes, and now selecting a Lucid .CA from the main menu opens it directly in Lucid, and a Thought .CT opens in Thought, just like on the Model 100.
• Data files are not directly interchangeable. A Lucid .CA or Thought .CT file carries machine-specific pointers in its header (the menu-launch pointer, plus a few embedded RAM addresses), so a file made on the Model 100 has to be translated before the NEC will open it correctly. I've written a small converter that rewrites those header pointers between the two formats. One caveat it flags but can't fix: cached floating-point cell values are stored in each machine's native number format; formula and table cells recalc themselves on load and self-correct, but a literally-typed number may need to be re-entered after conversion.
• Function keys, directories, dates, and the banner all diverge in small, specific ways. One current cosmetic gap: the NEC has no day-of-week table, so the day name in date displays is a blank placeholder for now.

The one that reads like a magic trick: the Write Rom file-list cursor wouldn't move between files, so I wrote a shim to bridge a NEC routine's register-style result back into the memory location SuperROM reads. First try: left-arrow worked, right-arrow did nothing. The system routine decides direction by reading CPU status flags left over from a subtraction, and my shim did a little arithmetic that clobbered those flags on the way in; left-arrow happened to survive, right-arrow didn't. One extra instruction to restore the flags, and both worked. That's the whole project in miniature: 90% mechanical, and the last 10% is understanding a 40-year-old routine well enough to know which CPU flag it's reading and why.

How it's actually debugged

All of this runs against two VirtualT emulators side by side, a Model 100 as the "known-good oracle" and the NEC as the patient, talking to a debugger over a socket so I can freeze both at the same spot, dump the same registers and memory, and watch for the exact instruction where the NEC's behavior peels away from the Model 100's. Fix that divergence, rebuild, byte-diff the new ROM against the old to prove only the bytes I meant to change changed, then re-run a disassembler over the whole thing to make sure no data got mistaken for code. Then back to the emulators to confirm it on real behavior. (Huge thanks to Ken Pettit, whose VirtualT and its debug socket made every bit of this possible.)

Along the way the project grew its own toolkit: a macro-aware tracer that actually understands SuperROM's inline-operand tricks, a "shape matcher" that locates a Model 100 routine's twin in the NEC ROM by its opcode skeleton and then validates the match, an emitter that applies the translation map with verify-before-write, and a family of little audit scripts, each one built to catch one of those invisible bug classes after it bit me.

Where it stands

This is honestly still an alpha, a 32 KB ROM full of clever 1980s assembly tricks running on a machine it was never written for, but it's in a genuinely exciting place:

• All four apps launch.
• Lucid: working for everything I've thrown at it: arithmetic, the math functions, and the spreadsheet functions (+SUM, +REF, +TBL). Needs more testing, but solid so far.
• Lucid Data: working, including forms entry and searching, and an intermittent data-corruption bug (traced to a stale build artifact in my own toolchain, of all things) is now fixed.
• Thought: looks solid; I can't find any differences in outline formatting or features between the Model 100 version and the NEC port.
• Write Rom: the shell works and is verified: open, edit, exit, new-file create, and file-list cursor navigation. But the bulk of its word-processing and printing code is a large body of essentially untested territory. This is my biggest concern right now.

Note: SuperROM-NEC changes two function-key assignments so the ROM behaves the way an NEC PC-8201/8201A/8300 owner expects, rather than the way the original Tandy Model 100 SuperROM did. As you know, the NEC keyboard has no dedicated PRINT key — the Model 100 has one, and SuperROM's printing functions were built around a user pressing it. The NEC also has ten function keys (F1–F10, the upper five reached with SHIFT) where the Model 100 has only eight, and NEC owners are used to pressing F10 (SHIFT-F5) to back out of a ROM application. So SuperROM-NEC moves EXIT to F10 and, since there is no PRINT key to fall back on, relocates PRINT to F8. You'll have to remember that SHIFT-F5 gets you out of SuperROM-NEC, as there's no on-screen hint for this; there wasn't space for it.

The ask: I'm looking for testers

If you know SuperROM well on the Model 100 or Tandy 200, I could really use your help shaking this out on the NEC. Right now I'm focused on testing under VirtualT (the build loads as an option ROM in the PC-8201A / PC-8300), so no hardware is required and there's nothing to risk.

Where I most need eyes:

• Write Rom: hammer the word processor and especially the printing features (print specs, headers/footers, and document "sending"). This is the biggest block of unverified code.
• The .CT → Thought auto-launch end-to-end with a real Thought file, and the behavior with a full directory.
• The .CA → Lucid auto-launch end-to-end with a real spreadsheet file, and the behavior with a full directory.
• Anything in Lucid, Lucid Data, or Thought that behaves differently than you remember it on the Model 100 or T200: that's exactly the kind of surprise I want to hear about.

One thing you don't need to report: the day-of-week name in date displays is a known cosmetic gap. The NEC has no day-of-week table, so for now it shows a blank placeholder rather than "Mon", "Tue", and so on. It's on my list.

Thanks for reading, and thanks to Stephen Adolph, whose math-routine hunt kicked this whole thing off, and Ken Pettit, whose VirtualT is the workbench the entire port was built on. I'm genuinely thrilled with where this is, and I'd love company for the last mile.

If you're interested in testing, use the "Contact me" link below.