Why not just write a C program for your desktop or use Emscripten if you want it on the web?

Because then you have to worry about portability and software lifecycles. What happens when they release the next Windows? Software dies after a few generations, by hook or by crook. It's the circle of life.

If you write a program for the SD-8516, it will live forever. And, you can write it in C, if you want. The slowdown is about half. That's the price you pay for an emulated system. But ask yourself, are you really using all of your modern computer's power? If the answer is no, I make the bold statement that the SD-8516 is a better choice, as a development platform, that any other computer system.

It's a dichotomy to be sure. The duality of man.

On one hand, it should be “retro”. It's clear that a throwback is good. However, it should also be a serious attempt at computing.

It must fulfill the ubiquity requirement. I.E. everyone had a C64. Everyone had a SNES. That kind of thing. It has to have a popularity transcending some kind of niche. That means, in this case, it has to run everywhere and on everything. Two entirely compatable goals, because it means we do not need to compete with modern computers for speed.

This means the system itself is single core. The software can multitask. But this is a single user system. The system is intended to run one application at a time. Not an OS with multiple things going on, like 100 different background theads. That could happen, but, it's not the design goal.

It must know itself. It is not real hardware. Attempting to be RISC is wrong. There are no cycles. Cycle accuracy was an artifact of hardware and it was unintentional. We do not need it.

But we are not really trying to invent a completely new programming language, although that is essentially what this is; a game library attached to a programming language. However, it is intended to represent the interfaces of yesteryear. This is important because it makes the box general purpose. Thus fulfilling the goals of a) retro and b) general purpose.

We do not aim for speed and power directly. It comes, we do optimize, but the goal is not to get 1000 mips. The goal is to get enough mips to cover anything in the early era. This means 1 to 100 is fine. As a CISC machine with no cycle count this is fine; 10 mips on the SD-8516 is worth 30 mips anywhere else; likely a little more due to instructions like CASETAB, SKPC, CVTAN and so on.

Early attempts tried to mimic hardware a little too much. The SD-8510 has bank registers. This was a total failure. Later, the SD-8516 had dual register instructions, which evolved into paired registers to get 24 and 32 bit general purpose registers, to be used as pointers. This was also a failure. The organization of the kernal in bank 1, and using memory mapped IO was also problematic (but somehwat workable). The ideal solutions to these were to expand the register file, increase the RAM slightly (to 512k or 1M) and provide an IO bank and/or video bank. This would lift the IO out of main memory without radically changing the IO interface.

The other option was to create some kind of device profile; i.e. a bus of 256 or so devices, which could be read from or written from. These are like registers; a separate memory area for IO. I.E. read from the keyboard status register. It could be done like:

  READ $56   ; read from port $56 into device/port A
  WRITE $56  ; write from A into device/port $56

This leads us towards;

  READ A, [$56]   ; Load from $56 into A -- this looks like a LD...

And it is a LD, but from a different, protected memory region. Like a fast IO cache. The alternate is to define functions directly like

  READKEY A         ; read a key into A
  PIXEL X, Y, C     ; as an actual opcode

These are like accelerators, but they don't feel like opcodes at all. More like a programming language. The fact is, in the end, that's what this really is. However, also, it isn't. It's a computer. It's just a computer that is running on software. What's so strange about that?

The closer you get to how a modern computer operates, the farther you get from success for a project like this. This is not a modern computer nor should it be. That doesn't mean it should be poorly designed. In fact this should be as capable as it could be; including 64 bit registers. But wait, didn't you just say…

“Retro done right.”

Why yes, yesI did. The issue here is constraints. The SD-8516 aims to be very hand-assembly friendly.

If you want to copy the 8 bit era:

Use only AL, BL, CL, etc. and don't use too much ram. Just the choice to use 8 bit registers will help you. Then again, look at what Steve Wozniak did. He wrote Sweet-16, to simulate 16 bit registers on an 8 bit machine. So keep an eye on your speed. Set MIPS to 1, or, 0.5. Maybe even try 0.25. Deal with it. This is how it was. Make it work. Crashing up against the constraints is what made the old games great. It was about gameplay, not graphics.

The 16 bit era is the main focus here, and will cover the SNES and early PC era. Use 16 bit registers. Ram, you can open up on a bit. RAM over 128k was common here.

The key is not should the SD-8516 allow 32 bit, but how it should allow it so that it does not interfere with 16 bit hand assembly. The method is simple; use 32 bit registers and not 16. The proposed standard for 32 bit is to use register pairs; AB, CD, XY, IJ, KT and so on. There are eight of them. But the second proposal is 16 X registers such as AX, BX, CX.

The 64 bit registers could be called EAX, EBX and so on. We could even go to 128 bit via SA, SB, SC or any other convention.

Another convention is to have b0..b7, then w0..w7 (with b0 accessing it's low byte) and then p0..p7 (24 bit), d0..d7 (32 bit), q0..q7 (64 bit) and even s0..s7 (128 bit). With a cross-width MOV, this system side-by-side with the current system would also be very powerful. The key here is you do not need to use such a system. With some restraint, you can hand-assemble any kind of program you want.

You don't have to do that. That's the point. You can if you want. This is a power that only an emulated computer can have. We can have a very large register file. We are not trying to be a modern computer. The entire system fits in cache! RAM included. We only need to be a computer.

And, we are. We are retro done right, and we are also, just a computer.