Port-Adressen

Hallo in meinem Buch befindet sich folgendes Codebeispiel bzw. folgende Erläuterung zu den Befehlen in und out:

;Der Tastaturpuffer hat die Portadresse 60h
in al,60h 
;Lies ein Byte vom E/A-Port mit der Adresse 60h (Tastaturpuffer) in das AL-Register.

Die Fragen lauten jetzt: 1. Wo bekomme ich eine (vollständige) Auflistung dieser Port-Adressen her und 2. Lassen sich diese Adressen auf meinen handelsüblichen Rechner anwenden bzw. sind diese Ports genormt?

Nobuo T

Zu 1.:
Nirgendwo. Die Zuordnung von Speicher- und E/A-Adressen haengt von der Hardwarekonfiguration deines PCs ab. Das beantwortet im Prinzip auch gleich
Zu 2.:
Jein. Frueher, als noch alles besser war (tm), und PCs und das Gebastel daran noch echten Geeks (mit viel Geld) und Profis vorbehalten und Plug&Play noch ferne Zukunftsmusik war, dh. alles schoen statisch, hat IBM vieles standardisiert. Siehe z.B. AT oder PS/2... Da wurde dann ein bestimmter Baustein fuer die Tastatur benutzt, der auf einem festgelegten Port gelauscht hat, da gab es VGA als festen Standard mit festgelegten Adressen, uvm.
Mit steigender Popularitaet und zunehmender Zerfrickelung sowie aufkommenden Standards wie PnP, PCI, ACPI, etc. wurden diese Standards jedoch zunehmend nur noch aus Gruenden der Rueckwaertskompatibilitaet simuliert. Dh. die entsprechende Hardware existiert in der Form praktisch gar nicht mehr.
Um eine Zusammenarbeit mit dem BIOS und die Implementierung speziell auf Hardware zugeschnittener Treiber kommst du oft nicht mehr herum, wenn du direkt auf Hardwareebene arbeiten willst.
Da hilft dir dann das Datenblatt der entsprechenden Hardware eher weiter als irgendwelche Monster-Portlisten.

Hallo! Danke für die Antwort!

Mir stellt sich dann jetzt aber die Frage, wie die Buchstaben auf den Bildschirm kommen, sobald ich den Rechner einschalte bzw. wie z.B. Windows es hinbekommt, daß der Pixel oben links die entsprechende Farbe erhält, sobald es geladen wurde, wenn das alles gar nicht hardwareunabhängig zu bestimmen ist.
Ich mein, irgendwie müssen sich die ganzen Hersteller doch untereinander abstimmen und irgendwie muß es doch prinzipiell möglich sein, daß meine Netzwerkkarte den Wert 00FF ausgibt. Wenn da jeder sein eigenes Süppchen kocht, funktioniert das doch alles vorne und hinten nicht!?

Nobuo T

Was meinst du, warum es allein tausend verschiedene Geraetetreiber von noch einmal so vielen verschiedenen Herstellern z.B. fuer T-100-Netzwerkkarten gibt? Kleiner Tipp: Das liegt nicht daran, dass die ersten Treiberversionen so verbuggt waren oder sich der ganze Spass so unglaublich toll weiter entwickelt hat. Die Kommunikationsdetails wie E/A-Adressen, oder was genau dort hineinzuschreiben ist, sind einfach nicht uebergreifend standardisiert.

Der PC bringt rudimentaere Treiber in einer Firmware mit, die beim Einschalten von einem ROM-Chip geladen wird. Dabei haelt praktisch jede Hardware, die vor dem Laden des Betriebssystems mit seinen eigenen Geraetetreibern benutzt werden kann, einen eigenen Chip mit Treiber-Firmware.
Im ROM auf dem Mainboard stecken dabei idR. Treiber fuer das Chipset (Enthaelt Hardware fuer USB, verschiedene Erweiterungsbusse, RAM, Netzwerk (wenn OnBoard), Tastatur, etc.), ein BIOS/EFI-Programm fuer Selbsttests, Hardwareinitialisierungen/Nachladen weiterer Treiber aus weiteren ROM Chips, zum Laden eines Betriebssystems von einem Datentraeger und ein Setup-Programm zum Veraendern von Hardwareeinstellungen.
Auf Grafikkarten sitzt dann z.B. ein weiterer ROM-Chip, der speziell an die Grafikkarte angepasste Hardwaretreiber enthaelt, die das BIOS/EFI-Programm auf dem Mainboard benutzen kann, um direkt beim Einschalten Grafik oder Schrift auf den Bildschirm zu bringen.
Wenn du in Windows keine Geraetetreiber z.B. fuer die Grafikkarte installierst, greift es AFAIK auch einfach auf diese in der Grafikkarte abgelegten Treiberprogramme zurueck, um etwas auf den Bildschirm zu bringen.
Das Softwareinterface dieser Treiber ist natuerlich standardisiert.
Das in Windows und anderen Systemen verwendete ebenso. Nicht jedoch die og. Details der Hardwareansteuerung.

Die Belegung der Ports ist sicherlich standardisiert: vieleicht nicht durch behördliche/öffentliche Stellen, aber sicherlich durch Konsortien entsprechender Hersteller. Diese müssen im Übrigen nicht immer öffentlich sein. Auch könnte es so sein, das man z.B. bei Intel ein ‚Port‘ bzw ‚Portbereich‘ anfragen/kaufen kann - dies währe dann Standartisiert

BTW: In den Grafikkarten gibt es keine Treiberprogramme

Nobuo T

guy³ schrieb:

Die Belegung der Ports ist sicherlich standardisiert: vieleicht nicht durch behördliche/öffentliche Stellen, aber sicherlich durch Konsortien entsprechender Hersteller.

Alle? Definitiv nicht. Ansonsten: Quelle bitte.

guy³ schrieb:

Diese müssen im Übrigen nicht immer öffentlich sein. Auch könnte es so sein, das man z.B. bei Intel ein ‚Port‘ bzw ‚Portbereich‘ anfragen/kaufen kann - dies währe dann Standartisiert

Richtig und richtig, aber dann wie gesagt eben nur fuer bestimmte Chipserien von Intel (bzw. dem jeweiligen Hersteller der Hardware) und nicht allgemeingueltig.

guy³ schrieb:

BTW: In den Grafikkarten gibt es keine Treiberprogramme

Ach? Und was ist mit dem hier (zB.)?

nachtfeuer

Naja, es gibt zumindest Normung hinsichtlich des Betriebssystems. Der Kernel darf in und out benutzen, Usermode Proggis nicht, und das hat auch seinen guten Grund.

Wie Nobuo schon schreibt...viele zugrundeliegende lowlevel-Funktionen(auch Highlevel) in Windows z.B. kann man sich als Workarounds und undokumentiertes Gedöns vorstellen.
Also ein richtig gutes Basisfundament für Transparenz und KnowHow Didaktik...
Das gleiche gilt für Linux, viele Workarounds, viele Funktionen sind gar nicht vorhanden, die viele Vorhandenden Funkionen oft nur spärlich dokumentiert. KnowHowfragmetierung in vollendeter Kunstform, durch diese Art von Codedschungel kann man sich nicht ohne professionellen Führer, unerschrockenes und erfahrenes Abenteuerteam und guter Kommunikationsverbindung zur Basis wagen...
(aber man kann sich zumindest mal anschauen, was bei dev/ so alles herumliegt).

Macht aber oft nicht viel Sinn, da beispielsweise für das Ansprechen/manipulieren der Tastatur Treiber und verschiedene Funktionen des Betriebssystems vorliegen. Auch unter DOS war es einfacher, Interrupts zu benutzen, als Datenblätter und Kommunikationsstandards und -protokolle zu studieren. Statt Interrupts benutzt man jetzt eben Systemfunktioncalls und Bibliotheken wie Directx, welche letztlich auch den hier gesuchten "Standard" darstellen.

Linux ist für hardwarenahe Geschichten vorzuziehen, da letztlich einfacher, dokumentierter und flexibler und so näher dran - sag ich mal so.
Und im Gegensatz zu Windows gibt es bei Linux mehr Systeme zur Auswahl, die man auf die eigenen Bedürfnise zurechtfrickeln kann (falls sie nicht eh schon gut passen).

Wenn man jetzt noch näher heran will, etwa weil man ein eigenes Betriebssystem schreiben möchte, dann muß man sich näher mit den Peripheriebausteinen und den Bausteinen der Schnittstelle befassen - was letztlich heißt, Entwicklungsboards für Mikrokontroller/Usb und Co und Protokolle für Schittstellen usw. besorgen. Gerade Usb ist vielversprechend, aber auch ganz schön umfangreich. Man möchte aber auch nicht unbedingt das Rad neu erfinden, also ist auch Reversing und weiteres Informieren über dokumentiertes/undokumentiertes Material angesagt.
(das hat aber Nobuo oben auch schon gepostet)

Bei Linux gibt es eine gute Möglichkeit, Assemblermathe zu plotten, über den Framebuffer:

siehe:
https://secure.wikimedia.org/wikipedia/de/wiki/Framebuffer
http://asm.sourceforge.net/articles/fb.html
http://net.pku.edu.cn/~course/cs201/2004/Assembly/asmutils-0.17/src/mandelbrot.asm
http://asm.sourceforge.net/articles/modex.html

und allgemein:
http://www.weblearn.hs-bremen.de/risse/RST/WS06/Grafikkarten-Programmierung/Ausarbeitung.pdf
http://www-vs.informatik.uni-ulm.de/dept/staff/weggerle/pubs/Hardwarenahe_Analyse_von_Grafikfunktionen_und_Shadern.pdf

Falls man selber per IN und OUT die Graka und den anderen Kram programmieren möchte, braucht man auch das entsprechende Betriebsystem dafür, z.B. Dos (+Extender), und die dazu passende Hardware. Aber man tut gut daran, erstmal die vorhandenen Schnittstellen dieser Tage (Cuda, OpenCl) auszunutzen.