Was FORTRAN buggy 4342

The ECO-FCO (Engineering Change Order-Field Change Order) process was easy. The new parts or modifications were made and tested. Diagnostics were upgraded to test for them. The parts were updated in manufacturing to the new spec and the reworked boards from repair were upgraded to that version or scrapped.

The modifications (wire wrap-chip change-ROM replacemenr-new microcode loads) or new boards were shipped to Field Service to implement in the field. The 11-780 ECO-FCOs usually involved some wire wrapping to the CPU backplane, new roms on the microcode and some new floppy disk loads of the writable control store microcode. They were often jump routines from bad micro rom stuff into the wcs patch area IIRC.

'Course when there were too many they issued new cpu boards and freed up the wcs space. The 11-785 went with mostly WCS space and minimal roms for easier maintenance on the wcs.

The worst ECO-FCO series was for the TS11 (Tape Stretcher-11) tape drive... Took three or four shots at this to make it usable including gluing some 7400 series chips to the board dead-bug style and soldering wires from 'em to change the motor controlls on that piece of crap drive. A bad design at the start. DEC's second worst tape disaster (besides the TU45 -- stop gap mess while waiting for Pertec to get the TU77 transport built).

Here's a good one about a PDP11-70 change from the PDP11 FAQ. These kinds of things are easy to do on the old TTL and discrete transister based cpu's but are a unpleasant woman inside a Pentium.

If Intel could've done these things they would've saved a lot of retooling on the Pentium FPU fiasco 8-)

3. Tom Farrin is famous for a hack he did to DEC's PDP-11-70. This was a trace cut and jump inside the CPU which: a) increased the system clock speed by 12.5% b) enabled IEEE-compatible floating-point arithmetic c) froze the contents of the cache d) disabled the Unibus reset that occurs automatically on a bus error e) made separate instruction and data space available in user mode ....

to which Robert Herndon provided additional insight: "and the answer is listed as `E'". I was present at a lecture he gave at the 1978 Unix Users Group Conference in NYC (this was just before they asked BTL for official permission to call themselves this, and were turned down, after which the conferences became "Usenix" conferences). In it, he described how he needed the MFPI instruction (move from previous instruction space; it gets a word of data from the "previous mode"'s instruction space) in order to efficiently determine the number of arguments pushed on the stack. This was because his Lisp interpreter was too big to run without running in separate I & D spaces (type 411 binary, as opposed to 407 (unshareable), or 410 (shareable, but common address space). Running programs in separate I & D spaces was an everyday event on PDP-11s at the time, but separate I&D binaries could not use the nargs() procedure (which looked at the caller's instructions).

Since his program was running in separate I & D spaces, any loads to look at the caller's instructions would simply load a word from the data space at the same address. DEC, in their wisdom, had made the MFPI and MFPD instructions privileged, so he couldn't use them to look at his instruction space. So he made a system call available to do this function, but found that it was very slow. And as he put it, that wasn't very satisfactory, and "Well, there's this NAND gate, and if you cut this wire...", and the room dissolved in laughter. And then he told us that this cut was available as a DEC field mod and gave us its number...

-- -- "When I think back on all the crap I learned in Vax school It's a wonder I fixed anything at all." (to the tune of Kodachrome) pechter-at-ureachtechnologies.com