m_thompson
Veteran Member
I believe that the empty section at the far right of the chassis is for the CI-780 Cluster Interface. I bought one for the RICM decades ago and it is still in the box.
- VCF SoCal - February 15 - 16 2025, Hotel Fera, Aneheim CA
- VCF East - April 4 - 6 2025, Infoage Museum, Wall NJ
- VCF Southeast - July 2025, Atlanta, GA
- VCF West - Aug 2025, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 2025, Schaumburg, IL
-
Please review our updated Terms and Rules here
Who is still running a VAX/780?
- Thread starter Robotrontechnik
- Start date
I believe that the empty section at the far right of the chassis is for the CI-780 Cluster Interface. I bought one for the RICM decades ago and it is still in the box.
pbirkel@gmail.com
Veteran Member
Thank you. The follow-on 11/750 has a mix of permanent uCode and a Patchable Control Store (PCS). An L008 Patchable Control Store (PCS) could be substituted for the L0005 CPU Control Store (see: http://gunkies.org/wiki/VAX-11/750). I've seen both modules on eBay but have no idea of the relative frequency of installation of these two alternatives.
I infer that DEC either was doing a lot of field-patching with the new 11/780 and wanted the flexibility of replacing a lot, although apparently not the entire (given the 4k ROM on the CIB), microcode load conveniently (no need to create-and-ship new fusable-link ROMs), or (2) adopted the PCS-based approach in the 11/750 as a cost-control measure, or (3) both.
I'm curious as to the evolution in the DEC strategy for uCode load at boot-time in the VAX-11 family. Anyone know more?
Bitly
Experienced Member
The 4K ROM on the CIB contains the console firmware, not the uCode
I don't know when (if ever) DEC did a full microcode load at boot time. At the time SRAM chips were small and expensive, so bipolar ROMs were a better choice.
The 780 has a bunch (~100) of PROMs for the microcode, and a logic array (FPLA) that allowed patches to be vectored into a portion of the WCS. Patches were delivered as a new console floppy + the FPLA. The console processor would check the FPLA version and the microcode on the floppy and refuse to start if they weren't compatible. Customers could also write custom microcode for the 780 to support specialized workloads.
The 750 also has a bunch (~125?) of PROMs for uCode, and the OS would load a file (BSD used pcs750.bin) on boot for patches, but I don't know how the instruction replacement mechanism actually worked. If memory serves, the G and H floating point was sold as a separate option that employed the L0008 (WCS). There might have been two versions of the WCS, one with double the memory to support the FPA uCode.
I don't think the ASIC VAXen had any way to patch the microcode, requiring a CPU replacement to fix microcode problems, but by that point DEC had a pretty good system in place to insure the chips worked properly prior to release.
CW
Al Kossow
Documentation Wizard
years ago, I bought and dumped the microcode roms for the 785. they are in http://bitsavers.org/bits/DEC/vax/vax785_jcs_cib_proms.tar
NF6X
Veteran Member
Doesn't the 11/730 do a full microcode load from console tape to its WCS?
hhedeshian
Member
Does this mean it is possible to start the 11/780 without the console floppy?
Bitly
Experienced Member
Yep, you're right. The 730 uses 16Kx1 DRAM chips for the main uCode and 1Kx4 DRAM chips for the user uCode.
CW
Bitly
Experienced Member
I don't believe so. The console firmware loads the WCSxxx.PAT file from the floppy, and if the version doesn't match(?) the FPLA version it won't start. Basically, the FPLA says 'if this uPC occurs, swap it for another in WCS' so without the patches loaded, instructions would fail.
You could probably use the console to probe the 780, but that would be about it.
Looking at a floppy image, there is a 'CONSOL.SYS' file, so the 4K ROM on the CIB may just be boot code.
CW
Note: I think the WCS version must be greater than or equal to the FPLA version, but I'm not positive.
hhedeshian
Member
Ok, it looks like there is very limited information online. I'm hoping someone has these files otherwise it seems this machine is a paperweight. Looking at J12 and J13 on the CPU backplane, I come up with:
Which maps out to:
Type: 01 (decodes to 11780)
Revision: 8
Letter: None (decodes to 0)
Plant code: NI
Serial: 964
It's clear looking at the jumpers that this system has had a few ECOs applied in the field. I confirmed I have M8238 (which is the newer WCS module introduced in 7.0) instead of M8233. According to the copy of K-RM-1178X online, I can use either WCS125 or WCS126.
So far I've only found copies of WCS120 and WCS123 online. Do you know anyone that would have access to these files?
Which maps out to:
Type: 01 (decodes to 11780)
Revision: 8
Letter: None (decodes to 0)
Plant code: NI
Serial: 964
It's clear looking at the jumpers that this system has had a few ECOs applied in the field. I confirmed I have M8238 (which is the newer WCS module introduced in 7.0) instead of M8233. According to the copy of K-RM-1178X online, I can use either WCS125 or WCS126.
So far I've only found copies of WCS120 and WCS123 online. Do you know anyone that would have access to these files?
Attachments
Last edited:
hhedeshian
Member
Actually... There is a file called "OldVMS V1.4.iso" on bitsavers which contains an image of "as-t213j-me" RX01 disk. According to the EVNDX-25 pdf, that is supposed to contain WCS125 which is compatible with my system. Thus-far, I haven't been able to mount that image and dump its contents.
AK6DN
Veteran Member
The size of the RX01 image in bytes might provide some clues as to its possible format:
1) 76x26x128 = 252,928 bytes would most likely be a logical block dump of the disk
2) 77x26x128 = 256,256 bytes would most likely be a physical sector dump of the disk
other sizes would provide less insight into the possible image format
hhedeshian
Member
I think you are on the right path. The directory contains images of both sizes. I'm able to read the 256256 size files in simh but not the 252928 size files.
Bitly
Experienced Member
Various flavors I've extracted over the years from floppies images I found online. Note, the two WCS124.PAT files have different MD5sums. I suspect the .other version is a different flavor.
CW
| Floppy label | WCS file |
| as-t214a-de | WCS124.PAT |
| unlabeled_1 | WCS124.PAT.other |
| as-t213j-me | WCS125.PAT |
| as-t213h-me | WCS126.PAT |
CW
AK6DN
Veteran Member
That makes perfect sense. SIMH RX01/02 supports raw track/sector image format, which are files of sizes 256,256 for RX01 and 512,512 for RX02.
The smaller file of size 252,928 is almost assuredly a logical block 0..N-1 512byte block image of 494 blocks for RX01.
hhedeshian
Member
This is fantastic! Thank you - I think I have all the files I need to get this thing going. For the moment, I'm stuck fighting a stubborn power supply in the BA11 chassis.
I pulled the smaller files into a hex editor and for sure they look like they have good data. It should be possible to write a quick program to add the first unused track back in and do the correct sector interleave. I'll probably take a stab at it this week. I believe the hardware hardware emulator you designed works with the raw track format, correct? I assembled one a while back (~2 years ago?) to bootstrap my 11/44. It worked great! (And having JLC PCB assemble it made it super easy). To start off with, I'll likely use the emulator to rapidly iterate through the console floppies until I get it working, then dump it to a physical disk.
Terri Kennedy
Experienced Member
No, at least not without emulating it. CONSOL.SYS is the main code for the front-end LSI. WCSxxx.PAT is the microcode patch file (I believe WCS126.PAT was the last one), VMB.EXE is the actual code the LSI loads into the VAX to boot a device. There are a whole load of xxxBOO.CMD files to boot different devices from different slots holding different adapters.
You also need the floppy drive for diagnostics. Some are controlled by the LSI (basic CPU tests) while others are run from the VAX itself, but loaded from the floppy.
If your debugging / diagnosing a sick VAX, a second floppy is very handy so you don't have to switch between discs all the time. On a single-drive console, CS1 is an alias for CS0, on a dual drive console they refer to separate drives.
You should get a hold of https://gunkies.org/wiki/VAX-11/780_&_VAX-11/782_Revision_Control and see what revision your CPU modules are. Mix-n-match generally does not result in a workable system.
I'm off to the middle of the Mojave Desert with only satellite text messaging until 10/31. I hate to tantalize and run, but I'll try to answer all questions once I return.
AK6DN
Veteran Member
There was a discussion on simh groups.io a month or so ago about someone who had logical block RX files and wanted to use them on simh, which wants RX physical image disk files.
Someone did write a converter program and did a pull request to the open-simh github simtools, but I don't think it has been fully integrated yet.
In any event, you can get the code from here: https://github.com/open-simh/simtools/pull/18
It is called lbn2pbn.c, and can convert to/from logical block RX files to physical sector RX files.
And yes, the RX02_EMULATOR uses the same format RX physical sector image files as does SIMH.
Bitly
Experienced Member
After some comparison to the uFiche, it appears WCS124.PAT.other is the correct version, and WCS124.PAT is something else.
CW
hhedeshian
Member
I was aware of this but wasn't aware of how critical it is to be matched down to the component level. Buyer beware I guess (if you're shopping for this stuff on eBay). I got lucky that I got a mostly complete system without having to piece things together.
I did a full inventory of all cards and options, and for the most part things look ok. There are a few discrepancies, however.
From J12 + J13, the system is coded for version 8.0; based on that I should have:
| Option | Expected Version | Actual Version |
| KA780 | 7.0 | 7.0 |
| FP780 | 2.0 | 2.0 |
| DW780 | 01,1A,1B,C1,D1 | 1B |
| MS780-E/H | 00 | B |
| RH780 #1 | 04,AA1,AB1,B1,C1 | 4.0 |
| RH780 #2 | 04,AA1,AB1,B1,C1 | B1 |
The only module level discrepency is the memory which is a rev B instead of a 00. This may be as simple as changing the jumpers on J12/J13 to re-ID the system (there don't appear to be any other difference between the 8.0 and 8.B) system version. All of the option modules (FP780, DW780, MS780, both RH780s) have cards which are consistent with the module versions.
Within the KA780 I have 3 card discrepancies. Some of the cards have a yellow tag on them, I assume that means these were likely field modified ECO'd
- M8236 should be C or D
- mine has no revision marking
- this card has a yellow tag / band on it
- M8238 should be rev A
- mine is rev B
- I suspect this is a non-issue and likely that rev was released after this document
- M8221 should be rev A or B
- mine has no revision marking
- this card has a yellow tag / band on it
