• Please review our updated Terms and Rules here

Tektronix 4052 Emulator

nikola-wan

nikola-wan

Veteran Member
Joined
Mar 6, 2018
Messages
1,530
Location
Texas, USA
This thread will continue the discussion of @daver2 's development of a Tektronix 4052 vector graphics microcomputer emulator!

Dave wrote the Tektronix 4051 Emulator - which emulates the Tektronix 4051 hardware architecture introduced in 1975 including the Motorola 6800 CPU with 32KB of RAM and 32KB of BASIC ROM and a Display board with 1024x780 vector graphics resolution. His emulator is written in HTML5 javascript and runs in Chrome, Firefox, Edge and other web browsers on a variety of computers including PC, Apple and Raspberry PI!

Dave is now working on a Tektronix 4052 Emulator which emulates the Tektronix 4052 computer introduced in 1979 which used the same Display board as the 4051 but replaced the 6800 with a Tektronix custom bit-slice 16-bit CPU that emulated the 6800 and added microcode for floating point which speeds up running 4050 BASIC programs about 10X over the 4051! The 4052 16-bit architecture doubled the RAM to 64KB and doubled the BASIC ROM to 64KB

The 4051 Emulator and instructions can be downloaded from a github repository here:
Tektronix 4051 Emulator

The 4051 Emulator has been enhanced by @WaveyDipole and includes my Tektronix 4050 GPIB Flash Drive - which emulates the Tektronix 4924 GPIB Tape Drive for BASIC program storage and data files.

I have posted many 4050 BASIC programs that I have recovered from over a hundred 4050 tape cartridges and many programs that I have written including Adventure for the 4052/4054 and MONOPOLY - curated to run on 4051, 4052 and 4054 computers and the 4051 Emulator here:
Tektronix 4050 GPIB Flash Drive

1736162027567.png
 
There is a difference between the documentation saying that the 4052 has an 8-bit A and B accumulator (because the instruction set only uses the A and B accumulators as 8-bit registers) and the accumulators physically being 8-bits.

The registers are stored within the four off AM2901A devices. Each device containing 16 * 4 bits of RAM - the RAM being used as registers.

By default, therefore, the A and B accumulators (which occupy two (2) of the RAM/REGISTER words) are physically 16-bits wide.

I suspect the microcoded MACRO instructions only treat these two accumulators as 8-bits.

I would be interested in seeing where the high bit(s) get set from through... It is possibly the microcode self-test routines?

My error was accidentally using all 16-bits of the accumulators when I should have used only the lower 8-bits. If the power-on self-tests accidentally leaves some bits set in the high byte of the A or B accumulators, then the resulting hardware (and hence my emulation) should have masked these higher bits out. It does now!

I am still hunting through the ROM code to find out where the subroutine is called to set-up the appropriate interrupt table in RAM.

Plenty of false leads...


Dave
 
Page 6-11 of the Section6 document indicates how the ALU uses Field-1 and Field-2 to access register A or register B.

There are several pages on ALU microcode operation in the 1980 Technical Data Section 6 that are NOT in the -03 Technical Data Section 6.

1736176857481.png
 
Still up to my eyeballs with work. I may be like this now to the end of the year I fear.

A job has gone 'belly up' and I am the only one to sort it out...

Dave
 
Got bored with work today (I can't effectively do much now until Commercial get their act together), so I will have a look at this again over the weekend.

I did solve one major problem last time by having a break and coming back with fresh eyes. Let's hope the same thing happens this time...

The current state of affairs is that when a keyboard interrupt is detected, the interrupt handler (part of the firmware) processes a table that is created to check to see if the interrupt is handled and (if so) by which bit of code.

From what I saw last time, there are multiple tables of PIA/ACIA addresses present. However, the table being processed by the keyboard interrupt does not contain the keyboard PIA - hence it is never handled.

It is almost as though the firmware has not detected the presence of a keyboard at startup, or is being told to ignore the keyboard interrupt.

We end up entering the interrupt handler in an infinite loop. I am just wondering now whether I have correctly implemented the /IRQ processing correctly (although this is in hardware and microcode). I am 99.9% sure I have correctly implemented the hardware for this sub-system within the 4052 emulator, and the microcode is the microcode - so should work now I have shaken (what I think is) all the bugs out of it.

Anyhow, I shall go back to first principles and check the emulator's hardware implementation, then disassemble the microcode for the /IRQ signal and (finally) disassemble the firmware again for the interrupt handler and interrupt tables. Then ponder...

Dave
 
daver2 said:
Got bored with work today (I can't effectively do much now until Commercial get their act together), so I will have a look at this again over the weekend.

I did solve one major problem last time by having a break and coming back with fresh eyes. Let's hope the same thing happens this time...

The current state of affairs is that when a keyboard interrupt is detected, the interrupt handler (part of the firmware) processes a table that is created to check to see if the interrupt is handled and (if so) by which bit of code.

From what I saw last time, there are multiple tables of PIA/ACIA addresses present. However, the table being processed by the keyboard interrupt does not contain the keyboard PIA - hence it is never handled.

It is almost as though the firmware has not detected the presence of a keyboard at startup, or is being told to ignore the keyboard interrupt.

We end up entering the interrupt handler in an infinite loop. I am just wondering now whether I have correctly implemented the /IRQ processing correctly (although this is in hardware and microcode). I am 99.9% sure I have correctly implemented the hardware for this sub-system within the 4052 emulator, and the microcode is the microcode - so should work now I have shaken (what I think is) all the bugs out of it.

Anyhow, I shall go back to first principles and check the emulator's hardware implementation, then disassemble the microcode for the /IRQ signal and (finally) disassemble the firmware again for the interrupt handler and interrupt tables. Then ponder...

Dave
Click to expand...
Dave,

Since the Option ROMs may have PIAs - or in the case of the 4052 Printer Interface MC6850 ACIA, I expected the PIA/ACIA table is updated based on initializing Option ROMs at power up. I see an Option ROM table in the 4000 ROM starting at 0x4315:

1745589750227.png

Maybe the keyboard interrupt is in a different table than the PIA/ACIA table?

Monty
 
This is the sort of thing I am going to be looking at during the start-up. It looks like the table is constructed in RAM, so if the start-up program 'thinks' there is no keyboard, it may not include it in the table.

This is unlike the 4051 where the table appeared to be 'fixed'.

Dave
 
Since Tektronix management wanted the 4052/4054 firmware to leverage the 4051 Motorola 6800 firmware (according to Bob Haas - 4052 microcode engineer - in his vintagetek museum YouTube video: Tektronix 4052 Development and Speed Comparison to 4051) I wonder if you could search the 4052 ROMs for the 4051 keyboard scan code handler - since the 4051 and 4052 have identical keyboards?
 
According to the KEYIN code in the 4051 microfiche in the INPCTL section of the GRAF-MCTCL.pdf the KEYIN process could accept Keyboard input from other devices?

1745593086561.png

I will keep looking for more keyboard routines.
 
Here is a table of 4051 IOKONS constants - interesting to me is the last entry SPCIOF: Special I/O Functions that need to look like a PRINT use this.

1745594279685.png

I am working on disassembling the 4052 Printer Interface ROM code (in a new 4052 Sound Effects board thread on this forum) - that does not have ROM CALLs but does have Special I/O Functions that use the PRINT statement to control the Printer Interface!
 
Dave,

I found the 4051 microfiche section on the Keyboard Processor module source code - now I need to find a section with bytes that I can search the 4052 ROMs for a match.

1745594834312.png
 
Dave,

I think I found the 4052 keyboard interrupt handler!

1745595224209.png

I searched the 4052 4000 ROM for the following HEX bytes from line 21 in the 4051 KBPROC code above: 81 EA 26 04 86 0C and got a hit with HxD at ROM address 6179.
Immediately before this code is 7E63B3 JMP 63B3
and before that is 2601394D2B03

Looks like the 4052 KBPROC Interrupt code! :biggrin:

1745595357103.png
 
Last edited:
The problem is getting there from an interrupt...

Hunting through the hardware and microcode I have found a number of addresses in the constant ROM at address $FEF0 onwards; in particular:

$FEF8 contains the address of the IRQ handler ($5BA2) [microcode $0F2].

$FEFC contains the address of the NMI handler ($F1F6) [microcode $0F4].

$FEFE contains the address to start BASIC ($79F3) [microcode $0CB].

The IRQ handler seems to (a) check the GPIB port for an interrupt and then (b) looks at devices pointed to by a 6-byte table for each interrupt 'source' starting at address $050E.

The only device that I can find in this table is address $FF44 (the ACIA).

My problem is that the IRQ handler is entered, the limited interrupting devices are checked (GPIB port and ACIA) and the IRQ handler exited.

However, at this point, the keyboard IRQ is still active, so the IRQ handler is re-entered...

We then just have an infinite loop...

I will check tomorrow what creates this table starting in RAM at $050E.

Dave
 
I have found the bit of code that creates the interrupt processing table:

Code: 
Write to KEYBOARD PIA [U320] + 2 (ORB) = $2C.
   BUSY-1 = 0 I/O-1 = 0 BREAK-1 = 1
Write to COMMUNICATIONS PIA [U241] + 0 (ORA) = $00.
DER: TEKTRONIX4052.js - BYTE write to address $050E space 1 of $FF from the instruction at address $D948.
DER: TEKTRONIX4052.js - BYTE write to address $050F space 1 of $44 from the instruction at address $D948.
DER: TEKTRONIX4052.js - BYTE write to address $0510 space 1 of $80 from the instruction at address $D948.
DER: TEKTRONIX4052.js - BYTE write to address $0511 space 1 of $D4 from the instruction at address $D948.
DER: TEKTRONIX4052.js - BYTE write to address $0512 space 1 of $A9 from the instruction at address $D948.
DER: TEKTRONIX4052.js - BYTE write to address $0513 space 1 of $28 from the instruction at address $D948.
DER: TEKTRONIX4052.js - BYTE write to address $0514 space 1 of $00 from the instruction at address $D39D.
DER: TEKTRONIX4052.js - BYTE write to address $0515 space 1 of $00 from the instruction at address $D39F.

$FF44 is the communications ACIA (as I have deduced from the disassembly of the IRQ handler code.

Now to see what this code is around $D948 and $D39D...

Dave
 
Dave,

How close does the 4052 Interrupt service routine disassembly look like the 4051 Interrupt service routine?

1745668014976.png
My search of the 4000-ROM showed a match for HEX C8DF... (lines 24-28 in the 4051 INTSVC source) at 5BE1 - near your 5BA2 IRQ handler start address.

1745668631394.png
 
I know your 4052 Emulator is running the ALU microcode and BASIC ROMs - but I was trying to see if the 4052 Assembler document indicated where the PIATBL was located - didn't find that but did run across this description of how the microcode handles returning from interrupt. Don't know if you already knew it was different than the 6800 behavior:

1745669276493.png
 
Dave,

I took your emulator ROM HEX data for each ROM from your 4052 Emulator TEKTRONIX4052.js file and created BINARY ROM files. The resulting 4000, 8000, C000 binary files each had a proper size of 16KB each.

But the E000 ROM in the RAM area also has a file size of 16KB - which is double the 8KB size it should be. So your emulator may NOT be loading that ROM properly?

The 4052 Emulator should ignore the lower 8K of 'FF's and load E000-FFFF in RAM space starting at 2000 in the E000 RAM space ROM - but you probably already do that properly.
 
Last edited:
You must log in or register to reply here.
Back
Top