Image Map Image Map
Page 2 of 2 FirstFirst 12
Results 11 to 19 of 19

Thread: PDP-11/04 Console Repair - Part 1

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

    Default

    Quote Originally Posted by intabits View Post
    Yes, that was the first thing I tried, as the MCUs are the only interchangeable part.
    Rob,
    I saw your name on the software comments. Yes, I missed where you mentioned trying a 8008. You are doing good. I admire the programmed tester you rigged up to incrementally checkout the different functions in the unit under test.

    Do you have GUI software in the PC setting up the test parameters and then transferring test routines to the Arduino for execution? Or is the Arduino doing a lot more? What language was used to develop all this? How long did it take? You sound like a hardware guy but you must have quite a bit of software know-how (a lot more than me). Looking forward to how you attack the next phase of troubleshooting.
    -Dave

  2. #12
    Join Date
    Jan 2019
    Location
    Melbourne, Australia
    Posts
    34

    Default

    Hi Dave,

    Thanks for the kind words.

    As I didn't know how far I'd have to take this, and how general purpose it might turn out to be, the PC software is fairly elaborate - more than it needs to be. I'm still working on where and how to partition the functionalities.
    It's a bit of a hybrid, as it has hard coded test routines, but the testing suite that invokes them and the text that it displays is specified in a test program text file.
    The manual tab-page provides flexibility for testing outside of what the test program covers, and the single line scripting bizzo is a pretty neat and useful part of that.
    The buttons on that page also allow sending the simple low-level commands to the Arduino.
    It's written in Delphi (pascal).

    The Arduino stuff is fairly simple, (about 500 lines), it has a reporting task that is continuously sending the 8008 pin values to the host, and a command execution task that receives and executes simple commands.
    A few of the commands cause repetitive operation of the output pins, but they are not used much by the canned tests.
    The most complex thing it does is the sequencing of loading the Address Register (placing the two bytes on the bus and toggling the AR latch signals)
    But basically, it just sets the pins as it's told, and the host does all the thinking.
    It uses the normal Arduino C++ (the only form of C I've ever done, or can bear)

    How long to do?
    Not that long, the basics were done in a couple of days, and then another few for debugging, extending etc.
    It's ongoing...

    Hardware V Software?
    I've done a lot of both, but a lot more of software, as it involves less movement of my lazy butt.

    I've now redesigned the PCB for the Arduino-based M7859 exerciser, and over the next week, will try to test the switch register and data paths to/from the Unibus.
    I'm still very surprised that the board seems to need more than what's already been tested, just to show zeroes on the console, and then wait for a keyress!
    Maybe I've missed/assumed something basic?

  3. #13

    Default

    When I diagnosed my M7859 I used a logic analyzer. However I have tried one those Saleae clones in the past and my conclusion was that they were not up to the task. I bought a used HP 1664 instead. The key is to have proper triggering capability. Trigger on a signal or trigger on a pattern. The next thing is to use some target system clock to clock data into the anlyzer and not let it free-run. HP is calling it state analysis.

    Now, to me it looks like the processor does not come out of reset properly. Do you have the DC LO L signal coming false? Does this generate the INTR signal to the processor. Trigger on DC LO L coming high and then see what happens.

    Now if this is OK the CPU should execute code from address 0. Does this happen? Use the LA to monitor the adress bus and see if that correspond to what the listing says. The tricky thing is to have some clock signal to latch data and adress within the LA. This has to happen after T2, T3 is probably best since this is the fetch/data in/data out phase. The good thing is that there is a nice signal generated already on E22 pin 8 that should be useful as a clock signal. Again, use the DC LO L coming high as the trigger.

    If the trace doesnít match the listing the CPU fails to read the ROM correctly for some reason. Then this has to be investigated.

    BTW. Does the CPU has the -9V?

    Sorry if this all is obvious or that are thing that you already tested which I missed when watching your videos.

  4. #14
    Join Date
    Feb 2009
    Location
    Southern California, USA
    Posts
    2,641

    Default

    Quote Originally Posted by MattisLind View Post

    Now, to me it looks like the processor does not come out of reset properly. Do you have the DC LO L signal coming false? Does this generate the INTR signal to the processor. Trigger on DC LO L coming high and then see what happens.
    Mattis,
    That is a good basic check to see if the INTR pulses high at power-on. Also he should check that READY is always high. READY seems to come the the CPU board that is not installed, but there may be a pull-up on the M7859 board. If READY is shorted on the M7859, that would stop things. But not likely as there is some random activity on the displays.

    Do you think intabits can use a pulse generator synced with the proper clock to pulse the READY line and cause the 8008 to single step through its instructions after power-up? Or is he going to have to break out a 32 channel logic analyzer?

    Or do you think his tester will work when the M7859 is tied into the UNIBUS?
    -Dave

  5. #15

    Default

    I donít think READY is involved since it goes to a pull and then onto J3. J3 is used when doing microdebugging of the 11/34 CPU and for all normal purposes not used. At least it is not of not of any use right now. Could be useful to check so that the pullup hasnít failed somehow. Should be unlikely though

    Not being an expert on the 8008 at all but it seems likely that you could do some kind of singlestepping with the READY signal. But you probably need logic to do it. Probably need to be inactive during T2 to make the processor stop before getting to T3. A flip-flop that is cleared when state T2 happens then it is set by external pulse to have the processor to run again. The pulse at E22 pin 6 can probably be useful here.

  6. #16
    Join Date
    Jan 2019
    Location
    Melbourne, Australia
    Posts
    34

    Default

    Dave and Mattis,

    Thanks for your help and interest.

    The little Cypress FX2 module, with my input protection PCB, and the Pulseview software is the sum total of my experience with logic analyzers. Together with crappy text probes, and some channels on my protecion PCB being flakey, my initial experiences were not wonderful. Though at 12MHz sample rate, I felt that it should be possible to get good results if I could get reliable connections, and fix the broken channels. The Pulseview software seems capable, though it does have several aspects that I found annoying. So my first contact with using an LA left me feeling a bit "meh...".

    For all the above, I want to avoid the use of the LA just at the moment, though I accept that I may be approaching the point where it becomes the only method left to resolve the problem. But getting a more capable (and expensive) LA, if that is what is required, is not something I want or can afford to do just now.

    My Arduino "exerciser" CPU replacement has let me explore the M7859 in a systematic and controlled way, and I want to take that to it's logical conclusion for the sake of completeness. And it may yet uncover the problem. I've now rebuilt it onto a proper PCB so it should be very robust and reliable, and I will start testing it today. I'm especially interested in seeing that things behave in the computer as they did in the standalone test jig.

    The basics that are mentioned in the previous posts have all been checked and seem OK, -9v, clock signals, int pin low, DC Low inactive etc. And at some time at the start of all this, I did convince myself that the reset process was working correctly, though I'll try to revisit that to be sure.

    For me, tracing or following the 8008 instruction flow, or single stepping its operation are last resorts. My testing gear is probably just not up to it (and possibly me also).
    The approach I'm taking, is that I do have working 8008 chips, and if I verify that all the hardware they interact with is working as it should, by unit testing every part of it, I should get a result. I'm still pursuing that approach, and I want to explore it fully first.

    Mattis,
    Did you see my reply to your old post about the ROMs on this board?
    I can confirm that the program ROM contents are the same as the listing in the maintenance manual, and that they are the same on both revisions of the board. The E34 ROM is also identical on both versions, and the contents I showed in my reply do seem to be correct (but beware the 2 swapped address pins)

  7. #17
    Join Date
    Feb 2009
    Location
    Southern California, USA
    Posts
    2,641

    Default

    Quote Originally Posted by intabits View Post
    The approach I'm taking, is that I do have working 8008 chips, and if I verify that all the hardware they interact with is working as it should, by unit testing every part of it, I should get a result. I'm still pursuing that approach, and I want to explore it fully first.
    Rob,
    Yes, that sounds good.

    After you replaced the bad 74175 latch, you placed the system back in the system and checked to see if everything was working. It wasn't. But then, did you take the board out of the system and go back and complete all the rest of the tests having to do with the Switch Register, etc?
    -Dave

  8. #18
    Join Date
    Jan 2019
    Location
    Melbourne, Australia
    Posts
    34

    Default

    The switch register can only be tested in the system, as the transceivers that also enable it onto the MCU input bus are open collector, and need the Unibus pullups.
    Not quite true, it can be done out of the system, if I probed the SR outputs going into the transceivers, but that's a test I ignored as I wanted to do it automatically by loading and then reading back via the transceivers.
    Thinking about it now though, it *is* a logical point to be checked, and would need to be checked if the automatic test failed. So I should add a testing step for that.

    Quote Originally Posted by dave_m View Post
    ...did you take the board out of the system and go back and complete all the rest of the tests having to do with the Switch Register, etc?
    Just realized you probably didn't mean switch register, but yes, I'm pretty sure I redid all the earlier test steps after replacing the 74175.
    I've been lazy today, and have done nothing, but will be redoing all tests with the new exerciser PCB, so we''l see...

  9. #19
    Join Date
    Feb 2009
    Location
    Southern California, USA
    Posts
    2,641

    Default

    Well done so far! Take a break. You must be seeing 1's & 0's in your sleep by now.

    Will one of the tests include checking the contents of the Switch Register Address Decoder PROM? If that PROM is kaput, there would be problems. I don't trust 50 year old bipolar PROMs (although the other PROMs tested are OK so far).
    -Dave

    EDIT: Oops, I thought the 74S133 was a Signetics PROM, but it is a 13 input NAND used to decode the address, not a PROM.
    Last edited by dave_m; July 28th, 2019 at 11:23 AM.

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
  •