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

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

  1. #51
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    2,976

    Default

    Why don't you implement the MARCH-C and/or MARCH-B memory tests (see the source code from my PETTEST2E)? This is a well-proven test - and the functions of the individual tests are documented for the failure modes they are testing for. OK - these are for DRAM chips - but the majority of the tests can be applied for SRAM as well.

    The variant I did for work was to use the algorithms as defined within the MICROCHIP application note (I can't remember which exact number at the moment) and to write my own macros for it to implement the low-level functions. These algorithms treat the memory device as an array of bits and read/write/test a bit at a time.

    Dave

  2. #52

    Default

    Quote Originally Posted by daver2 View Post
    Why don't you implement the MARCH-C and/or MARCH-B memory tests (see the source code from my PETTEST2E)? This is a well-proven test - and the functions of the individual tests are documented for the failure modes they are testing for. OK - these are for DRAM chips - but the majority of the tests can be applied for SRAM as well.

    The variant I did for work was to use the algorithms as defined within the MICROCHIP application note (I can't remember which exact number at the moment) and to write my own macros for it to implement the low-level functions. These algorithms treat the memory device as an array of bits and read/write/test a bit at a time.

    Dave
    Thanks! Will-do. I'll go read up on them.

  3. #53

    Default

    Just a note that this thread will be on hiatus until October (unfortunately). I have three weeks of work across the US, so I'll be traveling and out of my lab. I plan to resume my exploration of this troublesome PET when I return!

    One last tidbit before I check out; Some of you might recall that, after finally following Dave's advice about the ROM bank, I discovered that something is definitely intermittently fighting to drive the bus. I had *thought* that it might be one of the ROM chips since removing them seemed to improve my symptoms.

    I have since built a test rig on my Arduino to exercise the ROMs and check for the ROMs driving data lines when not selected. Unfortunately, all of the ROMs check out just fine, though I did find an EPROM that is slow to get one of its data bits live after ~CE. I'll continue my attempts to find the rogue chip(s) when I return!

    Thanks for all of your help everyone!

  4. #54

    Default

    Ok... Well.. One last question before I check out. I started dabbling this morning and found two things...

    First, leg 13 on the 7407 hex buffer seemed to have separated from the body of the chip, so the ~RES was making only intermittent contact. This has lead to another discovery... The only things on ~RES at the moment are the processor, the hex buffer, and a resistor. With the processor removed, ~RES behaves perfectly from the 555 through the inverter, through the buffer, to pin 40... With the processor inserted, ~RES has a 200 KHz square waveform that cycles between about 3.5v and 5v!! My first thought was the processor has something wrong, but I've dropped in a second processor and it behaves identically.

    This does not look normal. Any thoughts on what could cause this behavior? It really looks like something is causing ~RES to act as an output for something, which it shouldn't be able to do.

  5. #55

    Default

    Quote Originally Posted by dhoelzer View Post
    Ok... Well.. One last question before I check out. I started dabbling this morning and found two things...

    First, leg 13 on the 7407 hex buffer seemed to have separated from the body of the chip, so the ~RES was making only intermittent contact. This has lead to another discovery... The only things on ~RES at the moment are the processor, the hex buffer, and a resistor. With the processor removed, ~RES behaves perfectly from the 555 through the inverter, through the buffer, to pin 40... With the processor inserted, ~RES has a 200 KHz square waveform that cycles between about 3.5v and 5v!! My first thought was the processor has something wrong, but I've dropped in a second processor and it behaves identically.

    This does not look normal. Any thoughts on what could cause this behavior? It really looks like something is causing ~RES to act as an output for something, which it shouldn't be able to do.
    Ok, it's definitely not coming from the ~RES pin on the processor, but it is still only present when the processor is inserted. I put a CPU into a socket and bent pin 40 out to the side. Tying that to the ~RES right out of the inverted, it looks just fine. However, ~RES on the board after the 7407/7417 hex buffer, I have this:

    IMG_5211.jpg

    As a reminder, the VIA and PIA chips are not currently in the board. Looking at the schematic, the only other things on this circuit are a resistor and a return to the hex buffer (which is also not in circuit at the moment).

    Any thoughts? Should I be looking for some kind of a weak short to something at this point?

  6. #56

    Default

    Check R30 and its connection to Vcc

  7. #57
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    2,976

    Default

    Yikes, that looks horrid.

    Yes, I would look for a partial (high resistance) short circuit from the /RESET line (CPU pin 40) to something else with a clock on it. You need to follow the PCB track and look at the nearest neighbour tracks.

    A good magnifying glass and a bright light are required.

    Also, UD15 is used elsewhere *e.g. buffering the CPU PHI2 and R/nW signal - so there could be a partial short circuit somewhere around there - or UD15 is faulty internally?

    SORRY - been on holiday - I have been looking at the 8032 schematics! I mean A10 not UD15...

    Dave

  8. #58

    Default

    Quote Originally Posted by iz8dwf View Post
    Check R30 and its connection to Vcc
    That looked ok. +5 on one side, 200khz signal on the other.

  9. #59

    Default

    Quote Originally Posted by daver2 View Post
    Yikes, that looks horrid.

    Yes, I would look for a partial (high resistance) short circuit from the /RESET line (CPU pin 40) to something else with a clock on it. You need to follow the PCB track and look at the nearest neighbour tracks.

    A good magnifying glass and a bright light are required.

    Also, UD15 is used elsewhere *e.g. buffering the CPU PHI2 and R/nW signal - so there could be a partial short circuit somewhere around there - or UD15 is faulty internally?

    SORRY - been on holiday - I have been looking at the 8032 schematics!

    Dave
    Ok. I have a "Leak Tester" that I've never had success with. Maybe this is the job for it. I'll take a close look later today after I'm all packed up.

    Did you mean that to be "UD15"? This is a 2001-32n... There's no UD15 that I'm aware of... I'm not sure which part you were referring to here.

    If you're referring to the hex buffer, that is totally cut out at the moment (I don't have a spare 7407 or 7417 on hand), and it sits at UA10

  10. #60
    Join Date
    Feb 2009
    Location
    Southern California, USA
    Posts
    2,661

    Default

    I would be suspicious of oscillations in RESET circuit. Check the 555 timer (A2) and capacitors C66, C67 and C68. This PET has some fascinating issues.

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
  •