Image Map Image Map
Page 4 of 13 FirstFirst 12345678 ... LastLast
Results 31 to 40 of 122

Thread: PET 2001-32N - Diag works in UD9, but with Kernal it fails to start

  1. #31

    Default

    Quote Originally Posted by dave_m View Post
    If you are saying the kernel pettest runs, but the EDIT slot pettest EPROM does not, then I suspect one or both of the D8 and D9 ROM sockets or traces around them. Every time you swap a chip there, things change.
    I have verified good contact across the address and data lines all the way down to UD3, but I'll try it out again to be sure. I'm checking from the shoulder of an eprom down to the UD3 socket.

  2. #32

    Default

    Just an update. I spent a great deal of time thinking, studying the schematics, and reading. One or two of you folks have pointed toward something being active on the bus, and my suspicions are heading in that direction. Like Dave, I'm starting to think that the ripple/noise is actually a side effect of whatever device is fighting to control the bus/busses. Today I replaced the 74244s and 74153s that support the RAM. No change yet. I'm going to continue to examine/replace the bus drivers and buffers for now.

    If you have other thoughts or insights, please share!

  3. #33
    Join Date
    Feb 2009
    Location
    Southern California, USA
    Posts
    2,667

    Default

    Quote Originally Posted by dhoelzer View Post
    I have verified good contact across the address and data lines all the way down to UD3, but I'll try it out again to be sure. I'm checking from the shoulder of an eprom down to the UD3 socket.
    Sometimes pressing a probe on the pin of the chip will make an intermittent connection look good. I would give the sockets a good inspection looking for bad solder joints or solder splash. If in doubt, reflow the joints.

  4. #34

    Default

    Quote Originally Posted by dave_m View Post
    Sometimes pressing a probe on the pin of the chip will make an intermittent connection look good. I would give the sockets a good inspection looking for bad solder joints or solder splash. If in doubt, reflow the joints.
    (As you read this, have this question in mind: "Even as I type this, though, I'm forced to wonder if the actual problem might be a failing 4 to 16 decoder that is incorrectly turning on the chip select for more than one ROM at a time..." Is this more likely and should I spend time on this before I build a ROM testing/exercising circuit?)

    HAH!!!

    Well, I think you were *almost* right, Dave. It turns out it's not the sockets.. I had actually replaced them a few years ago. Everything tests out good there... HOWEVER, the idea of something driving the bus (either address or data) had me on a mission to identify any possible source... Removing the original BASIC mask ROMs.... and it now runs the tests mostly flawlessly for hours... The PETDIAG does complete screens of Gs and character though there are sparkly artifacts on the character set screens. Your test ROM also starts, but the screen contains a significant amount of garbage/incorrect text, though I can read "OKs" and the screen eventually mostly clears to perform the DRAM testing. The DRAM testing appears to crash the machine during the first iteration since it never moves from 0, but this is still progress.

    I'm super curious to prove that one of these ROM chips is doing something weird, so I'm currently wiring up an arduino to a breadboard with some code to continuously test the chip. I'm thinking that the test will alternate between a CRC and then reading the bus when the chip is deselected to see what happens over time as it warms up.

    I'm also putting together something to do DRAM testing after that now that my +12, +5, -5 supply came (I'm so lazy about building power circuits.. For $20, it's well worth buying one). I have to spend more time thinking and planning on that one since timing will matter much more. I also want to work out tests to verify the maximum delay between refreshes to fully test all of the transistors and capacitors in all of the bits. When I'm all done, I'll likely post the wiring diagram and some code out on Github.

    If you have thoughts or suggestions on the ROM or RAM testing, please let me know. Otherwise, I hope to report back with good news today or tomorrow. I'm super stoked that, perhaps, I have finally tracked down the real problem...

    Thanks as always

  5. #35

    Default

    MOS-made mask ROMs usually fail in two ways: either it never selects or it's always selected. On such a vintage device, one must absolutely test the ROMs first.
    A few posts back, I suggested that since the fault appeared to be A0-tied, the only problems could come from I/O chips (that you had excluded) or the ROMs.
    More likely the power supply noise is now gone and by the way, the typical PET power supply is 100% ok and I would never run 4116 DRAM out of an unknown supply that might not sequence correctly.
    Most 4116 variants do short internally as soon as -5V is not correctly present or falls too early. I have a few specimens that remind me these aspects.

    Frank

  6. #36

    Default

    Quote Originally Posted by dhoelzer View Post
    (As you read this, have this question in mind: "Even as I type this, though, I'm forced to wonder if the actual problem might be a failing 4 to 16 decoder that is incorrectly turning on the chip select for more than one ROM at a time..." Is this more likely and should I spend time on this before I build a ROM testing/exercising circuit?)
    To answer my own question, I've just probed pin 20 on every eprom socket... While PETDIAG is running, only 0xF000 is active, so that's good news.

    In the meantime, I think I just killed my original mask KERNAL ROM by inadvertently inserting it one pin off That's what I get for not putting on my glasses.

  7. #37

    Default

    Quote Originally Posted by iz8dwf View Post
    MOS-made mask ROMs usually fail in two ways: either it never selects or it's always selected. On such a vintage device, one must absolutely test the ROMs first.
    A few posts back, I suggested that since the fault appeared to be A0-tied, the only problems could come from I/O chips (that you had excluded) or the ROMs.
    More likely the power supply noise is now gone and by the way, the typical PET power supply is 100% ok and I would never run 4116 DRAM out of an unknown supply that might not sequence correctly.
    Most 4116 variants do short internally as soon as -5V is not correctly present or falls too early. I have a few specimens that remind me these aspects.

    Frank
    Yes, you did (and Dave said something similar) but I had roughly discounted it because the ROMs read correctly. I hadn't thought that all the way through.

    I may have some dead DRAMs again at this point, so the DRAM tester is necessary to progress further. I want to exercise the ROMs too, but for now I'm just going to make a whole new set on EPROMs and see what happens.

    Is it just me, or is designing and building circuits WAY easier than troubleshooting them? I have most of a Z80 computer that I designed on a breadboard and functioning... and that took only an afternoon. This PET has taken me weeks!

  8. #38

    Default

    Quote Originally Posted by dhoelzer View Post
    Yes, you did (and Dave said something similar) but I had roughly discounted it because the ROMs read correctly. I hadn't thought that all the way through.
    yes that's why I use a really vintage DATA I/O programmer, it tests that actually the ROM can be de-selected and goes tri-state on every data line. Many other programmers don't test that.
    Plus, I've seen programmers that happily test an EPROM as "blank" when actually it doesn't even select anymore (and fails as soon as one tries to program it).

    Frank

  9. #39
    Join Date
    Feb 2009
    Location
    Southern California, USA
    Posts
    2,667

    Default

    Quote Originally Posted by dhoelzer View Post
    I have most of a Z80 computer that I designed on a breadboard and functioning... and that took only an afternoon. This PET has taken me weeks!
    Your PET has been very stubborn, but your current plan should really help.

  10. #40

    Default

    Quote Originally Posted by dave_m View Post
    Your PET has been very stubborn, but your current plan should really help.
    After much progress, I'm again in a lull. The PET diag ran for hours, but screen artifacts began to develop, especially after me inadvertently inserting that KERNAL ROM incorrectly! I've now been messing with the video SRAM, which lead to writing a different piece of test code. That really worked a treat to identify the odd SRAM as very unhappy... but over time it has worsened, so it's possible that:

    1) All of the 2114 SRAM I have is marginal or at least out of spec for timing
    2) Something's up in the support logic there as well.

    Current plan: I have some rather larger SRAM devices that are also only 1 or 2 years old (rather than 40 years old). I'm in the middle of wiring something up on perf-board to completely replace the 2114 SRAM devices. If that proves more difficult than it seems, I may put some logic on a board that lets me programmatically drive address and data lines from the processor socket so that I can trace them through the board and swat all of these niggling bugs at once. This idea certainly won't find devices that simply can't switch fast enough anymore, but it should certainly identify devices that are getting stuck.

Tags for this Thread

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
  •