Image Map Image Map
Page 1 of 6 12345 ... LastLast
Results 1 to 10 of 52

Thread: Tektronix 4052 help....

  1. Default Tektronix 4052 help....

    I have a Tek 4052, or at least most of one, I'm missing the tape drive and some of the case parts. I received it mostly as parts. I'm trying to bring it back to life. I currently have it set up in a diagnostic configuration, spread out on a table so I can get to the board test points. I have a known good DVST, tape drive, keyboard (from my working 4051) connected to the boards. The 4052 power supply powers up with the correct voltages. I have tested the 7 microcode ROMs on the ALU (checksums correct). My testing tools include several oscilloscopes, a 7D01 Logic Analyzer plugin, and the diagnostic ROM Pack. I have version 5 microcode. Version 4.? firmware. 56K RAM.
    So far, it powers up, but I can't clear the screen, just a green display.
    The power & busy lights are on.
    The two LED's on the ALU board: DS190 on solid, DS195 flashes at about 1 hz
    The four LED's on the MCP board: DS1, 2, 3 on, DS4 has a short flash at about 2Hz, DS2 & 3 flash off briefly when DS4 flashes on.
    Looking at the test points on the ALU board with the logic analizer, it seems to be executing instructions instructions with the microcode. The manual seems to indicate the ALU will halt at selected addresses if the power-on self test detects problems. This doesn't seem to be occurring.
    Also, if the system detects bad RAM the MCP board program counter is supposed to indicate the bad RAM chips, I can't really tell if this is occurring.
    The program counter (on power up or when I press reset on the diagnostic rompack) seem to pulse each of the address lines in sequence and then addresses about 3000H, 5000H, 6000H, 7000H, 9000H (see photo, note that bit 11 on my 7D01 doesn't work, bad probe), and then seems to be executing code around 7D4FH.
    I'm not sure what to check next. It seems common to have bad RAM, but the lower bank is soldered in, and I would rather not just randomly start de-soldering RAM chips. Is there source code available anywhere so I can see where the program may be stuck? Can anyone provide any suggestions where to go from here?
    Thanks,
    Clay

    First photo: after reset, Program Counter on J266, LSB on top. 2nd photo, PC (J266) about 30 seconds later (looping).
    20190706_193924.jpg20190706_193823.jpg

  2. #2
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    3,155

    Default

    Hi,

    About to run off to work, but will get back to you at some point (or some of the other Tekies will)!

    If you hunt around on VCFED you will find a similar issue that we fixed on another 4052.

    There is also a diagnostic pod available - but maybe for the 4051 only? It's been that long since I have played with Tek kit.

    Monty is the main man around here!

    Dave

  3. #3
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    3,155

    Default

    Found Jos's 4052/4054 diagnostic ROM pack thread at http://www.vcfed.org/forum/showthrea...OM-pack-remade.

    Need to look into your specific microcode halt next... I will have to dig out my documentation...

    I have written a Javascript emulation of the 4051 and I keep 'fighting' with my update to the 4052... We have various bits of information that we have put together about the operation of the internals of the 4052 microcode and ROM/RAM - but nothing probably understandable by anyone else (if you get my meaning).

    Let me have a look for the repair thread to the 4052 or 4054 for you.

    Dave

  4. #4
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    3,155

    Default

    Maybe a good idea to read this thread http://www.vcfed.org/forum/showthrea...-from-Tek-4052.

    There is a lot (and I mean a lot) of technical stuff on that thread regarding the 4052 and what we disassembled. Reading it again myself brought back the memory of the sleepless nights !

    At the very end you will see where Monty joined... and the rest is history as far as Monty's resurrections of everything Tektronix is concerned - hardware, software you name it!

    It also looks like Jos's diagnostic Pack will be invaluable to you as well.

    Read the thread and then we can have a good go at getting your machine oeprational if you are up for it.

    EDIT: Just re-read your initial post and you say that you have a diagnostic ROM pack...

    Might have to refresh myself with my own initial ROM start-up disassembly (you will find a link to it on my google drive within the thread I have pointed you at).

    Dave

  5. #5
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    3,155

    Default

    Doing a bit more digging.

    I have used V5.1 firmware and V5 microcode in my 4052 emulator.

    The ROM code starts at 79F3 for V5.1 firmware.

    The ROM code starts at 7D0F for V4.something.

    If your code is looping at 7D4F then 7D4F - 7D0F = +40 bytes in.

    If I add +40 bytes to 79F3, this gives me 7A33 - which is within the bounds of the RAM check.

    So, the memory check stores the address of the failed memory byte into two consecutive bytes of memory (locations $3F and $40). In theory (and practice as Roland found out), you can use this as a trap condition for your logic analyser (remembering that the first access to each byte of memory will be the memory check itself and the second access will be the first failed memory address).

    The check ensures that this failed address is on a 4K boundary (i.e. ANDing the 16-bit failed RAM address with $0FFF should give a result of zero).

    If you can dump your ROMS (or find a dump of them on the internet anywhere) I can disassemble the memory check routine for you if that would help?

    Dave

  6. Default

    Thanks for your replies. I have read through the "saving ROM data from 4052" blog before, but I have been going through it again. It led me to believe the next step would be to read and verify the firmware rom's (I had already done this with the microcode rom's). From the blog it looks like the rom's are MK36000 (8K x 8 250ns) which has the same pinout as a MCM68764 EPROM which I should be able to read on my Data I/O 29B programmer. I attempted to read and verify the roms, but some of them show as all "FF", one shows as all "05", one as all "B6", one as all "7E".... ether it's not reading correctly, of all my roms are bad. It's possible there is some timing issue between the MK36000 an the MCM68764 which has a slower access time.
    The program counter seems to be executing a short loop of code which leads me to believe it's reading legitimate code from the ROM's. If it was all FF's or garbage it seems like it would be jumping all over random addresses. I'll take a look at the ROM data with the logic analyzer and see what it's doing.
    Clay

  7. #7

    Default

    Quote Originally Posted by oldcomputerexpert View Post
    Thanks for your replies. I have read through the "saving ROM data from 4052" blog before, but I have been going through it again. It led me to believe the next step would be to read and verify the firmware rom's (I had already done this with the microcode rom's). From the blog it looks like the rom's are MK36000 (8K x 8 250ns) which has the same pinout as a MCM68764 EPROM which I should be able to read on my Data I/O 29B programmer. I attempted to read and verify the roms, but some of them show as all "FF", one shows as all "05", one as all "B6", one as all "7E".... ether it's not reading correctly, of all my roms are bad. It's possible there is some timing issue between the MK36000 an the MCM68764 which has a slower access time.
    The program counter seems to be executing a short loop of code which leads me to believe it's reading legitimate code from the ROM's. If it was all FF's or garbage it seems like it would be jumping all over random addresses. I'll take a look at the ROM data with the logic analyzer and see what it's doing.
    Clay
    Unlike any other ROM/EPROM I can think of, MK36000 have "edge activated" /CE. It means you can't read such a ROM by simply pulling /CE low and cycling through the addresses, waiting for the access delay, then reading the data bus.
    I don't know how a 29B reads the ROM, but if it doesn't cycle the /CE signal on every address change, it won't read it correctly.
    HTH
    Frank IZ8DWF

  8. #8
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    3,155

    Default

    As Frank has pointed out, the MK36000 device is not as simple as potentially other (EP)ROMS are becuase of the address latch.

    It is all down to how your 29B works...

    I do have a copy of V4.something somewhere - so I will dissassemble that and see what it tells us.

    I don't believe all of your ROMS are bad either!

    The fact that you appear to be executing code out of the ROMS at all tells me that the microcode and hardware have passed the power on self test - so that is good news.

    Dave

  9. Default

    Quote Originally Posted by daver2 View Post
    As Frank has pointed out, the MK36000 device is not as simple as potentially other (EP)ROMS are becuase of the address latch.

    It is all down to how your 29B works...

    I do have a copy of V4.something somewhere - so I will dissassemble that and see what it tells us.

    I don't believe all of your ROMS are bad either!

    The fact that you appear to be executing code out of the ROMS at all tells me that the microcode and hardware have passed the power on self test - so that is good news.

    Dave
    Yes, I see looking at the timing diagrams for the MK36000, like you and Frank stated it would need to cycle /CE on every address change to get the correct data out. I am probably seeing only the first byte read from the chip on the 29B. I bet I could examine one byte at a time...
    Anyway, I have been doing more probing with the logic analyzer. Looking at J266, the Program Counter (PC), it looks like it's in a loop:
    7d51
    7d53
    7d55
    7d58
    7d5a
    7d5c
    7d45 (loop start?)
    7d48
    7d4a
    7d4c
    7d4e
    7d50
    7d53
    7d55
    7d57
    7d5a
    7d5c
    Sometimes I get other addresses, like it's off one byte:
    7d4d
    7d4f
    7d54
    7d56
    7d58
    7d5b
    7d5d
    7d46
    7d49
    7d4b
    7d4d
    7d4f
    7d52
    7d54
    7d56
    7d58
    7d5c
    7d45

    Moving to J264, MB0-15 which monitors the traffic in and out of the MAS to MCP on P254 - P154. I assume this will show address, and data from RAM & ROM:
    Note: I don't have the 7D01 logic analyzer set up to output the data yet, I'm just capturing it off the screen so the sections below could be out of order. I just took a photo of the screen at several points in the buffer or as it refreshed...
    dfff
    7d4a
    0000
    6d9a
    048b
    7d44
    a100
    0820
    7d4d
    7d58
    2612
    bcfe
    7d48
    7dd3
    86aa
    ----------------
    7d5a
    7d4c
    feea
    1618
    0000
    a700
    260b
    7d5d
    0055
    7dda
    44a7
    dfff
    7d4a
    0000
    161d
    ----------------
    7d5a
    7dcc
    dfff
    5d26
    0f64
    a700
    268b
    7d5d
    0055
    7d5a
    44a7
    dfff
    2612
    7d55
    00aa
    -----------
    0055
    0003
    7d4c
    ffea
    a3b0
    0000
    a700
    7d51
    ffea
    0055
    7d51
    ffe7
    0055
    7d5a
    7d4c
    dfff
    7d4a
    0000

    This may not be the best test point to observe instructions read from the ROM. If you know of a better location to pull a sample, please let me know.
    Clay
    Last edited by oldcomputerexpert; July 10th, 2019 at 08:15 AM.

  10. #10

    Default

    Clay,

    Lets get your 4052 fixed!

    My 4052 screen is not working - but I turned it on just now and it finishes booting and I can type on the keyboard.

    Let me get my logic analyzer hooked up to my 4052 and try to trigger on the address you seem to be looping on.

    Monty

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •