Try8085 is an integrated development environment and a simulator of the Intel 8085 microprocessor. I developed it in 2009 in collaboration with my fellow students Daniil Zapyatoy and Ilya Beda during my third year at ISIT. The project was supervised by docent Oleg A. Ikonnikov (Ph.D.), who’d later employ it to teach undergraduate students the 8085 assembly language. About six months ago, I revitalized this old codebase and released it under the GPLv3 license. I was driven by a mixture of nostalgia and curiosity, but, to my surprise, I found great peace of mind reconnecting with this artifact of my past. Now, I’d like to share some thoughts on Try8085 and the lessons of legacy software in general.

First, let me take a step back. At age 16, I was building a game mod for Morrowind — my then-favorite video game. I started a dedicated thread on a Russian Morrowind-themed forum where I’d post occasional updates, alpha builds, and various teasers, ranging from screenshots of scarcely furnished interiors to in-game book drafts (hinting at the hopelessly banal backstory). As it happens with most hobby projects, eventually I lost interest and almost forgot about ever doing it. Until the last summer, when a random tweet by Marco Arment about his ancient Total Annihilation mods reminded me about this past endeavor. I tried to find my old mod, too. But it was gone.

Frustrated, I spent hours digging through the Internet Archive. I discovered traces of the thread, but none of the files or messages. We like to joke that nothing ever disappears from the web. Well, it still does. Ultimately, I moved on, but this episode kept gnawing on my consciousness. Over the years I’ve lost and deliberately got rid of gigabytes of code and other work. Still, some projects are more important than others, and that one was important. In a way, it motivated me to apply to ISIT and pick software development as a career. I learned my lesson: don’t neglect things you’re not ready to let go. This realization was enough to turn my attention to another formative project of my career: Try8085.

Whereas the Morrowind mod was a labor of love, Try8085 started as a ploy to shirk a dull task. I had to pick a semester project for the “Computer Hardware” course, which would involve designing a massive circuit board in a buggy CAD software — something I had no interest in at a time. I knew that, a year earlier, Ilya and two other senior students had managed to change their assignment to porting the old Intel 8085 simulator for MS-DOS to Windows. Daniil and I had already had a chance to use the resulting software in class, and it was unbearably buggy. So, the two of us spoke to the teacher and suggested that our semester project would be fixing bugs in the simulator and developing several additional simulated connected devices for its platform. To our delight, the teacher welcomed the idea.

At least two months of procrastination ensued. Then, in late March, things began to escalate rapidly. We found out that the source codes of the simulator were lost. Somehow, each party assumed that everybody else kept a copy, so nobody cared to save one for themselves. The teacher gave us a choice between going back to the standard “boring circuit” project (there was still enough time to complete it) or proceeding with the simulator idea on our risk. For some reason, the prospect of having to build a complex application from scratch still seemed more appealing than the alternative. Our enthusiasm was further fueled by Ilya discovering the source codes of an older version of the program on his backup drive. The recovered version consisted of a VM mostly capable of running the 8085 bytecode and reams of bug-ridden GUI code for C++ Builder (the release version of the program used a different GUI framework). Thus, we needed to “just”:

1. Implement a translator of the 8085 assembly language.
2. Write a disassembler of the 8085 bytecode.
3. Build a graphical IDE with a built-in debugger.
4. Implement four simulated external devices: digital display, keyboard, ADC/DAC, and a block of eight 7-segment indicators.
5. Write extensive documentation required by the teacher.

All of that we had to complete within less than two months before the deadline, while still taking a dozen of other courses and studying for the approaching summer exams. Both Daniil and I also had a part-time job, which didn’t help either. Even now, I still don’t fully understand how we made it work, but I can name three things that, I think, contributed the most to the successful completion of the project.

Reference implementation. For the most part, we were replicating the existing program. There were a handful of things that we disliked about the original version, and those got changed. Yet, the majority of the grunt work was re-implementing the known functionality.

Pragmatic choice of tools. I’d had some experience using Qt for hobby projects, which made it a natural choice for Try8085. The productive power of Qt is in its vast, explorable API, quality documentation, and the Qt Creator IDE. Being a Linux user, I was also grateful for not having to leave the familiar environment, even though the resulting program would have to run on Windows.

Cheating mindset. It seems illogical now, but, even after finding out about the missing source codes, Daniil and I still thought we were somehow “cheating the system.” This attitude had a curious effect on our decision-making process. The effect I’d like to talk about in better detail.

We weren’t going to do anything that wasn’t critical to getting the job done. For example, the recovered source codes contained a several thousand lines long implementation of the 8085 assembly translator written in C. It was broken, too, which meant we’d have to understand the implementation, hopefully, fix the bugs, and, in the end, still deal with the lack of Unicode support. Instead, we replaced this lump of code with regular expressions (provided by Qt) and a known-to-work function, translating the parsed 8085 commands to their corresponding byte codes. The latter function we “borrowed” from the GNUSim8085, which at a time we deemed “cheating,” but in retrospect, it seems more like “leveraging the power of open source.” Sridhar Ratnakumar, the original author of GNUSim8085, is now listed among the contributors to Try8085.

Unbeknown to me, Onkar Shinde & Aanjhan resumed the development of GNUSim8085 in September 2016 – the month I pushed the GPL-released version of Try8085 to GitHub. I guess, there was something in the air.

In an essay titled “Holding A Program In One’s Head,” Paul Graham argues that a programmer is productive the most when he or she manages to internalize the entire codebase. He lists eight things that might help one achieve that state, and adds: “It’s striking how often programmers manage to hit all eight points by accident.” Mihaly Csikszentmihalyi, the father of the flow theory, also has a relevant quote:

Enjoyment appears at the boundary between boredom and anxiety, when the challenges are just balanced with the person’s capacity to act.

This description of enjoyment produced by flow experiences deeply resonated with me, when reading his 1990’s “Flow: The Psychology of Optimal Experience” (also, “the boundary between boredom and anxiety“ might be the perfect description of my mental state throughout the college). Working on Try8085, we managed to hit just the right balance between the external stress and internal doggedness. I focused entirely on the code, Daniil was doing QA and writing the docs. We’d often come to my place after the morning lectures, and work in one continuous stretch until late night. Then Daniil would leave to catch the last bus home, and I’d proceed with refactoring and bug fixing on my own, sometimes going to bed at 5 a.m., sometimes skipping sleep altogether. Later, we brought Ilya on board to help us fix shared memory issues on Linux and implement multi-threading for certain GUI actions. Unlikely as it seems, everything somehow converged on the night before the deadline. The resulting build was stable enough to be used for teaching the next year students the 8085 assembly language.

Ever since we concluded the project, Ilya’s been nudging me to release the simulator into open source. I’d take a stab at it once every few years, but there was an unfortunate regression in the newer versions of Qt 4 that made the grid view UI component unusable with lots of rows. This was a problem because we were unfortunate to employ it to display the entire 64KB of memory available to the simulated microprocessor. Finally, in August, I decided to dedicate a few hours just to get the project running on Qt 5. The migration process was a breeze, which reminded me of the benefits of static typing in the long run. Guided by the compiler, I changed a few things here and there, and the program launched. It felt almost surreal seeing that interface again. I opened an example file, and a block of 7-segment indicators appeared on the screen, displaying the number 42. The problematic hex viewer showed no signs of performance problems.

Consequently, I spent a few weekends tidying up the code, putting the application resources in order, and tuning the build pipeline. To my surprise, the codebase wasn’t too much of a mess. While there were some hairy parts, particularly in the translator and the VM, the project had an organized, modular structure. Partly, it’s thanks to Qt, but mostly because we made an effort to keep things organized. A nice reminder that high-level architectural decisions are more important than a concrete implementation of any particular module.

All in all, Try8085 is not an example of mindful software engineering, but it illustrates what can be achieved in a very short term when you work hard and focus on the right things. This is the lesson that I want to carry forward with me, and the reason why I still care about the project so many years later. Most software is evanescent, but there’s a case to be made about the value of preserving our professional legacy. I know I’m not alone in this. Jonathan Blow, the creator of video games Braid and The Witness, wrote about Braid: “I want to maintain this game indefinitely into the future.” Basecamp is another company that promises to support the older versions of their apps unchanged “until the end of the Internet.” While these are examples of software used by millions of people, it shouldn’t stop individual developers from caring about what’s important for them. After all, there are museums, and there are family photo albums. Both have their place in reconnecting us with our past.