Everything started a few years ago, when I discovered that I could program in C on 8-bit computers, specifically the Commodore 64.

It had always been my dream to be able to do it, so I started writing some games with this language, and a library of common used functions. Since the C language is by its nature portable, I started to create a library that would allow the same game to run on different computers, i.e. on MSX or ZX Spectrum.

Here I ran into a number of limitations of modern languages when used on 8-bit systems. Wanting to create something portable but, at the same time, efficient, I invented a new programming paradigm that I called "isomorphism". I introduced this paradigm on this 8-bit C library, and then I used it as the founding pillar of ugBASIC.

In a nutshell, "isomorphism" means the attempt to match one part of one computer to the counterpart part of another computer in the "best way", and for every supported hardware combination. Hence the term that, in mathematics, is a one-to-one correspondence between two sets.

The goal is to have software written for one computer that can run (with minimal modifications) on others, and with minimal loss of performance. This is done basically by not introducing unnecessary abstractions.

To give a concrete example: all computers allow you to print a character on the screen. The way they do this, however, varies from computer to computer. The classic solution is to "abstract" the concept of screen, assume that it behaves identically everywhere, and then implement it the same everywhere. The isomorphic approach, on the other hand, recognizes that functionality could exist in every target but it is probably differently implemented in every one. Or it might not even exist, and there might be no point in implementing it.

Another concrete example, this time the opposite. All modern languages rely on there being a stack to maintain local variables. In reality, almost all 8-bit processors do not have efficient stacks. So this abstraction is no good. For this reason, isomorphism implements a stackless approach. All memory is statically allocated. In C this was done by using global variables.

In conclusion: the language will provide the programmer with the conceptual functionality, letting each target implement it as best as possible. I emphasize here that I used the word "language", and not library. The reason I abandoned C was because with the C library, once the isomorphic approach was implemented, you no longer programmed in C. In practice there was no longer a distinction between "library" and "language". So it had no sense to continue to use C.

Having to choose a language, I chose BASIC. For two reasons. The first is that it was the language of choice for almost all home computers of the time, which makes it very common and it allows the same algorithms to be used. The second is that it is a language that makes no distinctions between "syntax" and "libraries", and is therefore ideal for isomorphism.

To date, ugBASIC generates executables for around twenty targets. When I say "target" I don't simply mean that ugBASIC produces something for it, but I can say that a program also runs on that target.

Obviously, being an isomorphic language without abstractions, it is not guaranteed that the result will be the same and the goal is not to make it run badly just to make it run.

For example, if a target has no bitmap graphics because it only has text modes, ugBASIC provides no abstractions to solve the problem. At the same time, however, it can offer very interesting alternatives. For example, on the VIC-20 it can reprogram characters to mimic the availability of images, but obviously this is not available on bitmap only targets.

By taking this approach, you will find that writing cross target sources in ugBASIC is feasible, and it depends on isomorphism. And, if you are not interested in portability, the language will be able to provide satisfaction for the specific target you choose.

Thank you for reading, and happy retrocoding!