To say that Tandy’s TRS-80 Model 100 was an influential piece of computer hardware would be something of an understatement. While there’s some debate over which computer can historically be called the “first laptop”, the Model 100 was early enough that it helped influence our modern idea of portable computing. It was also one of the most successful of these early portables, due in part to how easy it was to write your own software for it using the built-in BASIC interpreter.
But as handy and capable as that integrated development environment might have been, it never produced anything as impressive as this Baldur’s Gate III “demake” created by [Alex Bowen]. Written in assembly, the game’s engine implements a subset of the Dungeons & Dragons Systems Reference Document (SRD), and is flexible enough that you could use it to produce your own ASCII art role-playing game that can run on either a Model 100 emulator like Virtual-T or on the real hardware.
Don’t worry about not having enough experience with the Model 100’s hardware to conjure up your own fantasy adventure. Assembly is done through zasm, and even though the code is intended for the 8085 CPU used in the Model 100, it’s actually written in Z80 syntax. The assembler’s support for mapping unicode characters also allows you to get a serviceable preview of what the levels will look like on the Model 100’s display right inside of your editor.
As you might imagine, getting such a complex game running on the meager hardware of the Model 100 took considerable trickery. [Alex] goes into plenty of detail in the project’s documentation and the video below, but perhaps our favorite optimization is the text compression routine. A Python script ran through all of the text strings used in the game to identify the most commonly used character sequences, and then mapped them to values which could be used to piece together words and sentences. This saved approximately 1500 bytes, which might not sound like a lot to a modern game developer, but it’s much appreciated on a machine that’s only got 24 kilobytes of RAM to begin with.
We’ve seen a number of projects featuring the TRS-80 Model 100, but most of them involve ripping out the original hardware and replacing it with something modern. That said, if you’ve got a stock Model 100 and give this technical masterpiece a shot, we’d love to hear about it in the comments.
Respect!
I’ll have to dig out my M100. I’ve needed a reason to power it up.
Awesome work, love it! Though I think the comment about Virtual-T not supporting the original floppy drives is incorrect … I coded it myself. :) Just choose Peripheral Setup->COM Tab->Connect to simulated NADSBox. The NADSBox is an external piece of HW I also developed which emulates the original floppy drive protocol.
Ahhh, I overlooked that! This is really cool, thanks for letting me know!
Ah, and also, thanks for building such a useful tool, in general! The memory editor and CPU state view were also hugely helpful in getting this working!
My pleasure! I was wondering if you used VirtualT during your development (I kinda figured you did but didn’t want to assume).
Update: Thanks to majick on GitHub, there is now a more standard .co file available for running via the cassette interface. Updated running instructions can be found here:
https://github.com/ajbowen249/mol?tab=readme-ov-file#from-cassette
This should in theory be loadable just fine via TS-DOS’s “DOS-ON” mode with a TPDD or dlplus/LaddieAlpha on the other end. I’ll put in a PR for the docs once I verify it works (i.e. that the .CO doesn’t clobber the DOS-ON stub) — just need to bring some AA batteries downstairs.
If not, I’ll force-load it the old fashioned way and make a REX .BX image for people to use on Real Hardware.