7906 disc drive
I did some additional cleaning of the top disk head, using my 99% isopropyl alcohol and Kimwipes, inspecting periodically under the stereo microscope. The hope was that I could get it clean enough without having to wait to use the ultrasonic cleaner at Marc's home.
The result with an hour of work was an almost flawless head, to the limits of my microscope's resolution. I don't need to wait for the ultrasound bath. I think that one more shorter session just before I reinstall will be adequate.
In addition, I used a bright light to inspect the remaining heads as fully as I could to be sure that once I reinstalled the top head and used an alignment cartridge, everything would work properly. This was quite challenging due to the small clearances but I persisted.
As far as I can see, the heads are all good, but have a small amount of oxide at the leading edge consistent with normal use. My confidence level is about 80%, but I would really like to get a better view of the heads if I can (and the bottom fixed platter surface). Perhaps a fiber optic camera or similar means of inspection?
Legitimacy of placement of the Firmware Enhancement Board in slot 11 of my system
My system originally came with the Firmware Enhancement Board (FEM) in slot 10, the bottom slot of the IO cage, with a Timebase Generator IO card in slot 11 and other IO cards higher up in the cage. The FEM is not an IO board, however, but a board that holds ROMs that extend the functionality of the system. For example, it provide fast fortran, scientific instruction set and vector instruction set capabilities via ROMs placed on the board.
The way that the HP 1000 works with microcode is to place the address of the next microinstruction on the CRAM bus, which is a set of lines that run to all boards which host ROM. The appropriate board hosting the instruction at that CRAM address will respond by putting the microinstruction on the shared ROM bus, where it is latched in at the start of the next microinstruction cycle.
Various features, such as the vector instruction set, are placed at a range of the possible CRAM addresses which are reserved for the feature. Other features have different ranges reserved for them, as does the basic microcode implementing the regular instructions, control panel operations etc.
Boards like the FEM have a number of sockets available to hold ROMs, plus DIP switches to configure the socket to respond to a given range of CRAM addresses. Thus, you can use the FEM to hold different ROMs, or those ROMS could be installed in other ROM board types. The other types are CPU, FAB, WCS or user designed.
The CPU has sockets for the basic functionality of the machine, but adding all the features found on the system requires more sockets than are located on the CPU board. Thus, additional types were created. They are connected by a ribbon cable on their fronts, allowing them to see the CRAM address and containing the ROM bus as a shared tristate bus.
The first was the Firmware Adapter Board (FAB), which sits just below the CPU board underneath the IO card cage. When the FAB sees a CRAM address it hosts (set up by DIP switches to match particular ROM chips installed in sockets), it drives the output of the ROM onto the tristate bus, otherwise it sits in high impedance (hiZ) mode.
If the CPU also matches a particular CRAM address it can override the FAB board by asserting a signal BCSEN- that tells the FAB board to stay in hiZ mode even if it matches the CRAM. Then, the CPU would drive the ROM bus. When the CPU has CRAM addresses it does not drive, it stays in hiZ.
The FEM board is a larger board, sitting in a IO cage slot instead of under the CPU where the FAB fit. It can host more ROM chips. When it sees a CRAM address it hosts (based on DIP switches), it drives the output on the ROM bus otherwise it sits in hiZ.
The ribbon cable that connects to the CPU has a second socket beneath to fit to the FAB, if installed. It also runs up into the IO cage and has three more connectors that would fit ROM cards in slots 10, 11 and 12.
Writeable Control Store is a ROM board that is actually RAM, so that a user can write or update the contents of the microcode at given addresses. It can be accessed as an IO device for read/write, as well as with the ribbon cable when the system is fetching microcode. Thus this board actually uses the IO cage backplane because it is an IO device as well as a ROM board.
The priority order for ROM boards is, from highest to lowest, WCS, FEM, CPU and FAB. This is implemented with signals that run on the ribbon cable to all boards. Much like the BCSEN- signal told the FAB board to stay in hiZ even if it matched an address, there are three more signals.
ECSEN- is driven by FEM boards, to tell the CPU and FAB to stay in hiZ. This is how the FEM has higher priority than the FAB or CPU. If there are more than one FEM boards, the one that hosts the ROM chips for a given CRAM address will drive the ROM bus with the microinstruction and will assert ECSEN- to block CPU and FAB. The other FEM board(s) stay hiZ because they don't match the CRAM address.
WCSEN- is driven by WCS boards, to tell the FEM, CPU and FAB to stay in hiZ. The WCS board asserts that signal only when it will be providing the microinstruction for that CRAM address, otherwise it stays hiZ and leaves the signal off.
Finally, there is a signal RMX- that is provided for users who design their own custom ROM board - their board can assert RMX- to force WCS, FEM, CPU and FAB to stay hiZ and let the user board provide the microinstruction.
The FEM board sits in the IO cage but it has almost no connection to the IO backplane. It gets power and ground, bypasses IO priority the same way that a blank jumper card does, but nothing else. The only interaction when fetching microinstructions is over the front ribbon cable that links CPU to FAB, FEM, WCS and/or user boards.
The front ribbon cable would get in the way of ordinary IO cards, which tend to have cables connecting to the front of them and running off to various peripherals. The ribbon cable would block the connector. Thus, it is reasonable and usual to have the ROM boards installed together at the lower IO card slots - 10 and above - before any IO cards.
Since the ribbon cable has only three connectors and they are aligned with slots 10, 11 and 12, there is a physical constraint on where the cards should fit. However, there is no reason that particular ROM board types should sit in particular slots.
The manuals describing how to install the FEM and WCS boards provide ambiguous and sometimes contradictory prescriptions for where to place them. In one place it directs the CE to put the FEM in slot 10 except if there is a WCS and an FEM, the WCS goes in 10 and the FEM goes in 11.
A different diagram shows slot 10 with "FEM or WCS", slot 11 with "FEM or WCS" and slot 12 with WCS. The operating system needs to know where IO cards are sitting, since it has to address them by their slot number. The WCS is an IO card just like serial ports, so the software must know where it is, but the FEM is invisible to software.
On a side note, there is an IO priority order analogous to the ROM board priority, but for IO cards it is strictly the slot number, with the lower card having more priority than a card above it. This is implemented by a pair of signals on the IO backplane, PRL and PRH. Any request for interrupts runs down from the card above, on PRL, and is connected through to PRH unless this card wants to assert its priority for an interrupt request.
Thus, the lower the card, the more it is guaranteed that the processor will act on its interrupt request since it can block or jump ahead of all higher cards. If a slot is left open, no interrupt request from higher card slots can ever make it through to the processor. For this reason, jumper cards are a type of blank IO card that simply jumper PRL and PRH together to keep the interrupt chain unbroken.
In a machine with an FEM in slot 10 and IO cards above, the highest priority IO card is 11 and each slot above is one step lower in priority. That is how my system came, with FEM in slot 10, and IO cards starting in 11, with some blank jumper cards between various active IO cards.
I had discovered that the connector on the ROM ribbon cable that sat at slot 10 and hooked to my FEM board was flaky, causing the board to fail to see CRAM requests for microcode it hosted. The next connector up, for slot 11, worked fine, so I simply swapped my FEM for the IO board. Now the first IO card is in slot 10 and my FEM is in slot 11.
This does not affect the IO interrupt chain because the FEM card (and WCS) also jumper PRL to PRH. The first IO card is a Timebase Generator (TBG), which has no cable connecting to its front. That means the ribbon cable from FEM down to CPU won't interfere with the TBG or vice versa.
Everything works great, but it doesn't match tradition or the somewhat ambiguous directives in the firmware install manuals, or the experiences of most HP veterans. Therefore I have received warnings that people remember some problem with timing or priority or something with my FEM in slot 11 instead of 10.
I had to study schematics, ready theory of operations documents and reason through everything before I was comfortable that, while unusual, my configuration is legitimate. I am not sure I have convinced others who remember that somehow this is wrong.
Of course, if I had a good ribbon cable whose connector at slot 10 wasn't flaky - or if I can acquire a good replacement - I would go back to the traditional placement. There is no reason other than convenience in handling a bad connector for my alternative configuration.
HPdrive disc emulation capability
I am building up the ability to use a PC as an emulated disc drive, connected to the HP 1000 over an HP-IB bus to a controller card. To do this, I need:
- a windows based PC with PCI slots
- a National Instruments PCI based HP-IB card
- the HPDrive software and HP-IB card driver
- a 12821A HP-IB disk controller card for the minicomputer
- the cable between the 12821A and the NI board
- a suitable ROM boot loader in the minicomputer
Unfortunately, my NI board was shipped by USPS. It had a signature requirement, thus I had a tag on my door on Friday notifying me of the miss-delivery. I used the online system to request pickup on 11/6 at the post office, but they were unable to find it. They thought it might be on the truck for delivery, but of course it was not. Another visit tomorrow and possibly a lost package. I don't look forward to the claim process if that occurred.
No comments:
Post a Comment