Re: System/36 Kansas City
Man, that its one nice system. If I didn’t already have a S/36, I would be driving down there as we speak. Maybe one of these days I will get my hands on a 9 track for the S/36 like the one in the images. Oh well, good luck to whoever ends up getting the system! On Fri, Dec 13, 2019 at 11:26 AM Dave Wade via cctalk wrote: > In case any one is interested.. > > > > https://www.facebook.com/groups/retrocomputers/permalink/3042809669082227/ > > > > Dave Wade > > G4UGM & EA7KAE > > > >
Re: Looking for schematics of QBUS 32KW memory module.
I guess I should have been a little more specific about the memory issues I was having when I made this post. For the most part these issues seem to be scattered all about memory. Also, while the XXDP I have been running has been catching more or less the same addresses every time I run it, someones it misses a few or adds a few new ones. Moreover when the tests are done, I can read and write to the addresses using OTD just fine, which makes me think the chips that are bad (if they are bad, and it isn't some power related issue) are more flaky than dead. I put one of the outputs from a run of the XXDP test on a pastebin below. https://pastebin.com/mF6qWs0U On Sun, Sep 8, 2019 at 4:01 PM Jerry Weiss via cctalk wrote: > On 9/8/19 3:20 PM, Noel Chiappa via cctalk wrote: > > > From: Mister PDP > > > > > listed back there were numerous bad addresses all over memory. > > > ... > > > I cannot find schematics for any of the boards > > > > . > > > > With the completed chart in hand, given a failing word (address and bad > > data), you can work out which chip is at fault, and replace it. Repeat > > for all memory errors. > > > > Noel's approach is valid and I have done the same on several boards. > Sorry I don't recognize the vendor of your board. > > I would also suggest checking the voltages on the board, especially the > -5V for the memory chip if the memory faults are scattered across the > memory space. The circuitry on the upper left of your picture is > probably a NE555 that is used as a charge pump to generate Vbb from the > LSI power supplies. > > The larger capacitors are probably tantalum (Kemet?) and should have > aged better than electrolytics of the period. > >Jerry >
Looking for schematics of QBUS 32KW memory module.
Hello, A few weeks ago I ordered a Sigma 400255 for my H11A LSI-11 computer with the hopes of getting a 8" floppy hooked up for VCFMW. For the most part, all the tests I ran from the ODT seemed to be AOK. The one this I couldn't do it boot RT-11 from my TU58 emulator, as it would crash every time. Every since I was able to boot RT-11 on my machine it has been unstable and prone to crashes, but i chalked that up to the TU58 emulator, and not the machine itself. Since I needed to boot from to TU58 in order to INIT and make a bootable RT-11 disk for my system, I looked for other causes for the crashes. I ran the VKAA XXDP test, which passed fine. I then ZKMA test, which lo and behold listed back there were numerous bad addresses all over memory. The only memory modules I have are 3 nearly identical 3rd party 32KW memory modules. The one that I have in the system right now came with it, and is the one with memory errors. The other two are ones I bought on eBay that are in rather poor condition and currently do not work at all. I was hoping to transfer some of the 4116 chips from my nonfunctional units over to my semi-functional unit, but I cannot find schematics for any of the boards because they don't have any marking identifying marking on them. If anyone knows where I can find schematics for these boards, that would be wonderful. I am including a picture of one of these boards below. https://i.ibb.co/sQwZw0j/32kwram.jpg Thank You, Gavin Tersteeg
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 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
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
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
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
> 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
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. > >
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
Re: Looking for DEC M7264-CB Troubleshooting Documentation
I was referring to both the ODT prompt and the run light. I get nothing on the console and the “Run” light does not come on when the switch is toggled. On Thu, May 9, 2019 at 12:41 PM Noel Chiappa via cctalk < cctalk@classiccmp.org> wrote: > > From: Mister PDP > > > I was wondering if any in depth troubleshooting material existed > online > > I am not aware of any; I would be glad to be corrected. Unlike the early > gneration of UNIBUS CPU's, these generally weren't intended for internal > fault analysis and repair - module swapping and replacement was the > intended approach. > > The LSI-11 manual (EK-LSI11-TM-003) has a tiny bit of detail on how the > CPU board works (pp. 4-3 - 4-13), it's probably worth reading that before > diving into the CPU board internals. > > Things I'd check to start with - all the power voltages, and then the > clocks. > If those are all OK... BTW, for any serious fault analysis on these things, > you'll need a 'scope/logic analyzer. > > > When powered on, the CPU does not respond to the Run/Halt switch > either > > on the front panel or via the console. > > When you say 'does not respond', what's the symptom? Is the console ODT not > running (which could have any number of causes)? The whole system has to be > more or less running for ODT to work. I'd start elsewhere - e.g. does your > mounting box have the 'run' light? (It's driven by an output of the CPU > card.) Does that display any activity? > > Time to look at e.g. BSYNC, etc to see if the CPU is trying to read/write > the > console registers. > > Noel >
Looking for DEC M7264-CB Troubleshooting Documentation
Hello, As part of my H11A project, I am trying to debug my M7264-CB LSI-11 CPU module. When powered on, the CPU does not respond to the Run/Halt switch either on the front panel or via the console. I found engineering schematics for the M7264 online, but I was wondering if any in depth troubleshooting material existed online (Logic probe points, debugging steps, etc...). Thank You, Gavin
Re: Looking for DEC M8017-AA jumper settings
Well, it defiantly is a M8017 (M8017-AA to be exact), not a M7940. https://ibb.co/rQk55FC >From what I read, the M8017-AA refers to the DLV11-E/EC, but reading through the "DLV11-E and DLV11-F asynchronous line interface user's manual", the diagrams of the DLV11-E and F do not line up my module. On Thu, May 2, 2019 at 10:12 AM Noel Chiappa via cctalk < cctalk@classiccmp.org> wrote: > > From: Mister PDP > > > I have this DEC M8017-AA / DLV11 module that I am trying to configure > > ... the only manuals or resources I can seem to scrounge up are for > the > > DLV11-E, DLV11-F, and DLV11-J. > > If anybody knows what the jumper settings are, or where I can find > > them > > Huh? According to EK-DLV11-OP-001, an M8017 _is_ a DLV11-E? > > If you need config info for a DLV11 (M7940), it's available in the "LSI-11, > PDP-11/03 User's Manual" (EK-LSI11-TM-003), available in BitSavers. > > Noel >
Looking for DEC M8017-AA jumper settings
Hello, I have this DEC M8017-AA / DLV11 module that I am trying to configure to act as a console. I have been trying to find a manual to tell me what jumpers go where, but the only manuals or resources I can seem to scrounge up are for the DLV11-E, DLV11-F, and DLV11-J. If anybody knows what the jumper settings are, or where I can find them, I would really appreciate it. Here is a image of the board I am trying to configure: https://ibb.co/MS3hphz Thank You, Gavin
Re: Zenith Z-90 startup
Hello, I have had this issue with a number of H/Z89s I have. The terminal board and the logic board are two separate systems, so it seems to be common for the logic board to go down while the terminal board keeps working. I would check voltages on the logic board, then take it out of look for blown tantalum caps and burnt traces. The tantalum caps used in these systems seems to like to cause issues, with 5\8 of my systems experiencing issues with them. If that doesn't do the trick then check the power regulators on the logic board, as those can cause issues too. I'm not too familiar with the terminal setting on these systems, but I would check the DIP switch settings with the manual and see if there are any settings changed. There are many good sources for the manuals online last time I checked On Sat, May 12, 2018 at 1:23 PM, Jules Richardson via cctalk < cctalk@classiccmp.org> wrote: > > Any Zenith Z-90 owners out there (which appears to be the same thing as a > Z-89 / Heath H89, but with a DD soft-sectored disk controller)? > > I was given one up a couple of days ago which isn't giving the expected > "H:" prompt at power-on - but it *does* give a blinking cursor, and hitting > off-line lets me type, and characters get echoed to the screen. > Right-shift-reset clears the screen and gets me back to the cursor. > > Before I dig deeper, I'd like to verify that this isn't a feature, i.e. > that it's not auto-magically dropping into "terminal mode" at startup :-) > Unfortunately while I have masses of documentation for the machine, I'm > lacking a basic user guide which might shed light on any such mode; some of > the more detailed documentation that I have talks about rerouting the port > cabling to use the system purely as a terminal, but doesn't mention doing > any other configuration. > > cheers > > Jules >
