Engine Designs, Peter Tihanyi

It's been a while since I posted about the Ariel Virtual Computer project. A lot happened to it since then, and also, not so much. Unfortunately, I've fallen into the trap that keeps many projects getting from the prototyping stage (if there was one) to completion: Scope Creep. It's a technical term for including more and more features in a project, compared to the modest, down to earth initial design plan and things just get out of hand. I'm not completely lost though, but it's time for me to take a step back and make some level headed decisions about what's next.

The virtual machine (or emulator, same thing) that's running behind the scenes has been more or less done back then, I just fiddled around with it to cut out some unnecessary capabilities. This part of the project is surprisingly solid. If you'd like to look at some of the CPU details, I created a PDF file that I use as a cheat sheet while writing assembly code. Now it just needs single-precision floating point instructions, and I'll draw the line there. No support for double-precision. It's not the easiest decision though, the struggle is real.

Things started going south when I decided to create my own solution for text mode display. Initially the emulator was written as a console application and I could connect to it using a terminal emulator, telnet client etc to see its output. But this felt too limiting and what modern computer doesn't have some kind of display anyway...

Since the CPU handler itself is in a separate library, I started working on a new front-end. But what should it be? I chose Windows Forms on .NET 6.0 because why not try to get on with the times, right? Or should it be WPF? Or UWP? It doesn't help that pretty much every Windows Desktop development environment you can think of is in the following state: Is it dead? Yes. Well, no, not yet, but... There is a new thing on the horizon called Project Reunion. I mean WinUI. I mean Windows App SDK. They probably renamed it since I started writing this paragraph. In that a Hello World takes from 30 to 200 megabytes and uses either a handful or a hundred individual files, depending on the build settings you chose, and then it tends not to work at all. Thumbs up guys.

I made a bare minimum application that can display text in a Rich Textbox, but it had weird screen refresh problems and worse, I realized it physically can't use an image as background, nor can it use a transparent background. For that you need WPF or UWP. Fine, I'm not going to get scared away by this, I want that background image so much that I wrote my own bitmap-based character matrix rendering control. It's beautiful and works really nicely... Unless the control is too big. Like it's in full screen on a 4K display. The update becomes just laggy. The problem isn't with the bitmap creation or font rendering itself, it doesn't have excessive CPU usage, it's just getting mangled somewhere in the bowels of Windows that's not under my control.

I tried to go between .NET 6 and .NET 4.8, thinking the issue is with the new framework, but they are equally bad. I optimized the heck out of it, it's much better than it would be by default but still not good enough. To add insult to injury, if I compile the application in x86 mode then it's fine in most cases, but in x86-64 mode the screen update gets even worse. That was a great time to figure that out, given that debugging an application in Visual Studio is still best to do in x86 mode, so the problem was always in the Release version. I also had problems with setting up a steady timer that can handle a 60 FPS update for generating Vertical Blank interrupts and deal with the screen refresh, but I solved that issue.

Right now, I feel like I wasted a lot of time with this whole text display solution. I should just make it work with a Rich Textbox control and live with a single background color.

It also doesn't help that I can't decide about a fixed character matrix size. I have various old computers and displays with different resolutions that I'd like to potentially run it on. Will it be my old Apple Cinema Display with a mechanical keyboard? Or this Dell 27" 4K display when I replace it? Or my old 13" Surface Book? Setting the matrix width to 120 and the height to something more flexible is a good solution and it's all configurable in the settings, and the programs can read the matrix size from hardware registers. Of course, it would be so much better to have a fixed size, it would work in windowed mode just fine, but I would like it to look pretty in full screen mode, where I can pretend that my hardware is running my own operating system.

Oh, about the OS... I decided on an MS-DOS style OS that uses a Linux Bash-like shell with flexible display size, but can't do multitasking. It will just load the selected application, run it, the app can call OS Kernel functions to handle the screen, input, storage and other OS-level things without touching the hardware registers. When it's done, the program gives the control back to the shell. I made the system load a ROM image, start it up, and it loads the OS Kernel and executes it. You can type in the shell, so far so good. It does not load and execute programs yet, but I'm working on Kernel functions that programs can call.

Should I add graphics mode? It would be nice, but then I have the same problem as with the character matrix size, what will it use? 1920 x 1080 would be ideal for showing it off on YouTube, but what about all the other weird resolutions and aspect ratio my displays use? I think for the time being I will not add any graphics mode, and will see it way later whether I need it. And what about sound? Of course, I would love to write scene demos for it, but is it worth the hassle? Not really...

Mostly I want this to be a playground for making compilers and other nerdy tools that only need text display mode. At least this is a good, solid pointer that can guide my decision making about the system itself.

Take my advice, make a reasonable plan for your project and stick to it. You can always add more features to it later.