Short Survey on Programs

The microcode software is under development. I'm juggling with 5 or 6 types oft software:
- microcode
- millicode (yes, that's new!)
- bytecode (new too)
- assembler opcodes in ram
- the microcode assembler
- the microcode emulator (new)
- vipsi script interpreter (found the second bug in it after 5 years) B-)
So, slowly, what are they all about?

Vipsi Script Interpreter

The thing of software which also delivers this web site. The microcode assembler and the microcode emulator are written in this script language too.


That's obvious, hopefully. The codes actually executed by the control unit. All living starts here. After reset it also is obligued to setup the machine and load drivers and program. There are no other roms in the CPU: the microcode also contains the BIOS.

Assembler Opcodes

That's what the microcode is going to implement: Opcodes for a program running in ram. All opcodes are actually addresses of tiny programs in the microcode rom which load the next opcode when they are done:
:ADD ( a b -- c )
    add (hp--)
    jp  (ip++)

Microcode Assembler

The piece of software which reads the microcode sources and creates the hex files for downloading into the microcode roms. It eases my live with flow control instructions, compound instructions, checking, postponing and fitting the code into the roms. That's all not trivial and all very error prone. See what it creates from the above code example:
:ADD ( a b -- c )
    tst_add (hp)            // 1
    add     (hp--)          // 2
    ld      cmd,(ip++)      // 3
    nop     :bit15          // 4
1: add is too slow, because the carry can ripple through 16 bits until the result has settled. Therefore 'add' and similar opcodes must add a wait cycle, where the inputs are applied but the result is not yet latched.
3: This is, basically, what 'jp' in microcode does: it loads a new address into the microcode address counter, instead of incrementing it.
4: But this is what is required too:
- The next opcode is already fetched by the control unit and will be executed before the jump takes effect
- The feedback line (aka 'flag') 'bit15' is selected to determine in which code plane the jump will actually jump to. In a simple case this would be flag '0' (unconditional plane 0) or flag '1' (unconditional plane 1). But here i use flag 'bit15', which forwards bit 15 from the data bus, so that the jump destination will be in plane 0 (1) if bit 15 of the jump address is cleared (set).

Microcode Emulator

This is the newest piece of software. I'm currently no longer downloading the microcode to the real CPU but to an emulator written in vipsi. The emulator code has ~ 100 lines netto. Debugging stuff and comments increase it to ~ 400 lines currently. The simulator mcsim.vs is located in Software/Microcode/ aside the microcode source.


One of the best things which are possible in the K1 CPU's microcode is to jump to microcode addresses via table. Huh great! Great?
At first it seems impossible to do this. You cannot read microcode cells at arbitrary locations. There is no other source for addressing than the microcode address counter. It is hard to put a string of text into microcode. But, pretty soon, i felt it would be simpler to write something like
    pushstr "abc"
instead of:
    push 'a'
    push 'b'
    push 'c'
This could be solved similar to this:
    jsr pushstr
    dw  'a','b','c',0
    jp  p3
    jsr allocstr
    pop a0              // get return address
p1: ld  cmd,a0++        // jump
    ld  d0,ival :bit15  // already loaded microcode
 // --- 
p3: tst d0
    jp  !z,p2
    jsr storechar
    jp  p1
p2: ...
I tried to keep the example as short as possible. Microcode execution starts with a subroutine call to pushstr. pushstr pops the return address from the return stack which points to the 'a'. Now it loads the microcode address counter with this address (line p1:) but the next microcode is already loaded and is executed next: This loads register D0 with an immediate value which follows in the next microcode. This next microcode is the 'a' where A0 pointed to. Then the microcode runs through the other data bytes which just consume time but do nothing. Finally it reaches the 'jp p3' which jumps back to the string reading loop. Next time the jump hits the next char, because a0 is incremented each time.
Though this example has lots of room for improvement it shows how 'the impossible' thing works. With a little tweaking microcode can read constant data from the microcode rom.
The next step was to realize, that this works even better if the constant data is not 'data' but code:
    ld  alu,jptab1
    add alu,d0
    add alu,d0
    jp  alu
    jp  proc1
    jp  proc2
    jp  ...
Step 3 was to realize, that not the whole 'jp' instruction must be in the table, but only the address:
    ld  alu,jptab1
    add alu,d0
    ld  cmd,alu
    ld  cmd,ival  :bit15
    dw  proc1     :bit15
    dw  proc2     :bit15
    dw  ...
The trick are the two 'ld cmd' instructions in succession. It's a combination of the ideas in 'step 1' and 'step 2'.
Ok, and if, now, we use the address register 'ip' (instruction pointer, sic!) to point to the 'table' of addresses and if the addresses only point to routines which, after having done their job, jump to the next address in this list, we have in microcode exactly what assembler opcodes in ram do, and i called this millicode. It is much easier to write programs in millicode than in microcode assembler. :-) Though a little bit slower, due to the linking jumps and because i use a forth-style approach of argument passing on a data stack, like i do for assembler opcodes in ram.
After adding some glue to the microcode assembler, millicode programs look like this:
:DictShrinkToFit ( dict -- )
    Millicoded          // switch from microcode to millicode
    mc  Dup,DictWordsGet
    mc  Addq dict_word0 
    mc  Resize,Drop
    mc  Next            // kind of return
Yes, not only do i have a Forth CPU, but it's microcode is also programmed in Forth! :-)


Last thing to explain in this list is the 'bytecode'. This is a subset or at least very similar to assembler opcodes, only that instead of the opcodes it uses enumerated codes for instructions. Bytecode is the code loaded from driver eeproms on the K1-bus extension cards and is translated to assembler opcodes by the microcoded boot loader after reset.