Ethan Dicks <ethan.dicks at gmail.com> wrote: You drift from the question, Ethan... :-) To answer the original question, it was done in one of two ways. Either you set a bunch of DIP-switches to the value that should be sent as the interrupt vector, or else you programmed the card with the interrupt vector it should send. Older cards usually use DIP-switches, while modern cards usually are programmed. Remember that you don't need the interrupt vector to talk with the card in polled mode, so you can talk with the card, and set up stuff before you allow it to start generating interrupts... What you drift into, Ethan, is then the question of deciding what interrupt vector to actually set on the card. This is also an interesting topic. Very few devices have more than one reserved vector. That is, if we talk of one vector as assigned to one card. Some cards had more than one vector because of the nature of the card, such as a terminal interface which actually use two vectors. One vector for receiving characters, and one vector for transmitting characters. I can only remember one device where more than one set of vectors were reserved, and I think it ran to eight for that one. I'd have to look in a processor book to check the actual name of that device, though. For all other devices, vectors are allocated from the "floating" vector space, which is everything from 300(8) to 774(8). Each vector takes two words, the the lowest two bits of a vector is always 0, and are usually not even available on the switch pack, or register where you program the vector. For a device like a terminal interface, the next bit was also reserved, since it was used to differentiate between transmit and receive, so two vectors were programmed with one switch pack. There was/is a definitive schema for in which order vectors should be assigned, but it is more or less not used since all the OSes that atleast I have tried actually probe what vector each card uses, and use that vector instead of having some fixed scheme. All that is required is that no two devices use the same vector, because that would be bad. Well, there are really only two ways. Either dip switches, or programmed. :-) No, it's just the same for any PDP-11, just as for VAXen with Unibuses. You *must* use dip-switches for CSRs, or possibly accept that it is at a fixed address, which is a very bad idea. Vectors are either set with DIP switches, or programmed into the card at initialization time. But vectors are the simple part of the Unibus. The fact that it's easy to autodetect the vector makes it even simpler. All you need to make sure is that you don't have a conflict, and your vector issues are done. The interesting part of the Unibus is actually the CSRs. As the I/O address page is only 8K, and some devices use quite a few registers in that area, this is a short resource, so you cannot in general make a permanent allocation in the I/O page for all possible combination of devices you might have. So DEC designed a scheme for automatically detecting and configuring devices on the Unibus. (Plug and play long before the PC saw the light of day.) This do, however, require you to change the CSR address of devices way more often than you might think. The general idea runs like this. For most of the common devices, *one* CSR address is reserved. So, for the first device, you know which address to set it to. Any additional devices of that type goes into the floating address space. Each device additionally have a priority, size and modulo number. This is all on paper. For autoconfiguration to work, you then start with the highest priority device, and starts assigning CSRs to the devices you actually have of that type. When you are done, you go on to the next device, and repeat the exercise. Repeat until you've run through the whole list of device types, and by then you will have the CSR address of all the devices you have in your machine. Now, if you add one additional device of some type, it will probably affect the CSR address of all devices you have which have a lower priority, moving them in the floating address space. The same is true if you remove some device from the machine, which were located in the floating address space. More specifically the algorithm goes like this. (In pseudo-code, all numbers octal) CSR=160010 DEV_PRIO=1 while (! end_of_devices_you_have) CSR = round_up(CSR, device_modulo(DEV_PRIO)) for (number_of_devices(DEV_PRIO)) do this_device_csr = CSR CSR = round_up(CSR+device_size(DEV_PRIO), device_modulo(DEV_PRIO)) next CSR += 2 next Worth pointing out: Floating address space starts at 160010, and goes up. Preallocated CSR addresses are usually very high up in this space, and were allocated downwards. They "end" up somewhere around 174xxx space or so. I'm sure someone could locate the lowest pre-allocated CSR address that DEC assigned by looking in some processor book. Between each device type, one CSR address is reserved. This means that when you scan for devices, you'll run through one type at a time, and stop when you hit an address where there is nothing responding. You then go on to the next type. It's important to understand that the space after this non-existant address do not need to be the same size as that of the actual devices for that prio. That would be wasteful of address space. Once you hit the non-existant address, you start scanning for the next device type, using the modulo of that device type instead. So if you have one device type which uses 20 registers, and you don't have any of that type, you'll only waste one register, plus the modulo of the next device type. Once all the CSRs have been figured out, the DEC official scheme for vector allocation was basically to just allocate all vectors, starting at 300, for all the devices you have, packed together as closely as possible. No need for unused spaces, or anything else here. But this is all about the scheme for actually deciding what to use. The actual method of getting the card to know this info was switchpacks, or for vectors, programming a register. Johnny