• Please review our updated Terms and Rules here

Random find: computer system with pdp 11/23 cpu

God I'm tired of "vBulletin's Expired Tokens". Lost another post just now because of it. The advice to hit the "Back" button to recover your post doesn't work, and there is no indication it auto-saved. I'll try to reconstruct...

  • Glen - I apologize to you. I didn't mean to be contradictory, only to indicate my feelings that DEC documentation may not apply to this backplane. I now see we are in agreement.
  • On the Drive cables - Again I agree, I don't see them. This is why I asked about the board from J2B, which I'm guessing is an RQDXE like board, possibly to break out cables for drives. All this is supposition on my part till we see pics.
  • BOOT - yes, I'm going to assume there's a courtesy boot ROM in the set somewhere. You seemed more familiar with this vendor [SMS] than I, and I thought you might have more specific knowledge on this.
  • SEgamer - yes, thank you - that is the CPU. I'll research it. I see it has the MMU installed.


On ODT:

  • Please perform a little experiment for me: Get the system to the ODT prompt ["@"] and enter "0/" then <LF> [which is CTL-J on a PC keyboard in Hyperterm]. Post the entire sequence here.
  • When you did that test on address 17773000 and 17772150, was the QUAD board installed in SLOT 0 at the time?


I still wonder if there was a missing card in J4B, and what it might have been.

The idea of re-seating socketed parts on the Disk Controller board is risky, but if you have the confidence to try, it may help. Could we put that idea in abeyance until we get a little further along?

My non-DEC documentation is limited to only a few vendors. Unfortunately, none of yours are on my list.

We can stumble along on this road without documentation and probably get somewhere, but it's going to take a little time. Correct documentation will be the best way to speed things along. I suggest we continue trying to find some. A good start would be the memory board, with the Disk Control being a good second.
 
God I'm tired of "vBulletin's Expired Tokens". Lost another post just now because of it. The advice to hit the "Back" button to recover your post doesn't work, and there is no indication it auto-saved. I'll try to reconstruct...
Sorry to interrupt here, but I have the same problem. When I hit "post" or "preview", it has usually been a little while and it gives me the login screen. When I then log in, I'm back editing where I was - nothing is lost. I think hitting the "back" button will not work properly. I'm usually using an ancient version of FireFox, but I don't think that matters.
 
Sorry to interrupt here, but I have the same problem. When I hit "post" or "preview", it has usually been a little while and it gives me the login screen. When I then log in, I'm back editing where I was - nothing is lost. I think hitting the "back" button will not work properly. I'm usually using an ancient version of FireFox, but I don't think that matters.
This doesn't match my issue - I never get the login screen. To cure my problem, I must completely exit the browser and re-enter the site to cure it. A simple reload doesn't cure anything, but you only find out after you assemble/edit another item and then try to POST it. Once I get the "Expired Token" error page with the "back" advice, the post is lost. Your problem is likely the age of your browser and it's use of cookies. I admin a vBulletin site elsewhere and yours is a common complaint. Mine is much less common, fortunately.

Ok, back on topic.

SEgamer - We might be better able to help working on multiple research tasks at once. Could you post a battery of photos including as much details about the interior and cabling of the box and drive(s) as the system was when you opened it?

I checked out Clearpoint [a vendor I recall but which we never used] and it seems DATARAM began offering support for their products in 1993. Maybe that will surface a few more corners for us to look in for docs.


My thinking is that we need to figure out if this system was in an operation configuration when you got it [sans a missing card] or was it perhaps a "Hangar Queen" housing a bunch of more or less spare parts from other systems.

Some things we now know:

  • The CPU and SLU TT0: look operational [9600,N,8,1]
  • The power supply is at least partially functional
  • The Hard Drive sounds like it may be working, and perhaps still has a viable image on it. [thanks to your test with the PC]

Major Questions:

  • How were drives connected?
  • Is memory functional?
  • How is the Disk controller addressed? [i.e. - is it an RL emulator type or DU]
  • Is there a boot-rom on one of the system's cards and what are it's features?
  • Now that the console terminal communications are working, would it be possible for you to completely re-assemble the system in it's original config and try it again?
    • There might be some useful info printed to the console even if it doesn't start. Remember that some powerup memory tests can take a while so don't expect an instantaneous output. Don't forget to change W5 on the CPU back, at least temporarily.


Pics, pics, and more pics. Will these guys ever be satisfied??
 
I'll upload large pics of the entire case, outside and in, each card, and the backplane later today. Will also upload pics of the way it was hooked up before.

As for your questions, RSX:

- When I tested 17773000 and 17772150, the system was set up the way I got it (all boards connected and in their original locations)
- Drives were connected to the quad board disk controller when I got it
- Memory appears to be functional most of the time. I did write a basic program found here: http://www.codehosting.net/blog/BlogEngine/post/Do-nothing-Do-nothing-Do-nothing-Stop.aspx
and it appeared to run through and stopped with 1010 being the updated current address. Sometimes though, after running the program or entering a bad command would cause an
error when trying to enter in data (240 would show up as 000340 or 0 would show up as 000100, so that one bit would always be 1 for some reason instead of 0)
- Not sure how to check for the disk controller address, what do I need to do to see if it's RL or DU?

Thanks for all of the help so far, otherwise this thing would just be a fancy, heavy doorstop. :). In my next post, I'll also upload a document that sums up all of the information/findings/results that I've gotten so far.
 
Last edited:
Good response - Thanks.

Some "Standard Addresses" to check for:

  • 17774400 RL type controller - most commonly emulated
  • 17777170 RX - 8" Floppy
  • 17777400 RK - this type was less commonly emulated
  • 17772150 DU - you already know

Fairly common BOOT addresses: [not an absolute guide]

  • 17765000 - Diag Boot
  • 17773000 - RL Boot
  • 17773200 - DU Boot


A response on any of those will give us clues.

Sounds like you might have a stuck memory bit - it's a fairly common ailment. Some here are pretty knowledgeable how to narrow down those quickly. Give them time to post. It's an advantage that the chips are socketed.

I wish we could check the power supply voltages and quality first though.


Please remember to get those ODT test results. [just covering the bases]
 
Turning up some search results....


This chain mentions "CAPS" which could be a reference to CAPS-11. If so, this may be the OS on the hard drive. Please do nothing to disturb it. One of our members will be very interested to get data off of it, if this is the case. [he can help you troubleshoot that memory] I'm not sure how likely this is to turn out to be true, and could be a mistaken identification on my part.
 
And that would be yours truly who would be interested if CAPS-11 was on that disk. I understand that GenRad may have used CAPS-11 in some ATS (automated test systems, as in board testers).

And sorry for chiming in late, but I just read this thread just now. It looks to me like an AB/AB backplane (no CD interconnect.) However, it seems strange to me that the disk controller is at one and of the bus. Usually the processor is at one end of the bus providing termination, and then a terminator board (like BDV-11) or resistor packs on the backplane provide termination at the other end.

At any rate, it might be useful to identify the bus grant chain path (is it serpentine, or something else strange). Then all gaps can be eliminated from the grant chain.

I see the SA860 drive in the front of the machine. It seems likely that this was DY: and the controller should respond at the standard RXV21 CSR. I would bet that the MFM disk drive is DL: (as I think RSX11M+ may have said earlier.) It have an MDB controller that does this. I am pretty sure that it was so that cheap MFM drives could be used before dec made RQDX1 and RT11 V5.0 that supported MSCP controllers.

Assuming nothing has been toasted, it should be a nice machine.

Lou


Turning up some search results....


This chain mentions "CAPS" which could be a reference to CAPS-11. If so, this may be the OS on the hard drive. Please do nothing to disturb it. One of our members will be very interested to get data off of it, if this is the case. [he can help you troubleshoot that memory] I'm not sure how likely this is to turn out to be true, and could be a mistaken identification on my part.
 
Last edited:
Here's the text file with all the info I could get out of this thread (includes links to pdf files and photos). I'll keep updating this file so it'll be easier to keep track of everything. Download link is at the top right.

https://docs.google.com/open?id=0B2FtwqsDAw2PMGY4NTQ2OGEtYWU0Yy00YTc1LTk3N2MtMmI2NWM5Y2NkOTIz

I forgot to ask earlier, but when doing the 0/<lf>, how far should I go?

A couple locations should do it. I'm interested in the format of the response. [no ESCs please]

About your results posted elsewhere...

ODT Address Tests

The following is the exact response I got from the system in ODT. To avoid any confusion: I sent an Esc command between each address test to make it easier to read.

@17774400/?
@
@17777170/000040
@
@17777400/?
@
@17772150/?
@
@17765000/?
@
@17773000/005000
@
@17773200/012700

From those results, it looks like I'm getting responses for the 8" floppy, RL Boot, and DU Boot addresses.


  • Yeah, looks like you have a control for an RX [DY:] device.
  • On BOOTs... I'm not so sure. We'll look at this more later. See if you can determine the first BOOT ROM location the system responds to. Then with it open [after you've hit "/", hit <LF> a couple dozen times or so and post the outputs. Maybe we'll recognize the code. You could do this same thing at 17773000 and 17773200.
  • The detailed photos you posted at that link allowed me to see that the card in J2B is not an RQDXE like thing.
  • You also said there that originally, the HDD ready light wouldn't come on. Does it come on now that you've reassembled the system?
  • Do you still have the CPU starting to ODT? What were the original settings of those CPU jumpers please.


Other possible CSRs for you to investigate:


  • 17776700 RM
  • 17776300 RM / alt
  • 17777460 RF
  • 17772040 RS
  • 17777440

Lastly, on the QUAD Disk Control module, there's a small white connector in the right corner near the "A" fingers... was it plugged into anything?
 
HDD light still doesn't come on, and nothing was plugged into the connector on the quad board. I didn't see a spare power connector in the case either.

Here's the results:

@0/137645 (parity LED on the RAM board came on after this)
000002/040021
000004/137645
000006/040021
000010/137445
000012/040001
000014/137445
000016/040001
000020/137445

Lowest address it responded to out of the ones you gave me was 17773000.

@17773000/005000
773002/000240
773004/000240
773006/000240
773010/000240
773012/012710
773014/100002
773016/000400
773020/000005
773022/000167
773024/000006
773026/000240
773030/005000
773032/005010
773034/012700
773036/000340
773040/106400
773042/000401
773044/000000
773046/010001
773050/010105

None of these returned any data:

17776700 RM
17776300 RM / alt
17777460 RF
17772040 RS
17777440

The original config of the CPU jumpers was W6, W8 - W15 being connected. (Mode 2 and boot at 173000)
 
Ok, that's what I needed to see. Your CPU is in 18-bit mode. It's probably an 18-bit backplane, although it could be that the CPU is limited to 18-bits. [I haven't checked yet] ...and thanks for the CPU jumpers... I'll try to get to that tonight.

Please re-inquire those CSRs to be sure you get the same results, but drop the first two [most significant] numbers.

I.E.- 17772150 becomes 772150 - and so on.

The results should turn out the same, but I've seen systems where it mattered.


Lowest address it responded to out of the ones you gave me was 17773000.

I should have been clearer on this... does it respond to 772776? I'm looking for the lowest number in a contiguous block that it responds to, not just the lowest I listed. [although that info was helpful - thank you]

I found some SMS documentation, but so far it's not for yours. I'm reading through it to try to get a sense of their "style" of design. Very often in PDP-11 land, products were designed in "Families", each succeeding generation building on the last. I'm hoping to understand yours by similarities.

Anyway, I really expected us to find one of the CSRs for the more pedestrian HDD types. If the system's OS is CAPS-11, I would think the hardware would be based around DEC standard hardware addresses. There were standard "Alternate" and "Secondary" addresses, but I don't have a reference for all of them handy.

So another way we can proceed is to look at the BOOT code, and try to understand what I/O it's trying to use.


One last thing you can try - at the ODT prompt enter 773000G and wait a little while. See if anything is printed afterward. Watch the drive lights and listen.. there may be clues to be observed.

Your description of the memory does sound like we have work to do there. I'm still a little concerned that a weak power supply could be glitching the memory board. When we get to troubleshooting, we'll reduce the board compliment to only the memory and CPU. I pulled down the memory board DOC, so I may be able to offer some thoughts before the pro gets back. [Lou]

Anyway, I'll look at the BOOT code you posted now, and the CPU and get back to you.
 
Looking at the dual SMS controller card and referencing the manual you point to on bitsavers, it looks like U32 and U33 are the boot roms. Do you know what the connector on this board was connected to?
 
Looking at the dual SMS controller card and referencing the manual you point to on bitsavers, it looks like U32 and U33 are the boot roms. Do you know what the connector on this board was connected to?

I believe you are referring to Appendix B in this document. I agree with what you said in so far as - it does appear to be describing an ancestor of SGgamer's board described as being in slot 2B, just after the CPU. If true, it also implies the board in this system is Q-22 capable, as noted in that text.

The SMS product looks different than any I've seen for PDP-11, so I thought it would be worth describing a little. Although we do not have the precise documentation for this exact product, I now feel safe in making the following deductions.


  • The board set is comprised of two modules...
  • a QUAD wide board referred to as the "Formatter" in other versions - contains logic to deal with the DRIVES and MFM conversions
  • a DUAL wide board - referred to as the "LSI-11" Interface board - which provides the particular system access to the "Formatter".
  • The Formatter and the LSI-11 board interface via a 40-pin ribbon cable shown in this photo. [to answer PG31's question]
  • The LSI-11 board contains a system BOOT rom set [again, as PG31 observes]
  • I also believe the set provides a single CSR 177170 [or in our case 777170] to access BOTH the 8" floppy and the "Winchester" hard drive. This conclusion is based on code examples [see pages 4-78 and 4-79] and other descriptions in this document. [again - seemingly not specifically for this version of the board set]
  • It is possible that the "Formatter" board only uses the slot for power and hence is not part of the bus chain and can therefore live on the normally "illegal" side of the CPU. It may also be that this is not a "QBUS" slot at all. For safety's sake, I suggest both the slot and the board be treated as NON-QBUS for the time being. Do not put QBUS boards in this slot [0?], and do not put the QUAD board ["Formatter"] in any other slot.

It is unclear to me how this "single CSR" works with standard DEC software systems, but from claims in the literature, it apparently does. This methodology may be explained more fully in the documentation, I only skimmed it sufficiently to come to a general understanding. I plan to undertake a more thorough read of it at some point.
 
Please re-inquire those CSRs to be sure you get the same results, but drop the first two [most significant] numbers.

I.E.- 17772150 becomes 772150 - and so on.

The results should turn out the same, but I've seen systems where it mattered.




I should have been clearer on this... does it respond to 772776? I'm looking for the lowest number in a contiguous block that it responds to, not just the lowest I listed. [although that info was helpful - thank you]

I got the same results re-entering the previous addresses without the first two numbers. No response at 772776.

That one issue where I would enter 137 but it would show up as 037 is gone. Now when I enter 240, it shows up as 340 (now it's always on!). So Bit 6 seems to be the problem.



Here's what happened when entering 773000G

@773000G (Run light turned on, two seconds later the parity error light on the RAM board turned on, Run light turned off)

I flipped the Boot switch to see where it got stuck, and this came up every time (don't know if this helps, but I'll try posting everything I find)

000001
@

I also found and typed up the printout from some GENRAD programs they used for the drives. I feel like a dunce for not posting it earlier since every bit of info helps.

https://docs.google.com/document/d/1KPPZvzLREd52daIBc6mLWkpzDta2pCmP6QAOmqtX0i4/edit

Did that Formatter program mentioned wipe the drive? If so, I should've already assumed this because it came from an air force base, but it looks like optimism got in the way.

Now that my other projects are out of the way, I'll start reading the manuals and see if I can provide any useful input/suggestions on the matter.
 
Last edited:
I think it's stopping because of the memory errors. If the system had memory errors, it's highly doubtful they could have run a program to wipe the disk. They probably stopped using the system because it was inoperative, and sold it when it was inactive long enough not to be on anyone's list of concern.

I actually found those instructions elsewhere, but it didn't matter much because you don't have that floppy diskette... ?

If you want to read anything, start reading memory troubleshooting experience on that board type.


Here's what I'd like you to do next.


  • Remove all cards except the CPU (J1A).
  • un-power the disks
  • Install the memory in J2B
  • Install the Serial card [with TT0:] in J3A.

Power the system and re-check the RAM memory locations again, starting at address 0, and see if it's still misbehaving.

I still have concerns the power supply could be marginal, but if the problem persists with this lower card count, then we can try troubleshooting.

You have a big advantage because those ram chips are in sockets, which gives us a lot of easy options. We may be able to move a bad chip to an area that doesn't matter, or reduce the memory quantity temporarily to get more progress. One step at a time.

We need to find you a source for new RAM chips. Oh, Lou...?
 
Well after reading through the manual I found for the RAM board, it isn't exactly the one I have. The jumpers are different and mine has fewer jumpers than a regular Q-RAM 11. Another problem is that the pdf for it is missing Appendix B - Detecting Memory Chip Errors.

I did find info on the jumpers at least for my board (Q-RAM 11B): http://www.classiccmp.org/pipermail/cctech/2006-November/030357.html

The three jumpers labeled F are more than likely the battery backup settings based on the Q-RAM 11 manual. It seems that the 11B is just a re-packaged 44B that was probably shipped with 256K memory and different jumper settings.

If this info is correct, mine is set for 17772100 as the parity CSR address, 22 bit addressing, bank 0 set for 64k chips, bank 1 jumper missing (I hope this is the only thing causing the problem), no battery backup, 2M memory (all jumpers are set to 1, so this may be backwards), and the bits for the base address are all 0. (so it's the same as the CSR address?)

In the link, his board has all memory jumpers set to 0, but he says his board has 2M of memory. Mine is the opposite, where it has 256K memory and all jumpers are set to 1; but the way they described the settings contradicts what the jumpers are set to. Hopefully someone here has one for a 44B or 11B (probably the same manual) because I can't find one anywhere.

As for replacement chips, I do have spare RAM boards and an old video card for my IBM XT that have socketed chips that should work.
 
Last edited:
It is unclear to me how this "single CSR" works with standard DEC software systems, but from claims in the literature, it apparently does. This methodology may be explained more fully in the documentation, I only skimmed it sufficiently to come to a general understanding. I plan to undertake a more thorough read of it at some point.

If the controller in this system operates in the same way as the controller described in this manual, it sounds like it is only compatible with standared DEC software when operating in Compatible Mode, which only provides access to the floppy drive. To access the hard drive the controller needs to operate in the Extended Mode, for which you would need to use 3rd party drivers for the controller.

http://www.bitsavers.org/pdf/sms/qbus/3000632D_FW_OEM_Feb82.pdf

IV. PROGRAMMERS'S GUIDE

A. MODES OF OPERATION
In order to be either compatible with DEC software or alternately to offer enhanced performance and capacity, the controller may be operated in one of two modes. These modes are the RX02 compatibility mode and the extended mode.

RX02 Compatible Mode
In this mode the controller is completely compatible with the DEC RX02 floppy family, including single and double density format compatibility. When the controller is operated in the compatible mode, the following features are offered over the DEC RX02 system.

Extended Mode
The extended mode of the controller is its most powerful and useful mode. This mode offers significant functional and performance advantages over the DEC RX02 floppy disk system plus access to a fixed Winchester disk system using a common software handler. The same device registers are used to access both the floppy and fixed drives.
 
Thanks Glen - I was afraid it was something like that. [either / or] I'd not read that [spending time looking for QRAM44 stuff] but didn't it indicate that the boot roms could start from the Winchester? Interestingly, if the disk contains a bootable system, the drivers for the Winchester would likely be on it, no? [...guess I'm "a glass is half-full guy"?]

Our ram error is preventing us from getting to the "DRV?" prompt to enter the "W0" to make the attempt to boot the HD.

Back to SEgamer...


So you may have a source of spare chips then... Are you certain they're the same? This would be good. Depending on how many you have, there's always the "shotgun approach".

I too would be more inclined to follow a manual for a QRAM 44 over the one we have for an "11", an obvious mismatch. Those notes you found looked pretty relevant, although the descriptions for the "memory size" [section "D"] are not making sense to me yet.

CSR is not the same as the base address. It's a Parity memory, that's what the CSR is about. The base address is where in memory the RAM is set to respond to, which in your case should be 0000000. Did that answer your question or do I misunderstand?

Troubleshooting...

Does anyone have any intuition on "where in the words" these chips are? [geek humor]

We need to figure out the purpose [position] of each chip in memory. We could have you pull all the chips, except one and try to find the pattern, but I'd hate to loose the positions each was in now, since we have a demonstrable [non-intermittent] problem at the moment. Don't pull em yet. The problem with sockets is they become unreliable the more insertions they experience. Finding a strategy that minimizes this is important [to me anyway].

Incidentally - there's a lot of dust in those photos. Think you could find a way to vacuum it off a bit, maybe "dust it" with a clean soft bristle paint brush? This needs to be done before we start pulling ICs, and maybe again afterward.

A thought about board ID - please look on the back-side artwork for another identification. I'm wondering if it's an in-between artwork. How would you feel about looking under the paper label that says "11B" on the topside?

What electronic tools do you have on hand? Would you be able to use a scope or a logic probe?

I've been experimenting with a PC program I wrote that "Talks" ODT. It should be possible to add the ability to look through memory to find non-working memory bits and exercise them - or to loop-read/write a single address or bit so you could identify chips with a logic probe. This could be a reasonable troubleshooting aid not necessarily requiring chip depopulation. Maybe someone else has done this already?

Sure would be nice to find an accurate schematic.
 
Back
Top