PDP-8 History and Operation - and thoughts of FOCAL versus FORTH

I have been working my way through the Virtual VCF West 2020 videos, and was intrigued by the one showing the processes required to operate a PDP-8.

I came away from the video somewhat glad that I had avoided the minicomputer era, and all the encumberances of paper tape and 110 baud ASR 33 Teletypes. Whilst the early PDP-8 machines had a cycle time of 1.5uS and a typical 2 cycle memory access would take 3uS this was clearly not the bottleneck to efficient development on this machine.

The ASR33 Teletype and paper tape system ran at about 10 characters a second, which is OK for typing and printed output, but geologically slow when it came to loading the machine from tape, or repunching a tape having edited some of the code.

So I speculated, what would the PDP-8 computing experience have been like if there had been a Forth available for it? It belongs to the right era - the mid-1960s to mid 1970s, when Charles Moore was developing his Forth to run on various minicomputers.

A Tiny Forth can be written in about 2K or fewer words of assembly language, which would allow a couple of Kwords for user programs. So I did a google search on PDP-8 Forth - and it appears that it has almost been completely ignored, apart from on Github repository from Lars Brinkhoff - who looked at it almost exactly 7 years ago.

His approach was to write a target specific nucleus in the native machine language of the cpu, containing all the necessary primitives and then have a target independent kernel which allows the remainder of the Forth to be compiled.

This approach has been used by other notables in the Forth community, such as C.H. Ting with his eForth.

If the PDP-8 was a best selling computer with some 50,000+ sold - why was it not a popular target for Forth?

My views on this, is that it was in the wrong place at the wrong time. It was a budget machine aimed at education and small engineering or office roles. It’s 16-bit successor the PDP-11 was more likely to be used in the scientific roles (Radio Astronomy) where Forth first took some traction.

Additionally, until about 1975, few people outside the Radio Astronomy community knew anything about Forth, and it wasn’t until August 1980 when Byte Magazine ran their Forth Special Supplement where Forth was publicised to the wider hobbyist community.

By 1980, most hobbyists would be moving away from 15 year old minis and ASR33s and wanting far more compact microprocessor hardware with cassette storage or even a floppy drive.

Additionally, the PDP-8 had a Fortran compiler and a BASIC like language called FOCAL. Perhaps these were deemed sufficiently flexible for the PDP-8s that were used in academia and education.

So I genuiely believe that the poor old PDP-8 was going to miss the boat and remain a Forth spinster for the rest of it’s life.

But were there other reasons why the PDP-8 architecture was not a good fit for Forth? Possibly the subroutine mechanism which made recursion very difficult, or the 12-bit word size that was not a good fit for the usual 16-bit Forth VM model?

The PDP-8 was probably one of the last “octal” programmed minicomputers, and it’s instruction set reflected this - again not a good fit for Forth which was embracing hex notation and ascii character sets.

I have looked for a PDP-8 simulator written in C, and found one by Jean Claud Wippler of JeeLabs.

https://git.jeelabs.org/jcw/embello/src/branch/master/explore/1638-pdp8/p8.c

The simulator is about 250 lines of C code - which seems to be a lot more than I would have expected for such a simple machine. I have written simulators in about 60 lines of code - and the OPC project had several cpus that were simulated in a similar number of lines. A lot of this code relates to loading the memory from a file and for the input and output code. The actual instruction set is handles by four fairly compact switch-case structures.

So I feel a new project on the horizon - a compact PDP-8 simulator running on a Teensy - and a Forthlike interpreter to go with it. Should help keep me busy on these winter nights.

2 Likes

I think, FOCAL played very much the role of FORTH on the PDP-8, but with other objectives, like having a light-weight, but still capable floating point interpreter. (Maybe FLIP – Floating Point Interpreter and subroutine Package by J. Johnson, 1964 – on the PDP-1 can be seen as an early predecessor.)

Regarding emulation code, mind that the PDP-8 features only a 3-bit instruction set, but rather substantial microcoding. The architecture is quite well documented in various of Gordon Bell’s books, including representations in PMS/ISPS code, e.g., “Computer Engineering – A DEC View of Hardware Systems Design”, Digital Press, 1978, or “Computer Structures: Principles and Examples”, McGraw-Hill, 1982. (While the books are subject to copyright, it should be fairly easy to find a copy online. However, esp. Computer Engineering is a nice book and fairly easy to acquire as a real specimen.)

Edit: “Computer Structures: Principles and Examples” features a full, descriptive implementation of the PDP-8 in ISP code at pp. 125–128, while “Computer Engineering” features an in-depth explanation of the architecture, its structural levels, and design goals.

1 Like

The Gods are definitely on my side tonight.

I have found a version of jcw’s PDP-8 emulator - hacked to run on Arduino, with the ROM space pre-loaded with the 4K FOCAL language.

I have now loaded it into my 600MHz Teensy 4.0 and I have the genuine 1969 FOCAL coding experience interacting with Teraterm.

With the baudrate up to 921600 - we have a neat little system.

I understand now exactly what you were saying NoLand - FOCAL is a powerful program for a 4K memory and a lot easier to learn than Forth!

There was a wealth of scientific, technical and math routines written in FOCAL as well as some games such as Lunar Lander.

FOCAL appears easy to learn (similar to BASIC). It comes with a wealth of math and trig functions and it is possible to add your own commands and functions in order to partially customise the language to suit your application or hardware.

The University of Washington created their own version in the mid-1970s, U-W FOCAL that added several new commands, functions and improvements and tailored it to suit their particular Lab environment.

There is still a wealth of information about FOCAL available online including assembly source listings, program examples, manuals, advanced technical guides etc etc. I expect for many first time users of the PDP-8 it provided a friendly interactive, interpreted environment which effectively shielded them from the intricacise of the minimal PDP-8 instruction set and equally minimal hardware.

However, FOCAL was almost exclusively a DEC and DECUS product - although it was ported to the 8080. Ultimately it lost out to the tide of BASIC interpreters that were developed for the various minis and the new-fangled micros that were just appearing in the mid-1970s.

However despite it’s now obscure history, I have now got a much better respect for the PDP-8 and it’s role in computing history, and a better perspective of how to frame the minicomputer era relative to the developments of the later microcomputer era.

PDP-8 software archive can be accessed here including a scanned assembly listing of FOCAL-69:

http://pop.aconit.org/Programs/

3 Likes

Lunar Lander in FOCAL-69 using simulated PDP-8 on a Teensy 4.0.
You can probably see why I was not selected for the Apollo Programme

FIRST RADAR CHECK COMING UP

COMMENCE LANDING PROCEDURE
TIME,SECS ALTITUDE,MILES+FEET VELOCITY,MPH FUEL,LBS FUEL RATE
= 0 = 120 = 0 = 3600.00 = 16000.0 K=:0
= 10 = 109 = 5016 = 3636.00 = 16000.0 K=:0
= 20 = 99 = 4224 = 3672.00 = 16000.0 K=:0
= 30 = 89 = 2904 = 3708.00 = 16000.0 K=:0
= 40 = 79 = 1056 = 3744.00 = 16000.0 K=:0
= 50 = 68 = 3960 = 3780.00 = 16000.0 K=:0
= 60 = 58 = 1056 = 3816.00 = 16000.0 K=:0
= 70 = 47 = 2904 = 3852.00 = 16000.0 K=:170
= 80 = 37 = 1474 = 3539.86 = 14300.0 K=:200
= 90 = 27 = 5247 = 3140.80 = 12300.0 K=:200
= 100 = 19 = 4537 = 2710.41 = 10300.0 K=:200
= 110 = 12 = 5118 = 2243.83 = 8300.0 K=:200
= 120 = 7 = 2284 = 1734.97 = 6300.0 K=:200
= 130 = 3 = 1990 = 1176.06 = 4300.0 K=:200
= 140 = 0 = 5040 = 556.96 = 2300.0 K=:168
= 150 = 0 = 986 =- 13.63 = 620.0 K=:0
= 160 = 0 = 922 = 22.37 = 620.0 K=:0
= 170 = 0 = 330 = 58.37 = 620.0 K=:30
= 180 = 0 = 48 =- 20.19 = 320.0 K=:0
= 190 = 0 = 80 = 15.81 = 320.0 K=:12
ON THE MOON AT= 193.96 SECS
IMPACT VELOCITY OF= 11.73M.P.H.
FUEL LEFT:= 272.49 LBS
CONGRATULATIONS ON A POOR LANDING

ALT (FEET): … 986 (↓)… 922 (↓)… 330 (↓) … 48 (↓) … 80 (↑) … 0(!)
A small hop for man, but a giant oops for mankind :wink:
Congrats anyways!

Just to note: both those books (and a great deal more) are available on Gordon Bell’s own website. (And also available on the Internet Archive.)

2 Likes

Well done! A spectacular success!

So how may megs of ram are neeeded run 4 K focal?

You can’t really compare them, just because both were
interactive. BASIC or FOCAL where programable
calculator type problems, with floating point numbers
in the 1970’s, or simple industrial control.
As for FORTH it really had no real direction other than
being threaded code (fig forth) and cheap in the 1980’s
with 8080 (S-100 BUS) and 6502 (APPLE) and easy to control homebrew style devices like a small telecope.

The hardware between 1970 (PDP) and 1980 (APPLE)
can not be compared because of the cost of memory
and that defined what memory space word size possible,
4K PDP 8 16 KB 8008 64K 8080 256KB PDP 11

The other thing is PDP 8 did not lie about memory speed,
You GOT 4k of RANDOM ACCESS memory in PDP 8 time cycle often .75 us. You needed another cycle to write
back memory, Plain and simple timing. With modern cpus
who knows just how SLOW a instruction can be, with modern DRAM being a SERIAL style memory,and pipelining making it a serial cpu.
Ben.
Si-Fi novel quote “Don’t you just love FTL download speeds”.

Ben - the compilation report was as follows:

Sketch uses 22896 bytes (1%) of program storage space. Maximum is 2031616 bytes.
Global variables use 49852 bytes (9%) of dynamic memory, leaving 474436 bytes for local variables. Maximum is 524288 bytes.

The point is, it doesn’t really matter anymore.

The Teensy board is less than $20 and it’s given me a full weekend’s entertainment, and I have learnt a lot about the history and capabilities of the PDP-8 and FOCAL.

Tomorrow, I will reprogram it with another cpu simulation and have a play about with something different.

I have written experimental interpreters that were hand assembled into 300 bytes and cpu simulations that are just 60 lines of C code, but right now I wanted a quick and easy means to implement and experience the PDP-8.

My eyesight is failing and I struggle these days to even wire up 0.1" pitch DIL packages. Having lost my enthusiasm for making real hardware from sctatch, I have had to adapt to other means to still get a buzz from this hobby.

The 6502 and PDP-8 simulations have been fun, and have motivated me to tackle new projects having spent most of the last 6 months in the doldrums.

5 Likes

Nice to see, Teesy has ample memory for small stuff.A
$20 (toy computer) gets you the same as $2,000,000.00 main frame from the 1970’s so that shows how demanding modern software is compared to back then.
Good luck in finding your next project, as interesting machines may not have public software around, or white mice in the area,
Ben.

Ben,

It is phenomenal the computing resources that you can now buy for $20.

Just 10 years ago when I encountered my first Arduino, with a Atmel ATmega328 microcontroller - they were priced at $20. The ATmega has 32K Flash and 2K RAM with a maximum clock frequency of 20MHz.

The Teeny 4.0 has 64 times the Flash, 256 times the RAM, 30 times the clock frequency and 330 times the CoreMark performance - according to this benchmark. That’s significant progress in under a decade.

What I like about Teensy, is that it presents a blank slate for code development, without the overhead or encumberance of an OS.

This allows me full freedom to develop the experimental cpu code I choose, keeping the code simple with no overheads other than simple serial input and output routines.

Keeping the cpu and code simple gives me a better chance of ultimately being able to recreate it in TTL devices. My design is a 16-bit with a 4-bit bitslice architecture which I should be able to implement in about 80 simple TTL parts.

The processor is loosely based on Wozniak’s “Sweet-16” 16-bit virtual machine, which consists of an accumulator plus a further 15 general purpose registers. Keeping the operations solely between the accumulator and one other register reduces the complexity of the datapaths.

I have written enough assembly language to have routines for text input and output, numerical entry and output and hex to decimal conversion routines.

The next task is to write a simple monitor, and a tiny Forthlike interpreter which will allow self hosted language development.

2 Likes

The primary takeaway I got from tinkering with FOCAL was how it provided a complete computing environment - even for a machine as resource limited as the PDP-8.

This was no mean achievement, and the credit must go to the smart software engineers at DEC who had massaged a complete floating-point interpreted, interactive, extensible language, complete with line editor into just 4K words of core memory.

If we remember that the PDP-8 was originally based on DTL and used just about 1500 transistors and 10,000 diodes in the logic design. Additionally it used the rather unfamiliar “pulse logic” to achieve setting and clearing of the various flip-flops used in the very few registers present in the PDP-8 design.

I have read somewhere that almost half of the transistors in the PDP-8 were used to handle the addressing, read and write-back logic needed by the core memory.

With FOCAL loaded into core, it totally transforms this minimum architecture into a powerful, personal computer (by 1970’s standards), which when playing Lunar Lander this weekend - reminded me of the early text based, adventure games I encountered when the first micros appeared in school.

So here was a machine - with it’s beginnings clearly embedded in the PDP-5 (1963) which by 1975 was a 19" rack that could be built into medical instrument trolleys, or run a CNC machine tool, typset text for a local newspaper or run the information display systems for the BART (Bay Area Rapid Transport) system.

With an extensive back-catalogue of software and applications behind it, he PDP-8 had achieved a cult following as the world moved to early microprocessors in the mid-1970s. Intersil and Harris shrunk the PDP-8 architecture into a microprocessor format, achieving yet a further generation of integration. The resulting HD6120 found it’s way into several products including DECs range of DECMate intelligent video terminals, which were primarily aimed at data entry and word processing applications.

Bringing things into the 21st Century, I found this interesting site describing an SBC based on the Harris HD6120

4 Likes

A register file is big pain for a TTL computer, because you have a only few chips you can design with: 74170,74172. If you use more modern chips, a design
using 2901’s is a better option. 2901’s are hard to find,
so buy them now if can find them.
10 to 15 MSI chips for a TTL 4 bit bitslice in the data path
is good ballpark figure. Have you looked at the 1802 cpu?
Rather than working on 16 bit cpu, in LS TTL (FPGA development) memory is cheap I have gone to a simple 32
cpu. 2 16 bit alu cards cards and 1 control card. 5 256x4 proms (60ns) are used for control.A 20 bit design has 1 20 alu card in the data path. Both have Excess 3 addition and
512KB of address space. Ballpark timing runs at 1.8432 MHZ. Still tweeking both instruction sets, and debugging software.
The PDP/8 was compact because it could use a 12 bit instruction word. The IBM 1130 also had well thought of instruction set with indexing (core registers 0-3?) that I am
sure helped with FORTHs data/program stacks idea.
Having a register file in core memory was common idea in 1960’s. Then a slow machine was better than NO machine. Ben.

1 Like

Ben,

Register file chips are as rare as hen’s teeth these days.

Last year I managed to find a couple of tubes of 74F219 - these are a 16 x 4bit RAM with a 10nS access time - similar to the 74xx89 but tristate and non-inverted outputs.

They say that every computer architecture is designed around the requirements of the memory - so my bitslice design is influenced around the 16 registers that these RAM chips provide.

The rest of the design was inspired by Wozniak’s Sweet-16 and the simplicity of the PDP-8.

I don’t want to create a design so complex - that I cannot easily implement it in TTL.

Wishing you well with your 20 bit design,

Ken.

Sadly, the very odd 74172 needed for Brad Rodriguez’s PISC processor is really hard to find. I looked into replacing it with other TTLs but the complexity isn’t worth it. It is better to simply do a different design around another register chip instead.

2 Likes

From the link:

Eight 74172s provide eight 16-bit registers in a three-port register file. This file may simultaneously write one register (“A”), read a second (“B”), and read or write a third (“C”).

Gosh! That is quite the register file. I was going to suggest using (and under-using) an SRAM for a register file, but this is well beyond that.

1 Like

I got a whole tube of 74LS170’s. I like OC rather than tristate
simple because I have no chip select conflicts.
Unicorn electronics has the 29705 16x4 dual port ram in stock for $8 each. 74172’s are listed as limited stock on hand for $5 each.

Right now I am looking for SD card (standard size) break out cards, but just seem to find the
(micro) SD card adaptors.
The time frame of the design is mid 1970’s, so the older
standard SD cards (16 Meg) are more than ample to emulate the fixed drives at the time.

1 Like

Ben,

I guess you are in the US, here in the UK there are not many companies that stock the old TTL devices. You find a few on ebay, but they are getting rare.

My proposed design has been heavily influenced and inspired by Sweet-16 - so it is an accumulator plus 15 other general purpose registers.

The ALU design came from Dieter Muller (6502.org) which has been used to great effect in the Gigatron by the late Marcel van Kervinck. I intend to add a universal shift register for left and right shifts, and a 74x85 magnitude comparator to provide the GT LT and EQ flags.

That makes the 4 bitslice ALU 7 chips and the registers 1 chip. The PC will be 1 chip per slice and the control unit 6 or 8 chips in total.

The machine is a 64K address space - but page addressable to 16Mbyte

I think I can do the whole machine in 70 or 80 TTL ICs.

2 Likes

Why 16 meg of memory? Mr Gates claims 640K is ample.
Bank select cpu’s works best in 4 banks, program and data and display and and extra bank.

Since I am not using graphics on machines, I figure 128 Kb
is all I will ever use for 20 bits 96 KB program 32Kb O/s.
1 KB disc block size.
For the larger machine 8/16/32 bits, 128K user and 64K O/S. 2 KB disk block size. I/O is 2400 baud serial and
fictional hard drive of 203 tracks/ 2 heads 2 or 4 K bytes per track. (812 blocks) with a FAT style format.
Some BIOS and Library routines are in ROM, but floating
point still needs to be written.
Hardware 2 SD cards, so I can copy stuff as disk formats
are not standard.
Ben?

Sorry - this reply is definitely wandering off-topic, and would probably be better off under a new title.

Ben,

Agreed 16MB is a lot of memory by some starndards, and as someone who first touched a CP/M machine in 1978 with initially only 16Kbytes it seems an astronomical amount.

However, in the last 42 years we have reached the point where cell phones are regularly fitted with 8GB internal RAM and a microSD card that will take a 128GB card.

But we have to accept that the way we interact with computing devices has changed a lot - from a single user on a terminal working with a CP/M microcomputer - to a teenage kid on a cell phone who wants to have multiple Apps simultaneously in memory, and spend his day flicking between them, sending badly spelt messages punctuated by cryptic emoticons. Not to mention the demands of multiple, mult- megapixel cameras and HD or 4K screens.

Clearly the demands on memory and processor resources have mushroomed by many orders of magnitude, in terms of memory address space, processor transistor count and clock frequency.

I have been laying out pcbs since my college days, my first introduction was on a BBC micro in 1985. That was something of a challenge and it taxed the full resources of that early machine. Five years later we had access to 16 or 25MHz Compaq 80386 machines with perhaps 10MB of RAM and a 40MB hard drive.

That dramatically improved the whole business of laying out multilayer boards - although schematic capture and layout had to be done in separate applications, and communicate with each other using Engineering Change Order files (ECO) that allowed forward and back annotation to be performed and recorded.

Even 30 years ago - I remember this process to be quite productive, and in my opinion pcb design software has not seen the equivalent advances, that other engineering design packages have witnessed.

It is still very much a 2D manual process, and whilst screen refresh and resolutions have increased - it is still very much recognisable as the original 2D drawing engine software with a few somewhat irrelevant new features bolted on. CAD companies have to find something new to add on an annual basis to keep the subscription revenues coming in. In truth there really has not been much innovation in 40 years - somewhat dissapointing when you look at the tens of gigabytes these CAD package take up on the disk.

However, the symbol libraries have grown in size. You seldom have to design your own symbol or component footprint. However - I have twice been bitten by downloading 3rd party symbols that have been complete works of fiction.

To return to the original question about memory. I think 16MB, and a fairly fast 16 or 32 bit processor - say 100MHz clock, would fulfil the requirements of most of my professional requirements, such as PCB design, document editing, spreadsheet etc. Provided there was only a single application in memory at any time, performance would be acceptable.

I despair at my modern laptop that frequently struggles to perform - as a result of running background tasks that are entirely beyond my control.

A complete rethink about operating systems and how we interact with the machine might be in order. The biggest overhead to efficient machine interraction has to be the constant barrage of interruptions from the web, internet browsing and emails from co-workers. All things that were not widely available or commonplace in most companies back in 1990.