Image Map Image Map
Page 5 of 13 FirstFirst 123456789 ... LastLast
Results 41 to 50 of 122

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

  1. #41

    Default Progress and squirrel-chasing

    I have become slight distracted from my DRAM/ROM testing project by the SRAM video troubles. Yes, I know I'm easily distracted... It's because the video RAM problem seems infinitely simpler by comparison.

    Here's where I am. I have taken an HM6116 (the first 8 bit > 1k SRAM that I had in my parts box) and wired it in to replace the two 2114 SRAMs. From my reading of the datasheets, though they never seem to quite come out and say it, the 2114s appear to be 200ms parts. The 6116 is a 70ns part as a worst case, so that should be more than fast enough.

    Since the 6116 uses separate ~WE and ~OE pins, I've taken the ~WE signal from the 2114 socket and routed it to the ~WE pin and to a 7404 input. The output is sent to the ~OE pin; that should take care of writing and reading.

    The address pins are all pulled from one 2114 socket. I/O 0-3 are connected to F8. I/O 4-7 are connect to F7.

    Does this all sound reasonable? I have output with a PET DIAG installed, but it's not expected output. The good news (to me, at least) is that there are no columns "missing." Before I move to a prototype board, I want to verify my thinking and see if I can clear up the unexpected display output..

    Requisite photos:

    Current output:
    IMG_5199.jpg

    Rat's nest: (Don't be fooled... I accidentally dislodged that capacitor leg while photographing.)
    IMG_5198.jpg

  2. #42
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    3,003

    Default

    That's not what I would have expected either (although I can't see anything wrong with your logic).

    It may be that the 2114 powers up randomly, but a more modern device generally powers up to a 0 or a 1 (but not 100% repeatedly). This is my experience of modern RAMs at any rate (we had a 30 year old bug I had to fix in some firmware a year or so ago. We changed the SRAM device from one manufacturer to another. The original powers up to largely 0's whereas the modern equivalent generally powers up to largely 1's. This caused a power-up fault in the embedded firmware - as a memory location was used before being cleared).

    Another possibility (from what you are stating about the 'gets worse') is something that is temperature dependent. Have you tried the hair dryer and freezer spray yet?

    Another possibility is to remove all of the video RAM completely and link the data outputs from the RAM sockets to logical 0 and 1 - just to make sure the data latch, shift register, character generator and supporting 'glue' logic is working OK before you start even looking at the RAM. If you get a consistent screen of the desired character that you have linked in PETSCII then that is good.

    Just a thought...

    Dave

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

    Default

    Quote Originally Posted by daver2 View Post

    Another possibility is to remove all of the video RAM completely and link the data outputs from the RAM sockets to logical 0 and 1 - just to make sure the data latch, shift register, character generator and supporting 'glue' logic is working OK before you start even looking at the RAM.
    Actually a quick test is to just remove the video RAM and see if one gets the classic checkerboard pattern (PETSCII $FF = checkerboard). If that finds a problem good, if not then go on to your test of putting a few patterns on the video RAM outputs.

  4. #44

    Default

    Quote Originally Posted by dave_m View Post
    Actually a quick test is to just remove the video RAM and see if one gets the classic checkerboard pattern (PETSCII $FF = checkerboard). If that finds a problem good, if not then go on to your test of putting a few patterns on the video RAM outputs.
    Yes, I do get a checkerboard. That's one of the first things I confirmed when I started working on this beast.

    I have another very interesting idea I'm going to explore in the AM.. I'll post details when it succeeds or crashes and burns.

  5. #45

    Default

    Quote Originally Posted by dhoelzer View Post
    I have become slight distracted from my DRAM/ROM testing project by the SRAM video troubles. Yes, I know I'm easily distracted... It's because the video RAM problem seems infinitely simpler by comparison.

    Here's where I am. I have taken an HM6116 (the first 8 bit > 1k SRAM that I had in my parts box) and wired it in to replace the two 2114 SRAMs. From my reading of the datasheets, though they never seem to quite come out and say it, the 2114s appear to be 200ms parts. The 6116 is a 70ns part as a worst case, so that should be more than fast enough.

    Since the 6116 uses separate ~WE and ~OE pins, I've taken the ~WE signal from the 2114 socket and routed it to the ~WE pin and to a 7404 input. The output is sent to the ~OE pin; that should take care of writing and reading.


    IMG_5199.jpg

    Rat's nest: (Don't be fooled... I accidentally dislodged that capacitor leg while photographing.)
    IMG_5198.jpg
    This isn't going to work. You need to tie both ~CS and ~OE of the HM6116 low, tie the additional address line of the HM6116 low or high (it's 2K wide, instead of 1K of the 2114s), then connect the R/W line from the video ram glue decoding to the ~WE of the 6116.
    Man, you must really hate the 2114 as the are not anywhere rare even nowadays. There're lots of compatible SRAMs from almost every chip manufacturer active in the '70s and '80s (as it was still in use on the quite popular C64 for example).
    Frank

  6. #46

    Default

    Quote Originally Posted by iz8dwf View Post
    This isn't going to work. You need to tie both ~CS and ~OE of the HM6116 low, tie the additional address line of the HM6116 low or high (it's 2K wide, instead of 1K of the 2114s), then connect the R/W line from the video ram glue decoding to the ~WE of the 6116.
    Man, you must really hate the 2114 as the are not anywhere rare even nowadays. There're lots of compatible SRAMs from almost every chip manufacturer active in the '70s and '80s (as it was still in use on the quite popular C64 for example).
    Frank
    I don't hate them... I'm just scratching my head to figure out what the heck is going on. First it looks like a problem in the DRAM, then I get crazy video artifacts, then it sort of works, then the PETDIAG looks great, then it starts acting like the video ram again... Every 2114 and 8116 that I try changes the behavior of the entire system. At this point I can't tell if the problem is me (well, we all know I'm the problem here), the chips in my parts drawers, logic chips on the board, or some chip that intermittently drives either the address or data bus (or both).

    I was not complete in my description; I did tie the extra address lines low.

    As for the CS, the ~CS was tied low, but I tied ~OE to the 7404 because it seemed that ~WE and ~OE are mutually exclusive...?? no?

  7. #47

    Default In other news..

    As a result of the below, I've managed to determine that the video circuitry is all just fine, though I did have a couple of bad 2114s. This narrows things down in two ways: It appears that the data bus is fine and does not appear to be driven by anything unexpected... Thought could indicate my troubles are on the address bus, but I have not yet thoroughly tested the ~CS pins on the plethora of chips that are currently out of the board (all DRAMs, all ROMs).

    Does anyone know, offhand, if there is a pull-up applied to the data bus? I spent a few minutes looking, but didn't see anything obvious. I've noticed that if left floating, the data lines actually go high enough to be a 1 TTL level.


    In other news, I've spent a bit of time thinking outside of the PET, as it were. First, I've written up a sketch that works great for testing out HM6116 SRAMs with an Arduino.

    I've also written a sketch that exercises and tests 2114/6114s!

    I've even written a sketch that allows you to wire the Arduino into the SRAM sockets to test the individual data lines and CHARROM decoding to the screen....

    And I'm nearly finished writing one up that allows you to drop the Arduino in to *act as the SRAM* in the 2001N!

    Here are a couple of photos of the arduino being used to drive the data lines in the video RAM for testing. It currently iterates over the entire ROM. I have a second version that allows you to key in serially which byte should be displayed.

    When I finish the video RAM ICE (effectively that's what this is!), I'll push it into one of my Github repositories.

    This mess:
    IMG_5200.jpg

    is doing this:
    IMG_5202.jpg

  8. #48

    Default

    Quote Originally Posted by dhoelzer View Post
    As a result of the below, I've managed to determine that the video circuitry is all just fine...
    Strike that... I'm actually seeing that pins 13 and 14 in socket UF7 seem to have something fighting to drive them. When the Arduino tries to pull them to ground they actually float at 1.4 volts.... That seems to indicate an issue with either UF9 or UE7, and I'm leaning toward UE7 because if I ground the pins directly, the proper character is displayed. Let's go play with that 74244...

  9. #49

    Default

    Quote Originally Posted by dhoelzer View Post
    Strike that... I'm actually seeing that pins 13 and 14 in socket UF7 seem to have something fighting to drive them. When the Arduino tries to pull them to ground they actually float at 1.4 volts.... That seems to indicate an issue with either UF9 or UE7, and I'm leaning toward UE7 because if I ground the pins directly, the proper character is displayed. Let's go play with that 74244...
    Sigh. That might have been a wild goose chase. I think it was the Arduino failing to properly drive the pins. Well, two more chips socketed. I think I'm at least halfway through the logic chips on the board at this point!

  10. #50

    Default

    My 2114 testing rig has proven very useful and definitely shows that I have a bunch of marginal chips.

    Tests performed:

    Iterative Write/Read Testing:
    Iteratively writing incremental nibbles across the full 1k chip and immediately reading it back.
    This test is repeated 500 times, each time increments the starting nibble stored so that all bits are fully tested.

    Honor CS for reading/writing:
    Set all nibbles to a known value (0x0F)
    Set CS high
    Attempt to write all nibbles to a different value (0x0A) with CS still high
    Attempt to read back all bytes. Verify that none of the nibble reads see a 0x0F
    Set CS low
    Read back all nibbles and verify that none of them are equal to 0x0A.

    Any other tests you can think of that would be meaningful? I've found that some of these chips have random write/read errors, often in what appear to be the same rows/columns in the chips. A fair number of them seem not to care if CS is low and will happily allow you to write to some of the nibbles. This is much less important in the Commodore since CS is tied to ground, but stilla fault.

    Using these tests, I've found that 9 out of 14 of my 2114 chips are bad. Two of them are just outright bad and fail immediately. The majority fail a couple of hundreds of iterations in. Even though they do not read/write badly every time, they consistently fail on the same address every time. This helps me to understand at least *some* of the weirdness I've had!
    Last edited by dhoelzer; August 30th, 2019 at 12:15 PM.

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
  •