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.