Differences

This shows you the differences between two versions of the page.

--- sd:the_paradox_of_the_perfect_virtual_computer [2026/06/19 09:17] – appledog
+++ sd:the_paradox_of_the_perfect_virtual_computer [2026/06/19 09:54] (current) – appledog
@@ Line 57: / Line 57: @@
 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.
-== 32 and bit
+== 32 and 64 bit
 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.
@@ Line 63: / Line 63: @@
 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.
+== How many cores? Protected mode?
+The idea of CORES can be done in two ways. Either is transparent to the underlying system. The software must deal with this if it is allowed; from the standpoint of the state machine how it is implemented is meaningless. However; there must be something atomic about the system or there must be some atomic authority. Not everything can be re-entrant -- just most things. Protected mode and memory management is just like this. These are all features of a multi-user operating system that is designed to accomodate management engines and all the //other// modern conveniences required by modern computing in a modern world. So be it, but we defer to the host for this. We do not need to do any of that. So long as we provide the ability to fork(), we are feature complete.
+//How// we do this is irrelevant. I suggest a software solution such as a CPU "class" which we can then instantiate multiple of such, and have them co-ordinate -- likely through that shared-memory IO space I proposed -- or in some other way (but it will all come down to a shared memory somewhere, I suspect). This can let a protected mode program on one CPU request a second CPU to run certain code (or idle).
+Luckily we do not need to worry about this at all. Almost any game can simulate such as thing with an event que. Polling an event que even several thousand times per second is trivial; even for a program running on the SD-8516, which has a YIELD or otherwise hits the host with 241 batches per second; that alone is around a 4ms resolution and fine for almost any kind of UI except, perhaps, hair-trigger FPS shooters. Which are not really our problem domain. And, again, YIELD fixes that problem cleanly.
 == But why Retro?
@@ Line 68: / Line 75: @@
 And, we are. We are retro done right, and we are also, just a computer.
+== The path forward
+The original b0..b7 system seems more interesting and capable than EA, AX and EAX, precisely because it is separate. That splits 32/64 bit programming away from 8/16 bit based on the mode of the programmer. For C, it is less important; for C or any other language, pick the video mode and sound system that represents your era and set the system speed accordingly.
+With this in mind, what changes are to be made?
+* Simply the addition of the q0..q7 would aid.
+* More video modes.
+* Separate IO memory. This is looking more viable every day.
+* The kernal has to be moved. Likely to the start of, or end of memory. The kernal interface is based on the INT system. Next, FREE RAM becomes easy to calculate; it's the start of kernal space. The big issue, I suspect, is the INT system.
+=== Separate memory?
+The first thing to do is create a special bank (of 64k?) which we can call cache. All IO will be run through this and not main memory. This memory is accessed only via special load and store commands. The key here is I don't know what those commands should be, or how they should work. Maybe a MOV command that can move to and from cache memory. But how does this work exactly?
+* a) Since [] is used for a memory location maybe <> or () can be used for a cache memory location.
+* b) A separate opcode that moves data between registers and cache memory
+    LDA <$E000>
+    LDA ($E000)
+    LDA [[$E000]]
+This 'parallel memory' for IO and possibly video is interesting. A data-only memory, or, system/kernal-only memory.
+   MOVC A, [$4000]
+   MOVC [$4000], A
+The thing is, using [$4000] makes it look like something from RAM.
+   LDA &$4000
+Using & could indicate it's from cache, but this means it would need to be a different opcode.