Last visit was: Fri Jul 19, 2024 6:43 am
It is currently Fri Jul 19, 2024 6:43 am

 [ 22 posts ]  Go to page Previous  1, 2
 KISC: TTL-Processor with "Koyaanisqatsi" Instruction Set 
Author Message

Joined: Wed Feb 03, 2021 4:13 am
Posts: 19
DiTBho wrote:
Although MIPS is *somehow* a mainstream processor (not like arm, but with more commercal interests than RISC-V) it hasn't yet got a decent and stable one for llvm; HPPA (HP-RISC) is not even close to being mainstream, and it's rather a niche things, however, although there it's still supported by Linux, and although there are several enthusiasts around the internet, it has never had a working machine layer for llvm/clang, and even the support for GCC is not exactly "brilliant" since there are several issues compiling 64bit-kernels.

Damn! It's really shocking!

Mon Feb 22, 2021 12:56 pm
User avatar

Joined: Sat Feb 13, 2021 12:22 pm
Posts: 11
DiTBho wrote:
Well, first you have to write the machine-layer for the back-end :o
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! :D
DiTBho wrote:
From the above, I deduce (my pure speculation) that supporting llvm must not as easy as it sounds :shock:
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:
1234 C9 CC 15 0F|MOV C9,[BC1+5]
1238 B9 BB 16 0F|MOV B9,[BC1+6]
123C       90 CF|JCF BC9+0      ; JCF [BC1+5] ; JNC WORD PTR [EBX+5]
123E C9 CC 17 0F|MOV C9,[BC1+7]
1242 B9 BB 18 0F|MOV B9,[BC1+8]
1246       90 DF|JDF BC9+0      ; JDF [BC1+7] ; JNZ WORD PTR [EBX+7]
It's monstrous! Whole 10 bytes per one branch! :shock:
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:
; i8080-A --> A1
; i8080-B --> B1
; i8080-C --> C1
; i8080-D --> B2
; i8080-E --> C2
; i8080-H --> B3
; i8080-L --> C3
; i8080-SP -> B4:C4
; i8080-PSW > A1:A0
; i8080-M --> [B3:C3]

; i8080 "MOV A,B" (78)
7800 A1 AB 1F   |MOV A1,B1
7803          00|HLT

; i8080 "MOV A,C" (79)
7900 A1 AC 1F   |MOV A1,C1
7903          00|HLT

; i8080 "MOV A,D" (7A)
7A00 A1 AB 2F   |MOV A1,B2
7A03          00|HLT

; i8080 "MOV A,E" (7B)
7B00 A1 AC 2F   |MOV A1,C2
7B03          00|HLT

; i8080 "MOV A,H" (7C)
7C00 A1 AB 3F   |MOV A1,B3
7C03          00|HLT

; i8080 "MOV A,L" (7D)
7D00 A1 AC 3F   |MOV A1,C3
7D03          00|HLT

; i8080 "MOV A,M" (7E)
7E00 A1 AA 30 0F|MOV A1,[BC3+0]
7E04          00|HLT
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! :lol:

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

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!

Mon Feb 22, 2021 3:00 pm WWW
User avatar

Joined: Sat Feb 13, 2021 12:22 pm
Posts: 11
BigEd wrote:
That's significant progress! When you can, please share a link to your emulation solution.
Sorry, but very raw and shameful
Koy-Mac-Emu (Koy-Machine-Emulator) is ready in this moment… :oops:

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…

Sun Apr 11, 2021 10:20 pm WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1789
Thanks! It looks nicely retro!

Mon Apr 12, 2021 12:01 pm
User avatar

Joined: Sat Feb 13, 2021 12:22 pm
Posts: 11

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…

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.

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.
║ D9 │ Device │ Description of access to unit through the processor APRs       ║
║0x53│ i8253  │ D0/D1/D2 - Counter 0/1/2                                       ║
║    │        │ D3 - Mode Word Register                                        ║
║0x55│ i8255  │ D0/D1/D2 - Ports A/B/C                                         ║
║    │        │ D3 - Control Word Register                                     ║
║0x57│ i8257  │ D0/D2/D4/D6 - Channels 0/1/2/3: DMA Address                    ║
║    │        │ D1/D3/D5/D7 - Channels 0/1/2/3: Terminal Count                 ║
║    │        │ D8 - Status Word Register                                      ║
║0x79│ i8279  │ D0 - Data Word Register                                        ║
║    │        │ D1 - Status Word Register                                      ║

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.

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:

You do not have the required permissions to view the files attached to this post.

Mon Jun 07, 2021 10:01 pm WWW
User avatar

Joined: Sat Feb 13, 2021 12:22 pm
Posts: 11
A few tiny improvings of command decoding pull out this esoteric Koy-Architecture up to standard.
For example:
0000 A5         |REG A5        ; Select A5-APR
0001    FA      |INT FA        ; CALL 0xFA00 - LDA .DB 0x34
0002          34|.DB 0x34      ;
FA00    AA      |ARG A,A       ; Select An for loading
FA01       01 0F|MOV A,[BC0+1] ;
FA02       02 CE|JNC [BC0+2]   ; Ret
In new conception this code we can present like this:
0000 A5         |REG A5        ;
0001    AA      |REG A,A       ;
0002 10 10 02 0F|MOV A5,[IP+2] ; MOV A5,[0x0007]
0006          00|HLT           ;
0007          34|.DB 0x34      ;

Many options reaching through strange combination:
1234 -- -- -- -- CE|CLC                 ; Clear CF
1235 -- -- -- -- CF|CMC                 ; Complement CF
~~~~ ~~ ~~ ~~ ~~ ~~
1234 -- -- -- CE CF|STC                 ; Clear+Complement -> Store CF
~~~~ ~~ ~~ ~~ ~~ ~~
1234 -- -- -- CF CE|???                 ; Reserved: Complement+Clear -> ???
~~~~ ~~ ~~ ~~ ~~ ~~
1234 -- -- -- CF CF|???                 ; Reserved: Clear+Clear -> ???
~~~~ ~~ ~~ ~~ ~~ ~~
1234 10 10 10 15 CE|JCE [IP-5]          ; Jump with self-loop, if !CF -> HLT NC
1239 10 20 20 15 CF|JCF [BC1+BC2*6+5]   ; Jump, if CF

In this context, we can disable for using other obsolved simple code:
0000 AB         |ARG A,B
0001    A5      |REG A5        ; We can select the left operand
0002    B7      |REG B7        ; This switch works with next code only: Prediction, Advance
0003 BA         |ARG B,A       ; Accumulator is B7 though advance with previous code 0xB7
Then, this code can works like:
0000 AB         |ARG A,B
0001    A5      |REG A5        ; We can select the left operand
0002    B7      |??? B7        ; Exception: No Advance! Reserved code
0003 BA         |ARG B,A       ; Accumulator is not B7
0004    A5      |??? A5        ; Exception
0005    B7      |REG B7        ; Accumulator is B7

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…
1234    DD      |ARG D,D                       ; Operations «Device<->Device» is prohibited! But this is «Double<->Double» mode (BC pairs)
1235       D9   |REG D9                        ; After «ARG D,D» this work as «REG B9» and «REG C9»
1236          9E|EOR D9,D9                     ; Bitwise Exclusive OR with 16-bits operands (EOR BC9,BC9)
1237 50 60 70 8E|EOR D9,#D5+D6+D7,D8           ; BC9 = *(WORD *)(BC5 + BC6 + BC7) ^ BC8
123B 51 62 73 8E|EOR D9,#D5+D6+D7+123,D8       ; BC9 = *(WORD *)(BC5 + BC6 + BC7 + 123) ^ BC8
123F 50 50 70 8E|EOR D9,5#D7,D8                ; BC9 = *(WORD MODE_5*)BC7 ^ BC8
1243 50 50 60 60          8E|EOR D9,56#,D8     ; BC9 ^= BC8 in Mode #56
1248 50 50 60 60 70 70    8E|EOR D9,567#D8     ; BC9 ^= BC8 in Mode #567
124F 50 50 60 60 70 70 40 8E|EOR D9,567#D4,D8  ; BC9 = *(WORD MODE_567*)BC4 ^ BC8

Prefix interpreteer at here
Draft of Wiki-description at here

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

Mon Feb 28, 2022 11:20 am WWW
User avatar

Joined: Sat Feb 13, 2021 12:22 pm
Posts: 11
Is no developing in current time, but conceptual improving.

In old conception we have any empty sequence, like:
A1      |REG A1          ; Register A1 as Accumulator
A2      |REG A2          ; Register A2 as Accumulator
A3      |REG A3          ; Register A3 as Accumulator
But now that code mean this:
A1 A2 A3|REG A123        ; Register A123 as Accumulator
Thereafter the code:
4F      |MOV A123,A4     ; Move A4 to A123
5F      |MOV A123,A5     ; Move A5 to A123
6F      |MOV A123,A6     ; Move A6 to A123
Now means this:
4F 5F 6F|MOV A123,A456   ; Move A456 to A123
BC B1 B2 B3 B4 C5 C6 C7 C8|MOV B1234,C5678
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.

Fri Apr 05, 2024 11:00 am WWW
 [ 22 posts ]  Go to page Previous  1, 2

Who is online

Users browsing this forum: CCBot and 1 guest

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software