• Please review our updated Terms and Rules here

Tektronix 4052 Troubleshooting

nikola-wan said:
... and ran the ROM CRC Test, ALU Test and long and short RAM tests - all with no issues found.
... I have 4052 V5.1 ROMs - no patch ROMs and they all check out fine according to the list.
Click to expand...
Hi Monty,

thanks again for the CRC crosscheck. I ran a series of CRC tests today and noticed I get different CRCs for U805A/B and U897A/B each run -- see attachments below (sorry for the crappy quality, I used my old iPad as backup digicam). The other ROMs match yours and the published values. I also have v5.1 running on (as I now discovered) a rev04 MAS; maybe that's not a valid combination. I have the rev09 on which the ROMs were originally installed as spare.

IMG_7134.jpgIMG_7131.jpgIMG_7132.jpgIMG_7122.jpgIMG_7133.jpgIMG_7130.jpg

I also get SYSTEM ERRORs whenever I try the READ statement; that command defaults to device @34 (DATA statements) but actually reads from tape, then bails out with the error, probably after encountering a TRAP. The error code mentions what looks like an address in the 46XX range:

IMG_7117.jpg

46XX is infact occupied by U805 and U897. I suspect these chips are actually installed on my MAS, even though they shouldn't be, and maybe even flaky on top of that. I understand these are patch ROMs which are no longer required for v5.1.

Looks like I will have to pull those boards again (*groan*) and check what's on the MAS. I may also have to swap for the rev09 board, all other things being equal...

Btw, any update on that dastardly display dilemma?

--Roland
 
Last edited:
Ok, I'm the wiser now.

I swapped the MAS with the rev09 and installed the v5.1 ROMs as per the original config. NOW I get the reference CRCs:
IMG_7199.jpg

The READ statement now performs as expected (here without DATA in immediate mode) and doesn't trigger a SYSTEM ERROR anymore:
IMG_7201.jpg

So apparently the newer ROMs don't fully work in older MAS boards. I suspect there are subtle differences in the address decode logic that categorically enable the patch PLA and ROM sockets on the old boards, even if nothing's installed. It does raise the question why those sockets are still on the newer boards, tho. As for the significance of the U820C/D and U870C/D CRCs the DRP spits out... beats me.

Anyway, after lots of (literal) screwing around I tried the Gumowski listing cited in the Tek4051/52 emulation thread (Hi Dave!), and it worked as expected. Quite mesmerising to watch:
https://www.dropbox.com/s/1l2b9g429f9o98c/gumowski-tek4052.MOV?dl=0

Monty, please keep us posted on your end and good luck!

--Roland
 
Hi Roland...

I have been having a little look at the patch ROMS and the main ROMS again. I may be able to help with the U805/U897 A and B (or at least toss in my 10 cents)...

It looks like the small patch ROMS can be either 74S471 (256 bytes * 8) or 74S472 (512 bytes * 8). This fits with the address range from 4400 to 47FF (1K). 2 chips (odd/even) each of 512 bytes (max) = 2*512 = 1024 bytes. If you plug a 74S471 in - you will get two copies of the same thing (one shadowed) in the address space. I wonder if the DRP has split this memory area up into 2 (indicated as A and B on the display)? If the address space was treated as a single CRC - you would get a different CRC if you installed a 74S471 (shadowed) to installing a half programmed 74S472. Just a thought...

There may also be more to the U820/U870 ROM than we first thought... There seems to be valid data in the bit of ROM inside U820/U870 that overlays the patch ROMs. I thought this was a bit strange. But suppose it is possible that this ROM contains a number of separate 'bank switched' areas. I think this is what they mean by the A/B of the missing ROMS mapping onto the C/D of U820/U870.

Let me think about that one a bit more.

Have you (by any chance) seen a full schematic for the newer (A) MAS board? The schematic in my documentation (that has the ROMS) is critically missing (dooooo).

Dave
 
daver2 said:
There may also be more to the U820/U870 ROM than we first thought... There seems to be valid data in the bit of ROM inside U820/U870 that overlays the patch ROMs. I thought this was a bit strange. But suppose it is possible that this ROM contains a number of separate 'bank switched' areas. I think this is what they mean by the A/B of the missing ROMS mapping onto the C/D of U820/U870.
Click to expand...
Hi Dave,

that is strange, but so is everything about the 4050 series. The service manual confirms the 256/512 byte patch ROM size on page 7-23, and goes on to say:
"The patch ROMs are used for patching large sections of memory and are accessed by the instructions executed from the FPLAs."
Click to expand...
But if the FPLAs are missing, why were the missing patch ROMs (presumably) being addressed on the rev04 MAS, resulting in rubbish data? My guess is that the rev04 is "hardwired" to address the patches, while the rev09 isn't. After a lengthy visual inspection I saw no difference between the two boards. There is a tiny address decoder ROM U250, a 74S288, on both MAS. I suspect these may be different, although the labels (-033900) are identical.
Have you (by any chance) seen a full schematic for the newer (A) MAS board? The schematic in my documentation (that has the ROMS) is critically missing (dooooo).
Click to expand...
I may have intentionally removed it from my annotated PDFs of the service manual, to avoid confusion. I've since revised my PDFs and merged with the original pages, and organised them into separate files per revision. The 4052A MAS schematics are here:
https://drive.google.com/file/d/1S7rgJVbqi9uqqaHjyT6DfV1vQsi8_80z/view?usp=sharing

Happy pondering, :)

--Roland
 
I've made no progress on the oscillation in the 4052 - as it is a loop.

I guess I have to break the feedback loop to see where it starts - if it does.

Roland's post of the 4052A MAS schematics got me looking at my 4054A Upgrade Kit instructions. I posted the Kit Installation PDF here:

https://drive.google.com/file/d/1RIf2M7FFztswWBYEUHf5PjDL4rY6S-9R/view?usp=sharing

and I also found a FIRMWARE INSTRUCTIONS manual with the kit for 4052/4054 Version 5.1 and 4052A/4054A Version 1.3. Here is my scan of that short manual update:

https://drive.google.com/file/d/18djz2dqPUkuWsFnw_a6dubdyZgAyfWGz/view?usp=sharing

I saw this comment on page 6 "if you are using a 4054A or 4054 with the Field Upgrade Kit to Version 5.1, program 8, "Special 4054 Features", will not work until you make the following corrections". And then they list the change to the RND(0) to detect the version.

Ok - I checked the PLOT50 files from Roland and file 103 checks for the output of RND(0) and there must have been an issue with the result because the fix multiplies the RND(0) value by 10 and then checks the first digit of the result for 8 or 5 and if a match runs file 104. The "Special 4054 Features" in file 104 show the graphical cursor moved by the thumbwheels on the keyboard and the scalable fonts and dashed line drawing capabilities.

The rest of the FIRMWARE INSTRUCTIONS are PLOT50 BASIC errata and suggested workarounds.

The A upgrade instructions cover the 4052 and 4054 upgrades to 4052A and 4054A.

In both cases - ALU ROMs are upgraded, the MAS board is replaced with 672-7624-00 or greater - move the extra memory to the new MAS board, and the I/O board is replaced.

Since the I/O board is completely different on the 4052 and 4054, the kit will only work on one model. I've got the 4052A full-size I/O board so my kit will go on my 4052 after I get it working again.

I just updated the post - I thought I had the 4054A kit since one of the boxes had that label - but I checked the boards and I have a full size I/O card with TI 9914 GPIB controller!

Monty
 
Last edited:
Roland,

That "SYSTEM ERROR" is crazy!

I certainly haven't seen any documentation for such a thing. The 1982 Reference Guide has all the BASIC ERROR codes - they are numbered from 1 to 109.

Monty
 
Some more thoughts - but this is all supposition! I leave it to those with 'real machines' to validate what I am saying...

In the 'old days' of the Tektronix machines they would have produced mask programmed ROMS to hold the BASIC interpreter etc. Because of the high cost of producing mask programmed ROMS you aren't going to produce new devices to fix the inevitable software bugs that would be present. So, Tektronix used FPLAs and small patch ROMS.

Without the FPLAs and patch ROMs - the machine would work - albeit with the bugs that were present within the mask programmed ROMs.

If a 'patch' was needed, an address (plus the associated data byte) would be programmed into an unused position in the FPLA. For each and every byte that needed to be patched in the ROMs - a new entry would be needed in the FPLAs. For a simple one or two byte patch - this would be fine. For anything more complex (say a 20 byte fix to a subroutine) this method would not be practical. To overcome this, the FPLA could 'force' a JMP instruction to overlay the offending area of the mask programmed ROM which would JUMP to an area in the small patch ROMs. The patch ROMs (256 or 512 bytes) could then hold the required patch.

The FPLA and patch ROMs could be 'upgraded' to incorporate new patches as they were required - but the mask programmed ROM would have to stay as it was.

This leads me to the following conclusions:

1. Removing the FPLA and patch ROMs, the Tek machine should still work (albeit with the original bugs).
2. The FPLA and patch ROMs are related to a specific mask programmed ROM set. After all, they patch what is in the mask programmed ROM!
3. You could have differing FPLAs and patch ROMs that go with a specific set of mask programmed ROMs. After all, subsequent bugs could be found after a set of FPLA and patch ROMS were issued.
4. You should be able to remove the FPLAs (but leave the patch ROMs in place). This would default to using the mask programmed ROMs only (and the original bugs would return as a result). However, the patch ROMs would appear in the address map and would contribute to their CRCs. Nothing in the mask programmed ROM should (however) attempt to execute anything in the patch ROM (as the FPLAs would have been removed which would have caused this action).
5. The FPLA and patch ROMs themselves should be considered a 'set' (i.e. you shouldn't mix and match the FPLA and patch ROMs).

I suspect the "SYSTEM ERROR" is an internal check only that should never be triggered under normal circumstances - hence the reason it is not documented. There is nothing the user could do about it. In this case, it may result from 'mixing and matching' the mask programmed ROMS, the FPLAs and/or the patch ROMS. We do a similar thing with our own internal operating systems and compiler tools at work. We put 'sanity checks' in that should always pass - unless someone has been 'fiddling' with the software or a serious hardware problem is corrupting things. We try to report this as a system error and for the user to contact the support line (i.e. me).

Having written all this, I then looked at the MAS schematics again...

The ROM address space seems to be split into four:

0000 - 3FFF
4000 - 7FFF
8000 - BFFF
C000 - FFFF

The area from 0000 - 3FFF appears to be reserved for the bank switched ROM cartridges - so can be ignored.

The areas from 8000 - BFFF and C000 - FFFF appear to directly doecode for the ROMS on the MAS board.

The area from 4000 - 7FFF is allocated to a MAS ROM (U820 and U870) but the address decoding appears to disable part of the ROM:

U280B and U450B decode for addresses 0100 01xx xxxx xxxx (i.e. 4400 to 47FF). This appears to be the area occupied by the patch ROMS (U897 and U805).

The address space from 4000 - 43FF and 4800 - 7FFF appears to be always allocated to U820/U870. Interesting, this is two parts to these ROMS - I wonder if this is why U820 and U870 has an A and a B descriptor?

My guess would be (from looking at the schematic) that the address range from 4400 - 47FF within U820/U870 remains permanently unused and is permanently mapped to the patch ROMS U897/U805.

From my earlier post, U897 and U805 may be either 256 bytes or 512 bytes in size, hence they may be treated as two separate 256 byte entities (and hence the A and B designators for these devices).

The DRP can't really determine if the FPLAs are present or not; or whether the patch ROMS (U897 or U805) are present or not. All it can do is to calculate the CRCs for the address range and leave it up to the human to work out whether what is displayed is correct or not based upon the observed MAS configuration.

Let us now assume that Tektronix move away from mask programmed ROMS and towards EPROMS. Because of the ease of erasing and reprogramming EPROMS, there is now no need for the FPLAs and patch ROMs. The updates can be released on a new set of EPROMS.

I notice in the documentation that it states that newer MAS boards can disable the patch ROM logic by means of J419(?) My understanding of this statement is that this now releases all of the memory from 4000 - 7FFF to be allocated to the EPROMS for U820 and U870. In principle, this now frees up an additional 1K of EPROM to be used by the Tektronix programmers.

Newer boards could then be manufactured without the sockets for the FPLAs, patch ROMS or the address decoding logic.

Back to the DRP - it doesn't 'know' what configuration it is running on (i.e. an 'old' configuration with either 256 or 512 bytes of patch ROM or a 'new' configuration with no patch ROMs at all and the space occupied by EPROM). I would guess that the DRP will continue to report the U820A/B, U870A/B, U805A/B and U897A/B CRCs whether these devices are fitted or not.

If the DRP is fitted to a 'new' system with no FPLAs or patch ROMs, then (effectively) the U820/U870 EPROMs are 'split up' into four 'logical' devices (as far as reporting the CRCs are concerned) but the associated bytes are all physically stored in the two devices (U820 and U870).

4000 - 43FF = jump table from U820/U870. Let's say logical area 'A'
4400 - 47FF = what was the patch ROMs - but this areas is split into two to accomodate either 256 byte or 512 byte devices. Logical areas 'C' and 'D' - but indicate as areas 'A' and 'B' of U897 and U805.
4800 - 7FFF = remaining part of U820/U870. Lets say logical area 'B'.

That seems to make sense to me - but it all may be wrong of course...

Thoughts?

Incidentally, the link you posted to in #24 still seems to be missing schematic 6 of 7 (containing the ROM schematic) I think.

Dave
 
Last edited:
nikola-wan said:
Roland,
The only MAS and I/O diagrams I have from your annotated set are 4052A - NOT 4052.
Click to expand...
Hi Monty,

I have the 4052/4052A MAS and I/O diagrams in separate files here:
https://drive.google.com/drive/folders/1SXnOIuXbjfnIsdgU4N2Bj9BSXxX9uyZu?usp=sharing
I renamed the files to be a bit more descriptive as I constantly found myself shuffling through them until I found the relevant sections. Note that some of my annotations may be outdated or only apply to a certain MAS/ROM combination I was testing with.

Happy troubleshooting,

--Roland
 
daver2 said:
U280B and U450B decode for addresses 0100 01xx xxxx xxxx (i.e. 4400 to 47FF). This appears to be the area occupied by the patch ROMS (U897 and U805).

The address space from 4000 - 43FF and 4800 - 7FFF appears to be always allocated to U820/U870. Interesting, this is two parts to these ROMS - I wonder if this is why U820 and U870 has an A and a B descriptor?

My guess would be (from looking at the schematic) that the address range from 4400 - 47FF within U820/U870 remains permanently unused and is permanently mapped to the patch ROMS U897/U805.
Click to expand...
Hi Dave,

thanks for racking your brains over this. This suggests that the rev04 and rev09 MAS boards differ in how U280 and U450 map the addresses 4400-47FF. Your guess is confirmed by the fact that both v4.x ROMs at U820/U870 from the rev04 MAS contain nothing but FF in the range 200-3FF. With the 16-bit architecture and the decoded address base, that corresponds to 4400-47FF. In contrast, the same range in the v5.1 ROMs from the rev09 MAS contains valid data. Btw, these are also mask programmed, not EPROMs. Only the 4052A has the latter.

I notice in the documentation that it states that newer MAS boards can disable the patch ROM logic by means of J419(?) My understanding of this statement is that this now releases all of the memory from 4000 - 7FFF to be allocated to the EPROMS for U820 and U870. In principle, this now frees up an additional 1K of EPROM to be used by the Tektronix programmers.
Click to expand...
This must only apply to the 4052A; I haven't seen that jumper on the 670-6030 MAS boards. Can you point me to where this is documented?

Incidentally, the link you posted to in #24 still seems to be missing schematic 6 of 7 (containing the ROM schematic) I think.
Click to expand...
I'll check the original PDF; it may actually have been missing there. Or I was a bit overzealous when I removed some (annoying) empty pages.

I'll also have to revise some of my annotations indicating the address ranges occupied by each ROM in the schematic.

--Roland
 
>>> This must only apply to the 4052A; I haven't seen that jumper on the 670-6030 MAS boards. Can you point me to where this is documented?

http://bitsavers.trailing-edge.com/...echnical_Service_Manual_Section_7_Oct1983.pdf on page 7-22 (PDF page 25/28) - last paragraph on the page.

Yes, I think the 'new' MAS board refers to the "A" series where "the mask programmed ROMS, Patch FPLAs and patch ROMS have been replaced by 2764 type EPROMS". It also mentions about an additional two EPROMS and an internal bank select register.

Regards,

Dave
 
Hi Dave,

I've uploaded the original service manual PDFs as I received them from (I think) Philip Belben here:
https://drive.google.com/drive/folders/1FtdOXV9TaqXiox-Ckcf4CZiNeHK896_7?usp=sharing
Note there are many empty pages and different board revisions are merged into one chapter/file, which I found very confusing. More importantly, page 6 of the 4052A MAS is indeed missing there too! (See 4052_schematics-chap07-05). I guess we're stuffed now! :?

--Roland
 
>>> More importantly, page 6 of the 4052A MAS is indeed missing there too! I guess we're stuffed now!

We still have plenty to get working for the 4052 yet...

We'll worry about the 4052A and the 4054 later on!

Dave
 
I just did a long RAM test on my 4052 before taking the train back to Switzerland, only to realise my rev09 MAS actually has a faulty parity RAM (U645, upper even bank) -- something I'd have probably never realised without the DRP! This prompts another big thanks to Jos for making this essential tool available! :thumbsup:

I'll leave this chipswap for next time tho...

--Roland
 
daver2 said:
>>> This must only apply to the 4052A; I haven't seen that jumper on the 670-6030 MAS boards. Can you point me to where this is documented?

http://bitsavers.trailing-edge.com/...echnical_Service_Manual_Section_7_Oct1983.pdf on page 7-22 (PDF page 25/28) - last paragraph on the page.

Yes, I think the 'new' MAS board refers to the "A" series where "the mask programmed ROMS, Patch FPLAs and patch ROMS have been replaced by 2764 type EPROMS". It also mentions about an additional two EPROMS and an internal bank select register.

Regards,

Dave
Click to expand...

Dave and Roland,

Al has been very quick to add my Tektronix manual scans to bitsavers :)

I scanned the 4052A MAS schematic page 4-6.

The jumper is at the bottom of the page:

https://drive.google.com/file/d/1M0QhhHUjuWeD0slUhghtnNbtenilFgkN/view?usp=sharing

Monty
 
Tektronix 4052A MAS board and 4052A I/O board photos

Tektronix 4052A MAS board and 4052A I/O board photos

Guys,

I decided to take pictures of the 4052A MAS and I/O upgrade boards.

Tektronix 4052A MAS board

Tektronix 4052A I/O board

Looks like my MAS upgrade board has V 1.5 4052A EPROMs. The CRCs are not listed in Jos' pdf file for that version.

I checked my DATA-IO downloads of my Tektronix ROMs and I didn't find any of those downloaded - so I hope they all work :)

Wow - looking closer at my I/O board - the date codes on some of the ICs are 1984! the board is dash 03, so maybe one of the last boards built?

Monty
 
Last edited:
4054A MAS board and I/O board

4054A MAS board and I/O board

Good grief - I keep changing my mind, but maybe the boards can be used in either system?

Here is a photo of the upgrade kit box - clearly marked 4054F39 kit:

4054A Upgrade Kit Box

Here is a photo of the ALU ROMs that came with the kit:

4054A ALU ROM set

I also took photos of my 4054 MAS, I/O and bits of the ALU board. Looks like v4.1 ROMs in the MAS board (no patch ROMs installed)

Since Jos' diagnostic board CRC list doc does not show different CRC for 4052 and 4054 ROMs - I think the new "A" MAS ROMs and ALU ROMs would work on either 4052 and 4054 with the new MAS and I/O boards.

We will see - when I get either one of the 4052 or 4054 working properly.

Monty
 
I just checked my 4052A/4054A MAS board - J419 is removed on my upgrade board. I don't see any sockets for patch ROMs.

The last page of my post of the 4052/4054F39 upgrade kit instructions list three jumpers that must be installed on the new MAS board (J419 is not one of them), one on the new I/O board and one on the ALU board.

Monty
 
one more post before I start troubleshooting again :)

The difference in the upgrade kits is the I/O board.

The F39 manual lists the 4052A new I/O board as part number 670-7629-00 or higher.

The manual lists the 4054A new I/O board as 670-7630-00 or greater.

My upgrade I/O board is 670-7630-03.

Which confirms it is a 4054A upgrade kit and cannot be used on the 4052.

The bitsavers 4054 schematics don't have the 4054A boards - but Roland's post of the 4052A schematics show the new MAS and new I/O boards for the 4052A - so I guess I could use those if I have to debug the new boards.

Doooh' - I have the 4052/4052A schematics hard copy. The 4054A I/O board just has the higher resolution x/y DACs.

Monty
 
Cheers Monty. All will come to those who wait!

I have seen a sketch of the 4052A MAS in one of the Tek documents - and your schematic confirmed what I thought regarding the removal of the FPLAs and patch ROMs - although it did throw up the interesting item that the 'extra' EPROM lives from 0000 - 3FFF (I wondered how the extra EPROM appeared in the memory map. Now I know)!

Looks like J419 just completely disables the on-board ROM to me (so not as interesting as I had first guessed).

Dave
 
You must log in or register to reply here.
Back
Top