• Please review our updated Terms and Rules here

Tektronix 4052/4054 and 4052A/4054A custom bit-slice 16-bit CPU opcodes

nikola-wan

Veteran Member
Joined
Mar 7, 2018
Messages
1,410
Location
Texas, USA
Tektronix introduced their second generation 4050 microcomputers in 1979 - the 4052 and 4054.

Both of these computers were at least 8x faster running Tektronix 4050 BASIC programs than their first generation 4051 introduced in 1975 which had a Motorola 6800 CPU with a clock speed of 800KHz.

Bob Haas designed the bit-slice CPU for the 4052 and 4054 and described the design goals in his VintageTEK youtube video:
Tektronix 4052 Development and Speed Comparison to 4051

4052/4054 CPU Design goals
  1. 6800 compatibility
    • Must be able to leverage the 4051 32KB BASIC ROM firmware development
  2. 8 times faster than the 4051
    • 3 Factors of Two
      1. Double CPU clock speed (2MHz vs 800KHz)
      2. Double memory bandwidth with 16-bit memory width
        • This also doubled the address space which doubled the RAM to 64KB and doubled the ROM space to 64KB!
      3. Harvard Architecture - overlap instruction and data fetch
Hurdles
  • 6800 8-bit instructions and data could not take advantage of 16-bit memory bandwidth speedup
  • Harvard architecture was challenging and not delivered at launch in 1979
Prototype performance result of 3x the 4051 with these hurdles did not satisfy management.

Engineering proposed and management supported incorporating the double-precision floating point operations in microcode. This also would require extensive changes in the BASIC ROMs to use the new microcode instructions.

Bob added new opcodes for 4050 BASIC 64-bit floating point in the unused spaces of the 6800 instruction set and the result was over 30x speedup for floating point computations which also resulted in 8x speedup in vector graphics performance due to the multiple floating point operations to draw any vector!

Result

The 4052 and 4054 exceeded the goal of 8x performance improvement for the launch in 1979.

The third generation 4050 computers were named 4052A/4054A and launched in June 1982 with more new opcodes in the bit-slice CPU providing a 20% performance increase for some BASIC commands. These computers also included faster GPIB and serial interfaces, and new 4050 BASIC commands including structured BASIC and several new graphics commands - see this article:

Tekniques Vol6 No3 - BASIC Language Enhancements Highlight New Models

The next Tekniques Vol6 No4 included a tape with a 4052A/4054A Assembler written by two Tektronix programmers using the new structured BASIC commands.

I inventoried a large collection of Tektronix manuals and tapes at the Living Computer Museum in Seattle in 2018 and found that tape in the collection! I filled out a request to try to recover that tape and a couple of other tapes in that collection and recovered the entire tape and got LCM to scan the documentation for that tape and posted the assembler BASIC program and documentation on my github repository in this folder:

4052A-4054A-Assembler

The assembler documentation is 97 pages and includes not only the new opcodes for the 4052/4054 but also the opcodes added for the 4052A/4054A. It includes a couple of short programs to assemble and run - I also got Motorola MIKBUG assembled and running on my 4054A.

Most of the documentation is detailed descriptions for each new opcode and a list of 4052A/4054A BASIC ROM entry points!!

As I have been trying to disassemble the Option 30 Dynamic Graphics Coprocessor firmware - I will also need to understand how the 4054A sends commands to the Option 30, so I am examining the 4052 Assembler documentation again.

I found a nice Motorola 6800 opcode table here:
6800 instruction set

I put the table into a Word document and created a Tektronix 4052/4052A 4054/4054A opcode table from the BASIC assembler program and the assembler document:

Tektronix 4052-4054 Opcode Table.png

As you can see - Bob Haas added the opcodes in RED in the 6800 opcode gaps which have a GREY background color in addition to all the 6800 opcodes in BLACK to the original 4052/4054. Bob told me he did not work on the 4052A/4054A ALU, but the opcodes in BLUE and GREEN were added in addition to keeping all the opcodes in BLACK and RED.

The
GREEN opcodes are 6800 backwards compatible 16-bit extensions to operations on the A and B accumulator registers.

The engineers ran out of gaps for all the BLUE opcodes added for the 4052A/4054A and added C7 and FC as escape prefix codes to support the two extra lines in the opcode table for a total number of opcodes of 275 !!!


Here is my list of register extensions for the original 4052/4054 and 4052A/4054A with the same color codes as the opcode table:

6800 Registers and 4052-4054 & A-Series registers.png


Since they doubled the RAM and ROM sizes to 64KB - they were still limited to the 16-bit address lines so they added opcodes to change the address to/from the new Data Space A and Fetch Space B - and added condition code bits to detect which space is currently selected.

The assembler document indicates that this is the reason the assembly programs need to use SWI before accessing the ROMs - and the microcode will switch the space from RAM to ROM. The RET instruction will return from ROM space back to RAM space for the assembly program.
 
Last edited:
I just updated my 4052A/4054A folder on my repo with the work-in-progress MS Word doc and pdf version with these tables and posted the text above in the README.

That WIP doc needs the new 4052/4054 and A-Series detailed opcode descriptions added to the 6800 opcode details.

All the information needed for that is in the 97-page 4052A Assembler instruction pdf document.
 
I added the A-Series updates to the 6800 opcode details and believe there are two more A-Series opcode changes to 6800 opcodes: SWI and WAI.

The 4052A/4054A assembler document page 2 indicates SWI is the method that must be used to access BASIC ROM Calls - where the 16-bit address in the SWI will be in the ROM space for the next fetch.
This means the A-Series microcode for SWI pushes 11 bytes onto the stack including the CC status register bits 7 and 6 which are the current Fetch and Data Space settings as described in the document page 81 for the changes to 6800 opcode RTI!

If the A-Series changes do not include the SWI and WAI changes and do NOT push the 11 bytes onto the stack then RTI won't work right.

I posted my updated opcode table and opcode docx and pdf on my 4052A-4054A Assembler repository: 4052A-4054A-Assembler

Since I see the EXEC Call in the v1.5 4052/4054 posted ROMs - I wonder if an assembly program that ONLY uses the RED opcodes will work on a 4052 or 4054?

My 4052 is broken - so I cannot test my theory.
But someone with a 4052 or 4054 non-A series could test this!

I will power up my 4054A and input the short assembler example on pages 9 and 10 of the assembler document and create a BASIC program someone can run on their 4052/4054 (it will also run on the 4052A/4054A).

If the test program runs on a 4052 or 4054 non A-series - that means the RTI, SWI and WAI modifications are in the 4052 and 4054 v1.5 ALU microcode too!
 
Ok - I made a simple change to the 4052A Assembler program to write the length of the Code$ and length of the Rel$ before writing the Code$ and Rel$ to the Flash Drive.

This give my new ASM Test program the information to DIMension C$ and R$ before reading those strings from the binary file 4.

I have attached a zip file containing:

File 1 - the Assembler program (only runs on A-Series)
File 5 - the assembly source file for the Example program on pages 9 and 10 of the assembler doc
File 4 - the binary output file from assembling File 5 as the input file
File 9 - this program runs on my 4054A and asks for the assembled BINARY output file # and then simply loads the Code$ and Rel$ into C$ and R$ and does a CALL "EXEC",C$,R$

Can someone with a working 4052 or 4054 try running File 9 and selecting file 4 as the input file?

Output will look like this:

ASM Test on my 4054A.JPEG
 

Attachments

  • 4052AsmblrTEST.zip
    8.3 KB · Views: 1
The Assembler program file 1 uses the Flash Drive to read the input source file and creates the Code$ and Rel$ in memory until the assembly is complete.
Then the Assembler program writes the sizes of Code$ and Rel$ to the output Flash Drive file, followed by writing the Codes$ and Rel$ out to that same file.

My short program in the screenshot in the previous post asks for the Flash Drive file # of the Code$ and Rel$ and reads the sizes of the two strings, DIMensions the strings and then reads the Code$ and Rel$ and performs the CALL "EXEC",C$,R$ to run the assembly program.

When the assembly program executes the RET instruction - control returns to the BASIC program.
 
Back
Top