Over the past year, I have been writing an emulator for the original IBM PC Model 5150, and its slightly more advanced brother, the IBM XT Model 5160. These systems are the original ancestors of the modern PC, both released in the early 1980's. This project is both my first emulator, and my first project in the Rust programming language. A lot to learn all at once.
I had a tiny bit of assembly language experience from reading Randall Hyde's Art of Assembly ages ago, and in the 00's had reverse-engineered a bytecode interpreter for an adventure game engine (that would eventually make its way into ScummVM), so I felt I had enough experience to feel confident enough approaching PC emulation directly.
Fortunately, Rust was fairly easy to pick up from a background in C despite occasional frustrations with the borrow checker, and my initial guesses at emulator design turned out to be mostly feasible, if not always optimal. My initial implementation was purely instruction based, with no cycle-counts, and converting that to a cycle-accurate emulator was a bit of a challenge. More on that topic perhaps in a future article.
Background
I didn't grow up with an original IBM PC, but instead a popular clone, the Compaq Portable. It was a heavy beast, and was often described as a "luggable" system instead of "portable". With the keyboard affixed and the unit slid into its protective case, it could pass for a very large and unwieldy briefcase.
I spent many hours fascinated in front of the eerie glow of its green phosphor CRT. We had this machine for a long time, far past the point where it was grossly obsolete. I have fond memories of exploring the countless diskettes my father collected from PC User Group meetings and software I downloaded from BBS systems. It was this machine that spawned my love of computing, so a machine from this era that could run the same software seemed like a logical target. Nostalgia is a big motivator.
I chose the IBM PC, because it really was the first, and the fact that the BIOS source code for the IBM PC was available. IBM had published it in their Technical Reference for the machine, and others had performed OCR and cleanup on those source listings. This meant debugging the IBM PC's boot process was much easier than it otherwise would have been.
MartyPC is Born
Naming an emulator is notoriously difficult, and made more so by the popularity of a given platform. I'd hate to have to name an NES emulator at this point, given the hundreds of NES emulator projects out there in various stages of completion. PC is not anywhere near as popular a platform as the NES, but even so, we have emulators like DosBox, PCem, 86Box, PCBox, VirtualXT, PCE, UniPCEmu, PCjs and others. It felt like every permutation of "PC" and "86" had some sort of emulator attached to it.
Like many others with nostalgia for the IBM PC, I was entranced by the release of the PC demo 8088MPH:
This demo pushed the original IBM PC hardware well past its known limits, and rightfully blew quite a few minds in the process. At the time of it release, no emulator could really run it. I can't say I had any expectation of ever being able to run 8088MPH, but as an intangible, long-term goal it seemed an appropriate target. The End Boss of IBM PC emulation, so to speak. 8088MPH is chock full Back to the Future references, and so I thought I would name my emulator as a nod to this infamous demo. I picked the name Marty from the protagonist of the series, Marty McFly.
Sometime during development I discovered that there was a computer system called the FM Towns Marty, and I realized Googling "Marty Emulator" was never going to lead back to my project. Worse, I worried it would be considered rude to muddy the waters. I was fond of the name at that point, so I came up with a compromise, and now call the emulator MartyPC. I hope that the FM Towns emulation community doesn't come after me still. I have the alternate name "McFly" in my back pocket, just in case!
Last year, the developers of 8088MPH released a follow-up demo called Area 5150. Again this demo would do the impossible with the original IBM PC hardware, and won the demo competition Evoke 2022. Appearing in the middle of my development, it appeared that I had a new end goal already. Area 5150 broke every extant emulator again, even the popular and highly-accurate 86Box failed to run its end credits. An impressive effect that combined a water effect with a PCM sound player and text slideshow, the end credits of Area 5150 would turn out to require absolutely perfect cycle-accuracy.
At the time of its release, my emulator couldn't even display the introduction scene.
Almost exactly a year after I started development, in April of 2023, MartyPC could run the entire 8088MPH demo from start to finish with no major glitches.
A month later, it manages to run Area 5150 in its entirety:
Not to toot my own horn, but this was the first time Area 5150 had been emulated successfully from start to finish with no major glitches.
There are a few reasons I was able to succeed. One would be the development of many internal real-time debugging facilities, another was utilizing the technique of "hardware validation", a subject I intend to cover in a future blog article.
During development I have made very little attempt at making any optimizations, although there are surely many to make. Instead, I have focused on making my code clear to read and well commented. If you have a relatively fast PC you should have no issues running it, but it takes up more resources that you might expect to emulate a 40 year old computer. I plan to make some optimizations going forward. It will be interesting to see where I can save time while not sacrificing accuracy or clarity.
It would have been more useful to start a dev blog to document this process from the beginning, but as the saying goes: better late than never. I plan to document at least some of the more interesting efforts undertaken during its year-long development, and provide resources for future PC emulator developers. These articles may not be in the order that features were developed chronologically, but just written up as I find the time and motivation for a certain subject.
This is part 2 of a series on PC floppy copy protection methods. You can read Part 1, covering Formaster Copy-Lock here . Softguard Systems was founded by Joseph Diodati, Paul Sachse and Ken Williams in 1983 ¹ . The company went public in 1984, and by 1985 was one of the industry leaders in copy protection technology, although they produced a few other unrelated products as well. Advertisements for their copy-protection product, SUPERLoK, were commonly seen in the classified sections of publications such as InfoWorld and PC Magazine: The original Superlok product required professional disk duplication to lay down the requisite copy protection track. Eventually, Softguard would produce the "SUPERLoK KIT," which was writable with a standard PC floppy controller. An advertisement for the Kit can be seen above, left. The Kit version was aimed at smaller developers on a budget, and did not offer the same level of protection. This article will focus on the original ...
Preface This is Part 1 of a series of articles investigating various PC floppy protections, as I get them working in MartyPC . It assumes you have a familiarity with the structure of a PC floppy disk and the basic operation of a PC floppy drive. Thanks Thanks to NewRisingSun on VOGONS for his vast knowledge of copy-protection schemes and history, and to OBattler for his extensive knowledge of PC floppy controller operation. Formaster Corporation The Formaster corporation, headquartered in San Jose, CA, sold disk duplication equipment such as the FORMASTER Series One, pictured below. Courtesy of VintageComputing.com InfoWorld Sept. 19, 1983 Such machines may have been attractive investments for medium-sized software houses. Not only would it allow a software company to reproduce their own diskettes in bulk (up to 326 disks per hour, depending on options), the Formaster Series One could also add basic copy protection to each disk. The Series One started at $25,400US , or near...
In a previous article , I described a simple state machine to explain the prefetch behavior and miscellaneous observed bus delays of the Intel 8088. I now believe that the model I described there - although successful in modelling the 8088's behavior - was unnecessarily complex. There are in fact far fewer legitimate bus "delays", and they do not relate to internal state transitions. I have also slightly revised my description of the BIU's prefetching logic - I now believe that the prefetching decision happens at the end of T2, instead of the beginning of T3. There may not be much of a distinction between the end of one cycle and the beginning of the next, but it lines up better in our new diagrams. Introduction If you were interested enough to click on this article, you are probably already familiar with the 8088's bus cycle timings. A single bus cycle on the 8088 takes a minimum of 4 CPU cycles, consisting of 4 T-states numbered T1, T2, T3 and T4. Wait states (T...
Comments
Post a Comment