Damn! It's really shocking!

So, as a matter of principle, Koy-Emulation I can get at the JavaScript (useful for online browser-level presentation), C (as VirtualDub-filter) or Python (for Raspberry-Pi).
But C-version (for VirtualDub) or Python (for Raspberry) is very specific cases and nobody need for it.
In this way, the JavaScript online emulation demos I looking as best for first time!
Hmmm…
I'm look, for homebrew project that supports for LLVM and C - is very ambicious for non-commercial?

Well, then I will focus on i8080/z80 and JavaScript emulators. And on Verilog model for FPGA…

So, today I'm looking at this code:It's monstrous! Whole 10 bytes per one branch!
It's very actual problem of conception.
But, nevertheless, I see no reason to change something. Because basic conception started from homebrew core for homebrew processor.
For example:As You can see, it's simple idea of homebrew WYSIWYG RISC-core for execution any processor code, where guest CPU code sets high byte of address of microprogram. And 256 bytes per one guest-instruction - is too much for any tricks! Yes, it's will very slowly practical, but even i8086-code it can get too.
But this Koyaanisqatsi-CPU, as I understand it now, is not WYSIWYG-RISC, but WYSIWYG-CISC turns out anyway!

It still good for homebrew Any-CPU kit station abundantly.
But as an independent CPU it is very weird…

P.S.: All industry offers us a large choice of any fast processors. But all that have just very esoteric machine code anyway, where without translators we cann't doing something!
In this light, my fix idea was the essence of developing a simple and intuitive coding homebrew WYSIWYG-core. Let it is very slow, but it's very openned at byte-code level!

Sorry, but very raw and shameful
Koy-Mac-Emu (Koy-Machine-Emulator) is ready in this moment…

Press SPACE for step-by-step emulation & disassembly…

In top-right corner we can see the internal dump of processor: 40 APRs and architecture state.
This dump isn't useful and I using it for debugging of this Koy-Engine.

P.S.: In this time developing of KISC-Concept is temporary hybernated by different cases…

Thanks! It looks nicely retro!

Well…

Since this processor system like homebrew automatization for gardening or smart home and not invented for dynamical graphical playground, but like pocket systems with LCD-silhouettes, then it wanted for special graphical controller for Web-demonstrations.
At the Web-page You can find small assembler, dump viewer, disassembler and improvised LCD-screen with silhouettes…

Console.
Register D₉ is special and serves for switch the peripheral layers.
So, layer of console for output indexed by code C0₁₆ (Console 0ut). In this layer the register D₀ working for direct print any ASCII to screen console.

Graphics.
Each segment at LCD-screen can be turned on or off by single bit of mask register. For this case we can use the peripheral registers D₀…₈ - 72 bits - 72 LCD-segments. Layer of LCD-mask named as Coloured Buffer and indexed by code CB₁₆ in D₉.

Devices Unit Access.


Emulation.
As first step You can just click the «Run» button for typing «Hello World» at console in cold start mode. In this mode assembly program doing few initializes for stack and mores.
Subsequent presses on this button starts the CPU in warm mode, where the program just playing with LCD-segments.

Assembler.
You can direct assembling our code to try the Koy-technology.
For this You can edit the textarea and after You must just click to Refresh of Web-page. When page is reloaded, Your listing we be compiled, since local storage is used.
Assembler is to raw at this time, but for this demos is well.

Graphics buffer.
For this case was invented original idea of graphic system, where CPU have no direct access to screen pixels, since all graphical siluets/sprites must be stored in factory mask ROM (improvised), like factory LCD, like this:

In early times with the Monoscopes we can have a ROMs.
And for 70's as LCD or TV+ROMs-silhouettes we can haved Monoscope-silhouettes-ROM for CRT-TV Processor System for Smart Home.
(As illusion and dreaming about alternate retro technologies.)
In this way we not need for unversal raster generator and can use any other, like ZX-Raster or MSX-Raster. But to provide imitation of LCD-silhouettes we must pack the image to pass through a similar TTL buffer-circuit:

A few tiny improvings of command decoding pull out this esoteric Koy-Architecture up to standard.
For example:In new conception this code we can present like this:
Many options reaching through strange combination:
In this context, we can disable for using other obsolved simple code:Then, this code can works like:

Another feature is the vector mode.
If the classic notation in square brackets «[…]» was originally used for memory addressing, now it is more convenient to simply use the «#» symbol, since you can specify the octal code of the instruction operation mode before it…


Prefix interpreteer at here…
Draft of Wiki-description at here…

P.S.: In emulation that ideas is not realized at this time.
Conception only!

Is no developing in current time, but conceptual improving.

In old conception we have any empty sequence, like:But now that code mean this:Thereafter the code:Now means this:Thereby we can have:

1. Accumulators - from A1 to A999999
2. Bases - from B1 to B999999
3. Counters - from C1 to C999999
4. Devices - from D0 to D999999
5. Pairs - from B0:C0 to B999999:C999999

But we can't have immediate ALU instructions, like «ADD A123,B456» or «SUB A123,A456».
In first, we must load second register in intermediate. So, «MOV A9,A456» and then «ADD A123,A9».

But, because register «A123456789» is from very-very big register file, emulation of this architecture is too raw and difficult.
Too many difficult questions, but not answers in this current.

Since this architecture was conceived with bytecode encoding in the WYSIWYG paradigm, with the help of a neural network it was finally possible to choose the most suitable name - WYSIWISC
Also, since the neural network asked thematic questions with a vision of some problems, it was possible to solve conceptual problems on which everything had been stuck for these years.

Here the paired bytes 70 70 90 90 encode the index of link register #79 - D79, which will store address 0x1104 with the vector descriptor.
After that, instead of a byte-by-byte description of the vector, it is enough to specify the index of the link register - D79. Since register D79 stores address 0x1104, the decoder will remotely read the vector bytes and substitute it for any instruction.in this case, before calling the API, there is no need to use reserved registers and everything can be specified through relative references.

P.S.: Is no developing at this time. I debugged the vector parser for WYSIWISC-Emulator at i8080A.

This is all to complex for me.

Yes, unless You give up standard thinking (like bit fields and octal), the WYSIWYSC-paradigm is hard to understand.
The GPT/DeepSeek concludes that the architecture is about 70% transparent to any outside user, but the bot itself cannot correctly compose the code, since it has no analogues in its DB. Thus, it partially admits that such machine code is much more convenient for a person than all existing architectures, since a person thinks in context, and the neural network constantly loses context.


As first - the Prefixes.
After months of local training in the context of a template chat session, the neural network was still unable to figure out how to encode and decode a chain of prefixes, although I debugged the encoder (online) and decoder on Bash/JavaScript/Verilog, and developed a decoder on i8080/z80.

As second - the Delegates (special type of a empty prefixes).
Bot suggested an interesting term that continues the development of the D-group registers (pairs of B and C) and allows the implementation of a mechanism for tracing/debugging code.

P.S.: Neural network can't help me in developing the WYSIWISC.

Short example for testing neural encoding.

One variant of correct and compact machine code by manual encoding might look like this:I have specially formatted the code with spaces by pattern "Context | Target | Source | Operation".

But DeepSeek and GPT can't generate nearest code anyway!

Some how I get the feeling we are almost back to the old 2 1/2 addressing mode computers.
mem[pc+0] = mem[pc+0] op mem[pc+1]. if {cond} pc=[mem+2] else [pc+3]

Hm… May be…

At the moment, I encountered a rather strange situation.
Lines with "???" indicate a new problem: We have double pointer - delegated and immediate.

Previously, the combo «MOV 9#D4+5,B8» could simply mean «LEA D9,[IP+2]» + «MOV [eval("D4+5")],D8H» (CISC: "redefine delegate" + "move").
But now, as I strive for very strict command decoding (less CISC-commands), I see this as a new problem.

The more I "tighten the screws" in coding commands, the more curious moments arise.

P.S.: Anyway, in options "CISC vs RISC" I wish looking for RISC.

At the moment, I encountered a rather strange situation.

snip
BC B8 90 90 45 6E EOR B8,9#D4+5,C6 ???[/code]Lines with "???" indicate a new problem: We have double pointer - delegated and immediate.

Previously, the combo «MOV 9#D4+5,B8» could simply mean «LEA D9,[IP+2]» + «MOV [eval("D4+5")],D8H» (CISC: "redefine delegate" + "move").
But now, as I strive for very strict command decoding (less CISC-commands), I see this as a new problem.

Would a double pointer imply *(arg1 + scaled arg2 ...) ?
LEA is a needed instruction for most modern computing.

>P.S.: Anyway, in options "CISC vs RISC" I wish looking for RISC.


I am with unimpressed load/store architecture. I very unimpressed with the x86. I like the early machines as they had ample word
size for floating point 36+ bits, and a simple addressing modes ( often only 1).
Accessing external memory is slow, and think that the early designs had the best solution for that problem.