Image Map Image Map
Page 6 of 8 FirstFirst ... 2345678 LastLast
Results 51 to 60 of 71

Thread: Cbm 3032 power supply short / damaged board

  1. #51


    Today I received 2716 EPROM. I programmed (and verified) it using PETTESTE2KV04.bin and placed the EPROM in place of EDIT rom - U8.

    Unfortunately, nothing changed. Maybe it's a stuck buffer somewhere?
    Just to clarify, I have replacements for 6502, 6522 and 6520. Since we already discovered that a 6520 was faulty, maybe it's worth to try swapping the 6522 with another one?
    I'm asking before trying to avoid damaging potentially good components.

  2. #52
    Join Date
    Jun 2012
    UK - Worcester


    So when you say 'nothing changed' can you refresh my memory about what you mean please.

    What is on the screen (if anything). Is the screen blank. Does it have the random characters.

    You can remove the two PIAs and the VIA if you like. My PETTEST code doesn't even need them to run if you think they are faulty!

    Repeat the logic probe testing in an earlier post around the CPU please.


  3. #53


    The original problem was a garbage screen. I tried your pettester on the EDIT rom and it didn't work, so the garbage screen persisted.

    But I have some good news now! I tried to:
    - remove the PIAs and the VIA, tried again -> garbage screen
    - swap the 6502 with a replacement one, and the situation changed!

    Pettester started to work: it displays the first section of the test, but it get stuck there forever.


    Here is a video: as you can see, a couple of characters are still rolling.

    I did the logic probe test again, with this result:
    PIN01 - 0
    PIN02 - 1
    PIN04 - 1 fixed!
    PIN06 - 1
    PIN07 - oscillating (was 0 before replacing the cpu!)
    PIN08 - 1
    PIN37 - Oscillating
    PIN38 - 1
    PIN39 - Oscillating
    PIN40 - 1 after a while

    I then tried to put back the PIAs and the VIA, and to put back the original edit rom.
    The machine randomly boots: sometimes it shows the garbage screen, sometimes some random characters, it once displayed an almost correct startup screen, with some wrong characters (see COMIODORE and the other character wrong on the right of the screen).

    1-garbage.jpg 4-random.jpg3-bestresult.jpg

    Considering how the whole thing started, I am very happy of the current situation

  4. #54
    Join Date
    Feb 2009
    Southern California, USA


    That first part of PETTEST, did you get a screen of b's or g's or mixed? That will tell us something about your RAM. There is also something intermittent. Perhaps a bad CPU or EDIT ROM socket. But good progress!

  5. #55


    after carefully re-seating all the socketed IC, the situation stabilized.

    There are no more random garbage screens!

    - pettest displays the first screen only. it never reaches the ram test (as shown in the video)
    - standard EDIT rom displays the "COMIODORE" screen

  6. #56
    Join Date
    Jun 2012
    UK - Worcester


    Excellent, so you are getting there.

    The first test is to checkout the VIDEO RAM. If the PETTEST ROM ‘jams’ at this screen there are two possibilities:

    1. The CPU has stopped executing instructions correctly within the ROM.
    2. There is something wrong with the VIDEO RAM or access circuits.

    You can checkout the former by looking at the 4:16 address decoder (I will get you an IC reference shortly). The only addresses that should be accessed at this point is the EDIT ROM at $Exxx and the screen at address $8xxx. Anything else indicates the CPU has ‘escaped’!

    EDIT: UD2 (74154) pins 1-11 and 13-17. Only pin 9 ($8xxx) and pin 16 ($Exxx) should have activity. All of the other identified pins should be HIGH.

    If the above is OK, CAREFULLY check the displayed characters on the screen against what they SHOULD be. I see from one of your images that you got the odd rogue character on the screen (e.g. a < instead of a blank or the word COMIDORE). The odd bit may be faulty in the VIDEO RAM. There may only be (for example) two faulty characters if two of the video RAM bytes have a faulty bit. The display stays on the screen for a reason to help the human diagnose the problem.

    Last edited by daver2; March 21st, 2020 at 01:59 AM.

  7. #57


    Here are the 74154 measurements! 1/11 seems correct. 13/17 also, but there is activity on 21/22 (which should be an input, so i guess that is correct?) should i proceed with the comparison check?

    01 - high
    02 - high
    03 - high
    04 - high
    05 - high
    06 - high
    07 - high
    08 - high
    09 - oscillating
    10 - high
    11 - high
    12 - low

    13 - high
    14 - high
    15 - high
    16 - oscillating
    17 - high
    18 - low
    19 - low
    20 - high
    21 - oscillating
    22 - oscillating
    23 - low
    24 - high

  8. #58
    Join Date
    Jun 2012
    UK - Worcester


    That looks OK to me - the PETTESTER is running OK.

    I suspect, therefore, you have a VIDEO RAM or video RAM circuitry fault somewhere.

    You ned to check the screen characters very carefully for signs of error.

    EDIT: I have observed (what appears to be) one error already. On the second line there is a 'H' character. Just below it (on the third line) you should have a symbol. If you look at all of the other symbols below the 'H' you will see that the third line symbol is different. It shouldn't be...

    Last edited by daver2; March 21st, 2020 at 06:39 AM.

  9. #59


    I did a comparison pic with the computer and the emulator, and the only 2 characters that I see wrong are the G in the first row and the one under the H.

    Notice that that they are the only ones flickering in the video (i did a new one, but it's the same result of yesterday).

    The strange thing is that the "rogue" character and the M in the COMIDORE are in different positions: basically different programs shows different wrong characters in different positions!

    And also, how a faulty video ram can cause the freeze in the execution? It couldn't be a more general ram addressing problem?

  10. #60
    Join Date
    Jun 2012
    UK - Worcester


    >>> And also, how a faulty video ram can cause the freeze in the execution?

    The test program is not freezing, it is constantly testing the VIDEO RAM and video circuitry until such time as it gets back a healthy set of characters! There is no use in using the screen to display the results of further tests if the screen can't correctly display characters...

    The test program will constantly perform the same test UNTIL it reads back what it should do.

    There are a couple of things that a basic static test of this type will not reveal - that is permanently stuck bits at '1' or '0' where the test pattern contains the same bit configuration as the error. For example, if we write a bit pattern of binary 10101010 (hex AA) into a screen location, and bit 0 is permanently stuck at '0' then this test will not find the problem. If (on the other hand) we write a test pattern of 01010101 (hex 55) into the screen location, we will. This demonstrates that simple tests will only detect a small percentage of faults. This is why the tests get more complex (and thorough) as things proceed.

    What we need to do is to now find out why some of your video RAM or characters are not correct. Gut feeling tells me that your video RAM may be a bit on the edge - but let me think about it for a bit...



Posting Permissions

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