This is a project for self-learning, and is pretty much useless except for anyone interested in how a simple processor could be implemented. That said, I think it's cool.

This is of course a work in progress.

• 16 bit address and databuses
• 16 bit opcodes
• Byte and word size memory accesses, with signed/unsigned extension on byte reads
  • Bus error signal on unaligned word transfers
• Some opcodes (like LOADI, JUMPs, BRANCHes, ALUMI, CALLs) have one following immediate value/address
• 8 x 16 bit general purpose registers
• 16 bit Program Counter
• Load an immediate 16 bit quantity at the following address
• Load and store instructions operate either through a register, an immediate address or a register with an immediate displacement
• Clear instruction
• Simple status bits: zero, negative, carry
• ALU operations including
  • add, add with carry, subtract, subtract with carry, signed and unsigned 8 bit to 16 bit multiply, increment, decrement, and, or, xor, not, shift left, shift right, copy, negation, etc
• ALU operations are of the form DEST <= DEST op OPERAND, or DEST <= op DEST
  • ALUMI operates with an immediate operand, eg. add r0,#123
• Conditional and uncoditional jumps and branches: always, on each flag set or clear with don't cares
• Nop and Halt instructions
• Stacking: call/return and push and pop
• No microcode: a coded state machine is used
• Most instructions take 3 cycles
• CustomASM (https://github.com/hlorenzi/customasm) is the current assembler

• Interrupts, including software traps
• Testbench for the controller
• Add more instructions!
  • Relative addressing on loads and stores with the PC
  • (Better) multiply and divide?
  • Barrel shifter?
  • Restricting ALU ops to byte wide values might be useful
  • ....
• Better status bits: not currently settable via an opcode, nor are they changed on anything other then an ALU instruction
  • This unfortuantely includes the LOADRD and STORED opcodes, which is confusing and wrong
• It should be possible to do a build without multiply support, as very small FPGAs will not have sufficent resources

The currently used CustomASM CPU definition makes it possible to write very presentable assembly by, for example, combing LOADI, LOADM, LOADR and LOADRD into a single "load" mnemonic with the width represented by .w, .bu or .bs. ALU operations are similarly represented.

; prints the messsge in r2 at row r0 coloumn r1

printmsg:       shiftleft r0                    ; word wide address so shift
                load.w r0,(rowoffsets,r0)       ; get the start of the row
                add r0,r1                       ; add the column
.loop:          load.bu r1,(r2)                 ; get the char
                test r1                         ; checking for null
                branchz printmsgo               ; done?
                store.b (r0),r1                 ; output the char
                inc r2                          ; move to next source char
                inc r0                          ; move to next video addr
                branch .loop                    ; get more
printmsgo:      return                          ; done

; polls the ps2 port for a byte, returning 0 in r0 if nothing is available

getps2byte:     load.bu r0,PS2_STATUS           ; get from the status reg
                test r0                         ; nothing?
                branchz .nothing                ; keep waiting yet....
                load.bu r0,PS2_SCANCODE         ; get the scancode
                compare r0,#0xf0                ; break?
                branchz .nothing                ; no, carry on
                store.w SEVENSEG,r0             ; display it for debug
                return                          ; done
.nothing:       clear r0                        ; return 0
                return                          ; done