| What I had to do to make cards happy: |
| |
| 1. Tseng ET4000 W32P |
| This card wants to call the original system BIOS video routines. |
| It sets the int 0x42 vector to F000:F065, the entry point to the |
| system bios video routines. |
| CAVE: don't catch int 0x42 and use the vbios int 0x10 routines. |
| At early stage during initialization they call int 0x42. This |
| causes an infinite loop. |
| |
| 2. ATi Mach64 Rage IIc AGP |
| This card does similar things like the Tseng ET4000 W32P. |
| However it doesn't have the problem with the ininite loop. |
| |
| 3. Elsa Victory II-A16 AGP Banshee |
| This card is very clever: It knows it is an AGP card. Therefore |
| it knows it is behind a PCI-PCI bridge. It also knows that noone |
| else is behind this bridge. Therefore it start reprogramming the |
| bridge! For this it assumes the AGP bridge is on bus 1. |
| |
| 4. Elsa Gloria Synergy 8 ViVo AGP PM2 |
| This card likes to see a complete interrupt vector table. If |
| we fill this table with 0 the VBIOS detects this and quits |
| initialization. |
| |
| 5. Dimond Viper 330 AGP NVIDIA Riva 128. |
| This card has a similar problem like the Elsa Gloria. It wants |
| to read the system BIOS date at 0xffffd. |
| |
| 6. Matrox Mystique PCI |
| This card reads the IO port 0x62. If it doesn't like what it sees |
| it loops forever. To keep the card happy put 0xfc into 0xffffe. |
| This location holds the system model id. 0xfc means IBM-AT. |
| One can make an interesting observation: this card likes to know |
| with whom it has to share the system. Therefore it accesses PCI |
| config space of all the other cards. It does this bypassing the |
| PCI BIOS by reading the PCI access ports directly. |
| |
| 7. Matrox G100 AGP |
| This card has the same problem as the Mystique. |
| |
| Apperantly this works now. However not all combinations of cards are |
| checked, yet. |
| |
| Further notes: |
| the IO register 0x42-0x43 as well as 0x61-0x63 are of special interest |
| for many graphic cards. They should be emulated. |
| The so called "Industry Standard BIOS Entry Points" to int 0x42 (0xFF065) |
| and to int 0x1a (0xFFE6E) should be filled with useful code. This code |
| needs to return as if it was called as int. |
| The subvendor ID PCI registers might cause problems. On some chipsets |
| they are programmed in a non-obivous non-PCI conformant way. |
| V_Bioses are seen to modify the following int: |
| 0x10 (default video), 0x1f(font table), 0x42(copy of default video), |
| 0x43 (??), 0x6d (copy of default video - same as 0x10?) |
| |
| TODO: |
| Int 0x6d needs to be done. |
| All interrupts where there is no default industry standard entry point |
| should point to an unused location in the 0xF000 segmant (possibly |
| 0xF0000). This way they could be trapped. A trap handler for |
| a. int 0x42 and int 0x1a needs to be implemented. |
| The default "industry entry point" for video and PCI (0xFFE6E) should |
| also be implemented. (any others?) They should either be routed to |
| int 0x42(0x6d?) (video) and 0x1A (PCI) or some other interrupts to |
| trap them. Mapping of system bios might not be a good idea. Maybe |
| the system bios area should just be filled with "hlt" to trap any |
| access there. |
| Handling of timer IO registers 0x42, 0x43 and IO registers 0x61, 0x62. |
| |
| Find documentation: |
| - on interrupt vector table |
| - on industry standard entry points to the system bios |
| - on IO registers 0x61 and 0x62 |
| |
| |