Image Map Image Map
Page 1 of 2 12 LastLast
Results 1 to 10 of 18

Thread: KIM-1 memory issues?

  1. #1
    Join Date
    Nov 2012
    Location
    Richmond Hill, Ontario, Canada
    Posts
    1,079

    Default KIM-1 memory issues?

    Hi All,

    I have Dwight Elvey's KIM-1 debug board and I have a Rev D KIM-1 that passed the CPU test but fails on the memory test. Oddly enough, the memory test pattern is short-long-short-long-short-long-short-long where "short" is a bad RAM chip and "long is a good RAM chip. I can replace the four RAM chips and retry but I am wondering if it may be a different IC?

    Other tests complete with issues so I want to fix this first and move on.

    ANy help is much appreciated.

  2. #2
    Join Date
    Jan 2010
    Location
    Central VA
    Posts
    4,210

    Default

    I found the dead SRAM in my current KIM-1 with the big logic analyzer, I was able to observe the bad bit after a stack push/pop.

    I forget, does the rev D board use two 2114s instead of eight 2102-equivalents? (I know some of the later revs do) If so, then it'd make sense that a single bad RAM chip would result in "four" dead RAM chips.

    The data out of the SRAMs is buffered, at least on the 2102 version, and there *are* two 4-element packages responsible for that. I'm not familiar with the operation of Dwight's board (I remember it being discussed), but if the beep pattern indicates which RAM is bad in succession, then a defective buffer wouldn't make sense. I guess it's possible that something else is trying to drive the data bus too, and causing a conflict, which looks like bad RAM? Or it's four dead 2102-type SRAMs. I've had a bunch fail in various equipment.

  3. #3
    Join Date
    Nov 2012
    Location
    Richmond Hill, Ontario, Canada
    Posts
    1,079

    Default

    The Rev D uses 8 x 2102-4's. From the docs, it uses two 74LS145 to buffer the memory but the U13 buffer does U5, U6, U7 and U8 memory while the U14 buffer does U9, U10, U11 and U12. If any one of those groups read bad, I would definitely blame the buffer but it's U5,U7,U9 and U11 with short blinks.

    Can one piggyback 2102s to check them?

  4. #4
    Join Date
    Jan 2010
    Location
    Central VA
    Posts
    4,210

    Default

    Quote Originally Posted by snuci View Post
    Can one piggyback 2102s to check them?
    Not really, though I don't advise piggybacking any RAM as a diagnostic tool anyway. I'd wait for Dwight or someone who's really familiar with his diagnostic tool to reply, if you have no other way of checking things out.

  5. #5

    Default

    Hi
    The test has no idea of the cause of the failure, it only responds to not being able to write and read a value into the RAM. It is clearly suspicious that something other than the RAM is at fault, showing alternating RAMS failing. The code does depend on the operation of the processor and that there is no other loads on the data buss that would block the write or read of the locations.
    The fact that alternating RAMS are failing is actually an indication that all of the RAMs are indicating a failure. Since the code must run without depending on the RAM, the test is restricted to indicating the first failed pattern. Since the pattern uses a 55h and AAh. It would cause just such a pattern of alternating bits passing and failing if the read were a constant value. The likely components are the are not the RAMs themselves. It is likely some other element of the system.
    Since it seems to be running the code of the EPROM, I'd suspect that it is not the diagnostic board at fault.
    The first suspect might be the address decoder clip. I need to look at the diagram to see what we can look at as possible sources of the problem.
    I'll get back as soon as I've had some time to examine the possible sources of the problem.
    Dwight

  6. #6

    Default

    There are a number of possible failure points. The first is actually the diagnostic board. In order to boot, it takes over the boot operation. It does this by bringing the "Decode Enable" line high. This is one of the wires that goes from the debug board to pin K of the Application Connector. This disables U4 on the KIM, by pulling pin 12 of U4 high. The debug board is suppose to boot and then allow the debug board to run at an address as is decoded by U4. It does this by a write to the debug board that trips a flip flop on the debug board. ( I'll need to check which chip this is ). The code should then be executing from an address decoded by U4. I'm not sure if the code will still seem to work if U4 fails to take over the address. I'll need to examine the code to see if it could do so. So the first possibility is that the Debug board is not bringing U4-12 low to allow it to decode on board addresses. This includes the RAM.
    The other possibility is that U4 is failing to enable the RAMs that run on the address bank K0.
    I'm not sure what type of test gear you have? This would make a difference as to what we might do next.
    Dwight

  7. #7

    Default

    Ok, I was looking at the code it may be able to run at FC00. This would be with either a dead U4 or a failure of the debug board to bring U4-12 to zero. I have to dig up the schematics and look to see how the release circuit works but I recall it used a 74LS74. The reset pin would cause it to go to one state and a read of the address would cause it to change state, bringing U4-12 to 0.
    The code is dual mapped. Still the Error light routine is executed with a jump to 0D00h. I don't know how it could get there if the code continued to run at FC00h. It should reach the point that is would reach the error condition and then attempt to jump to 0D00h from some place between 0C00h and 0D00h. if it were trying to continue to run at FC00h the processor's addresses would go to 0D00h and then just execute until it reached FC00h again where it would just loop back to 0D00h without executing the error routine.
    At least that is my thinking.
    Now that I've convinced myself that the debug board could not run the error routine without U4 decoding K3 ( 0C00-0FFF ), lets look at what else might be the problem.
    I'm looking at the schematic:

    http://www.classiccmp.org/cini/pdf/R...ll%20KIM-1.pdf

    It shows that U15 and U16 are needed for the RAM to be working. Some of the stages of U16 are need to create the two phases of clock 2. The debug board also needs these two clocks. U15 is not needed for the debug board.
    So, without using a scope or logic probe, I would put the possible likely failure points, in desending order as:
    U15
    U16
    U4
    one of U13 or U14 enable pins stuck high
    one of the RAMs holding the R/W or CS*
    The 6502 addressing ( not to likely as it seems to be working )

    A logic probe or scope could look at these to see what was more likely. Remember that when you reach a failing point it is not easy to determine if it is a failing output or a failing input that is holding a line in a particular state. Usually it is the driving side but it still could be a stuck input.
    Dwight
    Last edited by Dwight Elvey; February 5th, 2019 at 10:42 PM.

  8. #8
    Join Date
    Nov 2012
    Location
    Richmond Hill, Ontario, Canada
    Posts
    1,079

    Default

    Hi Dwight,

    Thanks for the reply. It is definitely not the debug board. It works great on two other KIM-1s.

    The first CPU test works. I have it socketed and tried an extra just in case. I also get failures on any subsequent test. Originally this KIM-1 had a switch and some wires that I removed. It did not work properly with the switch but it did work better but not properly either. I think I will do some deep inspection of traces to see if any were cut first. I'll then take a look at what you suggest later tonight. Thanks again.

    Santo

  9. #9

    Default

    Quote Originally Posted by snuci View Post
    Hi Dwight,

    Thanks for the reply. It is definitely not the debug board. It works great on two other KIM-1s.

    The first CPU test works. I have it socketed and tried an extra just in case. I also get failures on any subsequent test. Originally this KIM-1 had a switch and some wires that I removed. It did not work properly with the switch but it did work better but not properly either. I think I will do some deep inspection of traces to see if any were cut first. I'll then take a look at what you suggest later tonight. Thanks again.

    Santo
    After the first two test, the later test require working RAM. The 6502 is almost a lump of silicon without zero page RAM. When I first started, I didn't think I'd be able to make the RAM test work without some RAM. The test uses all of the CPU's registers, including the stack pointer for holding data.
    Follow the R/W path from processor to RAM as well as the K0 path from the address decoder.
    Dwight

  10. #10
    Join Date
    Nov 2012
    Location
    Richmond Hill, Ontario, Canada
    Posts
    1,079

    Default

    Hi Dwight.

    I found a missing trace! It was between pin1 of U4 and pin 1 of U16. I couldn't see it until I desoldered the 7404 and replaced it and noticed some discoloration where the trace used to be.I checked against another KIM-1 and sure enough, it was missing. The memory test now displays 2 long, 1 short, 4 long.

    I am a bit confused if memory at U9 is bad or everything else is bad BUT U9.

    DBINSTR.TXT says short is bad as noted, "A 1 second blink indicates a good bit and a short blink indicates a failed bit."
    RAMTEST.SEQ says short is good as noted, "A short blink means that bit is good. A long blink indicated that bit bad. The long blink is about 1 second. The short one is clearly short."

    One of them is right and I am inclined to think that RAMTEST.SEQ is right if it's the code.

    Can you clarify? I did the display test and it failed the first time but then worked a second time so we are getting somewhere, I think.

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
  •