• Please review our updated Terms and Rules here

Tektronix 4052 Emulator

I think I have worked out where I have gone wrong with the X and Y coordinates for the text.

I think I have misunderstood the order of the 8-bit port (Port B) and the two (2) bits from port A that make up the 10-bit coordinates.

Also (from the value of the resistors) the XCHAR and YCHAR appear to contain a lower-value resistor at 2k.

The X (an Y) coordinates have resistor values ranging from approximately 2M down to 4k (in powers of 2) whereas the XCHAR (and YCHAR) coordinates have resistor values of 8k, 4k and 2k.

These are the 'facts'. I now just have to work out the implementation...

Dave
 
Dave,

I've been examining my disassembly of the 4052 Printer Interface ROM.

Since 4052 Option ROMs are bank switched to 0000 in the ROM space - I see instructions that write to low (like first page) addresses.

I know the 4052 CC register has separate DATA and FETCH space indicators.

Does the 4052 microcode default to execute out of ROM (F=1) with D=1 (RAM)?
 
If my memory serves me correct - yes it does.

Interestingly, there is an SFA instruction (set Fetch space to A) that clears the F bit (and, therefore, executes code from RAM) but there is no corresponding SFB instruction. So I wonder how the instruction set swaps back to ROM space again?

Dave
 
4052A Assembly manual says assembly code in RAM uses SWI instead of JMP to access ROM entry points in the table at 4000, and that code is responsible for getting back to RAM (maybe because the CC register with original D and F was pushed on the stack and CC is restored on the RTN?).

Here is their example 4052 assembly program:

Code:
EXAMPLE: CALL "EXEC",EX$,REL$

0000:                     PUTCHR=4063
0000:    4F               CLR A     
0001:    3F 4063   LOOP:  SWI PUTCHR 
0004:    4C               INC A
0005:    27 03            BEQ DONE
0007:    7E 0001          JMP LOOP
000A:    39        DONE:  RTS

To represent this code, EX$ and REL$ would have these values:

       EX$ = 4F 3F 40 63 4C 27 03 7E 00 01 39 (HEX)
    
       which would be coded as:
       EX$="0?@cL'C~@A9"
    
       and
    
       REL$ = 00 00 00 08 (HEX)
    
       coded as:
       REL$="@@@H" (where all four are underlined control characters)
 
Last edited:
That will be it. I forgot about SWI. I did remember about RTN though - but couldn't think of it's side kick!

The code I had used for X and Y coordinates on the 4052 IS a copy of the 4051 code. I need to add a few more debug statements to see what is going on.

I added some debug statements to see what is going on with the F flag though.

The F flag is set to 1 by the microcode before executing any instructions.

The start-up code and keyboard interrupt (in fact nothing) then plays with the F flag UNTIL I press the <return> key.

The F flag is reset to 0, and this coincides will all sorts of mayhem breaking out!

I suspect this is the next flaw in my 4052 emulator to fix...

Dave

1745863490194.png
 
I typed 'listy' instead of 'list' and received the following error message (this time as expected):

1745864723136.png

Ignore the 'yellow' blocks. They are the un-erased cursor...

This time, the F flag was not changed - and the code survived! So I am definitely on the right track with my 'delayed F flag' modification.

The coordinates for the alpha dots appear to be drawn correctly though - so there must be something outside of my screen drawing code somewhere.

The 'L' is drawn at X=0 Y=767. The 'I' is drawn starting at X=14, Y=767.

'S' at X=28, Y=767.
'T' at X=42, Y=767.

I have a meeting shortly - so possibly no more time to play tonight...

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.

View attachment 1292370
Dave,

I think this table ONLY applies to the original 4052/4054 microcode that you are using for your 4052 Emulator.

The A and B registers are NOT 16-bit wide for the v5.1 ALU microcode.

Both A and B were widened to 16-bits in the A-Series v1.5 ALU microcode according to the 4052A Assembler documentation pdf page 8 and page 10 has the new opcodes for the A-Series (4050GX) along with the 6800 opcode extensions.

PDF page 75 shows the 6800 ABA opcode was extended to ADD 16-bit B and 16-bit A registers in the A-Series ALU microcode, so the Table 6-1 would have to change for the A-Series ALU microcode to show the 16-bit A and 16-bit B registers as noted in my WIP - Tektronix 4052-4054 opcode Decoding tables.pdf document posted on my github repository in the 4052A-Assembler uni format directory:

1745887999995.png
 
I am not sure where the above post fits in our current discussion?

Anyhow, there appears to be a consistent inconsistency with the X coordinates:

1745916156001.png

It is almost as though the least significant bit of the X coordinate (and presumably the Y coordinate by extension) is not used...

Either that, or there is a very subtle change in the circuitry between the 4051 and 4052.

Dave
 
Dave,

Do you have the 4052/4052A Parts and Schematics Service Manual Aug 1983?
This was posted on https://w140.com/tekwiki/wiki/4052 in two parts as it is so big. Schematics in the 2nd half.

Here is the 4052 I/O board schematic page for the X and Y D/A converters:

1745923290105.png
 
Last edited:
I am not sure where the above post fits in our current discussion?

Anyhow, there appears to be a consistent inconsistency with the X coordinates:

View attachment 1300078

It is almost as though the least significant bit of the X coordinate (and presumably the Y coordinate by extension) is not used...

Either that, or there is a very subtle change in the circuitry between the 4051 and 4052.

Dave
Dave,

I posted the register page because I thought you had mentioned you put 16-bit registers for A and B in the 4052 Emulator?
The original 4052/4054 microcode only supported 8-bit registers for A and B - even though the 2901 registers were 16-bits wide.

The 4052A/4054A added 6800 opcode extensions including extending the A and B register opcodes to support 16-bits.
 
Yes, I have all of the schematics. These are where I took the emulation from in the first instance...

The document is correct (regarding the sizes of the A and B registers), but for the wrong reasons.

My 'bug' was a genuine error on my part - that was fixed...

The register set consists of 16 'generic' registers, each of 16 bits - even for accumulators A and B.

The microcode can treat the ALU in an 8 or 16 bit manner. By this I mean that the microcode contains a field (FIELD 4) that defines an 8-bit transfer to/from data space (FIELD 4 = 4) or a 16-bit transfer to/from data space (FIELD 4 = 5).

Likewise, the instruction is fetched into latch U225 and ROM U210 decodes the instruction into the operand type and addressing mode - in particular, whether the operand is 8 or 16 bits in size.

Because ALL of the registers are 16-bits, the microcode can 'play games' with the ALU itself:

1. The condition code register flags can be set from either the low byte of the ALU or all 16-bits of the ALU.
2. When shifts or rotates are being performed by the microcode as part of the ALU operation, the ALU can be configured as either a 16-bit shift/rotate machine or an 8-bit shift/rotate machine by 'breaking' the 4-bit ALU slices into two 8-bit sections and manipulating the 'in' and 'out' of the shift/rotate machine.

By default, the microcode treats registers 0 and 1 (accumulators A and B respectively) as 8-bit quantities. But that does not actually mean that the upper byte of these registers is actually 0.

Hence, the document is correct that accumulators A and B 'appear' as an 8-bit register (by the operation of the microcode) - but the accumulators are actually implemented using a 16-bit register.

I think I am going to spend a little bit of time in improving my microcode disassembler so that I can get a more 'English' output from the disassembly. A lot of the Tektronix source for the microcode is not well commented at all. I wonder if there is a better copy of the microcode listing. This would be useful for the microcode labels where the scan is unreadable.

Dave
 
I created the pdf of the 4052/4054 ALU microcodes from the microfiche scans here:
https://w140.com/tekwiki/wiki/067-0942-99

You have probably seen my WIP - Tektronix 4052-4054A opcode Decoding tables.pdf in which I reformatted the opcode pseudocode operations into that document from the 4052 Assembly doc.

I just reprocessed the ALU original resolution microcode pages with PhotoDemon to invert the negatives and then convert to 256 shade grayscale pdf - hope this helps a little bit.

Too big to post here, so I posted them on my repo:
Tektronix 067-0942-99 4052-4054 ALU Microcode Listing.pdf
 
Thanks. I will have a look.

I have to go and do some mowing now, and then I am going out tonight.

I took a look at the raw fiche - and the text that I am having trouble reading in the PDF files is pretty unreadable on the raw fiche also. I will see what I can recover from the PDFs as labels.

Dave
 
I'm working through my disassembly of the 4052 Printer Interface ROM and see that my first encounter with a 4052 opcode: 14 Hex (unused in 6800), "ADXI" (4052 Assembler page 20) has not been entered into my WIP 4052 opcode document.

My first pass through the 4052 Printer Interface disassembly was to find the FCB entries and add new line above and below so they would be easy to find and fix.

I think the current WIP doc only has the 6800 opcode extensions for the 4052A/4054A added - which doesn't help the 4052 Assembler.

I am using color coded opcode text in the WIP document to delineate:
  • Black opcodes are standard 6800
  • Red opcodes are added for 4052/4054 (and also work in 4052A/4054A)
  • Blue opcodes are 4052A/4054A ONLY
  • Green opcodes are 4052A/4054A ONLY 16-bit register extensions to 6800 opcodes - and backwards compatible with 6800
Time to add the new 4052/4054 opcodes into my WIP document.
 
Here is my first pass of adding the 4052/4054 opcodes into my document - and there are a couple of 4052A/4054A opcodes because they have comments comparing to the 4052 opcodes.

I will now continue my 4052 Printer Interface disassembly by inserting the 4052 opcodes and checking that the code might work with that opcode.

@daver2, apparently the 4052 microcode got the Negate instructions CARRY bit the opposite of the 6800 - fixed in the 4052A microcode. See page 36 of the 4052A Assembler doc:

///// WARNING \\\\\\

The 4052/4054 microcode set the Negate CARRY bit exactly opposite of how it is set in the 6800 and 4052A/4054A!!

See 6800 manual

BTW - I haven't fixed the opcode links from the first table in the detailed listing yet. Many of them go to the original 6800 opcode document website in .cz
 

Attachments

Last edited:
I changed the colours of the cursor and text on my emulator screen (so I can read the text now...).

I also added the DELAYED_CCRF flag (Condition Code F flag) to only take effect on the fetch space immediately after a "PC = ALUOUT" type of microcode instruction. I removed a lot of debug code and increased the instruction execution rate per cycle of the emulator operation.

This 'changed' the operation of the emulator, but did not fully 'fix' it. I suspect there is still an internal 'timing error' to rectify.

I will add some further debug code to my emulation so I get a full instruction trace as soon as the emulation executes a SFA instruction to see exactly what is going on...

The 'real' hardware consists of a number of clock cycles, where various different activities take place within each clock cycle. The emulation contains the clock cycles - but I have not enabled them as of yet. I was hoping to avoid this - as implementing 'clock cycles' will slow down the emulator. I am still convinced (in the back of my mind) that what I have done (by not implementing at least two (2) clock cycles per microinstruction) may not work...

However, so far, I have been able to 'fix' my way out of trouble...

Dave
 
I have just added some more debug code - and totally confused myself!

Time to vegetate in front of the television and think a bit more...

Dave
 
I have just spent an hour or two 'playing' with the latest 4052 emulator and I am noticing a few strange occurrences.

For example, when typing LIST, I get part way then the screen erases. I have some debug code that I enabled, and there is a whole load of ERASE CRT and COPY CRT diagnostic messages output:

1746382717323.png
The Key codes of 49 and 53 is the 'I' and 'S' of LIST respectively. The code has spotted the release of the 'I' key and the depressing of the 'S' key. It then proceeds to do some 'strange' things with the PIA to initiate COPY and ERASE actions?

The microcode (uPC) is implying that we are in the IRQ part of the microcode - and hence (my guess is) the code should be saving the registers into RAM rather than playing with PIA!

The emulation does, however, appear to recover after this - which is why I possibly never noticed it before.

Let me play more...

Dave
 
Possibly another subtlety of this pesky 'DELAYED_CCRF' flag?

1746383870908.png

CCRF=1 means ROM space.

DELAYED_CCRF=0 means RAM space.

I wonder if there is a signal to clear (or override) this pesky latch under certain circumstances?

Dave
 
Back
Top