glgorman
If you haven't noticed by now, at some point in time, I managed to successfully remove an AMD Duron chip that is, I think, at least 25 years old, if not older, from whatever long since dead PC that it was associated with. Not only that, I successfully managed to unsolder the original ZIF socket from the now completely bricked motherboard, by a time-honored method that I will not otherwise describe in too much detail in these parts. Yet, having come to the realization that turning a possibly still functional legacy CPU into an interesting paperweight is a perfectly valid form of abuse, I therefore decided to start this project. Which, for now, does absolutely nothing, except sit there and look nice.
Then again, even if it doesn't quite play doom, so what? The PC that it came from was clearly doomed for other reasons, so why not have some fun? Obviously, there is something weird and wonderful about this particular vintage of CPU, so who knows, maybe someday, a new hardware project might actually get built based on the design principles that otherwise should seem so evident, even if they are not. Like, what if we could somehow build a Parallax Propeller P2-based PC, or maybe create something ESP32-based, or "whatever", and just somehow put it on a circuit board that might not cost all that much to have made, in this day and age, so that it can, in turn, be plugged into an existing legacy PC.
Just because. For the same reason that some people climb Everest, or any other mountain, for that matter. Because it is there. And because it might actually be possible to do.
Yet, as far as finding other ways to run DOOM on alternative hardware is concerned, all hope is not lost. At some point, once upon a long time ago, I took a DOOM distribution, I think of the original DOOM, and went to work at trying to see how hard it would be to get DOOM running as a Microsoft Foundation Class library C++ application, i.e., in Visual Studio 2005, no less. And even if I never quite got that to work, I did make considerable progress, wherever that was, in some other timeline.
I mean, at least I got most of the DOOM codebase to compile, not as an application, but as a library, which I suppose, could also possibly be compiled as a DLL, or maybe as an Active-X control. Or maybe I should try using some modern AI-based tools to rewrite all of this in TypeScript. I did have some issues with some of the files that were giving me some trouble, of course, so I put those into a separate project, at least for the time being. Thus, i_sound, I_system and I_video remain non-functional in this build.
Yet, really, the 115 or so errors that are preventing this project from compiling doesn't really seem like that big of a deal. I just need some compatibility code that deals with the requirements for some non-Windows API's like just why it is that I am getting errors like "XPending : cannot convert parameter 1 from XWIN::Display to 'Display" and so on. So let's take a closer look at the real world of application building, and what I had to work with while trying to build my entry for a previous contest, i.e. the One Hertz challenge. Thus staring from a workspace that actually included something like 14 separate projects, I was able to jump right in, locked and loaded with the ability to interact with a COM port that was in turn connected via USB to a GPS module, right from the get go.
And that meant, of course, that creating a working One Hertz application was almost already in the bag, allowing me to focus on the intricacies of the methods of Euclid, and Ptolemy, for that matter.
And that is because, as some people might say, a design isn't perfect when this is nothing left that needs to be added, rather a design is perfect when there is nothing left that can't be removed. That is to say, as we go from this:
