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.