Image Map Image Map
Page 2 of 7 FirstFirst 123456 ... LastLast
Results 11 to 20 of 65

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

  1. #11
    Join Date
    Feb 2009
    Location
    Southern California, USA
    Posts
    2,646

    Default

    Quote Originally Posted by dhoelzer View Post
    Well that's interesting. First, it was definitely freezing during the RAM tests.

    I managed to get a picture of it running tests. You can see the $ $ in the bottom.
    A clue may be that a 'space' is hex 20 and a '$' is hex 24. Issue in video RAM data bit 2??



    But since then I am back to failing to start. I just get a random screen and the KERNAL fails to start the test EPROM in the EDIT slot, so that seems to be a DRAM problem again...???
    You seem to have sockets in ROM area. Perhaps a bad connection? Reflow solder joints.

  2. #12

    Default

    Quote Originally Posted by dave_m View Post
    A clue may be that a 'space' is hex 20 and a '$' is hex 24. Issue in video RAM data bit 2??





    You seem to have sockets in ROM area. Perhaps a bad connection? Reflow solder joints.
    For the video RAM, I've tried swapping the two 2114 chips, but the $ don't move.

    As to the EPROMS.. Mmm... I'll give that a look! Thanks! I've never had a good look at those sockets.

    I suppose a loose connection on the EPROMs could also make it crash during the RAM test. Any ideas about the failed RAM test?

  3. #13
    Join Date
    Feb 2009
    Location
    Southern California, USA
    Posts
    2,646

    Default

    Quote Originally Posted by dhoelzer View Post
    Any ideas about the failed RAM test?

    No, we need to wait for daver2 the programmer. He has not finished the user manual. What he has is on his google drive page. With the RAM test failing, the code does not go on to ROM and keyboard tests.

  4. #14

    Default

    Quote Originally Posted by dave_m View Post
    No, we need to wait for daver2 the programmer. He has not finished the user manual. What he has is on his google drive page. With the RAM test failing, the code does not go on to ROM and keyboard tests.
    Hmm.. It sort of looked like it was just looping through the RAM test over and over until it crashed.

    I'm still at a point where it completely fails to start again. I've tested all of the address and datalines between the DRAM and the buffers and the ROMs and the buffers and it all looks good.

  5. #15

    Default

    Quote Originally Posted by dhoelzer View Post
    Hmm.. It sort of looked like it was just looping through the RAM test over and over until it crashed.

    I'm still at a point where it completely fails to start again. I've tested all of the address and datalines between the DRAM and the buffers and the ROMs and the buffers and it all looks good.
    More interesting... Powered on this morning after it completely failing last night... It shows DRAM problems again, but starts the tests in the KERNAL slot.

  6. #16
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    2,803

    Default

    Daver2 is on holiday at the moment... Trying to use a keyboard where the Y and Z keys are transposed (on purpose that is)...

    I re-used the memory test at work for a project, so I will copy and paste the documentation I wrote into the user manual upon my return.

    My EPROM code does not require any form of RAM to be working at all for it to start up.

    The first thing it does do is a very simple RAM test on Page 0 and 1 of memory and the video RAM. We need these to work for later. If that works OK, you should get to the point of performing a keyboard and ROM checksum before testing the RAM thoroughly.

    Dave

  7. #17

    Default

    Quote Originally Posted by daver2 View Post
    Daver2 is on holiday at the moment... Trying to use a keyboard where the Y and Z keys are transposed (on purpose that is)...

    I re-used the memory test at work for a project, so I will copy and paste the documentation I wrote into the user manual upon my return.

    My EPROM code does not require any form of RAM to be working at all for it to start up.

    The first thing it does do is a very simple RAM test on Page 0 and 1 of memory and the video RAM. We need these to work for later. If that works OK, you should get to the point of performing a keyboard and ROM checksum before testing the RAM thoroughly.

    Dave
    I was at that point, Dave, but it has seriously regressed. Not only won't your tests start at this point, but now the typical PETTEST KERNAL version doesn't start, which seems very bad... and this is after replacing all of the DRAM and getting it to the point where the keyboard looked to be the only think I needed to work on.

    I've traced out all of the address and data lines but there seem to be no breaks. The video RAM seems fine, but I have swapped chips to no avail. I spent some time scoping pretty much all of the logic chips on the board, and nothing stands out as non-functional. I'm at a loss as to where to go next. I'm seriously thinking about:

    1) Writing some code that jumps from the reset vector to a continuous address/data sweep with some kind of diagnostic probe that I can scope

    2) Dragging the logic analyzer up here and seeing what the processor is doing and where it's getting stuck

    I have tried swapping the 6502, by the way.

  8. #18

    Default

    A bit of spotty progress. Following the advice of someone else I'm in touch with via email, I checked the ripple on the DRAM supplies. It's hovering between 400 and 500 mv on all three supplies. I replaced the electrolytics on the DRAM supply lines but that actually made the ripple *worse*, so I might have had some cheap capacitors in my drawer. However, while scoping those rails to check the ripple at the DRAM, the PET DIAG started to run with every other character corrupted! I'm going to work to cut the ripple in half and see what that does. My contact is suggesting that my problem might be that the DRAM is too sensitive to the ripple that's present in the circuit at the moment.

  9. #19

    Default

    Quote Originally Posted by dhoelzer View Post
    A bit of spotty progress. Following the advice of someone else I'm in touch with via email, I checked the ripple on the DRAM supplies. It's hovering between 400 and 500 mv on all three supplies. I replaced the electrolytics on the DRAM supply lines but that actually made the ripple *worse*, so I might have had some cheap capacitors in my drawer. However, while scoping those rails to check the ripple at the DRAM, the PET DIAG started to run with every other character corrupted! I'm going to work to cut the ripple in half and see what that does. My contact is suggesting that my problem might be that the DRAM is too sensitive to the ripple that's present in the circuit at the moment.
    That one else is me
    The symptoms really smell like a data bus conflict probably dependent on A1 address line status. I'd pull the 6520s and the 6522 to see if things get better.

    Frank IZ8DWF

  10. #20

    Default

    Quote Originally Posted by iz8dwf View Post
    That one else is me
    The symptoms really smell like a data bus conflict probably dependent on A1 address line status. I'd pull the 6520s and the 6522 to see if things get better.

    Frank IZ8DWF
    I'll try that this morning, but aside from that, I've promised to do real work the rest of the day.

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
  •