Last visit was: Sun Aug 01, 2021 4:58 am
It is currently Sun Aug 01, 2021 4:58 am



 [ 20 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: 17
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: 9
Location: https://en.wikipedia.org/wiki/Tashkent
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:
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:
Code:
; KOYAANISQATSI BYTE-CODE / ASSEMBLY          ; IA-32 PSEUDO-ANALOGY
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:
Code:
; 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: 9
Location: https://en.wikipedia.org/wiki/Tashkent
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: 1627
Thanks! It looks nicely retro!


Mon Apr 12, 2021 12:01 pm
User avatar

Joined: Sat Feb 13, 2021 12:22 pm
Posts: 9
Location: https://en.wikipedia.org/wiki/Tashkent
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.
Code:
╔════╤════════╤════════════════════════════════════════════════════════════════╗
║ 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                                      ║
╚════╧════════╧════════════════════════════════════════════════════════════════╝


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:
Image
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
 [ 20 posts ]  Go to page Previous  1, 2

Who is online

Users browsing this forum: AhrefsBot, CCBot and 0 guests


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