Feedback/suggestions on the architecture of the Continuum 93 fantasy computer

Software
, ,
1

Hi there,

Last year I was tempted to purchase the computer I started programming on in my childhood. It was a HC2000, a romanian clone of the ZX spectrum, 48k basic, floppy disk. I loved that machine and now they are extremely rare to come by. I struggled a lot, because the price was high. While, yes, I could afford it, I was quite torn between owning it, knowing I won’t do much with it, rather than play some old games now and then. So, after quite a bit of soul searching, I decided not to buy it, and instead chose to create a fantasy computer inspired by it. The aim of it is to function pretty much in the spirit of the original, but with some improved features, with the ability to write code easily, debug easily and eventually have a wrapper so people can release games and applications made with it.

Right now it’s a Windows exclusive, but I have plans to also be able to easily deploy it onto Mac, Linux and quite a few single board computers, such as raspberry pi’s and others, through a host lightweight OS.

So, in the last quarter of 2022, I started putting it together, as an emulator written in C# with MonoGame. So, behold! Continuum 93 is now in its infancy. A 30 Mhz single core CPU with a full set of proprietary assembly instructions (clearly inspired by the Z80 set), with 16 MB of RAM, but able to manipulate 8 bit, 16 bit, 24 bit and 32 bit registers, separate stacks for calls and registers (that have their own memory) and multiple register pages. The video architecture is a 480x270 pixels 8bbp organized on separate layers (able to set up from 1 layer up to 8 layers, each one with a 256 colors configurable palette). Yes, it is primarily designed for retro games.

The development of it is at a slow-relaxed pace, but I’d like to create a good backlog of features/additions to it.
I am already considering extending the instruction set to include the ability to work with negative numbers, floating numbers, and also include some 2D graphics acceleration features. Also, when available (on some single board computers) it would also be able to access GPIO pins.

Then, I thought that maybe I can share some of my work here, to expose it to suggestions and critique, since I do suspect some of you worked intimately with assembly at some points.

Do you have some assembly instructions that you think would be interesting to be added to this architecture? Do you have some overall suggestions or do you want to point out some mistakes you believe I made? If you have the curiosity and time, please take a look! I’ll appreciate all feedback, including the one that criticises.

I wanted to make it easier and attach the .pdf documents here directly, but the extension is not allowed. So, I would kindly invite you to download the release from here and look in the Support subdirectory where you will find the documentation I am making reference to:

The assembly reference and interrupt reference are auto-generated by a tool I have which interprets the logical primitives I use in my emulator and produce the documentation in less than a second, so there could be some weird mistakes there. Of some, I am aware. Some documents might look discouragingly lengthy, but that’s because every instruction has been disected and documented. In general, probably just looking at the table of contents would be enough to get an idea.

Thank you!

1 Like
2

Always good to see a new invention!

My advice, I think, would be to try to go towards minimalism(*) rather than maximalism. For a few reasons

  • simpler machine is easier to learn
  • simpler machine would be a smaller chip, a more realistic alternate history
  • the constraints of programming a simpler machine make for more creativity
  • simpler machine is easier to write, test, debug

Nice idea to be portable to all popular platforms including the Pi! (The Pico might also be an interesting target, although a very much smaller one.)

Edit: (*) I don’t quite mean minimalism. The Z80 isn’t minimal. But if you keep adding things and approach something like an Athlon, that’s maximal!

1 Like
3

I definitely recognize what you are saying. Some part of me is already saying this “machine” is basically ready with this architecture it has now. What it clearly misses is sound. But, I think I will be able to have a nice surprise there.

Sure, I will polish a few things, right now I am writing a better OS for it, and by this, exposing myself to my own work to see what would be the difficulties of programming on it and fix those before someone else gets frustrated.

But some other part of me also wants to explore a bit and see what would be out there that could be a nice discrete addition.

Clearly, I don’t want to end up writing a new Java VM, so yes, I need to be careful!

Thank you!

4

First time I have seen software, being used as hardware.The main reasion one uses a
minimal system is to have as few bugs as possible,like ARG , reset is active high not low
as wired. Since you can debug software today quite well I say go for it. Have you looked
at the Japanese computers of that era, some had really impressive hardware.

1 Like
5

Is it just for gaming?
There are many emulators around.
More minimal would mean only one system. And those emulators exist.
But I think there are also similar attempts. Multi-systems in 1. Or general platform independent gaming engines including browser/online and offline. (Sorry, I currently don’t remember any names).
I wonder if this will be successful and what the goal is, except for personal reasons.

Mixing 8-bit, 16-bit and even 32-bit in one system.
The higher systems can display more colors and higher resolution.
And you can’t play 2 games at the same time.
And it also depends on the available games.

Best retro games and game ideas to me is still a C64 despite or rather because of the few colors and low resolution.

1 Like
6

Hi there!

It is built with retro gaming in mind yes, but certainly not limited to. And actually, the machine is 24bit, since the memory addressing takes up that many bits.

When I mentioned the 8 bit through 32 bit I meant the registers and it’s certainly not uncommon to be able to work with registers on lower bit space even on 64 bit hardware. Maybe a stretched example is to consider a higher level language that is able to define variables as boolean (1 bit), byte (8 bits), short/ushort (16 bits), int/uint (32 bit) and so on. It is mainly done to save memory when you know that for certain purposes you only need a specific amounts of bits.

I am not certain what you mean by playing 2 games at the same time. If you mean multitasking, such as starting two games in Windows and alt-tabbing from one to another, that can be achieved even with a single core CPU, since you can implement an operating system which performs a round-robin scheduler able to switch from one process to another. Moreover, you can even implement a way to pause the process that is not in focus, so your CPU remains free for whatever process you are working on actively.

There is indeed an extensive list of fantasy computers/game consoles which NoLand kindly brought to my attention (kudos), so indeed there are quite a lot of existing efforts. Had I known about it before I started building mine, I’d still went ahead and done it since I feel Continuum offers (or will offer) a few unique advantages. That’s not to say I am confident this will lead to some extraordinary success and there’d be an overwhelming amount of people using it. It might definitely die alone on the Internet, and even then, I will simply publish the sourcecode of everything and still expose some value for other people to either build something similar or better than mine, or modify it in such a way that has more vision or success than what I tried.

The aim of this fantasy computer is to be an easy-to-use computer that allows writing retro-games in assembly, on a machine with a balanced set of limitations (for instance, out of that long list I mentioned earlier, there are only 3 computers that work natively with assembly, and Continuum is one of them). It is also meant to eventually be deployed to a lot of hardware to mimic taking ownership of, and turn itself into an “indistinguishable hardware”, and also to allow people to publish their games on Steam, Epic games or Itch, for instance as stand-alone games.

At least, that is the vision now. What will happen, we’ll see, I still need to invest some effort in maturing this project, and if nothing else, I will definitely have enjoyed this journey. :slight_smile:

Thanks for your feedback!

7

As you should!
I’d also advice in the direction of a simple design. Not so much for the difficulties you may encounter, but for the “real” retro feel. Retro computers were all about their limitations, even back in the day. Now adding to this whatever feature we may wish for is quite against the basic idea. I also think that the fun is really in dealing with these limitations and stretching the boundaries. (Think Atari 2600.) Which is only possible, because the simplicity of the design allows us to maintain a mental image of the entire system.
A rather novel way of approaching this and emulating how these systems were designed may be to put an imaginary price tag on each component that would have been required and then go for cost reduction, as a general guideline for features. Maybe even determine a budget in front and then try to meet these requirements.
(Notably this should not attribute to the native assembly feature, which is quite a brilliant idea.)

1 Like
8

I like the idea of costing out the features. One of the pitfalls of a paper design, or even any software-implemented design, is that there are negligible costs involved. But real CPUs have a cost - transistors and wires consume area, and final cost is an (exponential) function of chip size. In a TTL implementation of a CPU, there’s a Bill of Materials, and a large PCB will cost more - perhaps much more - than a small one. In programmable logic, such as CPLDs or FPGAs, logical functions are almost free, until the point where the design overflows one specific device and the next-biggest device costs more.

We had some fun a few years back with One Page Computing, where the constraint was to confine code to 66 lines of printout. That was quite extreme. The UXN project is similarly small: 100 lines of C for the core.

1 Like
9

I spend far too much, on sourcing components. since I live in the middle of now where. the price of shipping far exceeds the price of components. The only fast supplier is Digikey but I can’t count on them for have older 5 volt though the hole parts. I often have to order months ahead guessing the exact parts needed, and reordering again when I get the pcb mostly done.
Check the power of the larger IC’s, I have gone to ALS and CMOS for the 8 bit wide compnents.
125 ma vs 25 ma does add up.

PCB prices from china for 8 x 10" cards are about $100 + $50 for shipping in US dollars.
I found routing a PCB requires lots of space for wires than you expect. Older parts you
wire around the chip 74ls374, newer parts 74ls574 you wire through the chips.
I like cmos 16v8’s and 22v10’s, to replace TTL.
Ben.
Back to my 36 bit 2.0 uS TTL (2901) mainframe project.

1 Like
10

Yes, I am definitely convinced of that. I don’t think I would make dramatic additions to the assembly architecture. Maybe indexed addressing (which, also existed on the Z80) such as:

  XOR AB, AB
.clear_loop
  LD (0x000000 + AB), 0 ; <- Indexed adressing
  INC AB
  CP AB, 0xA000
  JR NZ, .clear_loop
  RET

I am now concentrating on usability features, such as a simpler way to write code for it, a better OS (written in native assembly), the debugger and after that I’ll tackle sound.

The one feature that kind-of appeals to me is some interesting way of processing graphics, such as SNES’s famous video mode 7. But that’s definitely for later, and I’m not even sure I’d go the same path. But I’ll try and find a naive way to evolve to “some” 3D.

Then I expect to port it and then write the wrapper to allow people to write games they can publish.

And, I think that’ll be it. After that I expect I’ll just write software libraries in Continuum assembly, example programs, some tutorials… But I would leave it as is. Oh, probably some more interrupts I may have missed.

11

True. That is why I am cheating. :smiley: I never intend to go to a hardware implementation with this. Not that I wouldn’t love it. But this will start and end as a virtual computer since it is a way faster path for me to get far with it.
In all honesty, if the stage is set correctly, it could become indistinguishable. For instance, if you set-up a raspberry PI correctly, put a Z80 spectrum emulator on it, set it up to start really instantly and plug the whole thing inside a classic ZX Spectrum, who will know? :smiley:

12

Sure, for some purposes this can work very well. Not all purposes though, which is why there are still projects which expose the CPU bus, for example, or have an actual CPU in them. It’s up to the originator to decide what their project is going to look like, always bearing in mind that one person’s preference doesn’t invalidate anyone else’s.

Indeed, in the case of the one page computing, and some not-quite-6502 adventures I once had, a very early step was to write an emulator, because that’s the easiest thing to do, to explore the software possibilities. (The next thing needed is an assembler!) This is true, I think, even if the aim is to make hardware, whether that be TTL chips or FPGA, or something else.

1 Like