Announcement

Collapse

Forum etiquette

Our mission ...

This forum is part of our mission to promote the preservation of vintage computers through education and outreach. (In real life we also run events and have a museum.) We encourage you to join us, participate, share your knowledge, and enjoy.

This forum has been around in this format for over 15 years. These rules and guidelines help us maintain a healthy and active community, and we moderate the forum to keep things on track. Please familiarize yourself with these rules and guidelines.


Remain civil and respectful

There are several hundred people who actively participate here. People come from all different backgrounds and will have different ways of seeing things. You will not agree with everything you read here. Back-and-forth discussions are fine but do not cross the line into rude or disrespectful behavior.

Conduct yourself as you would at any other place where people come together in person to discuss their hobby. If you wouldn't say something to somebody in person, then you probably should not be writing it here.

This should be obvious but, just in case: profanity, threats, slurs against any group (sexual, racial, gender, etc.) will not be tolerated.


Stay close to the original topic being discussed
  • If you are starting a new thread choose a reasonable sub-forum to start your thread. (If you choose incorrectly don't worry, we can fix that.)
  • If you are responding to a thread, stay on topic - the original poster was trying to achieve something. You can always start a new thread instead of potentially "hijacking" an existing thread.



Contribute something meaningful

To put things in engineering terms, we value a high signal to noise ratio. Coming here should not be a waste of time.
  • This is not a chat room. If you are taking less than 30 seconds to make a post then you are probably doing something wrong. A post should be on topic, clear, and contribute something meaningful to the discussion. If people read your posts and feel that their time as been wasted, they will stop reading your posts. Worse yet, they will stop visiting and we'll lose their experience and contributions.
  • Do not bump threads.
  • Do not "necro-post" unless you are following up to a specific person on a specific thread. And even then, that person may have moved on. Just start a new thread for your related topic.
  • Use the Private Message system for posts that are targeted at a specific person.


"PM Sent!" messages (or, how to use the Private Message system)

This forum has a private message feature that we want people to use for messages that are not of general interest to other members.

In short, if you are going to reply to a thread and that reply is targeted to a specific individual and not of interest to anybody else (either now or in the future) then send a private message instead.

Here are some obvious examples of when you should not reply to a thread and use the PM system instead:
  • "PM Sent!": Do not tell the rest of us that you sent a PM ... the forum software will tell the other person that they have a PM waiting.
  • "How much is shipping to ....": This is a very specific and directed question that is not of interest to anybody else.


Why do we have this policy? Sending a "PM Sent!" type message basically wastes everybody else's time by making them having to scroll past a post in a thread that looks to be updated, when the update is not meaningful. And the person you are sending the PM to will be notified by the forum software that they have a message waiting for them. Look up at the top near the right edge where it says 'Notifications' ... if you have a PM waiting, it will tell you there.

Copyright and other legal issues

We are here to discuss vintage computing, so discussing software, books, and other intellectual property that is on-topic is fine. We don't want people using these forums to discuss or enable copyright violations or other things that are against the law; whether you agree with the law or not is irrelevant. Do not use our resources for something that is legally or morally questionable.

Our discussions here generally fall under "fair use." Telling people how to pirate a software title is an example of something that is not allowable here.


Reporting problematic posts

If you see spam, a wildly off-topic post, or something abusive or illegal please report the thread by clicking on the "Report Post" icon. (It looks like an exclamation point in a triangle and it is available under every post.) This send a notification to all of the moderators, so somebody will see it and deal with it.

If you are unsure you may consider sending a private message to a moderator instead.


New user moderation

New users are directly moderated so that we can weed spammers out early. This means that for your first 10 posts you will have some delay before they are seen. We understand this can be disruptive to the flow of conversation and we try to keep up with our new user moderation duties to avoid undue inconvenience. Please do not make duplicate posts, extra posts to bump your post count, or ask the moderators to expedite this process; 10 moderated posts will go by quickly.

New users also have a smaller personal message inbox limit and are rate limited when sending PMs to other users.


Other suggestions
  • Use Google, books, or other definitive sources. There is a lot of information out there.
  • Don't make people guess at what you are trying to say; we are not mind readers. Be clear and concise.
  • Spelling and grammar are not rated, but they do make a post easier to read.
See more
See less

Motherboard debugger

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Motherboard debugger

    Hi,

    I am considering developing a debugger which would be a CPU drop-in replacement which contains an FPGA and a microcontroller to diagnose motherboard issues down to the chip level. The software would run on an Adruino/Teensy and the FPGA would generate the bus cycles and would communicate with the user via the USB/UART.

    The software would first try to access each device on the motherboard similar to existing diagnostic ROMs. But when it encounters a failure, the software will prompt the user to attach a probe wire to the pins of specific ICs to observe if the signal is toggling as expected. If so, the software will ask to look at other signals until the failed component is found so the user can replace it.

    The ultimate goal would be for the software to be sophisticated enough to diagnose and isolate failures for every IC on these vintage motherboards without the user needing oscilloscopes, schematics, or
    debugging skills.

    Any thoughts/suggestions?

    Thanks,
    -Ted

    #2
    Dunno about that for 286 and later motherboards, many of which use LSI chipsets.

    Comment


      #3
      You will have to cater for variations in the circuitry.
      Some examples:

      * See modifications at [here] and [here].

      * See [here]. A hardware problem that was addressed in later boards ?

      Comment


        #4
        Originally posted by modem7 View Post
        You will have to cater for variations in the circuitry.
        I would think modifications and other motherboards could be supported as it would just require updated software while the tester hardware would remain the same...

        In fact, if all signals passed through the FPGA then different pinouts could also be supported such as the 6502, Z80, and others...

        Comment


          #5
          It's been done back when you could still buy 5v tolerant FPGAs
          Or, you can kick the CPU off of the bus and do your own bus cycles the way that in-circuit emulators or the Fluke 9010 worked

          Comment


            #6
            You may start with my Debuggerfor the PC as base of your idea. Instead of the display you can attach a microcontroller or other intelligent device. One thing you can do then is to log how a healthy PC behaves. When running into a bad type of that PC, use the debugger and compare the results with the log of the good one. You can decrease the number of logs by using a diagnostics ROM that fits multiple machines.

            This idea can be extended to PCs with PCI slots. But that is, as stated on my site, a bit to sophisticated for me.

            The main advantages of my idea is IMHO that you don't have to remove/replace ICs, you use a ready available access, and you can start simple with immediate results.
            With kind regards / met vriendelijke groet, Ruud Baltissen

            www.baltissen.org

            Comment


              #7
              The ultimate goal would be for the software to be sophisticated enough to diagnose and isolate failures for every IC on these vintage motherboards without the user needing oscilloscopes, schematics, or
              debugging skills.
              Honestly, I don't think that's attainable. Call me a pessimist. Running down the malfunctioning segment of a SSI TTL chip somewhere on the board from the CPU socket is probably not doable, without putting a known board on a bed-of-nails ATE setup.

              Comment


                #8
                Originally posted by Chuck(G) View Post
                Honestly, I don't think that's attainable. Call me a pessimist. Running down the malfunctioning segment of a SSI TTL chip somewhere on the board from the CPU socket is probably not doable, without putting a known board on a bed-of-nails ATE setup.
                The board would have a probe wire(s) which the user would attach to IC pins requested by the debug software. Bus cycles are initiated at the CPU socket and the results are checked with this moveable probe which should allow all components to be tested...

                Comment


                  #9
                  I suppose that might be workable with a specific PCB, but how general can you make this?

                  Comment


                    #10
                    Originally posted by Chuck(G) View Post
                    I suppose that might be workable with a specific PCB, but how general can you make this?
                    It could be extended to support any type of processor or motherboard, but for now I am investigating whether there is enough interest to invest time in the project...

                    I have been watching a number of YouTube debug videos recently where the host has access to a debug ROM, an oscilloscope, and the schematics but still ends up desoldering/replacing multiple chips until they stumble on the broken one. These hosts have debugging skills and equipment greater than the average vintage hardware enthusiast yet they still struggle finding the faulty IC's. The enthusiast is even less likely to achieve success...

                    What I enjoy about this Forum is how a new user will ask for help debugging their hardware and a number of senior members spring into action posting ideas, suggestions, URLs, and other words of support which often will result in finding the bug. I wondered if there was some way to consolidate/catalog this knowledge into an "expert system" where a cheap piece of hardware could be plugged into the machine and the user would follow steps to track down the fault down to the specific IC. These machines are only getting older, so I believe there could be a growing use for a system like this; especially for users who dont have the time, equipment, or inclination to debug subtle faults.

                    I'm not sure yet what the best flowchart would be for tracking down failures (Im open to suggestions); but the first step would be to simply test specific IC's on the board. If we want to test the IC which generates RAS/CAS, I would ask then to attach the probe to pin-x of IC-y and hit enter when ready, then I would send a series of bus cycles, or even elongated/distorted cycles, to force activity on this IC which is detected by the probe(s). The Teensy's ADC could also be used to sense the voltage level for mid-level voltages. If success, then I would request another pin or IC be probed, until the faulty IC was found. The next development step would be to integrate these IC tests into a smarter flowchart which would only test ICs in failing paths. (Meaning, if we can access DRAM successfully, then there is no reason to check any IC in this path)

                    Anyway, this is the general idea... The hardware would probably be a small PCB which replaces the CPU and contains an FPGA to generate the bus cycles and a header for the Teensy 4.0. Probably less than $50 in parts... The complexity would be in the software... But once it is dialed-in just about any fault on the board could be isolated..

                    Seem reasonable?

                    Comment


                      #11
                      Aren't you assuming that the motherboard clocks and bus interfaces work properly? I could see on semi-functional motherboard how one could isolate bad RAM chips, but a fault in an SSI chip (or something within an LSI chipset) would be a pretty ambitious goal. It's going to be really tough getting past the "it's a brick" type failures.

                      For example, how would you diagnose a faulty 8288 bus controller?

                      Comment


                        #12
                        Aren't you assuming that the motherboard clocks and bus interfaces work properly? ... For example, how would you diagnose a faulty 8288 bus controller?
                        Not really... the Teensy 4.0 has <20ns IO sampling time, so strobes like ALE can be tested and I control the bus interface, so testing each output combination of the 8288 would be easy. It also contains ADC's, so voltage and signal levels could also be tested.

                        Basically, if you can debug the issue with an oscilloscope, then this system should also be able to detect it.

                        Comment


                          #13
                          I'm familiar with the MCU, but I think the task of replacing the 'scope and/or LE may be bigger than you think.

                          Comment


                            #14
                            Check out the Fluke 9010a and 9100a devices.

                            Comment


                              #15
                              Okay, I'll suspend criticism and hang onto a couple DOA XT boards that I have around here. I'm willing to offer one up for test. I think the task is more than anyone expects.

                              Comment

                              Working...
                              X