Image Map Image Map
Page 5 of 9 FirstFirst 123456789 LastLast
Results 41 to 50 of 89

Thread: Faulty 8032-SK with no V-Sync - Gary

  1. #41

    Default

    I logged the various input signals on the PIA together with the Data lines.

    Below a zoomed out and zoomed in screenshot of the signals.

    There clearly are activity on all the various select signals but, to be honest, I now need to carefully look for the logic states you indicated. And...I really don't know how to interpret what's happening on the data bus.

    Keyboard PIA - 1 - small.jpg

    Keyboard PIA - 2 - small.jpg

    Note: I've seen this logic analyzer create spurious spikes when all 16 the signals are being captured.
    Keyboard PIA - 3 - small.jpg

  2. #42
    Join Date
    Feb 2009
    Location
    Southern California, USA
    Posts
    3,047

    Default

    Signals looks OK to the PIA, the chip selects are connected properly to the PIA. The 50 Hz is not there because CRT Controller (6545) is not initialized (due to NOP test). But as far as data lines, a logic analyzer may not tell the difference properly between tri-state and high. You may need a scope for that.

    I was hoping for a problem with the chip selects to the PIA. There is only a tiny chance that the PIA is properly chip selected, but not outputting valid logic signal levels on data bus during read cycles.

    On previous tests you did see a proper 50 Hz to PIA I think. Maybe double check when RAM/ROM board in place.

    So far there is no reason why PIA is not generating an Interrupt Request (/IRQ). Very puzzling...

  3. #43

    Default

    Indeed Dave,

    The problem is the RAM/ROM board goes over the keyboard PIA, so I can't get to it to measure what's happening when the machines boots the Kernel.

    So now I'm looking to make a 40-pin extender to get either the CPU or PIA out the way to test. Getting bit silly.

    I did look at the data bus with the scope and do see 3 different levels. But it's so noisy, I can't really tell what it should look like. Any idea what the signals should look like / not look like on the data bus?

    Definitely saw the 50Hz signal to the PIA and VIA when the RAM/ROM board is in place. I also checked the levels of the 50Hz signal and it's nice and clean and at the right levels.

  4. #44
    Join Date
    Feb 2009
    Location
    Southern California, USA
    Posts
    3,047

    Default

    Quote Originally Posted by Jannie View Post

    I did look at the data bus with the scope and do see 3 different levels. But it's so noisy, I can't really tell what it should look like. Any idea what the signals should look like / not look like on the data bus?
    With three chip selects in the PIA, it may too difficult to get a good trigger to check the data lines using the scope. Let us ponder on other tests.

  5. #45
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    4,097

    Default

    I was reviewing all of the posts just now:

    1. There is a history of ‘eaten pins’.
    2. There is a history of problems with /IRQ.
    3. At one point you suspected a problem with data line D7. I don’t see any mention of this issue since.

    I do note that in one of the logic analyser traces above, the data lines seem to settle on a value of $EA (a NOP instruction) for a period of time. I wonder where this comes from and why?

    Just a few observations.

    Dave

  6. #46

    Default

    Quote Originally Posted by daver2 View Post
    I was reviewing all of the posts just now:
    Dave
    Thanks Dave, appreciate it.

    Quote Originally Posted by daver2 View Post
    1. There is a history of Ďeaten pinsí.
    Dave
    Yup, this machine was in a barn for an extended period and the chips that were socketed had rusted pins. These were the CPU and character ROM. I replaced both of them and the sockets look good and traces out. At least all the pins on the CPU I tested. Actually, the Edit ROM is also socketed but the pins looks OK. I'm using a RAM/ROM board to map them out. But I'll also not be surprised if it turns out to be a dis somewhere on the board.

    Quote Originally Posted by daver2 View Post
    2. There is a history of problems with /IRQ.
    Dave
    Yes, this was caused by the keyboard PIA that caused the IRQ to be stuck and the machine would not boot at all. After I replaced the keyboard PIA, the machine booted and the PET tester board did not report the IRQ stuck anymore. I've remove the IEEE PIA and lifted the leg of the VIA IRQ so, at this point only the keyboard PIA is connected to the IEQ line. I also checked it down to earth and supply.

    Quote Originally Posted by daver2 View Post
    3. At one point you suspected a problem with data line D7. I donít see any mention of this issue since.
    Dave
    Yes, you're right. The Tynemouth PET Tester reported D7 not being pulled up at one point but in subsequent tests it seems to be OK. But it's a valid point. I need to check it a bit more with the RAM/ROM card in place.

    Quote Originally Posted by daver2 View Post
    I do note that in one of the logic analyser traces above, the data lines seem to settle on a value of $EA (a NOP instruction) for a period of time. I wonder where this comes from and why?
    Dave
    The CPU's data bus is completed lifted on the NOP generator, so can't be that. If the $EA is intentional, it can only be a ROM? Any idea how to catch this the easiest? I can probably look at the data bus and the ROM select lines at the same time? I only have 16 channels on the logic analyzer.

    Quote Originally Posted by daver2 View Post
    Just a few observations.
    Dave
    Thanks again!!

  7. #47
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    4,097

    Default

    After some thought (and lunch)... my advice would be to use your logic analyser to monitor the control signals around the 6520 PIA UB12 and see what values are being sent to the device to initialise it. We can then see if the data values match what they should be.

    D0-D7.
    BA0 and BA1
    R/W

    The chip enable signals (trigger for the logic analyser):

    BA4=1
    / I/O=0
    X8XX=1

    If you canít get to the pins of the PIA, chase them back to their source.

    Does this make sense?

    Dave

  8. #48

    Default

    Quote Originally Posted by daver2 View Post
    After some thought (and lunch)... my advice would be to use your logic analyser to monitor the control signals around the 6520 PIA UB12 and see what values are being sent to the device to initialise it. We can then see if the data values match what they should be.

    D0-D7.
    BA0 and BA1
    R/W

    The chip enable signals (trigger for the logic analyser):

    BA4=1
    / I/O=0
    X8XX=1

    If you can’t get to the pins of the PIA, chase them back to their source.

    Does this make sense?

    Dave
    100%.

    Will have to chase them back and use clips, but no problem to do that.

  9. #49

    Default

    Gents, I have read through the posts and don’t want to divert attention away from the strategy in play, but, saw a photo of the motherboard with what looked like an eprom in the Edit rom socket. Is that a 2716 (should only be 2k).

    When you put the Tynemouth diagnostic board back in does it report any errors including the roms ?

    Andy

  10. #50

    Default

    Quote Originally Posted by AndyG View Post
    Gents, I have read through the posts and don’t want to divert attention away from the strategy in play, but, saw a photo of the motherboard with what looked like an eprom in the Edit rom socket. Is that a 2716 (should only be 2k).

    When you put the Tynemouth diagnostic board back in does it report any errors including the roms ?

    Andy
    Thanks Andy,

    At one point, I plugged a copy of Dave's PETTESTER (2816) into the EDIT ROM socket and tried to configure the Tynemouth board to replace all the ROMs except the EDIT ROM on the motherboard. Idea was to see if I could get the newer PETTESTER working but was ultimately not successful. Most of the other tests above would've been with the normal Edit ROM in place. However, the Tynemouth board does map all the ROMs out.

    The PET diagnostic board gave inconsistent CRCs for the ROMs which lead to the whole sequence above to trace the /CS for the ROMs.
    Last edited by Jannie; October 28th, 2020 at 02:53 AM.

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
  •