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

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,433

    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

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
  •