Back to BASICS

In March of 2017, I began to follow a project on Hackaday.io for a microcomputer constructed entirely out of common TTL integrated circuits.  TTL stands for transistor-transistor logic, and appeared first in the very late 1960s.  Several of the iconic minicomputers of the early 1970s were constructed from TTL integrated circuits – including the Data General Nova and the DEC PDP-11. Remarkably the descendants of this family of logic devices are still available today, using modern high speed CMOS process so that they are much faster yet consume a lot less power.  In real terms they are also a lot cheaper than they were –  with typical devices costing between $0.50 and $1.00.

The Gigatron TTL Microcomputer has evolved from the breadboard computer featured in Hackaday.  It was released as a DIY soldering kit last March and could play simple video games – typical of the late 1970s and early 1980s.  It has 64 colour graphics and sound similar to the Acorn Electron or Sinclair Spectrum which appeared at that time. However, all of these features are done completely without a microprocessor – all of the control logic, arithmetic and input – output is done using readily available TTL chips.

Gigatron uses just 35 TTL chips – and these ate simple logic functions such as counters, multiplexers, decoders, registers and adders. There is nothing used here that would not have been available back in 1975.  However Gigatron does take advantage of decades of memory evolution, and uses modern ROM and RAM chips- which would have been very expensive – but now available for just a couple of dollars each.

Gigatron produces a 64 colour video signal that can be displayed on any  VGA compatible monitor.

The Gigatron kit contains all the components you need to make a fully fledged computer – and sells for under $200.  Full details are available on the gigatron.io website. There is a User forum – linked from the Gigatron website.

In the last year,  the Gigatron has benefited from both hardware and software upgrades. Today I received by post the new V3 ROM which includes a BASIC interpreter and a small adaptor pcb, which allows you to use a PS/2 keyboard with the Gigatron.

Writing in BASIC takes me back about 40 years to when I first encountered microcomputers at high-school.  It’s an easy language to learn and opens up the architecture of the Gigatron for further exploration.

Whilst relatively simple in hardware terms, there is considerable sophistication in the software which allows it to perform the colour graphics and sound. Fundamentally it is an 8-bit Harvard architecture, executing native machine language out of ROM, but on top of this is built a 16-bit Von Neuman virtual machine – which executes code out of RAM – whilst seamlessly taking care of all of the critical video timings.

The virtual cpu – or vCPU has just 34 core instructions which allow 16-bit operations to be performed.  These operations execute in typically 14 to 28 clock cycles (6.25MHz clock) – but nevertheless are still about 5 times the performance of a 6502 or Z80 – which were the usual choice of microprocessor in the late 1970s and early 1980s.  Indeed the Gigatron is even faster than the first IBM PC of 1981 – although it cannot address as much memory.

There is scope to increase the clock speed of the Gigatron possibly to 16 or 20MHz- and I am currently doing some experimentation  – which will become the subject of a future post.

I am also intrigued with the possibility of developing a Forth-like language based on the 34 instructions of the vCPU. Like the old days of BASIC – the interpreted language would be self-hosted on the Gigatron – and not rely on modern PCs, python or sophisticated tools for its development.

 

 

 

 

 

 

 

 

Advertisements
Posted in Uncategorized | Leave a comment

When all you have is a hammer…….

Last weekend I attended a retro-computing fair at the Centre of Computing History in Cambridge.  This was my first visit to this popuar museum and I was impressed by the range of exhibits that they had on show.

35 years ago – Cambridge was buzzing with computer activity – and it was home to at least two of the prominent home computer companies in the early 1980s – Acorn and Sinclair.  Machines of this era were on prominent display throughout the museum.

I got my first computer around this same time – a ZX81 which I built up from a kit – following a price reduction – in the Spring of 1983, the ZX81 was very much being superseded by more sophisticated hardware such as the Spectrum, the BBC Micro and a plethora of other 8-bit machines.  It cost me £39.99, at a time when £40 was a week’s wage in a summer job, to a sixth former.  I still have it – or most of it, a surviving keepsake, when many other bits of more sophisticated electronic hardware have long since been junked.

When all you have is a Z80 – everything needs to be solved with Z80 code……….

The early 1980s machines were relatively unsophisticated and we learned how to get the most out of them with clever coding and a bit of ingenuity.   Slowly the IBM PC and it’s clones became the dominant machine in the office, and computing changed forever.

In the early 1990s, my job involved designing pcbs using ORCAD.  For Autumn 1990 to Spring 1991, I pushed tracks around the screen using a ‘286 machine clocked at 25 or 33MHz.  I don’t remember the job being particularly arduous or slow – but then we barely had Windows – and the PCs would really only run a single application at a time. There was no Internet, no distractions and no social media interrupting your thought processes every 20 seconds.

Now we are surrounded by microcontrollers of all sizes, and electronic hardware has never been cheaper – our daily lives revolve around staring into LCD screens – both big and small – we have become addicted to checking our phones and our social media apps – in the hope that something interesting is happening elsewhere.

But I digress….. I’m here to write about a revolution in open source hardware.

Last year, Alan Wood and I, designed an FPGA dev board around the Lattice ICE40 device.  This was our first venture into open source FPGA hardware – very much triggered by Clifford Wolf’s open source FPGA toolchain “Project IceStorm”.

We put together the combination of a low cost ARM microcontroller and an easily programmable FPGA.  We wanted to create a platform that was interesting from a hardware perspective  and one that could readily be expanded. And so “BlackIce” was created.

Returning to the retro-computing fair,  I was fortunate enough to be able to demonstrate some retro machines, created by community member David Banks running on our BlackIce hardware.

The following designs are now available from David’s github repository:

  1. Acorn Atom (6502)
    https://github.com/hoglet67/Ice40Atom3
  2. BBC Micro Model B (6502) with BBC BASIC
    https://github.com/hoglet67/Ice40Beeb2
  3. Jupiter ACE (Z80A with FORTH)
    https://github.com/hoglet67/Ice40JupiterAce1
  4. CP/M Platform – Z80A with either serial terminal connection or colour VGA /PS/2 Keyboard
    https://github.com/hoglet67/Ice40CPMZ802

David has included binary files for each of these designs that need to be programmed into the STM32L433 using DFU-UTIL. These binary files contain the ROM data and make the design file “sticky” – i.e. resident in the STM32 flash – so on power on the FPGA boots to whichever retro computer you have chosen.

For each of these designs you will need a Digilent VGA pmod (£8.99 from Farnellhttp://uk.farnell.com/digilent/410-345/pmod-board-video-graphics-array/dp/27681896)

atom3

Connecting VGA and PS/2 Keyboard using standard Digilent pmods

This plugs into Pmods 7/8 and 9/10.

You will also need a PS/2 keyboard – which requires a trivial adaptor (4 resistors) plugged into Pmod 11/12 or can be bought from Digilent here:

http://www.mouser.co.uk/ProductDetail/Digilent/410-094/?qs=sGAEpiMZZMsF1ODjcwEocGEoetGlDts14V4qfo%2fFYIE%3d3

You will see from the datasheet for the PS/2 connector – that it is a very simple circuit.

Below is our display at the Centre for Computing History – with the BlackIce board hosting a BBC B running a sphere demo in BBC basic.BBC_retro_sphere

 

 

 

 

 

 

 

Posted in Uncategorized | Leave a comment

Arduino meets open FPGA

sdr

BlackIce Open FPGA – Includes an 80MHz “Arduino”

Arduino is the Marmite of embedded programming – you either love it or hate it.

Regardless of how you feel about it – Arduino in the last 12 years probably has introduced more people to embedded programming of microcontrollers than any other organisation. What started with the humble AVR ATmega8 in 2005 has grown to include a multitude of different microcontrollers. and devices.

Initially the Arduino IDE handled only Atmel AVR microcontrollers – but with the addition of the Arduino Due board, it has opened up to include ARM devices – including parts by Atmel and ST Microelectronics.  To allow this to work the GCC toolchain for ARM has been integrated into the Arduino IDE along with the necessary “board files” and hooks to the various programmer devices.

In late August I noted that the STM32L4 parts had been brought into the fold – by way of the “Butterfly” boards which use the STM32L433.  This is the same microcontroller that we use on the current generation of myStrom BlackIce FPGA boards – and to have this part readily programmable from within the Arduino ecosystem will open up a whole new set of possibilities for the BlackIce board.

The STM32L433 brief specification:

64 pin low power ARM M4 Cortex microcontroller
256Kbytes of flash memory, 64Kbytes of SRAM
80MHz clock
USB 2.0 Full speed interface
11 timers
Capacitive touch interface
12 bit 5 MSPs ADC
2 x 12 bit DACs
SPI and Quad SPI
I2C

The full datasheet

Whilst my initial efforts in late August allowed me to program the STM32L433 from within the Arduino IDE using the “Butterfly” board file, it was going to take further work to create a custom board file for our BlackIce pcb.

Following on from the Hebden Bridge “Wuthering Bytes” festival in early September, our programmer friend Richard Miller has now created the necessary board file and Arduino platform support for BlackIce – and so all of the peripheral features and GPIO are now accessible via Arduino library functions.

Instructions for configuring the Arduino IDE and more details of the accessible GPIO signals are included on Richard’s Github repository.

This framework includes the DFU-UTIL program – which allows you to bootload the STM32 from within the Arduino IDE. Here are a few helpful hints:

  1. First remove the programming jumper from pins 14 and 16 of the Pi connector
  2. Plug the USB cable into the centre microUSB connector
  3. Always press the reset switch before you recompile and program.
  4. Replace the jumper if you want the code to be permanent
  5. If you want to access the UART – use “Serial1.xxx” in any functions that use the Serial code.

It was not long before I had Blink running, so I decided to load my old favourite – SIMPL. This is a small interactive toolkit that allows you to exercise the hardware via a series of serial commands. You can read about it and find the code on my Github repository .

All appeared to work and soon I had the STM32L433 executing my interactive code.

Finally, as the STM32 is cocked at 80MHz – which is 5 times faster than the standard Arduino, plus it is a 32 bit processor rather than an 8-bit device, out of curiosity, I decided to run the standard dhrystone benchmark test to see how it compares to the regular 16MHz Arduino.

The results were interesting, clearly showing that the 32 bit ARM architecture scores over the 8-bit AVR:

Arduino Uno

Microseconds for one run through Dhrystone: 78.67
Dhrystones per Second: 12711.22
VAX MIPS rating = 7.23

BlackIce:

Microseconds for one run through Dhrystone: 8.94
Dhrystones per Second: 111854.70
VAX MIPS rating = 63.66

So on the Dhrystone benchmark – BlackIce is about 8.8 times faster than the regular Arduino R3.

Arduino GPIO Headers

One of the features of BlackIce is that most of the spare GPIO signals from the STM32L433 microcontroller have been brought to Arduino-style female headers.  These allow connection to the analogue ADC, PWM, UART, SPI and I2C lines.  All apart from the six ADC inputs are 5V tolerant. For simple extensions to the BlackIce board – Arduino style shields may be fitted – but preferable if they are of the 3V3 type to avoid 5V reaching the FPGA pins and potentially causing damage.

Serial Terminal connection

BlackIce has a UART to USB converter IC which appears as a CH340 COM port.  It is available on the micro USB connector closest to the bottom left corner of the pcb.  This may be utilised from within Arduino provided that it is referenced as “Serial1”

STM32 – FPGA Interface

The STM32L433 shares a total of 20 signal lines with the ICE40 FPGA.  Some are used to provide the FPGA configuration interface (for FPGA programming) but may be re-used at runtime.

The signals are arranged into the following groups.

SPI Interface:    MOSI, MISO, SCLK, SS

Quad SPI Interface:  QD0,  QD1, QD2, QD3, QCS and QCK

GPIO Interface:    Dig 16, Dig 17,  Dig 18, Dig 19 (Slide switches)  B1, B2 (Buttons)

UART Interface:   TX , RX

Misc Controls:      RESET, DONE

All of these with the exception of RESET and DONE appear on the FPGA as GPIO and may be repurposed as required.

Posted in Uncategorized | Leave a comment

Splitting the Atom

It’s not everyday that you meet someone with the talent and tenacity of Dave Banks (@hoglet67 on Twitter).  In less than three days, Dave ported his FPGA based Acorn Atom from Xilinx and VHDL across to Lattice ICE40 and verilog. The result is a fully functioning Acorn Atom – running on our latest open source FPGA board, BlackIce.

The Atom was a forerunner of the Acorn Electron and the BBC Micro. It used a 6502 microprocessor an provided a chunky colour display – which was virtually unknown back in 1980 when the Atom first appeared.

On Friday, Dave emailed me to say that he was going to begin to port his Atom design to the BlackIce board – and was looking at the VGA implementation using the recreated Motorola 6847 graphics controller as used in the Atom. However, the 6847 module was written in VHDL and would have to be ported to verilog first – so that it could take advantage of the open source “IceStorm” FPGA toolcain.

Then without warning, on Saturday evening the following two images appeared:

custom_vga

With the help of a few carefully chosen resistors and a hacked VGA cable, Dave had fashioned a VGA output – driving the resistor arrays direct from the FPGA pins. The result was the characteristic Atom “pre-boot” screen – when the video RAM is full of random data.

atom_1

Within a couple of hours, Dave had achieved the boot screen, connected a PS/2 keyboard and written “Hello World” in Acorn BASIC.

To any casual observer – all of this happened within the short space of Saturday afternoon.

atom_hello_word

BlackIce_PS2

By late Saturday night – and a few tweets on my part – interest was gaining rapidly – and eagerly awaiting part 2 of Dave’s installments.

atom_sch

Dave put up an original Atom schematic – to illustrate the extent of the digital logic that had been implemented within the ICE40 FPGA – and by Sunday evening we faced some Alien Invaders – a port of the famous “Galaxians” game:

galaxians_1s

 

galaxians_2

It was now Sunday evening and Dave mentioned that he had work out a way to get ROM data into the large external SRAM (256K words) that is closely coupled to the FPGA.  This involved some neat coding tricks – and taking advantage of the flexibility of the BlackIce loading mechanism.

Dave’s progress was soon appreciated by the “stardot” forum – a group devoted  to Acorn retro computers – and very soon, a fellow forum member, Ed Brindley, had implemented a similar Atom – using the BlackIce board and some Digilent pmods  – for the VGA and keyboard.

atom3

atom4

This all looks like excellent progress – but Dave was like a dog with a bone – he had to solve the issue of using the microSD socket on the underside of the BlackIce board to allow a full repertoire of Atom software to be loaded via SD card.

This latest triumph appeared on Tuesday morning – just 3 days after commencing this mammoth project.

Dave’s write-up of this project appears on the myStorm forum with full technical details – which you may find here

Atom7

Atom6

Atom5

Thanks to Dave for his tireless work in making this happen in such a short space of time.

BackIce will be featuring at @WutheringBytes in Hebden Bridge between September 1st and 10th.

Throughout the week we have talks, workshop sessions and general FPGA geekery goodness.

If you’d like to obtain a BlackIce open source FPGA board – please follow this link – or contact me at ken dot boak at gmail dot com

Ken.

Posted in Uncategorized | Leave a comment

A Minimum Interactive Language Toolkit

In previous posts I began to describe a minimum interactive language toolkit which could work standalone in virtually any small microcontroller. Here are the following prerequisites I stated in the previous post:

  1.  Interactive – commands may be typed at the keyboard for immediate execution
  2.  Commands can be combined into programs then compiled for later execution
  3.  Extensible – from a small kernel of commands, a whole application can be built
  4.  No external tools required other than a serial terminal – all tools run on chip.

This may appear to be a huge break from conventional wisdom, as virtually all embedded microcontroller development is done in high level C – compiled using a package of tools hosted on a more powerful machine – such as laptop.

Microcontrollers have evolved to have a fairly large proportion of their memory as flash-ROM, and modest quantities of  RAM – so it’s not unusual to find a micro with 32K bytes of flash but only 2k bytes of RAM. Whilst this partition of memory resources is not ideal for interactive languages (more RAM would be nice) – it’s enough to get started.

In the early days of microprocessors – it was commonplace to have a “Monitor” program – which consisted of a few simple commands to allow hexadecimal opcodes to be entered directly into memory and then executed from a given address. Some of these monitor programs also allowed a hex-dump to be sent to a terminal, to examine the contents of memory, plus primitive editing commands.

Typically the monitor would take a few hundred bytes of ROM, but it provided the absolute basics of being able to write machine code. Assemblers seldom existed, given the meager resources of the early home computers, and so a lot of coding was done by hand assembly – using pencil and paper – or by copying hexadecimal listings out of magazines.

What I am proposing here is a program that offers the same low level support as a monitor, but rather than programming in raw Hex or machine language, the User has access to a small instruction set of highly mnemonic commands.  These are executed out of memory by a  generic virtual machine, hosted on the MSP430 microcontroller.

This can be coded in about 562 bytes of assembly language, of which 128 bytes are a 64 entry look-up table. The MSP430 generally dos not have a good code density with an average of around 2.95 bytes being required for each instruction.

The mechanics of this virtual machine are as follows:

  1. Take in a string of serial characters and place in a buffer until the newline character is detected.
  2. Parse through the characters one at a time creating a jump address into a look-up table based on the ascii value of the character.
  3. Numerical character strings are handled by the number routine, forming them into a 16-bit integer which is placed on the stack.
  4. All other characters cause program flow to jump to a table-selected address from where code is executed. Numerical parameters may be used from the stack.
  5. Where appropriate putchar is used to provide serial output of numbers and strings
  6. Jump back to the parser in (1).

The prototype has been coded up in MSP430 assembly language – and is available at the following github repository.

A More Efficient Instruction Set?

Most MSP430 instructions are two bytes,  but moving byte or word constants into registers, byte comparisons and byte subtractions require a further two bytes to hold the constant.  Calls also require the second pair of bytes to hold the call address.

As much of the interpreter is based on the testing and handling of characters and the manipulation of ascii values – it would appear prudent to have a class of instruction that could efficiently handle 8-bit values.  This could be done by allowing an 8-bit immediate value to be coded into the instruction, with a 4-bit field for the source/destination register and a 4 bit instruction.

This becomes a balancing act between a processor that can efficiently handle 16-bit maths operations via registers and still efficiently handle 8-bit immediates. It becomes quite a challenge to shoe-horn this into a 16-bit instruction wordlength, but it’s no different to the challenge that the 8-bit ISA designers had when the immediate was the byte following the opcode.

Last year I reviewed the 8080/Z80 common instruction set based on how they were decoded – and I produced the following image.  Whilst the 8080 and Z80 were 8-bit micros, they did have a small capability to handle 16-bit numbers by way of their register pairs plus a very few 16-bit instructions.  perhaps there could be some inspiration from the 8080 instruction set – for a processor that could handle 8-bit immediates and short jumps – whilst being predominantly a 16-bit machine.

z80_octal_3

When expressed in octal – and a bit of colour added  – it’s clear to see how the instructions were grouped with the most significant 2 bits defining the class, the next 3 bits defining the operation, and the bottom 3 bits defining the operand(s). It’s a clever bit of encoding – that ensured that almost all of the 256 opcodes did something useful.

If we take the top two bits to define the instruction Group – a very rough description is as follow – where only Group 01 and 10 are entirely regular and defined by the bit fields. Groups 00 and 11 need further decoding to derive their classification.

00  xxx   yyy     – INC, DEC, double ADD, relative jumps etc

01  DST   SRC     – regular source to destination register moves

10  ALU  SRC    – register-accumulator ALU operations ADD ADC SUB SBC AND XOR OR CMP

11  FLG  JMP    – conditional CALL, RET, JMP operations

With Groups 00 and 11 being a bit of a mash-up — it might be possible to re-hash them into something a bit more logical.

A Hybrid CPU.  – Neither Fish- Nor Fowl

The 8080 was based on a modest set of 8 registers that could be combined to form 16-bit pairs  bc, de, hl.  Limited arithmetic was permitted within these pairs – in that they could be added to hl as an accumulator, incremented or decremented.  They could be loaded with immediate 16-bit constants and could be used as indirect pointers for load and store operations to memory.  The hl pair had special preference in that it was used as a memory pointer and any of the other registers could load or deposit through (hl). Push and Pop operations were done on the register pairs.

With 8 registers we have the possibility of creating a small stack – and with a rich, orthogonal set of register to register moves (Group 01), there is little or no requirement to have the usual stack manipulation instructions.  Group 10 instructions allow any register to have math or logical operations done using the accumulator as the destination.  So in theory if the register file were considered to be a pseudo-stack – any of the members could interact with the accumulator – or top of stack.

A machine capable of executing Group 01 and 10 instructions would be fairly versatile – so lets keep these in place.  That leaves manipulating Groups 00 and 11 to provide the other necessary instructions.

 

 

 

 

 

Posted in Uncategorized | Leave a comment

Minimal Computing – some more thoughts

This post is concerned with minimal computing – a subject that is close to my heart. I write this on the day that my Employers have suffered a major ransom-ware cyber attack on their servers and IT systems, bringing the companies activities to a virtual standstill.  To me this proves the fragility of the technology that we entrust for our day to day lives. There has to be a better, much simpler way……..

In the 1960s, the world of computing was evolving quickly as many new machines came on the market.  For code developers at that time, this presented a problem in that every new machine had a different assembly language, and this, and other quirks of the machine had to be mastered before efficient coding could be done.

High level languages such as Fortran, Algol and Cobol first appeared in the late 1950s, and whilst these eliminated the need for the developer to handle the machine language directly, the languages brought their own problems and abstracted control of the machine from the programmer.

The young developers of that age wanted something better, and both Ken Thompson of Bell Labs and C fame, and Charles H. Moore – inventor of Forth,  came up with their own solutions – to create a comfortable programming environment where they could code efficiently.

Thompson was part of the team including Brian Kernighan and Dennis Richie, working a Bell Labs who brought us the C programming language and the UNIX operating system – which is the basis of Linux and the foundation layer of almost all open source software.

Moore decided that he preferred a language that was closer to the “metal”,  and interactive in nature – so as to avoid the edit, compile, debug cycle – typical of a compiled language such as C.  Moore also believed that the target processor should be able to host it’s own toolchain – and not rely on external resources from a more powerful machine. Key to this was the dual capabilities of Forth – summarised (from Wikipedia) “Forth features both interactive execution of commands  and the ability to compile sequences of commands for later execution.” It is also extensible, in that it has the means for the programmer to create new commands.

Inspired by Chuck Moore’s Forth, and the minimum instruction set computing (MISC) ICs that he subsequently developed, I decided to get to the heart of minimum interactive computing and devise a computing environment that could be applied to the smallest, resource limited microcontrollers and offer the four main features of Forth that I felt were most important

  1.  Interactive – commands may be typed at the keyboard for immediate execution
  2.  Commands can be combined into programs then compiled for later execution
  3.  Extensible – from a small kernel of commands a whole application can be built
  4.  No external tools required other than a serial terminal

These I believe are the minimum requirements for computing – an interactive computing environment that can accessed with nothing more than a serial terminal.

Now some versions of Forth can be very comprehensive and run to about 16Kbytes, though most are between 4K and 6K.  My quest was for a much-reduced “Forth-Like” environment, that was so small, that it could almost become part of the bootloader, and be always present at start-up.  My initial experimentation was with Arduino – as it was so widely available,  but I then progressed to ARM and MSP430 – because of their larger wordsizes.  I settled on the MSP430 as my “model processor”  – because of it’s 16-bit wordsize (ideal for Forth) and the fact that it had a very “clean, orthogonal” instruction set, with a rich set of registers. I found coding in MSP430 assembly language relatively straightforward and thus I use it to test out new ideas.

As a bare minimum, the interactive environment needs to be able to do the following:

  1. Read consecutive serial characters from a UART and place them into an input buffer.
  2. Identify numerical strings from this buffer and convert them into integers to store in RAM.
  3. Use non-numerical characters as the index for a jump table, allowing the processor to branch to blocks of code on the basis of the ascii value of the character.
  4. Execute code at the jump address, then return to fetch the next character from the input buffer.

These actions are best performed by an inner interpreter  running within a loop, which co-ordinates the actions and ensures that the characters from the buffer are interpreted in sequence until the buffer end is reached with a newline character. This is all that is required to form the basis of an interactive character interpreter framework – and in MSP430 assembly language may be achieved in about 300bytes – including the initialisation of peripherals (UART, GPIO etc) and the get_char and put_char UART routines.

The other main aspect of a Forth-like language is that ability to store sequences of commands from the input buffer to memory,  and “compile” them, so that they are available to be run later.

Forth uses the process of giving these sequences a name or “word” and uses a process called the “colon definition” to commit the sequences to memory in an orderly arrangement – such that they may be retrieved and executed later.  Forth uses a dictionary structure to do this which it scans to find the word just typed.  Whilst convenient, this offered more sophistication than I needed so I adopted a much more basic approach.

In order to keep this process extremely simple, I decided that  naming a sequence would just really mean allocating a known character to it, such that it can be executed upon receipt of that character.  Then finding a fixed address to store the sequence could also be based on the value of that character, so that it may be located by a jump table.

So with this simple approach, for example  we can type a sequence  100L   The number decode routine will put 100 (decimal) onto the stack and then jump to the code that is addressed by decoding ascii L. This might be for example a routine that sends a number to a parallel 8-bit port which has LEDs attached.  The routine picks up the value of 100 from the stack and lights the LEDs to give a binary representation of 100.

This was how the programming toolkit started – just the means to decode a single integer number and use it within a given routine to perform some I/O action.

It was decided that capital letters would be used for the user routines, allowing a full 26 different actions, initially passing a single numerical parameter to the routine via the stack.  This was deemed a little limited, so a mechanism was derived to put more parameters onto the stack – so that arithmetical operations could be done.

Forth uses whitespace to separate words, but I thought that the space character could be used to separate sequences of numbers and place them on the stack one after another:

14 29    put 14 on the stack then put 29 on the stack

We can then introduce code that provides the basic maths operators + – * /

14 29+     Adds 14 and 29 leaving 43 on the top of the stack

14 29-     Subtracts 14 from 29 leaving 15 on the top of the stack

Following on from the above example we can then add in the “L”   LEDS command

14 29+L      Illuminates the LEDs with binary pattern for 43

14 29-L       Illuminates the LEDs with binary pattern for 15

So the fledgling language began – a means to perform a series of operations expressed as a string of serial characters. As the language evolved, the following conventions emerged:

Language primitives:   All ascii symbols and punctuation marks ! ” % ^ & *  ( ) _ +  etc

Built in functions:          Lower case characters a to z

User “Words”:                  Upper Case characters A to Z

Assembly Language Implememtation

Tiny-Forths had been explored before – notably on the AVR, a register rich 8 -bit processor but these resulted in about a 2K bytes implementation. My aim was to reduce the core of the language to less than 1024 bytes.

In the winter and spring of 2017, I decided to code up the language in MSP430 assembly language.  This served two purposes, I got to learn a little MSP430 assembly language, and it illustrated what sort of resources were required of a processor in order to implement a compact version of this language.

The MSP430 was chosen because it was a 16 bit processor – and it had a very orthogonal instruction set and a rich set of 16 registers. To me, it represented a blank canvas on which to paint the essence of the language.

The MSP430 code was quite compact with the kernel of the language fitting into some 300 bytes and a full implementation in under 900 bytes.

In the next part I will take the ideas around a self contained 1K byte interactive language toolkit further.

 

 

 

 

 

 

 

 

 

 

 

Posted in Uncategorized | 2 Comments

Minimal CPUs – “One Page Computing”

As I continue to explore the boundaries between computing hardware, firmware and software as part of an effort to reduce the perceived complexity to something that I can understand, the idea arose for a computing platform with an artificially imposed simplicity.

Hackaday has run competitions for the best code application written in fewer that 1024 bytes of code, so this led me to think about what sort of computing machine could be constructed in fewer than 1024, 2-input NAND gates. Memory would not be counted.

It was whilst pondering this when I received a comment to a past blog post from “BigEd” – who is a participant and moderator in the anyCPU forum

As a result of his comment,  I visited the anyCPU forum, and this showed that hardware constrained cpus were nothing new.

anyCPU is a spin-off from 6502.org to address the interests of those actively developing new cpu designs using FPGAs.  Several of these cpus were designed  with influences from the 6502, using the 6502 as a benchmark for the performance of the new designs. This has led to some interesting challenges within the forum – such as to create an 8-bit design with similar or better performance to the 6502, and the “One Page Computing” challenge  – which deserves special mention.

“One Page Computing”

The “OPC” project is to create a fully functioning, useful cpu, who’s design can be captured in just 1 page of verilog code – where a page is defined as 66 lines of 132 characters – or the old green and white, fan-fold, tractor feed line-printer paper.

This artificial design constraint,  puts some interesting challenges on the design – and in remarkable short time – has led to an interesting evolution of cpu designs – that meet this criteria. With each generation of the design, the instruction set has improved, as has the performance.

The OPC challenge was conceived in mid-April and in barely 4 months the OPC design has gone through 6 major iterations as outlined in this github project   This shows that FPGAs can be used to quickly prototype new cpu designs with minimum of expenditure.

The clever folks on the OPC Project now have written an assembler, and there is a C compiler currently being adapted to cater for the OPC6 instruction set.  Another enthusiast is porting PLASMA, a high level bytecoded language to the OPC6.

OPC6 was design constrained by the need for it’s verilog description to fit onto 1 page of printer paper – but this has shown that quite sophisticated cpus can be designed from very little resources.

“BigEd” has done a quick port of the OPC6 onto a Lattice ICE40 – merely to look at the resources used:

After packing: 
IOs 57 / 206 
GBs 0 / 8 
GB_IOs 0 / 8 
LCs 598 / 7680 
DFF 106 
CARRY 64 
CARRY, DFF 0 
DFF PASS 57 
CARRY PASS 3 
BRAMs 2 / 32 
WARMBOOTs 0 / 1 
PLLs 0 / 2 

After placement: 
PIOs 33 / 206 
PLBs 108 / 960 
BRAMs 2 / 32

The after placement figures show that the logic has used about 1/8th of the programmable logic blocks (PLBs) and one sixteenth of the available Block RAM, on the 8k Lattice Ice40.

For comparison – a soft core 6502 uses the following:

After placement: 
PIOs 27 / 206 
PLBs 144 / 960 
BRAMs 0 / 32

With low cost FPGA boards now available, for as little as £40,  supported by an open-source tool chain, there has never been a better time to get started with “One Page Computing”.

The OPC6 is the latest cpu to evolve from the OPC experiment.

It has 16 registers and provides a fairly comprehensive instruction set allowing register to register operations, not dissimilar to the MSP430, but lacking in several of the addressing modes. The conditional predicate bits allow the instruction to be conditionally executed according to the status of the ALU flag bits.

The OPC6 Instruction set is as follows   (See https://revaldinho.github.io/opc/ for full size):

opc6_instruction_set_1

 

 

 

 

Posted in Uncategorized | 4 Comments