Continuum 93, an assembly machine emulator that... does not have a hardware

[EnthusiastGuy]

Hey guys!


Last year I started investing quite a lot of my 90's retro computing nostalgia into writing this fantasy emulator of a retro machine that really didn't exist (though all my childhood I wished it would) designed mainly for retro game development with a dedicated (albeit a bit simplified) assembly programming language I also designed inspired by a lot of CPU's of that era such as the Z80, Amiga and others.

I am really happy to present to you this month's update of Continuum 93 which now also features a realtime debugger/disassembler as well as a dedicated simple OS written in this machine's assembly, some example programs and offcourse, updated manuals and technical references.

This project is currently only for PC/Windows, however, it will make its way onto other platforms soon enough.

While this project was initially released in march or so this year, given I am now more confortable with how stable this is, I now decided to look around for communities that might share interest in this and found you guys, so there I am, daring to share with you my latest update on my project. Feel free to share any feedback or critique (I'm not a daisy, hit me) you may have. It will be put to good use!  :)

So, without further ado, here are the main features added to this month's 0.3.7 update:
Video introduction and demo here: https://youtu.be/11kUXbjUK6M

- A very much improved debugger;



- A new OS for Continuum written directly in the assembly language of this machine;



- A new way of programming with VS Code and the code can be split over different files;




You can download it for free on this project's itch page here.
While appreciated, donating is very much optional, so just pull the slider all the way to zero and download Continuum.


Cheers!

[Gilbert]

Hi.

Fantasy computers are quite interesting, and one that has an assembly language set should be fun too.
The other fantasy computer systems I have tried usually only support higher level scripting languages (such as Lua or Python), and you usually need to pay for them for full use (at least I managed to download the whole Continuum 93 package without paying anything naming a price ).

Like emulators for existing consoles, we can develop or play stuff for a closed system with well-defined limitations (unlike on programmes on modern computers which may break due to compatibility issues with different configurations), and the good thing with fantasy computers is that we usually don't need to deal with quirks on existing systems due to hardware (e.g. you cannot write to video memory at certain time in a real console).

For a better introduction, I think you may also include the links for your website and the itch page. They are accessible from the Youtube link, but I think it wouldn't hurt you you add their direct links to your post.

[EnthusiastGuy]

Hi Gilbert, thanks for your feedback!

... Fantasy computers are quite interesting, and one that has an assembly language set should be fun too.
The other fantasy computer systems I have tried usually only support higher level scripting languages (such as Lua or Python), and you usually need to pay for them for full use (at least I managed to download the whole Continuum 93 package without paying anything naming a price ). ...

Yes, I also know one commercial fantasy console that uses Lua. When I started developing Continuum I had no idea of this "genere" of "fantasy consoles". A friend of mine that got wind of what I'm doing did the research that I was probably supposed to do in the first place and pointed me to what's been done already. Thankfully, the essence and architecture of Continuum is still rather unique so I was not discouraged to continue developing it.

Assembly programming is really not that bad once you get the basics of it. And, in truth, I have simplified a bit the experience you'd have with it. Someone once said to me, it's good to have challenges, but while I want those challenges to exist in a generic platform level, I don't want the developer frustrated on obfuscated CPU timings that don't immediately make it clear how to code a specific subroutine or anything like that.

... Like emulators for existing consoles, we can develop or play stuff for a closed system with well-defined limitations (unlike on programmes on modern computers which may break due to compatibility issues with different configurations), and the good thing with fantasy computers is that we usually don't need to deal with quirks on existing systems due to hardware (e.g. you cannot write to video memory at certain time in a real console). ...

That's one of the core values that I planned for Continuum. Eventually, I want to have this ported to other platforms, including (if not "especially") most single board computers. One of the visions I have is to enable the user the ability to construct easily a physical keyboard where they'd stuck one of these SBC's and turn it into an actual retro console, fully compatible with whatever you see now on PC.
That will be a journey, we'll see how it goes.

For a better introduction, I think you may also include the links for your website and the itch page. They are accessible from the Youtube link, but I think it wouldn't hurt you you add their direct links to your post.

Yep, thanks for this. Updated my post just now. Have no idea why this didn't occur to me in the first place.

[segaloco]

So this "fantasy" approach as you call it is used in Don Knuth's "The Art of Computer Programming" quite successfully. Throughout the works, Don presents a hypothetical CPU architecture that models pretty well the basics of low-level compute devices but without adhering too closely to any given implementation. As such, he is able to communicate a wide array of pretty involved computing topics essentially in assembly language without needing to rely on any given vendor's stuff, a boon for those looking to understand algorithm design at the individual operation level.

Something I've been considering that is a bit of a middle of the road approach is designing a console based on existing architectures and ICs, but such components that haven't before been clobbered together in such a way. More precisely, I want to see what it'd take to produce a "console" that is entirely Western Electric, using the WE32000 CPU architecture and various WECo DSPs for the graphics/audio handling, essentially producing an embedded platform wholly made from telecom compute devices.

Also I second that idea of this eventually being able to be embedded on a SBC and boxed with say a keyboard or something. For anything that isn't trying to be the next AAA console, this is probably the way to go if considering an actual scaled production run, because the concern of the operating logic itself could be easily provided by a simple SoC and then the machine itself could essentially run as an RTOS. In some senses, just giving the emulator you're providing somewhat of an operating system kernel, just a kernel in which the entry interfaces are based on binary opcodes rather than making a native jump and just pushing native arguments to the stack.

[EnthusiastGuy]

Don Knuth's "The Art of Computer Programming" successfully employs a hypothetical CPU architecture to explain low-level computing concepts without tying to specific implementations.

A middle-ground approach involves designing a console using existing components in novel ways, like using Western Electric's WE32000 CPU and DSPs for graphics and audio.

This concept could be embedded in a Single Board Computer (SBC) for scaled production, simplifying the operating logic with an RTOS-like setup. The emulator would serve as an OS kernel using binary opcodes for entry interfaces.

I am not familiar with the book you mention, but I find it a very nice idea to use an abstract set of instructions (pretty much like pseudocode) to ilustrate architecture-agnostic implementations. It reminds me of one of the assembly programming books I read many years ago where the author used an actual diagram of the CPU/registers/RAM to explain step-by-step what is going on with each instruction. Offcourse, that was based on a real CPU, but nonetheless, the visual of that was very clear.

I 'think' I also visited that middle of the road at some point, or at least a variation of. That was well before Continuum 93 was even a concept in my mind. I was playing around with some microcontrollers, namely ESP8266, ESP32 and some compact versions of, along with others. I wanted to be able to poke their memory and get how I could "take ownership" with a minimal OS I could natively write in (or something) so I could make a retro machine there, by using their proprietary assembly architecture. I could then connect two or three microcontrollers, one would act as a video board, the other as a sound board, and I could use a modular approach in my software to create an interesting, "native" retro computer.
It turned out to be quite a challenge, even with all the documentation at hand. I got how the memory fragmentation was designed, what steps to do for various tasks, but there were some quirks I didn't got around of. Still haven't given up the idea of doing so, but after a month of exploration, I chose to park it and think of other ways.

So, a while after that (a year ago), I layed down the first concept of Continuum 93 and started working on it. I pretty much had the same idea, make it a native thing on some single board computers, but start from an existing kernel. It sounded simple in my mind, so I even tried to contract someone to write some... bootstrap platform where I could deploy this emulator that would take over the machine and act as the omni commander of all.

Then, a seasoned programmer, versed in linux (unlike me) explained to me what that entails. It wasn't impossible. Just very expensive and time consuming.

So, as practical as I could get, I first wrote this for Windows, as it is today. And I established a strategy to run it also as an application on some existing linux distributions, including (or starting with) the Raspberry Pi series.

On such sistems, this emulator could (in some future) also provide an interesting way of accessing pins and that could be nice for some projects/games/custom hardware/prototyping and others.

I mean, who doesn't like (?):

Code: Select all

LD A, 4 ; some analogue pin
LD B, 5	; some other analogue pin
OUT A, 128	; Set analogue pin (0 - 1023)
IN EF, B	; Get (0 - 1023) from pin into register EF

But, yeah, that's for the future.

As for today, now, I am happy to say that the last few days I was able to deploy the Continuum Emulator (as an application) onto Raspberry Pi models: 2 A+, B, 3, 4, Zero 2W. And that on Raspberry Pi OS (aarch64 architecture) and RetroPie (armv71 architecture).

So, one step closer, I guess.

[segaloco]

So, a while after that (a year ago), I layed down the first concept of Continuum 93 and started working on it. I pretty much had the same idea, make it a native thing on some single board computers, but start from an existing kernel. It sounded simple in my mind, so I even tried to contract someone to write some... bootstrap platform where I could deploy this emulator that would take over the machine and act as the omni commander of all.

Then, a seasoned programmer, versed in linux (unlike me) explained to me what that entails. It wasn't impossible. Just very expensive and time consuming.

What you're describing there is somewhat like a hypervisor running a single client, a JIT interpreter of an intermediate bytecode. Look into the Inferno operating system from Bell Labs. That was an attempt at an OS centralized on the concept of a JIT bytecode machine. At the time the idea is it would be somewhat like Java, a virtual machine that runs on some sort of host and reads its own bytecode format. However, the Bell labs folks intended to go a step further and produce it as a formal OS, you could run an Inferno VM on another OS or as a completely standalone supervisor.

There may also be something in Singularity, an OS experiment by Microsoft, that would help here. It's a "managed mode" operating system, dunno if that means it's overwhelmingly running on .NET IL or if it's still pretty heavily reliant on the machine architecture throughout, but any info published on that may help.

Also, check out https://www.tuhs.org, they've got source codes to a wide array of UNIX versions. While UNIX is a monolithic bare metal kernel, it could offer some design ideas regarding process swapping and all that. The contents of clock.c and slp.c in the main kernel source are particularly salient to the subject, as that is where the clock interrupt handler and scheduler routines live respectively. This is old stuff, but also as a result is much simpler than say trying to get a birds eye view of the process system in the Linux kernel. There's even a very detailed commentary on the V6 kernel from John Lions of the University of NSW in Australia. Heck I recommend that book to any programmer, it's to this day one of the best expositions of a complex, systemic software application I've ever seen.

Finally, on the more cutting edge end of the spectrum, microkernel architecture may provide some ways to minimize the amount of low-level work you need to do. Take a look at seL4, that's one of the current microkernels that seems to be getting some attention. Another, more pedagogical example would be MINIX, although that is also a tad bit dated, but it does have an accompanying text book that is also an excellent description of OS theory and implementation.

Feel free to PM if you'd like some more info, I've built a few toy kernels for RISC-V and do other little OS etudes from time to time, so would gladly play sounding board or spitball ideas.

[EnthusiastGuy]

...
Microsoft's Singularity, a "managed mode" OS experiment, may offer insights. It's not clear if it's heavily reliant on .NET IL or machine architecture.

Check out https://www.tuhs.org for UNIX source codes. It's monolithic, but clock.c and slp.c in the kernel source could inspire process swapping ideas. John Lions' book on the V6 kernel is also valuable.

For modern options, consider microkernels like seL4 and pedagogical examples like MINIX. They can simplify low-level implementation work.
...

Thank you for all of this!


This was actually very informative. I do find a lot of familiar ideas and concepts in Inferno OS. I too plan to have Continuum support multiple languages that would compile to Continuum's assembly from (for example) a variation of BASIC I have designed (on paper) both in realtime but it could also produce assembly bytecode, but I also dared dreaming of a compiler at least for C. Not sure I can pull off C++ on my own. But that's not a priority now, to be honest. I also liked the philosophy of abstracting processes and resources to files.

I am yet to deep dive into the barebones of the Unix Heritage Society archives for, as you called it: a bird's eye view, but in all honesty what really attracted my interest was indeed seL4. I see it also comes with quite a few useful components. I would need the USB, keyboard and network. Haven't found a mouse yet, but that's less important. I do think that is what I am really looking for and you could not have found a better moment to show that to me.

I like what they provide, the licensing is tailored not to force you into anything, so I am definitely looking into it now.
If not that, I will look for alternatives since now I am aware of the "microkernel" term. But this looks really promising.


Again, thank you kindly, and I will most certainly take you up on your offer to bug you once in a while with a question or two.

[segaloco]

Fantastic, I love hooking folks up with the knowledge they're seeking. OS theory has been a near and dear subject to my heart for years. I've long thought of video games for embedded platforms as their own little operating systems, they're just abstracting signals from peripherals into distinct actions on the silicon. You also in that scenario have to deal with interrupts, servicing user input, scheduling execution of arbitrary objects in a table, memory management, etc. Your goal is just more specific, rather than providing a general computing environment, you're providing a "guided" computing environment with narrow scope and subsystems.

If you get into reading any of the UNIX stuff, there are three companion books to the source depending on the era you're studying. If you find yourself looking at anything V4-V6, those kernels are best served by the Lions commentary. If you start looking at V7 branching towards the BSD line, there's a line of books starting at 4.3BSD and continuing into FreeBSD concerning the design and implementation, Kirk McKusick is the primary author on that one. If you veer more the commercial line towards System V, Maurice Bach with Bell Labs wrote up a nice book on SVR2. Around the margins there is also an early study on UNIX concerning the V1-V2 era, but I don't recommend it as much as it is *very* old and the system wasn't written in C at the time, so you gotta know PDP-11 asm pretty well. On the other end of the margin there is a more modern take on Solaris by Sun, one of the more successful System V derivatives, but I don't know the quality of that book, I've only skimmed bits of it at the local university.

Finally just because it deserves honorable mention and underlies literally all of this, there is The Multics System by Organick. Multics is the project that UNIX was inspired by and overtook. The book written on its kernel I think is the first book written about the design and implementation of a real OS kernel, earlier works had described more the managerial landscape of OS design (see Fred Brooks Mythical Man Month)

If you can't guess already, I'm a literature evangelist, there is such a wealth of good books out there which have been educating programmers for decades. Honestly I'm a teensy bit surprised you haven't heard of Knuth, The Art of Computer Programming is often cited as one of the greatest works of computing technical literature. As an aside, Don Knuth is also behind TeX, the typesetting system used widely in open source documentation these days. I'm still a TROFF purist but I did recently find a copy of the TeXbook in the recycling at the university so I'm starting to familiarize myself with it.

Best of luck with everything, it's always exciting to see people working on general purpose operating systems. The field has kinda atrophied a bit, but there are cool things going on out there like seL4 and Redox as well. The latter is a UNIX-like written almost entirely in Rust. I hope it manages to get bigger some day, I'd love to give an all-Rust system a whirl.

[tepples]

Now that Chromium-based browsers have (finally) started to support a subset of MathML since January 2003, TeX is good to know even if only as an input method to produce MathML. I learned about this from the gbadev community's ongoing refresh of Cearn's Tonc tutorial.

[aa-dav]

...

Very interesting ISA!
And I have several of questions about it.

First of all: 26 GPRs seem alphabet-induced limitation. Encoding seems to support up to 32 8-bit GPRS. Is it really about letters, or there are some other considerations like placing 6 bytes of SPR/SPC into register pages during register set changes?

Second: I didn't find where register sets are saved during REGS execution instruction. Maybe they are memory-mapped? Or they reside inside CPU?

Third: there are no details about instructions with lower bit size of second argument. Like "ADD AB, C". Second argument could be zero-extended or sign-extended and it's important to understand (and, probably, to have option to choose).

Also I don't see "arithmetics with carry" like ADC on Z80. I understand that there is almost no need in it with ISA supporting up to 32 bit arithmetics, but it is common to have such instructions even in modern ISAs. The only one which is missing it is MIPS (IIRC).

Anyway, it was fun to learn about your ISA! I have the same hobby as you viewtopic.php?t=21868 and did my virtual PC with vitrual ISA too. It's more like PDP-11, however and strictly 16-bit.

[Gilbert]

I've thought of the 26-byte register limit too, but I think it all came down to the convenience of the coders.
One powerful aspect of the register system is the "circular looping" feature, so if say, if there are 32 bytes in a register set, you need more symbols other that the 26 capital letters, say, if we use lowercase letters afterwards:
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdef
Then, if we want to use a 3-byte register that starts with d, it would become deA, which is a lot less intuitive (and easily to make mistakes) than having exactly 26 bytes, so you can have YZA, YAB, etc.

Alternatively, if we limit them to 16 bytes:
ABCDEFGHIJKLMNOP
Then you have registers like OPA, PAB, etc., which is also relative hard to use. (It took me a while to figure out the 16th alphabet is P.)

[aa-dav]

If there is no hardware reason behind limiting GPRs to 26 letters I whould propose alternative register naming: B0-31 for bytes, P0-31 for pairs, T0-31 for triples and Q0-31 for quads as an example. Original lettering could be saved with exception of wrapping ones. That is P1 is synonym for BC. And Q30 has no synonym in letters (and it is wrapping one).
Alphabet lettering is good thing in fact for controlling unconscious registers overlap. For examle in ADD HIJK, KL we can see more clearly that overlapping happens than in ADD Q16, P18.

[EnthusiastGuy]

Hi there

... 26 GPRs seem alphabet-induced limitation. Encoding seems to support up to 32 8-bit GPRS. Is it really about letters, or there are some other considerations like placing 6 bytes of SPR/SPC into register pages during register set changes?

I've thought of the 26-byte register limit too, but I think it all came down to the convenience of the coders.

[Paraphrased]
The register system's "circular looping" is powerful, but it becomes less intuitive and error-prone when using non-alphabet symbols or fewer than 26 bytes, making register names like "deA" or "OPA" less user-friendly.

Bingo! This actually took me a lot of debating to "settle". I think I went through the full train of thought that Gilbert mentioned and then some. I did consider extra symbols, some suffixed symbols/wording and so on. At some point I thought to leave it as an easter egg for the developer that is willing to code by hand the opcodes with the "hidden" registers but then I'd lose the circular connection which is actually useful on some interrupts where you'd want to register into the interrupt with Z for instance and plant your arguments starting with A/AB and so on.

Every solution I came up with ended up being more confusing than the last. I suddenly realized I am struggling to make the optimal use of available bit space when my focus was instead the user. So, I decided to be a tad wasteful and limit this to 26 simple registers. It does kind-of scratch me that I am losing 6 registers, but I am at peace with this now . It wouldn't be the only place where I'm wasteful, there are a lot of opcodes with 'u' (unused) bits.

... I didn't find where register sets are saved during REGS execution instruction. Maybe they are memory-mapped? Or they reside inside CPU?

Indeed, they're inside the CPU. REGS is simply switching the register page, somewhat similar to what EXX does in the Z80. It can be useful in some situations, but I found that using:

Code: Select all

.YourCoolMethod
    PUSH A, Z   ; Pushes register space defined by A, B, ... Z to stack
    ; your super cool code here
    POP A, Z   ; Retrieves the equivalent register spaces back to registers A, B, ... Z
    RET

... is actually cleaner.

... there are no details about instructions with lower bit size of second argument. Like "ADD AB, C". Second argument could be zero-extended or sign-extended and it's important to understand (and, probably, to have option to choose).

The regular registers (the alphabet registers) have no notion of signed values. They are treated exclusively as whole numbers, so in this example ADD AB, C would act pretty much as ADD AB, [whole value]

Code: Select all

AB = 0xFF00, C = 0x77, ADD AB, C => AB = 0xFF77
AB = 0xFFFF, C = 0x02, ADD AB, C => AB = 0x0001

[Spoiler for the next release]
However, if you do need to use negative numbers, starting with version 0.6.8 (which is currently brewing) you will have a set of 16 floating point registers (single precision -> 32 bit, IEEE Standard 754 WITHOUT the notions of infinity, NaN and negative zero). Since those new registers make no sense to be a part of a composite system, they are named F0 up to F15.

Moreover, you will have the ability to do:

Code: Select all

LD A, F0 or
LD AB, F0 or
LD ABC, F0 or
LD ABCD, F0
; Offcourse, only the whole ABS(float value) carries through.

If the number will fit, the operation succeeds, otherwise the overflow flag is set and the target register is unmodified.

It also works the other way around:

Code: Select all

LD F0, ABCD

Below you can see a program I wrote the other days with this upgraded architecture.

https://youtu.be/DOjuLj5TM6M

The above demo I've just simply ported to Continuum is actually a very impressive piece of work. The original (or one of the originals) was written in BASIC in about 16 lines of code. You can learn more about it or trace it's history starting here.

... I don't see "arithmetics with carry" like ADC on Z80. I understand that there is almost no need in it with ISA supporting up to 32 bit arithmetics, but it is common to have such instructions even in modern ISAs. The only one which is missing it is MIPS (IIRC).

Yes, you are correct. No equivalent of the ADC/SBC exists since I am still in doubt whether it would be needed. Probably for situations where certain existing assembly algorythms would make use of that. That is still a bit on the debate side, but I'd welcome and appreciate your input on this, if you want.

Anyway, it was fun to learn about your ISA! I have the same hobby as you viewtopic.php?t=21868 and did my virtual PC with vitrual ISA too. It's more like PDP-11, however and strictly 16-bit.

Hey, that was really cool to see. Looking at the instructions, you actually have NO waste, you implement a RISC based architecture that makes it very easy to know where your instructions are (I am still having serious trouble backing from a debug breakpoint, since I have variable length instructions).
Also, very interesting way of implementing CALL by tinkering with the stack and instruction pointer addresses.

Not to mention, total respect for actually making a working Wolfenstein prototype. You only need some enemies and a gun and you're there!

[EnthusiastGuy]

I've thought of the 26-byte register limit too, but I think it all came down to the convenience of the coders.
One powerful aspect of the register system is the "circular looping" feature, so if say, if there are 32 bytes in a register set, you need more symbols other that the 26 capital letters, say, if we use lowercase letters afterwards:
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdef
Then, if we want to use a 3-byte register that starts with d, it would become deA, which is a lot less intuitive (and easily to make mistakes) than having exactly 26 bytes, so you can have YZA, YAB, etc.

Alternatively, if we limit them to 16 bytes:
ABCDEFGHIJKLMNOP
Then you have registers like OPA, PAB, etc., which is also relative hard to use. (It took me a while to figure out the 16th alphabet is P.)

Yeah, you're pretty much spot on with your whole message. Just one note, in my model register composition is unable to skip any symbols, they need to be consecutive and incremental, so in your presented references:

1. ABCDEFGHIJKLMNOPQRSTUVWXYZabcdef
2. exactly 26 bytes, so you can have YZA, YAB, etc.

1. deA cannot work, since it skips f. efA would work, so would fA or defA (which is quite a weirdly cool name for a register that also takes me to think: define A)
2. YZA is correct, but YAB cannot be, only YZAB or ZAB. Or ZA (which is yet another weird name for a register, but since I also have KLM, I won't press the topic further)

Most likely those are typos, but since I noticed two, I said it's safer to make this note.

[aa-dav]

The regular registers (the alphabet registers) have no notion of signed values. They are treated exclusively as whole numbers, so in this example ADD AB, C would act pretty much as ADD AB, [whole value]

This is zero-extension behaviour.

However, if you do need to use negative numbers

Wait, you do have negative numbers already. You just don't have sign-extension operations with second-operand-with-lower-bitness.
Latter is not obligatory requirement, but binary addition and substraction with https://en.wikipedia.org/wiki/Two%27s_complement two's complement could be perceived as signed values already. Multiplication and divisian are operations which needs to know difference (so, there are unsigned mul and signed mul in most ISAs).
I whould recommend to add one instruction to your ISA: EXTEND SIGN, for example:

Code: Select all

EXSG HJ, J

In fills bits of upper bytes of first argument with upper bit of second argument, so 0xA7 will be converted to 0xFFA7 as if 0x77 is negative value -167.
Also you can add EXTEND WITH ZEROS simmetrical operation which will fill upper bytes with zero (but that could be imitated (not fully because of flags corruption) by just XOR H, H).
Also to fully support integer signess you must have "overflow flag" which is somewhat like carry for signed values.
In fact four flags are sufficient for signed and unsigned condition flags: zero, carry, sign and overflow. Some modern ISA just doesn't have anything else.
Check there: https://goiabada.github.io/docs/section ... flags.html - all integer conditions are described as logical operations on four flags: Z, C, N and V.
(It important to mention that Z80 has support for Overflow flag and calculates it correctly, but it has no conditional jumps which could do signed integer comparisons like 'less than', so they must be implemented in several instructions. So it has limited support for signed integers, but you could do full of it easily)

I have no more time right now. I'll add up to my answer later.