Image Map Image Map
Page 10 of 10 FirstFirst ... 678910
Results 91 to 96 of 96

Thread: Saving ROM data from Tek 4052

  1. #91

    Default

    Quote Originally Posted by daver2 View Post
    My suggestion would be to remove the socketed option chips first and see what happens...
    In the meantime I will think how to test the RAM out in a more structured manner...
    Hi Dave,

    thanks for clarifying the RAM organisation. What do we do if the non-socketed NEC µPDs are faulty? I can unsolder one with a some patience, but several...

    I've gone over your firmware disassembly, and I agree with your annotations. While we now know what the firmware is doing, we don't know why it's doing it. The RAM test and following loop really makes no sense to me at all, and throws up a lot of questions:

    • Why is memory only checked up to FEEA, when RAM ends at FEFF (with FF00-FFFF mapping to I/O)?
    • Why are the loops starting at 7A42 always executed, regardless of where the preceding RAM test ended?
    • Why is the top of memory (or first failed address) written to RAM at 0x003F if it's retained in the X register? For external diagnostix?
    • Why do both loops at 7A46 and 7A4C test a condition (BNE) that never changes? If the RAM test successfully (?) ended at FEEA (actually FEEB, since it's post-incremented), the first loop will already hang! As such, we don't know for sure if the RAM is infact faulty...
    • Why isn't a fault condition asserted within the loops? The parity error LED is triggered by hardware, and it's off in this case.
    • What were the Teks smoking when they designed this thing?


    My head hurts, I think I'm gonna go lie down.

    --Roland
    "END OF LINE" [MCP, 1982]
    "An admin that isn't a bit hackerish is just the guy mopping up the keyboard" [Phrack V0b I3f P12]
    "Any appearance of danger is simply a device to enhance your experience" [Futureworld, 1976]

  2. #92
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    1,455

    Default

    >>> I agree with your annotations.

    Excellent, so the first hurdle over with!

    >>> Why is memory only checked up to FEEA, when RAM ends at FEFF (with FF00-FFFF mapping to I/O)?

    Don't forget that with a full complement of RAM (32K+24K=56K) the RAM will end at 0xDFFF. The CONSTANT ROM (starting at 0xE000) will terminate the memory test anyway...

    >>> Why are the loops starting at 7A42 always executed, regardless of where the preceding RAM test ended?

    I am not too sure what you are asking. The code at 7A42 just seems to be where everything ends up when the test has 'run out' of what appears to be valid RAM.

    >>> Why is the top of memory (or first failed address) written to RAM at 0x003F if it's retained in the X register? For external diagnostic?

    I assume it is written to 0x3F (and 0x40) from the X register as there is no direct means of performing logical testing on the 16-bit X register directly itself. The 16-bit X register appears to be stored into memory as two 8-bit bytes and then logically tested for being a multiple of 4K.

    >>> Why do both loops at 7A46 and 7A4C test a condition (BNE) that never changes? If the RAM test successfully (?) ended at FEEA (actually FEEB, since it's post-incremented), the first loop will already hang! As such, we don't know for sure if the RAM is infact faulty...

    Using a BNE this way is an easy way of saving ROM bytes I suspect. You perform a test and 'jump to yourself' if the test fails. Neat - but poor error reporting to the poor user. But, there again, these devices ended up in laboratories etc. anyway - so you just called in the repair company and they diagnosed the problem and fixed it. At least Tektronix did produce diagnostic aids etc. for their repair people. I don't think anyone did that with the micros. of the time... As I have identified above, I don't think the error should the RAM test ever succeeded be triggered! You could try reporting the error to Tektronix and see how they respond !

    >>> Why isn't a fault condition asserted within the loops? The parity error LED is triggered by hardware, and it's off in this case.

    Good question. I will have a look at the schematics and see if I can come up with an answer for this.

    >>> What were the Teks smoking when they designed this thing?

    I couldn't possibly comment...

    >>> My head hurts, I think I'm gonna go lie down.

    Back to the Asprin again!

    With regard to replacing the lower bank of RAMS. Let's not be too worried about that for now. Let's identify the problem first and see where that leads us.

    Dave

  3. #93
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    1,455

    Default

    I have done a bit of disassembly on what I think are the interrupt handler routines.

    I haven't got time to write up my hand-written notes just yet (I am heading out for an airport shortly) but I will when I get back.

    I have disassembled what I think is the NMI routine - and it does something weird with the parity error latch - like clear it AND HOLD IT CLEARED when a parity error occurs. If this is the case, you may not actually see the PARITY LED light during startup!

    Dave

  4. #94

    Default

    Quote Originally Posted by daver2 View Post
    I have disassembled what I think is the NMI routine - and it does something weird with the parity error latch - like clear it AND HOLD IT CLEARED when a parity error occurs. If this is the case, you may not actually see the PARITY LED light during startup!
    Hi Dave,

    thanks for the update. I suppose then it's a parity error only lasts 1µsec or so.

    Quick update from my side: I met up with Jos at VCFE in Zürich and he checked the µROMs I brought along after socketing the ones with broken pins: their checksums agreed with his, and they did so consistently. I think we can conclude that at least their content is ok, though mechanically they're very fragile indeed. Many thanks, Jos!

    Unfortunately, Jos' 4052 started to act up while on exhibit with what appears to be a thermal fault. His 4014 terminal, on the other hand, was rock solid and drew crowds. The keyboard on that thing is awesome! Thanks again, Jos, for putting these on exhibit!

    Meanwhile, I'll figure out how to determine the address where the RAM testing routine bails out. I'll also take a look at the diagnostic ROMpack schematics and parts in anticipation of building one. I took a look at Jos' module, and we discussed the possibility of him etching several PCBs if there is sufficient demand. After all, there are quite a few defunct 4050's out there that need testing. Laying these out (something I have no experience with) will take some time.

    Best regards,

    --Roland
    "END OF LINE" [MCP, 1982]
    "An admin that isn't a bit hackerish is just the guy mopping up the keyboard" [Phrack V0b I3f P12]
    "Any appearance of danger is simply a device to enhance your experience" [Futureworld, 1976]

  5. #95
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    1,455

    Default

    A 'suppliers' diagnostic!

    Error, what error? I never saw an error!

    Before I loose it:

    Code:
    79B2:
    
    86 41    ; LDAA 41 - IMMEDIATE
    97 4B    ; STAA 4B - DIRECT
    B6 FF 2A ; LDAA FF2A - KEYBOARD PIA PORT B DATA.
    84 EF    ; ANDA EF - Clear PB4 of keyboard PIA.
    B7 FF 2A ; STA FF2A - KEYBOARD PIA PORT B DATA.
    B6 FF 2A ; LDAA FF2A - KEYBOARD PIA PORT B DATA.
    8A 10    ; ORAA 10 - Set PB4 of keyboard PIA.
    B7 FF 2A ; STA FF2A - KEYBOARD PIA PORT B DATA.
    3B       ; RTI
    Interestingly, accumulator 'A' is modified by this action and never appears to be stored across (what I think is) the NMI handler...

    Dave
    Last edited by daver2; November 20th, 2017 at 12:27 PM.

  6. Default

    Hi Dave,

    thanks for the disassembly. That does indeed assert CLRPER, which clears the parity error latch. I would assume this NMI handler is triggered by the HDWFAIL signal, which is in turn asserted by a parity error. But what's the point of clearing (ignoring?) a fatal error and continuing as if nothing happened? If it's fatal, the system should just halt, in which case saving/restoring registers is indeed irrelevant.

    Btw, I don't think I ever saw 79B2 show up on my analyser, but I'll check my notes.

    --Roland
    "END OF LINE" [MCP, 1982]
    "An admin that isn't a bit hackerish is just the guy mopping up the keyboard" [Phrack V0b I3f P12]
    "Any appearance of danger is simply a device to enhance your experience" [Futureworld, 1976]

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
  •