[x86] Arbeitsspeicher für Periperie

[hell_bird]

hi,

Im Gerätemanager unter windows wird für ein gerät das angezeigt:
1) IRQ (klar)
2) DMA (nicht ganz klar)
3) E/A-bereich (klar)
4) Arbeitsspeicher (Was ist DAS?)

zu 2
Wenn ein Gerät einen DMA-Kanal hat, kann es dann auf den gesamten Arbeitspeicher zugreifen?

zu 4
Haben viele Geräte einen eigenen Bereich im Arbeitsspeicher?

[mapel110]

zu2) nö, nur auf freie bereiche ;)

zu4) naja, der treiber für die jeweiligen geräte ist im arbeitsspeicher.

[zeckensack]

1)Ein IRQ bietet dem Gerät die Möglichkeit, den Prozessor bei der Arbeit zu unterbrechen und den IRQ-Handler aufzurufen. Dieser kann zB neue Daten bereitstellen, wenn die 'alten' 'verbraucht' sind (zB: Soundkarte hat einen Puffer fertig abgespielt, und verlangt von ihrem Treiber, daß er wieder gefüllt wird).
2)DMA funktioniert über einen IRQ-ähnlichen Mechanismus (DRQ), wobei die Anfrage aber nicht an die Software geht, sondern an den Chipsatz. DMA geht AFAIK nur innerhalb von 64k-Fenstern. Der DMA-Controller selbst kann btw auch einen IRQ auslösen, wenn es nötig ist.

3)"I/O" läuft über die x86-Instruktionen "out" und "in". Das ist primär interessant für Geräte mit wenigen offenliegenden Ressourcen, die man noch übersichtlich über Register ansprechen kann (VGA-Steuerregister zB, nicht aber der Framebuffer). I/O-Ports haben ihren eigenen Addressraum, der vom Speichermanagement vollstänig abgetrennt ist.

4)Oberbegriff hiervon ist memory mapped IO. Das traditionelle Beispiel ist der VGA-Framebuffer, der fest auf der linearen Addresse 0xA000 anfängt. Der Unterschied zu 3 ist, daß der Prozessor Daten via "MOV" in diese Bereiche überträgt, als wäre es Systemspeicher. MMIO kann theoretisch klassisches IO ersetzen. Voodoo-Karten machen kein "I/O", sondern sind rein memory mapped.

Modernere Geräte mit arg viel 'mappable' Speicher können ihre Speicherfenster freier anordnen, und auch aus- und wieder anknipsen (wichtig um virtuelle Addressen und Segment-Deskriptoren einzusparen). Für diese Geschichte braucht man zudem OS-Support, weil Treiber, die MMU des Prozessors und der Chipsatz gefragt sind.

[Demirug]

Anmerkung zu 2:

Das mit den 64KB stimmt AFAIK nur begrennzt. Bei den alten DMA Controllern (8237A+8212) konnte man das zählregister durch zusammenschalten von 2 Kanälen das Zählregister von 16 auf 24 Bit erweitern. Da man aber auf den alten XT Kisten nur einen Kanal zur freien verfügung hatte. Die anderen 3 sind belegt (Memory Refresh, Speicher<->Floppy, Speicher<->Harddisk) war das Feature recht nutzloss.

Beim 286 (8737A) hat man dann mehr Kanäle und könnte diesen Trick nutzen. Da man aber den 8737A nie wirklich benutzt hat sondern das nachfolge Model 82C37A wurde der Trick überflüssig weil dieser einen erweiterten Modus hat welcher 24 Bit Address und Zählregister direkt unterstützt.

[hell_bird]

2) das verstehe ich noch nicht ganz:
Also das Gerät sendet einen DRQ an den Chipsatz und dann? woher weiß das gerät wohin es schreiben kann?

4) heißt das, dass wenn zum beispiel daten über den PCI-Bus gesendet werden, dass dann die Daten in den RAM geschrieben werden und der bus holt es sich dort ab? oder ist dieser Speicherbereich nur virtuell und die Daten die per mov dort ankommen gehen in wirklichkeit direkt durch den bus

Achja...wird der Video-RAM der Grafikkarte auch gemappt?

[GloomY]

Ich hab' auch ein paar Fragen:

Der Framebuffer ist je nach Auflösung und Farbtiefe unterschiedlich groß. Woher weiss man dann, wann der FB zu Ende ist und wieder ein "normaler" Adressbereich anfängt, der nicht auf den Framebuffer gemappt ist? Muss man beim schreiben in den Framebuffer nicht fürchterlich aufpasssen, dass man da nicht über den gemappten Speicherbereich hinausschreibt?

Werden beim "normalen" I/O einzelne Bits in die Register geschrieben oder wie muss man sich das vorstellen?

[Demirug]

Original geschrieben von hell_bird
2) das verstehe ich noch nicht ganz:
Also das Gerät sendet einen DRQ an den Chipsatz und dann? woher weiß das gerät wohin es schreiben kann?

Wenn ein DMA Tranfer gestartet wird übergibt man dabei die Quell und Zieladdresse sowie die Anzahl der Bytes die Kopiert werden sollen.

4) heißt das, dass wenn zum beispiel daten über den PCI-Bus gesendet werden, dass dann die Daten in den RAM geschrieben werden und der bus holt es sich dort ab? oder ist dieser Speicherbereich nur virtuell und die Daten die per mov dort ankommen gehen in wirklichkeit direkt durch den bus

Nein, bei memory mapped weiss das System das eine bestimmte Addresse jetzt nicht mehr auf den Hauptspeicher verweistt sondern auf ein Gerät und leitet die Lese und schreibzugriffe entsprechend um.

Achja...wird der Video-RAM der Grafikkarte auch gemappt?

Teilweise. Es war allerdings eher unter DOS üblich direkt im Speicher der Grafikkarte herumzuschreiben.

[Demirug]

Original geschrieben von GloomY
Ich hab' auch ein paar Fragen:

Der Framebuffer ist je nach Auflösung und Farbtiefe unterschiedlich groß. Woher weiss man dann, wann der FB zu Ende ist und wieder ein "normaler" Adressbereich anfängt, der nicht auf den Framebuffer gemappt ist? Muss man beim schreiben in den Framebuffer nicht fürchterlich aufpasssen, dass man da nicht über den gemappten Speicherbereich hinausschreibt?

Normalerweise schreibt man ja heute nicht mehr direkt in den Framebuffer. Desweiten ist wenn man man böse fummelt ein solcher Bereich nur für Treiber zugänglich. Schreibt dieser aber über die grezen hinaus schreibt man eben irgendwo hin und das kann zu allem führen.

Beim guten alten DOS war das aber alles ganz anders aber das ist eigentlich ein eigene Thema und dafür kann man Bücher füllen (was auch gemacht wurde).

Werden beim "normalen" I/O einzelne Bits in die Register geschrieben oder wie muss man sich das vorstellen?

Byte ist die kleinste Einheit. Letzten Endes sagt man der CPU eben das man einem bestimmten Port lesen oder schreiben will und die CPU leitet dann durch den Chipsatz diese Anfrage an das richtige Gerät weiter. Letzten Endes stellen die ganzen IO-Port auch nur eine Art zusätzlichen Speicher da der wie memory mapped eben mit der Hardware verbunden ist.

[mrdigital]

die Zeiten von hexA000 sind zum Glück lange vorbei (und wird nur noch beim booten verwendet)! Eine VGA Karte bekommt ein 64KB(!) grosses Speicherfenster im realen Speicher-Adressraum der CPU (eben an der Adresse A000). Das mit den 64k stammt ja noch aus 8086 Zeiten, wo eben der gesammte Adressraum gerade mal 1MB umfasste. Mittlerweile ist es so, dass eine GraKa ihren gesammten Speicher in den Adressraum der CPU einblenden kann (PCI, bzw. 4GB Adressraum sei dank) und der Grafikkartenspeicher dann aus Sicht der CPU wie Hauptspeicher aussieht. Dieses Speicherfenster liegt dann in der Regel am oberen Ende des Adressraumes. Andere PCI Devices machen das selbe mit ihren Pufferspeichern (IDE Controller, Netzwerkkarte, ...).

[Haarmann]

mrdigital

Beim Booten isses ned xA0000, sondern je nach je xB0000 oder xB8000 - das eine ist Textmodus in Farbe und das andere Texmodus in SW.

GloomY

Direkt in den Framebuffer schreiben war bei VGA noch recht einfach. Da waren alle Karten gleich (OK - Bitplanes sind auch ned der Hit). Richtig heiter wurds eigentlich erst bei allen Karten, die mehr den VGA beherrschten. Erst musstest mal irgendwie per IO Ports die Auflösung einstellen (Schauderhaft sowas - mein Notebook hatte nen GLD5440 oder sowas in der Art drinnen), danach gabs 2 Arten von Karten. Die einen mappten den Speicher linear wohin und die anderen durftest dann Speicherfenster für Fenster (immer 64KB) durchblättern und füttern. Erst danach kamen die Leute auf die VESA BIOS Extensions, womit man wieder ne einheitliche Lösung hatte. Ab V 2.0 konntest dann zufrieden bei allen Karten nen linearen FB nutzen. Ich hab so nen Würgemodus dann eben mal für ne Unit in Pascal gemacht (wobei mehr inline drin war aber egal), damit ich den Output auf entweder nen PS Laser, oder den Moni leiten konnte (Fraktale hatten wir damals) und mich ned mit C beschäftigen wollte, wo die das bereits vorgeproggt hatten an unserer Schule ;). Ich würds dementsprechend nach wie vor unter Horror definieren.
Deswegen waren fast alle Games nur auf 320*200*8Bit beschränkt, denn das war im xA0000 Fenster einblendbar und somit wars einfach zu proggen.

[Demirug]

Original geschrieben von Haarmann
mrdigital

Beim Booten isses ned xA0000, sondern je nach je xB0000 oder xB8000 - das eine ist Textmodus in Farbe und das andere Texmodus in SW.

Inzwischen gibt es auch einige System die im Grafikmodus hochfahren.

GloomY

Direkt in den Framebuffer schreiben war bei VGA noch recht einfach. Da waren alle Karten gleich (OK - Bitplanes sind auch ned der Hit). Richtig heiter wurds eigentlich erst bei allen Karten, die mehr den VGA beherrschten. Erst musstest mal irgendwie per IO Ports die Auflösung einstellen (Schauderhaft sowas - mein Notebook hatte nen GLD5440 oder sowas in der Art drinnen), danach gabs 2 Arten von Karten. Die einen mappten den Speicher linear wohin und die anderen durftest dann Speicherfenster für Fenster (immer 64KB) durchblättern und füttern. Erst danach kamen die Leute auf die VESA BIOS Extensions, womit man wieder ne einheitliche Lösung hatte. Ab V 2.0 konntest dann zufrieden bei allen Karten nen linearen FB nutzen. Ich hab so nen Würgemodus dann eben mal für ne Unit in Pascal gemacht (wobei mehr inline drin war aber egal), damit ich den Output auf entweder nen PS Laser, oder den Moni leiten konnte (Fraktale hatten wir damals) und mich ned mit C beschäftigen wollte, wo die das bereits vorgeproggt hatten an unserer Schule ;). Ich würds dementsprechend nach wie vor unter Horror definieren.
Deswegen waren fast alle Games nur auf 320*200*8Bit beschränkt, denn das war im xA0000 Fenster einblendbar und somit wars einfach zu proggen.

Erinnere mich nicht daran. Das Vergnügen eine VESA-fähige Grafik Unit für Pascal zu schreiben hatte ich auch mal. Der grösste Horror ohne VESA war es aber teilweise erst mal festzustellen welcher Chip den nun in dem Rechner arbeitet.

Das mit dem linearen FB hat aber wenn ich mich recht entsinne nur in Verbindung mit einem DOS-Extender funktioniert.

Ja Basis 320*200*8Bit war recht einfach. Etwas kompliziert war der von Spielen meist benutzte 320*200*8Bit*4Pages Modus am besten noch mit Softscrolling.

[Haarmann]

Demirug

"Inzwischen gibt es auch einige System die im Grafikmodus hochfahren."

Dann hätte man ja endlich mehr denn 640KB DOS Speicher ;).

Ging mir in etwa auch so mit dieser Sache. Notebook hatte eben nen Cirrus Logic (natürlich ne Rarität und ned ein normaler 2x) und die Desktops der Schule ne alte ATI Mach8. Ich liess also meine Sachen nur aufm Laptop laufen... spätestens beim Lesen der Mach8 Dokumentation, wird wohl jedem klar werden wieso.
Ich brauchte so nen komplexen Modus nie (320*200 mit mehr als einer Ebene), da der Cirrus, im Gegensatz zum Oak oder Tritent, schon schnell genug war um beim Retrace gerade nen 64er Segment vom RAM, wo ich das Bild aufgebaut hab, in die Karte zu schieben. Und da ich ein fauler Zeitgenosse war und bin, machte ich mir die Arbeit nicht gerne schwerer denn nötig.

LFB kannst auch per Inline commands nutzen - Präfixe lassen grüssen. Man muss aber wissen, wo man ihn sucht. Ohne VESA wär das wohl auch zum Horror geworden.
Unter DOS konntest auch einfach speicher holen - viele Programme liefen ja nicht gleichzeitig mit Dir...

Softscrolling brauchte ich zum Glück nie. Ich stelle mirs mental schon vor, wie man der Graka per Ports dieses Fensterchen malträtieren durfte, bis das lief. Ich kann ja in meinem "historischen" VGA Buch mal nachschlagen...