# ATARI and the PCI bus

## 1. PCI bus

The Peripheral Components Interconnect (PCI) bus originally for IBM-compatible PCS developed, there urgently the necessity for a fast, processor-independent bus system existed. Since that time this bus was established also for other computer worlds (e.g. the current Macintosh models on base of the Power PC, various workstations with DEC's alpha processor or in addition, the current UltraSparc of SUN).

Also the developers of the Hades and the Milan thought of this really universal interface. This development led there that one can actually use now the same extension cards on different computer platforms - if drivers for the system concerned are available in each case. Therefore it is long at the time to be occupied once more near with the PCI bus. First we provide an overview of the possibilities of the PCI bus, afterwards we will then become acquainted with the individual registers for the initialization and configuration of PCI cards. The termination forms then the conception from the PC well-known PCI BIOS for ATARI compatible computers by the example of Hades and Milan.

### 1,1 general

The PCI bus is specified for 32 bits long data with max. 33 mc/s and is optionally expandable on 64 bits and/or 66 mc/s. The clock may take however in principle any value between 0 and 33 mc/s. With 33 mc/s and 32 bits data capacity theoretical data transmission rates of up to 132 MB/s are possible, and in practice actual values close this theoretical maximum are attainable.

According to the electrical specification can be accommodated at a PCI bus up to four Slots apart from the host system. Over a PCI Bridge then still another further bus can be attached. If this is again a PCI bus, one can repeat the play also several times.

Each PCI device can contain several independent functions (multi function DEVICES), which can be responded also independently via the bus. Most at present available devices are however so-called ' single function DEVICES '.

With the multi-function cards one must differentiate two of reason on different versions:

- A only one bus - the configuration areas of such PCI cards lie apart in each case 256 bytes (i.e. the address lines reflect simply register (bit 0-7) and function code (bit 8-15) of the card.
- 2. PCI2PCI-Bridge with single function DEVICES or multi function DEVICES of the type 1 at the second bus - sowas SCSI occurs e.g. with combination cards such as Ethernet +. Since the bus number would be selected here over the address lines A16-23, such cards cannot be used with the Hades probably or only reduced (because the configuration areas are limited to few KB).

## 2. Hardware

For the fundamental functions of the PCI bus altogether 47 pins for Slave adapters as well as 49 pins are needed for master adapters. In addition the links of supply voltage come. Without an enumerating of all signals I would like to do here however, since this would blow up the documentation unnecessarily, and also not at all for the application of the PCI BIOS would be relevant. Therefore are alsoonly the most important, in the figures used signals, to be more near described:

AD[0..31 ] - ADDRESS/CData

Addresses and data are gemultiplext transmitted. The individual bytes of the 32-Bit of word are released over the lines / C/BE[0..3 ].

/ C/BE[0..3 ] - COMMAND/BYTE Enable

The bus command (different reading and schreibarten) contains and in the data phase the signal byte Enable for the data lines in the address phase.

IDSEL - Initialization DEVICE SELECT

Chip SELECT for initialization and configuration of the PCI card. For each PCI Slot its own line is available.

/ REQ - Request, is used only for bus mast ring

Bus request, for each Slot is available a line.

/ GNT - Grant, is used only for bus mast ring

Bus dispatching, for each Slot is available a line.

/ INTA - INTERRUPT Request A

Request of an INTERRUPT with single function DEVICES.

/ INTB, C, D - INTERRUPT Request B, C, D

These INTERRUPT lines may be used only by devices with several functional units (multi function DEVICES).

The remaining signals more or less serve the control during the different address and data phases and their synchronisation. One finds details in the PCI local bus Specification and the PCI system Design Guides, a good overview can one in addition, by means of the Elrad booklets 3/97 and 4/97 provide. Since we would not like to develop new PCI cards here, but from the PC area already available cards also the Hades, Milan and other compatible ATARI computers to make tasty would like, did we here without further hardware details, which are not relevant for driver adjustments. The correct processing of the signals should be taken over anyway by the PCI Bridges available in the computers.

### 2,1 DMA

Basically any PCI device can appear as bus masters. As bus masters this PCI device can transmit then independently data from its own storage area into the system memory of the host computer. This type of the background processing relieves the processor of the host computer very strongly. However therefore all PCI devices, which have to transport large quantities of data, should or fast transfers require, when bus masters can occur. E.g. SCSI CONTROLLERS or also modern network cards use the DMA (direct memory access) ability of the PCI bus, in order to transport data fast into that or from the primary storage.

The advantages on use of a bus-masterable PCI device quite particularly show up with ' genuine ' multitasking operating systems, since the saved computing time can be put to other processes there at the disposal. Under single Tasking it is subject to the fate of the programmer to pull from the bus master ability of a PCI device of advantages. An access, which waits only for the end of a transfer, is simpler to implement, given away by no-load operation of the processor however again the won time.

The bus-masterable PCI device requests the bus by setting its / REQ line. A master may use / REQ however only for its current access, not however, in order to protect itself the bus in the long term. The bus Arbiter of the host computer assigns the bus to this device by setting the appropriate / GNT signal. After the bus was assigned to the PCI device, this can execute its DMA access. If the PCI device does not release the bus within a certain time again, the host computer can get GNT line the bus by taking away / also again freely. The bus master must terminate then presently/immediately the access.

### 2,2 INTERRUPTS

On the PCI bus altogether four " pegel" triggered INTERRUPT lines are available (INTA... intd). All devices with only one function may use only INTA, the other three lines are intended for the operation so-called ' multi function DEVICES '.

In the PCI specification is not defined and thus the respective board manufacturer one leaves the further processing of the INTERRUPTS. The INTERRUPT lines of the individual Slots can be connected therefore either as " ground through " bus (open drain) in each only erdenklichen combination, or however they are advanced individually by each Slot at the appropriate INTERRUPT CONTROLLER. According to an INTERRUPT request then the respective driver of this PCI device is responsible to recover the cause of the interrupt request.

In contrast to the quite ill Design of the ISA bus it is possible with the PCI bus therefore that several cards an INTERRUPT line divide (shared INTERRUPTS) - bottlenecks, how one could do them in former times from the DOSen, are avoided thereby. However then the assigned software drivers for the PCI cards must be able to process also INTERRUPTS, with which several devices an INTERRUPT line divide. More to this topic gives it then with the conception of the PCI BIOS.

### 2,3 extension ROMs

The PCI specification describes also a mechanism, with which a PCI device can offer a exekutierbaren ROM code for a device-specific initialization to etc.. This ROM can contain thereby several different ROM images, in order to support the most diverse computers and processor architectures.

The OPEN BOATS standard for PCI designates FORTRAN programs in the ROM, so that the ROM code is slowly (because interprets), but but processor independent. The other possibility are " native " ROM images (for the respective platform which can be supported), about which the manufacturers make however no use (probably because then could be justified only with difficulty, why e.g. the same diagram card for a PowerMac usually for 100% are more expensive than for the Intel PC). natural can OPENBOOT images and native images in a ROM be accommodated together.

### 2,4 Plug'n'Play

The magic word " Plug and Play " is very closely connected with the PCI bus. Because the leidige topic of the resources assignment for the hardware is only here over in suitable BIOS (PCI BIOS) elegantly solvable. In the ideal case the installation of of a new PCI card sees thus as follows from (in contrast to the PC is not necessary with a ATARI compatible repeated (or repeated) boats during the installation; -)

- Card into a free Slot clean-put
- Computers start, the PCI BIOS configure the card
- Software drivers for the PCI card start and finished

The PCI bus actually is configuring defined. But contain everyone
PCI device a record of registers, which can be picked out during the boat process. Contained are here apart from information about the device (manufacturer, device, type class, possibilities, Waitstates, INTERRUPT...) also the necessary storage areas.

Thus it is possible for the BIOS to merge the card correctly in the system without resources conflicts or strike itself the user with DIP switches, Jumpern etc. must occur. At the Macintosh sector (NuBus) and at the Amiga sector (Zorro II/III bus) e.g. the problem of the autoconfiguring is solve since the existence of the respective bus systems (thus for over 10 years) by the way already!

The PCI standard designates meanwhile also optionally the " Hot Plug ability ", so that PCI cards can be changed even in operation. That may be made however in no case at the Hades or Milan, since this can lead to the destruction of the Main board or the card (for this feature special prerequisites are necessary).

### 2,5 Hades

In the Hades the at present common implementation with 32 bits and max. 33 mc/s is used. For the conversion of the PCI bus in the Hades thereby the ' PCI local bus Specification revision 2,0 ' was consulted. The binding to the CCU takes place via a reprogrammierbaren Xilinx building block, by which therefore also later extensions should be possible.

The INTERRUPT lines INTA - INTD of each Slots are summarized and thereafter the TT-MFP are supplied. By the use of a MFP as INTERRUPT CONTROLLER (only flank triggering possible), the binding corresponds to the PCI specification with the Hades actually not, there

in this all INTERRUPT lines as ' are level-triggered ' defined. This circumstance difficult more difficult naturally the correct implementation of INTERRUPT-HANDLEARN, which must consider this behavior accordingly. Better the use of a PCI BIOS, which relieves this " Schwerst" work of, is natural.

In the Hades there are 3 DMA (direct memory access) channels for the 4 PCI Slots altogether. PCI Slot 1 occupies DMA (direct memory access) channel 1 (highest priority), PCI Slot 2 is assigned the DMA (direct memory access) channel 2. Those / REQ and / GNT lines of the Slots 3 and 4 are summarized concerning DMA and occupy the DMA (direct memory access) channel 3 (lowest priority). The Busarbitrierung with the help of these signals is taken over by a further mini Xilinx.

Fig. 1: The components in the Hades, taken part in the function of the PCI bus

### 2,6 Milan

Also the Milan has a PCI bus with a data capacity of 32 bits with max. 33 mc/s. The binding to the CCU been made by a PCI Bridge of the company PLX. INTERRUPT over the Intel PCI ISA Bridge and the INTERRUPT CONTROLLERS available therein are processed and passed on as autovector INTERRUPTS to the CCU. The Busarbitrierung for the DMA accesses takes place in one of the Glue chips.

Fig. 2: Block diagram of the hardware structure used in the Milan

## 3. Configuration range from PCI devices

As previously mentioned, each PCI device has its own register record. An access to this configuration area always takes place via parallel setting of the IDSEL line of the ensprechenden Slots and the creation of the register address and the bus command Configuration READ or Configuration Write on the lines / C/BE[0..3 ]. The IDSEL line is separately available thereby for each Slot and by the Motherboard is out-coded. Only with this type of the control an access to the individual cards is directly possible after the RESET, since at this time still no address areas were assigned. That access to these registers becomes up the PC supplied by the PCI BIOS over the instruction Configuration READ / Configuration Write.

### 3,1 general

The PCI bus has the potential to simplify the configuration of supplementary tickets substantially. In addition however these PCI devices must make certain functions available (via registers) of the configuration software (PCI BIOS). In the following the registers of this pre-defined configuration area are thus presented. The accurate format of the registers (i.e. the number of implemented bits etc..) again wiederrum depends on the respective PCI device. However some general rules must be observed. So all registers must offer the possibility of reading the adjusted values backwards and these read data must represent a value, which the card for the current adjustments even uses.

The configuration registers will for the configuration, and used initialization for the handling of heavy errors, and should only by the initialization software (i.e. PCI BIOS) and possible error processing routines be used. The device drivers are to use only accesses to I/O and/or MEMORY of areas, in order to manipulate device-specific registers and thus the functionality of the PCI device.

### 3,2 outline

Each PCI card contains a record of defined registers, which supply information about the card and which at all only enable the automatic assignment of resources. The register area is 256 bytes long and divides into one of the PCI-SIG (PCI - Special Interest Group) pre-defined and into a card-specific area. Only the necessary registers must be implemented the memory layout 64 byte to be enough, pre-defined area must however by each PCI card be kept and contain identification data of the card and the possibilities for the general check of the card in the respective PCI devices by the two areas. The following 192 bytes are given not by the PCI specification, but can be filled with manufacturer-specific information and analysed afterwards by the software driver.

The registers are analysed during the initialization of the PCI bus and must contain valid values therefore already directly after the RESET. Also later the registers must remain in the free access, have there needed for example the operational software (PCI BIOS) the information about the address areas and possible status information to be queried.

In order to find out, which cards are attached at the PCI bus now, one can select the Vendor ID in everyone the Slots available in the system. The host system therefore access to the configuration areas does not have to support available cards (without error message). Since for a Vendor ID the value FFFFhex is not permitted, it is therefore enough completely if the system hardware does not return the delivery this value with read accesses on the configuration area available cards evenly.

Each PCI device must ignore write accesses on reserved or not supported registers, i.e. the write access must be concluded at the PCI bus without error message. The data are rejected however by the card. Read accesses on reserved or not implemented registers must be likewise concluded without error message at the bus, and be returned a value of 0000hex.

Table 1: The pre-defined configuration registers

Configuration register | Address Offset
--- | ---
DEVICE ID | Vendor ID | 00h
Status | COMMAND | 04h
Class code | Revision ID | 08h
ARE | Header type | Latency timer | Cache LINE Size | 0Ch
Cousin ADDRESS of register | 10h
14h
18h
Çh
20h
24h
Reserved | 28h
Reserved | 2Ch
Expansion ROM cousin ADDRESS | 30h
Reserved | 34h
Reserved | 38h
Max_lat | Min_Gnt | INTERRUPT pin | INTERRUPT LINE | 3Ch

Table 1 shows the layout from the PCI-SIG defined 64Byte-Bereichs, which must support each card. It is naturally released to each PCI device to store further device-specific registers in the following area. All fields, consisting of more than one byte, are appropriate for the Little Endian (Intel) format as the base, i.e. the niederwertigere address contains also the niederwertigere byte.

The driver often commodity must deal with bit-coded fields carefully, since these mostly reserved bit locations for a any later use contain. The software must therefore with read accesses masks use around the used bits to extract, and may under no circumstances on certain values in reserved bits rely. With write accesses the software must guarantee the fact that the values of reserved bits are not changed, i.e. their value must beforehand selected and to the desired value of the other bits " gemerged " becomes.

Also this of the PCI-SIG pre-defined area is divided into two areas. First 16 bytes the long area applies to all types of PCI devices and is always alike. Different layouts can be assigned to the remaining 48 bytes as a function of the function of the PCI device. The field ' header type ' at address 0Ehex determines, which layout it concerns within this second area.

All PCI devices must implement the registers for Vendor ID, DEVICES ID, COMMAND and status. The implementation of the other registers is optional and depends again once more on the functionality of the PCI device. Implemented registers cannot being treated registers reserved by the PCI device like. If however a PCI device contains a function, whose behavior is determined through one of the defined registers, then the PCI device must make this register available in the place with the defined behavior, defined for it.

### 3,3 identification registers

Five fields within the pre-defined area are intended for the identification of the device. All PCI devices must support these fields. The configuration software can determine thus easily, which devices at the PCI bus of the computer are available. All these registers are " READ only ".

#### 3,3,1 Vendor ID

This field identifies the manufacturer of the PCI device. Valid identifiers are assigned of the PCI-SIG to paying (!) members, in order to ensure a clarity. This manufacturer identifier is 16 bits long, whereby the value FFFFhex represents an invalid Vendor ID and from the Motherboard with an not occupied Slot one returns the delivery. On the basis this value thus the PCI BIOS can differentiate whether in the Slot concerned a card is available or not

#### 3,3,2 DEVICES ID

This field identifies a special device. The identifier will assign to the software driver from the manufacturer of the card, and serves together with the Vendor ID to unique detecting of a PCI device. The function FindPCIDevice of a PCI BIOS makes use from this possibility. A special problem results however when using standard INTERFACE chip like the PCI9060. If one uses such an INTERFACE chip e.g. on a card even built, then this announces itself with its own Vendor and DEVICE ID and for a unique recognition and distinction of such cards is necessary therefore still another subsystem Vendor ID as well as subsystem a DEVICE ID. With this topic at a later point in time a further article will concern itself.

#### 3,3,3 revision ID

This register contains a device-specific revision number. The value will assign again from the manufacturer of the card, whereby also the revision number is permitted to 00hex. This field should be regarded therefore as manufacturer-specific extension to the DEVICE ID.

#### 3,3,4 headers type

This byte determines both the layout of the bytes 10hex to 3Fhex of the configuration area, and the information whether the device contains further functions. Bit 7 of this register is used in order to indicate so-called multi function DEVICES. If the bit is 0, then it concerns with this device a single function DEVICE, is it however set, then this device has several functional units. Bits 6,,0 determine finally the format of the second section of the configuration area. Pointed to table 1 the layout applies to standard devices and is marked by header type 00hex. At present still header is type
01hex for PCI to of PCI Bridges defines.

#### 3,3,5 Class code

The Class code register is ' READ only ' and in addition is likewise only used, in order to determine the ' kind ' (the general function) of a PCI device, as well as in some few cases a register INTERFACE.

The register is partitioned in addition in 3 bytes. The highest byte (at address 0Bhex) represents the base class, which quite generally describes the function of this card. The middle byte (at address 0Ahex) is a Subklasse, which more exactly describes the function defined in the base class. With respect to the case of base class 02hex for network CONTROLLER is continued to differentiate here e.g. between Ethernet, token ring, FDDI and other types. The lowest byte (at address 09hex) is finally device-specific register INTERFACE, over which device-independent software with the device can communicate. Table 2 shows the defined values for the base class. The Class code enables at all only the co-operation of device-independent software with standard components as for instance to a diagram card, since there is evenly an abundance at different manufacturers (Vendor ID) and different compatible diagram cards (DEVICE ID), whom a driver would have to implement otherwise all.

Table 2: The definition of the base classes

Base class | Meaning
--- | ---
00h | PCI device was already manufactured before the definition of the Class codes
01h | measure of STORAGE CONTROLLER
02h | network CONTROLLER
03h | display CONTROLLER
04h | Multimedia DEVICE
05h | MEMORY CONTROLLER
06h | Bridge DEVICE
07h - FEh | reserves
FFh | device fits into none of the above classes

##### 3,3,5,1 the base class 00 hex

This base class was defined, in order to ensure downward compatibility for those PCI devices, which were already built before the definition of the base classes. New devices may not use this value any longer, and older devices should transferring so far than possible to a more meaningful value. For this base class only two Subklassen, all other values exist are reserved.

Table 3: Base class 0

Base class | Subklasse | INTERFACE | meaning
00h | 00h | 00h | all PCI devices except VGA compatible devices
01h | 00h | VGA compatible devices

##### 3,3,5,2 the base class 01 hex (measure of STORAGE CONTROLLER)

This base class was defined for all possible applications of mass storages. So far no registers INTERFACES are defined for these devices

Table 4: Base class 1

Base class | Subklasse | INTERFACE | meaning
01h | 00h | 00h | SCSI bus CONTROLLER
01h | 00h | IDE CONTROLLER
02h | 00h | floppy disk CONTROLLER
03h | 00h | IPI bus CONTROLLER
80h | 00h | other one measured STORAGE CONTROLLER

##### 3,3,5,3 the base class 02 hex (network CONTROLLER)

This base class was defined for the most diverse types at network cards. There are so far still no defined registers also here INTERFACES.

Table 5: Base class 2

Base class | Subklasse | INTERFACE | meaning
02h | 00h | 00h | Ethernet CONTROLLER
01h | 00h | token ring CONTROLLER
02h | 00h | FDDI CONTROLLER
80h | 00h | other network CONTROLLER

##### 3,3,5,4 the base class 03 hex (display CONTROLLER)

This base class was defined for all types at diagram cards. In addition there are some Subklassen, to which its own register INTERFACE exists in each case.

Table 6: Base class 3

Base class | Subklasse | INTERFACE | meaning
03h | 00h | 00h | VGA - compatible diagram card
01h | 00h | XGA - compatible diagram card
80h | 00h | all other diagram cards

##### 3,3,5,5 the base class 04 hex (Multimedia DEVICE)

This base class defines the possible types of Multimedia devices, for which however no specific registers INTERFACES are defined.

Table 7: Base class 4

Base class | Subklasse | INTERFACE | meaning
04h | 00h | 00h | video
01h | 00h | audio
80h | 00h | other Multimedia of devices

##### 3,3,5,6 the base class 05 hex (MEMORY CONTROLLER)

This base class defines all possible types at MEMORY control-learns. No specific registers INTERFACES are defined.

Table 8: Base class 5

Base class | Subklasse | INTERFACE | meaning
05h | 00h | 00h | RAM
01h | 00h | FLASH
80h | 00h | other MEMORY CONTROLLER

##### 3,3,5,7 the base class 06 hex (Bridge DEVICE)

This base class is reserved for all possible types of ' bridge DEVICES '. Such PCI bridge is a PCI device, which mappt PCI resources (MEMORY or I/O) of page of this device on the other page of the device. There are several Subklassen, and no specific registers INTERFACES are defined.

Table 9: Base class 6

Base class | Subklasse | INTERFACE | meaning
06h | 00h | 00h | host bridge
01h | 00h | ISA bridge
02h | 00h | EISA bridge
03h | 00h | MC bridge
04h | 00h | PCI to of PCI bridge
05h | 00h | PCMCIA bridge
80h | 00h | all other bridge DEVICES

### 3,4 control registers

#### 3,4,1 COMMAND registers

Over the COMMAND registers know the different possibilities of the PCI device over individual bits freigeschalten to become, if the device also supports this. The COMMAND register represents also a simple check of the PCI device whether it may PCI Cycles generate or to it answer. If one writes 0 into the COMMAND registers, then this device with exception of accesses to the configuration area is logically separate from the PCI bus. All PCI devices must put this functionality to the system at the disposal. The other bits in the COMMAND register can be implemented in dependency of the further functions and possibilities of the card concerned alternatively. A card, which permits e.g. no I/O to accesses, will not permit also a setting of the appropriate bit in the register. The PCI devices contain typically the value 00hex after that power UP, i.e. the functions are only released by the PCI BIOS (or also not).

Table 10: Bit in the COMMAND register

Bit | meaning
0 | IO space 0: Device does not react to I/O access 1: Device reacts to I/O access
1 | MEMORY space 0: Device does not react to MEMORY access 1: Device reacts to MEMORY access
2 | bus master 0: Device does not generate any accesses at the PCI bus 1: Device may appear as bus masters
3 | Special Cycles 0: Device ignores Special Cycle operations 1: Device reacts to Special Cycle operations
4 | MEMORY Write and Invalidate Enable (as bus masters) 0: Device uses MEMORY Write of instruction as bus master only 1: Device may use MEMORY Write and Invalidate.
5 | VGA pallet Snooping (bit must made available by all VGA compatible devices weden) 0: Device treats pallet instruction like all different 1: Device does not answer to pallet instruction
6 | parities error Response (devices, which check for parities, this bit must support; Devices must always generate the parity bit, even if the function is deactivated over this bit) 0: Device ignores parities - errors 1: Device signals and reacts to parities - to error
7 | WAIT Cycle control 0: Device operates without address DATA stepping 1: Device operates with address DATA stepping
8 | SERR # enable (parity one announced one set only if also this bit) 0: Device may not signal a system error at pin / SERR 1: Device may signal system error at pin / SERR
9 | almost bake-to-bake Enable (it determines whether the PCI device may execute transactions as bus masters to different targets; the initialization software sets this bit, if all targets almost bake-to-bake capable signal) 0: Device may almost bake-to-bakes not to use 1: Device may as bus master almost bake-to-bakes uses
10-15 | reserves

#### 3,4,2 status registers

The status register is used to it, in order information concerning PCI bus - relevant processes to the order to place. The PCI devices do not have to implement again wiederrum all bits, depend again on the functionality of the card. If a card acts e.g. as target, but never a target toilet signaled, also this bit will not be used by the card. Read accesses on these registers run normally, write accesses on this register can only reset but not set bits. A bit in this register is deleted, if one writes a 1 at the respective position. If one liked to delete e.g. bit 14, without impairing other registers, then one writes the value 4000hex into this register. In contrast to it the PCI device can these bits only set, but not reset.

Table 11: Bit in the status register

Bit | meaning
0 - 6 | reserves
7 | almost bake-to-bake Capable (it displays, whether the PCI device as target almost bake-to-bake transactions to several targets verabeitet can) 0: none almost bake-to-bake transactions as target possible 1: Device understands as target also almost bake-to-bakes transactions
8 | DATA parity Detected (one signals only if a parity error occurs during a bus master access, and by the COMMAND registers also freigeschalten became) 0: no parity error with master access or by COMMAND register closed 1: Parity error occurred with master access
9 - 10 | DEVSEL timing (a PCI target it displays at pin / DEVSEL that it registered access in an address, which is in an address range assigned by the base address register; the value determines, at which point in time after the address phase the pin / DEVSEL from High after Low changes.) 00: fast (after a PCI clock cycle) 01: means (after two PCI clock cycles) 10: slowly (after three PCI clock cycles) 11: reserved
11 | Signaled target toilet (displays, if the PCI device aborts the current transaction at the PCI bus) 0: no aborted transaction 1: Device aborted transaction with ' target toilet '
12 | Received target toilet (displays, if the PCI device as bus master one acts and one aborts the current transaction at the PCI bus by the target) 0: no aborted transaction 1: Target aborted transaction with ' target toilet '
13 | Received master toilet (displays, if the PCI device as bus master one acts and one aborts the current transaction with exception of Special Cycle at the PCI bus by ' master toilet ' - all bus-master-capable devices must implement this bit) 0: no aborted transaction 1: Bus master - transaction was aborted by ' master toilet '
14 | Signaled system error (it displays, whether the device signaled system at pin / SERR an error) 0: no system error 1: System error signals
15 | Detected parity error (it displays, whether the device detected a parity error - even if the parity handling by the COMMAND registers abgeschalten became) 0: no parity error detected 1: Parity error detected

#### 3,4,3 different functions

The following registers are device-specific and must be made available only by those cards, which contain described functionality. For the standard operation these registers are not necessary.

##### 3,4,3,1 Cache LINE Size

This register determines the size of the Cache LINE in long words (32 bits). This register must be made available by all bus-masterable devices, which Write and Invalidate the command can generate. Devices to caching protocol are involved, use this register over to find out, when Burst accesses at the Cache are to be repeated boundaries. If the register is set to 0, the respective devices can ignore the PCI Cache lines / SDONE and / SBO. Devices, which make this register available, must set its value with RESETS to 0.

##### 3,4,3,2 Latency timers

That standard access on the PCI bus is the Burst. A single access is thus nothing different one than after the first data item terminated Burst. Both the master and the Slave (target) can abort a Bursttransfer. The bus master aborts a transfer if the bus is extracted from it over / GNT, and its internal delay (latency timers) ran.

This register determines the value of the Latency of timer for bus master, and must therefore also by all bus-masterable devices be made available, which process more than two data phases in the burst mode. With two or fewer data phases in the burst mode this register can being executed also than ' READ only ', the value thus fixed should however smaller alike 16 (bus clocks) be. A quite spread implementation designates e.g. the lowest 3 bit as ' READ only ', while the upper 5 bits can be changed at will. Thus a dissolution of the Latency of timer of 8 bus results clocks. Is this register however as pure ' READ only' register executed, does not have to set the PCI device to its value with RESETS to 0.

##### 3,4,3,3 Built in Self test (ARE)

This optional register serves for the control one on the PCI card implemented self-tests, if this is at all available. PCI devices no self check make available, return the delivery in this register the value 0. A device, whose self check was started, may impair the normal operation of the PCI bus in no keinster way.

Table 12: Bit in ARE register

Bit | meaning
7 | ARE capable 0: Device does not support a self check 1: Device makes an inserted self check available
6 | start ARE 1: Self check start. After termination of the test this bit is set by the PCI device again to 0. Even if this does not apply at the flow of 2 seconds, then this card is to be classified as defective.
5 - 4 | reserves
3 - 0 | Completion code 0000: PCI device passed the self check. All values different of 0000 represent device-specific error codes.

##### 3,4,3,4 INTERRUPTS LINE

This 8-bit broad registers is used by the host system to generally make the information available about that the device assigned hardware INTERRUPT. The value in this register displays, which input of the INTERRUPT CONTROLLER is connected with the INTERRUPT pin of the PCI device. Both device drivers and the operating system can use this information in order to determine INTERRUPT priorities and vector information. The values in this register depend on the respectively used architecture. The value FFhex is used if no allocation to the INTERRUPT CONTROLLER could be determined, or if no connection to this exists. By the PCI device this register not one continues to consider.

##### 3,4,3,5 INTERRUPTS pin

The INTERRUPT pin register can be only read. Via this register the PCI device indicates to the host system, which INTERRUPT line of the PCI bus uses it. PCI devices, which do not generate INTERRUPTS, must set this register to 0.

Table 13: INTERRUPT pin register

Worth | meaning
0 | PCI device generate no INTERRUPTS
1 | PCI device uses INTERRUPTS pin / INTA
INTERRUPT | pin / INTB uses 2 PCI device
3 | PCI device uses INTERRUPTS pin / INTC
INTERRUPT | pin / INTD uses 4 PCI device
5-255 | reserves

##### 3,4,3,6 MIN_GNT and MAX_LAT

These two ' READ only ' registers determine the limit values for setting the Latency of timer (only for the bus master operation necessarily). Both registers have here a dissolution of 0.25 microseconds. A value of 0 displays that this PCI device no special demands of the configuration of the Latency of timer makes.

MIN_GNT displays, how long the PCI device needs at least for only one Burst period (only one data phase) regarding a PCI clock rate of 33 mc/s. Thus the bus should be assigned to the PCI device (when bus masters) by the bus Arbiter for at least this time. MAX_LAT defined, for like for a long time the PCI device as bus master access to the PCI bus to obtain would like. From both values one can select then a suitable value for the Latency timer register. The bus master returns the bus only then if the bus Arbiter extracts the PCI bus from it over / GNT, and which ran own latency timers. A master may protect itself however not by constant activating / REQ line the bus in the long term, but only for the current access use. The algorithm to the Arbitrierung is however not determined in the PCI specification. The PCI devices should indicate therefore also such values, which enable an effective use both the PCI bus and their own internal resources.

#### 3,4,4 base ADDR meals

The base addresses are one of the most important functions, in order to ensure a simple configuration and integration of PCI devices into the computer system. The six base address registers contain in the initialization phase (from the PCI BIOS) assigned the addresses to the access to the individual address areas of the PCI device. Bit 0 in these address registers can be only read and displays whether the address area is situated in the MEMORY area or in the I/O area.

##### 3,4,4,1 MEMORY areas

Registers, which request a MEMORY area, must set 0 to the value 0 to bits. The registers are thereby either 32 bits or in addition, 64 bits long. For the Auskodierung of the base address the PCI device uses however only bits 4 to bits 31 or Bit63, i.e. MEMORY areas always begin at 16 byte - boundaries. The other bits are ' READ only '. In bit 3 of the register it is indicated whether the address range is ' prefetchable ', and in bit 2 and bit 1 the desired type of the MEMORY is mappings in the initialization phase.

Table 14: Address register for MEMORY areas

Bit | meaning
31(63)..4 | MEMORY base address (32 or 64 bits long)
3 | Prefetchable
2 - 1 | type (the register 32/64 bit would pour, as well as desired address area) 00: 32 bits long, arbitrary in 32 bits the address area 01: 32 bits long, address area below 1 MB 10: 64 bits long, arbitrary in 64 bits the address area 11: reserved
0 | MEMORY space indicator = 0

##### 3,4,4,2 I/O areas

Registers, which request an I/O area, are always 32 bits long and must in bit 0 the value 1 return the delivery. Bit 1 is reserved (READ only) and must be always deleted, all other bits (bit 2 to bits 31) finally describes the address in the I/O area, i.e. these areas always begin at 4 byte - boundaries.

Table 15: Address register for IO areas

Bit | meaning
31..2 | I/O base address
1 | reserves (always 0)
0 | IO space indicator = 1

Altogether workstation for six address registers is in the configuration area. The first address register always begins at offset 10hex. The position of the second address register depends then however on the size of (32/64 bit) of the first register, and therefore begins at offset 14hex or 18hex. Diagram cards request typically an I/O area for the control registers and a MEMORY area for the diagram memory. If a PCI device wants to put its control registers into the MEMORY and into the I/O area, it must " spendieren " for it also two address registers. Basically it all PCI devices should enable, to control registers into the MEMORY area to briefcases. That developed from the inadequacy of the PC's, which possess a much to small I/O area.

##### 3,4,4,3 request of address areas

In order to determine now, how much memory requests the respective device by means of the address registers, the host system describes each address register with the value FFFF'FFFFhex and reads thereafter the register backwards again. The PCI device supplies at those bit locations 0 back, it to the Auskodierung of the desired storage area uses. If the device requests e.g. a 1MB large MEMORY area in the 32-bit address area and 256 byte a large I/O area, then one finds FFF0'0000hex for the MEMORY area after describing with FFFF'FFFFhex in an address register and in the other FFFF'FF01hex for the I/O area. The host system can assign in accordance with it the base addresses for the respective PCI devices. Starting from this point in time the PCI devices decode the accesses then out. The assignment of the address areas with boats of the computer system is function of a PCI BIOS.

## 4. PCI BIOS

### 4,1 idea

The idea to the PCI BIOS for the ATARI compatible computers developed from the necessity for the allocation of storage areas to the I/O and MEMORY areas of the PCI devices.

On PC's and compatible ones PCI functionality is made available over an Bios extension (the PCI BIOS) standardized. The Bios has two substantial functions. On the one hand the supply of an interface for the software for the access to the PCI devices, on the other hand the initialization and the distribution of the resources of the individual PCI devices. The initialization runs without direct access of the user directly after the RESET.

### 4,2 boat process

After the RESET the host system tests first the presence of the installed PCI devices. These effected via the access to a defined register (Vendor ID). at this time are possible for access to the still unknown cards only with the instruction Configuration READ and Configuration Write. After it out-gets the system has whether and where cards are in the computer, with all PCI devices the necessary address areas is determined. This occurs as previously mentioned with the writing of the value FFFF'FFFFhex into the respective address register.

Each PCI device can request max. 6 storage areas. The address range in the address register, needed in each case, is bit by bit out-masked. For coding for example bits 0 to bits 9 are used (out-code with FFFF'FC00hex), the area 2^10 is, thus 1024 bytes large. There is the selection between I/O gemappten and MEMORY gemappten areas (see articles in output 5/98). For a PCI device the two areas differ on only by the different commands / C/BE[0..3 ].

As response the host system (BIOS) assigns in each case address ranges to the individual devices - if in the address area enough workstation is available. Here e.g. the Hades in the comparison to the PC has to offer some more, since in the PC the I/O area is very limited. The Hades offers in our case 256 MB to I/O area and 512 MB MEMORY area. That should really be sufficient for the start; -) After the log-on the PCI devices then are responsible for the Auskodierung of their address areas. The assigned address areas can be selected for the later accesses to I/O and MEMORY area from the configuration registers of the devices also again.

In a register of the defined configuration area (INTERRUPT pin) by each PCI device the INTERRUPT line used in each case is indicated. The BIOS assigns thereupon and further functionality puts to one of the available INTERRUPTS over BIOS routines at the disposal.

### 4,3 process way

The driver of an installed PCI hardware therefore passes through the following steps for the initialization and following use of a PCI board:

- Test on available PCI BIOS and its version number
- PCI card with the routines find_pci_device or find_pci_classcode look up; the card must then exclusively over of the PCI BIOS the assigned deviceconcerns to be addressed.
- either over get_resource the necessary information for the direct access to the respective storage areas are selected (the driver must here possible off sets, which Ordering etc. consider byte), or but one uses the reading and write routines for MEMORY and I/O of areas, provided by the PCI BIOS
- possibly further card-specific information selects and on it reacts accordingly
- Card finally via the registers in I/O or MEMORY area head for

The further access to the attached PCI devices after the initialization and configuration access to the accordingly assigned address ranges is thus made by MEMORY and/or I/O. For this access no special Bios would be more necessary, but the PCI BIOS offers however evenly also here a simple accessability on these storage area/registers of a PCI device, without having to worry about any off sets and byte Orderings (Intel/Motorola).

### 4,4 installation of the PCI BIOS

Milan owners can skip the following paragraphs of calm conscience (it to read harms in addition, not), because the Milan the PCI BIOS already in the TOS integrated. Thus, switching on on and equal lot putting reads here the foreign exchange.

When Hades owners one copies PCI_BIOS.PRG from the file simply into the AUTO file, if possible at the beginning, but in any case before device driver PCI cards accesses and for it the BIOS interface already needs. The PCI BIOS creates in addition one _ PCI Cookie, over which then localizes the BIOS routines and to be used can. Details in addition are also in the ATARI PCI BIOS Specification (the current output carries the version number V1.12). at the Hades exist however additionally also still the possibility, a Low level BIOS (PCI_CONF.PRG of Torsten long) to install, which supplies the necessary information about Subcookies after the initialization of the PCI devices. Too PCI_CONF.PRG one can inquire details at the author Torsten long.

If one starts thus PCI_CONF.PRG forwards PCI_BIOS.PRG, then _ a PCI Cookie is already present. The I-BIOS used then already of PCI_CONF information supplied over the Subcookies and contributes then (only) still the interface for the BIOS routines. Also the INTERRUPT handling is then passed on from the PCI BIOS PCI_CONF. Since it will however not give for the Milan a PCI_CONF.PRG, the driver programmers should use excluding the standardized BIOS interface, which does not exclude however again wiederrum the use of PCI_CONF. Device drivers, which " nourish themselves, do not become " however only of the Subcookies of the PCI_CONF on other ATARI compatible PCI computers as the Milan not to function.

If one uses PCI_BIOS.PRG alone, then it (with exception of the supply of the Subcookies) takes over the functions of PCI_CONF.PRG and creates _ the PCI Cookie with the information itself necessary for the BIOS interface. The information, which PCI_CONF would normally supply over Subcookies, is however not lost, because for this the PCI BIOS makes the standardized routine available get_resource .

## 5. Functions of the PCI BIOS

To receive described in the following thus the software INTERFACE, which can be used by the PCI device drivers and other operational software, in order access to the PCI cards in ATARI compatible systems. Details can be reread also in the current in each case output of the ATARI PCI BIOS Specification. After all Vorraussicht one will find these in the near future under http://www.milan computer.de.

The PCI Bios installs " _ PCI" Cookie for one, via which the BIOS routines can be localized and addressed. For programmer there is for this already a PCI LIBRARY, who completes these functions, and thus very simple access permits. The current in each case versions of the PCI BIOS for the Hades and the appropriate PCI LIBRARY are to be found under http://www.wvnet.at/privat/97021702 /. Further there is a c-sample program here also for the use of this LIBRARY. As soon as the generally valid ATARI PCI BIOS Specification is available in the Internet, will it also one link here on it to give. With the Milan the BIOS routines will be fixed integrated in one of the next versions of the Milan TOS, an appropriate program in the AUTO file are not necessary in contrast to the Hades thus then any longer. Whether and when this possibly also with the Hades the case its becomes, can be said at this time not yet.

Each PCI device of the PCI BIOS deviceconcern assigned, with which these devices can be addressed then. Conclusions of do not deviceconcern on the PCI Slot concerned are possible, and also not desired. In the following calls in assembler and C, the information is represented to the used parameters completes themselves in each case mutually. All PCI BIOS routines must be called in the supervisor mode.

### 5,1 the PCI BIOS error code

The following error codes can be returned the delivery in the event of an error by the BIOS routines.

Table 16: Error code of the BIOS routines

Error code | name
$00000000 | PCI_SUCCESSFUL
$$FFFFFFFE | PCI_FUNC_NOT_SUPPORTED
$$FFFFFFFD | PCI_BAD_VENDOR_ID
$$FFFFFFFC | PCI_DEVICE_NOT_FOUND
$$FFFFFFFB | MORE PCI_BAD_REGISTER_NUMBER
$$FFFFFFFA | PCI_SET_FAILED
$$FFFFFFF9 | PCI_BUFFER_TOO_SMALL
$$FFFFFFF8 | PCI_GENERAL_ERROR
$$FFFFFFF7 | PCI_BAD_HANDLE

The following two error codes are used not by the BIOS routines themselves, are however reserved for a PCI LIBRARY.

Table 17: Error code of the PCI LIBRARY

Error code | name
$$FFFFF001 | PCI_BIOS_NOT_INSTALLED
$$FFFFF000 | PCI_BIOS_WRONG_VERSION

### 5,2 configuration and handling

#### to 5,2,1 find PCI DEVICE

This function serves for to look a certain PCI device up (a PCI card can accommodate again wiederrum several functional units = devices) over DEVICES and Vendor ID. Thus a software driver finds thus its appropriate hardware, if it was installed also in the computer. If a hardware should be several times in the system available, or two cards with the same IDs to announce itself, so the individual cards are queried over their index. One begins thereby with index 0 and increases him then until the routine returns the delivery the error code PCI_DEVICE_NOT_FOUND.

Call in assembler:

    	Input:

    		D0.LDevice ID
    in the bits 31,,16 (0 - $$FFFF),

    			Vendor ID in the bits 15,,0
    (0 - $$FFFE)

    		D1.WIndex (0 up to number of PCI devices with
    these ID)

    	output:

    		D0.LGeraete-Handle or PCI BIOS
    error code

Call in C:

    	LONG concerns = find_pci_device (ULONG
    id, UWORD index)

    	id:Device and Vendor ID of the PCI device

    	index:Index (with several same devices)

    	Returnwert:positiv - deviceconcern

    				negatively - PCI BIOS
    error code

Special case:

with Vendor ID FFFFhex one can look all PCI devices up available in the system, which DEVICE ID ignored in this case.

#### to 5,2,2 find PCI Classcode

This function serves to look a certain PCI device up over their Classcode. With this function it is e.g. possible to achieve the diagram card without knowing the manufacturer or the DEVICE ID. This function leads naturally only to success even if the PCI device uses one the determined Class code. There are several PCI devices with the same Classcode, then the device driver can the further cards over their index test. One begins thereby with index 0 on and increases him then until the routine returns the delivery the error code PCI_DEVICE_NOT_FOUND.

Call in assembler:

    	Input:

    		D0.LClasscode:

    			Bit 23..16Base class (0 - $$FF),

    			bit 15..8Sub
    class (0 - $$FF),

    			bit 7..0Programming INTERFACE (0)

    			flag:

    			Bit 26Base class 0:vergleichen 1:ignorieren

    			bit 25Sub class 0:vergleichen 1:ignorieren

    			bit 24Progr.
    INTERFACE:  one can

    			indicate 0:vergleichen 1:ignorieren with
    the bits 24,,26 thus, which sections of the Classcodes

    			must
    correspond with the found PCI devices

    		D1.WIndex (0 - number
    of PCI devices with this Classcode)

    	output:

    		D0.LGeraete-Handle or PCI BIOS error code

Call in C:

    	LONG concerns = find_pci_classcode
    (ULONG class, UWORD index)

    	class:Classcode of the PCI device

    	index:Index (with several same devices)

    	Returnwert:
      positively - deviceconcern

    				negatively - PCI BIOS error
    code

#### 5,2,3 READ Configuration { Byte| Word| Longword }

These three functions permit read accesses on the configuration registers of a PCI device, whose deviceconcerns or was determined find_pci_device before find_pci_classcode by means of.

Call in assembler:

    	Input:

    		D0.LGeraete-Handle of the desired PCI device

    		A0.LZeiger on
    result variable

    		D1.BAdresse of configuration register
    (0.1.2... for byte access)

    		D1.BAdresse of configuration
    register (0.2.4... for word access)

    		D1.BAdresse of
    configuration register (0.4.8... for long word access)

    	output:

    		D0.LPCI-BIOS error code

    			read data are after
    the call in the result variable

Call in C:

    	LONG error code = read_config_byte (LONG
    concerns, UBYTE moves, UBYTE * address)

    	LONG error code =
    read_config_word (LONG concerns, UBYTE moves, UWORD * address)

    	LONG error code = read_config_longword (LONG concerns, UBYTE
    moves, ULONG * address)

    	handle:Geraete concerning the
    selected PCI device

    	reg:Adresse of the configuration register

    	more adresse:Zeiger on result variable

    	Returnwert:PCI BIOS error code

#### 5,2,4 READ Configuration { Byte| Word| Longword } ALMOST

These three functions permit a reading from registers in the configuration area without complex error and

Plausibility CHECKS and are also somewhat faster therefore than their 3 sisters (therefore it particularly suitably for INTERRUPT routines and if one knows quite exactly, what one does; -). Register contents are stored in the Returnwert. Thus these functions in c-programs can be still more easily applied.

Call in assembler:

    	Input:

    		D0.LGeraete-Handle of the desired PCI device

    		D1.BAdresse of
    configuration register (0.1.2... for byte accesses)

    		D1.BAdresse of configuration register (0.2.4... for word
    access)

    		D1.BAdresse of configuration register (0.4.8... for
    long word access)

    	output:

    		D0gelesener value (8, 16
    or 32 bits)

    		SRcarry flag is set in the case of an error
    (dependent on the implementation)

Call in C:

    	UBYTE VALUE = fast_read_config_byte
    (LONG concerns, UBYTE moves)

    	UWORD VALUE =
    fast_read_config_word (LONG concerns, UBYTE moves)

    	ULONG
    VALUE = fast_read_config_longword (LONG concerns, UBYTE moves)

    	handle:Geraete concerning the selected PCI device

    	reg:Adresse of configuration register

    	Returnwert:Inhalt of
    the configuration register

Examples:

1)device_vendor = fast_read_config_longword (handle, 0)

the Vendor ID supplies and in the bits 16-31 the DEVICE ID in the bits 0-15

2)vendor = fast_read_config_word (handle, 0)

the Vendor ID returns the delivery

3)device = fast_read_config_word (handle, 2)

the DEVICE ID returns the delivery

4)timer = fast_read_config_byte (handle, 13)

supplies the schliesslichen value of the Latency of timer

#### 5,2,5 Write Configuration { Byte| Word| Longword }

These three routines serve for the writing of configuration registers of a PCI device.

Call in assembler:

    	Input:

    		D0.LGeraete-Handle of the desired PCI device

    		D1.BAdresse of
    configuration register (0.1.2... for byte access)

    		D1.BAdresse
    of configuration register (0.2.4... for word access)

    		D1.BAdresse of configuration register (0.4.8... for long word access)

    		D2zu writing register value (8/16/32 bit)

    	output:

    		D0.LPCI-BIOS error code

Call in C:

    	LONG error code = write_config_byte
    (LONG concerns, UBYTE moves, UBYTE val)

    	LONG error code =
    write_config_word (LONG concerns, UBYTE moves, UWORD val)

    	LONG error code = write_config_longword (LONG concerns, UBYTE moves,
    ULONG val)

    	handle:Geraete concerning the desired PCI device

    	reg:Adresse of the configuration register

    	val:zu
    writing register value

    	Returnwert:  PCI BIOS error code

#### 5,2,6 INTERRUPT Handler

For each PCI INTERRUPT it knows a whole chain of INTERRUPT-HANDLEARNS to give, since also several PCI devices the same INTERRUPTS can divide (see also articles in the output 4/98). Over deviceconcern can now a device driver his own INTERRUPT Handler by hook_interrupt into the suitable chain enter let, without having to know the INTERRUPT responsible for it.

Footstep thereafter an INTERRUPT up, by the BIOS the Handler entered into the chain is called in sequence. Each INTERRUPT Handler becomes thereby with that one Parameter called, which was specified with the call hook_interrupt of. This parameter is completely freely selectable by the device driver, selection suitable with one would know with only one driver also several (identically constructed) devices parallel serve. The INTERRUPT Handler must check immediately after its call whether the INTERRUPT was released by the card cared for by them, and accordingly to react. That is, the INTERRUPT cause is to be recovered, and the appropriate bit of the BIOS internal parameter is to be set. If the appropriate device did not release the INTERRUPT, the INTERRUPT Handler may change the BIOS internal parameter under no circumstances!

The Handler is to be regarded as normal procedure, i.e. also in assembler the INTERRUPT Handler with RTS is locked.

Call in assembler:

    	Input:

    		A0.LParameter,
    that by means of hook_interrupt was specified

    		D0.LBIOS-interner parameter

    	output:

    		D0.LBit 0 will
    set, if the INTERRUPT were released by the cared for PCI card,

    			otherwise one may this parameter not be modified

Call in C:

    	LONG VALUE = interrupt_handler (LONG *
    VALUE, LONG internal)

    	value:Parameter, by means of
    hook_interrupt was specified

    	internal:BIOS internal
    parameters

    	of Returnwert:BIOS internal parameters

#### 5,2,7 Hook INTERRUPT Vector

Hangs the INTERRUPT Handler of the driver into the chain of the appropriate INTERRUPT channel. Beforehand still if no Handler was in the chain, also the PCI INTERRUPT concerned in the host system is activated. After occurance of the respective INTERRUPT the indicated INTERRUPT Handler is thus called. However it is to be made certain in particular that the INTERRUPTS on the PCI device may be activated only after the call of this function, since it can come otherwise too spurious INTERRUPTS.

If a INTERRUPT Handler is already announced for the selected PCI device, then one receives an appropriate PCI BIOS error code. It is to be advised against urgently to remove unhook_interrupt by other Handler. For this purpose there is the function get_card_used, over which a call baking routine of the other driver can be determined. The call of this call baking routine gives then the possibility to the other driver of deinstallieren itself cleanly and arrears-free.

Call in assembler:

    	Input:

    		D0.LGeraete-Handle of the desired PCI device

    		A0.LZeiger on
    the INTERRUPT Handler of the driver

    		A1.LZeiger on parameters
    for INTERRUPT Handler

    	output:

    		D0.LPCI-BIOS error
    code

Call in C:

    	LONG error code = hook_interrupt (LONG
    concerns, ULONG * routine, ULONG * parameter)

    	handle:Geraete
    concerning the desired PCI device

    	more routine:Zeiger on the
    INTERRUPT Handler of the driver

    	more parameter:Zeiger on
    parameters for INTERRUPT Handler;  this is selecting of the driver a
    value

    				freely, which will along-transfer with each call of the
    Handlers of the BIOS.

    				Thus can in only INTERRUPT Handler
    also serve several

    				identically constructed PCI devices.

    	Returnwert:  PCI BIOS error code

#### 5,2,8 Unhook INTERRUPT Vector

With this routine one can remove one hook_interrupt by means of announced INTERRUPT Handler again. The driver must note however that the INTERRUPTS on the PCI device must be deactivated before the call of this BIOS function, since it can come otherwise too spurious INTERRUPTS.

Call in assembler:

    	Input:

    		D0.LGeraete-Handle of the desired PCI device

    	output:

    		D0.LPCI-BIOS error code

Call in C:

    	LONG error code = unhook_interrupt (LONG
    concerns)

    	handle:Geraete concerning the desired PCI device

    	Returnwert:  PCI BIOS error code

#### 5,2,9 GET resource DATA

All information supplies to the resources of a PCI card (or a PCI device in the case of multi-function cards). The returned the delivery information may not be under any circumstances changed by the device drivers. The device driver can on the basis the offered information (byte ordering etc..) the card then directly address. A further possibility is the use of the BIOS routines read_mem_..., write_mem_..., read_io_... and write_io_..., whereby one must worry then about no secondary conditions themselves.

The routine supplies a pointer on the first resource descriptor of the desired PCI device. The device driver can achieve then the further descriptors by means of an offset (length of a descriptor). The last descriptor of the device is particularly marked again wiederrum. The sequence of the Despriptoren corresponds those of the base address registers in the PCI Konfigurationsbereich. A PCI device can request/use also several resources of the same type.

Call in assembler:

    	Input:

    		D0.LGeraete-Handle of the desired PCI device

    	output:

    		D0.LZeiger on first resource descriptor or PCI BIOS error
    code

Call in C:

    	LONG pointers = get_resource (LONG
    concerns)

    	handle:Geraete concerning of the desired PCI device

    	Returnwert:positiv - pointers on resource information (first
    descriptor)

    				negatively - PCI BIOS error code

Table 18: Structure resource of a descriptor

Name | Size of | description
NEXT | WORD | length of this structure in bytes, serves for the determination of the next Deskiptors
flag | WORD | type of resource and different other flags
start | LONG | start address of the resource in the PCI address range, is not directly addressable the resource, then the address is 0
length | LONG | length of the resource
offset | LONG | offset of the physical PCU ADDRESS to the PCI address
dmaoffset | LONG | offset for DMA (direct memory access) transfers to of/to primary storages
private | x BYTE | BIOS internal data, may not be changed

In order to determine the descriptor of the next resource of the PCI device, one must add the field NEXT for the start address of the current descriptor. The field start indicates the beginning of the appropriate resource in the PCI address range. If this resource should not be directly addressable, then the address 0. is located over length can one the length of this resource finally determine in this field. The PCI address range is not to be equated generally with address seen by the CCU from. The address offset, which is to be added to the PCI address, in order to determine the physical address for the CCU, is in the field offset store-storing that entry dmaoffset finally indicates the offset, which must be added to the PCI address, if it concerns DMA (direct memory access) transfers.

Table 19: The flags in the resource descriptor

Name | Flag | description
RSC_IO |  | an I/O area, with deleted bits concerns it indicates $4000 a MEMORY area
RSC_LAST | $8000 | last resource for this PCI device
FLG_8BIT | $0100 | 8 bits accesses are supported
FLG_16BIT | $0200 | 16 bits accesses are supported
FLG_32BIT | $0400 | 32 bits accesses are supported
FLG_ENDMASK | $000f | indicates the byte Ordering: 0: Motorola (big endian) 1: Intel (little endian), ADDRESS swapped 2: Intel (little endian), lane swapped 3..14: reserved 15: unknown, access only over BIOS possible

If the resource in the Motorola format (0) is present, one needs to do nothing further. All accesses run as used. If it concerns however the Intel format, is to be differentiated as a function of the implementation in terms of hardware of the PCI bus in the host system between two different possibilities:

- In the case of Intel, ADDRESS swapped (1), is not necessary with 32Bit-Zugriffen a modification of the access address. For 16Bit-Zugriffe one must XOR link however the address with the value 2, with 8Bit-Zugriffen must one the respective address with the value 3 XOR link, in order to access the memory correctly. The date which can be read/written is however always present in the correct format.
- in the case of Intel, lane swapped (2), is not necessarily at the addresses any modification. With 8Bit-Zugriffen also no conversion of the date is necessary, concerns it however 16Bit-Zugriffe, must in the date High byte and Low byte be exchanged (ror.w # 8, d0). For 32Bit-Zugriffe the 4 bytes must be brought by the form 1234 into the format 4321 (ror.w d0:swap d0:ror.w d0).

Who does not want to argue with all that more near, that should rather nevertheless equal the BIOS routines mentioned above use, which execute the if necessary necessary modifications independently. If the byte Ordering is unknown (15), one must endeavor the in any case BIOS for all accesses.

The following routines were not published yet in the appropriate article of the ST computers. As soon as the article in the output appeared 10/98, I will again insert the descriptions of the following routines.

### 5,3 MEMORY and I/O areas

#### 5,3,1 MEMORY READ

#### 5,3,2 ALMOST MEMORY READ

#### 5,3,3 MEMORY Write

#### 5,3,4 IO READ

#### 5,3,5 ALMOST IO READ

#### 5,3,6 IO Write

### 5,4 driver management

#### 5,4,1 GET Card Used

#### 5,4,2 set Card Used

### 5,5 call baking routines

#### 5,5,1 call-bake 0: GET Driver ID

#### 5,5,2 call-bake 1: Try to remove more driver

Summary

## 6. Contact address

Markus spruce farmer

Hans riding ago lane 1

A-3950 Gmuend

AUSTRIA

mailto:fichti@wvnet.at

http://www.wvnet.at/privat/97021702/index.htm

## 7. Source directory

[ 1 ] PCI local bus Specification revision 2.0

[ 2 ] Elrad 3/97 and 4/97 (bus Basics - technical bases of the PCI bus)

[ 3 ] PCI Special Interest Group

P.O. Box 14070

OR 97214, port country, the USA

http://www.pcisig.com