As you may have seen, in the comment section of my previous two articles, a somewhat confused individual has left a number of rather lengthy comments. I had already encountered this individual in the comments section of some YouTube videos (also with an Amiga/oldskool/retro theme), and had already more or less given up on having a serious conversation with this person. It is apparent that this person views things from an entirely different perspective, and is not capable of being open to other perspectives, making any kind of conversation impossible, because you simply hit the brick wall of their preconceptions at every turn.
Having said that, it did trigger me to reflect on my own perspective, and as such it may be interesting to formalize what retro/oldskool programming is.
Perhaps it’s good to first discuss the wider concept of ‘retro computing’. A dictionary definition of the term ‘retro’ is:
imitative of a style or fashion from the recent past.
This can be interpreted in multiple ways. If we are talking about the computers themselves, the hardware, then there is a class of ‘retro computing’ that imitates machines from the 70s and 80s, that ‘8-bit’ feeling. Examples are the PICO-8 Fantasy Console or the Colour Maximite. These machines did not actually exist back then, but try to capture the style and fashion of machines from that era.
A related class is that of for example the THEC64 Mini and THEA500 Mini. While these are also not exact copies of hardware from the era, they are actually made to be fully compatible with the software from the actual machines. They are basically emulators, in hardware form. Speaking of emulators, of course most machines from the 70s and 80s have been emulated in software, and I already shared my thoughts on this earlier.
Also related to that are peripherals made for older machines, such as the DreamBlaster S2P. These are not necessarily built with components that were available in the 70s and 80s, but they can be used with computers from that era.
In terms of hardware, my interests are focused on actual machines from the 70s and 80s. So actual ‘classic’ hardware, not ‘retro’ hardware; the PICO-8 and Colour Maximite fall outside the scope. I mostly focus on IBM PCs and compatibles, Commodore 64 and Amiga, as I grew up with these machines, and have years of hands-on experience with them.
My interests in emulation are in function of this: I may sometimes use emulation for convenience when developing, reverse-engineering and such. And I may sometimes modify emulators to fix bugs or add new features. I may also sometimes use some ‘retro’ peripherals that make the job easier, or are more readily available than actual ‘classic’ peripherals. Such as the DreamBlaster S2P, or an LCD monitor for example.
My blog is mainly about developing software, and the only software you can develop is new software, so in that sense it is always ‘retro programming’: new software, but targeting machines from a specific bygone era.
There are also people who discuss actual software from the past, more from a user perspective. That can be interesting in and of itself, but that is not for me. I do occasionally discuss software from the past, and sometimes reverse-engineer it a bit, to study its internals and explain what it is doing. But usually the goal of this is to obtain knowledge that can be used for writing new software for that class of hardware.
Anyway, I believe I already said it before, when I started my ‘keeping it real‘ series: I went back to programming old computers because they pose very different programming challenges to modern machines. It’s interesting to think about programming differently from your daily work. Also, it’s interesting that these machines are ‘fixed targets’. A Commodore 64 is always a Commodore 64. It will never be faster, have more capabilities, or anything. It is what it is, and everyone knows what it can and cannot do. So it is interesting to take these fixed limitations and work within them, trying to push the machine as far as it can go.
Why the comments are barking up the wrong tree
Getting back to the comments on the previous articles, this person kept arguing about the capabilities of certain hardware, or lack thereof, and made all sorts of comparisons with other hardware. Within the perspective explained above, it should be obvious why this is irrelevant.
Since I consider the machine I develop for a ‘fixed target’, it is not relevant how good or bad it is. It’s the playground I chose, so these are the rules of the game that I have to work with. And the game is to try and push the machine as far as possible within these rules.
The machines I pick also tend to be fairly common off-the-shelf configurations. Machines exactly as how most people remember them. Machines as people bought and used them, and how software from the era targeted them.
Yes, there may have been esoteric hardware upgrades and such available, which may have made the machines better. But that is irrelevant, as I don’t have these, and do not intend to use them. I prefer the ‘stock’ machines as much as possible.
So I am not all that interested in endless arguments about what hardware was better. I am much more interested in what you can make certain hardware do, no matter how good or bad it may be.
Related to that, as I said, I like to use machines in configurations as how most people remember them. This person kept referencing very high-end and expensive hardware, and then made comparisons to the Amiga, which was in an entirely different price class. I mean, sure, you could assume a limitless budget, and create some kind of theoretical machine on paper, which at a given point in history combined the most advanced and powerful hardware available on the market. But that wouldn’t be a realistic target for what I do: retro programming.
I like to write code that actually works on real machines that most people either still have from when they were young, or which they can buy second-hand easily, because there’s a large supply of these machines at reasonable prices. And in many cases, the code will also work in emulators. If not, then the emulators need to be patched. I will not write my code around shortcomings of compilers. Real hardware will always be the litmus test.