AGP/PCI/ISA System Frage zu IO Ports

Michael Dreschmann schrieb:

solche "Schweinereien" habe ich besher noch nicht gemacht, aber hast du schon mal probiert, ob eine Karte solo ohne Bios in dem ISA-Slot funktioniert, ohne deine Verdrehlogik? Vielleicht ist in dem Bios irgendeine ini-Routine, die den Chipsatz überhaupt einschaltet (fpga o.ä.). Zusätzliche Grafikkarten unter verschiedenen Betriebsystemen habe ich schon barfuß angesteuert, auch am Bios vorbei aber nie ohne Bios.

Waldemar

rch

und

[...]

Gut.

kann

f

Es gibt da im Port 0x3c3 dieses magische Bit um die Karte aus dem Adressraum auszublenden. Wer wei=C3=9F, wie das nach dem Reset gesetzt is= t?

vom

=C3=9Cblicherweise wird 0x100-0x3ff weitergeleitet, solange keine integri= erte Peripherie des Chipsatzes auf den Adressen liegt. Das reicht hoffentlich.

ine

Nee, ISA-8-Bit-Zugriffe ohne Waitstate-Verk=C3=BCrzung sind komplett ohne best=C3=A4tigung. Und ob in einem ISA-Slot was drinsteckt, fragt kein PCI-Chipsatz ab. Zu EISA-Zeiten gabs da wohl mal was.

Wenn Du im Bereich 0x100 bis 0x3ff geblieben bist, ist unwahrscheinlich, dass die Zugriffe nicht ankommen. Schau doch mal mit nem Oszi (oder notfalls Voltmeter) ob sich was auf der IOR-Leitung tut (idle-Pegel 5V), wenn Du in einer engen Schleife Ports von der Karte liest.

Gru=C3=9F, Michael Karcher

Ja, auch das habe ich schonmal probiert, da kann ich sie auch nicht ansprechen. Daher der Gedanke, dass in diesem Fall der ISA Slot vom Chipsatz eventuell komplett abgeschaltet wird.

Du meinst im BIOS der ISA Graka, dass dort irgendwas am Grafikchip freigeschaltet wird? Dachte ich auch schon, aber 1. steht davon nichts im Datenblatt vom Grafikcontroller und 2. hab ich das ISA Graka BIOS mal disassembliert und da fängt er direkt an in Register zu schreiben, auf die ich keinen Zugriff bekomme. Da ich das von DOS aus versuche ist es höchstens Möglich, dass das Systembios vom Rechner hier irgendwas mit der Karte macht.

Viele Grüsse, Michael

Da steht bei meiner Controller im Datenblatt, dass dieses Register nur beim Localbus relevant. Aber ich habs trozdem mal getestet und es wirkt leider nicht :(

Meine Adressverdrehung vertauscht A[15:12] mit A[8:5]. D.h. die Adresse 0x3d6 (ist ein spezielles Register dieses Grafikcontrollers für die TFT-Ansteuerung welches immer aktiv sein sollte) landet auf

0xE216 und wäre damit ausserhalb des von dir genannten Bereichs. Allerdings funktioniert eine Parallelportkarte mit der Adresse 0x278 welche nach der Adressverdrehung 0x3218 ist durchaus einwandfrei.

Is ne gute Idee, werde ich tun. Hatte schon vor nen kleinen FPGA daranzuhängen und mit dem Xilinx Chipscope mal nachzugucken, aber bevor ich das anfange dacht ich, vielleicht weiß jemand hier die Lösung.. ;)

Viele Grüsse, Michael

Ich habe gerade nochmal nachgeschaut und entdeckt, dass die Parallelportkarte nur die Adressbits A[9:0] an den Controller führt. D.h. die kann auch nur den Bereich 0-0x3ff dekodieren, bzw. danach wiederholt der sich. Ist das normal für ISA?

Gruss, Michael

Das ist wahrscheinlich eine Karte der Marke Methusalem. Bei den XT-Rechnern war das mal so. Seite 6, 3.Absatz:

Hach, das waren noch Zeiten, Pink Floyd, Led Zeppelin, die alten Stones ...

--
Gruesse, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

Michael Dreschmann wrote:

Ja, war bei allen mir untergekommenen ISA-Karten so. Alles darüber wird nur von Onboard-(LPC-)- und PCI-Devices verwendet.

Kann gut sein, dass die ISA-Bridge die Adressbereiche gar nicht durchreicht bzw. diese Adressen schon PCI-Devices zugewiesen worden sind:

| [~]: cat /proc/ioports | 0000-001f : dma1 | 0020-0021 : pic1 | 0040-0043 : timer0 | 0050-0053 : timer1 | 0060-006f : keyboard | 0070-0077 : rtc | 0080-008f : dma page reg | 00a0-00a1 : pic2 | 00c0-00df : dma2 | 00f0-00ff : fpu | 0170-0177 : 0000:00:0f.1 | 0170-0177 : libata | 01f0-01f7 : 0000:00:0f.1 | 01f0-01f7 : libata | 0290-0297 : pnp 00:07 | 0376-0376 : 0000:00:0f.1 | 0376-0376 : libata | 0378-037a : parport0 | 037b-037f : parport0 | 03c0-03df : vga+ | 03e0-03e7 : pnp 00:08 | 03f2-03f5 : floppy | 03f6-03f6 : 0000:00:0f.1 | 03f6-03f6 : libata | 03f7-03f7 : floppy DIR | 03f8-03ff : serial | 0400-041f : pnp 00:08 | 0400-0407 : vt596_smbus | 04d0-04d1 : pnp 00:08 | 0778-077a : parport0 | 0800-087f : pnp 00:08 | 0800-0803 : ACPI PM1a_EVT_BLK | 0804-0805 : ACPI PM1a_CNT_BLK | 0808-080b : ACPI PM_TMR | 0820-0823 : ACPI GPE0_BLK | 0cf8-0cff : PCI conf1 | 5010-5015 : ACPI CPU throttle | a000-cfff : PCI Bus #01 | c000-c0ff : 0000:01:00.0 | d000-d0ff : 0000:00:12.0 | d000-d0ff : via-rhine | d400-d4ff : 0000:00:11.5 | d400-d4ff : VIA8237 | d880-d89f : 0000:00:10.3 | d880-d89f : uhci_hcd | dc00-dc1f : 0000:00:10.2 | dc00-dc1f : uhci_hcd | e000-e01f : 0000:00:10.1 | e000-e01f : uhci_hcd | e080-e09f : 0000:00:10.0 | e080-e09f : uhci_hcd | e400-e40f : 0000:00:0f.0 | e480-e483 : 0000:00:0f.0 | e800-e807 : 0000:00:0f.0 | e880-e883 : 0000:00:0f.0 | ec00-ec07 : 0000:00:0f.0 | fc00-fc0f : 0000:00:0f.1 | fc00-fc0f : libata

Gruß Henning

ist?

Dann schau noch mal ins Datenblatt. Einige Chips haben dies Register in der ISA-Version dann auf 0x46E8, IIRC. Oder MCA-Artig im Bereich um 0x102= .

f

Uh, schlecht. Der PCI-Adressraum wird h=C3=A4ufig von oben vergeben. Und

0xE000 kann demnach irgendwo in den PCI-Bus dekodiert werden. Versuch mal mit nem PCI-Listing-Tool zu schauen, wo die PCI-Karten liegen. Auf dem ISA-Bus landet nur die Bereiche, f=C3=BCr die sich PCI f=C3=BCr unzust=C3=A4ndig h=C3=A4lt.

Gru=C3=9F, Michael Karcher

t.

Ja, das ist Folklore. Als die Karten noch TTL-Gr=C3=A4ber waren hat das h= alt einen Dekoderchip bzw. die Laufzeit f=C3=BCr die Kaskadierung gespart. Un= d weil es alle so gemacht haben, hat sich auch bis mitte der 90er keiner daf=C3=BCr interessiert, alle 16 Bits zu dekodieren, schlie=C3=9Flich wei= cht man Konflikten nur aus, wenn auch der Konfliktpartner voll dekodiert.

Was durchaus =C3=BCblich war, war dagegen, die h=C3=B6heren Bits zur Regi= sterauswahl auf einer Karte zu verwenden. Die SB32-Reihe von Creative Labs hat standardm=C3=A4=C3=9Fig den Soundblaster-Teil auf 0x220, und den Wavetabl= e-Synthesizer auf 0x620, 0xA20, 0xE20. Analog wurde dieses Prinzip bei der 3c515 und ISA-ISDN-Karten mit Siemens-Chipsatz verwendet.

Deine VGA wird wahrscheinlich auch nur 10 Bits dekodieren. Zuerst wollte ich Dir vorschlagen, A5 (was zwischen 0x3C0 und 0x3DF immer 0 ist) auf A6, A7, A8 oder A9 zu verschieben, aber die Adressen sind schon alle belegt. Offensichtlich war es zu TTL-Zeiten vorteilhaft, viele 1en in der Adresse zu haben. Der Vorteil w=C3=A4re halt, dass Du im sicheren Fenster geblieben w=C3=A4rst. Wenn Du A9 und A10 tauschst, lande= t die Karte bei 0x5C0..0x5DF (bzw. 0x5B0..0x5CF wenn Du den MDA-Modus benutzt), was auch funktionieren sollte. Allerdings wird bei 10-Bit- Dekodierung dann auch 0x7C0..0x7DF funktionieren. A9A11 und A9A12 f=C3=BCr die zwei weiteren Karten w=C3=A4re erfolgverspechender, da Du im= mernoch bei recht niedrigen Adressen bleibst. 0x5C0..0x5DF aliast auf

0x1C0..0x1DF (vor dem Tausch), was meines Wissens nach =C3=BCblicherweise frei ist. Die anderen Tauschvorschl=C3=A4ge landen im gleichen Bereich, sollten also Host-seitig auf dem ISA alle keine Problem machen, solange die Adressen auf dem ISA ankommen.

Gru=C3=9F, Michael Karcher

u=20

Das nicht. Aber der Chipsatz routet die Original-VGA-Adressen unter umst=C3=A4nden nicht auf den ISA-Bus wenn er da kein VGA-BIOS findet.

ben,

F=C3=BCr einen Warmstart ist das auch in Ordnung. Kann es sein, dass das = BIOS irgendwo eine Kaltstarterkennung (also ob die Karte =C3=BCberhaupt reagie= rt) macht, und sie nur dann gegebenenfalls freischaltet?

r

Das hat keine Ahnung von ISA-Karten, kann aber im PCI-Chipsatz konfigurieren, was mit bestimmten I/O-Adressen zu passieren hat. Wenns ein Intel-Chipsatz ist: Besorg Dir das Datenblatt der South Bridge (PIIX3 bzw. PIIX4), die gibts im Internet.

Gru=C3=9F, Michael Karcher

Zumindest ist es wohl nicht unueblich. Mit IBM Tropic-Netzwerkkarten hatte man gerne dieses Problem: | If you have a sound card in your machine, and it sits at IO | 0x220, you may end up with a conflict with your token ring | adapter at 0xA20.

Das bedeutet auch Soundkarten konnten damals wohl auch nicht alle I/O-Adressen dekodieren.

Micha

Ja, das hab ich nun auch festgestellt. Sobald die AGP Karte läuft, kommt auf dem 0x3cx / 0x3dx Bereich nix mehr durch...

Gruss, Michael

Jupp, genau, 0x102 is der Port, an den ich nit komme aber bräuchte... Und damit is das Rätsel wohl auch schon gelöst: Hab heute mal ein FPGA Board an den ISA Bus gehangen und mal geschaut, welche Portzugriffe denn eigentlich durchkommen und welche nicht. Wirklich ein System konnt ich da jetzt nit erkennen. Prinzipiell geht alles von 0 - 0xffff durch, aber viele Bereiche dazwischen werden eben rausgefilter bzw. wohl schon vom PCI benutzt.

0xx3Cx und 0xx3Dx kommt z.B. nie an... Jedenfalls hab ich jetzt mal nen Bereich bei 0x1002, 0x12cx, 0x12dx, bzw. das gleiche nochmal bei 0x2... und 0x3... getestet und da kommt wohl alles durch. Dann muss ich mir wohl irgendwo nen 5V EEPROM oder sowas als Gluelogic besorgen mit 5 Eingangen und 7 Ausgängen... Ansonsten gibt das wohl doch noch nen TTL Grab ;) Danke euch allen jedenfalls für die Hilfe. Ich denke es liegt an dem Sleep Bit in diesem 0x102er Port. Der ganze Stress wegen einem Bit....

Gruss, Michael

Das klingt nach dem "subtractive decoce"-Modus. Alles, was nicht auf den PCI-Bus dekodiert wird, fliegt r=C3=BCber nach ISA.

Wenn das auch bei 0x4002, 0x42cx, 0x42dx durchgeht, ...

... tausche einfach A8 mit A12, A13 bzw. A14 f=C3=BCr die drei Karten. Be= i EEPROM oder so hast Du ja extralaufzeiten, die =C3=84rger machen k=C3=B6n= nten. Alle VGA-Zugriffe haben ja A8 gesetzt, und mit gesetztem A12, A13, A14 kommt sonst eigentlich niemand daher. =C3=9Cbrigens hast Du gl=C3=BCck, d= ass der Chipsatz den DMA-Controller (der zwischen 0x00 und 0x1F liegt) nicht auch nach 0x1000 bis 0x101F aliased...

Gru=C3=9F, Michael Karcher

Ist schon alleine wegen der Geschwindigkeitsunterschiede zwischen ISA und AGP sehr sinnvoll.

Gerrit

Naja, dann drüfte aber doch z.B. 0x8002 nicht rausgenommen werden. Zumindest in der Systemsteuerung hab ich da keinen belegten IO Port gefunden.

Das hab ich jetzt leider zu spät gelesen ;) Jetzt steckt ein GAL16V8 drin (15ns), den hatten se sogar hier beim Mükra. Hat dann immerhin noch den Vorteil, dass ich nacher beim RAM Zugriff in Software nix verdrehen muss. Wir ham heute mit drei Leuten 2 Stunden da gehockt um die DMF für die Logikfunktionen auszurechnen. War n heiden Spaß, wenn dann laufend jeder was anderes raus hatte oder sich alles bis auf einen Eingang rauskürzt und man kanns nit glauben... ;) Aber da merkt man erstmal, was einem beim FPGA Design son Synthesetool an Arbeit abnimmt ... Aber am Ende hat sichs wohl gelohnt, zumindest ein paar Register der ersten Karte konnte ich schonmal auslesen. Weiter gehts dann wohl erst morgen.

Ja, damit hatte ich eigentlich auch gerechnet, aber man darf ja auch mal Glück haben :)

Gruss, Michael

0xE216 aber nicht, weil das auf 0x0216 gespiegelt wäre und daher mit einer ISA-Karte, die dort liegt, kollidieren würde. Das PCI-Bios darf PCI-IO daher im Allgemeinen nur auf 0x400-0x4FF und die entsprechenden Vielfachen davon legen, weil 0x0000-0x00FF für Onboard-Bereiche reserviert war und nie auf den ISA-Bus gelangte.

Ja, das ist krank ...

Korrekt ("subtraktive Dekodierung"). Genau daher legt das BIOS normalerweise PCI-Karten nicht auf Adressen, wo eine ISA-Karte sein könnte.

cu Michael

Der Chipsatz weiß normalerweise nicht von VGA oder nicht-VGA - alles über

0x0100, wo sich keine PCI-Karte angesprochen fühlt, geht auf den ISA-Bus.

cu Michael

es =C3=BCber

SA-Bus. Die AGP-Bridge schreit aber bei den VGA-Ports "hier!", und daher geht das nicht auf den ISA-Bus. Und das kann das BIOS im Chipsatz abschalten. Ob es das abh=C3=A4ngig vom VGA-BIOS auf dem ISA-Bus tut, wei= =C3=9F ich allerdings nicht, k=C3=B6nnte es mir vorstellen.

Gru=C3=9F, Michael Karcher