Re: M7264 Troubleshooting
> From: Allison >> "The console emulator Octal Debugging Technique (ODT)is a portion of >> the processor microcode ... The console ODT implemented on the LSI-11/23, >> PDP-11/23 and PDP-11/23-PLUS is identical." > However LSI-11/23 whatever that is, typo? No, that's exactly what's in the manual I cited; as you say, though: > That always had me during my yeas at DEC going which one are you > talking about, as every thing had at least three names (never > minding numbers) and one was usually ambiguous or a nonspecific > family name. DEC's naming of systems always drove me wild. To me, the worst one is the lack of a name for a system including a KDJ11-A; as someone here pointed out, the name "-11/73" is properly only applied to systems with a KDJ11-B and no PMI memory. As I understand it, DEC apparently didn't sell KDJ11-A's in complete, new, systems (it was just an upgrade board), so no number was ever allocated. Noel
Re: M7264 Troubleshooting
I have been working on it for the past week, and I would say the I have my system 95% functional as of now. On Sun, Jun 9, 2019 at 9:05 AM Noel Chiappa wrote: > > unlike my M8017, it will actually respond to my inputs on my > > terminal. I'm pretty sure I may just have the card configured > > incorrectly, but I'm not going to worry about that for now. > > If the M8017 is actually broken, I would be more than happy to trade a > working, tested DLV11-J (useful for TU58 emulation :-) for it, as I'd > like to have a DLV11-E for my collection. > Taking a closer look at it, it appears that I did not have my connector built correctly. It seems to work now. I got the tu58em software running on my laptop, interfected to my system via the DLV11-J I have. I was able to load XXDP and RT-11 more or less without a hitch. Typing in the bootstrap code is a real pain to do every time I want to boot the system, so I really need to get that MXV11-A working. While RT-11 boots, I am seeing some oddities that don't show up under a normal 11/03 emulated under SIMH. - Upon startup, the DIR command will refuse to list the directory, and just return a "?MON-F-Trap to 4 020142" error. This issue can be corrected by running V2.1 BASIC or another application, which then after the DIR command will work normally. - Also upon startup, sometimes normal RT-11 commands such as DATE and D will return ?KMON-F-File not found DK:*.SAV. This has like a 50% chance of happening. - Saving a file under K52 where the file length has been shortened will also return a ?MON-F-Trap error, and refuse to save the file correctly. This only happens sometimes. I am betting (or hoping) that this is just an issue with the TU58 emulator I am using, and not something wrong with the CPU. I have parts on the way for a RX02 emulator, so hopefully that will fix some of the issues I have having (and make it faster too). On top of that, the RUN/HALT and LTC lights on the front panel still do not function, even thought the switches clearly work and the computer responds accordingly. I am betting this is an issue with on the board somewhere, but as it does not impede functionality I am fine with it for now. One last question, besides TU58 and RX02, are there any other good storage options for a Q/Q 16 bit backplane PDP-11. I know there are SCSI hard drive boards for the 18 and 22 bit backplanes, but it would be nice if there was one that could work with my 16 bit H11A. Well, this project has been a lot of fun. Thank you for all the help you guys have gave me. Gavin.
Re: M7264 Troubleshooting
On 06/08/2019 10:37 PM, Noel Chiappa via cctech wrote: > > From: Allison > > > ODT for the two systems are very different. .. KDF-11 the ODT is part > > of the higher level code. The larger cards (11/23 and 23+) boot to > > resident (ep)rom. > > Ah, no. (Well, the KDF11 CPU's can boot to EPROM, which in the -11/23+ can be > on the CPU card; the -11/23 is a dual card and has no functionality on the CPU > card except the CPU.) Yes that is what the para quoted above implies. The resence of Eprom and serial are unique to the F11 based and later J11 quad width cards. All of the Qbus processor cards could boot to Eprom (TEV11) just like the Unibus 11s. And yes the KDF11 cpu does rely on higher level code inside the microcode its how that code was structured [and made to fit]. Also there are three cards for the KDF11, one dual width, and two quad width. The 11/23 early did not boot all devices and had different eproms (board level difference) than the later 11/23+ hence the + [and different part designations in the Mseries] designation. Back then FS noted that when requesting replacement boards and history requires it. > > The ODT in the KDF11's (and KDJ11's) is, just like in the LSI-11's, > microcode, not macro-code. From the 1982 'microcomputers and memories' > handbook, pg. 161 (in Chapter 7, "Octal Debugging Technique (Microcode > ODT)"): Save for the CPU and microcode are entirely different. ODT as a function is defined to do certain things how its done is vaguely similar at best. While implemented in ucode how its done and depnendancies are very unique to the each (again cp1600 and F11) > "The console emulator Octal Debugging Technique (ODT)is a portion of > the processor microcode ... The console ODT implemented on the LSI-11/23, > PDP-11/23 and PDP-11/23-PLUS is identical." Yes and unlike many here I have CPUs of all three form factors operational. However ODT on the dual width CPU does require a serial card as there is no way to talk to it without. That is an important difference especially if jumpered for ODT. Actually my "11" series Qbus collection includes all of the CPUs from the LSI11 though J11 based. And the bus versions are greater from the LSI11 early (and H11) though the later ones with PMI some specific to devices like the RL11 controller board set. However LSI-11/23 whatever that is, typo? So I will say the CP1600 processor of LSI-11 and the F11 (KDF-11)processor have major differences in how ODT works internally and on the bus and the code that does that are very different. To the user with a terminal its not very visible but to the service person (or someone assembling a system) it makes a difference. ODT had a specification and if you reffered to it that inside DEC it was not clear if it was microcode only that what the user/field service saw behaved in a very specific way. When applied to a specific processor it had deeper meaning. Some of that was factory test related. That Specification was an evolved thing as LSI-11 (cp1600) lead to additions and minor changes that were important to Field service and manufacturing. > and on pg. 154: > > "Unlike the LSI-11 and LSI-11/2, the LSI-11/23 does not enter console > ODT upon occurrence of a double bus error" Glad to see someone reads the books. There are other differences on power up and run states. Like the ram and console dependencies But all the M7264 posts were boiled down to the problem of not reading and understanding that ODT for that version of the CPU had dependencies. As well as the evolution of Qbus family of PDP11 CPUs and their low level and bus level idiosyncrasies. Most never refer to the LSI-11/23 that way to mean KDF-11 CPU its was a documentation error that propagated in educational services and lead to errors. LSI-11 (CP1600) was the first generation Qbus and later was F11 or J11 (or the T11). The difference was not always small as there were subtle instruction set differences and diagnostic impacts. That always had me during my yeas at DEC going which one are you talking about, as every thing had at least three names (never minding numbers) and one was usually ambiguous or a nonspecific family name. > From which I think is quite clear that the KDF11's have microcode ODT. It's not a question only the implications of how they did it. That they did it using using ucode is too road a generalization and misses implementation details. Its those details that get you when assembling systems and forgetting to include functions that are required if not used. That goes back to how DEC supported their systems when computers no longer had front panels. It was a field service requirement so they were not trying to wake a brick with nothing. Allison > Noel >
Re: M7264 Troubleshooting
> From: Allison > ODT for the two systems are very different. .. KDF-11 the ODT is part > of the higher level code. The larger cards (11/23 and 23+) boot to > resident (ep)rom. Ah, no. (Well, the KDF11 CPU's can boot to EPROM, which in the -11/23+ can be on the CPU card; the -11/23 is a dual card and has no functionality on the CPU card except the CPU.) The ODT in the KDF11's (and KDJ11's) is, just like in the LSI-11's, microcode, not macro-code. From the 1982 'microcomputers and memories' handbook, pg. 161 (in Chapter 7, "Octal Debugging Technique (Microcode ODT)"): "The console emulator Octal Debugging Technique (ODT)is a portion of the processor microcode ... The console ODT implemented on the LSI-11/23, PDP-11/23 and PDP-11/23-PLUS is identical." and on pg. 154: "Unlike the LSI-11 and LSI-11/2, the LSI-11/23 does not enter console ODT upon occurrence of a double bus error" >From which I think is quite clear that the KDF11's have microcode ODT. Noel
Re: M7264 Troubleshooting
On 06/08/2019 07:08 PM, Noel Chiappa via cctalk wrote: > A follow-up to close out something: > > > OK, now a picture of the bus with no console card: > > > http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/jpg/BSYN-BDAL_NoMem.jpg > [Note: image re-named, to correctly say what it's showing] > > > It's a bit hard to interpret what's going on here .. The long assertion > > of BSYNC is undoubtly the CPU trying to get the console CSR to respond, > > and eventually timing out. Not sure what the short assertion following > > it is - without looking at the ucode for the ODT, there's no way to know > > what the CPU's doing. > > > Even harder to understand is what the BDAL line is doing. It looks like > > it's un-asserted (0, i.e. +3V) on the falling (electrically - rising, > > logically) edge of BSYN (which would be incorrect - see above). And then > > it hops around while BSYNC is asserted, which makes no sense at all to > > me. > > So this makes a little more sense now. > > This is actually showing a NXM cycle to main memory (apparently to address 0), > hence the '0' on BDAL10. (The second assertion of BSYNC must be somehow > associated with the NXM.) Apparently it doesn't even try to talk to the > console card unless the memory is there OK; if it can't see the memory, it > must just reset and try again. > > Here: > > > http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/jpg/BSYN-BDAL_NoCon.jpg > > is a system with memory, but without a console. A very similar picture, but > here BDAL10 _is_ '1', as expected. > > > So the original picture did in fact indicate what the problem was - had I > known enough to know how to interpret it! Schaeffer's Law strikes again! > > Although I still don't understand why the LSI-11 wants to see main memory on > the bus, in order for ODT to run. ODT doesn't use memory at all; ODT on the > KDF11 CPUs will run without any memory. ODT for the two systems are very different. The LSI-11 ODT is microcode in the base CPU MICOM set and very low level. Also the 11/2 cpu (dual width is a bit differnt), KDF-11 the ODT is part of the higher level code. The larger cards (11/23 and 23+) boot to resident (ep)rom. Also consider the difference between the restart/run between the two. If memory serves The KDF11 requires enough ram to have a few of the key addresses in low memory operational. There is a lot going on with the LSI-11 as it also initializes internal and external RAM. At the time memory nearly always dynamic and require refresh cycles before it is "on line". The manuals detail it well. Allison > Noel >
Re: M7264 Troubleshooting
A follow-up to close out something: > OK, now a picture of the bus with no console card: > http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/jpg/BSYN-BDAL_NoMem.jpg [Note: image re-named, to correctly say what it's showing] > It's a bit hard to interpret what's going on here .. The long assertion > of BSYNC is undoubtly the CPU trying to get the console CSR to respond, > and eventually timing out. Not sure what the short assertion following > it is - without looking at the ucode for the ODT, there's no way to know > what the CPU's doing. > Even harder to understand is what the BDAL line is doing. It looks like > it's un-asserted (0, i.e. +3V) on the falling (electrically - rising, > logically) edge of BSYN (which would be incorrect - see above). And then > it hops around while BSYNC is asserted, which makes no sense at all to > me. So this makes a little more sense now. This is actually showing a NXM cycle to main memory (apparently to address 0), hence the '0' on BDAL10. (The second assertion of BSYNC must be somehow associated with the NXM.) Apparently it doesn't even try to talk to the console card unless the memory is there OK; if it can't see the memory, it must just reset and try again. Here: > http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/jpg/BSYN-BDAL_NoCon.jpg is a system with memory, but without a console. A very similar picture, but here BDAL10 _is_ '1', as expected. So the original picture did in fact indicate what the problem was - had I known enough to know how to interpret it! Schaeffer's Law strikes again! Although I still don't understand why the LSI-11 wants to see main memory on the bus, in order for ODT to run. ODT doesn't use memory at all; ODT on the KDF11 CPUs will run without any memory. Noel
Re: M7264 Troubleshooting
On 06/08/2019 12:07 PM, Mister PDP via cctalk wrote: > On Fri, Jun 7, 2019 at 7:35 PM Noel Chiappa wrote: > >> PS: Might be useful to check that the DLV11-J works; having a stock of >> known-good >> boards you can swap in is such a tool for QBUS debugging. > > > Tried that one out too, and it works. In fact, unlike my M8017, it will > actually respond to my inputs on my terminal. I'm pretty sure I may just > have the card configured incorrectly, but I'm not going to worry about that > for now. Right now I am working on getting a TU58 emulator set up. You > wouldn't happen to know where I could find detailed instructions > (Address/Vector, Bootstrap, etc..) on how to do this would you? > LSI-11 (or PDP-11) Microcomputer handbook there were many versions over the years earlier maybe more useful to LSI-11 users. First you really want the DLV11J as you need the ports. Configure it with the standard address for DD(TU58) and its vector. There is a list in the various Qbus LSI/PDP11 manuals. Note to boot anything from TU58 you will need a boot program and unless you add a MRV11 (eprom card) that means hand entry via ODT. See http://retrocmp.com/tools/tu58fs/265-tu58fs-pdp-11-boot-loader-operation for details. Also you will want not less that 16Kbytes of memory more its very desirable the upper limits is about 28K words as the upper 4K words is reserved mostly for boot (ep)roms and device addresses. Most common easily loaded OS is RT-11 V3 though 5.4. The most common devices: RX01 floppy LP11 Parallel printer, this can also be a port on the DLV11 for a serial printer. And of course the console VT52 or VT100 were the time frame for LSI-11 but any of the later VT2xx,3xx and later terminals work well. LSI-11 Boot, terminator card (there are variants depending on the bootable devices. ONE LAST REMINDER: LSI-11 was first of its kind and while Qbus did become a standard it did not remain completely in the original format. There is Q16, Q18, and Q22 and that specified both level of change and the address bus width. Not all cards work right in LSI-11 level bus with LSI-11 cpu and some of the older cards common to LSI-11 do not in the newer buses with 11/23 or later cpus. Some of the backplanes did specific incompatible things with the CD portion of the connector chain and in some cases had a EF connector (HEX width). Use care, read up, and have fun. Allison
Re: M7264 Troubleshooting
On Fri, Jun 7, 2019 at 7:35 PM Noel Chiappa wrote: > PS: Might be useful to check that the DLV11-J works; having a stock of > known-good > boards you can swap in is such a tool for QBUS debugging. Tried that one out too, and it works. In fact, unlike my M8017, it will actually respond to my inputs on my terminal. I'm pretty sure I may just have the card configured incorrectly, but I'm not going to worry about that for now. Right now I am working on getting a TU58 emulator set up. You wouldn't happen to know where I could find detailed instructions (Address/Vector, Bootstrap, etc..) on how to do this would you?
Re: M7264 Troubleshooting
I missed the part of the thread about the memory being disabled. I think the 11/05/10 is the only PDP-11 with a few registers on the CPU that you can run short routines. I also like the built is console SLU. Paul On Fri, Jun 7, 2019 at 9:18 PM Jon Elson via cctalk wrote: > On 06/07/2019 06:19 PM, Mister PDP via cctalk wrote: > > Wow, I wasn't aware that the ODT console needed memory to run. Checking > on > > my board, it looks like the 4kw was disabled. I plugged in my 32kw module > > with my M8017-AA, and it fired right up to ODT without a hassle. Seems > that > > was the issue all along. > > > > > Oh, of course! You can do very elementary checking of a > switch-and-lights PDP-11 with no memory, but creating any > sort of useful program that will run using only ROM and the > 8 registers would be VERY challenging. I suspect you might > be able to get it to print some text on the terminal, but > not a whole lot more. Obviously, no way to call a subroutine > without a stack. > > Well, glad you found it! > > Jon >
Re: M7264 Troubleshooting
On 06/07/2019 06:19 PM, Mister PDP via cctalk wrote: Wow, I wasn't aware that the ODT console needed memory to run. Checking on my board, it looks like the 4kw was disabled. I plugged in my 32kw module with my M8017-AA, and it fired right up to ODT without a hassle. Seems that was the issue all along. Oh, of course! You can do very elementary checking of a switch-and-lights PDP-11 with no memory, but creating any sort of useful program that will run using only ROM and the 8 registers would be VERY challenging. I suspect you might be able to get it to print some text on the terminal, but not a whole lot more. Obviously, no way to call a subroutine without a stack. Well, glad you found it! Jon
Re: M7264 Troubleshooting
> From: Mister PDP > Wow, I wasn't aware that the ODT console needed memory to run. It was news to me too! (And apparently to most others here too?) I was going to look at those confusing bus cycles, using an only slightly mis-addressed console, and wanted to first check that that console worked when properly configured; so I plugged in it and an LSI-11/2 CPU - nothing. Switched to a different CPU (maybe the first one died), _still_ nothing? So I tried an -11/23, ODT worked! So, the console worked; the chances of two CPUs that were working a week ago suddenly both dying seemed slim... what else could it be? And the /23 works with no memory! Odd. Will definitely have to make a note of that LSI-11 behaviour on the CHWiki. > I plugged in my 32kw module with my M8017-AA, and it fired right up to > ODT without a hassle. Yee-hah!!! EXCELLENT!!! Well, it took a while, but we finally got there! Do let us know how it goes with your next steps - and if you have an issue, let us know! (Hopefully, next time, we won'tbe so clueless! :-) Noel PS: Might be useful to check that the DLV11-J works; having a stock of known-good boards you can swap in is such a tool for QBUS debugging.
Re: M7264 Troubleshooting
Wow, I wasn't aware that the ODT console needed memory to run. Checking on my board, it looks like the 4kw was disabled. I plugged in my 32kw module with my M8017-AA, and it fired right up to ODT without a hassle. Seems that was the issue all along. On Fri, Jun 7, 2019, 3:08 PM Noel Chiappa wrote: > Hi, sorry I'm slow to do those tests; got distracted by the power > card stuff. > > So I've just dicovered that in a system with _only_ an LSI-11/2, > and a console, ODT doesn't start. I had to plug a memory card in > as well for ODT to work. (Confused the dickens out of me!) > > Is the RAM on your CPU card configured off? > >Noel >
Re: M7264 Troubleshooting
Sorry for the break, finals at school have been a little crazy. For simplicity of testing I have switched back to the M8017-AA instead of the M8043. The both are behaving in the exact same manner, so I am not ruling out the idea that the CPU is at fault just yet. On Wed, May 29, 2019 at 6:17 AM Noel Chiappa via cctalk < cctalk@classiccmp.org> wrote: > I suppose it would be worth while checking BDALn, BSYNC and BDIN _on the > console card_ (I'm not sure where he was looking at them, before) just to > rule out the broken bus line possibility. > I took a look on them, all of the signals make it into the card On Tue, May 28, 2019 at 9:08 PM Noel Chiappa wrote: > Hey, I have some extra console cards; probably the best thing to do at > this point is to send you a known working (i.e. tested) one. You can > then send me back your broken (maybe?) card - I don't mind getting a > broken one in trade, I can amuse myself fixing it. > > If you'd like to try this, let me know your mailing address, and I'll > get a tested card off to you (once the tree craziness dies down). > > Sorry you're not up and running yet... :-( > > Noel > Thanks for the offer, but I think I can diagnose if the card is working properly pretty easily. Looking at the schematics for the M8017, the BRPLY signal is generated by the 4 DC005 and DC004 (or DC003, I can't remember) chip. The bank of DC005 chips compare the address coming in with the address defined by the jumpers, and the DC004 takes some of the other signals on the backplane and combine the MATCH signal from the DC005s to generate the BRPLY signal. I should be able to find if the correct signals are coming in by looking at my logic analyzer, and then use that to see if the DC005s are generating the MATCH signal.
Re: M7264 Troubleshooting
On 05/29/2019 07:17 AM, Noel Chiappa via cctech wrote: > > From: Josh Dersch > > > how is the backplane in the H11 currently configured? (i.e. what boards > > are in what slots?) Could the issue here be something as simple as a > > break in the qbus due to a misplaced board? > > He did mention that he had the console card in the slot next to the CPU, which > I think is what you're referring to - but it shouldn't matter for ODT, which > doesn't use interrupts, only programmed I/O. > > A QBUS system will work fine without continuity of grant (interrupt, DMA) > lines to boards which only respond to DATI/DATO (memory, non-interrupt I/O, > etc). Just for grins, I took my -11/03, and plugged the console card in a > bunch of slots down, leaving several empty slots between it and the CPU, and > it worked 'fine': ODT was fine, and it would run "BR ." programs fine, too. > > So unless there's actually a break in one of the 'broadcast' bus lines (e.g. > BDALxx, etc) on that backplane, between the CPU slot, and the slot the console > card is in, or something like that... > > I suppose it would be worth while checking BDALn, BSYNC and BDIN _on the > console card_ (I'm not sure where he was looking at them, before) just to > rule out the broken bus line possibility. > > > One thing that's bugging me, though; he said "BDAL3-13 .. are all active and > jump around in some manner". But for the ODT microcode loop trying to read the > console CSR, i.e. 0177560, BDAL7 (0200) and BDAL3 (010) should be 0, i.e. > un-asserted. > > So why are they jumping around too? Is this somehow related to the odd > behaviour > I was seeing on my machine with no console card, where the BDAL line was > behaving > in a way I couldn't understand? > BDAL, Bus Data and Address lines. During the nominal cycle the address, then strobe, then data (from ot to an addresses device or memory) and controls asserted for the cycle type (ReadWord, Read ByteHigh, ReadbyteLOW, WriteWORD and so on. There are also transfers on the same lines for interrupt vector and priority. All that makes the BDAL lines busy... Generally the LSI-11 is a bit stranger as it also does bus level memory refresh for dynamic ram card that do not refresh themselves. The contemporary memory cards did not self refresh and used the early 4K or 16K 16pin devices. Memory used for 11/23 (f11) and later by then self refresh on the local card level was the norm and cut bus traffic load. Many of the functions were replicated as part of the T-11 CPU. > I'm going to look into that more, to try and understand what I'm seeing there, > but it won't be today, which is 'crane day'! Big tree! Allison > >Noel >
Re: M7264 Troubleshooting
> From: Josh Dersch > how is the backplane in the H11 currently configured? (i.e. what boards > are in what slots?) Could the issue here be something as simple as a > break in the qbus due to a misplaced board? He did mention that he had the console card in the slot next to the CPU, which I think is what you're referring to - but it shouldn't matter for ODT, which doesn't use interrupts, only programmed I/O. A QBUS system will work fine without continuity of grant (interrupt, DMA) lines to boards which only respond to DATI/DATO (memory, non-interrupt I/O, etc). Just for grins, I took my -11/03, and plugged the console card in a bunch of slots down, leaving several empty slots between it and the CPU, and it worked 'fine': ODT was fine, and it would run "BR ." programs fine, too. So unless there's actually a break in one of the 'broadcast' bus lines (e.g. BDALxx, etc) on that backplane, between the CPU slot, and the slot the console card is in, or something like that... I suppose it would be worth while checking BDALn, BSYNC and BDIN _on the console card_ (I'm not sure where he was looking at them, before) just to rule out the broken bus line possibility. One thing that's bugging me, though; he said "BDAL3-13 .. are all active and jump around in some manner". But for the ODT microcode loop trying to read the console CSR, i.e. 0177560, BDAL7 (0200) and BDAL3 (010) should be 0, i.e. un-asserted. So why are they jumping around too? Is this somehow related to the odd behaviour I was seeing on my machine with no console card, where the BDAL line was behaving in a way I couldn't understand? I'm going to look into that more, to try and understand what I'm seeing there, but it won't be today, which is 'crane day'! Noel
Re: M7264 Troubleshooting
On Tue, May 28, 2019 at 6:23 PM Noel Chiappa via cctalk < cctalk@classiccmp.org> wrote: > Hi, sorry about the delayed reply; been dealing with this: > > http://ana-3.lcs.mit.edu/~jnc/jpg/backoak/WholeTreeS.jpg > > The cranes arrive tomorrow... > > > > I took a look at all the lines you mentioned. BDAL3-13, BDIN, BSYNC, > and > > BBS7 are all active and jump around in some manner. > > Hmm. Well, that shoots down the simplest theory; that a CPU BDAL (or > perhaps > BDIN) driver (technically, a transceiver) chip is bad; if you're seeing any > activity at all on a line, the driver must be working. So, either both > console > cards have an issue, or something more complex is going on. > > Here are some pictures to show you what you should be seeing, and what I'm > seeing with an LSI-11 with no console card. First, normal operation: > > http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/jpg/BSYN-BDAL_OK.jpg > > The top trace is BSYNC, the bottom BDAL10 (which should be asserted for > 0177560, the console CSR's address; it's the 02000 bit). The timebase on > this > one is 1 usec per division. As you can see, it's in a tight loop reading > that > register. > > The QBUS spec shows that for a DATI cycle, the DAL lines are set up before > BSYNC is asserted (falling edge here, since the bus lines are inverted). > BDA10 is indeed asserted (low) when that happens; shortly after it goes > back > to 0 (high) so that device can put its data out on those lines. It stays > high, > so that bit in the CSR must be 0. > > OK, now a picture of the bus with no console card: > > http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/jpg/BSYN-BDAL_NoCon.jpg > > It's a bit hard to interpret what's going on here (note that the timebase > is > much larger - 5 usec). The long assertion of BSYNC is undoubtly the CPU > trying > to get the console CSR to respond, and eventually timing out. Not sure > what > the short assertion following it is - without looking at the ucode for the > ODT, there's no way to know what the CPU's doing. > > Even harder to understand is what the BDAL line is doing. It looks like > it's > un-asserted (0, i.e. +3V) on the falling (electrically - rising, logically) > edge of BSYN (which would be incorrect - see above). And then it hops > around > while BSYNC is asserted, which makes no sense at all to me. > > > At this point, my best guess at the most likely cause of your problem > (given > the 'all the lines are doing stuff') is that both console cards have > issues. Tomorrow, when I'm not outside, I'll try and look at some other > BDAL > lines and see if they are doing the same thing with no console card in. > > Noel > Dumb question -- this is a long thread, so maybe this has been covered and I missed it -- but how is the backplane in the H11 currently configured? (i.e. what boards are in what slots?) Could the issue here be something as simple as a break in the qbus due to a misplaced board? - Josh
Re: M7264 Troubleshooting
Hi, sorry about the delayed reply; been dealing with this: http://ana-3.lcs.mit.edu/~jnc/jpg/backoak/WholeTreeS.jpg The cranes arrive tomorrow... > I took a look at all the lines you mentioned. BDAL3-13, BDIN, BSYNC, and > BBS7 are all active and jump around in some manner. Hmm. Well, that shoots down the simplest theory; that a CPU BDAL (or perhaps BDIN) driver (technically, a transceiver) chip is bad; if you're seeing any activity at all on a line, the driver must be working. So, either both console cards have an issue, or something more complex is going on. Here are some pictures to show you what you should be seeing, and what I'm seeing with an LSI-11 with no console card. First, normal operation: http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/jpg/BSYN-BDAL_OK.jpg The top trace is BSYNC, the bottom BDAL10 (which should be asserted for 0177560, the console CSR's address; it's the 02000 bit). The timebase on this one is 1 usec per division. As you can see, it's in a tight loop reading that register. The QBUS spec shows that for a DATI cycle, the DAL lines are set up before BSYNC is asserted (falling edge here, since the bus lines are inverted). BDA10 is indeed asserted (low) when that happens; shortly after it goes back to 0 (high) so that device can put its data out on those lines. It stays high, so that bit in the CSR must be 0. OK, now a picture of the bus with no console card: http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/jpg/BSYN-BDAL_NoCon.jpg It's a bit hard to interpret what's going on here (note that the timebase is much larger - 5 usec). The long assertion of BSYNC is undoubtly the CPU trying to get the console CSR to respond, and eventually timing out. Not sure what the short assertion following it is - without looking at the ucode for the ODT, there's no way to know what the CPU's doing. Even harder to understand is what the BDAL line is doing. It looks like it's un-asserted (0, i.e. +3V) on the falling (electrically - rising, logically) edge of BSYN (which would be incorrect - see above). And then it hops around while BSYNC is asserted, which makes no sense at all to me. At this point, my best guess at the most likely cause of your problem (given the 'all the lines are doing stuff') is that both console cards have issues. Tomorrow, when I'm not outside, I'll try and look at some other BDAL lines and see if they are doing the same thing with no console card in. Noel
Re: M7264 Troubleshooting
mån 2019-05-27 klockan 12:47 -0500 skrev Mister PDP via cctalk: > I took a look at all the lines you mentioned. BDAL3-13, BDIN, BSYNC, > and > BBS7 are all active and jump around in some manner. BRPLY is still > the only > line that does not have any activity on it. None of the BDAL lines > seem > shorted to ground or to each other. My DLV11-J is configured to > essentially > factory settings (J3 set as console, 8 bits no parity) except for the > fact > that J3 is at 9.6k baud instead of 300, the address jumpers are > exactly the > same as the one you provided. > Someone had a bit of trouble (whom ?) with things. Erratic behaviour in device addressing. He found that (i believe) that 8 switches in dip jumper was broken.
Re: M7264 Troubleshooting
I took a look at all the lines you mentioned. BDAL3-13, BDIN, BSYNC, and BBS7 are all active and jump around in some manner. BRPLY is still the only line that does not have any activity on it. None of the BDAL lines seem shorted to ground or to each other. My DLV11-J is configured to essentially factory settings (J3 set as console, 8 bits no parity) except for the fact that J3 is at 9.6k baud instead of 300, the address jumpers are exactly the same as the one you provided. On Sun, May 26, 2019 at 6:35 PM Noel Chiappa wrote: > Hey, I owe you replies to about a zillion emails; been busy, I'll > try and get to them tomorrow. A few quick things: > > > > My M8043 (DLV11-J) just arrived today. > > Here are the jumpers on mine, which I just pulled from a working system, > so you can compare and make sure you have them correct: > > A5 L > A9 L > A12C > A10C > A11C > A8 C > C2 C > C1 C > > Key:L = jumper from left post to right (component side up, gold pads > at bottom) > C = jumper from center post to right > > A6 I > A7 R > > I = Insert, R = Remove > > B-X-H X-H > > I have left out the vectors jumpers, since ODT doesn't use interrupts, and > the line config jumpers (their setting shouldn't have any effect on the > ability of the board to respond to ODT). > > > > I have a hard time imagining that both my M8017 and my M8043 are > > bad, but it could still be possible. > > Well, I did mention that the CPU board could have a fault causing it to > put out a bad address for the console; the other likely cause is that > both consoles are bad. Not sure which is the most likely. > > The blunt hammer debugging technique is to look at the address being put > out on the bus; you'll need to look at BDAL3-12 and BBS7 (sort of an AND > of all the high address bits, so devices should work on Q16, Q18 and Q22; > in fact, the manual says that device should look at BBS7, and hot BDA13 > and up). Best to use a 'scope so you can see what the waveforms look like. > This is slow and painful, but will allow precise, definitive diagnosis. > > If the address is good, look also at BDIN. If that's toggling, it's the > consoles. Otherwise, CPU issue,which we'll delve into once the data > points definitively. > > Noel >
Re: M7264 Troubleshooting
On Sun, May 26, 2019 at 1:03 PM Brent Hilpert via cctalk < cctalk@classiccmp.org> wrote: > Didn't this start out with the RUN LED not lighting up? > I don't recall it being mentioned that that was repaired. > I spent a good amount of time with the RUN LED issue, but eventually hit a brick wall. I traced the signal from the halt switch all the way into the "Control Chip" on the MCP-1600 chipset (All OK), but since the CPU directly controls if the LED is on or not I was not able to determine why the CPU was not telling the light to go on. Since other signals on the board were looking good (as in it was trying to communicate with other cards on the board), I am assuming that is a secondary issue. On Sun, May 26, 2019 at 11:23 AM Jon Elson via cctalk wrote: > > Well, if just ONE address line driver on the CPU has gone > > bad (or a short in the backplane) it could prevent the DLV > > from recognizing the address. If there are any other > > boards in the system, take them out. Maybe even the > > memory boards, and try to read/write the DLV addrsss from > > the console. (Oh, maybe that's the problem, you don't > > have the full programmer's console on this machine.) > > > Oh, DLV means Q-bus, so there isn't much choice EXCEPT > serial console, is there? > Yeah, when the serial console doesn't work, you've got a > problem. You could check each addr/data line to see that it > wiggles. If it doesn't wiggle, then you can see if the > state it is in makes sense. Obviously, somewhere in the > serial console routine, it should be addressing the serial > console, so every line should at some point be in the state > to select the console CSR. > A logic analyzer set up to read out the bus would be a good > tool at this point. > > Jon > The only cards I have in my system right now is the M7264 CPU board, and my M8043 DLV11-J (or M8017-AA, which I also have onhand) serial board in the slot closest to the CPU. The M7264 has 4KW of memory onboard, but I don't think the ODT prompt even needs any memory. I haven't gone and checked if any of the lines are shorted when they are not suppose to be, but a number of the pins are shorted with solder bridges on the back side of the H11A backplane. They look like they have been there since this machine was new, I am am assuming that they are intentional. When I get home I will go and check to see if any of the data/addr lines are stuck using my logic analyzer, as well as making sure those solder bridges are where they are suppose to be.
Re: M7264 Troubleshooting
Didn't this start out with the RUN LED not lighting up? I don't recall it being mentioned that that was repaired. Perhaps pursue fixing that - while it may be a secondary problem that doesn't resolve a 'bigger' problem, it could be that it uncovers a common problem.
Re: M7264 Troubleshooting
On 05/26/2019 10:44 AM, Jon Elson via cctalk wrote: On 05/26/2019 12:13 AM, Mister PDP via cctalk wrote: Ok, small update. My M8043 (DLV11-J) just arrived today. It seemed in good condition so I confirmed it was set up correctly (9.6k baud and console on J3), built a serial cable from the information provided on gunkies, and put it into my system. Sadly, it behaves exactly how it did with the M8017. No output, no activity on the BRPLY line. I have a hard time imagining that both my M8017 and my M8043 are bad, but it could still be possible. Well, if just ONE address line driver on the CPU has gone bad (or a short in the backplane) it could prevent the DLV from recognizing the address. If there are any other boards in the system, take them out. Maybe even the memory boards, and try to read/write the DLV addrsss from the console. (Oh, maybe that's the problem, you don't have the full programmer's console on this machine.) Oh, DLV means Q-bus, so there isn't much choice EXCEPT serial console, is there? Yeah, when the serial console doesn't work, you've got a problem. You could check each addr/data line to see that it wiggles. If it doesn't wiggle, then you can see if the state it is in makes sense. Obviously, somewhere in the serial console routine, it should be addressing the serial console, so every line should at some point be in the state to select the console CSR. A logic analyzer set up to read out the bus would be a good tool at this point. Jon
Re: M7264 Troubleshooting
On 05/26/2019 12:13 AM, Mister PDP via cctalk wrote: Ok, small update. My M8043 (DLV11-J) just arrived today. It seemed in good condition so I confirmed it was set up correctly (9.6k baud and console on J3), built a serial cable from the information provided on gunkies, and put it into my system. Sadly, it behaves exactly how it did with the M8017. No output, no activity on the BRPLY line. I have a hard time imagining that both my M8017 and my M8043 are bad, but it could still be possible. Well, if just ONE address line driver on the CPU has gone bad (or a short in the backplane) it could prevent the DLV from recognizing the address. If there are any other boards in the system, take them out. Maybe even the memory boards, and try to read/write the DLV addrsss from the console. (Oh, maybe that's the problem, you don't have the full programmer's console on this machine.) Jon
Re: M7264 Troubleshooting
Ok, small update. My M8043 (DLV11-J) just arrived today. It seemed in good condition so I confirmed it was set up correctly (9.6k baud and console on J3), built a serial cable from the information provided on gunkies, and put it into my system. Sadly, it behaves exactly how it did with the M8017. No output, no activity on the BRPLY line. I have a hard time imagining that both my M8017 and my M8043 are bad, but it could still be possible. On Thu, May 23, 2019 at 7:38 AM Mattis Lind via cctalk < cctalk@classiccmp.org> wrote: > Den tors 23 maj 2019 kl 14:14 skrev Noel Chiappa via cctalk < > cctalk@classiccmp.org>: > > > > From: Jon Elson > > > > > Yes, this is most likely a bus timeout > > > > The good news is that it looks like his CPU is 'mostly' working; and if > > the NXM is due to a fault on the CPU (e.g. bad bus transceiver sending > > the wrong address), that would be fixable (it uses 8641's). > > > > If the fault is in the DLV11-E (and not just misconfiguration), depending > > on > > where the fault is, he might be out of luck with that card; it uses > DC005's > > for transceivers, which of course are unobtainium now. > > > Not really unobtainium: https://www.ebay.com/itm/281679682476 and > https://www.ebay.com/itm/253305313497 > > These DC0xx chips can sometimes be found on Ebay under their Signetics > name. > > DC003 C2293N > DC004 C2301N > DC005 C2324N > DC006 C2345N > DC010 C2344N > > > > > > Still, QBUS serial > > interfaces are not rare. > > > > And overall, progress is being made! :-) > > > > Noel > > > > /Mattis >
Re: M7264 Troubleshooting
Den tors 23 maj 2019 kl 14:14 skrev Noel Chiappa via cctalk < cctalk@classiccmp.org>: > > From: Jon Elson > > > Yes, this is most likely a bus timeout > > The good news is that it looks like his CPU is 'mostly' working; and if > the NXM is due to a fault on the CPU (e.g. bad bus transceiver sending > the wrong address), that would be fixable (it uses 8641's). > > If the fault is in the DLV11-E (and not just misconfiguration), depending > on > where the fault is, he might be out of luck with that card; it uses DC005's > for transceivers, which of course are unobtainium now. Not really unobtainium: https://www.ebay.com/itm/281679682476 and https://www.ebay.com/itm/253305313497 These DC0xx chips can sometimes be found on Ebay under their Signetics name. DC003 C2293N DC004 C2301N DC005 C2324N DC006 C2345N DC010 C2344N > Still, QBUS serial > interfaces are not rare. > > And overall, progress is being made! :-) > > Noel > /Mattis
Re: M7264 Troubleshooting
> From: Jon Elson > Yes, this is most likely a bus timeout The good news is that it looks like his CPU is 'mostly' working; and if the NXM is due to a fault on the CPU (e.g. bad bus transceiver sending the wrong address), that would be fixable (it uses 8641's). If the fault is in the DLV11-E (and not just misconfiguration), depending on where the fault is, he might be out of luck with that card; it uses DC005's for transceivers, which of course are unobtainium now. Still, QBUS serial interfaces are not rare. And overall, progress is being made! :-) Noel
Re: M7264 Troubleshooting
On 05/22/2019 05:04 PM, Noel Chiappa via cctalk wrote: > On the LSI-11/2, with the machine stopped, 'run' was off, and the > output on AF1/AH1 was always high (i.e. not asserted). > I don't have any guesses as to what the behaviour of yours is about. Hah! Eureka! I had a brainwave, and decided to look at my machine with the serial console board pulled out! I then get the exact same behaviour on SRUN as you're seeing - a very brief spike every so often (about every 25 usec, here). Yes, this is most likely a bus timeout as the console firmware is polling the serial module, and that module is apparently not acknowledging the request. Jon
Re: M7264 Troubleshooting
> On the LSI-11/2, with the machine stopped, 'run' was off, and the > output on AF1/AH1 was always high (i.e. not asserted). > I don't have any guesses as to what the behaviour of yours is about. Hah! Eureka! I had a brainwave, and decided to look at my machine with the serial console board pulled out! I then get the exact same behaviour on SRUN as you're seeing - a very brief spike every so often (about every 25 usec, here). So I'd be looking pretty hard at your DLV11-E; start by making sure it is configured correctly. Past that, you'll need prints; Manx claims there aren't any online, but there are a set in the jumbo assemblage, ET-LSI-11 (MP00706); the DLV11-E prints are on pp. 31-37. All you have to do to get a nice 'scope loop is to power the machine on; the CPU will dutifully try and read the RCSR, in a fairly tight loop. Probably worth picking up a spare DLV11 of some type for fault localization via board-swapping/etc; DLV11-J's can be found on eBait for not a large sum. Noel
Re: M7264 Troubleshooting
> From: Glen Slick > According to the M7270 LSI-11/2 Microcomputer Module User's Guid[e], > it uses BC1, BD1, BE1, BF1 for SCLK3 H, SWMIB18 H, SWMIB19 H, SWMIB20 H. Oh, thanks! I wonder how I missed that, looking at the prints? (The drawings have these nice dark arrowheads to indicate backplane connections.) I just visually blew past it, I guess. BH1 is also used there (for SWMIB21 H); and on the previous page, the STOP L output is on AE1, and MTOE L (whatever that is) can be fed from AK1. Not quite sure how a Q22 memory card causes the problem, electrically, since those lines are inputs on the memory card, so it's an input<->input connection (i.e. voltage sources in TTL), but obviously it does. And I also don't see why Q18 cards are a problem; BDAL16 and 17 are AC1 and AD1 respectively, which I don't see in the 'extra pins' list for the LSI-11/2. Oh well, not too important to track it down. Thanks again for catching my miss! Wow, it's been a lng time since I worked with an LSI-11 - about 40 years! :-) Noel
Re: M7264 Troubleshooting
On Tue, May 21, 2019 at 5:34 PM Glen Slick wrote: > > On Tue, May 21, 2019 at 4:56 PM Noel Chiappa via cctalk > wrote: > > > > Well, I verified that the LSI-11/2 should work in a Q22 backplane - > > in the sense that the only pins it tries to talk to are standard > > QBUS pins, and AF1/AH1 for SRUN. It doesn't drive BREF, which might > > cause issues in later QBUS systems. > > > > (It doesn't seem to work with Q18 memory, such as the MSV11-D. Attempts to > > write 0 to memory from ODT wind up leaving the bits in the high byte set. > > I have no idea why - anyone have any ideas? With Q22 memory, the symptoms > > are even stranger; the system hangs with the 'run' light on - even with > > the HALT switch on! Luckily I had an MMV11, and it worked OK with that.) > > Q22 memory uses BC1, BD1, BE1, BF1 for BDAL 18L, BDAL 19L, BDAL 20L, BDAL 21L > > According to the M7270 LSI-11/2 Microcomputer Module User's Guid, it > uses BC1, BD1, BE1, BF1 for SCLK3 H, SWMIB18 H, SWMIB19 H, SWMIB20 H. > > I haven't found a scan of the KD11-H Field Maintenance Print Set MP-00050. I just found an online scan of MP00495 KD11-HA LSI11 CPU Field Maintenance Print Set. It does show SCLK3 H, SWMIB18 H, SWMIB19 H, SWMIB20 H being driven on BC1, BD1, BE1, BF1 for the M7270 LSI-11/2. So that seems like it might be an issue with Q22 memory.
Re: M7264 Troubleshooting
On Tue, May 21, 2019 at 4:56 PM Noel Chiappa via cctalk wrote: > > Well, I verified that the LSI-11/2 should work in a Q22 backplane - > in the sense that the only pins it tries to talk to are standard > QBUS pins, and AF1/AH1 for SRUN. It doesn't drive BREF, which might > cause issues in later QBUS systems. > > (It doesn't seem to work with Q18 memory, such as the MSV11-D. Attempts to > write 0 to memory from ODT wind up leaving the bits in the high byte set. > I have no idea why - anyone have any ideas? With Q22 memory, the symptoms > are even stranger; the system hangs with the 'run' light on - even with > the HALT switch on! Luckily I had an MMV11, and it worked OK with that.) Q22 memory uses BC1, BD1, BE1, BF1 for BDAL 18L, BDAL 19L, BDAL 20L, BDAL 21L According to the M7270 LSI-11/2 Microcomputer Module User's Guid, it uses BC1, BD1, BE1, BF1 for SCLK3 H, SWMIB18 H, SWMIB19 H, SWMIB20 H. I haven't found a scan of the KD11-H Field Maintenance Print Set MP-00050.
Re: M7264 Troubleshooting
> From: Mister PDP Well, I verified that the LSI-11/2 should work in a Q22 backplane - in the sense that the only pins it tries to talk to are standard QBUS pins, and AF1/AH1 for SRUN. It doesn't drive BREF, which might cause issues in later QBUS systems. Although it's a different board from the LSI-11, it uses the same CPU chip set, so it should give us some useful comparison data. So after a certain amount of issues (see next), I got my LSI-11/2 working. (It doesn't seem to work with Q18 memory, such as the MSV11-D. Attempts to write 0 to memory from ODT wind up leaving the bits in the high byte set. I have no idea why - anyone have any ideas? With Q22 memory, the symptoms are even stranger; the system hangs with the 'run' light on - even with the HALT switch on! Luckily I had an MMV11, and it worked OK with that.) > I took a picture of the readouts for SRUN Odd. On the LSI-11/2, with the machine stopped, 'run' was off, and the output on AF1/AH1 was always high (i.e. not asserted). I don't have any guesses as to what the behaviour of yours is about. > Checking the BSYNC, it looks like there is life. It oscillates at > 58.605 KHz, and has wider peaks than the SRUN signal. The frequency is not as useful as plain timings - especially for signals which don't have a 50/50 duty cycle. For example, on the -11/2, while in the ODT console CSR read loop (below), BSYNC is asserted for 2.5 usec (which sounds about right for a complete read cycle), then off for 1.0 usec. Also, in the pictures, it's not clear which part of the cycle is asserted (which, on the QBUS, is 0V - i.e. inverted) and which is idle (~3V). Is this the actual bus signal we're seeing, with high being idle, zor on the other side of an inverting receiver? The image shows some timing numbers, but it's not clear that they mean. E.g. above, it says "4.00 usec" - but is that per division, the whole horizontal, what? Below, I see below "17.06 usec", and if that's the rising edge -> next rising edge interval, that sounds like a bus timeout is happening. > This signal does not respond to the Run/Halt switch being toggled, > but I would assume that to be normal Right; while in ODT the CPU is trying to read the console CSR, and so you should see BSYNC cycling. At this point, you might want to look at BRPLY, which will tell us if the console is responding to the read of the CSR. Also, I don't know if your /73 system has a KDJ11-A (dual width card, no onboard console) or a KDJ11-B (quad width card, onboard console); if the former, it might be worth swapping the DLV11 card into that system to see if _it_ is working. Noel
Re: M7264 Troubleshooting
> Can you check that BHALT on the QBUS is actually asserted (i.e. 0V) when the switch is in HALT? I checked the BHALT signal going into the backplane, and it seems to be in good working order. I took a picture of the readouts for SRUN, which you can see here: https://photos.google.com/share/AF1QipOLFAH-Uip-O3LzqZKZVndV2LpGMdNjs4ndyhsKR6aZqqmXD9utlAdkReqoTJyU4A?key=RjExZHdDNC1XTUpkWFhEdU8xLW9vdXBMa2pzY1J3 Checking the BSYNC, it looks like there is life. It oscillates at 58.605 KHz, and has wider peaks than the SRUN signal. This signal does not respond to the Run/Halt switch being toggled, but I would assume that to be normal as I have the board jumpered to run at ODT. https://photos.google.com/share/AF1QipP3G6vBu30RlZUUR6YL3Zjz_LofyJsT-k8TOSYO8ldMhkryuxSdLJ11cq0E9OWBag?key=RlF6R1lTM0ZQc2tMTmN0TnNmdlpzYnM1X1huODFn On Mon, May 20, 2019 at 11:51 AM Noel Chiappa via cctalk < cctalk@classiccmp.org> wrote: > > From: Mister PDP > > > > After a day of confusing and mixed up signals (I don't really use > > this type of equipment very often) .. I switched over to the > > oscilloscope > > Don't feel bad, I too prefer to rely on an oscilloscope by default; not > only does it let you see what's really happening (intermediate voltages, > noise, etc) but it's simpler, and there are less ways to get incorrent > info. > > > to confirm that the four clock signals on the MCP-1600 chipset were > > working properly .. and was able to see that the very basics of the > > CPU were working. > > It's not necessarily good if the 4 clocks (I take it that's what the > latter refers to) are working, because if one or more of those were broken, > it's a relatively easy/simple fix, whereas if they are working, and > the CPU's still not running, it could be a failed CPU chip, and the only > fix there is to replace it. > > > the SRUN signal coming off of the backplane. > > Note that SRUN isn't crucial to the machine's operation, it's just user > info. If SRUN is somehow broken on it's own (i.e. failed component > somewhere between where the CPU generates it, and the display LED) finding > and fixing that issue won't help. > > Far more useful, in terms of getting the thing running, would be to know > if BSYNC on the QBUS is hopping around (as ODT tries to talk to the > console - an easy thing to check into, too). If not, that's a show-stopper > that needs to be looked into. > > > > From: Glen Slick > > > the SRUN L signal is driven on to the backplane bus line AF1. > > The '78-'78 "microcomputer processors" says (pg. 3-15) that on the LSI-11 > it's also on CH1; just to complete the complexity, it also says (pg. 3-32) > that on the LSI-11/2 it's also on AH1! > > > > From: Mister PDP > > > I hooked the oscilloscope up to SRUN off of E68, and found that it > > oscillates low at 58.68KHz. .. Hitting the Run/Halt switch does not > > have any effect on the period or amplitude of the oscillation. > > So maybe the CPU is actually running after all? Although turning > RUN/HALT to 'HALT' should stop it - the Run light would I think go > out when ODT is running. (It certainly does on the /23.) > > Can you check that BHALT on the QBUS is actually asserted (i.e. 0V) > when the switch is in HALT? > > Noel >
Re: M7264 Troubleshooting
> From: Mister PDP > After a day of confusing and mixed up signals (I don't really use > this type of equipment very often) .. I switched over to the > oscilloscope Don't feel bad, I too prefer to rely on an oscilloscope by default; not only does it let you see what's really happening (intermediate voltages, noise, etc) but it's simpler, and there are less ways to get incorrent info. > to confirm that the four clock signals on the MCP-1600 chipset were > working properly .. and was able to see that the very basics of the > CPU were working. It's not necessarily good if the 4 clocks (I take it that's what the latter refers to) are working, because if one or more of those were broken, it's a relatively easy/simple fix, whereas if they are working, and the CPU's still not running, it could be a failed CPU chip, and the only fix there is to replace it. > the SRUN signal coming off of the backplane. Note that SRUN isn't crucial to the machine's operation, it's just user info. If SRUN is somehow broken on it's own (i.e. failed component somewhere between where the CPU generates it, and the display LED) finding and fixing that issue won't help. Far more useful, in terms of getting the thing running, would be to know if BSYNC on the QBUS is hopping around (as ODT tries to talk to the console - an easy thing to check into, too). If not, that's a show-stopper that needs to be looked into. > From: Glen Slick > the SRUN L signal is driven on to the backplane bus line AF1. The '78-'78 "microcomputer processors" says (pg. 3-15) that on the LSI-11 it's also on CH1; just to complete the complexity, it also says (pg. 3-32) that on the LSI-11/2 it's also on AH1! > From: Mister PDP > I hooked the oscilloscope up to SRUN off of E68, and found that it > oscillates low at 58.68KHz. .. Hitting the Run/Halt switch does not > have any effect on the period or amplitude of the oscillation. So maybe the CPU is actually running after all? Although turning RUN/HALT to 'HALT' should stop it - the Run light would I think go out when ODT is running. (It certainly does on the /23.) Can you check that BHALT on the QBUS is actually asserted (i.e. 0V) when the switch is in HALT? Noel
Re: M7264 Troubleshooting
Alright, I hooked the oscilloscope up to SRUN off of E68, and found that it oscillates low at 58.68KHz. This oscillation is very short lived, with it bouncing back up to high nearly instantly. Hitting the Run/Halt switch does not have any effect on the period or amplitude of the oscillation. On Mon, May 20, 2019 at 3:05 AM Brent Hilpert via cctalk < cctalk@classiccmp.org> wrote: > On 2019-May-20, at 12:11 AM, Glen Slick via cctalk wrote: > > On Sun, May 19, 2019 at 11:48 PM Brent Hilpert via cctalk > > wrote: > >> > >> Except the SRUN (K8 SRUN L) action is not latched, so it probably > appears as an > >> active-low heartbeat pulse with some periodicity when the processor is > in run mode. > >> A low-going pulse during PH 3 every instruction cycle perhaps. > > > > http://www.bitsavers.org/pdf/dec/pdp11/1103/1103_Schematics.pdf > > > > Page 171 of the PDF, Lights & Switches Board schematic > > > > The SRUN L signal (routed from the backplane through the power supply) > > is fed through a 74123 retriggerable monostable multivibrator > > one-shot before driving the RUN LED. If the SRUN signal is a pulsing, > > the LED might effectively be driven constantly on. > > > > I don't have the H11 schematic. It's front panel might have similar > > logic driving the RUN LED. > > > Good, that makes sense together, as the duty cycle could be expected to be > too low to light the LED driven directly. > > TTL monostables weren't the most reliable components. > >
Re: M7264 Troubleshooting
On 2019-May-20, at 12:11 AM, Glen Slick via cctalk wrote: > On Sun, May 19, 2019 at 11:48 PM Brent Hilpert via cctalk > wrote: >> >> Except the SRUN (K8 SRUN L) action is not latched, so it probably appears as >> an >> active-low heartbeat pulse with some periodicity when the processor is in >> run mode. >> A low-going pulse during PH 3 every instruction cycle perhaps. > > http://www.bitsavers.org/pdf/dec/pdp11/1103/1103_Schematics.pdf > > Page 171 of the PDF, Lights & Switches Board schematic > > The SRUN L signal (routed from the backplane through the power supply) > is fed through a 74123 retriggerable monostable multivibrator > one-shot before driving the RUN LED. If the SRUN signal is a pulsing, > the LED might effectively be driven constantly on. > > I don't have the H11 schematic. It's front panel might have similar > logic driving the RUN LED. Good, that makes sense together, as the duty cycle could be expected to be too low to light the LED driven directly. TTL monostables weren't the most reliable components.
Re: M7264 Troubleshooting
On Sun, May 19, 2019 at 11:48 PM Brent Hilpert via cctalk wrote: > > Except the SRUN (K8 SRUN L) action is not latched, so it probably appears as > an > active-low heartbeat pulse with some periodicity when the processor is in run > mode. > A low-going pulse during PH 3 every instruction cycle perhaps. http://www.bitsavers.org/pdf/dec/pdp11/1103/1103_Schematics.pdf Page 171 of the PDF, Lights & Switches Board schematic The SRUN L signal (routed from the backplane through the power supply) is fed through a 74123 retriggerable monostable multivibrator one-shot before driving the RUN LED. If the SRUN signal is a pulsing, the LED might effectively be driven constantly on. I don't have the H11 schematic. It's front panel might have similar logic driving the RUN LED.
Re: M7264 Troubleshooting
On 2019-May-19, at 9:09 PM, Glen Slick via cctalk wrote: > On Sun, May 19, 2019 at 8:05 PM Mister PDP via cctalk > wrote: >> >> After that, I decided to try and find out why the >> Run/Halt light was not coming on when I hit the switch. Looking at the H11 >> schematics, the light relies on the SRUN signal coming off of the >> backplane. The problem I am currently facing is I cannot find where the CPU >> board generates the SRUN signal. If anyone who is more experienced that me >> knows how the M7264 generates the SRUN signal, that would be wonderful. > > http://www.bitsavers.org/pdf/dec/pdp11/1103/1103_Schematics.pdf > > Page 27 of the PDF, LSI-11 CPU MODULE (K8) schematic > Grid position B1, the SRUN L signal is driven on to the backplane bus line > AF1. > > I have no idea how the logic works on the M7264 module that drives that > signal. It looks like the CPU chipset is putting a binary 'state action code' onto the WMIB 18-21 lines (sources on page K2) during clock phase 3 (PH 3 H at gate E45.10). The action code is decoded to 1 of 8 actions by E68. Most of the states are latched by the subsequent flip-flops, and those states are cleared or set by the action codes. Except the SRUN (K8 SRUN L) action is not latched, so it probably appears as an active-low heartbeat pulse with some periodicity when the processor is in run mode. A low-going pulse during PH 3 every instruction cycle perhaps.
Re: M7264 Troubleshooting
On Sun, May 19, 2019 at 8:05 PM Mister PDP via cctalk wrote: > > After that, I decided to try and find out why the > Run/Halt light was not coming on when I hit the switch. Looking at the H11 > schematics, the light relies on the SRUN signal coming off of the > backplane. The problem I am currently facing is I cannot find where the CPU > board generates the SRUN signal. If anyone who is more experienced that me > knows how the M7264 generates the SRUN signal, that would be wonderful. http://www.bitsavers.org/pdf/dec/pdp11/1103/1103_Schematics.pdf Page 27 of the PDF, LSI-11 CPU MODULE (K8) schematic Grid position B1, the SRUN L signal is driven on to the backplane bus line AF1. I have no idea how the logic works on the M7264 module that drives that signal.
M7264 Troubleshooting
This is a continuation of my post from about a week and a half ago. The weekend I had some free time, so I returned, armed with a oscilloscope and logic analyzer, to try and figure out what is wrong with my H11A. At first, I tried to use the logic analyzer to confirm that the four clock signals on the MCP-1600 chipset were working properly. After a day of confusing and mixed up signals (I don't really use this type of equipment very often), I realized that my logic analyzer was picking up the signals incorrectly. I switched over to the oscilloscope and was able to see that the very basics of the CPU were working. After that, I decided to try and find out why the Run/Halt light was not coming on when I hit the switch. Looking at the H11 schematics, the light relies on the SRUN signal coming off of the backplane. The problem I am currently facing is I cannot find where the CPU board generates the SRUN signal. If anyone who is more experienced that me knows how the M7264 generates the SRUN signal, that would be wonderful. Thank You, Gavin
