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.

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.

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. However, lowering IO directly into opcodes