C porgrammierung unter DOS

Du willst unter DOS? (nicht Windows?) noch eine Karte ansprechen?

Was für eine Karte ist es denn? Eigenentwicklung oder gibt es da noch 
"andere" Treiber?

Greifst du nur über IO-Register zu oder sind da noch memory mapped 
Bereiche möglicherweise in höheren (>1MB) Regionen.

Ehrlich gesagt würde ich sowas vermeiden, wenn du wirklich nur den 
Hintergrund hast den du angibst. Wenn es eine Messkarte ist, schau mal 
bei Labview nach.
Der Zugriff auf die Karte wird zumindest wesentlich einfacher, auch vom 
Debugging wenn Linux oder ein anderes 32Bit Betreibssystem vorhanden 
ist.
Dos ist ein 16 Bit Betriebssystem und man sollte sich sehr klar über die 
Auswirkungen sein, wenn man 32 Bit Zugriff braucht und was dein 
C-Compiler macht.

Also hier mal ein kleiner Einstieg:
Ralph Browns Interrupt list
Beschreibt Int 1A ,AX=B102 Find PCI Device
Damit kannst du erstmal suchen wo sich die PCI Karte eingeordnet hat. 
(ja die kann unterschiedliche Adressen haben)
Nimm die Hilfe des BIOS dafür in Anspruch, versuche nicht selbst über 
den PCI-Bus zu suchen. Einige PCI-Konfigurationsregister sind nur durch 
32Bit Portzugriffe erreichbar. Bei 16Bit Portzugriffe werden sie nicht 
angesprochen.
Du solltest also wissen WAS dein C-Compiler macht. (Assembler ist da 
nicht schlecht)
Wenn du über 1MB rauswillst, solltest du wissen was der Protected Mode 
ist und in welchem Modus du bist. Da du nicht alles andere killen 
willst, ist die Zuhilfenahme von DPMI oder VCPI sehr angebracht. Das 
kann alles sehr umständlich werden. "PC-Intern" ist da ein guter 
Einstieg.

Wenn es sich nur um eine IO-Karte handelt versuche die PORT Adresse 
rauszubekommen (Find PCI Device)/ oder teste halt alle Adressen an die 
sich die Karte im IO-Bereich mappt und probiere mal in DOS mit "debug"
und "i" und "o" Befehlen, ob du die Karte ansprechen kannst.
Wenn ja, wird es sehr einfach in C  (outb/outw) und sollte schaffbar 
sein.

Besorg die ein altes TURBO C von Borland (so um 1990). Sehr einfach zu 
bedienen mit Hilfe-Funktion und Einzelschrittablauf, +++. Und dazu 
natürlich den K&R.

Es gab da mal ein CT-Projekt für einen Eprom-Brenner. Die Software für 
das Gerät gab es als Sorce-Code dazu. Das dürfte als Einstieg recht 
hilfreich sein um zu sehen, wie man die Hardware anspricht interrupts 
auslöst, abfängt ect.

Mal was Ketzerisches OT:

Diplomarbeit hat mit Studium zu tun, Studium mit LERNEN. Was willst Du 
denn lernen bei solch einer Diplomarbeit? Dein zukünftiger potentieller 
Arbeitgeber lacht Dir doch ins Gesicht, wenn Du über Deine Diplomarbeit 
sprichts: C unter DOS, das ist ja der Knaller!

Wer bietet denn solche Diplomarbeiten an? Die Arbeit selbst soll auf 
Tontäfelchen dokumentiert werden?

Such Dir ne vernünftige Diplomarbeit, was Du machst ist 
Zeitverschwendung.

Ja
Cheers
Detlef

> Such Dir ne vernünftige Diplomarbeit, was Du machst ist
> Zeitverschwendung.

Das sehe ich garnicht so. Schließlich soll Hardware verwurschtelt und 
nicht die Abartigkeiten von Windows/XP ergründet werden.
Andernfalls könnte man die Forderung aufstellen, alle kleinen µPs 
generell nur noch mit einem Multitasking-Betriebssystem zu 
programmieren.
Unter DOS kommt man erheblich besser an die Hardware heran. Wozu also 
aus dem Hügel ein Gebirge machen?

Ihr habt natürlich recht. Ein richtiger Programmierer beginnt mit XP und 
schreibt sich seine IO.DLL ebenmal schnell selber. Und wer das auf 
Anhieb nicht bringt, soll auch keine Freude bei der Arbeit haben. 
Erfolgserlebnisse, wozu das denn ?
Habt Ihr auch so angefangen ? 1. Fahrstunde auf der Autobahn ?
Um Hardware zu testen, braucht man kein Windows. Wozu also die 
übertriebenen Ansprüche ?

Das Ding ist zum Testen des PCI-Bus... ratet mal wie weit Windows beim 
booten kommt wenn da ein Fehler ist :D
Wollt ihr bei jedem neuen Mainboard erstmal Windows installieren um dann 
den Bus zu testen. Bitte in Zukunft erst in den Protected Mode 
umschalten bevor ihr groß mit dem Denken anfangt. Da hat man gleich viel 
mehr Platz fürs Denken.

Freedos ist auch nur 16bit.

Zum Thema: Für 32bit gibt es den DOS-Extender DOS32A
http://dos32a.narechk.net/index_en.html

Open Watcom scheint der dazu passende Compiler zu sein:
http://www.openwatcom.com/index.php/Main_Page

> Zum Thema: Für 32bit gibt es den DOS-Extender DOS32A
> Open Watcom scheint der dazu passende Compiler zu sein:

Ich habe irgendwo noch eine kommerzielle Version des alten Watcom. 
Damals hieß der DOS-Extender allerdings DOS4GW. Der Compiler war damals 
bei Spieleentwicklern sehr beliebt.

> das ganze ist durchaus eine moderne diplomarbeit in einem modernen
> indurstriebetrieb;
> zu dem zeitpunkt wo getestet wird gibt es noch kein windows
> (produktionstechnischer hintergrund), also ist es auch keine
> alternative;

Wie wäre es mit einem minimalistischen Linux, z.B. von einer Diskette 
bzw. einer Live-CD? Da braucht man dann auch keine Installation, aber 
man muss nicht gleich alles zu Fuß machen.

Ich weiss dass es total überholt ist, aber zu der Zeit, als ich dieses 
Teil aufgebaut habe, ist man zur Gewinnung solcher Informationen in die 
Bibliothek gegangen und hat sich die gebundenen CT-Jahrgänge rausgeben 
lassen, in denen man dann die benötigten Informationen rausgesucht und 
kopiert hat.
Soweit ich weiss gibt es Bibliotheken immernoch nur die Suche ist 
inzwischen einfacher. Man blättert nicht mehr stundenlang nach den 
Informationen, man sucht sie im Artikelindex und schlägt dann gezielt 
das Gesuchte Jahrgangsheft auf.

Warum beantwortest du nicht mal die eigentlich relevante Frage:
Musst du auf Bereiche jenseits von 1MB für die Karte zugreifen?

Wenn nein, viel Spass mit deinem DOS auch wenn ich das recht angestaubt 
finde.
Ist wahrscheinlcih die schnellste Lösung, auch wenn Linux da nicht so 
sehr hinterherhinkt.

Wenn ja, würde ich mir das nochmal genau überlegen. DPMI, Protected Mode 
usw.
braucht doch einiges an Zeit um sich da einzuarbeiten. Da würde ich auch 
eher zu Linux neigen, das Dir da einiges abnimmt, nämlich den 
Höhenunterschied zwischen "Hügel und Gebirge". Den darfst du nämlich in 
Dos zum grossen Teil selbst Programmieren.

Das Testen von jedem Einzelnen PIN am PCI Bus kannst du vergessen.
Wenn da was falsch ist fährt höchstwahrscheinlich weder DOS noch 
irgendwas anderes hoch.
Bleibt der Funktionstest der Karte über die Kartenregister egal ob nun 
IO oder memorymapped.

Lass dich vorerst nicht von Linux, 32-Bit und sowas irremachen.
DOS ist durchaus noch üblich in der embedded-Welt der Industrie.
Mit Linux werden sich noch einige Entwickler wundern die naiv Linux in 
ihre Produkte gebracht haben (wenn es um GPL geht und man soetwas der 
Geschäftführung klarmachen muss).
Ich kenne nicht nur aus meinem Arbeitsbereich genügend Beispiele für DOS 
auf PC104 Systemen, vor allem in Systemen wo es auf funktionale 
Sicherheit ankommt.

Deine Diplomarbeit hat auf jedenfall ein guten Lerneffekt in Richtung 
Embedded-Entwicklung und/oder Treiberentwicklung für eigene Hardware.

Aber mal zum Thema:

auch wenn das Buch schon von Wolfram gennannt wurde:
Versuche irgendwo "PC-Intern Systemprogrammierung" von Data-Becker zu 
bekommen. Da ist alles erläutert was du brauchst.

>auch wenn das Buch schon von Wolfram gennannt wurde:
>Versuche irgendwo "PC-Intern Systemprogrammierung" von Data-Becker zu
<bekommen. Da ist alles erläutert was du brauchst.
Version 3.0 ist am Empfehlenswertesten allerdings fehlt DPMI 
Programmierung unter C mit Dosextender. Aber zumindest bekommst du eine 
Ahnung welcher Berg da auf dich zukommt.

Jaja die gute alte "PC-Intern" Bibel.
Bei mir steht immer noch die 2.0 im Regal :)
Das Ding war wirklich sein Geld wert. Letzte Version war meines Wissens 
5.

CU Frank

PS: Der Autor war übrigens Michael Tischer.

den Stecker zum PCI Bus oder irgendeine externe Schnittstelle?

>zurück zu dem test selbs: ich setzte einen funktionierenden bus voraus,
>der test soll den stecker validieren
das ist ein Widerspruch in sich, wenn der PCIbusanschluss fehlerhaft 
ist, hast du keinen funktionierenden Bus! Das knallt wahrscheinlich 
schon bei der Evaluierung der Karte durch das BIOS. Da kommt es 
eventuell erst gar nicht bis zum Dos oder anderen Sachen. Außerdem 
könntest du sowieso nicht alle PINS evaluieren mit einem DOS-Programm. 
Wenn du die Karte an ihrer Adresse findest kannst du eigentlich davon 
ausgehen das die PINS i.o sind.

>also der bus auf dem baseboard selbst geht
Wenn die erste defekte Karte drin war wär ich mir da nicht mehr so 
sicher.
Das einzige was du tun kannst, ist: Teste die Funktionalität der Karte 
in ihrer Anwendung. Wenn alles fkt. ist sie OK. sonst nicht.
Ich glaube nicht das die spätere Anwendung unter DOS läuft.
Nebenbei kommt man da auch Treiberfehlern auf die Spur.
Das was du da mit den PIN's versuchst... da gibt es einen elektrischen 
Leitungstest und einen JTAG/Boundaryscan für sowas.

Das mindeste wäre ein Hot-plug-fähiger PCI-Test-Adapter , wie der hier:
http://www.quancom.de/quancom/quancom01.nsf/home_prod_eng.htm?OpenFrameSet&Frame=unten&Src=http://www.quancom.de/qprod01/eng/produkte/uebersicht/bus_extender.htm
sonst muß man für jede neue PCI-Karte wieder neu booten.

Das ist ein deutscher Hersteller, dt. Beschreibung hier:
http://www.quancom.de/qprod01/deu/pb/pci_ext64.htm

Es geht darum, den PCI-Slot zu testen, nicht die Karte...

Ja dann...
nach genauerem Durchlesen seh ichs auch
Für wieviele Steckzyklen ist der PCI-Stecker spezifiziert ? Schon die 
96poligen DIN-Leisten VG... haben nur 200-300 Zyklen, und hier ist eine 
Seite nur eine vergoldete Platine, das sollte man nicht zu oft stecken.