Last visit was: Wed Dec 01, 2021 6:05 pm
It is currently Wed Dec 01, 2021 6:05 pm

 [ 52 posts ]  Go to page Previous  1, 2, 3, 4  Next
 Suite-16 (formerly Bitslice using currently available TTL) 
Author Message
User avatar

Joined: Fri Mar 22, 2019 8:03 am
Posts: 328
Location: Girona-Catalonia
About the ALU instructions I think you may need an ASHR instruction which has some applications. Also, the SHL can be replaced by ADD to itself, so maybe you can remove the former to save encoding space.

Sat Oct 12, 2019 8:17 pm

Joined: Mon Aug 14, 2017 8:23 am
Posts: 157
Here are a few points about the ALU.

It is based on Dieter Muller's unit that is based on 74xx153 multiplexers and a 74xx283 adder. It was used in an 8-bit form in the Gigatron - and it lends itself directly to a 4-bit wide bitslice design, consisting of four multiplexers and one adder.

Further extensions include adding a 4-bit universal shift register (74xx194) to provide a SHR - although this could be done with a 74xx157 to select either a (hardwired) right-shifted version of the ALU output, or the ALU output directly.

A further extension is to include a 74xx85 4-bit magnitude comparator - which allows direct comparisons to be performed to test for equality, less than and greater than, setting flag bits when a CMP or CMPC instruction is performed.. These might be useful but it's not much more than can be done with the use of the SUB instruction, and might not justify the extra complexity.

So the basic ALU is 5 devices, with the option of adding a shift-register, and a comparator.

Finally, as the Accumulator (AC) is very closely coupled to the ALU, a 4-bit register 74xx173 is included in the ALU group. This group of 6 or 8 ICs forms the core of the bitslice and yields the following arithmetic and logical instructions:

NEG (bitwise negatation)



INC can be done by setting the carry and performing ADD
DEC can be done by ADDing -1 (FFFF)
INV is the ones complement which is used during twos complement SUBtraction - see NEG

The multiplexer front end has sufficient flexibility to generate 0000, FFFF, and -A

The other neat trick that Marcel showed me from the Gigatron, is that if you apply -A to the ALU when you want to perform a JMP instruction - then the CarryOut flag (CO) indicates if the Accumulator is zero. The MSB of the ALU may also be used to test whether >0 or <0 condition exists.

The Gigatron ALU uses a combination of CO and the ALU MSB to decode the full set of Branching conditions - using very little hardware.

Branch on Zero is probably the most useful of the conditional jump instructions - and in some MISC/Forth cpus it is the only one provided.

The ALU currently needs 5 control signals - one of which is the CarryIn. The intention is to use a diode array to decode the instruction bitfield into the various ALU control signals.

The Gigatron used a 3 bit wide instruction field, which is compact and allows the other 5 bits to be used for the various addressing modes and the ALU second operand source. This works well if your instruction word width is limited to 8 bits - but for a 16-bit wide instruction, much greater flexibility becomes possible.

As my instruction coding is still a work in progress - I will discuss this a later time.

Sun Oct 13, 2019 10:09 am

Joined: Mon Aug 14, 2017 8:23 am
Posts: 157
After a couple of days thinking about the ISA, and following the suggestion of (I think) Roelh, I have started to document the Suite-16 project over on the site.

One advantage of is that the project can be documented as a series of blog posts - suitably illustrated with pictures, diagrams and code snippets.

It also makes you think more carefully about what you wish to publish, organise your ideas and charts the progress of the project. opens you up to comments and suggestions - with a little peer review and constructive criticism.

There's not much published yet, but I am currently focusing on the instruction set, with the aim of writing a simulator in C - to test the instructions and see if the ones initially chosen all "play well together nicely".

Tue Oct 15, 2019 12:26 pm

Joined: Mon Aug 14, 2017 8:23 am
Posts: 157
This week I have been thinking about the Suite-16 instruction set - and how it might be implemented in hardware.

I've started some Hackaday project logs to document the progress.

Steve Wozniak's Sweet-16 gave me the first clue to how to express the instructions in a clear and concise manner - with just 31 instructions.

I then sat back and thought about how to describe the whole machine.

The simplest description is a much modified PDP-8, which has had its buses stretched from 12-bit to 16-bit, had some general purpose 16-bit registers added, and a 16-bit bit long instruction word.

My latest Hackaday project log specifically looks at the instruction set - as influenced by the PDP-8. ... influences

Thu Oct 17, 2019 2:55 pm

Joined: Mon Aug 14, 2017 8:23 am
Posts: 157
Now that I have got a basic simulator running in C, I can work towards proving the Instruction Set.

However hand assembly of 16-bit instruction words gets a bit tedious - even though the bytecodes are trivial.

I decided that I would hack together a barebones tool that would help me assemble instructions from either text typed at a terminal, or sent from a text file using a terminal program such as TeraTerm.

The first thing to do was to establish a few rules:

To make the job of writing the assembler easier, I really only wanted to parse single characters - rather than the more conventional mnemonics that are usually 3 of 4 character strings - like ADD and CALL.

All of the mnemonics would be assigned a single character - which for arithmetic and logic operations is all very familiar

ADD becomes +

SUB becomes -

AND becomes &

OR becomes |

XOR becomes ^

INV becomes ~

So that's the arithmetical and logical instructions mostly taken care of apart from INC and DEC - and these seem suitable:



The next task is to allocate single character pseudonyms to my register set R0 to R15. Personally, I find it much easier to remember alphabetical names rather than numbers. Anyone familiar with 8080 or Z80 code will be quite happy using B, C, D, E, F, H, L, M etc.

So I have allocated a capital letter starting at A (a logical choice for the Accumulator) and ending at P, which happens to be the Program Counter. All I have done is add a few more register names such as G, I, J, K, N and O.

J and K are often good choices for loop counters and M as a memory referencing register like on the 8080. They can always be changed later depending on the application, I might want to call my Stack Pointer S and my Return Stack pointer R at some later date.

The assembly language syntax is minimal - just enough to get the job done. A register is refered to by it's name followed by some operator. As most of the ALU operators involve a register plus the accumulator as the destination we can omit the A.

B+ ADD B to A.

B} Move B into A direct register addressing

B{ Move A into B

B! Store A at the address given by B - these are indirect register addressing using fetch @ and store ! symbols borrowed from Forth

B@ Load A from the address given by B

Numeric constants (immediate addressing) use the # - which is borrowed from the LIT word in Forth

1234#B Load B with 1234 which follows in the next memory location

234#B Load B with the short constant, which is found in the payload byte

We now have to dig a little deeper for meaningful symbols

B\ POP an item off the stack into A, where B is used as the stack pointer

B/ PUSH an item onto the stack, using B as the stack pointer

$ Identify the following number as hexadecimal

127= Branch if A=0 to zeropage address 127

126< Branch if A<0 to zeropage address 126

125> Branch if A>0 to zeropage address 125

I have managed to implement this in less that 200 lines of C code. This is enough to prove the concept and show that the correct instructions can be assembled from the limited syntax.

More features such as labels, origins etc can be added when required.

Fri Oct 18, 2019 7:47 pm

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1647
Nice idea - shades of EDSAC. (pdf)

Fri Oct 18, 2019 8:31 pm

Joined: Mon Aug 14, 2017 8:23 am
Posts: 157

Quite correct. I was involved with an EDSAC simulator a couple of years ago (simulating it on an MSP430 devboard) - and already had quite a lot of experience working with single character opcodes - especially capital letters.

It was therefore quite an easy hack, to change the syntax so that it would be appropriate to Suite-16. It was the sort of mini-project that you feel you can achieve in a Friday afternoon - and have something working by tea-time :)

Had I been living in the 21st Century, and known some Python, I'm sure that I might have been able to follow that option.

However, I believe in keeping things as simple as possible, and accessible to the hobbyist hacker, so I have taken the decision to create these early tools (simulator and assembler) using an Arduino compatible dev-board.

Now that I have a tool that can accept small snippets of assembly language and convert it to object code, I have the means to build up a set of primitives for a Forth-like language. Then I will be able to code at a slightly higher level.

This was the approach Chuck Moore used when he wrote his "proto-Forth" for the IBM 1130.

His original 1968 listings came to light a couple of years ago - and you can see that in the first few lines of his listing that he is creating an assembler for the 1130 instruction set by ORing together the various bitfields to assemble the instruction into memory.

Now slightly more than 50 years later, I am treading the same path.


You do not have the required permissions to view the files attached to this post.

Fri Oct 18, 2019 9:22 pm

Joined: Mon Oct 07, 2019 2:41 am
Posts: 273
monsonite wrote:
Now that I have got a basic simulator running in C, I can work towards proving the Instruction Set.

However hand assembly of 16-bit instruction words gets a bit tedious - even though the bytecodes are trivial.

I decided that I would hack together a barebones tool that would help me assemble instructions from either text typed at a terminal, or sent from a text file using a terminal program such as TeraTerm.
More features such as labels, origins etc can be added when required.

A 8 bit Byte swap might be a handy feature,like on the DG's NOVA computer. The Nova also only had 32K of memory with the sign bit, used as another level of indirection on a Indirect instruction.
The sign bit was often used for a low/high byte on a byte pointer on many machines.

I found that while a Assembler is needed, after writing bootstrap and test routines some sort of
high level language is needed to handle arrays,subroutine calls and looping for bigger programs. UNIX took off not because it was on a PDP 11, but they could write the OS and other software in C using structures for clean coding of information. File Pointers are a good example.
Old DOS archives might have a table driven cross assembler in C that may speed up writing one.

The current compiler I have, just does basic compiling and structures need to be added to it soon.
I expect it to run in 24KB once converted from C to Self Hosting program before Chrstmas.

Sat Oct 19, 2019 6:10 am

Joined: Mon Aug 14, 2017 8:23 am
Posts: 157

Thanks for the suggestion about the byte-swap instruction.

I figured out earlier this week that it might be useful - even if it could only be done on the accumulator.

There are a number of operations that don't fit well into my limited opcode scheme.

These include the clear, complement and shift operations, plus the means to generate small constants such as 0, 1, 2, 4, 8 and -1 (FFFF).

I currently have some unassigned instructions in the upper half of my 0x group, and I was proposing to follow the lead of the OPR instructions on the PDP-8, where direct operations on the accumulator (CLA, CMA, SLA, SRA etc) could be coded into the individual instruction bits. The byte swap, and any 8-bit Input/Output operations would also be part of this group.

Sat Oct 19, 2019 9:34 am

Joined: Mon Aug 14, 2017 8:23 am
Posts: 157
Hello World!

Tradition states that the first thing you get a new computer to do is print out the exclamation "Hello World!"

To reach this point you need to have most of your cpu (or simulator) working, including correct instruction decoding, memory access, various addressing modes, conditional branching and some means to examine the contents of the registers.

I'm pleased to say that after a few days this week defining the instruction set, writing a simulator, an assembly tool and general documentation, Suite-16 has uttered it's first exclamation.

        0x1100,     // SET R1, 0x06
        0x4100,     // LD R0, @R1
        0xE100,     // INC R1
        0x0103,     // BNZ 03
        0x0000,     // BRA 00
        ' ',

Sat Oct 19, 2019 3:13 pm

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1647

Sun Oct 20, 2019 8:29 am

Joined: Mon Aug 14, 2017 8:23 am
Posts: 157
After managing "Hello World! over the weekend on my Suite-16 simulator, I thought I'd have a go at a decimal integer printing routine.

This will test the arithmetic operations as well as the conditional branching.

The routine takes the 16-bit integer value from the accumulator and sends it to the serial terminal as 5 ascii characters followed by CR and LF.

Leading zeros are not suppressed - this is a quick and dirty hack.

The draft routine is 84 (16-bit) words long in memory, but can easily be shortened with a sub-routine or two.

It craps out at 42767 - which is 10,000 + 32,767 - I think it's trying to tell me something about the limitations of ascii coding

I timed the period to output 32768 5 digit numbers (plus CR and LF) at 52 seconds with a 115200 baudrate with the simulator running on a 16MHz MSP430.

I then tried the 400MHz ARM STM32H743. Again at 115200 baud - time 21 seconds.

I then ran it on the 400MHz ARM STM32H743. This time at 921600 baud - time about 3 seconds. To fast to get an accurate benchmark.

I'm just happy that I am making progress and so far the instruction set seems to be useful.

I need to get subroutine call and return working - but that's on the TODO list.

Tomorrow I am going to work on the 16-bit number entry routine, and the proceed with the SIMPL interpreter.

Tue Oct 22, 2019 10:34 pm
User avatar

Joined: Fri Mar 22, 2019 8:03 am
Posts: 328
Location: Girona-Catalonia
Nice progress. I have a question though.

I understand that you are using several development boards on the Arduino IDE to test the simulator. You are now porting your "SIMPL" interpreter to run on Suite16 so that it can be run by the simulator. Among others, this involves the port of the 'printnum' function, as you described in

However, I am intrigued by the final implementation of the 'putchar' opcode. I understand that so far the development boards are connected to a computer through a serial port and the Arduino IDE . On your simulator, you simply use the "Serial" class to get input/output from/to your computer through the Arduino terminal window. So up to this point everything looks pretty clear.

My question is however about the final implementation. I understand you will have to implement a similar feature on your physical TTL processor, i.e. a serial port so you can connect your CPU to the world. Please can you elaborate on this?


Wed Oct 23, 2019 7:20 am

Joined: Mon Aug 14, 2017 8:23 am
Posts: 157

Good question - In the simplest of microprocessor systems you would frequently use a UART IC - such as the 68B50.

However this device contains a multiple registers and would not be easy to program with such a simple I/O scheme as I am planning.

Implementing a UART in TTL, whilst obviously possible would add significant complexity to the design.

Another scheme is to use bit-banged serial, where a single output pin is used to transmit serial data, and another to receive, under the timed control of the cpu. This was a technique often used with the early microcontrollers (PICs etc) before they had integrated UARTs. Whilst simple to implement and effective it does tie up lots of cpu cycles timing the pulses.

The third method is to use a parallel to serial shift register - like a 74xx165, and use this as the output register. The clocked serial data can be received using an Arduino running a variant of SPI mode. The Arduino then buffers the data and outputs it to the laptop via USB.

Serial input may also be done with a shift register such as the 74HC595. This is what the Gigatron does for PS/2 keyboard entry - and they use an ATtiny mcu to convert the PS/2 protocol to a format that is easier for the shift register.

The third method will allow high speed comms - and whilst purists may say that it is cheating using an Arduino it will probably be the easiest method to get something to work.

Wed Oct 23, 2019 7:42 am
User avatar

Joined: Fri Mar 22, 2019 8:03 am
Posts: 328
Location: Girona-Catalonia
Hi Ken,

Thanks for that. This subject is the one that currently sits in the darkest place of my CPU74 build. I think that I have the basic understanding to design a CPU, but I'm essentially lost on everything that's required around it, such as eventual PS2 / VGA support or serial ports, program-loader and so on. As the fist step, I would be fine by just being able to connect it to a regular computer through a 'serial' terminal, so I can run things such as "basic" or other ascii based stuff. Using an arduino as the 'bridge' may prove to be indeed the easiest method. I am keeping an eye on what you do!


Wed Oct 23, 2019 10:27 am
 [ 52 posts ]  Go to page Previous  1, 2, 3, 4  Next

Who is online

Users browsing this forum: AhrefsBot, CCBot and 0 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software