A byte-wide stripped-down version of the YGREC16 architecture

Similar projects worth following
#YGREC16 is getting pretty large and moving away from the original #AMBAP inspiration, making it less likely to be implemented within my lifetime. So here is a "back to minimalism" version with
* 256 bytes of DRAM (plus one parity)
* 8 byte-wide registers
* less relays than the YGREC16
and that's pretty much it. So I give up on the idea of playing the Game of Life. Is Tetris still possible ?

A significant reduction of the register set's size is required so I/O must be managed differently, not through the register set (instruction or RAM-mapped, to be determined). The register map is expected to be:

  • D1  <= for NOP
  • A1
  • D2
  • A2
  • R1
  • R2
  • R3
  • PC  <= for INV

I shrunk the instruction word down to 16 bits. It is still reminiscent of the YGREC16 older brother but I had to make clear cuts... The YGREC8 is a 1R1W machine (like x86) instead of the RISCy YGREC16, to remove one field.

I have swapped the condition field and the ALU code field, which is now a more classical opcode.

There are two instruction forms : either an IMM8 field, or a source & condition field, followed by the src/dest field and a small opcode. The source field can also become a short immediate field (3 bits only but essential for conditional short jumps or increments/decrements).

The opcode field has 4 bits and the following values:

Logic group :

  • OR  => Reg OR Reg does not change Reg
  • AND
  • XOR
  • ANDN

Arithmetic group:

  • ADD
  • SUB
  • CMPU
  • CMPS

Shift group:

  • SHL
  • SHR
  • SAR
  • ROL (might be removed)
  • ROR (might get axed too)

Control group:

The COND field has 4 bits, more than YGREC16, so we can add more direct binary input signals. CALL is moved to the opcodes so one more code is available.  All conditions can be negated so we have :

  • Always
  • Z (Zero, all bits cleared)
  • C (Carry)
  • S  (Sign, MSB)
  • B0, B1, B2, B3 (input signals)

Instruction code 0000h should map to NOP, and the NEVER condition.

Instruction code FFFFh should map to INV, which traps or reboots the CPU : condition is implicitly ALWAYS because it's a IMM8 format : MOV FFh PC (thus rebooting/alerting with some code placed there, if any, otherwise keep instruction at FFh equal to INV to make an endless loop)

Overall, it's  still orthogonal and very simple to decode, despite the added complexity of dealing with 1R1W code.

1. Honey, I forgot the MOV

  • Honey, I forgot the MOV

    Yann Guidon / YGDES09/29/2017 at 02:54 0 comments

    Oh well I'm soooooo used to the RISC way that the opcode map didn't even include a MOV instruction. I have retrained my brain to avoid idiosyncrasies from 1R1W/CISC/accumulator architectures and now I have to redesign the opcode map.

View project log

Enjoy this project?



Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates