From memory this is automatic after you've been around a little while and posted a bit. One of the safeguards to try to deter spammers and the like.
- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
Problems using tu58em with VAX-11/725 / VAX-11/730
- Thread starter vaxorcist
- Start date
From memory this is automatic after you've been around a little while and posted a bit. One of the safeguards to try to deter spammers and the like.
AK6DN
Veteran Member
[ Sorry to hijack this thread temporarily but PM does not work yet ... I'll try and make this interesting to others as I can ... ]
Yup. I was over in ML21-4 early on but made the trek over to ML5-5 all the time to load and debug a new diagnostic image whenever you had the system up and running. And waiting on Art Lim to get a new FPP microcode image. Later on when the FP11-E started I adapted the diags to that board set and added some hardware specific tests. IIRC the FP11-E was the fastest FPP of all those available on PDP-11s (even 11/70).
Next I worked on the 11/60 microdiagnostic that went on the DCS (diagnostic control store) module that tried to do board and chip level failure detection. Mike Carafiello (sp?) did the DCS board IIRC. Spent many long hours debugging that microcode as it could only be done on the h/w proto. Usually third shift :-( as I recall as I was low man on the totem pole.
If you feel nostalgic for the 11/60 you can go HERE to see lots of saved documents.
After the 11/60 shipped (and I made the obligatory trip to Aguadilla PR to bring up the diagnostics in manufacturing...) I moved from diagnostics to engineering to work on the 11/74 CISP microcode with Lewis Costas and David Sager. Very technically challenging, the goal was to make the 11/74 CIS run as fast as possible (ie, cache bandwith limited) on the 11/74. We did that and once we finished and got it all working marketing canceled it. I remember Mike Brown and Ray Boucher did the hardware design. Jim Brown (later Bob Magers IIRC) was project manager.
Most people don't believe the 11/74 CISP ever existed and equate 11/74 as meaning just the 4xCPU MP option (which was really just 11/70MP before that, Verell Boaen was the project engineer/designer on that effort IIRC). But I have THIS to prove that it did (this is a scanned image of a real plex panel I have in my possession). There are also some interesting documents HERE that you might want to look at just for yucks.
One thing I remember was the 'multiwire' quick turn boards that were done for the CISP board set to help speed bringup. They were so unreliable however that each time they flexed a bit connections from the wires to the vias would come and go, and after a short time they were just covered with a mat of soldered 30ga red wires to bypass the intermittent traces. I think that was the first, and last, time that multiwire was tried. A technology way before its time.
A few years ago I was able to get a couple of 11/60 board sets, an 11/60 backplane, an 11/60 console, an 11/60 DCS module, and an FP11-E board set from various sources. At some point I want to try and bring it up on the bench, and see if I can cram it into a spare BA11-K box I have. Not too many running 11/60s around these days, it was a rare beast that was only sold for a very short period of time (couple or three years IIRC). Lots of 11/44s and 11/34s (I have one of each, both running) still around and available. If I have trouble bringing up the 11/60 I'll give you a call
Good to hear from you, hang around this board and give some insight to some of the young-un's on the good old PDP-11 and VAX days before they became just single chips.
Regards,
Don
PS I think the PM issue is because you haven't been a member here long enough as a prior poster indicated.
Last edited:
jmiddleton
Member
- Joined
- Sep 10, 2015
- Messages
- 10
Don,
I still don't have access to PM, so I'll just have to use this thread.
Well, between the 11/60 and the 11/74 we must have crossed paths quite often. If I saw you in person (or maybe as you looked back then) I'd probably recognize you. And likewise you seeing me as I was back then.
I remember many of the 11/60 and 11/74 people quite well. The manager of the 11/60 project when I first arrived was Jega Arulpragasam (sp?), but Jim O'Loughlin took over at some point and he was in charge when it was released to manufacturing.
When they brought me up from San German, PR to help debug the 11/60 I lived at Rosie's Apts., across the street behind the Shell gas station and the Maynard House Of Pizza. I would go to work by entering building 21 and working my way up to 5-5.
I worked 3rd shift 11/60 debug with Mike Carrafiello for about 3-4 months, then 2nd shift debug by myself for the rest of the year I was there. We sat at an LA-30 terminal and debugged microcode and hardware five nights a week. Then Mike and the two Dave's who were working second shift moved on to do other things on the project and I moved to second shift in the lab space on the other side of the offices.
One vivid memory I have from my second shift days is that Richie Lary would take over my machine during my dinner break and work on his WCS (Writeable Control Store) PDP-8 emulator. He got it working and, as I was told many times, it was the fastest PDP-8 in the world, so fast the WPS-8 developers used it for years to compile that OS. That's what various people said, FWIW.
FYI, Mike and I are still in touch.
Originally the 11/60 boards were supposed to built and tested in San German, but part way through my time in Maynard they shifted it to Aguadilla and I had to choose between sticking with the 11/60 and going to Aguadilla, or changing to some other project and going back to San German. For better or worse (mostly better) I decided to stick with the 11/60.
FWIW, they put the 11/60 boards into layout *long* before they were really ready, so the boards we used for several months ended up a rats nest of etch cuts and 30 gauge wires. The wires were mostly on the "2" sides of the boards and there were so many we had to tape Mylar sheets (the type used to separate core memory boards) to the "2" sides of these "re-worked" boards to keep the wires from being ripped off when removing or replacing a board. The "best" board had about 400 wires, and the worst about 800. I have no idea how many etch cuts.
After putting in a year in Aquadilla supporting the startup of the 11/60 module manufacturing line, someone from the 11/60 team (O'Loughlin?) asked me if I'd like to transfer to Engineering in Maynard. I jumped at the chance.
The job in Maynard was originally supposed to be lab debug tech for the 11/60A, a proposed follow on to the 11/60 that would have added various features, such as extended addressing (4 megabytes). But it was cancelled shortly after I got there and I really had nothing to do for a while. The 11/74 CIS group (Jim Brown, Ray Boucher, and Mike Brown) was right next to the area where I was, and eventually I was offered the job of lab tech for the 11/74 CIS, which I took. It was kind of a mess when I started there, so after a couple of weeks of PDP-11/70 school, I cleaned it up and got everything working. Sometime after that they transferred us up to the Tewksbury facility.
Comment: yes, the PDP-11/74 CIS existed. I worked on it for about a year. Unfortunately, unlike Don, I don't have anything tangible to show from it.
I remember a couple of interesting things from that project:
1) I hand wired the timing signals of the first 11/74 CIS backplane, which were normally just twisted pair wires. They got the backplane manufacturing group to build one with no timing signal wires, and then, with a wire wrap gun in hand, I connected things up using coax wires. Putting the core wires on was easy, but the ground wires were difficult at times since they were supposed to be attached to a ground pin that was within a certain radius of the core wire attachment point (1" I think). In some cases I had to put a fifth chunk of wrap on a pin because all the ground pins in range already had four, which meant I couldn't put the "required" number of wraps on the pin. But it worked, and the first time I started things up with standard 11/70 boards the machine came right up. I breathed a sigh of relief.
2) There were an awful lot of control store ROMs, something like 100 if memory serves me. That was way too much for one board (it got *very* hot), so they decided to distribute them across two boards. Of course that made the option even more expensive to produce.
Enough for now. I have to get back to the VAX-11/730 Console and TU-58 document.
John
I still don't have access to PM, so I'll just have to use this thread.
Well, between the 11/60 and the 11/74 we must have crossed paths quite often. If I saw you in person (or maybe as you looked back then) I'd probably recognize you. And likewise you seeing me as I was back then.
I remember many of the 11/60 and 11/74 people quite well. The manager of the 11/60 project when I first arrived was Jega Arulpragasam (sp?), but Jim O'Loughlin took over at some point and he was in charge when it was released to manufacturing.
When they brought me up from San German, PR to help debug the 11/60 I lived at Rosie's Apts., across the street behind the Shell gas station and the Maynard House Of Pizza. I would go to work by entering building 21 and working my way up to 5-5.
I worked 3rd shift 11/60 debug with Mike Carrafiello for about 3-4 months, then 2nd shift debug by myself for the rest of the year I was there. We sat at an LA-30 terminal and debugged microcode and hardware five nights a week. Then Mike and the two Dave's who were working second shift moved on to do other things on the project and I moved to second shift in the lab space on the other side of the offices.
One vivid memory I have from my second shift days is that Richie Lary would take over my machine during my dinner break and work on his WCS (Writeable Control Store) PDP-8 emulator. He got it working and, as I was told many times, it was the fastest PDP-8 in the world, so fast the WPS-8 developers used it for years to compile that OS. That's what various people said, FWIW.
FYI, Mike and I are still in touch.
Originally the 11/60 boards were supposed to built and tested in San German, but part way through my time in Maynard they shifted it to Aguadilla and I had to choose between sticking with the 11/60 and going to Aguadilla, or changing to some other project and going back to San German. For better or worse (mostly better) I decided to stick with the 11/60.
FWIW, they put the 11/60 boards into layout *long* before they were really ready, so the boards we used for several months ended up a rats nest of etch cuts and 30 gauge wires. The wires were mostly on the "2" sides of the boards and there were so many we had to tape Mylar sheets (the type used to separate core memory boards) to the "2" sides of these "re-worked" boards to keep the wires from being ripped off when removing or replacing a board. The "best" board had about 400 wires, and the worst about 800. I have no idea how many etch cuts.
After putting in a year in Aquadilla supporting the startup of the 11/60 module manufacturing line, someone from the 11/60 team (O'Loughlin?) asked me if I'd like to transfer to Engineering in Maynard. I jumped at the chance.
The job in Maynard was originally supposed to be lab debug tech for the 11/60A, a proposed follow on to the 11/60 that would have added various features, such as extended addressing (4 megabytes). But it was cancelled shortly after I got there and I really had nothing to do for a while. The 11/74 CIS group (Jim Brown, Ray Boucher, and Mike Brown) was right next to the area where I was, and eventually I was offered the job of lab tech for the 11/74 CIS, which I took. It was kind of a mess when I started there, so after a couple of weeks of PDP-11/70 school, I cleaned it up and got everything working. Sometime after that they transferred us up to the Tewksbury facility.
Comment: yes, the PDP-11/74 CIS existed. I worked on it for about a year. Unfortunately, unlike Don, I don't have anything tangible to show from it.
I remember a couple of interesting things from that project:
1) I hand wired the timing signals of the first 11/74 CIS backplane, which were normally just twisted pair wires. They got the backplane manufacturing group to build one with no timing signal wires, and then, with a wire wrap gun in hand, I connected things up using coax wires. Putting the core wires on was easy, but the ground wires were difficult at times since they were supposed to be attached to a ground pin that was within a certain radius of the core wire attachment point (1" I think). In some cases I had to put a fifth chunk of wrap on a pin because all the ground pins in range already had four, which meant I couldn't put the "required" number of wraps on the pin. But it worked, and the first time I started things up with standard 11/70 boards the machine came right up. I breathed a sigh of relief.
2) There were an awful lot of control store ROMs, something like 100 if memory serves me. That was way too much for one board (it got *very* hot), so they decided to distribute them across two boards. Of course that made the option even more expensive to produce.
Enough for now. I have to get back to the VAX-11/730 Console and TU-58 document.
John
Marty
Veteran Member
Hi All;
John, and Don, I could Listen/Read Your "Dec" Stories for Days at a time..
Please, Please give the rest of us some of these as You can..
John, You Mention that when You first brought up the 11/74 it was with 11/70 Boards, So what was the difference ?? Microcode..
John, as others, including Don already know, I have a PDP 11/45 (in a wooden frame), which after I (hopefully can get the PDP 8i clone going) I can get back to the 11/45.. And maybe John can make some suggestions to help me get it going once again..
THANK YOU Marty
John, and Don, I could Listen/Read Your "Dec" Stories for Days at a time..
Please, Please give the rest of us some of these as You can..
John, You Mention that when You first brought up the 11/74 it was with 11/70 Boards, So what was the difference ?? Microcode..
John, as others, including Don already know, I have a PDP 11/45 (in a wooden frame), which after I (hopefully can get the PDP 8i clone going) I can get back to the 11/45.. And maybe John can make some suggestions to help me get it going once again..
THANK YOU Marty
AK6DN
Veteran Member
When I first transferred to the 11/74 project there was no office space left in building 5, so us microcoders were relocated into the Mill main office building (the small two story office building right on Main Street at the main gate). There were three of us total in the building for several months until we moved up to the new Tewksbury site. The distinguishing feature in the building was a room on the first floor that had a huge cast iron safe, a big spherical oval object, about four or five feet in diameter. The original safe for the paymaster at the Mill, and it was probably set in place back in the 1860s, and then the building was built around it. Likely it is still there today.
The main 11/74 CPU board set leveraged the 11/70 as much as possible, only enough changes were made to the CPU boards and backplane to hook in the CISP processor to the datapath and necessary control signals. So I seem to recall that 11/70 boards would work in the 11/74, but not the other way around. I think the main topology change in going from the 11/70 to 11/74 backplane was pushing all the slots down four locations to make room for the four board CISP processor set, and I recall that one of the RH controller subsystems was pushed off the end of the backplane in the process.
The 11/74 CPU control store was upgraded from 256x64b to 512x64b (same number of devices, just 2X bigger) to allow for some CPU code space for the CISP option communication. On the CISP board set as you mention the full control store was 4096x96b which I think was something like 96 1Kx4 bipolar prom devices. As you indicate it ran pretty hot. One of the worst times was when we had to burn the PROMs for a new microcode release. 96 devices to program on the CISP, and usually another 16 for the base CPU.
Luckily for most of the development we had a bipolar RAM WCS box that was controlled by an 11/05 running RT11. The RAM WCS could run at full speed and was large enough to map the whole 4Kx96 microcode image. So for most lab microcode debug and testing it was just reloading the WCS with the new microcode image. We only had one WCS box however, so that one proto system was used basically 24/7 during debug and bringup.
There are lots of speculations on why the 11/74 was cancelled and never produced. Backplane was costly to produce, but in reality it was not much different than the existing 11/70 backplane in terms of complexity. There was nothing that esoteric on any of the updated 11/74 CPU boards, and the CISP processor was not using any esoteric technology, just schottky TTL and bipolar PROMs on a four hex board set.
My opinion is the demise of the 11/74 CISP had to do with its performance. It was just too good, and in COBOL benchmarks at the time (the only language compiler supporting the new CIS instructions) we just blew past the same benchmarks running on the newly announced VAX-11/780 running COBOL. Not by just a small margin, but by 3X to 5X faster. This made the mid-range systems marketing group (at the time PDP and VAX were both in Tewksbury, just down the hall from each other) sh*t in their pants, and they basically said no way can you ship a PDP-11 system that will outperform the newly released VAX that was just starting to get traction in the market. So bye bye 11/74 CISP.
Don
Last edited:
pbirkel@gmail.com
Veteran Member
'Tis a shame that no documentation for that CIS design has surfaced. Would be (IMO) a very interesting read ....
Do you have any specific recollections about that which you could share? E.g., did it take the 11/44 CIS design as a starting point, or strike out in a completely new direction? What made it so complex compared to the 11/44 design?
AK6DN
Veteran Member
Actually the 11/44 CIS design was going on at the same time as was the 11/74 design, it was maybe a few months behind it. The 11/44 CISP microcoder (a guy named Wayne Uejio, he was quite a character) was the sole microcoder on the 11/44 CISP. Their goal was a complete implementation on the two boards they could allocate to CIS (a hex datapath and a quad control store). Maximum performance was NOT a goal of the 11/44 CISP.
The 11/74 CISP and 11/44 CISP microengines were not derived from one another. They shared some datapath similarities (each having an integer path based on 2901 bit slices; 11/74 was 32b, 11/44 16b; each having a dedicated decimal arithmetic datapath that could do byte wide packed and zone decimal arithmetic) but not much else was common. The 11/44 would serialize operations in time to save logic and minimize datapath width. The 11/74 had full width datapaths (32b integer) to do computations in one cycle, and lots of special purpose logic to handle the nuances of each of the various CIS instructions (packed decimal, character string, conversion to/from integer). 11/74 CISP uCode was 4Kx96, 11/44 uCode was 1Kx88. 11/74 was highly pipelined, lots of loop unrolling for special cases. 11/44 had minimal pipelining. 11/74 goal was maximum performance, running the 11/74 cache memory databus at maximum bandwidth; 11/44 goal was just getting it to fit and work at a reasonable performance level.
Last year I came across 11/44 CISP manuals on eBay so grabbed them and Al kindly scanned them; they are available in HERE. The technical manual has a very detailed description of the implementation of the 11/44 CISP. Sadly no such documents exist for the 11/74 CISP.
Last edited:
pbirkel@gmail.com
Veteran Member
Ahh. I was rereading "Soul of a New Machine" recently, reminding me that sometimes the form-factor constraints can become _the_ driver for a new design (in the case of DG it was the fixed-size single-board constraint on major subsystems). Expanding into an additional SU for the 11/44 main-backplane (which would have actually added 5 slots) would have had all sorts of undesirable ramifications on system packaging & configurations :-<.
4K-word uCode is a heckuvva handful! Implementing special-case pipelining must have made that even more fun ...
Did you have any emulation tools to use before committing yourself to burning a new set of ROMs and handling the boards, and/or perhaps a developmental WCS to drive the CISP?
And I thank you for recovering those CISP documents last year; made my month, for sure :->! The general clues regarding the 11/74 design are quite helpful, especially the observation that in the 11/74 with a 32b-wide memory cache one would want an equally wide CISP data-path in order to maximize throughput. And the loop-unrolling/pipelining.
The 11/780 only ever supported the Commercial Instruction Set in software-emulation, or was it microcoded but without any specialized accompanying HW? (I haven't looked into the 11/780 design as yet. Someday ...)
AK6DN
Veteran Member
Actually it was funny you mention that book. At the time I worked at DEC (75-82) the first year I lived in Boston and commuted out to Maynard. The second year I moved to Marlborough with a college buddy from MIT who just started a job at DG, you guessed it, working on the Eagle project. At some point he mentioned there was some guy following them all around and taking notes; he was supposedly writing some kind of book about computer engineering projects. Did not think much of it at the time. The book of course was Soul of a New Machine. My college buddy in the book was Jim Guyer, one of the hardware designers. To my knowledge he still works at DG/EMC and never has worked anywhere else. Later he got married and moved to a house in Marlborough or Westborough or Northborough IIRC. After living for a couple of years in the Marlborough condo I moved up to an apartment in Lowell to be closer to the Tewksbury site, he moved to an apartment in Marlborough. Once a month or so we would still get together for a beer and talk about VAX/PDP vs NOVA/Eclipse and just hang out.
Found this LINK and this LINK with some info about the book, some pictures, and where they are now (in 2000). My roommate Jim was one of the Hardy Boys. I also remember now a number of times Jim and I would get together with Ken Holberger (team lieutenant) and another guy (don't remember who now) and play doubles tennis, and then barbecue and beer afterwards.
As I mentioned in an earlier post we had a WCS box filled with bipolar ram (boards and boards of 256x4 devices I think) that we used for day to day debug of microcode. We could reload it from an 11/05 that ran RT11; images were downloaded from a PDP-10 (later VAX) over a serial line where we ran the actual microassembler. Without the WCS box we could never have completed the project.
There were so many special cases my head still hurts today from thinking about them. For instructions like MOVC, we had even/odd alignment of the source, even/odd alignment of the destination, and forward/backward copying depending upon overlap of source/dest. Then for small strings (less than four bytes or so) we would do direct inline byte by byte. Longer strings went into an iterative loop.
Last edited:
pbirkel@gmail.com
Veteran Member
Wonderfully interesting pages, especially the first (explain ...)! And that you had such an interesting association with that team.
'pologies about the WCS remark; for some unfortunate reason I had thought that the WCS-and-11/05 was in reference to debugging the 11/74 main Control Store, not the CISP Control Store.
Marty
Veteran Member
Hi All;
Thank You for the Stories !!!
For a novice like me , What is and does CISP stand for ??
I have the book, in a moment I will look at the links.. Thanks for them in advance..
A few Years ago I was able to get ahold of Carl Alsing, and He was nice and kind enough to respond to me..
I was asking some questions about my Data General Eclipse S-130..
Where I worked in the 1980's the company had an 11/60, and it was their main machine, for Tape Backup, for programming Customer Specific Applications, I should say making the file to download to the Prom programmer.. I have most of the tapes, (but Bruce is too Busy to Read them, at present).. Needless to say they Scrapped it Years ago, after I was long gone..
THANK YOU Marty
Thank You for the Stories !!!
For a novice like me , What is and does CISP stand for ??
I have the book, in a moment I will look at the links.. Thanks for them in advance..
A few Years ago I was able to get ahold of Carl Alsing, and He was nice and kind enough to respond to me..
I was asking some questions about my Data General Eclipse S-130..
Where I worked in the 1980's the company had an 11/60, and it was their main machine, for Tape Backup, for programming Customer Specific Applications, I should say making the file to download to the Prom programmer.. I have most of the tapes, (but Bruce is too Busy to Read them, at present).. Needless to say they Scrapped it Years ago, after I was long gone..
THANK YOU Marty
Last edited:
pbirkel@gmail.com
Veteran Member
CIS = Commercial Instruction Set -- a set of additional instructions/op-codes for BCD and string manipulation; COBOL/DIBOL being the primary target
CISP = Commercial Instruction Set Processor -- the additional hardware that implements the CIS
- 11/44 has a two-module set (one HEX, one Quad) -- implementing what I believe operated as a full co-processor
- 11/74 apparently had a 4-module set -- presumably it could run as a co-processor
- 11/23 (F11) has a quad-ROM in one extra-wide 40-pin chip; no extra hardware, so just (lots of) microcode and thus no co-processing
The co-processing bit was that since operations could be run against character-strings or BCD-sequences it could take some time before one might complete; since that activity was using dedicated hardware (excepting memory access), in the meantime the CPU could be continue to be "productive" with the ALU/etc.
I don't think that the J11 had any CIS-support?
Al Kossow
Documentation Wizard
Sadly, they used it in the 2020 as well, and they are big boards.
Marty
Veteran Member
Hi All;
PBirkel, Thank You for the Explanation !!
THANK YOU Marty
PBirkel, Thank You for the Explanation !!
THANK YOU Marty
tingo
Veteran Member
Thanks for sharing history with the rest of us. This is very interesting!
jmiddleton
Member
- Joined
- Sep 10, 2015
- Messages
- 10
It's been more than 30 years since I wrote this code (from around late 1979 to early 1982), so I
hope you'll understand if I can't remember some of the details or make some mistakes.
And no, I don't have any official documentation, such as the source code listing or a schematic of
the console hardware. I've often wished that I had the former (it has copious comments - very
useful with assembler), but at the time I was just happy to be moving on to something else. If
anyone finds the source code listing, or even a code dump, I'd love to have a copy.
Caveat: I seem to remember that there are around 7,000 lines of 8085 code (ROM + RAM), so analyzing
a core dump might a bit of a challenge. A source code listing would be much better.
Here are some general VAX-11/730 console comments:
The console microprocessor is an 8085A-2 with an external clock of 10Mhz, which was divided down
internally to 5Mhz. It was the fastest version of the 8085 at the time, which was a good thing in
general. However this caused a problem when I finally got a hardware "in circuit emulator" since
that emulator only worked to a maximum of 5Mhz external, so the clock speed on the board had to be
cut in half when using the emulator. Fortunately I never ran into any timing problems related to
this reduced speed.
On boot, the console loads its RAM-based code (firmware) from the TU-58. There is 16kb of RAM, but I
think I only used about 14-15kb. In the initial design the layout was 4k ROM and 4k RAM, but that
was changed to 2k ROM and 16k RAM, then 4k (or 6k - see below) ROM and 16k RAM.
After loading itself, the console loads the processor's microcode, again from the TU-58. If I
remember correctly, originally I only had a "brute force" method of loading the microcode. But I got
someone from the microcode team to write a short routine that I could load first (brute force), then
communicate with that to load the rest of the microcode.
The ROM code is divided up into either two or three 2kb segments, depending on whether Remote
Diagnosis Support (the Remote Diagnosis Port (RDP) option) was purchased. Each 2kb segment requires
two chips since, as was noted elsewhere, they are 4 bits wide.
During development all the ROM chips were in sockets for fairly obvious reasons. And believe me,
without an emulator I went through a lot of ROMs before I got the console to load the RAM code.
Sounds like they ended up soldering in at least the bottom 4k (4 chips) for production, which makes
sense. I have no idea what they did in the RDP case. Are there two sockets on the board near the
soldered in ROMs? If so, that's what they are for.
Because I didn't want a change to the code in one 2kb segment of ROM to mess up calls from another
ROM segment, or from RAM, I set up vectors in each segment so there would be no direct subroutine
calls between ROM segments (other than the vector locations), and no direct calls from RAM to ROM
routines. Again, just calls to the vectors.
The console actually does quite a lot. For example, it controls the AC Low, DC Low, and Bus Init
timing during power up and power down. It also contains the interval timer and the Time Of Year
(TOY) clocks. The interval timer and the TOY clock are implemented using an AMD 9513, which has five
16bit counters that can be configured in various ways. I set up two for the Interval Timer, two for
the TOY, and if I remember correctly, one for AC Low timing.
A quirk of the 9513 caused some problems until I finally figured out what was going on by carefully
reading what I call "the warnings section" at the end of the chip spec: you could not read or write
any register in the 9513 while a clock edge was being processed. Fixing this required adding more
logic to the board.
On startup, the console also searches main CPU memory for a VMS Boot Block and, if it finds one,
uses that to start the OS.
And I'm sure there are other things, but I simply can't remember everything.
TU-58 specific comments:
The connection between the console and the TU-58 is a Signetics 2651 USART, a device which works all
the way up to 38.4 kbaud. This was a good thing, but it caused a problem during the Bus Idle state
that occurs over the course of an 8085 interrupt. I believe it was because the 2651 uses a single
R/W (Read vs. Write) pin whereas the Intel UART (8250 or 8251?) that was normally used with the 8085
has separate R and W pins. But the Intel UART only goes up to 19.2 kbaud, not fast enough for our
purposes.
By the way, the problem was this:
If there was a character in the USART read buffer,
And
If an interrupt occurred while the console was executing code in the 64xx(16) block,
Then, during Bus Idle, the upper 8 bits of address would also be impressed on the lower 8
lines, and 64(16) is the address of the USART. Unfortunately the Signetics USART did
not have the two pin system of the INTEL USART, so it didn't realize that BI was in effect
which sets those pins to Not Read and Not Write. Instead, the 2651 saw it as a read and
the character was read out and fell on the floor so to speak. We encountered this while
the VMS TU-58 driver writer was debugging his code.
Back to the TU-58:
I don't believe the data overrun problem with the TU-58 was unique to the VAX-11/730. I seem to
recall that any machine that wanted to use the TU-58 over the Unibus at a high baud rate would run
into the problem since with a single character interface and no DMA there is an interrupt per
character. So at 38.4 kbaud interrupts would occur rapidly, approximately every 260 microseconds.
Although it wasn't unique to the VAX-11/730, I believe we were the driving force for a fix. I,
along with a support person, discussed the data overrun problem with someone from the TU-58 team and
realized we could not add hardware xon/xoff support, and I think it was because it would have
required changes to existing hardware (DL-11? and others, including the VAX-11/730) that no one was
willing to make.
FWIW, by itself the console of the VAX-11/730 has no trouble keeping up with TU-58 running at 38.4
kbaud, so I do not use MRSP when loading the console RAM or the VAX-11/730 microcode. These
operations are performed at the maximum rate. The real problem is that the overall system (console
plus microcode plus VMS) can't process things that quickly.
John
hope you'll understand if I can't remember some of the details or make some mistakes.
And no, I don't have any official documentation, such as the source code listing or a schematic of
the console hardware. I've often wished that I had the former (it has copious comments - very
useful with assembler), but at the time I was just happy to be moving on to something else. If
anyone finds the source code listing, or even a code dump, I'd love to have a copy.
Caveat: I seem to remember that there are around 7,000 lines of 8085 code (ROM + RAM), so analyzing
a core dump might a bit of a challenge. A source code listing would be much better.
Here are some general VAX-11/730 console comments:
The console microprocessor is an 8085A-2 with an external clock of 10Mhz, which was divided down
internally to 5Mhz. It was the fastest version of the 8085 at the time, which was a good thing in
general. However this caused a problem when I finally got a hardware "in circuit emulator" since
that emulator only worked to a maximum of 5Mhz external, so the clock speed on the board had to be
cut in half when using the emulator. Fortunately I never ran into any timing problems related to
this reduced speed.
On boot, the console loads its RAM-based code (firmware) from the TU-58. There is 16kb of RAM, but I
think I only used about 14-15kb. In the initial design the layout was 4k ROM and 4k RAM, but that
was changed to 2k ROM and 16k RAM, then 4k (or 6k - see below) ROM and 16k RAM.
After loading itself, the console loads the processor's microcode, again from the TU-58. If I
remember correctly, originally I only had a "brute force" method of loading the microcode. But I got
someone from the microcode team to write a short routine that I could load first (brute force), then
communicate with that to load the rest of the microcode.
The ROM code is divided up into either two or three 2kb segments, depending on whether Remote
Diagnosis Support (the Remote Diagnosis Port (RDP) option) was purchased. Each 2kb segment requires
two chips since, as was noted elsewhere, they are 4 bits wide.
During development all the ROM chips were in sockets for fairly obvious reasons. And believe me,
without an emulator I went through a lot of ROMs before I got the console to load the RAM code.
Sounds like they ended up soldering in at least the bottom 4k (4 chips) for production, which makes
sense. I have no idea what they did in the RDP case. Are there two sockets on the board near the
soldered in ROMs? If so, that's what they are for.
Because I didn't want a change to the code in one 2kb segment of ROM to mess up calls from another
ROM segment, or from RAM, I set up vectors in each segment so there would be no direct subroutine
calls between ROM segments (other than the vector locations), and no direct calls from RAM to ROM
routines. Again, just calls to the vectors.
The console actually does quite a lot. For example, it controls the AC Low, DC Low, and Bus Init
timing during power up and power down. It also contains the interval timer and the Time Of Year
(TOY) clocks. The interval timer and the TOY clock are implemented using an AMD 9513, which has five
16bit counters that can be configured in various ways. I set up two for the Interval Timer, two for
the TOY, and if I remember correctly, one for AC Low timing.
A quirk of the 9513 caused some problems until I finally figured out what was going on by carefully
reading what I call "the warnings section" at the end of the chip spec: you could not read or write
any register in the 9513 while a clock edge was being processed. Fixing this required adding more
logic to the board.
On startup, the console also searches main CPU memory for a VMS Boot Block and, if it finds one,
uses that to start the OS.
And I'm sure there are other things, but I simply can't remember everything.
TU-58 specific comments:
The connection between the console and the TU-58 is a Signetics 2651 USART, a device which works all
the way up to 38.4 kbaud. This was a good thing, but it caused a problem during the Bus Idle state
that occurs over the course of an 8085 interrupt. I believe it was because the 2651 uses a single
R/W (Read vs. Write) pin whereas the Intel UART (8250 or 8251?) that was normally used with the 8085
has separate R and W pins. But the Intel UART only goes up to 19.2 kbaud, not fast enough for our
purposes.
By the way, the problem was this:
If there was a character in the USART read buffer,
And
If an interrupt occurred while the console was executing code in the 64xx(16) block,
Then, during Bus Idle, the upper 8 bits of address would also be impressed on the lower 8
lines, and 64(16) is the address of the USART. Unfortunately the Signetics USART did
not have the two pin system of the INTEL USART, so it didn't realize that BI was in effect
which sets those pins to Not Read and Not Write. Instead, the 2651 saw it as a read and
the character was read out and fell on the floor so to speak. We encountered this while
the VMS TU-58 driver writer was debugging his code.
Back to the TU-58:
I don't believe the data overrun problem with the TU-58 was unique to the VAX-11/730. I seem to
recall that any machine that wanted to use the TU-58 over the Unibus at a high baud rate would run
into the problem since with a single character interface and no DMA there is an interrupt per
character. So at 38.4 kbaud interrupts would occur rapidly, approximately every 260 microseconds.
Although it wasn't unique to the VAX-11/730, I believe we were the driving force for a fix. I,
along with a support person, discussed the data overrun problem with someone from the TU-58 team and
realized we could not add hardware xon/xoff support, and I think it was because it would have
required changes to existing hardware (DL-11? and others, including the VAX-11/730) that no one was
willing to make.
FWIW, by itself the console of the VAX-11/730 has no trouble keeping up with TU-58 running at 38.4
kbaud, so I do not use MRSP when loading the console RAM or the VAX-11/730 microcode. These
operations are performed at the maximum rate. The real problem is that the overall system (console
plus microcode plus VMS) can't process things that quickly.
John
AK6DN
Veteran Member
Good summary. However the classification as a 'co-processor' is not accurate. The CISP engines (both 11/44 and 11/74) operate much the same as the corresponding FP11 engines do on those machines, more as an extended datapath and microengine. Once a CIS instruction is decoded the main CPU passes control over to the CISP microengine, and it assumes control from then on. The CISP drives a microaddress over to the main CPU to force it to do specific pre-coded microops. Both the 11/44 and 11/74 CISPs did not do any operand decoding or memory accesses directly, but forced the main CPU to do them for it. So in effect from the user code point of view the CIS instruction would run to completion before allowing the main CPU to continue.
CIS instructions could take some time to execute (ie, like a MOVC with a 64KB string length that shifted all 64KB of data space virtual memory up one byte). This could take tens of milliseconds to execute the one instruction.
The impact could be severe on interrupt latency, so the CISP instructions were implemented with the capability of suspend and resume. CISP instructions could checkpoint themselves by pushing up to 64 words of state on the stack, and setting a bit in the PSW (a previously unused bit) to indicate the instruction was suspended.
So for very long instructions the CISP microcode might check every 100 usec or so for an interrupt pending, and if so it would cause itself to suspend and allow the interrupt to be serviced. As part of the suspension it would push any state on the stack it wanted to save, set the PSW suspend bit, and backup the PC to point at the CIS instruction. So when the interrupt service completed and the CIS instruction restarted it would look at the PSW bit to see if it was a restart vs a new execution, and if a restart pop the saved info off the stack and resume the instruction where it left off.
Needless to say this added an additional level of complexity (and regression testing!) to the microcode implementation and debug/validation. The DEC diagnostic written for CIS (ZKEEA0) has explicit support for the KW11P programmable (or line) clock to fire off interrupts as fast as possible to cause CIS instructions to be restarted ad naseum.
When implementing the CIS microcode we made decisions on each instruction as to how the interrupt check/restart would be handled:
(1) for very short instructions (ie, load descriptors) we did not check for interrupts midstream, and never did a restart. The only interrupt check was at the end of the instruction, same as for any regular PDP-11 instruction.
(2) do an instruction restart instead of resume. Set the resume bit in the PSW, but don't push any intermediate state on the stack. If an interrupt comes in just throw away any current instruction progress and restart the instruction from scratch on the next decode. This was used very rarely as with a high enough interrupt rate no forward progress would be made in the CIS instruction execution, causing the system to essentially stall until the interrupt rate was reduced. Off hand I don't recall which (if any) CIS instructions used this choice, it was certainly the least optimal choice of last resort.
(3) do a full instruction checkpoint and resume. Set the resume bit, push up to 64w of state on the stack. Design the microcode to always make some forward progress before the next interrupt check. So even with a very high interrupt rate the instruction will complete in a finite, predictable amount of time. Most instructions just needed to use the general registers (which held the operand descriptors) and the resume bit to restart, or maybe a word or two of state on the stack. However, a few exceptions (like MULP and DIVP) required saving a full 64w of intermediate state to resume.
Now back to your regular programming ... and thanks to John for the details on the 11/730 console subsystem.
Don
Last edited:
jmiddleton
Member
- Joined
- Sep 10, 2015
- Messages
- 10
By the way, the reason I said we were the driving force for MRSP was that we couldn't afford to lower the TU-58 speed to something the system could tolerate since that would have been a fixed baud rate. The startup time is rather long as is, but would have become much longer with a decrease in the rate of TU-58 transfers.
John
John
Marty
Veteran Member
Hi All;
Don and John, You two and a few of Your Dec friends, need to Write a 5000 Page Book of You Dec Adventures, And things not in The Dec official Manuals as well as 'How' Things were done, found out and Implemented, before Production..
Before You all loose what You remember or are no longer here with us..
And we loose a Very Precious Resource.. YOU !!
For the most part The Engineers that are trained today Could not find their way in a PDP 11 anything, because of lack and change in what they are trained with, they Don't have a chance to Engineer a Dec or Data General from scratch using IC's and build it and make it run..
That is a lost skill.. That You have.. And I wish I had and knew more about..
Not that I have any leg to stand on..
I have a Wire-List and Schematic for the PDP 8i Clone and even with all of that and a book to help guide me, I still can't get it to work.. And so that is one of the reasons, we all need Your lost skill's written down, to us us less fortunate on How to do what You know how to do on these old machines..
I wish You could come here for about a month, and help me and train me in getting my pdp 8i clone and my PDP 11/45 in working condition.. I know though that, that is an outlandish dream of an Old man who can't do it myself..
And Yes, I have more Digital Design books than You could put on a 10 foot book shelf.. But, its someone with experience, to guide me first hand that I don't have, to show me how to go from books to actual machine..
THANK YOU Marty
Don and John, You two and a few of Your Dec friends, need to Write a 5000 Page Book of You Dec Adventures, And things not in The Dec official Manuals as well as 'How' Things were done, found out and Implemented, before Production..
Before You all loose what You remember or are no longer here with us..
And we loose a Very Precious Resource.. YOU !!
For the most part The Engineers that are trained today Could not find their way in a PDP 11 anything, because of lack and change in what they are trained with, they Don't have a chance to Engineer a Dec or Data General from scratch using IC's and build it and make it run..
That is a lost skill.. That You have.. And I wish I had and knew more about..
Not that I have any leg to stand on..
I have a Wire-List and Schematic for the PDP 8i Clone and even with all of that and a book to help guide me, I still can't get it to work.. And so that is one of the reasons, we all need Your lost skill's written down, to us us less fortunate on How to do what You know how to do on these old machines..
I wish You could come here for about a month, and help me and train me in getting my pdp 8i clone and my PDP 11/45 in working condition.. I know though that, that is an outlandish dream of an Old man who can't do it myself..
And Yes, I have more Digital Design books than You could put on a 10 foot book shelf.. But, its someone with experience, to guide me first hand that I don't have, to show me how to go from books to actual machine..
THANK YOU Marty
Last edited:
NF6X
Veteran Member
I wonder if any of the retrocomputing podcasters might like to interview folks like Don and John?