(From this old-school but contemporary page-of-links which is full of fascinating material - here's a quick description of the PDP-8 (pdf))

Three CPUs built with minimal hardware and therefore needing very small instruction sets:

Open 7400 Logic Competition: The BrainF* Machine by Alexis Bezverkhyy
This one is new to me: it has 10 instructions and is built to run assembled BrainF* programs. Just 17 chips, all 74-series apart from the UART, runs at 2MHz. Can print an ASCII Mandlebrot in a couple of minutes. Source package includes Life and Mandlebrot programs. You'll see the latter was written in a C-like macro language.
There's also a pointer to a C to BrainF* compiler.



From there, a link to PISC by Bradford J. Rodriguez
A Minimal TTL Processor for Architecture Exploration
uses 22 74-series chips including the useful but possibly hard to find '181 ALU and '172 register file.


Finally, Tiny CPU in a CPLD, by Steve Chamberlin, with a minimized 6502-like instruction set
http://www.bigmessowires.com/cpu-in-a-cpld/, also 2010/04/18/tiny-cpu-architecture


Interesting technology note on the 12-bit PDP-8:

Thanks, Ed. Here is a little MISC of my own. Six chips! Not merely a design exercise, this device added functionality to my customer's printing presses.
-- Jeff

It's a beaut! Feels like you could control a mechanical Turing Machine with this, so I think that makes it a fully qualified computer!

I'd be tempted to hook up an "Activity" LED to Q7.

I do like the subroutine mechanism - reminiscent of the one used by Sinclair in their scientific calculator. I was pleased to have speculated that they'd done what they had in fact done - so that's at least three of us who had the same thought there.

What was your approach to building the assembler?

The assembler was unremarkable -- written in Forth, but it was just a hasty hack. I had no incentive to make it fancy, as the Printing Press program was the only thing I ever assembled! This CPU was "one-application" as well as "one-bit"!

There are lots of comments here on Hackaday. A few folks thought this machine would be a brain-twister to program, but in fact it's mostly quite straight-forward. The assembler takes successive source lines and, by default, outputs the corresponding binary instructions to successive addresses, so things are not as helter-skelter as they may seem. You can ignore the fact every instruction is in fact a two-way branch.

I was completely caught off guard by how much attention this project got! Reddit and Hacker News also picked it up; in addition, there were dozens of tweets and retweets, and someone even translated my page into Spanish and reposted it. These ultra-simple CPUs really seem to intrigue and inspire people. Thanks for the new topic, Ed.

-- Jeff

ps- see also the Wikipedia article, One instruction set computer.

Thanks for those extra pointers Jeff.

I'm going to indulge myself slightly and present Atari's vector drawing engine as found in the Asteroids video game - it's a very simple 6502 system, with simple timer-based sound generation, but it has an interesting coprocessor to drive the vector graphics to the monochrome XY tube. And that coprocessor is in TTL. It has drawing instructions and a subroutine mechanism, but isn't a general-purpose CPU. I think it's interesting anyway.

The primary source is the schematic, found here (pdf) but the relevant parts have been marshalled by Jed Margolin here (pdf). Much more accessible is a document here (pdf) written by Phil Pemberton. He says:




The PC and stack are implemented with three 74LS670 register files and an up/down counter.



The coprocessor shares RAM and ROM with the 6502, with the CPU having priority. (The CPU also has private ROM and RAM. There's a hardware trick whereby pages 2 and 3 can be swapped, which allows the two sets of state for a two-player game to be accessed without indirection.)

Quick pointer to a related discussion over on 6502.org:
http://forum.6502.org/viewtopic.php?p=18115#p18115
where the question is


and among the answers, we have 8BIT:


and Arlet:

Edit: MCPU is by Tim Böscke, and is now found at https://github.com/cpldcpu/MCPU - it even fits in a 9536.

and Dajgoro reports some progress:


and MichaelM works on a serial ALU:

source posted at https://github.com/MorrisMA/MiniCPU-S

MichaelM has another contribution too:


Finally, Arlet says


Finally finally, for lowdown on efficient implementations on FPGA, there's a recommendation to read Creating Embedded Microcontrollers
(Programmable State Machines) by Ken Chapman: pdf here.

On the subject of MISC, and explorations on small CPUs and Forth-like machines, see Ken Boak's new blog at
https://nanode0000.wordpress.com/2017/0 ... -machines/

Another mention needed of Ken Boak's blog, I think. He's developed a tiny Forth-like language called SIMPL which he can then use to explore CPU architectures by emulation. Here are his recent posts:

Making it Minimal – MISC Machines
Exploring the J1 Instruction Set and Architecture using SIMPL
An EDSAC Simulator using SIMPL
The 1949 EDSAC Instruction Set and Architecture
Using SIMPL as a tool to bootstrap unusual processors
Emulating Simple CPUs Using Arduino

Ed,

Thanks for the shout out regarding my blog - much appreciated.

SIMPL is not much more than a case statement running within a loop - and was inspired by Ward Cunningham's Txtzyme https://github.com/WardCunningham/Txtzyme

It decodes single ascii characters within the case statement , and this allows several unique operations to be performed just by typing a character at the serial terminal.

Txtzyme was limited to just 13 operations, such as setting a port pin, taking an ADC reading, printing an integer number or a text string and running loops. I quickly realised that I could extend the instruction set and make it a lot more useful.

It has been implemented on Arduino (AVR), MSP430 and ARM.

It occurred to me that the character decode could be used as the basis of simulating a CPU, and one of my first attempts was James Bowmans J1 Forth CPU.

There is a strong resemblance between his verilog code for the instruction decoder, and my instruction decoding case statements - which is now fairly obvious, now that I am embarking on verilog programming.

Whilst James's J1a design does not quite qualify as a OPC design - I find his verilog style very clear, which as a beginner, I find important.

https://github.com/jamesbowman/swapfort ... rilog/j1.v

James went on to implement the J1a on a Lattice ICE 40 - with 1K logic elements - and there's a youtube of him demonstrating this.

Recently I have been involved with a mate in producing a low cost FPGA board, BlackIce - which also is an ICE 40 - but "4K" logic elements.

I put this in quotes, because it's actually an 8K die - and it's only Lattice's proprietary programming software that knobbles half of the chip.

When programmed with Clifford Wolf's IceStorm open source tool chain - it literally blossoms into a fully functioning 8K device.

I'm looking forward to contributing to the OPC project - even if my contribution is in the form of open source FPGA dev boards

regards



Ken

Great to see you here Ken. BlackIce looks very attractive, with the fast 16 bit wide SRAM. (And getting double the FPGA capacity is a win too.)

At the beginning of this year I was mainly looking for dev boards with 32 bit wide memory, but since the OPC idea took off, 16 bits seems just right! (In fact, it even turned out that running OPC6 with a bytewide memory and a tiny code cache works pretty well - it's 16 bits on the inside, 8 bits on the outside.)

Word-addressed machines appeal to me at present - they are simpler than byte-addressable, naturally have a bandwidth advantage over machines with only byte-wide memory, and while they might lose out a little when working on byte-sized data such as strings or opcodes in some interpreted language, they should win when handling pointers or integers or floats. Also they have some historical interest - before bytes were invented, words were all there was.

So, EDSAC, J1, and OPC all seem to be in the same space, in that way at least.

And, a word-wide opcode has plenty of bits to make instruction decoding simpler.

Hi Ed,

When my friend Alan Wood and I specified the BlackIce design, I was influenced by James's J1 - and word addressing appeared the obvious choice. The word-wide 10nS SRAM was only a couple of dollars, so it seemed sensible to include it on the back of the pcb - very closely coupled to the FPGA.

Whilst there are about 50 of the myStorm boards in circulation - I don't think anyone has used the SRAM in earnest yet.

There have been a few designs, notably those of Chuck Moore, that pack several 4 or 5 bit opcodes into a 16-bit word and execute them in sequence. This creates a pseudo-pipeline which speeds up the throughput, but also allows the use of slower RAMs.

Matthias Koch of MeCrisp Forth has got the J1 running on the myStorm board - and a version of MeCrisp that runs on the ARM cpu.

My ultimate aim was to understand which instructions are essential for an interpreter like SIMPL, and try to implement these efficiently. So I coded SIMPL up in very crude MSP430 assembly language - so I have a feel for what is needed to implement it - at least on a 16-bit harvard cpu with a reasonable amount of registers. As it happens I only use about 6 registers. However there's quite a lot of transferring data between those 6 registers - and so a hybrid machine that has both a stack architecture but allows efficient register to register instructions might be an advantage.

On OCP 6 I like the means of being able to modify the registers by a short integer - including the PC which gives short jumps. I'd be tempted to extend this idea to allow an 8-bit "payload" - so that efficient jump tables can be created, and an instruction like DJNZ would also be useful for implementing efficient loops.

A register file in on chip RAM could be used to create a parameter stack, for a true stack machine - but as SIMPL generally only uses 2 operands, even a full stack is possibly somewhat redundant.

I'll try to come up with a proper description of SIMPL to share with the forum. I've tried several times to describe it, but it's constantly evolving, and finding new applications. I've added a summary below, but the full code (MSP430 ASM) is on github

https://github.com/monsonite/SIMPL/blob ... asm_15.asm

I think that it's best to think of it as a toolkit to help exercise experimental hardware, with an instruction set that is highly mnemonic - so that you can virtually write directly in the machine language of the processor - and still read the code.

;-------------------------------------------------------------------------------
; SIMPL - a very small Forth Inspired Extensible Language
; Implementing the Initialisation, TextTead, TextEval and UART routines in MSP430 assembly language
;
; A Forth-Like Language in under 1024 bytes

; Ken Boak May June 2017

; Loops, I/O, Strings and Delays added
; Jump table reduced by 36 entries (72 bytes)
; times_32 subroutine further reduces codesize


; This version 860 bytes 9600 baud communications with 1MHz DCO

; Input and output to port P2 of Launchpad added with "i" and "o" commands

; SIMPL_430ASM_16

; Primitive Instructions - all have a fairly mnemonic ascii character that is the machine instruction!

; These allow basic maths an logical instructions on 16-bit integers + - / * & | ^ ~
; Stack Manipulation DUP DROP PUSH POP SWAP OVER " ' , . $ %
; Memory transfers with FETCH and STORE @ !
; Compilation mode with : and ;
; Simple decrementing loops (..........)
; Input and Output
; Print a string _Hello World_

; Note as of 13/06-2017 - not all of these are fully implemented


; ADD +
; SUB -
; SHR /
; SHL *
; AND &
; OR |
; XOR ^
; INV ~
; DUP “
; DROP `
; PUSH ,
; POP ‘
; SWAP $
; OVER %
; FETCH @
; STORE !
; CALL :
; RETURN ;
; JMP \
; JE =
; JGT >
; JLT <
; TO-R {
; FROM-R }
; LOOP-Strt (
; LOOP-End )
; IN [
; OUT ]
; KEY ?
; PRINT _
; NOP Space
; LIT #


; Lower case letters are used for more complex commands

;a
;b
;c
;d
;e
;f
;g
;h set port pin high
;i input byte from port
;j
;k access the loop counter variable
;l set port pin low
;m milliseconds delay
;n
;o output byte to port
;p print the to of stack to terminal
;q print the ascii character at given RAM location
;r read input pin
;s sample the ADC
;t
;u microseconds delay
;v
;w
;x
;y
;z


; Upper case letters are used to define Users "words"

; User Routines are defined by capital letters starting with colon : and end with semicolon ;

; eg :F10(100mh200ml); ; Flash the led 10 times - high for 100mS and low for 200mS

; You can play sequences of notes through a small speaker ABC etc

; :A40{h1106ul1106u); musical note A
; :B5{h986ul986u); musical note B
; :C51{h929ul929u); musical note C
; 57{h825ul825u); musical note D
; :E64{h733ul733u); musical note E
; :F72{h690ul691u); musical note F
; :G81{h613ul613u); musical note G
; :H_Hello World, and welcome to SIMPL_; A Banner Message

;A
;B
;C
;D
;E
;F
;G
;H
;I
;J
;L
;M
;N
;O
;P
;Q
;R
;S
;T
;U
;V
;W
;X
;Y
;Z



; Examples of SIMPL phrases

; eg add 123 and 456 and print the result to the terminal

; 123 456+p

; Loop 10 times printing "Spurs are Fab!"

; 10(_Spurs are Fab!_)

; Flash a LED 10 times 100mS on 200mS off

; 10(h100ml200m)


; Toggle a port pin at 1MHz 1000(hlhlhlhlhlhlhlhlhlhl)

; That's all folks!
;-------------------------------------------------------------------------------

monsonite, you can put [code] and [/code] around your code to make the forum software preserve your white space and make the section monospaced. Then you can get for example:



It also won't try to translate character combinations into emojis like it did in your line

; 57{h825ul825u); musical note D

Instead, you'll get

The inc and dec commands were fairly late additions to the OPC6 - it's certainly tempting to put short constants into the instruction word, but of course it makes decode a bit more difficult. In fact I think we can see a slight gradual decline in the speed of the machine as we added features and the logic became more complex. It's also true for a one-page machine that the code becomes increasingly dense - hopefully still not yet to the point of being obfuscated.

It's an interesting practical question though, what a multi-way branch would look like with the present machine, and how it might be improved if that seemed like a good idea.

It's also interesting though that the machine was an adequate computer - Turing complete - from the outset. In a sense, everything we've added has been unnecessary, but shifting the tradeoff away from machine simplicity and towards higher performance and better code density.

An 8 bit MISC implemented in a XC9536XL CPLD, for a data acquisition application.

http://archive.cmb.ac.lk:8080/research/bitstream/70130/3253/1/2005paper10.pdf
https://pdfs.semanticscholar.org/9a03/79457eba00ff564b02fe2be15bb84bd70c02.pdf

The CPU has only three instructions:-

And the short application code is inside the CPLD as well:-

And takes advantage of the JTAG boundary scan support available in the XC9536XL for transferring data to a PC:-

That's so minimal! Their instruction set contains 3 instructions, as does their program in ROM. (The already-small CPU has been cut down so much, it's become a fancy implementation of a finite state machine.)

But the reference to

could be very interesting. Here's a version of the paper
MCPU - A Minimal 8Bit CPU in a 32 Macrocell CPLD by Tim Böscke (2001, revised 2004)
as found in the repository
https://github.com/cpldcpu/MCPU
which links to a minimal emulator and compiler for the machine:
https://jeelabs.org/2017/11/tfoc---a-minimal-computer/