Hypercell ein ] Hypercell aus ] Zeige Navigation ] Verstecke Navigation ]
c++.net  
   

Die mobilen Seiten von c++.net:
https://m.c-plusplus.net

  
C++ Forum :: Projekt: OS-Development  ::  Eigenes OS?     Zeige alle Beiträge auf einer Seite Auf Beitrag antworten
Autor Nachricht
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 21:03:47 13.03.2009   Titel:   Eigenes OS?            Zitieren

Mich würde mal interessieren, wer alleine oder mit anderen an einem eigenen OS entwickelt, zu welchem Zweck und in welcher Sprache (ASS, C oder C++)? Links?

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 12:00:36 24.01.2015, insgesamt 1-mal bearbeitet
Kernel-Developer
Unregistrierter




Beitrag Kernel-Developer Unregistrierter 21:21:54 13.03.2009   Titel:   Re: Eigenes OS?            Zitieren

Erhard Henkes schrieb:
Mich würde mal interessieren, wer alleine oder mit anderen an einem eigenen OS entwickelt, zu welchem Zweck und in welcher Sprache (ASS, C oder C++)? Links?

Ich entwickel mit ein paar anderen zusammen ein eigenes OS, finden kannst du es hier. Ist in C geschrieben und der Zweck ist denke ich klar :???:
Kóyaánasqatsi
Mitglied

Benutzerprofil
Anmeldungsdatum: 03.10.2008
Beiträge: 3172
Beitrag Kóyaánasqatsi Mitglied 09:52:05 14.03.2009   Titel:              Zitieren

Hallo

Habe vor graumer Zeit mal angefangen, aber schon nach dem Multiboot Kernelloader aufgehört. War in C und Assembler...

Mfg.
way

_________________
createch-web www.wie-nehme-ich-zu.de
abc.w
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2008
Beiträge: 1366
Beitrag abc.w Mitglied 12:17:48 14.03.2009   Titel:   Re: Eigenes OS?            Zitieren

Erhard Henkes schrieb:
zu welchem Zweck und in welcher Sprache (ASS, C oder C++)?

Ich habe mich auch mal mit einem eigenen OS in Assembler beschäftigt zwecks endlich mal den Protected Mode der Intel CPUs zu verstehen. Habe aber diesbezüglich versagt und daraus wurde nichts. Hm, vertane Lebenszeit... hätte lieber in was anderes und sinnvolleres investieren sollen.
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 15:19:50 14.03.2009   Titel:              Zitieren

Alleine ist sicher schwierig. Zu zweit oder dritt macht das mehr Sinn. Wichtig ist, dass man alles genau dokumentiert, wenn man zwischenzeitlich pausieren will/muss.

Ich denke, dass es auch teilweise an der mangelnden Erklärung der Vorbilder und an langatmigen Theorie-Erklärungen liegt, wenn es in der Praxis schief geht. Beim Einstieg haben die wenigsten den kompletten Durchstieg durch alle Facetten. Also ist es wichtig, die Dinge detailliert zu erklären und vor allem auch Anregungen für eigene Experimente zu geben, damit die Dinge wirklich "glasklar" werden.

Bevor man bei einem Hobby- oder Experimental-OS auf den Protected Mode umschaltet, sollte man erst den Real Mode didaktisch komplett ausloten, damit der PM nicht zur Belastung wird, sondern zur Bereicherung.

Ich habe mir vorgenommen, didaktisch den Einstieg in die OS-Entwicklung zu erleichtern, denn es hilft, sowohl Assembler, C und auch die Hardware richtig zu verstehen, zumindest dann, wenn man dies möchte. Daher bitte ich euch mit zu helfen.

Hier die Seite:
http://www.henkessoft.de/OS_Dev/OS_Dev1.htm

Bitte um konstruktive Kommentare/Ideen. Mir ist volles Verständnis und ein stufenweiser und leichter Einstieg wichtig. Kein blitzschnelles Voranhuschen einer Elite. Die brauchen solche Seiten nicht, sondern nur Datenblätter, Tabellen, ....

Wenn jemand mitmachen möchte, gerne. Bitte hier oder per mail. Im Kopf der Seite ist Platz für viele Namen. Hauptziel: Spaß und wirkliches Verständnis vermitteln. Ich möchte auch niemanden zwingen, zunächst Linux zu installieren, um zu beginnen.

Bisher haben sich für mich gvim [EDIT: notepad++ bringt mehr Komfort], nasm und bochs als wirklich brauchbar heraus kristallisiert. partcopy.exe kann sicher durch etwas anderes ersetzt werden. Wichtig ist, dass sich niemand die Festplatten "zerschießt".

Ich habe eine Floppy Disk zum Booten verwendet. Heutige PCs haben dies nicht mehr ohne weiteres. Viele haben aber noch alte PCs mit Floppy Disk und wollen wirklich "physisch booten". Didaktisch muss das einfach sein.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 00:52:55 11.07.2009, insgesamt 1-mal bearbeitet
asdca
Unregistrierter




Beitrag asdca Unregistrierter 17:07:06 14.03.2009   Titel:              Zitieren

Euer Problem ist, daß ihr immer nur in x86 denkt. x86 ist nicht unbedingt die optimale Plattform für einen Einsteiger mit dem ganzen 20 Jahre alten Schrott wie Realmode, Callgates, Segmentregistern und dem ganzen anderen Mist. Ich verstehe nicht, warum immer alle Welt sowas immer unbedingt für die x86 Architektur machen muss. Die ist nicht nur hässlich, sondern auch klobig und extrem Noobunfreundlich.
asdca
Unregistrierter




Beitrag asdca Unregistrierter 17:08:43 14.03.2009   Titel:              Zitieren

Gleicher Flame richtet sich natürlich auch an div. Buchautoren.
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 17:20:04 14.03.2009   Titel:              Zitieren

asdca schrieb:
Euer Problem ist, daß ihr immer nur in x86 denkt. x86 ist nicht unbedingt die optimale Plattform für einen Einsteiger mit dem ganzen 20 Jahre alten Schrott wie Realmode, Callgates, Segmentregistern und dem ganzen anderen Mist. Ich verstehe nicht, warum immer alle Welt sowas immer unbedingt für die x86 Architektur machen muss. Die ist nicht nur hässlich, sondern auch klobig und extrem Noobunfreundlich.

da bin ich voll bei dir. erhard: mach was für 'ne ARM-plattform. ich wette es gibt mehr ARM-basierte systeme auf der welt als PC(x86)-kisten.
:)
Verärgerter Gast
Unregistrierter




Beitrag Verärgerter Gast Unregistrierter 17:48:15 14.03.2009   Titel:              Zitieren

+fricky schrieb:
asdca schrieb:
Euer Problem ist, daß ihr immer nur in x86 denkt. x86 ist nicht unbedingt die optimale Plattform für einen Einsteiger mit dem ganzen 20 Jahre alten Schrott wie Realmode, Callgates, Segmentregistern und dem ganzen anderen Mist. Ich verstehe nicht, warum immer alle Welt sowas immer unbedingt für die x86 Architektur machen muss. Die ist nicht nur hässlich, sondern auch klobig und extrem Noobunfreundlich.

da bin ich voll bei dir. erhard: mach was für 'ne ARM-plattform. ich wette es gibt mehr ARM-basierte systeme auf der welt als PC(x86)-kisten.
:)

Ich könnt kotzen :mad:, da +fricky recht hat :D
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 18:16:27 14.03.2009   Titel:              Zitieren

Verärgerter Gast schrieb:

Ich könnt kotzen :mad:, da +fricky recht hat :D

wie jetzt?!?
ach ja, erhard: wie wär's mit 'nem OS für nintendo-DS? die plattform ist weit verbreitet, einigermaßen gut 'reverse engineered' und es gibt, meines wissens, bisher nur ein hobbyisten-OS dafür.
:)
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 19:15:16 14.03.2009   Titel:              Zitieren

ARM, Nintendo DS etc. ist sicher sehr interessant, leider hat nicht jeder so etwas greifbar, vom Programmieren mal abgesehen. Die 80i86 Historie hat uns wirklich einen monströsen Wirrwarr als Kellerfundament hinterlassen. Da habt ihr völlig Recht. Aber umso größer die didaktische Herausforderung. ;)

Ich versuche die Reihenfolge:

1) Werkzeuge bereit stellen
2) Praktisches Arbeiten
3) Notwendiges Backgroundwissen praxisnah vermitteln
4) Experimentieren, um Auswirkungen zu zeigen

einzuhalten.

Wenn man einsteigt, benötigt man z.B. zunächst nur das Wissen über CPU, Register und Interrupts. Das findet man heute alles ordentlich bei wiki ... :)

Das Mittel, das viele an der Hand haben, die am Internet hängen und Tutorials lesen, ist nun mal der 80i86 PC mit MS Windows.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 22:07:54 14.03.2009   Titel:              Zitieren

Erhard Henkes schrieb:

Das Mittel, das viele an der Hand haben, die am Internet hängen und Tutorials lesen, ist nun mal der 80i86 PC mit MS Windows.

klar, aber du nutzt doch sowieso 'nen simulator (bochs) für deine experimente. dann könntest du auch 'nen simulator für eine interessante plattform verwenden, und nicht für dieses stokelige x86-gedöns.
:)
''
Unregistrierter




Beitrag '' Unregistrierter 22:27:21 14.03.2009   Titel:              Zitieren

das 'monströse Wirrwarr' machts aber gerade interessant.
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 22:58:57 14.03.2009   Titel:              Zitieren

@+fricky: Gegen dieses Argument kann man nur einwenden, dass nach der Emulation auch noch die echte Anwendung kommen sollte. Bei ARM fallen mir sofort z.B. Roboter und sonstige Elektronikanwendungen ein, ein schönes Thema, aber man kann nicht alles gleichzeitig machen.
@": Ich denke, dass einige User, die mit dem PC unter MS Windows arbeiten, vielleicht einfach mal Lust haben, ein OS zum Ticken zu bringen. Das Entscheidende dabei ist die praktische Beherrschung des Themas, denn nur dann hat man die Kraft und Leidenschaft zum Experimentieren und Umsetzen von Ideen. Das ist der entscheidende Punkt, wo viele didaktische Ansätze stecken bleiben.

Im ersten praktischen Schritt habe ich den Mini-Kernel komplett bootbar in Sektor 1 geschrieben.

Im nächsten Schritt wird ein Bootloader in Sektor 1 vorgeschaltet, der den gleichen Mini-Kernel nun aus Sektor 2 lädt (BIOS INT für Floppy Disk) und im Speicher anspringt. Im Kernel wird dann lediglich die Boot-Signatur entfernt und die Segment-Adresse geändert.

Das ist technisch für den Ersteller einfach durchführbar:

nasm boot.asm -f bin -o boot.bin
nasm kernel.asm -f bin -o kernel.bin
copy /b boot.bin + kernel.bin myOS.img
partcopy myOS.img 0 400 -f0

siehe: http://www.henkessoft.de/OS_Dev/OS_Dev1.htm

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 02:16:44 15.03.2009, insgesamt 4-mal bearbeitet
abc.w
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2008
Beiträge: 1366
Beitrag abc.w Mitglied 12:14:13 15.03.2009   Titel:              Zitieren

Zitat:
Bitte denken Sie daran, sich für solche Aufgaben entsprechende bat-Dateien zu schreiben, wenn Sie experimentieren.

Habe das Tutorial mal kurz überflogen und das ist der Satz, der mich persönlich "stört". Ich bin nämlich für den Einsatz von Makefiles. Man kann nämlich die Makefiles wie gewöhnliche Batch-Dateien schreiben mit dem Vorteil der "automatischen" Fehlerbehandlung:
Code:
all:
    nasm boot.asm -f bin -o boot.bin
    nasm kernel.asm -f bin -o kernel.bin
    copy /b boot.bin + kernel.bin myOS.img
    partcopy myOS.img 0 400 -f0

Sollte in der einen oder anderen Zeile ein Fehler auftreten, wird Makeprozess sofort abgebrochen... Bei Batch-Dateien müsste man mit unübersichtlichen goto's arbeiten, was dann schnell unübersichtlich wird.
/rant/
Mitglied

Benutzerprofil
Anmeldungsdatum: 18.10.2008
Beiträge: 1846
Beitrag /rant/ Mitglied 14:28:44 15.03.2009   Titel:              Zitieren

Ich habe ganz früher mal einige kleinere Dinge gebaut: Bootloader + Kommandozeile + FAT-Dateisystem + Interpreter (Sah aus wie Assembler, wurde aber interpretiert...). Alles nur 16-bit Assembler mit rawwrite auf Diskette und dann gebootet. Für 32-bit und PMode hatte ich weder die Zeit, noch die Nerven. Die Dokumentation hat mir seinerzeit schon gereicht um zu wissen, dass ich es gar nicht erst versuchen sollte. Warum ich das gemacht habe? Aus Eigeninteresse, und um etwas neues zu lernen. Inzwischen würde ich mich sehr für 64-bit OS-development interessieren, doch wie gesagt habe ich keine Zeit^^

_________________
MCPD, MCTS and more! | "It's 7:05am. I have not slept." | www.google.com
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 15:27:27 15.03.2009   Titel:              Zitieren

Zitat:
Ich bin nämlich für den Einsatz von Makefiles.

Danke für diesen wichtigen Hinweis! Ich denke, zu Beginn erleichtert dies die Sache für einen Einsteiger nicht wirklich. Da lässt man ihn besser die einzelnen Befehlszeilen immer wieder in die Konsole hacken, damit er sich daran gewöhnt. Welches make.exe ohne notwendige DLL würdest Du denn einsetzen? Download-Link? Wo wird der Einsatz möglichst einfach beschrieben? Vielleicht überzeugst Du mich doch noch.

Das waren die Gründe, warum ich mich - zumindest für die ersten Schritte - für bat-Dateien entschieden habe. Langfristig geht dies natürlich nicht, aber momentan habe ich noch keine C-Toolchain im Einsatz. Es gibt nur nasm.exe und partcopy.exe.

Ich habe auch das img gegen bin getauscht, um nicht zu verwirren:
Code:
nasm boot.asm   -f bin -o boot.bin
nasm kernel.asm -f bin -o kernel.bin
copy /b boot.bin + kernel.bin MyOS.bin
partcopy MyOS.bin 0 400 -f0


EDIT: Habe doch noch ein einfaches make.exe ohne DLL gefunden:
http://www.steve.org.uk/Software/make/make.zip
EDIT1: Bei den Bin-Tools von gcc 2.03 ist auch ein alleinstehendes make.exe dabei: http://www.osdever.net/do ....... DJGPP-Installer-nocpp.exe

Ich werde dies im Tutorial abändern, weil der Einsatz von make.exe / makefile langfristig wirklich der richtige Weg ist. :live:

Ist als Alternative zu den bat-Dateien dargestellt, siehe
http://www.henkessoft.de/OS_Dev/OS_Dev1.htm#mozTocId748324 (Kapitel 4.5.3)
Praktisches Hindernis können die notwendigen Separatoren im makefile sein, aber gvim zeigt dies sehr gut durch fehlende bzw. vorhandene rote Schriftfarbe an.
Ein Einstieg in den make-Prozess muss auf jeden Fall erfolgen. Da führt wahrlich kein Weg beim OS Development vorbei.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 14:07:00 28.03.2009, insgesamt 5-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 18:40:51 15.03.2009   Titel:              Zitieren

Zitat:
Bootloader + Kommandozeile + FAT-Dateisystem + Interpreter (Sah aus wie Assembler, wurde aber interpretiert...).

bootloader + command-line interpreter ist nun vorhanden, zumindest im Real Mode. Einige Befehle und strcmp wurden bereits implementiert, damit man Experimente mit eigenen Befehlen leicht beginnen kann. Vielfach wird hier in Tutorials nur der Reboot eingebaut und man wird mit "Go wild!" oder "Viel Spaß!" alleine gelassen.
Den Reboot haben wir mit "exit" natürlich auch schon. Ich hoffe, dass ich bisher alles möglichst verständlich und zum praktischen Nachmachen einladend dargestellt habe, sonst kann ich gleich aufhören. Diesbezüglich bitte ich um ernsthaftes Feedback.

Der Tipp mit dem make-Prozess wurde inzwischen umgesetzt. Danke!

Vielleicht könnt ihr auch über den Code schauen, denn bei einem OS sollte alles möglichst performant laufen.

@/rant/: Wenn Du Lust hast, kannst Du mich gerne unterstützen, soweit Du kannst.
Hier steht nichts unter Zeitdruck. Didaktische Qualität und leichte Umsetzung ist wichtig und geht vor Quantität.

Die Umschaltung von RM nach PM übernehme ich gerne. Da knoble ich noch an der Didaktik.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 18:44:24 15.03.2009, insgesamt 1-mal bearbeitet
abc.w
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2008
Beiträge: 1366
Beitrag abc.w Mitglied 22:18:35 15.03.2009   Titel:              Zitieren

Hallo,

habe mal aus Neugier das Tutorial "durchgearbeitet" (mit copy-paste natürlich ;)).
Habe mit bochs folgende Erfahrung gemacht: Booten funktioniert auch mit von nasm erzeugten Binärdateien. D.h. man benötigt nicht unbedingt ein Diskettenlaufwerk oder sonstiges. In der bochsrc.txt reicht z.B. folgendes:
Code:
floppya: 1_44=c:\BochsMyOS\MyOS.bin, status=inserted

Und die Datei MyOS.bin erzeugen wie immer:
Code:
nasm.exe kernel.asm -f bin -o MyOS.bin

Finde ich schön, weil wer hat denn heutzutage ein Diskettenlaufwerk...

Und ein Problem habe ich mit meinem Makefile gehabt. Folgende Zeile wollte make irgendwie nicht akzeptieren:
Code:
    ...
    copy /b bootloader.bin + kernel.bin MyOS.bin

Da kommt bei mir immer folgende Fehlermeldung:
Code:
process_begin: CreateProcess(NULL, copy /b bootloader.bin + kernel.bin MyOS.bin, ...) failed.
make (e=2): Das System kann die angegebene Datei nicht finden.
mingw32-make: *** [OS3] Error 2

Und hier ein "Workaround":
Code:
...
    cmd /c copy /b bootloader.bin + kernel.bin MyOS.bin

Man muss also eine neue Instanz der Windows Befehlsinterpreters cmd starten und das eine Kommando übergeben. Warum auch immer. Aber wie dem auch sei, mein Makefile sieht jetzt so aus:
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
all:
    @echo Please select target: OS1 or OS2 or OS3
 
OS1:
    @echo OS1 selected.
    rm -fv kernel.bin bootloader.bin MyOS.bin
    c:\nasm-2.06rc6\nasm.exe kernel.asm -f bin -o MyOS.bin
    @echo Ready.
 
OS2:
    @echo OS2 selected.
    rm -fv kernel.bin bootloader.bin MyOS.bin
    c:\nasm-2.06rc6\nasm.exe kernel2.asm -f bin -o MyOS.bin
    @echo Ready.
 
OS3:
    @echo OS3 selected.
    rm -fv kernel.bin bootloader.bin MyOS.bin
    c:\nasm-2.06rc6\nasm.exe bootloader.asm -f bin -o bootloader.bin
    c:\nasm-2.06rc6\nasm.exe kernel3.asm -f bin -o kernel.bin
    cmd /c copy /b bootloader.bin + kernel.bin MyOS.bin
    @echo Ready.
 
clean:
    rm -fv kernel.bin bootloader.bin MyOS.bin

Man kann also mit make OS1 oder make OS2 oder make OS3 das eine oder andere assemblieren lassen...
Ansonsten hat alles wunderbar funktioniert (unter bochs) ;) Bin gespannt auf Protected Mode.
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 23:49:48 15.03.2009   Titel:              Zitieren

Zitat:
habe mal aus Neugier das Tutorial "durchgearbeitet"

Danke für den Test und das positive Feedback.

Zitat:
floppya: 1_44=c:\BochsMyOS\MyOS.bin, status=inserted

Darauf habe ich sofort im Tutorial als Alternative für das config-File hingewiesen.
Heute gibt es wirklich kaum noch Floppy Disk Laufwerke. Aber es ist für viele Coder einfach ein tolles Gefühl, wenn man einen (alten) PC mit einem selbst gebastelten OS physisch von einer Floppy booten lassen kann. :D
Da ich selbst noch eines an meinem PC eingebaut habe, verwende ich es natürlich. Ich mag einfach dieses Klack-Geräusch und das aufleuchtende Lämpchen, wenn die Floppy angesprungen wird. Aber man muss mit der Zeit gehen. :D

Danke für den "Workaround" bezüglich copy. Ich verwende noch Win XP. Vielleicht klappt es deshalb. Weiß eigentlich jemand wo dieses copy heutzutage auf der Platte steckt? In win/system32 habe ich es nicht gefunden.

Das ausgefeilte makefile wird sicher auch noch Verwendung finden, ich möchte aber nicht zu früh vom eigentlichen OS ablenken. Die Tools sind vor allem Mittel zum Zweck, und gerade beim Thema makefile blicken viele - durch die IDEs - nicht mehr durch.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 23:56:04 15.03.2009, insgesamt 1-mal bearbeitet
Nobuo T
Moderator

Benutzerprofil
Anmeldungsdatum: 09.10.2001
Beiträge: 4762
Beitrag Nobuo T Moderator 13:36:08 16.03.2009   Titel:              Zitieren

Hab's mal ueberflogen ... besonders die Codes:

1. Beispiel:
Z. 19 (mov si, ...) ist ueberfluessig
(Auf Kosten der Uebersicht haette man das und evtl. einiges Andere nat. insgesamt auch effizienter loesen koennen...)

Z. 103, 104 (mov ah, ...; mov al, ...) ist uebelste x86-Suende: sowas schreibt man wenn irgendwie moeglich immer auf einmal in das uebergeordnete Register (hier ax)

Z. 119, 120 das gleiche

Das strcmp koennte man IMHO nun aber wirklich effizienter machen:
Z. 130 ist ueberfluessig. Vergleiche besser direkt al mit [di]
"cmp reg, 0" kannst du gegen "or al, al" o.Ae. tauschen (wie du es schon in print_string machst)
ich bevorzuge da "test reg, reg", AFAIR belegt das weniger Platz... Zumindest solltest du dich mal fuer eins entscheiden. ;)
Es waere auch sinnvoller, das Ergebnis im Z-Flag zurueck zu geben. Das ist naemlich bei deinem Code so wie so schon 0, wenn eq und 1, wenn nicht eq... -> Kram mit CF weg und nur ein Ruecksprung-Label. :)

Z. 96 wieder der 0-Vergleich...

Es waere uebrigens sinnvoll, die Initialisierung des Stacks nicht unter den Tisch fallen zu lassen.
Ich bin mir nicht mal sicher, wo das BIOS den Stack anfangs hinzaubert. AFAIK gilt das als undefiniert. Da sollte man eigentlich nicht so einfach reinschreiben. Ein ueberwaeltigender Aufwand ist das nun wirklich auch nicht. Um dem Vorzubeugen: um das mov ss,.. und mov sp,.. gehoeren keine cli/sti, da man bei Intel so schlau war, bei "mov ss, ... " automatisch die Interrupts fuer die naechste Instruktion zu unterdruecken.

Den "buffer" haette man um Platz zu sparen zB. auch auf den Stack packen koennen.


Beispiel "Bootloader":
Z. 30: xor ax, ax waere kuerzer... (Z. 37 dito)
Z. 41-45: Wieder direkt hintereinander 8Bit-Register mit Konstanten geladen: Boese!

insgesamt ist das nat. ein *sehr* rudimentaerer BL, aber ich gehe mal davon aus, das war beabsichtigt...


Beispiel in 4.5.2:
IMHO wenig sinnvoll, es und ds in BL und Kern direkt hintereinander auf den selben Wert zu setzen. Das im Kern wuerde reichen.

_________________
==Mod im Assembler-Forum==

http://z0r.de/2908
Unregistrierter





Beitrag Unregistrierter 15:26:31 16.03.2009   Titel:              Zitieren

Erhard Henkes schrieb:
Weiß eigentlich jemand wo dieses copy heutzutage auf der Platte steckt? In win/system32 habe ich es nicht gefunden.

COPY ist als "Funktion" in der cmd.exe integriert. Ist deshalb nur verfügbar in einer Konsole.
rapso
Moderator

Benutzerprofil
Anmeldungsdatum: 17.06.2002
Beiträge: 8699
Beitrag rapso Moderator 18:34:32 16.03.2009   Titel:   Re: Eigenes OS?            Zitieren

Erhard Henkes schrieb:
Mich würde mal interessieren, wer alleine oder mit anderen an einem eigenen OS entwickelt, zu welchem Zweck und in welcher Sprache (ASS, C oder C++)? Links?

hab auf dos einen multitasking aufsatz gecodet, damit konnte ich dann unter dos mehrere programme gleichzeitig laufen lassen (und ein TSR was im hintergrund per timer interrupt 92mal in 5sekunden die tasks gewechselt hat, wenn ich das noch recht im kopf habe.
hab ein game os in flat-memory-mode geschrieben, darin funktionierten die 16bit treiber usw. leider nicht, war damit man auf den ganzen speicher zugreifen konnte ohne XMM usw.
fuer gameboy ein simples OS das mir noch erlaubt hat primitiv den speicher zu begutachten nach nem absturz.
fuer ps3 hab ich nen simples OS erweitert damit ich andere aufloesungen und den zweiten ppu-thread nutzen kann. hab dann noch ein lightweith task system geschrieben. :)

_________________
follow me|
-Mod im Spiele-/Grafikprogrammierung
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 20:27:05 16.03.2009   Titel:              Zitieren

Zitat:
Es waere uebrigens sinnvoll, die Initialisierung des Stacks nicht unter den Tisch fallen zu lassen.
Ich hatte einen geschrieben, selbstverständlich ohne cli/sti, habe ihn aber im Tutorial gelöscht, weil es auch so lief (Didaktik ;)).
Reicht es, wenn man den Stack erst im Kernel implementiert? Im BL (bewusst primitiv gehalten, weil ansonsten immer zu GRUB geraten wird) hat der Stack m.E. noch nichts zu suchen.

Die al/ah vs. ax Geschichte macht Sinn (werde ich abändern auf ax), weil wir auf jeden Fall nicht unter 16 bit anfangen müssen.

Welche Speicheradressen würdet ihr verwenden?
0x0000:0x07C0 für den Bootloader ist klar
0x1000:0x0000 für den Kernel?
0x9000:0x0000 für den noch einzurichtenden Stack?

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 21:49:08 17.03.2009, insgesamt 3-mal bearbeitet
Nobuo T
Moderator

Benutzerprofil
Anmeldungsdatum: 09.10.2001
Beiträge: 4762
Beitrag Nobuo T Moderator 20:36:09 16.03.2009   Titel:              Zitieren

Erhard Henkes schrieb:
Zitat:
Es waere uebrigens sinnvoll, die Initialisierung des Stacks nicht unter den Tisch fallen zu lassen.
Ich hatte einen geschrieben, selbstverständlich ohne cli/sti, habe ihn aber im Tutorial gelöscht, weil es auch so lief (Didaktik ;)).
Reicht es, wenn man den Stack erst im Kernel implementiert? Im BL (bewusst primitiv gehalten, weil ansonsten immer zu GRUB geraten wird) hat der Stack m.E. noch nichts zu suchen.

Dafuer, dass er im BL "noch nichts zu suchen hat", machst du aber doch regen Gebrauch davon. ;)
Wenn du es ganz sauber haben willst, kannst du ihn im Kern nochmal an eine ausgekluegeltere Stelle verfrachten.

_________________
==Mod im Assembler-Forum==

http://z0r.de/2908
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 21:49:46 16.03.2009   Titel:              Zitieren

Code:
1
2
3
4
5
6
7
8
    ; set parameters for reading function
    ; 8-bit-wise for better overview
    mov dl,[bootdrive] ; select boot drive
    mov al,10          ; read 10 sectors
    mov ch, 0          ; cylinder = 0
    mov cl, 2          ; sector   = 2
    mov dh, 0          ; head     = 0
    mov ah, 2          ; function "read"  

Das bleibt! Hier geht die Didaktik vor. :)
Ansonsten danke für die Tipps!
Ich habe alle Helfer bereits "namentlich" im Tutorial erwähnt. :live:

http://www.henkessoft.de/OS_Dev/OS_Dev1.htm

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 22:09:24 16.03.2009, insgesamt 1-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 00:21:42 17.03.2009   Titel:              Zitieren

Zitat:
Dafuer, dass er im BL "noch nichts zu suchen hat", machst du aber doch regen Gebrauch davon. ;)
OK, ich sehe es ein:
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
     org 0x7C00  ; set up start address
 
    ; setup a stack
    mov ax, 0x9000  ; address of the stack
    mov ss, ax      ; SS = 0x9000
    xor sp, sp      ; SP = 0x0000
 
    ; start
    mov [bootdrive], dl ; boot drive from DL
    call load_kernel    ; load kernel
 
    ; jump to kernel
    jmp 0x1000:0x0000   ; address of kernel

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 10:59:02 17.03.2009   Titel:              Zitieren

mit einem "OS" hat dieses x86er-bootloader gefrickel noch nicht viel zu tun. wann geht's denn endlich los mit multitasking, betriebsmittelverwaltung, hal, etc.
:)
Nobuo T
Moderator

Benutzerprofil
Anmeldungsdatum: 09.10.2001
Beiträge: 4762
Beitrag Nobuo T Moderator 13:38:02 17.03.2009   Titel:              Zitieren

:o)
Im Prinzip richtig. Nur duerfte es sehr schwierig werden, dieses weite, eher theorielastige Themengebiet geschickt mit Erhards praktisch ausgerichteter Didaktik unter einen Hut zu bringen.

Erhard Henkes schrieb:
Das bleibt! Hier geht die Didaktik vor. :)

Ok, aber vielleicht kann ich dich noch ueberzeugen, der Sache einen kleinen Kommentar zur Effizienz beizufuegen. Ich kriege jedes Mal einen Krampf, wenn ich sowas sehe (zuletzt sogar in einem kommerziellen BL). :D

_________________
==Mod im Assembler-Forum==

http://z0r.de/2908


Zuletzt bearbeitet von Nobuo T am 13:39:20 17.03.2009, insgesamt 1-mal bearbeitet
Unregistrierter





Beitrag Unregistrierter 14:30:39 17.03.2009   Titel:              Zitieren

Ins Kapitel "4.5.1 Bootloader" passt ev. noch einiges zur relativen (segmentierten) Schreibweise von Adressen:
Code:
Relative Adresse -> Segment:Offset
Absolute Adresse -> (Segment * 0x10) + Offset
Assembler:
1
2
3
4
5
6
7
8
9
org 0x7C00 ; set up start address  
 
; setup a stack
mov ax, 0x9000  ; address of the stack
mov ss, ax      ; SS = 0x9000
xor sp, sp      ; SP = 0x0000
(...)
; jump to kernel
jmp 0x1000:0x0000   ; address of kernel
Zitat:
Das Programm startet bei 0x7C00, legt einen Stack an bei 0x9000, lädt den Kernel nach 0x1000 und springt dorthin.
Das Programm startet relativ bei 0000:7c00, absolut bei (0000*0x10)+7c00 = 0x7c00.
Aber der Stack liegt relativ bei 9000:0000, absolut bei (9000*0x10)+0 = 0x90000.
Der Kernel liegt somit absolut bei 0x10000, weshalb der Bootloader alleine locker (0x10000 - 0x7c00 = 0x8400) über 33 KB groß sein kann.
Prinzipiell eine nicht akzeptable Verschwendung von (einstmals) wertvollen Speicherplatz. :)
Aber das sollte vorerst keine Rolle spielen. Didaktik geht vor! :live:
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 22:25:08 17.03.2009   Titel:              Zitieren

Zitat:
... weshalb der Bootloader alleine locker (0x10000 - 0x7c00 = 0x8400) über 33 KB groß sein kann.

Guter Hinweis! Ich erkläre jetzt mal, warum mir die Didaktik und ein umfassendes Verständnis wichtiger ist als ein schnelles Vorwärtsschreiten, bei dem man viele verliert und wichtige Details auf der Strecke bleiben.

So findet man dies nun im Tutorial:
Code:
0h *  16^4 + 8h * 16^3 + 4h * 16^2 + 0h * 16^1 + 0h * 16^0  =
0  * 65536 + 8  * 4096 + 4  * 256  + 0  * 16   + 0  * 1     =
             32768     + 1024                               =  33792


33792 Byte / 1024 = 33 KByte

Korrekt ist also:
Der Bootloader darf höchstens 33 KB groß sein.

Würdet ihr den Kernel auf 7E00h setzen? Dann passt kein Byte mehr dazwischen.
Eigentlich könnte man sogar die beiden Boot-Signatur-Bytes überschreiben?
Also 7DFEh als Minimum? Didaktisch interessante Frage, finde ich.

Experiment mit 7DFEh: Absturz (bleibt "hängen", lädt keinen Kernel)
Experiment mit 7E00h: läuft ständig im Kreis (Bootloader Message erscheint und wird wieder gelöscht)
Also: Wieviel Abstand wird genau benötigt und warum?

Zitat:
Ins Kapitel "4.5.1 Bootloader" passt ev. noch einiges zur relativen (segmentierten) Schreibweise von Adressen

Ich habe ein Kap. 4.5.4 "Background-Wissen: Speicheradressierung im Real Mode (RM)" aufgenommen und in 4.5.1 darauf verwiesen:
Zitat:
Das Programm startet bei 07C00h, legt einen Stack an bei 90000h, lädt den Kernel nach 10000h und springt dorthin.
Adressierung im Real Mode siehe Abschnitt 4.5.4

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 23:49:17 17.03.2009, insgesamt 5-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 23:17:29 17.03.2009   Titel:              Zitieren

Zitat:
vielleicht kann ich dich noch ueberzeugen, der Sache einen kleinen Kommentar zur Effizienz beizufuegen. Ich kriege jedes Mal einen Krampf, wenn ich sowas sehe


@Nobuo T:
Das möchte ich nicht, dass Dir schlecht wird bei dem Code. :D
Wir brauchen Dich noch zum Überprüfen/Optimieren.
Ich habe auf Deinen Wunsch hin folgende Passage ergänzt:
Zitat:

Hinweis: Die Verwendung des High und Low Byte eines Registers in Verbindung mit dem Befehl mov, wenn genau so gut das gesamte 16-Bit-Register mit einem Befehl bedient werden könnte, ist eine Verschwendung von Prozessortakten! Dies geschieht in obigem Fall nur der besseren Übersicht wegen. Performanter Programmierstil ist dies nicht.

Also anstelle

mov al,10 (mov al, 0x0A)
mov ah, 2

verwendet man performant

mov ax, 0x020A

Nun wollte ich schreiben, wieviele Takte man oben und unten benötigt, habe aber keine Übersichtslisten gefunden. Kennt sich da jemand aus? Link?

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 23:19:47 17.03.2009, insgesamt 1-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 00:04:03 18.03.2009   Titel:              Zitieren

Muss man eigentlich auch auf das Little Endian-Format bei Intel Prozessoren ("Lowest Byte first") eingehen? Ich denke ja, denn bereits, wenn man
Code:
times 510-($-$$) db 0
dw 0xAA55

schreiben wollte, anstelle
Code:
times 510-($-$$) db 0
db 0x55
db 0xAA

Dann muss man die veränderte Reihenfolge erklären. Im Hexeditor sieht man ja auch:
aus dw 0xAA55 wird im Speicher 55AA

Zur Vermeidung habe ich zwei Mal db verwendet. :D

Zitat:
wann geht's denn endlich los mit multitasking, betriebsmittelverwaltung, hal, etc.
Hoffentlich bist Du noch jung. Das kann noch etwas dauern. :D Nein, im Ernst. Ich möchte jeden Schritt genau ausloten, niemand verlieren.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 00:24:38 18.03.2009, insgesamt 3-mal bearbeitet
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 10:21:05 18.03.2009   Titel:              Zitieren

Erhard Henkes schrieb:
Muss man eigentlich auch auf das Little Endian-Format bei Intel Prozessoren ("Lowest Byte first") eingehen? Ich denke ja

das solltest du unbedingt tun, mit begründung, warum die x86'er sowas machen. und dann nicht nur für 2-byte werte.

Erhard Henkes schrieb:

Zitat:
wann geht's denn endlich los mit multitasking, betriebsmittelverwaltung, hal, etc.
Hoffentlich bist Du noch jung. Das kann noch etwas dauern. :D

hoffentlich bist du noch jung. bei den themen kannste dir 'nen wolf schreiben.
:)
Nobuo T
Moderator

Benutzerprofil
Anmeldungsdatum: 09.10.2001
Beiträge: 4762
Beitrag Nobuo T Moderator 14:10:04 18.03.2009   Titel:              Zitieren

Also wenn schon, denn schon:
Zitat:

Hinweis: Die Verwendung des High und Low Byte eines Registers in Verbindung mit dem Befehl mov, wenn genau so gut das gesamte 16-Bit-Register mit einem Befehl bedient werden könnte, ist eine Verschwendung von Speicherplatz und Prozessortakten (in diesem Fall 1 Byte und max. z.B. auf einem 486 1 Takt zusätzlich)! Dies geschieht in obigem Fall nur der besseren Übersicht wegen. Performanter Programmierstil ist dies nicht.

Also anstelle

mov al,10 (mov al, 0x0A)
mov ah, 2

verwendet man performant

mov ax, 0x020A



Erhard Henkes schrieb:

Nun wollte ich schreiben, wieviele Takte man oben und unten benötigt, habe aber keine Übersichtslisten gefunden. Kennt sich da jemand aus? Link?

Ist alles ziemlich undurchsichtig. Quellen waeren Docs aktueller CPU von den Herstellern. Wie aber bereits erwaehnt, braucht schon der 486 max. 1 Takt fuer so ein mov - auf neueren CPU werden das vermutlich nicht mehr sein.
Zumindest AMDs fruehere 64Bitter liessen sich von sowas AFAIR auch gern mal die Pipeline durcheinander bringen, also wahrscheinlich dann auch 2 Takte.

_________________
==Mod im Assembler-Forum==

http://z0r.de/2908
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 18:07:09 18.03.2009   Titel:              Zitieren

Zitat:
Also wenn schon, denn schon:
Was meinst Du damit?

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
Nobuo T
Moderator

Benutzerprofil
Anmeldungsdatum: 09.10.2001
Beiträge: 4762
Beitrag Nobuo T Moderator 19:03:06 18.03.2009   Titel:              Zitieren

Ich habe mir erlaubt, deinen Text hauptsaechlich um die Erwaehnung des zusaetzlichen Speicherplatzverbrauchs zu erweitern (was in einem BL wichtiger sein duerfte als 1 verpulverter CPU-Takt), falls das nicht aufgefallen sein sollte... :)

_________________
==Mod im Assembler-Forum==

http://z0r.de/2908
abc.w
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2008
Beiträge: 1366
Beitrag abc.w Mitglied 20:06:14 18.03.2009   Titel:              Zitieren

Bezüglich Takte gibt es hier http://www.agner.org/optimize/ unter "4. Instruction tables: Lists of instruction latencies, throughputs and micro-operation breakdowns for Intel and AMD CPU's" eine schöne Übersicht über die ganzen Befehle und deren Takte, uOps und was weiss der Teufel noch was... falls es jemand genauer wissen möchte.
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 20:45:04 18.03.2009   Titel:              Zitieren

Zitat:
Ich habe mir erlaubt, deinen Text hauptsaechlich um die Erwaehnung des zusaetzlichen Speicherplatzverbrauchs zu erweitern (was in einem BL wichtiger sein duerfte als 1 verpulverter CPU-Takt), falls das nicht aufgefallen sein sollte... :)
Sorry! Danke für die Ergänzung. Jedes Byte im ersten Sektor ist wertvoll.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 00:17:22 19.03.2009, insgesamt 1-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 00:16:42 19.03.2009   Titel:              Zitieren

Ich wollte mal auf die Schnelle in den PM umschalten, macht aber einen Reset. Ich finde momentan den Fehler einfach nicht. Liegt es an GDTR/GDT, am fehlenden IDT oder am far jump?

Vielleicht sollte ich doch auf C umsatteln? Mir gefällt Assembler aber didaktisch besser, weil es klarer ist. Kann bitte jemand nachhelfen?

..

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 10:28:09 05.10.2013, insgesamt 3-mal bearbeitet
Nobuo T
Moderator

Benutzerprofil
Anmeldungsdatum: 09.10.2001
Beiträge: 4762
Beitrag Nobuo T Moderator 00:55:19 19.03.2009   Titel:              Zitieren

Ich wuerde spontan auf deine GDT, bzw. GDTR tippen. Bist du dir zB. sicher, dass die Basisadresse im GDTR auch stimmt?

_________________
==Mod im Assembler-Forum==

http://z0r.de/2908
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 01:03:12 19.03.2009   Titel:              Zitieren

Nein, ich habe da zu viel aus verschiedenen Ecken zusammen geflickt. Das funktioniert leider auch nicht, denke aber, dass es so richtig ist:
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
gdtr:
      dw gdt_end - gdt - 1 ; lenght of GDT
      dd gdt
 
gdt:                       
      dw 0         ; (0h) Null Segment
      dw 0                 
      db 0                 
      db 0                 
      db 0                 
      db 0
 
code_gdt equ $-gdt
      dw 0x0FFFF
      dw 0x0000
      db 0x00
      db 0x9A
      db 0xCF
      db 0x00
 
data_gdt equ $-gdt
      dw 0x0FFFF
      dw 0x0000
      db 0x00
      db 0x92
      db 0xCF
      db 0x00
 
video_gdt equ $-gdt
      dw 3999 ; Limit 80*25*2-1
      dw 0x8000
      db 0x0B ; Base 0xB8000
      db 0x92
      db 0x00
      db 0x00
 
gdt_end:  

Die Basis-Adresse ist doch das Label gdt?

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 01:07:51 19.03.2009   Titel:              Zitieren

Habe gerade mal bei uns im Forum recherchiert:
http://www.c-plusplus.de/ ....... opic-var-t-is-219332.html
Da klagt auch jemand über Neustart. Da lag es am far jump. :rolleyes:
Naja, aus Fehler kann man ja auch lernen. Da scheitern die meisten. :D

Wenn ich org 0x10000 vorne rein setze, funktionieren die normalen Befehle im Real Mode. Bei PM stürzt er aber sofort ab.

Wenn ich org 0x7c00 vorne rein setze, funktionieren die normalen Befehle im Real Mode natürlich nicht mehr. Bei PM stürzt er aber nicht mehr ab, aber er zeigt auch nichts an (z.B. 'A'). Man kann dann noch Zeichen eingeben, Puffer von 31 Zeichen läuft noch.

org 0x10000 ist richtig. Wie muss ich den far jump schreiben?

Was ist hier der richtige Selektor für den Jump?

Code:
 db 0xea    ;instruction for FAR JUMP
  dw do_pm      ;Offset for jump
  dw 0x8    ;selector of the segment for the jump
 
 ; jmp code_gdt:do_pm does not work?!

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 01:41:08 19.03.2009, insgesamt 5-mal bearbeitet
Nobuo T
Moderator

Benutzerprofil
Anmeldungsdatum: 09.10.2001
Beiträge: 4762
Beitrag Nobuo T Moderator 01:36:04 19.03.2009   Titel:              Zitieren

Tja, das ist eben so eine Sache mit den Labels in Asm. Praktisch sind das ja beim x86 eigentlich immer offsets. Da muss auch jeweils die Basis-Adresse zu stimmen (wird auch beim nasm mittels org festgelegt).

Kurze Ueberlegung:
Wenn du deinen Code nach 0x10000 laedst und die Segmentregister dann mit 0x1000 laedst, klappt das ohne, bzw. mit org 0 natuerlich erstmal im RM problemlos, da dein Code an Offset 0 des Segments direkt beginnt. Im GDTR muss dann aber die physikalische mit absoluter Basis 0 stehen! Das selbe beim far jump zum PM - der offset-Teil muss dort dann relativ zur Basisadresse, die im angegebenen Code-Selector steht, passen.
Wenn du stattdessen einfach so die labels da rein schreibst, ohne zu beruecksichtigen, dass sich deren Adresse so ohne Weiteres nur auf das RM-Segment 0x1000 beziehen, geht die Sache schief.

_________________
==Mod im Assembler-Forum==

http://z0r.de/2908


Zuletzt bearbeitet von Nobuo T am 01:39:41 19.03.2009, insgesamt 1-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 01:46:52 19.03.2009   Titel:              Zitieren

<< Zwischenstand gelöscht >>

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 01:06:23 21.03.2009, insgesamt 1-mal bearbeitet
Nobuo T
Moderator

Benutzerprofil
Anmeldungsdatum: 09.10.2001
Beiträge: 4762
Beitrag Nobuo T Moderator 02:00:55 19.03.2009   Titel:              Zitieren

Sorry, ich bin gerade auch zu bematscht in der Birne, um konkreter zu werden. Da kann ich mich erst nach einer Muetze Schlaf konzentriert mit befassen...

_________________
==Mod im Assembler-Forum==

http://z0r.de/2908
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 11:34:55 19.03.2009   Titel:              Zitieren

Erhard Henkes schrieb:

Geht das nicht einfacher als unten im Code?

wahrscheinlich nicht.
Erhard Henkes schrieb:

Ist schwierig zu verstehen.

du wolltest doch unbedingt das x86-flickwerk nehmen. jetzt musst da wohl durch.
:)
Nobuo T
Moderator

Benutzerprofil
Anmeldungsdatum: 09.10.2001
Beiträge: 4762
Beitrag Nobuo T Moderator 13:51:39 19.03.2009   Titel:              Zitieren

Das ist nicht unbedingt ein Problem von NASM (bzw. mir faellt kein Assembler ein, mit dem das wirklich geschickter ginge), sondern eine Eigenart des x86, dass hier in einem Code einfach verschiedene Adressierungsmechanismen zum Zugriff auf die selben Labels benutzt werden.
Am saubersten waere es IMHO, wenn du dafuer sorgst, dass dieses Phaenomen der unterschiedlichen Basisadressen gar nicht erst auftritt. Dazu musst du in diesem Code-Abschnitt immer die Segment-Basis 0 benutzen (im RM also alle Segmentregister auf 0 setzen, dh. der Code muss auch in den ersten 64K Speicher liegen, im PM die Basisadresse fuer Zugriffe auf diesen Code auch 0) und an den Anfang des Codes entsprechend eine org-Anweisung mit dem Start-Offset des Codes zur Basis 0 (also das Offset innerhalb der ersten 64k, wo der Code anfaengt).
32Bit-Segmente mit Basis 0 und bis zu 4GB Groesse zu verwenden, bietet sich dann im PM spaeter natuerlich so oder so auch an...
So kannst du dir dann auch zB. den extra-Descriptor fuer die Textausgabe sparen und hast einen leichteren Uebergang zu C-Code (wie wuerde man direkt aus c heraus ueberhaupt mit verschiedenen Selectoren umgehen?).
So solltest du keine Probleme mit irgendwelchen "org"ien oder "Kunstgriffen" mit addierten Basisadressen o.Ae. bekommen.

Falls du deinen Code unbedingt im Segment 1000 lassen willst, kommst du um einiges Gebastel mit Addition der phys. Basisadresse (10000) zur Adresse der GDT und evtl. die Differenz der Basisadressen der Code-Segmente in RM und PM zum Far-Jump in den PM wahrscheinlich nicht umhin.
Das waere dann immerhin evtl. eine gute Gelegenheit, die Adressierungsmechanismen des RM, rein physikalischer Adressen und PM ohne paging genauer zu beleuchten... wenn du das wirklich sauber kommentierst und erklaerst.


Noch zu etwas Anderem:
In meinem letzten OS-Projekt in der Uni, und nun in deinem Code, wurde mir mal wieder deutlich vor Augen gefuehrt, dass es nicht "cool", sondern hoechstens verwirrend ist, irgendwelche weitgehend unkommentierten Zahlen zur Darstellung von Bit-flags hinzuklatschen. Du tust deinen Lesern sicher einen Gefallen, wenn du flags in den Deskriptoren genauer kommentierst.

Mich wuerde auch interessieren, weshalb du meinen Tipp zu deinem strcmp nicht uebernummen hast?

_________________
==Mod im Assembler-Forum==

http://z0r.de/2908
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 18:49:23 19.03.2009   Titel:              Zitieren

Zitat:
Mich wuerde auch interessieren, weshalb du meinen Tipp zu deinem strcmp nicht uebernummen hast?


@Nobuo T:
Sorry, hatte vergessen, es auch im Tutorial einzutippen. Dein Tipp ist hervorragend! Code ist jetzt kürzer: Carry-Flag weg und nur noch eine Rücksprungadresse '.done'

..

Ich hoffe zumindest, dass ich Dich so richtig verstanden habe.
Wie hättest Du dies mit 'test op,op' (AND-Verknüpfung ohne Speicherung, nur Flags setzen) gemacht? Das nimmt man doch eher, um zu testen, ob ein bestimmtes Bit gesetzt ist? z.B. test AL, 64 (check auf Bit 6)

Bezüglich RM -> PM bin ich noch am Grübeln. da muss ich noch einige Hobby-OS analysieren. Vielleicht kann man die besten Ideen aus allen heraus kristallisieren. Die Idee von Nobuo T ist auf jeden Fall bedenkenswert. Welchen offset würde man da mittels org wählen und warum? Mir ist noch nicht klar, warum die meisten den Kernel (oder ersten Teil des Kernels) nach 10000h setzen.

Zitat:
... dass es nicht "cool", sondern hoechstens verwirrend ist, irgendwelche weitgehend unkommentierten Zahlen zur Darstellung von Bit-flags hinzuklatschen. Du tust deinen Lesern sicher einen Gefallen, wenn du flags in den Deskriptoren genauer kommentierst.

Völlig richtig! So darf man das auch nicht machen, war nur Test.
Besser: binäre Darstellung im Assemblercode mit Kommentar, der die einzelnen Bits bezüglich ihrer Aufgabe beschreibt/erklärt. :live:

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 10:30:54 05.10.2013, insgesamt 4-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 23:24:05 19.03.2009   Titel:              Zitieren

Zunächst mal vielen Dank an alle, die mich bisher nicht entmutigten, sondern mich mit Rat und Tat unterstützen. IMHO ein wirklich konstruktives Subforum.

Für die Ungeduldigen:
Nun wollen wir mal versuchsweise von RM nach PM schalten (ist noch nicht im Tutorial, weil didaktisch noch nicht klar genug), indem man den Befehl "pm" eingibt.

Ich habe zunächst die Methode der Kalkulation für die GDTR-Werte nach dem Umschalten verwendet, um zu sehen, ob das alles gut klappt. Funktioniert wirklich. Didaktisch ist dieser Weg nicht perfekt, lässt sich aber dennoch erklären. Vielleicht kann Nobuo T seine Idee daneben stellen zum Vergleich.

Nun fehlt didaktisch nur noch ein Command Line Interpreter und ein Befehl "RM" im Protected Mode, der den Rücksprung nach Real Mode gewährt.

In Zeile 277 steht noch nichts Sinnvolles als Zieladresse (zur Zeit wird der Code "gedumpt", ich habe mal in DL mit den Farben gespielt). Hat jemand eine kleine gute Idee für den Einstieg?

Typisch wäre jetzt ein Sprung in einen C-Kernel. Aber inzwischen gefällt mir Assembler viel besser. Man gewöhnt sich an alles. ;)

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 10:32:03 05.10.2013, insgesamt 4-mal bearbeitet
abc.w
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2008
Beiträge: 1366
Beitrag abc.w Mitglied 00:03:35 20.03.2009   Titel:              Zitieren

Hallo,

habe mal den Code in bochs ausprobiert, weiss nicht, ist es normal, dass nach dem Kommando pm lauter farbiger Zeichen erscheinen... ;)
Bezüglich der drei Zeilen:
Code:
  db    0xea            ; instruction code for FAR JUMP
  dw    ProtectedMode        ; offset for jump
  dw    0x8            ; selector of the segment for the jump

Man kann sich die Binärdatei mit dem Programm ndisasm, das mit nasm mit dabei ist, disassemblieren lassen, z.B. so:
Code:
c:\nasm-2.06rc6\ndisasm.exe -b 16 kernel.bin

Dann sieht man, wie ndisasm es interpretiert:
Code:
000001E4  EA57020800        jmp word 0x8:0x257

Also kann man die oberen 3 Zeilen durch eine ersetzen:
Code:
  jmp word 0x8:ProtectedMode

Damit wird scheinbar auch ein FAR JUMP generiert. Man kann es auch hier nachlesen: http://www.nasm.us/doc/nasmdo10.html#section-10.1
Ich hab es mal ausprobiert und es kommen immer noch die farbigen Zeichen - also wahrscheinlich funktioniert es wie vorher. Und die ndisasm Ausgabe stimmt auch mit der vorherigen überein.
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 00:04:56 20.03.2009   Titel:              Zitieren

Zitat:
habe mal den Code in bochs ausprobiert, weiss nicht, ist es normal, dass nach dem Kommando pm lauter farbiger Zeichen erscheinen... ;)

Das Progrämmchen war nur Spaß zum Testen, lief durch die Strings und wechselte die Farbe bei jedem 'NUL'. Ich bräuchte das hier:

Hat jemand einen ASM-Code für '.clearScreen' (ab 0xB0000) und '.eineSekundePause' in PM?
Dann könnte man dies hier machen:

Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
ProtectedMode2:
  mov ecx, 0x0B8000
  mov esi, 0x10000 + msg_pm2 ; 'OS currently uses Protected Mode.'
  mov dl,  0x01
.endlessloop:
  call .eineSekundePause
  call .clearScreen
  inc dl
  cmp dl, 0x15
  jz .resetcolor
  call PutStr_32
  jmp .endlessloop
.resetcolor:
  xor dl, dl
  jmp .endlessloop

Bestimmt nicht schlecht für den Anfang. ;)

Code:
  jmp word 0x8:ProtectedMode
  ;db   0xea            ; instruction code for FAR JUMP
  ;dw   ProtectedMode       ; offset for jump
  ;dw   0x8         ; selector of the segment for the jump

Ja, geht! Offenbar gibt es bei manchen Compilerversionen Probleme, sonst würden nicht viele sich zu diesem Kunstgriff retten.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 00:20:37 20.03.2009, insgesamt 4-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 02:46:20 20.03.2009   Titel:              Zitieren

Die Subroutine ClrScr32 bewirkt einen Reboot. Kommentiert man den Befehl aus, läuft der String 'OS currently uses Protected Mode.' oben links in 16 Farben durch. Ich möchte nur jeweils vorher den Bildschirm löschen. Code macht aber Probleme. Vielleicht hat jemand eine Idee?

..

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 10:33:17 05.10.2013, insgesamt 1-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 11:25:42 20.03.2009   Titel:              Zitieren

Im Tutorial könnte man den clrscr zunächst noch im RM ausführen. GDT habe ich
nach gdt.inc ausgelagert. Inzwischen alles schon ganz schön unübersichtlich.
So sieht momentan eine zumindest in Bochs binär von Platte funktionierende Version (von floppy im PC booten klappt momentan nicht?) aus:

..

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 10:33:47 05.10.2013, insgesamt 6-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 12:57:07 20.03.2009   Titel:              Zitieren

Ich habe das OS auf einem alten PC (AMD 1400 MHz) getestet. Dort rebootet er bei Eingabe "pm", während bochs das OS brav von Diskette schluckt. Weiß jemand, wo der "real wirksame" Fehler liegt?

Didaktisch steckt das "OS" momentan im Schlamm, da ich momentan nicht sicher bin, wie man das Ganze am besten in kleine Häppchen verpacken kann. Was würdet ihr in welche inc-Dateien packen? Man kann das ja auch kaum noch sinnvoll hier posten (warum gibt es keine scroll-Funktion für solche Dateien wie in anderen Foren?).

lgdt [gdt] findet man in google 216 mal.
lgdt [gdtr] findet man in google 740 mal.
Letzteres ist ja auch richtiger, werde das anpassen.

Jemand hatte auch nach Einstieg in x86-64 gefragt. Hier sind Links dazu:
http://wiki.osdev.org/Entering_Long_Mode_Directly
http://en.wikipedia.org/wiki/Long_mode

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 13:29:51 20.03.2009, insgesamt 3-mal bearbeitet
Nobuo T
Moderator

Benutzerprofil
Anmeldungsdatum: 09.10.2001
Beiträge: 4762
Beitrag Nobuo T Moderator 16:50:03 20.03.2009   Titel:              Zitieren

Ok, mal der Reihe nach abarbeiten...

Erhard Henkes schrieb:

Ich hoffe zumindest, dass ich Dich so richtig verstanden habe.
Wie hättest Du dies mit 'test op,op' (AND-Verknüpfung ohne Speicherung, nur Flags setzen) gemacht? Das nimmt man doch eher, um zu testen, ob ein bestimmtes Bit gesetzt ist? z.B. test AL, 64 (check auf Bit 6)

Ja, so war das gedacht, sieht ok. :)
"test" kannst du sowohl, wie du schreibst, benutzen, um einzelne Bits zu testen, allerdings erzielst du mit "test al, al" praktisch das gleiche Ergebnis wie mit "or al, al" (oder wohl auch "and al, al", wenn wir schon dabei sind), ist aber IMHO zumindest konsequenter. :)

Erhard Henkes schrieb:
Welchen offset würde man da mittels org wählen und warum?

Das offset, an den du den Code im RAM bzgl. Segment 0 kopierst. Da bietet sich IMHO zB. 8000h an...

Erhard Henkes schrieb:
Mir ist noch nicht klar, warum die meisten den Kernel (oder ersten Teil des Kernels) nach 10000h setzen.

...aus dem selben Grund, aus dem wohl auch viele Frickler ihren Code nach 10000h laden: Es ist einfach eine schoene runde Adresse. Und bei 10000h laeuft man praktisch auch keine Gefahr mehr, irgendwo mit den Untiefen der BDA in Konflikt zu geraten. 8000h sollte da AFAIK aber auch sicher und "rund" genug sein.

Erhard Henkes schrieb:
Ich habe das OS auf einem alten PC (AMD 1400 MHz) getestet. Dort rebootet er bei Eingabe "pm", während bochs das OS brav von Diskette schluckt. Weiß jemand, wo der "real wirksame" Fehler liegt?

Ohne zu testen, kommt mir folgendes eigenartig vor:
Assembler:
;z234-237, kernel.asm
  mov    WORD [CODE_Desc+2], 0    ; code segment base address = 0
  mov    WORD [DATA_Desc+2], 0    ; data segment base address = 0
  mov    BYTE [CODE_Desc+4], 0    ; code segment base address = 0
  mov    BYTE [DATA_Desc+4], 0    ; data segment base address = 0

Halte ich durchaus fuer problematisch, mit den RM-Segmenten im PM auf den Speicher zuzugreifen. -> Mein Tipp waere, das Ganze als initialisierte Daten anzulegen, dann kannst du dir diesen Code (wie die restliche Initialisierung in z 104 eigentlich auch) sparen.

Ausserdem bekommst du potentiell Probleme, wenn du auf Speicher >1MB zugreifst (stack), ohne die A20 eingeschaltet zu haben.

...
Erhard Henkes schrieb:
Vielleicht kann Nobuo T seine Idee daneben stellen zum Vergleich.

...seufz... Das wuerde einiges an Arbeit, da ich deinen Code erst recht nicht ohne Testen umfangreich umschreiben und hier einstellen will. Mal sehen, ob ich heute Abend Zeit und Nerv finde.


Zu deinem clearscreen32:
32Bit loop und rep benutzen ecx... Vielleicht liegt es daran.

_________________
==Mod im Assembler-Forum==

http://z0r.de/2908


Zuletzt bearbeitet von Nobuo T am 16:51:58 20.03.2009, insgesamt 1-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 19:43:42 20.03.2009   Titel:              Zitieren

Zu test op,op:
Ich dachte, Du würdest dies als Ersatz für cmp op,op einsetzen wollen.

Ich habe leider noch nicht genau verstanden, wie Du das mit den initialisierten Daten als Vereinfachung meinst. Ein konkreter Vorschlag würde hier echt helfen.

Wie kann man in Bochs eigentlich die Belegung des Speichers visualisieren?
Kenne bisher nur den Bochs Debugger mit der Register-Visualisierung.
Ist das biedere Bochs eigentlich das ideale Tool bezüglich Visualisierung oder hat jemand bessere Erfahrung mit anderen Emulationen gemacht? Einer der didaktischen Probleme ist ja, dass man überhaupt nicht "sieht", in welchem Mode (RM, PM) man sich befindet, ob A20 aktiviert ist, usw. Da ist eines der Probleme beim Einstieg in die OS-Entwicklung.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 19:46:51 20.03.2009, insgesamt 1-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 01:03:42 21.03.2009   Titel:              Zitieren

Zitat:
...seufz... Das wuerde einiges an Arbeit, da ich deinen Code erst recht nicht ohne Testen umfangreich umschreiben und hier einstellen will. Mal sehen, ob ich heute Abend Zeit und Nerv finde.

Hier ist noch eine andere ältere (Okt. 1996) Quelle für dieses Vorgehen:
http://www.fh-zwickau.de/ ....... utor/code/pmode/pm_01.asm (einfach)
http://www.fh-zwickau.de/ ....... r/code/pmode/pm_07_03.asm (komplex mit multitasking)

Dies war wahrscheinlich auch Vorbild für die bereits o.g. Vorgehensweise, die Dir nicht sonderlich gefällt:
http://lowlevel.brainsware.org/wiki/index.php/Protected_Mode

Erklärbar ist es auf jeden Fall ganz gut.
Mich irritiert momentan, dass es in Bochs läuft, aber auf einem alten PC von Floppy nicht bootet. :rolleyes:

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 17:04:25 21.03.2009, insgesamt 2-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 14:55:51 21.03.2009   Titel:              Zitieren

Ich habe als Vorbereitung etwas zu RM und PM geschrieben:
http://www.henkessoft.de/OS_Dev/OS_Dev1.htm#mozTocId362977

Es ist wichtig, dass man die Erklärungen und Zeichnungen möglichst einfach und richtig versteht. Ansonsten versteht man die praktische Abfolge hinterher falsch. Könnt ihr das bitte mal checken?

Die nächste geistige Reihefolge wäre dann z.B.:

1) Selektor (hier kommen GDT und LDT sowie die Privilege Levels 0-3 ins Spiel)
2) Aufbau GDT
3) Welche Deskriptoren gibt es noch?
4) Interrupts
5) Programmablauf in PM
6) Multitasking

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 17:02:19 21.03.2009, insgesamt 1-mal bearbeitet
Nobuo T
Moderator

Benutzerprofil
Anmeldungsdatum: 09.10.2001
Beiträge: 4762
Beitrag Nobuo T Moderator 17:33:22 21.03.2009   Titel:              Zitieren

Ich habe deine Quellcodes mal etwas umgebaut. Um die Scrollerei einzudaemmen, habe ich die Dateien mal hier hochgeladen.
Waere praktisch, wenn du die Quellcodes in deinem Tutorial auch direkt als Downloads haettest (habe sie zumindest nicht gefunden).
Eine aufschlussreiche Seite zum A20-Kram ist zB. hier zu finden.

Zu deinem Text:
Begriffe im Deutschen werden meist ziemlich nach Lust und Laune verwendet, aber
lineare und physikalische Adresse ist AFAIK nicht das Gleiche. Spaetestens beim Paging nicht: Da wird aus der linearen (zT. dann auch logische Adresse genannt) Adresse mit der PageTable erst die physikalische Adresse gewurstet.

IMHO koenntest du noch etwas ausfuehrlicher darauf eingehen, warum fuer Multitasking nun auf einmal Schutzmechanismen noetig sind, und warum fuer DOS nicht, bzw. was unter Multitasking grob zu verstehen ist.

Ansonsten bin ich mir nicht sicher, ob das so schon "leicht verstaendlich" ist.
IMHO ist dein Fazit noch etwas verwirrend und deinen "5)" in der praktischen Umsetzung kann nicht mal ich so nachvollziehen.

_________________
==Mod im Assembler-Forum==

http://z0r.de/2908
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 18:21:40 21.03.2009   Titel:              Zitieren

Zitat:
lineare und physikalische Adresse ist AFAIK nicht das Gleiche.

Ja, da hast Du ab dem 386er völlig Recht. Man findet in der Literatur ständig einen Mischmasch aus 286er 16-Bit-Protected-Mode und 386er 32-Bit-Protected-Mode. Beim 286er ist die "lineare" Adresse identisch mit der physikalischen Adresse, beim 386er muss letztere aus der ersten wegen des Pagings berechnet werden. Auch die Deskriptoren sind beim Sprung vom 286er zum 386er von sechs auf acht Byte gewachsen. Erst durch direkten Vergleich beider Systeme versteht man, warum das heute so chaotisch angeordnet ist.

Nobuo, vielen Dank für Deinen Quellcode! Ich werde eine Seite mit Download-Links einbauen. Dort wird es dann auch einen Bereich "Erlkönig" geben, wo wir alphas und betas ablegen können.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 18:24:36 21.03.2009, insgesamt 1-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 18:25:52 21.03.2009   Titel:              Zitieren

Zitat:
IMHO koenntest du noch etwas ausfuehrlicher darauf eingehen, warum fuer Multitasking nun auf einmal Schutzmechanismen noetig sind, und warum fuer DOS nicht, bzw. was unter Multitasking grob zu verstehen ist.
Akzeptiert.

Das "Fazit" werde ich ebenfalls überdenken.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 18:44:37 21.03.2009   Titel:              Zitieren

Feedback bezüglich Code von Nobuo T:

Test 1: Auf Floppy schreiben und "echt" booten.
Resultat: Perfekt! :live:

Erstes Code-Studium:
Kernel auf 0x08000 gesetzt wie diskutiert,
buffer weg,
A20 eingeschaltet (die berühmte 21. Adressleitung),
ansprechende Ausgabe der Meldung im PM

@Nobuo T: Danke für die fundierte Unterstützung! :)

@all: bitte den Code checken, gute Ideen werden sofort angenommen. Vielleicht kann man auch im Real Mode noch etwas Interessantes ergänzen, z.B. den CPUID-Befehl?!

Zitat:
Waere praktisch, wenn du die Quellcodes in deinem Tutorial auch direkt als Downloads haettest (habe sie zumindest nicht gefunden).

http://www.henkessoft.de/OS_Dev/Downloads/20090321_eh_os.zip

Ich werde diesen m.E. gelungenen Einstieg in den PM nun didaktisch aufarbeiten, damit das Tutorial Einsteigern das Leben so leicht wie möglich macht. Da fehlen noch einige gute Abbildungen. Die Unterscheidung zwischen 16-Bit- und 32-Bit-Protected Mode ist didaktisch wichtig. Paging, Unterschied lineare/phys. Adresse ebenso.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 21:19:48 22.03.2009, insgesamt 6-mal bearbeitet
Unregistrierter





Beitrag Unregistrierter 01:17:07 22.03.2009   Titel:              Zitieren

Erhard Henkes schrieb:
Vielleicht kann man auch im Real Mode noch etwas Interessantes ergänzen
Vielleicht folgendes:

Wenn man im PM ein Segmentregister initialisiert und dann wieder in den RM wechselt, bleibt die Segmentgröße des Selektors für das initialisierte Segmentregister erhalten. Dadurch hat man über dieses Segmentregister Zugriff auf die gesamte Segmentgröße auch im RM.

Was heißt, die Begrenzung auf 1MB RAM im RM kann relativ einfach außer Kraft gesetzt werden. Das Segmentregister darf nur nicht im RM wieder verändert werden. Sonst ist der Spaß vorbei. Aber man ja beliebig oft hin und her wechseln. :)
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 00:15:02 23.03.2009   Titel:              Zitieren

@+gjm+:
Das klingt ja echt abenteuerlich! :D
Findet man dazu bereits einen Link im Internet oder ist das Geheimwissen?
Wie läuft denn da die genaue Adressierung im zurück geschalteten RM ab?

@abc.w: Hast Du den neuen Code bereits ausprobiert?
http://www.henkessoft.de/OS_Dev/Downloads/20090321_eh_os.zip

@Nobuo T: Deine konstruktiven Vorschläge wurden aufgenommen und hoffentlich weitgehend umgesetzt. Multitasking und A20 Gate wird jetzt auch breiter besprochen. Das ist schon ganz schön viel Text, hoffentlich brauchbare Abbildungen und ziemlich viele Zeilen Assembler, nur um die Basis PM zu erreichen. Didaktisch ist es wirklich nicht ganz einfach die x86 Historie verständlich zu erklären, ohne allzu langatmig zu werden. ;)

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 00:26:05 23.03.2009, insgesamt 2-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 01:31:35 23.03.2009   Titel:              Zitieren

Eine Frage zum Bootloader-Code:
http://www.henkessoft.de/OS_Dev/OS_Dev1.htm#mozTocId80121

Wir schreiben den Offset der Sprung-Adresse des Kernels nachs BX.
Später springen wir ohne Verwendung dieses Registers.
Code:
mov bx, 0x8000     ; set up start address of kernel
;...
jmp 0x0000:0x8000   ; address of kernel

ES:BX ist notwendig für int 0x13 als "Buffer Address Pointer".
So läuft es auf jeden Fall auch:
Code:
mov bx, 0x8000     ; set up start address of kernel
;...
jmp bx   ; address of kernel

Wäre letzteres o.k.? Ist das didaktisch nicht besser? Man verwendet BX auch im Sprungbefehl sofort sofort.

Das erscheint ja auch etwas merkwürdig:
Code:
mov [bootdrive], dl ; boot drive from DL
...
mov dl,[bootdrive] ; select boot drive

Man könnte den Kernel wohl auch von anderer Stelle laden?
Da unser System dies nicht macht, könnte man [bootdrive] doch auch völlig weg lassen?

Label load_kernel1 kann jetzt ja auch entfallen nach Nobuos Änderung?

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 10:35:14 05.10.2013, insgesamt 6-mal bearbeitet
Cortex-M3 Fan
Unregistrierter




Beitrag Cortex-M3 Fan Unregistrierter 10:04:23 23.03.2009   Titel:              Zitieren

^^mannomann. ist das ein grausames gefrickel hier!
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 11:11:08 23.03.2009   Titel:              Zitieren

Zitat:
ist das ein grausames gefrickel hier!

Destruktive (Troll-)Beiträge werden mich nicht aufhalten oder irritieren. :D
Bessere Ideen bezüglich der Umsetzung oder Gesasmtkonstruktion sind dennoch gerne gesehen. :)
Begründe mir lieber mal jemand, warum IBM das Boot-Programm genau nach 7C00h gesendet hat. Die exakte Erklärung habe ich bisher noch nirgends gefunden.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
Nobuo T
Moderator

Benutzerprofil
Anmeldungsdatum: 09.10.2001
Beiträge: 4762
Beitrag Nobuo T Moderator 11:26:12 23.03.2009   Titel:              Zitieren

Naja, mit dem Wegoptimieren muss man immer aufpassen. Das ist sehr oft auch ein Kompromiss zwischen Stabilitaet, Kompatibilitaet und Optimierung, der einen gewisser "Verhaeltnisbereich" IMHO nicht verlassen sollte.

Erhard Henkes schrieb:

Wir schreiben den Offset der Sprung-Adresse des Kernels nachs BX.
Später springen wir ohne Verwendung dieses Registers.
Code:
mov bx, 0x8000     ; set up start address of kernel
;...
jmp 0x0000:0x8000   ; address of kernel

ES:BX ist notwendig für int 0x13 als "Buffer Address Pointer".
So läuft es auf jeden Fall auch:
Code:
mov bx, 0x8000     ; set up start address of kernel
;...
jmp bx   ; address of kernel

Wäre letzteres o.k.? Ist das didaktisch nicht besser? Man verwendet BX auch im Sprungbefehl sofort sofort.


Im Code vor dem long jump zum Kern, kommen wir ganz gut zurecht, ohne genau zu wissen, welchen Wert cs hat, da alle Spruenge etc. nur relativ zum aktuellen Offset (IP) adressieren. Wenn du aber den Sprung ueber bx machst, hast du ein absolutes Offset zu CS und musst dir daher sicher sein, dass cs auch 0 ist. Sonst schiesst du am Ziel vorbei. ;)
Kann also sein, dass das funktioniert. Die Chancen stehen aber auch nicht schlecht, dass es das auf anderen PCs nicht tut.

Erhard Henkes schrieb:

Das erscheint ja auch etwas merkwürdig:
Code:
mov [bootdrive], dl ; boot drive from DL
...
mov dl,[bootdrive] ; select boot drive

Man könnte den Kernel wohl auch von anderer Stelle laden?
Da unser System dies nicht macht, könnte man [bootdrive] doch auch völlig weg lassen?

Bei der ersten Verwendung hatte ich die Sache in deinem alten Code auch auskommentiert (z. 16). Beim 2. Mal bin ich nicht sicher, ob dl vom Interrupt nicht geschrottet wird.

Ansonsten ist das wieder eine Kompatibilitaetsfrage. Du kannst natuerlich die Info des BIOS wegschmeissen, dl einfach immer auf 0 (fdd A:) setzen und damit ausschliessen, dass jemand den Code jemals von was Anderem (2. Floppy, USB oder was auch immer) startet, aber IMHO sind es diese 2 Zeilen irgendwie nicht wert.
Deshalb habe ich sie drin gelassen.

Erhard Henkes schrieb:

Label load_kernel1 kann jetzt ja auch entfallen nach Nobuos Änderung?

Da hast du allerdings recht.


Erhard Henkes schrieb:

@+gjm+:
Das klingt ja echt abenteuerlich! :D
Findet man dazu bereits einen Link im Internet oder ist das Geheimwissen?
Wie läuft denn da die genaue Adressierung im zurück geschalteten RM ab?

Nunja, IMHO eher ein glitch denn ein echtes feature. Gelegentlich findet man die Sache als "Flat Real Mode", "Unreal Mode" oder auch "Voodoo Mode" bezeichnet und in alten, frickeligen DOS-Spielen oder Demos verwendet.
Hier gibt es etwas darueber zu lesen.

Erhard Henkes schrieb:

Begründe mir lieber mal jemand, warum IBM das Boot-Programm genau nach 7C00h gesendet hat. Die exakte Erklärung habe ich bisher noch nirgends gefunden.

Vermutung:
Historische Ursachen. Es war einfach das obere Ende des RAMs (32kb).

_________________
==Mod im Assembler-Forum==

http://z0r.de/2908


Zuletzt bearbeitet von Nobuo T am 11:28:24 23.03.2009, insgesamt 1-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 12:09:58 23.03.2009   Titel:              Zitieren

Hallo Nobuo T, danke für deine Antwort. Bei mir wurde DL nicht geschrottet (sind die BIOS-Interrupts nicht gleich realisiert?), der Sprung mit BX alleine klappte ebenfalls. OK, ich werde auf Dich hören und das nur als Kommentar angeben. Load_kernel1 wird gestrichen. Danke für die Links! Voodoo ... :D

So sieht der bootloader nun (endgültig) aus:
http://www.henkessoft.de/OS_Dev/OS_Dev1.htm#mozTocId80121

Ich bitte um Check des Kernels:
http://www.henkessoft.de/OS_Dev/OS_Dev1.htm#mozTocId412221
(@Nobuo T: Abfrage eines Keystroke vor Reboot bei 'exit' wurde bereits eingebaut. Danke für den Hinweis!)

Noch eine andere didaktische Frage: Die Bezeichnungen KB, MB etc. sind ja inzwischen nicht mehr eindeutig, vor allem bei MB, GB. Würdet ihr auf KiB, MiB, GiB etc. umsteigen? Die Akzeptanz dieses neuen Vorschlages ist ja noch gering.
http://de.wikipedia.org/w ....... -Pr.C3.A4fixe_zur_Basis_2

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 21:03:53 10.10.2013, insgesamt 6-mal bearbeitet
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 16:50:49 23.03.2009   Titel:              Zitieren

Erhard Henkes schrieb:

Als kleine Belohnung für die, die hier mitlesen:
http://bazonline.ch/digit ....... 8752&pageID=1&n=1
(sehr schöne nostalgische Fotostrecke zum Thema Computer und Werbung)

hihi, uralt-computer passen schon irgendwie zu diesem thread.
hier gibts übrigens noch mehr davon: http://www.computerhistor ....... tions/marketingbrochures/
:)
Mr X
Mitglied

Benutzerprofil
Anmeldungsdatum: 18.09.2007
Beiträge: 1712
Beitrag Mr X Mitglied 18:06:48 23.03.2009   Titel:              Zitieren

Hallo,
Das Tutorial gefällt mir sehr gut :)

Als Alternative zu Bochs und VirtualPC kann ich noch VirtualBox empfehlen (kostenlos).
Funktionierte bei mir auf Anhieb. Um die Bootdiskette einzubinden muss diese nochnichtmal in ein Image verpackt sein...

mfg
Mr X
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 19:37:26 23.03.2009   Titel:              Zitieren

Mr X schrieb:
... Das Tutorial gefällt mir sehr gut :) ... Als Alternative zu Bochs und VirtualPC kann ich noch VirtualBox empfehlen (kostenlos). Funktionierte bei mir auf Anhieb. Um die Bootdiskette einzubinden muss diese noch nicht mal in ein Image verpackt sein ...

Danke für das positive Feedback :) und den Tipp mit VirtualBox. Das werde ich mir anschauen. Denn gerade diese Dinge sind didaktisch wichtig, denn jedes Emulations-Programm hat seine Schwächen und Stärken. Nur wenn Theorie, Praxis und Tools Hand in Hand gehen, macht die Sache Freude und treibt die Kreativität vorwärts.

Nun habe ich auch die gtd.inc beschrieben, ein echtes Bit-Gefrickel.
http://www.henkessoft.de/OS_Dev/OS_Dev1.htm#mozTocId398766
Bitte schaut mal drüber, ob ich keinen Fehler gemacht habe.

Jetzt fehlt noch die Erklärung des Kernel-Codes.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 19:49:50 23.03.2009   Titel:              Zitieren

@Nobuo T: An dem Punkt bin ich auch schon ins Grübeln gekommen, weil dies alles andere als intuitiv ist. Hier kam genau dazu eine Frage aus einem anderen internationalen Forum:
http://forum.osdev.org/vi ....... 9451&p=152668#p152668
Zitat:

One thing that caught my eye is this:

Code:
xor ax, ax
[...]
mov ss, ax
mov sp, ax
[...]
call print_string

You zero SS and SP and then you use the stack (implicitly by CALL). That looked strange first. It's not broken, but it is not very intuitive. Maybe you want to consider to note this in your text (I didn't see anything about that, maybe I just missed it) and explain why and how that works.

Vielleicht kannst Du da noch etwas zu Deiner Idee erläutern. Da klafft noch eine "didaktische Lücke". :D
Das Thema Stack würde ich gerne auch noch beschreiben (Prinzip, SS, SP, Nutzung durch call, ...). Ich war allerdings über deine Lösung so verblüfft, dass ich erst mal genauer hinschauen wollte.

Auch diese Zeile wirkt auf den ersten Blick merkwürdig.
add sp, -0x40 ; make room for input buffer (64 chars)

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 20:33:49 23.03.2009, insgesamt 1-mal bearbeitet
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 22:22:18 23.03.2009   Titel:              Zitieren

Erhard Henkes schrieb:

Auch diese Zeile wirkt auf den ersten Blick merkwürdig.
add sp, -0x40 ; make room for input buffer (64 chars)

na, so machste platz auf'm stack. macht ein c-compiler z.b auch so ähnlich, wenn du ein lokales array aus 64 bytes anlegst.
:)
Mr X
Mitglied

Benutzerprofil
Anmeldungsdatum: 18.09.2007
Beiträge: 1712
Beitrag Mr X Mitglied 23:07:22 23.03.2009   Titel:              Zitieren

Zum Thema Emulatoren könntest Du doch ein eigenes Kapitel machen, indem kurz beschrieben wird, wie man damit das OS zum laufen kriegt und welche Vor-/Nachteile das Programm hat, anstatt gelegentlich zwischendurch weitere Emulatoren vorzustellen...
Piscu
Unregistrierter




Beitrag Piscu Unregistrierter 23:16:10 23.03.2009   Titel:              Zitieren

@fricky: SP dürfte aber zu dem zeitpunkt auf 0 sein, weshalb das subtrahieren von 40h (= addieren von -40h?) komisch ist.
Zumindestens kommt es mir komisch vor, wo liegt der (mein) denkfehler?
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 23:35:25 23.03.2009   Titel:              Zitieren

Zitat:
Zum Thema Emulatoren könntest Du doch ein eigenes Kapitel machen, indem kurz beschrieben wird, wie man damit das OS zum laufen kriegt und welche Vor-/Nachteile das Programm hat, anstatt gelegentlich zwischendurch weitere Emulatoren vorzustellen...
Ja, ist mir auch aufgefallen. Ursprünglich wollte ich nur Bochs verwenden, allerdings sind die Emulatoren so wichtig, dass man alle vorstellen sollte. Werde das konzentrieren. Allerdings erst hinten, denn vorne lenkt das doch stark ab. Nicht jeder arbeitet gerne gleichzeitg mit 10-15 Tools. ;)

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 23:39:42 23.03.2009   Titel:              Zitieren

Zitat:
na, so machste platz auf'm stack.
Das man den Stackpointer nach "unten" wandern lässt, um Platz zu schaffen, ist klar. Aber wie gesagt, ist der Wert vorher bei 0, wenn ich nicht irre. Also hinterher -40. Warten wir auf den Kommentar von Nobuo T. Das hat er genial "verbrochen". Vorher hatten wir den Stack bei 0x90000 (http://www.henkessoft.de/OS_Dev/Bilder/Speicherbelegung.JPG), wo viele ihn hin knallen. Unten bei 0 ist doch auch die IVT. Aber es läuft, das ist die Hauptsache, die theor. Erklärung kommt sicher noch. Vielleicht ein genialer "wrap" :D

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 23:50:03 23.03.2009, insgesamt 6-mal bearbeitet
Nobuo T
Moderator

Benutzerprofil
Anmeldungsdatum: 09.10.2001
Beiträge: 4762
Beitrag Nobuo T Moderator 23:39:59 23.03.2009   Titel:              Zitieren

Richtig, +fricky. Push macht Platz auf dem Stack, indem 2 (oder 4, oder wie gross der Operand auch immer ist) Byte von (e)sp subtrahiert werden und schreibt dann den Operand dann nach ss:(e)sp.
Hier wird halt nur Platz auf dem Stack reserviert, erstmal ohne was rein zu schreiben.

Zu ss und sp mit 0 initialisieren:
Ist vielleicht nicht sofort intuitiv, aber hier IMHO ziemlich praktisch.
Wie gesagt hat man es beim x86 mit einem full descending stack zu tun. Wenn also bei sp=0 etwas auf den Stack gepackt wird, gibt es beim Subtrahieren von sp erstmal einen schoenen Ueberlauf, bzw. wrap-arround: zB. 0 - 2 = 0xFFFE. Genau da landet dann der erste Wert.

Der Code sieht ansonsten beim ersten drueber schauen ganz gut aus. Aber meine msg00 haettest du eigentlich auch gleich ganz loeschen koennen, statt sie nur zu verschieben. War da nur zu debug-zwecken. Die Ausgabe habe ich wie es aussieht auch wieder entfernt, aber den Text vergessen. :D

Und zum Teil ueber die A20 zunaechst noch: Ueber die Ports 60h und 64h sprichst du erstmal nur mit dem Controller auf dem Mainboard. Darueber kannst du dann (seriell) etwas an die Tastatur schicken. Und D1 an 64h ist einfach ein Kommando, das bewirkt, dass das naechste Byte auf Port 60h beim outputport landet, statt bei der Tastatur.

edit: Hui, haette nicht gedacht, dass einfache Integer-Arithmetik (signed/unsigned Addition vs. Subtraktion und Ueberlaeufe) hier fuer solche Verwirrung sorgt. :confused:
Oder hat das damit zu tun, dass da der Stack involviert ist? Das spielt wie gesagt in dem Zusammenhang ueberhaupt keine Rolle.

_________________
==Mod im Assembler-Forum==

http://z0r.de/2908


Zuletzt bearbeitet von Nobuo T am 23:44:38 23.03.2009, insgesamt 2-mal bearbeitet
abc.w
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2008
Beiträge: 1366
Beitrag abc.w Mitglied 23:43:51 23.03.2009   Titel:              Zitieren

Habe mal die zip Datei 20090321_eh_os.zip runtergeladen, Makefile ein wenig angepasst (wegen meiner nasm Installation), das ganze mit meinen Werkzeugen gebaut und mit den binär Dateien in der zip-Datei verglichen. Alles gleich :)
Unter bochs ausprobiert - es läuft.
Nun wollte ich mal mit ndisasm ein wenig disassemblieren, hie und da mal schauen und schon gibt es ein kleines "Problem" mit kernel.bin. In der kernel.asm gibt es ja mal 16-Bit, mal 32-Bit Code, was mit [Bits 32] und [BITS 16] "umgeschaltet" wird. Nun, ndisasm kommt damit nicht klar oder ich kenne noch nicht die Möglichkeit, wie man es hinkriegt, dass alles zusammen sauber disassembliert wird... Wäre vielleicht ein Splittern der kernel.asm in zwei Dateien sinnvoll? Eine mit [BITS 16], die andere mit [BITS 32]?
Eine Sache bezüglich Disassemblieren noch: Am Ende des Bootloaders und des Kernels wird mit Nullen aufgefüllt (X ist 510 oder 1024):
Code:
times X-($-$$) db 0

Was würde gegen z.B. so was sprechen:
Code:
times X-($-$$) hlt

Also Auffüllen mit HLT-Befehlen... Ist nur ein Vorschlag, aber ich persönlich sehe ein Paar Vorteile:
- beim Disassemblieren sieht man sofort, wo das Ende ist (ok, mit Nullen sieht man es auch, aber man hat lauter add [bx+si],al stehen, was irgendwie unschön ist)
- zumindest psychologische Wirkung, man fühlt sich ruhiger, weil, wenn die CPU dort warum auch immer ankommt, bleibt sie dort stehen und es passiert nichts :)
Nobuo T
Moderator

Benutzerprofil
Anmeldungsdatum: 09.10.2001
Beiträge: 4762
Beitrag Nobuo T Moderator 00:03:36 24.03.2009   Titel:              Zitieren

abc.w schrieb:

Nun wollte ich mal mit ndisasm ein wenig disassemblieren, hie und da mal schauen und schon gibt es ein kleines "Problem" mit kernel.bin. In der kernel.asm gibt es ja mal 16-Bit, mal 32-Bit Code, was mit [Bits 32] und [BITS 16] "umgeschaltet" wird. Nun, ndisasm kommt damit nicht klar oder ich kenne noch nicht die Möglichkeit, wie man es hinkriegt, dass alles zusammen sauber disassembliert wird...

Ja, ist ein Problem. Die Situation hat man auch nicht all zu haeufig, dass man 16- und 32-Bit code in einem binary hat.
Ehrlich gesagt bin ich in die Verlegenheit auch noch nicht wirklich gekommen, bzw. hoechstens in einem Debugger - den kann man oft bei Bedarf umschalten.

abc.w schrieb:

Wäre vielleicht ein Splittern der kernel.asm in zwei Dateien sinnvoll? Eine mit [BITS 16], die andere mit [BITS 32]?

Problem beim Aufteilen waere, dass man entweder beim 2. Teil mit dem Start-Offet (org) aufpassen muesste, oder Verschnitt haette, wenn man es an eine groessere, festgelegte Adresse packt.
Da ist die uebersichtliche Disassemblierbarkeit mit einem einfachen disasm IMHO irgendwie nachrangig.

abc.w schrieb:

Eine Sache bezüglich Disassemblieren noch: Am Ende des Bootloaders und des Kernels wird mit Nullen aufgefüllt (X ist 510 oder 1024):
Code:
times X-($-$$) db 0

Was würde gegen z.B. so was sprechen:
Code:
times X-($-$$) hlt

Also Auffüllen mit HLT-Befehlen... Ist nur ein Vorschlag, aber ich persönlich sehe ein Paar Vorteile:
- beim Disassemblieren sieht man sofort, wo das Ende ist (ok, mit Nullen sieht man es auch, aber man hat lauter add [bx+si],al stehen, was irgendwie unschön ist)
- zumindest psychologische Wirkung, man fühlt sich ruhiger, weil, wenn die CPU dort warum auch immer ankommt, bleibt sie dort stehen und es passiert nichts :)

Naja, grundsaetzlich vielleicht nicht schlecht, was die Uebersicht beim Disassemblieren betrifft, hat aber ansonsten nicht viel Zweck. Ob der Rechner nun stehen bleibt bis zum naechsten IRQ oder gleich ein wenig dummes Zeug rechnet ist bei so einem gravierenden Problem dann wohl auch ein wenig egal. :p

_________________
==Mod im Assembler-Forum==

http://z0r.de/2908
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 00:10:46 24.03.2009   Titel:              Zitieren

Jungs, ihr seid richtig kreativ! Macht richtig Spaß mit euch. Der eine baut einen Wrap in den Stack, dass den Profis vom osdev.org der Verstand stehen bleibt und ein anderer schlägt "times X-($-$$) hlt" vor. :D

Das mit dem Stack auf 0 habe ich bisher noch nicht gesehen, finde es aber richtig gut. Ich habe es mir einfach als wrap vorgestellt, wie damals beim A20-Gate.

Ich habe mal "times X-($-$$) hlt" in Google eingegeben. Null Fundstellen!
Das ist doch echt ein Grund, dies zu verwenden. ;) Die massenweise F4 im Hex-Editor sehen richtig lustig aus: http://www.henkessoft.de/OS_Dev/Bilder/boot_bin_hex.JPG

@abc.w: die "hlt" sind schon im Tut eingebaut und hochgeladen. :live:

Die msg00 ist schon entfernt (ich hatte sie mal aufgehoben, weil ich dachte vielleicht bauen wir sie didaktisch noch ein, so mit keystroke und weiter ...). :D

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 00:28:32 24.03.2009, insgesamt 3-mal bearbeitet
Nobuo T
Moderator

Benutzerprofil
Anmeldungsdatum: 09.10.2001
Beiträge: 4762
Beitrag Nobuo T Moderator 00:22:38 24.03.2009   Titel:              Zitieren

Erhard Henkes schrieb:
Jungs, ihr seid richtig kreativ! Macht richtig Spaß mit euch. Der eine baut einen Wrap in den Stack, dass den Profis vom osdev.org der Verstand stehen bleibt und ein anderer schlägt "times X-($-$$) hlt" vor. :D

Tja, in der Tat. :D So viel war hier schon laenger nicht mehr los. Ist AFAIR uebrigens inzwischen auch der laengste Thread in diesem Forum. :live:

_________________
==Mod im Assembler-Forum==

http://z0r.de/2908
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 00:55:45 24.03.2009   Titel:              Zitieren

Zitat:
Ich habe mal "times X-($-$$) hlt" in Google eingegeben. Null Fundstellen!
Das X muss man natürlich ersetzen:
"times 510-($-$$) db 0" 380 Fundstellen (auch nicht gerade viel, wir sind schon dabei)
"times 510-($-$$) hlt" 1 Fundstelle: http://kldp.org/node/89199 (leider sind wir nicht Erster! :rolleyes: )

"times 1024-($-$$) db 0" 20 Fundstellen
"times 1024-($-$$) hlt" 0 Fundstellen

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 01:00:21 24.03.2009   Titel:              Zitieren

Zitat:
Und zum Teil ueber die A20 zunaechst noch: Ueber die Ports 60h und 64h sprichst du erstmal nur mit dem Controller auf dem Mainboard. Darueber kannst du dann (seriell) etwas an die Tastatur schicken. Und D1 an 64h ist einfach ein Kommando, das bewirkt, dass das naechste Byte auf Port 60h beim outputport landet, statt bei der Tastatur.


Ich habe das nun hoffentlich klar genug dargestellt:
http://www.henkessoft.de/OS_Dev/OS_Dev1.htm#mozTocId13510

Hier würde ein Bild helfen. Muss mal nachdenken.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
Unregistrierter





Beitrag Unregistrierter 01:19:17 24.03.2009   Titel:              Zitieren

Hier ein kleiner Hinweis zur Übersicht:
Assembler:
loop:
 
(...)
 
 jmp loop :confused:
Es verwirrt beim Lesen wenn ein Labelname wie ein Opcode klingt. Es wäre vielleicht besser, Opcodenamen wie "Reservierte Worte" nicht als Bezeichner zu verwenden.

Noch was zum "Voodoo-Mode": :)
Drauf verlassen kann man sich ja, solange eben nichts und niemand die Segmentregister verändert. Das wäre z.B. der Fall, wenn man vorhat, ein RM-OS zu schreiben *wegduck* und dann das Format für ausführbare Programme selbst festlegt. Oder (viel einfacher) bei bootfähigen Programmen, die die Hardware testen, oder wirklich schnell mal eine Zahl ausrechnen sollen.
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 01:21:27 24.03.2009   Titel:              Zitieren

Zitat:
Es verwirrt beim Lesen wenn ein Labelname wie ein Opcode klingt. Es wäre vielleicht besser, Opcodenamen wie "Reservierte Worte" nicht als Bezeichner zu verwenden.
Sehr guter Hinweis. Wird geändert.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
Christoph
Moderator

Benutzerprofil
Anmeldungsdatum: 30.04.2001
Beiträge: 6045
Beitrag Christoph Moderator 01:24:57 24.03.2009   Titel:              Zitieren

@Erhard Henkes:
Die Screenshots auf deiner Webseite würde ich eher im PNG-Format abspeichern und nicht als JPEG. Das hätte folgende Vorteile gegenüber JPEG:
1) Keine unscharfen Kanten, Text bleibt daher gut lesbar.
2) Oft kleinere Dateigröße.

_________________
Wenn Word für Längeres geeignet wäre, würde es nicht Word, sondern Sentence, Page oder Article heißen.
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 02:25:08 24.03.2009   Titel:              Zitieren

Zitat:
Die Screenshots auf deiner Webseite würde ich eher im PNG-Format abspeichern und nicht als JPEG
Danke für den Tipp :live:
EDIT: Ist deutlich performanter als JPG. Werde mich wohl umgewöhnen müssen. ;)

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 22:20:40 24.03.2009, insgesamt 1-mal bearbeitet
Unregistrierter





Beitrag Unregistrierter 03:27:52 24.03.2009   Titel:              Zitieren

Noch etwas zur Integer-Arithmetik (signed/unsigned Addition vs. Subtraktion).
Weitergeführt bis zum "Ende" würde die "RealMode" dann in etwa aussehen wie folgt:
Assembler:
RealMode:
 add sp, -0x40     ; space for input buffer (64 chars)
(...)
 add sp,  0x40     ; clean it, please
 ret
Besser wäre da die "klassische" (und verständliche) Logik:
Assembler:
RealMode:
 sub sp,  0x40     ; space for input buffer (64 chars)
(...)
 add sp,  0x40     ; clean it, please
 ret
Nobuo T
Moderator

Benutzerprofil
Anmeldungsdatum: 09.10.2001
Beiträge: 4762
Beitrag Nobuo T Moderator 14:49:19 24.03.2009   Titel:              Zitieren

Ob nun sub oder add ist in diesem Fall wohl reine Geschmackssache. Ich versuche sub wenn moeglich aus dem Weg zu gehen, da ich das uebersichtlicher finde (es gehen auch Mythen ueber einen Geschwindigkeitsvorteil um...).
Und wer nicht erkennt, dass
+(-40) == -(+40)
ist, hat noch andere Probleme als sich mit OS-Entwicklung zu befassen. :D
Was hat das mit "klassischer Logik" zu tun?

Was das "clean please" betrifft: Hast natuerlich prinzipiell recht. So wuerde/koennte man das sauber in einer Prozedur mit lokalen Variablen loesen. Evtl. koennte man einen entsprechenden Kommentar platzieren.
Der Code fuer den Prompt (was du wohl "RealMode" nennst?) ist allerdings keine klassische Prozedur und hat deshalb auch keinen Ausgang, bei dem das irgendwie sinnvoll unterzubringen waere. Anders ausgedrueckt: Wenn der Prompt verlassen und der angelegte Puffer damit nicht mehr gebraucht wird, also freigegeben werden koennte, wird jedes Mal der RM-Stack unmittelbar danach eh eingestampft.
Assembler ist in der Hinsicht nun mal einfach keine Sprache fuer Sauberkeitsfanatiker. :D

_________________
==Mod im Assembler-Forum==

http://z0r.de/2908
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 15:27:59 24.03.2009   Titel:              Zitieren

wann geht's denn nun endlich mit dem OS los?
:)
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 16:08:12 24.03.2009   Titel:              Zitieren

Zitat:
wann geht's denn nun endlich mit dem OS los?

Zunächst habe ich die Code-Abschnitte erklärt, z.B. die "Zeigermechanik" bezüglich des Selektors auf die Deskriptoren-Tabelle. In vielen anderen Artikeln findet man
Code:
jmp [b]0x8[/b]:ProtectedMode
und
Code:
mov    ax, [b]0x10[/b]
    mov    ds, ax      ; data descriptor --> data, stack and extra segment
    mov    ss, ax            
    mov    es, ax
, und niemand erklärt, woher die 0x8 oder 0x10 eigentlich kommen, fallen einfach vom Himmel. Die Berechnung habe ich mittels Abbildung zum Selektoraufbau und Linksshift mit dem wissenschaftlichen "Calculator" nun hoffentlich klar genug dargestellt.
http://www.henkessoft.de/OS_Dev/OS_Dev1.htm#mozTocId533818 please check ;)

Didaktisch bin ich noch nicht völlig zufrieden, da muss noch einiges klarer gezeichnet und umgestellt werden.
Von dieser Seite ( http://forum.osdev.org/viewtopic.php?f=1&t=19451 ) kommen auch noch einge Randbemerkungen.

Nun ist aber immerhin eine ansprechende Basis mit eingeschaltetem A20 Gate und Protected Mode entstanden, die sich allerdings noch völlig autistisch verhält. :D
Die nächsten Schritte werden dem Kernel die Innen- und Außenwelt systematisch öffnen. Ich denke hier gerade über das Was, Wie, Wann und ASM vs C und die Aufgliederung der Module nach. Auf jeden Fall möchte ich den didaktischen Aspekt ganz vorne sehen. Daher würde mich interessieren, wie Einsteiger ohne Erfahrungen in OS Development das Tutorial bisher einschätzen.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 16:59:20 24.03.2009, insgesamt 4-mal bearbeitet
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 17:08:37 24.03.2009   Titel:              Zitieren

Erhard Henkes schrieb:

Die nächsten Schritte werden dem Kernel die Innen- und Außenwelt systematisch öffnen. Ich denke hier gerade über das Was, Wie, Wann und ASM vs C und die Aufgliederung der Module nach.

ok, als faustformel: alles was in C nicht so toll geht, machste in asm (z.b. umschaltung der tasks), alles andere in C. weil du ja x86 benutzt, sollteste dann auch auf die 'task state segmente' eingehen.
:)
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 20:22:16 24.03.2009   Titel:              Zitieren

@+fricky: Danke für Deine Ratschläge. :)

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 21:39:49 24.03.2009   Titel:              Zitieren

Erhard Henkes schrieb:
@+fricky: Danke für Deine Ratschläge.

keine ursache. es gibt übrigens auch kernels, die ganz ohne asm auskommen. such mal nach protothreads/contiki und das hier:
http://www.nilsenelektronikk.no/nenesos.html
:)
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 22:32:31 24.03.2009   Titel:              Zitieren

Zitat:
Contiki is designed for microcontrollers with small amounts of memory. A typical Contiki configuration is 2 kilobytes of RAM and 40 kilobytes of ROM.
Ist mir schon klar, wo ich mich bei dem x86-Gerödel befinde. Das Programm oder OS wird dann eben ins EEPROM geflasht (mache ich beim Asuro oder Nibo auch: http://www.henkessoft.de/ ....... shen_Ausschnitt_small.jpg ) anstelle von Floppy oder Hard Disk gebootet. Übrigens sehe ich ASM nicht als Nachteil für den bisherigen OS Start.

Mal eine andere Frage: Kennt sich jemand mit Qemu aus? Ich habe es bisher nicht geschafft, das OS damit zu booten. Lohnt es sich, sich damit herum zu quälen?

Zum Debuggen erscheint mir der Bochs Debugger momentan ideal.
@Nobuo T: Wie debuggst Du bei solchen Entwicklungen genau?

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 23:08:16 24.03.2009, insgesamt 3-mal bearbeitet
Unregistrierter





Beitrag Unregistrierter 02:38:32 25.03.2009   Titel:              Zitieren

Im Abschnitt über die A20-Leitung ist mir folgendes aufgefallen:

Es fehlt der definitive Grund, warum sie unbedingt im PM aktiviert sein muß. Ich will es mal so formulieren: Im PM kann ich auf die paar Byte, die die A20-Leitung adressiert, auch gerne verzichten. Aber warum sollte ich das lieber nicht? :)
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 10:54:38 25.03.2009   Titel:              Zitieren

Erhard Henkes schrieb:
Zitat:
Contiki is designed for microcontrollers with small amounts of memory. A typical Contiki configuration is 2 kilobytes of RAM and 40 kilobytes of ROM.
Ist mir schon klar, wo ich mich bei dem x86-Gerödel befinde. Das Programm oder OS wird dann eben ins EEPROM geflasht (mache ich beim Asuro oder Nibo auch: http://www.henkessoft.de/ ....... shen_Ausschnitt_small.jpg ) anstelle von Floppy oder Hard Disk gebootet.

naja, das waren ja nur beispiele, für nicht-preemptive kernels, die entweder continuations oder state machines für's task-switching benutzen. sowas muss nicht unbedingt ins flash, man kann's auch vom laufwerk booten.

Zitat:
Übrigens sehe ich ASM nicht als Nachteil für den bisherigen OS Start.

nachteil ist, je mehr asm du einsetzt, desto mehr nagelst du dein OS auf einen spezifischen prozessor fest. und wenn du so, wie bis jetzt, weiter machst, kannste dein tutorial bald in 'die geheimen tricks der x86-assembler gurus' umtaufen.
:)
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 20:58:37 25.03.2009   Titel:              Zitieren

Zitat:
Es fehlt der definitive Grund, warum sie unbedingt im PM aktiviert sein muß. Ich will es mal so formulieren: Im PM kann ich auf die paar Byte, die die A20-Leitung adressiert, auch gerne verzichten. Aber warum sollte ich das lieber nicht?


Im Protected Mode kann man problemlos mit 32 Bit arbeiten. Daher muss man das A20-Gate wieder aktivieren, da ansonsten bei bestimmten Speicherzugriffen Fehler auftreten, da die 21. Adressleitung deaktiviert ist. Das bedeutet, das man auf eine andere Speicherstelle zugreifen kann als beabsichtigt. Daher schaltet man A20 ein, bevor man den Kernel und weitere Programmteile startet. Ist das so o.k.?

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 20:59:59 25.03.2009, insgesamt 1-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 20:59:24 25.03.2009   Titel:              Zitieren

Zitat:
wenn du so, wie bis jetzt, weiter machst, kannste dein tutorial bald in 'die geheimen tricks der x86-assembler gurus' umtaufen.
Ja, da hast Du evtl. Recht.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
Mr X
Mitglied

Benutzerprofil
Anmeldungsdatum: 18.09.2007
Beiträge: 1712
Beitrag Mr X Mitglied 22:49:21 25.03.2009   Titel:              Zitieren

@Erhard Henkes: Inwiefern nervt Sund VirtualBox eigentlich bei dir mit Werbung?
Bei mir erscheinen nur gelegentlich Tipps und Hinweise auf Updates, ich finde diese Passage zur Werbung daher etwas übertrieben...
abc.w
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2008
Beiträge: 1366
Beitrag abc.w Mitglied 00:01:45 26.03.2009   Titel:              Zitieren

Erhard Henkes schrieb:
Zitat:
wenn du so, wie bis jetzt, weiter machst, kannste dein tutorial bald in 'die geheimen tricks der x86-assembler gurus' umtaufen.
Ja, da hast Du evtl. Recht.

Ich denke, jeder verfolgt beim Programmieren seine eigene Philosophie. Und in Assembler ist es irgendwie so, je länger man sich damit beschäftigt, desto verschwommener wird die Grenze "tricks" und "normal".
Zum Beispiel einfache Zeile aus kernel.asm:
Code:
    xor cx, cx

Warum nicht einfach:
Code:
    mov cx, 0

Oder noch eine Zeile:
Code:
  or cl, cl     ; zero? (start of the string)

Warum nicht einfach:
Code:
    cmp cl, 0

Und man braucht nicht einmal ein Kommentar dazu. Jeder, der es liest, sieht sofort: compare irgendwas mit Null.
Ich habe bei mir persönlich festgestellt, je "idiotensicherer" der Code geschrieben, desto weniger Kommentare und noch weniger Zeit beim Debuggen. Aber das ist wiederum meine "Philosophie".
Nobuo T
Moderator

Benutzerprofil
Anmeldungsdatum: 09.10.2001
Beiträge: 4762
Beitrag Nobuo T Moderator 01:39:24 26.03.2009   Titel:              Zitieren

IMHO, wer mit so einer Philosophie anfaengt (x86)Asm zu programmieren, kann irgendwo nicht wirkliche viel Ahnung von der Plattform haben, fuer die er da programmiert und ist daher wohl besser beraten, es bleiben zu lassen und auf eine abstrakte Hochsprache umzusteigen, in der derart "idiotensichererer Code" in der Performance nicht so kontraproduktiv, und auch allgemein viel effektiver uebersichtlicher zu gestalten ist.
So ist das doch einfach eine billige Ausrede fuer schlechten Code.

edit: Ack volkard. Auch ein guter Vergleich. :)

_________________
==Mod im Assembler-Forum==

http://z0r.de/2908


Zuletzt bearbeitet von Nobuo T am 01:52:16 26.03.2009, insgesamt 2-mal bearbeitet
volkard
Mitglied

Benutzerprofil
Anmeldungsdatum: 06.04.2000
Beiträge: 29842
Beitrag volkard Mitglied 01:47:49 26.03.2009   Titel:              Zitieren

wer
Code:
xor cx, cx

verschmäht, weil es angeblich unleserlich wäre, und
Code:
mov cx, 0

vorzieht, der muß in der hochsprache auch
Code:
++c;

meiden und immer brav
Code:
c = c + 1;

schreiben.

_________________
return [ :><%%> ();//c++-trollfish returning void
Ich empfehle dringend, das Problem zu vertagen, bis es akut wird. Dann liegt mehr Erfahrung vor, was wirklich gebraucht wird.
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 02:29:05 26.03.2009   Titel:              Zitieren

Zitat:
Bei mir erscheinen nur gelegentlich Tipps und Hinweise auf Updates, ich finde diese Passage zur Werbung daher etwas übertrieben...
Akzeptiert, werde dies abmildern. Möchte sachlich bleiben, hat mich aber schon ziemlich genervt.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 03:16:33 26.03.2009   Titel:              Zitieren

Wir haben einen noch etwas ausbaubaren Real Mode, auch im PM könnte man in Assembler noch etwas machen, aber ich denke, nun ist es an der Zeit, zu einem in C geschriebenen Kernel zu wechseln.

Als Compiler unter Windows verwende ich den allseits bekannten Compiler DJGPP (2.03 ohne C++). Ist dies das richtige Werkzeug? (Download bei Bona Fide OS Dev.) http://www.osdever.net/do ....... DJGPP-Installer-nocpp.exe

Dazu habe ich eine technische Frage:

Ich habe boot.bin (aufgefüllt auf 512 Byte mit Bootsignatur) und kernel.bin (aufgefüllt auf 1024 Byte).

Dann habe ich ein k(ernel)_entry.asm und ckernel.asm, das via k_entry.o und ckernel.o mittels linker ld zu ckernel.bin gelinkt wird.

Dann packe ich alles zu einer einzigen Binärdatei zusammen, die dann auf Floppy geschrieben wird: copy /b boot.bin + kernel.bin + ckernel.bin MyOS.bin

Der Bootloader lädt sich selbst nach 0x7C00 und den Rest nach 0x8000. Der gelinkte Part mit dem C-Kernel fängt durch die HLT-Auffüllung ab 0x8400 an.

so sieht k_entry.asm aus:
Code:
1
2
3
4
5
6
7
8
9
10
[BITS 32]
 
[global start]
[extern _main] ; this is in the c file
hlt
hlt
hlt
start:
  call _main
  jmp $

Ich kann im bin-Format nicht [extern start] angeben und dann nach start springen: jmp 0x8:0x8000+start

Daher habe ich mir erst mal die drei HLT vor start gebaut, dann kann ich die Startadresse im Hexeditor hinter den "f4f4f4" leicht finden :D und direkt anspringen, z.B.: jmp 0x8:0x86e3; goto C-Kernel (0x8400 + 0x02e3 ist natürlich eine variable Zielscheibe).
Finde das didaktisch interessant, weil man hier zeigen kann, wie die Zusammenhänge im Speicher ganz genau sind und warum man eine Objektdatei benötigt, denn "start" kann man nur dort als externes Label verwenden.

Was ist hier eurer Meinung nach der sauberste Weg?
Benötigt man überhaupt noch eine Zwischen-Datei k(ernel)_entry.asm? (16/32-Bit-Problematik beim ersten Kernel? Außerdem haben wir im ersten Kernel "org 0x8000" verwendet, was wiederum nur im Binär-Format geht)

Gibt es irgendwie einen Trick (außer dem Spicken nach einer optischen Erkennungsmarke in der Binärdatei), dass man aus kernel.bin nach "start" springen kann, also wie gesagt "extern start" klappt nicht im Binär-Format.

Der Sprung von _main nach _main() {...} innerhalb der Objektdateien ist natürlich problemlos.

Wie überwindet man die Grenze bin -> obj mit einem Sprung am saubersten?

EDIT: Inzwischen über Linker und Linkerscript gelöst.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 14:42:29 28.03.2009, insgesamt 6-mal bearbeitet
rapso
Moderator

Benutzerprofil
Anmeldungsdatum: 17.06.2002
Beiträge: 8699
Beitrag rapso Moderator 08:09:46 26.03.2009   Titel:              Zitieren

abc.w schrieb:

Code:
    xor cx, cx

Warum nicht einfach:
Code:
    mov cx, 0

Oder noch eine Zeile:
Code:
  or cl, cl     ; zero? (start of the string)

Warum nicht einfach:
Code:
    cmp cl, 0


das hat nichts mit philosophie zu tun, es generiert anderen code, der andere laufzeit und performance eigenschaften hat. das ist eben der unterschied zwischen cisc und risc.
wenn man diese nicht kennt, macht es nicht soviel sinn etwas in assembler zu schreiben, und das ist kein ding der sprache, sondern der hardware.

auf nem cell sieht du vielleicht
Code:
NOP
OR R1,R1,R1
OR R2,R2,R2

und wunderst dich, wieso nicht einfach immer NOP? Philosophie? vielleicht sogar im gcc?

(und nein, ist kein CISC, ich hab mir das ja auch nicht ausgedacht es so zu machen :P)

_________________
follow me|
-Mod im Spiele-/Grafikprogrammierung
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 09:30:55 26.03.2009   Titel:              Zitieren

abc.w schrieb:

Zum Beispiel einfache Zeile aus kernel.asm:
Code:
    xor cx, cx

Warum nicht einfach:
Code:
    mov cx, 0


weil der erste befehl keinen operanden braucht -> kürzer/schneller
das gehört zum guten ton der assemblerprogrammierung. meistens will man möglichst wenig und möglichst schnellen code haben. na gut, bei den heutigen giga-Hz und -byte x86ern ist sowas natürlich alles egal.
:)
abc.w
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2008
Beiträge: 1366
Beitrag abc.w Mitglied 21:17:21 26.03.2009   Titel:              Zitieren

volkard schrieb:
wer
Code:
xor cx, cx

verschmäht, weil es angeblich unleserlich wäre, und
Code:
mov cx, 0

vorzieht, der muß in der hochsprache auch
Code:
++c;

meiden und immer brav
Code:
c = c + 1;

schreiben.

volkard, vielleicht war es gestern spät bei Dir, oder, nach deiner Schlussvorlgerung zu urteilen, hast Du den Unterschied zwischen Assembler und Compiler nicht verstanden...
rapso schrieb:
auf nem cell sieht du vielleicht
Code:
NOP
OR R1,R1,R1
OR R2,R2,R2

und wunderst dich, wieso nicht einfach immer NOP? Philosophie? vielleicht sogar im gcc?
rapso, wahrscheinlich war es bei Dir auch spät gestern. Ich kenne mich mit ner Cell CPU natürlich nicht aus und finde diese drei Befehle, so wie sie da stehen, hm, ja, hübsch. Ich vermute aber, da es keinen Sinn macht, diese drei Befehle einfach so aus dem Kontext zu entreissen und ohne "Vorgeschichte" und "Nachgeschichte" einfach so zu posten, dass Du deren Bedeutung auch nicht verstanden hast...
Wie dem auch sei, interessant, wie es abgeht, wenn man anfängt, beim Assembler-Gefrickel mal auf den einen oder den anderen Umstand hinzuweisen. Und ich habe mich noch nicht in den ganzen Code eingelesen...
Trotzdem unverständlich, oder vielleicht übersehe ich irgendwas? Nehmen wir den Bootloader z.B., der Zugriff auf die Festplatte ist im ms-Bereich. Sagen wir mal 10 ms. Bei einer 1 GHz CPU entsprechen die 10 ms 10 Millionen Takte. Nehmen wir an, ein CPU Takt entspricht 1 Sekunde, 10 Millionen Takte sind also 10 Millionen Sekunden. Ergibt etwa 115 Tage... Ihr habt jetzt also mit xor ax, ax einen Takt gespart. Also eine Sekunde gespart, um dann 115 Tage zu warten... Kann mich bitte jemand aufklären?
volkard
Mitglied

Benutzerprofil
Anmeldungsdatum: 06.04.2000
Beiträge: 29842
Beitrag volkard Mitglied 21:45:38 26.03.2009   Titel:              Zitieren

abc.w schrieb:
volkard schrieb:
wer
Code:
xor cx, cx

verschmäht, weil es angeblich unleserlich wäre, und
Code:
mov cx, 0

vorzieht, der muß in der hochsprache auch
Code:
++c;

meiden und immer brav
Code:
c = c + 1;

schreiben.

volkard, vielleicht war es gestern spät bei Dir, oder, nach deiner Schlussvorlgerung zu urteilen, hast Du den Unterschied zwischen Assembler und Compiler nicht verstanden...

ach, da ist ein unterschied? bestimmt nur philosophischer natur.
zur sache:
xor reg,reg ist einfach ein festes idiom, das sich mit ein wenig übung sogar schneller liest, als mov reg,0
++var ist einfach ein festes idiom, das sich mit ein wenig übung sogar schneller liest, als var=var+1
diese parallele versuchte ich aufzuzeigen.

_________________
return [ :><%%> ();//c++-trollfish returning void
Ich empfehle dringend, das Problem zu vertagen, bis es akut wird. Dann liegt mehr Erfahrung vor, was wirklich gebraucht wird.
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 22:22:47 26.03.2009   Titel:              Zitieren

Volkard hat im abstrakten Sinne Recht. Es kann nicht sein, dass man performant Assembler schreiben will und dann die Lesbarkeit in den Vordergrund rückt.

Bezüglich der Linker-Geschichte habe ich es jetzt auch endlich geschafft. Ich hatte die Reihenfolge hinter ld falsch angegeben. Konnte auch weiter vereinfachen. Nun ist alles zu meiner Zufriedenheit.

Jetzt gibt es nur noch: bootloader, (asm)kernel and ckernel.
asm- und C-kernel werden zusammen gelinkt. Wichtig ist, dass der asm-kernel binär vorne bei 0x8000 zu liegen kommt. Daher die Reihenfolge ld ... kernel.o ckernel.o Anders hängen die ganzen Strings vorne bei 0x8000 herum.

linker script:
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
OUTPUT_FORMAT("binary")
ENTRY(RealMode)
SECTIONS
{
  .text  0x8000 : {
    *(.text)
  }
  .data  : {
    *(.data)
  }
  .bss  :  {                
    *(.bss)
  }
}



makefile:
Code:
1
2
3
4
5
6
7
8
9
all:
   nasmw -O32 -f bin boot.asm -o boot.bin
   nasmw -O32 -f aout kernel.asm -o kernel.o
   gcc -c ckernel.c -o ckernel.o
   ld -T kernel.ld kernel.o ckernel.o
   rename a.out ckernel.bin
     
   cmd /c copy /b boot.bin + ckernel.bin MyOS.bin
   partcopy MyOS.bin 0 1000 -f0

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 00:36:44 27.03.2009, insgesamt 1-mal bearbeitet
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 22:52:52 26.03.2009   Titel:              Zitieren

abc.w schrieb:

Wie dem auch sei, interessant, wie es abgeht, wenn man anfängt, beim Assembler-Gefrickel mal auf den einen oder den anderen Umstand hinzuweisen.

das nennt man 'best practices' der asm-programmierung, keine umstände. genau so, wie der c++-frickler lieber ++x statt x++ verwendet, obwohl es in vielen fällen keinen unterschied macht.
:)
abc.w
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2008
Beiträge: 1366
Beitrag abc.w Mitglied 23:32:54 26.03.2009   Titel:              Zitieren

+fricky schrieb:

das nennt man 'best practices' der asm-programmierung, keine umstände. genau so, wie der c++-frickler lieber ++x statt x++ verwendet, obwohl es in vielen fällen keinen unterschied macht.
:)

Best practices... Lese grade das hier http://www.win.tue.nl/~aeb/linux/kbd/A20.html
Zitat:
...However, it failed to do this address truncation (a bug), and people found that there existed programs that actually depended on this truncation.

Bestimmt hat einer damals beim Programmieren der 8086er gedacht, wozu in meinem Programm explizit eine Abfrage einbauen, wenn die CPU von selbst eine "address truncation" macht und ich so Takte sparen und dabei perfomant auf die unteren Adressen zugreifen kann... Gängige Praxis, eine Funktion nutzen, die irgendwas vollkommen anderes macht, das eine oder andere Zwischenergebnis in einem ganz bestimmten Sonderfall erzeugt, an den man normalerweise nicht denkt, dessen Zwischenergebnis ich dann doch in meinem Programm benutze und mich darauf verlasse.
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 00:40:41 27.03.2009   Titel:              Zitieren

Also langsam wird's mir unheimlich mit Assembler. :D
Ich habe den Sprung zum "rettenden" C-Kernel nun mit einer rudimentären Ausgabe realisiert:

http://www.henkessoft.de/OS_Dev/OS_Dev1.htm#mozTocId397878 (Text)
http://www.henkessoft.de/OS_Dev/Downloads/20090326_eh_os.zip (Dateien; gcc/ld voraus gesetzt)
Download DJGPP: http://www.osdever.net/do ....... DJGPP-Installer-nocpp.exe

Nun haben wir bootloader, real mode (asm), protected mode (asm) und C als bare bone Gerüst. In C fühle ich mich doch gleich wohler. ;) Erstmal vielen Dank, dass ihr mich bis hierher begleitet habt. Die weitere Entwicklung in C, die natürlich noch signifikant mit Assembler durchsetzt sein wird, passt eigentlich nicht in dieses Sub-Forum. :confused:

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 00:59:20 27.03.2009, insgesamt 3-mal bearbeitet
Professionelle Meinung
Unregistrierter




Beitrag Professionelle Meinung Unregistrierter 01:59:09 27.03.2009   Titel:              Zitieren

Erhard Henkes schrieb:
Die weitere Entwicklung in C, die natürlich noch signifikant mit Assembler durchsetzt sein wird, passt eigentlich nicht in dieses Sub-Forum. :confused:



Das wird dir niemand übel nehmen, dieser Thread ist das Beste seit langem. Weitermachen!
volkard
Mitglied

Benutzerprofil
Anmeldungsdatum: 06.04.2000
Beiträge: 29842
Beitrag volkard Mitglied 02:06:50 27.03.2009   Titel:              Zitieren

Professionelle Meinung schrieb:
Das wird dir niemand übel nehmen, dieser Thread ist das Beste seit langem. Weitermachen!

jup. muß ich auch mal sagen.
gut.

_________________
return [ :><%%> ();//c++-trollfish returning void
Ich empfehle dringend, das Problem zu vertagen, bis es akut wird. Dann liegt mehr Erfahrung vor, was wirklich gebraucht wird.
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 09:25:41 27.03.2009   Titel:              Zitieren

volkard schrieb:
Professionelle Meinung schrieb:
Das wird dir niemand übel nehmen, dieser Thread ist das Beste seit langem. Weitermachen!

jup. muß ich auch mal sagen.
gut.

^^ich schliesse mich dem an, obwohl ich bisher nur am lästern war.
:)
rapso
Moderator

Benutzerprofil
Anmeldungsdatum: 17.06.2002
Beiträge: 8699
Beitrag rapso Moderator 10:33:31 27.03.2009   Titel:              Zitieren

abc.w schrieb:
rapso, wahrscheinlich war es bei Dir auch spät gestern.

waere es nicht einfacher und auch zielgenauer den fehler bei sich selbst statt bei allen anderen zu suchen?

Zitat:

Ich kenne mich mit ner Cell CPU natürlich nicht aus und finde diese drei Befehle, so wie sie da stehen, hm, ja, hübsch.
jap, genau das wollte ich damit verdeutlichen. du scheinst wenig ahnung zu haben und deswegen weichst du in philosophie aus, wie jemand der zum ersten mal in der schule von zahlen hoert und sich fragt, ob es nicht einfacher waere mit einem 8ter system, statt die daumen mit zu nutzen.

Zitat:

Ich vermute aber, da es keinen Sinn macht, diese drei Befehle einfach so aus dem Kontext zu entreissen und ohne "Vorgeschichte" und "Nachgeschichte" einfach so zu posten, dass Du deren Bedeutung auch nicht verstanden hast...

Es ist fast lustig dass du erst zugibst nicht zu wissen was diese befehle an sich haben, somit nichtmal weisst, dass jeder einzelne schon den ganzen kontext hat den man braucht um zu verstehen wozu sie dienen, aber vermutungen anstellst dass ich das nicht verstehe.

Zitat:
Wie dem auch sei, interessant, wie es abgeht, wenn man anfängt, beim Assembler-Gefrickel mal auf den einen oder den anderen Umstand hinzuweisen. Und ich habe mich noch nicht in den ganzen Code eingelesen...

klar, jemand der scheinbar nicht viel erfahrung hat wird natuerlich erstmal verwundert schauen was das alles soll und dass es nicht so laeuft wie es in seinem unerfahrenen und unbefangenen dasein als ideal gilt.
jemand mit ahnung, der ein mox eax,0 statt xor eax,eax sieht, wird sich dagegen wundern und feststellen, entweder
1. wurde das von nem anfaenger programmiert
2. es hat einen trifftigen grund nicht der normalen vorgehensweise zu folgen, wollte er flags nicht veraendern? wollte er ein spezielles code allignment? wollte er eine spezielle code groesse? ueberschreibt er den code spaeter mit was anderem und schreibt deswegen erstmal 0 rein?

es passiert also genau das gegenteil was du eigentlich bezwecken wolltest, statt es leserlicher zu machen, wirst du jedem erfahrenen programmierer einen stolperstein stellen.

_________________
follow me|
-Mod im Spiele-/Grafikprogrammierung
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 23:07:15 27.03.2009   Titel:              Zitieren

@ Professionelle Meinung, volkard, +fricky:
Danke für das positive Feedback. Das wird mich sicher beflügeln, das bisherige Mini-OS nun mit C weiter auszubauen und bei entscheidenden Punkten hier nachzufragen. :)

Didaktisch wird der Video-RAM erklärt:
http://www.henkessoft.de/OS_Dev/OS_Dev1.htm#mozTocId483279

und anschleißend die Funktionen des C-Kernels zerpflückt, damit herum gespielt und dann optimiert.
http://www.henkessoft.de/OS_Dev/OS_Dev1.htm#mozTocId958376

Mich würde auch eure Meinung zum kurzen Abschnitt "Gerätetreiber" interessieren:
http://www.henkessoft.de/OS_Dev/OS_Dev1.htm#mozTocId220571

Eine Design-Frage ist, was man "funktionell" in C-Module zusammen packt und welche Funktionen man in der Erstausbau-Stufe benötigt. Ich möchte nichts übertreiben, damit niemand den Überblick verliert, sonst kann ich meine Leser gleich zu Linux 0.01 schicken.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
abc.w
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2008
Beiträge: 1366
Beitrag abc.w Mitglied 00:03:02 28.03.2009   Titel:              Zitieren

@rapso: Wollte an dieser Stelle ein Paar Kommentare abgeben, ich denke, ich lasse es lieber sein. Wir haben unsere Meinungen gesagt und jeder kann sich über das Gesagte eigene Meinung bilden.

Ich versuche grade verzweifelt, mit meinen Werkzeugen mingw-gcc und dem Linker, der dabei ist, den Kernel zu kompilieren. Es geht leider nicht. Bekomme Fehlermeldung (habe --verbose beim Linker angegeben, damit die Ausgabe ausführlicher wird):
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
C:\BochsMyOS\20090326_eh_os>make
c:\nasm-2.06rc6\nasm.exe -O32 -f bin boot.asm -o boot.bin
c:\nasm-2.06rc6\nasm.exe -O32 -f aout kernel.asm -o kernel.o
gcc -c ckernel.c -o ckernel.o
ld -T kernel.ld kernel.o ckernel.o --verbose
GNU ld version 2.17.50 20060824
  Supported emulations:
   i386pe
using external linker script:
==================================================
OUTPUT_FORMAT("binary")
ENTRY(RealMode)
SECTIONS
{
  .text  0x8000 : {
    *(.text)
  }
  .data  : {
    *(.data)
  }
  .bss  :  {
    *(.bss)
  }
}
 
==================================================
attempt to open kernel.o succeeded
opened script file kernel.o
kernel.o: file not recognized: File format not recognized
make: *** [all] Error 1

Anscheinend kennt der mingw Linker den aout Format nicht. :(
Kennt jemand einen Workaround?
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 00:52:53 28.03.2009   Titel:              Zitieren

Zitat:
Anscheinend kennt der mingw Linker den aout Format nicht. :( Kennt jemand einen Workaround?
Guter Hinweis. Ich verwende gcc 3.1 (im DJGPP-Paket)
http://www.osdever.net/do ....... DJGPP-Installer-nocpp.exe , weil diese Version bei Bona Fide zum Download angeboten wird.

Ich wusste, dass mit C das Gewurschtel mit den Tools los geht, aber dafür ist das Programmieren jetzt deutlich einfacher.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 00:28:05 07.05.2009, insgesamt 4-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 01:54:19 28.03.2009   Titel:              Zitieren

Wie kann man den gcc umstellen auf Intel Syntax? War das -masm=intel beim gcc?

Wie heisst das dann korrekt in Intel Syntax? :D
C++:
inline void outportb(unsigned int port,unsigned char value)
{
    asm volatile ("outb %%al,%%dx"::"d" (port), "a" (value));
};

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 01:57:02 28.03.2009, insgesamt 1-mal bearbeitet
Bitsy
Mitglied

Benutzerprofil
Anmeldungsdatum: 01.05.2001
Beiträge: 518
Beitrag Bitsy Mitglied 06:41:43 28.03.2009   Titel:              Zitieren

Ich glaube so einfach geht das nicht.
Allerdings sollte der NASM mit aout zurechtkommen (fette Zeile).

Aus der DJGPP-FAQ:
Unter Punkt 17.1 werden einige Problembehandlungen aufgezeigt. Dann:

17.2 Converting between Intel ASM syntax and AT&T syntax

Q: Where can I find an automated conversion tool to convert my Intel-style assembly code into a code acceptable by Gas?
Q: Where can I find a converter from AT&T assembly to Intel style?
A: A SED script which should do most of the conversion was posted to the {DJGPP news group}.

A program called TA2AS which can convert TASM assembly source to AT&T style can be found {on the DJGPP server} and {on Oulu}. TA2AS was written by Frank van Dijk of the Spirit group; if you have questions about this tool, you may contact {Jan Oonk}. The authors say that the program is far from finished, but the sources are available with the package so you can fix whatever is broken for your needs.

Another similar converter is Intel2Gas, available from its {Web page}.

Beginning with Binutils 2.10, Gas has an option that causes it to accept the Intel syntax, so you can use Gas to assembly Intel-style code.

Alternatively, here is what you can do to make your code linkable with DJGPP programs:
* Get and install NASM, a portable x86 assembler which supports most of the Intel syntax and can generate DJGPP-compatible COFF object files (as well as lots of other formats, such as Microsoft 16-bit OBJ and Win32, a.out, and ELF). It also supports Pentium and Pentium Pro opcodes, and MMX. NASM is free for non-commercial use (see the docs for commercial use restrictions) and can be compiled with DJGPP. NASM can be found {on NASM Web site}, which has links to official download sites. The maintainers of NASM are {Jules} and {H. Peter Anvin}.

Be warned that NASM is not 100% identical to MASM or TASM. Even experienced assembly programmers might need some time to adapt to the slightly different flavor of NASM. If you want something much more similar to TASM, get JAS. JAS is available {from OULU}.

Also note that NASM, or at least some of its versions, doesn't produce debug info in the format understood by GDB, which makes debugging NASM-assemblied code tedious (you might not be able to display source lines and refer to local symbols by name). Latest versions of NASM might correct this deficiency.
* For a small number of relatively short files, consider converting them with a smart editor (like Emacs or its work-alikes).
* Obtain a copy of Microsoft MASM 6.11. It has a -coff option to generate object code in COFF format which can be submitted to GCC, so you can compile your original source. You can also use the LIB32 librarian from Microsoft C8 to convert object files to COFF by putting them into a .lib library, then extracting them as COFF files. {28} Note that, unless you link the MASM-generated object files with DJGPP's ld (as opposed to Microsoft's LINK /CO command), you won't be able to debug the resulting program, because the debug info is not in correct format. I'm also told that masm doesn't produce sections named ".text" and ".data", so you might need to hex-edit the section names in the object file manually.
* Use a disassembler to disassemble the object code, then convert it to the AT&T format either by hand or using TA2AS. One place to look for such a disassembler is {on SimTel.NET mirrors}.
Keep in mind that syntax is only one of the aspects of converting code written for DOS to DJGPP. You should also make sure your code doesn't violate any of the rules for protected-mode programming (see {GPF in asm code}).

If you need to perform the opposite conversion, from the AT&T style to the Intel style, try the Att2Intl converter written by {Gregory Velichansky}. Its output is intended for NASM or TASM. Att2Intl is available {from Greg's home page}.

Der komplette Punkt 18 der FAQ mit Informationen über low-level-programming könnte auch noch die eine oder andere wertvolle Information beinhalten.
Wenn da noch die eine oder andere Komponente vom DJGPP fehlt, ich hab da noch Unmengen von Resourcen rumliegen.


Zuletzt bearbeitet von Bitsy am 06:57:44 28.03.2009, insgesamt 4-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 12:10:28 28.03.2009   Titel:              Zitieren

-- verbose ist ein guter Hinweis. Bei mir sieht dies so aus, noch ein problem mit partcopy.exe, aber es läuft alles:

Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
G:\OSDev\Test\13 C>make
nasmw -O32 -f bin boot.asm -o boot.bin
nasmw -O32 -f aout kernel.asm -o kernel.o
gcc -c ckernel.c -o ckernel.o
ld -T kernel.ld kernel.o ckernel.o --verbose
[b]GNU ld version 2.13[/b]
  Supported emulations:
   i386go32
using external linker script:
==================================================
OUTPUT_FORMAT("binary")
ENTRY(RealMode)
SECTIONS
{
  .text  0x8000 : {
    *(.text)
  }
  .data  : {
    *(.data)
  }
  .bss  :  {
    *(.bss)
  }
}
 
==================================================
attempt to open kernel.o succeeded
kernel.o
attempt to open ckernel.o succeeded
ckernel.o
rename a.out ckernel.bin
cmd /c copy /b boot.bin + ckernel.bin MyOS.bin
boot.bin
CKERNEL.BIN
        1 Datei(en) kopiert.
partcopy MyOS.bin 0 1000 -f0
Failed to read source at offset 800make.exe: *** [all] Error -1

Schwachstellen: letzte Zeile (jemand eine Idee?), und ich müsste ckernel.bin vorher löschen, damit a.out umbenannt werden kann. Gibt es da einen Parameter für rename, das auf jeden Fall zu machen, auch, wenn ckernel.bin existiert?

Für das Problem von abc.w habe ich momentan keine Lösung, ich war schon froh, dass ich selbst das Linken geschafft habe. Aber vielleicht schaffen wir es gemeinsam, eine möglichst allgemeingültige Lösung zu finden.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 12:12:22 28.03.2009, insgesamt 1-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 12:14:19 28.03.2009   Titel:              Zitieren

bei abc.w: i386pe
bei mir: i386go32

Ich habe nochmal genau geschaut (also nicht Version (war wohl DJGPP) 2.03, sondern 3.1): GCC 3.1 C compiler binaries for DJGPP

Zitat:
ld --version
GNU ld version 2.13

gcc --version
gcc.exe (GCC) 3.1


Das att2intl Tool findet man übrigens hier:
http://www.bumba.net/~hmaon/a2i/ :)
@Bitsy: Danke für den Hinweis!

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 18:17:31 28.03.2009, insgesamt 4-mal bearbeitet
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 14:02:17 28.03.2009   Titel:              Zitieren

Erhard Henkes schrieb:

Mich würde auch eure Meinung zum kurzen Abschnitt "Gerätetreiber" interessieren:
http://www.henkessoft.de/OS_Dev/OS_Dev1.htm#mozTocId220571

Zitat:
In unserem OS müssen wir uns nun zumindest auf die rudimentärsten Operationen konzentrieren, nämlich Videoausgabe (monochrome/farbige Text/Grafik-Ausgabe), Dateneingabe über Tastatur und Daten lesen/schreiben von/auf formatierte(r) Floppy Disk. Maus, Drucker, Festplatte könnten später folgen, wenn notwendig.

ich würde schon mal versuchen, das ganze modular aufzubauen, so dass z.b. die text-ein/ausgabe, gerätesteuerung usw. über einheitliche schnittstellen gehen, also funktionen wie 'putchar()' und 'getchar()' umgeleitet werden können, indem man z.b. intern pointer auf strukturen umsetzen kann. dazu könntest du dir eine generische 'driver' struktur definieren, die bestandteil spezialisierter strukturen ist (objektorientierung also (nein, nicht c++ benutzen!!), so dass später leicht andere geräte eingehängt werden können). bewährt hat sich auch ein 'handle'-konzept, sowas wie stdin, stdout, file, raw, etc. der bastelfreudigkeit sind keine grenzen gesetzt.
:)
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 15:23:54 28.03.2009   Titel:              Zitieren

Ich habe mal dieses "halbfertige" Tool att2intl.exe eingesetzt:
man gibt z.B. asmcode.s (ATT) ein und erhält asmcode.asm.

Beispiel:
Code:
"outb %%al,%%dx"::"d" (port), "a" (value)
==>
Code:
"out BYTE ["a" +value], BYTE %dx":[:"d" +port], %al


allerdings funktioniert
C++:
inline void outportb(unsigned int port,unsigned char value)
{
    asm volatile ("out BYTE ["a" +value], BYTE %dx":[:"d" +port], %al);
};

mit gcc -c ckernel.c -o ckernel.o -masm=intel nicht.
Zitat:
ckernel.c: In function `outportb':
ckernel.c:39: parse error before "a"

Kann da jemand bitte etwas nachhelfen? Ansonsten bleibt es eben bei der AT&T-Sysntax.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 15:29:36 28.03.2009   Titel:              Zitieren

@abc.w: Konntest Du das Problem lösen? Möchte niemanden verlieren.
Zitat:
The other main snag concerns object-file formats. There are two variants of the 32-bit COFF format: one used by Microsoft Win32 tools, and one by the rest of the world. They are only subtly different, and linkers which expect one format will happily link the other. The difference comes in the relocations: if you write code in, say, NASM, and link it using the Microsoft linker along with some modules compiled using Visual C++, the addresses in the final output will come out wrongly. There’s no real workaround for this, but luckily most tools that work with the PE format will allow you to emit files in the Win32 format: NASM has its -f win32 option, and Cygwin has the pei-i386 output format.


Zitat:
For LD (the linker that is most often used with DJGPP and gcc) use the option --oformat binary.


EDIT: delete (gelöst): del (anstelle delete; einer meiner Uraltfehler) u. -o beim Linker

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 02:01:14 29.03.2009, insgesamt 3-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 15:31:30 28.03.2009   Titel:              Zitieren

@+fricky:
Zitat:
generische 'driver' struktur definieren, die bestandteil spezialisierter strukturen ist
hast du einen Link oder ein beispiel-OS vor Augen. würde mir das gerne mal an einem konkreten beispiel anschauen. thema passt momentan genau, bin da dran.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
Swordfish
Mitglied

Benutzerprofil
Anmeldungsdatum: 27.03.2005
Beiträge: 5638
Beitrag Swordfish Mitglied 15:36:20 28.03.2009   Titel:              Zitieren

Erhard Henkes schrieb:
Was nimmt man da bei Win XP? delete ging nicht. Oder kann man bei rename einen Parameter angeben, der bestehende files überschreibt.

Nimm copy /Y rename a.out ckernel.bin.

cheers, Swordfish

PS: toller Thread! :live:

_________________
To the journey! And to those of us who aren't here to celebrate it with us.
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 16:23:04 28.03.2009   Titel:              Zitieren

Erhard Henkes schrieb:
@+fricky:
Zitat:
generische 'driver' struktur definieren, die bestandteil spezialisierter strukturen ist
hast du einen Link oder ein beispiel-OS vor Augen. würde mir das gerne mal an einem konkreten beispiel anschauen. thema passt momentan genau, bin da dran.

was konkretes wüsste ich jetzt auch nicht. such mal im internet nach 'i/o model' oder so ähnlich. z.b. in der linux doku müsste sowas zu finden sein und in irgendwelchen büchern über betriebssysteme natürlich auch.
ach, vielleicht hilft das:
http://cespc1.kumoh.ac.kr/~juyoon/lecture/osd/2006/osd08.pdf
:)
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 17:31:14 28.03.2009   Titel:              Zitieren

Zitat:
Nimm copy /Y rename a.out ckernel.bin.

Komischerweise wird das /Y im makefile nicht akzeptiert (unter MS-DOS sollte es gehen). Ich habe mich nun an die -o Option beim Linker erinnert. Die macht alles platt.

So geht es, zumindest bei mir mit gcc 3.1:

Code:
1
2
3
4
5
6
7
8
9
10
11
all:
    nasmw -O32 -f bin boot.asm -o boot.bin            
    nasmw -O32 -f aout kernel.asm -o kernel.o          
    gcc -c ckernel.c -o ckernel.o                      
    ld -T kernel.ld kernel.o ckernel.o -o ckernel.bin  
    cmd /c copy /b boot.bin + ckernel.bin MyOS.bin    
    partcopy MyOS.bin 0 800 -f0
    del kernel.o
    del ckernel.o
    del ckernel.bin
    del boot.bin   


Ich habe versucht, den Prozess auch grafisch (inzwischen mit video.c) darzustellen: http://www.henkessoft.de/OS_Dev/Bilder/make_process.PNG

Linker Script:
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
OUTPUT_FORMAT("binary")
ENTRY(RealMode)
SECTIONS
{
  .text  0x8000 : {
    *(.text)
  }
  .data  : {
    *(.data)
  }
  .bss  :  {                   
    *(.bss)
  }
}


In einem anderen Thread hier habe ich brauchbare Mischung aus Hexeditor+Disassembler+Rechner gefunden:
http://members.inode.at/anton.zechner/az/Disassembler.htm
Echt interessantes Teil.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 21:59:58 28.03.2009, insgesamt 4-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 18:59:25 28.03.2009   Titel:              Zitieren

@+fricky: Danke für den Link. Hier ist auch eine interessante Architekturübersicht (kompakt): http://www.samueldotj.com/Ace/Architecture.asp

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 22:09:17 28.03.2009   Titel:              Zitieren

hier haste noch'n paar interessante slides zu dem thema
http://www.minix3.ru/docs/slides/Ch3.pdf
:)
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 01:25:56 29.03.2009   Titel:              Zitieren

@+Fricky: danke für die Links, aber teilweise schon etwas weit in den Details, dafür aber wieder zu komplex und gleichzeitg theoretisch. Das verwirrt momentan mehr als es beim Design hilft.

Zur Zielsetzung ist eine abstrakte theoretische Diskussion auf der Meta-Ebene notwendig. Die Herausforderung besteht darin, dass es keine Übereinstimmung darin gibt, wie man ein OS optimal aufsetzt (cf. Tanenbaum, Modern Operating Systems, 2nd Ed., Chap. 12: Operating System Design). Das finde ich nach diesen vielen Jahren schon interessant.

Einige Dinge weiß man aber inzwischen:
Monolithische Kernel (Windows, Linux) sind erfolgreicher als Micro Kernels. Das hat aber lediglich Effizienzgründe und keine strukturelle Basis, kann uns also egal sein.
Präemptives Multitasking (Modernes Windows) ist aus Sicht eines Prozesses besser als kooperatives (klassisches Windows).

Tanenbaum sieht vor allem vier Aufgabenfelder eines OS:
1) Abstraktion schaffen (schwierigste Aufgabe)
2) Primitive Operationen bereit stellen
3) Isolation sicher stellen
4) Hardware Management

Files, Prozesse, Synchronisation, Speichermodelle, I/O System, System calls, Fehlerseparation durch voneinander unabhängige Systeme, ... da stehen wir ja praktisch nicht mehr am Anfang, aber ob wir bereits im Optimum sind, das ist noch offen. Die Kontrolle der Hardware ist eher eine Fleissaufgabe.

Ein OS ist ein gigantisches Software-Paket. Unix hat mehr als 1 Mio., Linux 2.6 ca. 5,7 Mio., Win 2000 ca. 29 Mio., Win XP ca. 35 Mio. und MS Vista ca. 50 Mio. Zeilen Sourcecode. So etwas kann also keinesfalls in der Zielgeraden liegen. Daher muss man sich von diesen Systemen als Zielbild lösen.

Das Entscheidende dabei ist, dass niemand in wenigen Monaten ein neues OS schreiben kann. Diese Illusion sollte man rasch aufgeben. Bei einem Hobby-/Lehr-Projekt geht es also vor allem darum - didaktisch möglichst klar dargestellt - ein Verständnis für die Zusammenhänge und Möglichkeiten auf der untersten Ebene zu schaffen.

Es macht m.E. mehr Sinn, zunächst in der Historie anzuknüpfen und von dort aus neue Wege zu suchen. Das Original MS-DOS 1.0 (1981) besteht z.B. aus rund 4.000 Zeilen Assembler-Code (nicht offen gelegt). Die grundlegenden Funktionen dieses Systems lassen sich leicht nachvollziehen und verstehen. Es gibt inzwischen freie Clones.

MS DOS hatte vier Bereiche und arbeitete nur im RM:
1) Bootcode
2) io.sys = Geräteroutinen (Monitor, Tastatur, Festplatte, Schnittstellen)
3) command.com = Befehlsinterpreter
4) Ausführung von Programmen (COM, EXE)

Befehle:

"intern":
del, erase - Dateien löschen
rd, rmdir - Verzeichnis löschen
dir - Verzeichnisinhalt anzeigen
cd, chdir - Verzeichnis wechseln
cls - löscht den Bildschirminhalt
md, mkdir - Verzeichnis erstellen
copy - Kopieren einer oder mehrerer Dateien
ren, rename - Umbenennen von Dateien oder Verzeichnissen
type - Anzeigen von Textdateien
set - zeigt DOS Umgebungsvariablen oder legt eine neue fest
ver - zeigt die DOS Versionsnummer
vol - zeigt die Datenträgerbezeichnung an

"extern":
attrib - Zeigt Attribute von Dateien oder legt diese fest
fdisk - Partitionierung der Festplatte erstellen oder verändern
move - Verschieben von Dateien
mem - Anzeigen der Belegung des Arbeitsspeicher
tree - Zeigt die Verzeichnisstruktur an
format - Formatieren eines Datenträger

EDIT: MS-DOS hatte auch einige Systemaufrufe wie den berühmten int 21h... (Anmerkung von abc.w)

http://www.operating-syst ....... rosoft/msdos_211-scr-.gif

Tanenbaum empfiehlt folgende drei Punkte für das Design:
Einfachheit, Vollständigkeit und Effizienz. :)

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 19:52:07 29.03.2009, insgesamt 3-mal bearbeitet
Unregistrierter





Beitrag Unregistrierter 01:59:22 29.03.2009   Titel:              Zitieren

Erhard Henkes schrieb:
Es macht m.E. mehr Sinn, zunächst in der Historie anzuknüpfen und von dort aus neue Wege zu suchen.
Meine Rede! :live: Man muß sich nur trennen von der Ansicht, daß im RM nur 1 MB RAM adressierbar sind. Dann müssten die Ideen eigentlich nur so hervorsprudeln. Vorausgesetzt natürlich, das Ziel ist nicht, DOS einfach nur zu kopieren.
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 02:22:29 29.03.2009   Titel:              Zitieren

Zitat:
Man muß sich nur trennen von der Ansicht, daß im RM nur 1 MB RAM adressierbar sind.
Gibt es hierzu bereits ein stabiles Hobby-/Lehr-OS, das man sich mal anschauen könnte?

Ich denke nicht, dass der Protected Mode das zentrale Problem ist, eher was daraus gemacht wurde. Die Adressierung ist beherrschbar (eine Zeigerebene mehr und Paging, dafür hat man flat Speicher-Adr.). Multitasking mit allen Problemen muss ja z.B. nicht sein. Es geht doch eher darum, die enorme Leistung eines heutigen PC, die unter Windows (und inzwischen auch Linux) verschüttet wird, frei zu legen und Programmen bereit zu stellen.
Zitat:
perfection is reached not when there is no longer anything to add, but when there is no longer anything to take away.
Antoine de St. Exupéry.

Zitat:
Protected Mode has several advantages over Real Mode:
1. Protected Mode has Protection, the ability to keep programs from messing around and crashing each other(this is how Proctected Mode got its name).
2. You may only have several tasks (like Windows and Linux).
3. You have 4GB of address space (A20-Gate enabled).
4. You can use paging to access memory.
http://www.osdever.net/tutorials/gettingstarted.php

Wichtig ist nach Tanenbaum eine Abstraktionsidee, Beispiele:
alles ist ein Tape (Fortran)
alles ist ein File (Unix)
alles ist ein Objekt (W2K)
alles ist ein Dokument (www)

A.S.Tanenbaum ist ja immer einer der Verfechter des aus seiner Sicht "eleganten" Microkernel-Prinzips gewesen, das er im OS Minix umsetzte.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 11:30:42 29.03.2009, insgesamt 6-mal bearbeitet
abc.w
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2008
Beiträge: 1366
Beitrag abc.w Mitglied 10:55:08 29.03.2009   Titel:              Zitieren

Erhard Henkes schrieb:

MS DOS hatte vier Bereiche und arbeitete nur im RM:
...
Befehle:
...
"intern":
...
"extern":
...

Vorsicht... vorsicht... MS-DOS hatte auch einige Systemaufrufe wie den berühmten int 21h... ;)
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 11:47:32 29.03.2009   Titel:              Zitieren

@abc.w: ja, das ist richtig. Hat das mit dem Compilieren/Linken nun geklappt, oder gibt es da noch ein Grundsatzproblem?

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
abc.w
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2008
Beiträge: 1366
Beitrag abc.w Mitglied 12:01:29 29.03.2009   Titel:              Zitieren

Erhard Henkes schrieb:
@abc.w: ja, das ist richtig. Hat das mit dem Compilieren/Linken nun geklappt, oder gibt es da noch ein Grundsatzproblem?

Das habe ich noch nicht hingekriegt...
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 12:20:13 29.03.2009   Titel:              Zitieren

@abc.w: Schade, dass wir nicht wissen, woran es exakt liegt. Probiere doch mal parallel den DJGPP: http://www.osdever.net/do ....... DJGPP-Installer-nocpp.exe

Vielleicht erkennst Du dann, woran es genau liegt. Wenn ich es richtig verstanden habe, macht der Linker Probleme.
http://www.henkessoft.de/OS_Dev/Bilder/make_process.PNG (gelb)

Ich hatte hier noch einiges zusammen getragen:
http://www.c-plusplus.de/ ....... asc-and-start-is-130.html

NASM has its -f win32 option,
and Cygwin has the pei-i386 output format.

For LD use the option --oformat=binary.
http://lists.zerezo.com/mingw-users/msg00383.html

Keine Ahnung, ob das die richtige Spur ist.

Zur Erinnerung:
bei abc.w: i386pe
bei mir: i386go32

Vielleicht kann jemand anderes hier zielgenau helfen.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 12:44:17 29.03.2009, insgesamt 4-mal bearbeitet
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 12:52:23 29.03.2009   Titel:              Zitieren

Erhard Henkes schrieb:
@+Fricky: danke für die Links, aber teilweise schon etwas weit in den Details, dafür aber wieder zu komplex und gleichzeitg theoretisch. Das verwirrt momentan mehr als es beim Design hilft.

schau es dir einfach in ruhe an und lass dich davon inspirieren. du musst ja kein OS strikt nach lehrbuchmeinung basteln (das wäre auch langweilig), aber z.b. in den tanenbaum-slides sind prinzipien erwähnt, von denen man als os-designer mal was gehört haben sollte. was du davon verwertest und was nicht, bleibt dir überlassen. ich würde zumindest leichte erweiterbarkeit und austauschbarkeit von komponenten von vorn herein einplanen. nicht dass du später mal alles umbauen musst, wenn ausgaben statt auf dem bildschirm, in einer datei landen sollen.
:)
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 13:45:57 29.03.2009   Titel:              Zitieren

Zitat:
ich würde zumindest leichte erweiterbarkeit und austauschbarkeit von komponenten von vorn herein einplanen. nicht dass du später mal alles umbauen musst, wenn ausgaben statt auf dem bildschirm, in einer datei landen sollen.
Das ist richtig. Abstraktion ist der entscheidende Punkt.

..

Folgende Punkte sehe ich bisher für mein "PrettyOS" (Deckname):
- Common affordable hardware platform (Standard PC ab 80386)
- Flat 32-Bit Virtual Memory Model (das bedeutet PM bei x86)
- Easy programming
- Simplicity (KISS Prinzip gilt in einer komplexen Welt immer mehr)

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 10:41:13 05.10.2013, insgesamt 5-mal bearbeitet
abc.w
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2008
Beiträge: 1366
Beitrag abc.w Mitglied 18:52:48 29.03.2009   Titel:              Zitieren

Habe mit mingw-Linker & Co ein wenig rumexperimentiert. Es funktioniert immer noch nicht und ich glaube nicht, dass es funktionieren wird...
Der mingw-Linker unterstützt folgende Formate:
Code:
C:\BochsMyOS\20090327_eh_os>ld --help
Usage: ld [options] file...
...
ld: supported targets: pe-i386 pei-i386 elf32-i386 elf32-little elf32-big srec symbolsrec tekhex binary ihex
ld: supported emulations: i386pe
...

Der nasm Assembler unterstützt folgende Formate:
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
C:\BochsMyOS\20090327_eh_os>c:\nasm-2.06rc6\nasm -hf
...
valid output formats for -f are (`*' denotes default):
  * bin       flat-form binary files (e.g. DOS .COM, .SYS)
    aout      Linux a.out object files
    aoutb     NetBSD/FreeBSD a.out object files
    coff      COFF (i386) object files (e.g. DJGPP for DOS)
    elf32     ELF32 (i386) object files (e.g. Linux)
    elf       ELF (short name for ELF32)
    elf64     ELF64 (x86_64) object files (e.g. Linux)
    as86      Linux as86 (bin86 version 0.3) object files
    obj       MS-DOS 16-bit/32-bit OMF object files
    win32     Microsoft Win32 (i386) object files
    win64     Microsoft Win64 (x86-64) object files
    rdf       Relocatable Dynamic Object File Format v2.0
    ieee      IEEE-695 (LADsoft variant) object file format
    macho     NeXTstep/OpenStep/Rhapsody/Darwin/MacOS X object files

D.h. der nasm Assembler kann Objektdateien erzeugen, die der mingw-Linker nicht kennt. Ausserdem scheint es problematisch zu sein, dass die Datei kernel.asm 16-Bit und 32-Bit Code enthält. Wenn man mit nasm versucht, z.B. win32 Format zu generieren, bekommt man zahlreiche Fehlermeldungen:
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
C:\nasm-2.06rc6\nasm -O32 -f win32 kernel.asm -o kernel.o
kernel.asm:21: error: COFF format does not support non-32-bit relocations
kernel.asm:27: error: COFF format does not support non-32-bit relocations
kernel.asm:35: error: COFF format does not support non-32-bit relocations
kernel.asm:40: error: COFF format does not support non-32-bit relocations
kernel.asm:45: error: COFF format does not support non-32-bit relocations
kernel.asm:50: error: COFF format does not support non-32-bit relocations
kernel.asm:55: error: COFF format does not support non-32-bit relocations
kernel.asm:59: error: COFF format does not support non-32-bit relocations
kernel.asm:64: error: COFF format does not support non-32-bit relocations
kernel.asm:69: error: COFF format does not support non-32-bit relocations
kernel.asm:74: error: COFF format does not support non-32-bit relocations
kernel.asm:82: error: COFF format does not support non-32-bit relocations
kernel.asm:88: error: COFF format does not support non-32-bit relocations
kernel.asm:117: error: COFF format does not support non-32-bit relocations
make: *** [all] Error 1

Was COFF mit win32 Format zu tun hat, weiss ich jetzt nicht...
Dann habe ich mit ELF Format ausprobiert (scheint der kleinste gemeinsame Nenner zu sein, mingw-Linker und nasm können es beide und man kann die ckernel.o mit objcopy nach ELF konvertieren). Es kommt ungefähr folgende Fehlermeldung:
Code:
C:\BochsMyOS\20090327_eh_os>ld -T kernel.ld kernel32.o ckernel_elf.o
ld: cannot perform PE operations on non PE output file 'a.exe'.

Mit kernel32.o habe ich versucht, 16-Bit Code von 32-Bit Code zu trennen und die Datei ckernel_elf.o ist die ckernel.o konvertiert nach ELF.
Wie es aussieht, es geht mit mingw Tools nicht. :( Oder ich mache irgendwas falsch.

Werde mir wohl den weisshaarigen DJGPP runterladen...
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 19:48:46 29.03.2009   Titel:              Zitieren

Zitat:
Werde mir wohl den weisshaarigen DJGPP runterladen...

DJGPP (gcc 3.1, ld 2.13):
ld.exe: supported targets: coff-go32 coff-go32-exe a.out-i386 srec symbolsrec tekhex binary ihex
ld.exe: supported emulations: i386go32

mingw (ld 2.17.50 20060824 )
ld: supported targets: pe-i386 pei-i386 elf32-i386 elf32-little elf32-big srec symbolsrec tekhex binary ihex
ld: supported emulations: i386pe

Hat da jemand die Lösung für den ASM-Kernel (16 u. 32 Bit) bezüglich Kopplung von NASM output file und Linker (ld 2.17) input file?

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 20:18:54 29.03.2009, insgesamt 3-mal bearbeitet
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 20:03:53 29.03.2009   Titel:              Zitieren

Erhard Henkes schrieb:

Momentan schmökere ich gerade im Buch von Richard A. Burgess "Developing Your Own 32 Bit Computer Operating System" (MMURTL V1.0). Er hatte sich bei seinem Operating System folgende Ziele gesetzt:

ah, ich glaub' das hatte ich mal in den fingern. ist schon ziemlich alt und er hat sein OS komplett in asm programmiert, ne?

Erhard Henkes schrieb:

The name is an acronym for Message based MUltitasking, Real-Time, kerneL."

'message based' bedeutet, dass kein timer-gesteuerter scheduler drin ist, sondern context-switches werden durch versenden von messages herbeigeführt, oder? finde ich gut. präemptives, gewaltsames multitasking nach zeitscheiben ist manchmal gar nicht so toll.

Erhard Henkes schrieb:

Folgende Punkte sehe ich bisher für mein "PrettyOS" (Deckname):
- Flat 32-Bit Virtual Memory Model (das bedeutet PM bei x86)
- Easy programming
- Simplicity (KISS Prinzip gilt in einer komplexen Welt immer mehr)

ja, pretty-OS hört sich auch besser an, als der bisherige name.
flat memory model: was denn sonst? segment/offset-gedöns ist einfach nur übel.
easy programming: muss schon sein. keine übertriebenen schutzmechanismen, vertrau dem programmierer, denn er weiss, was er tut.
KISS: sehr vernünftig.
:)
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 20:23:26 29.03.2009   Titel:              Zitieren

PrettyOS nicht pretty-os oder pretty-OS :D

Zunächst müssen wir erstmal das NASM/Linker-Problem bei mingw (siehe post von abc.w) lösen, damit wir niemanden verlieren.

Multitasking/Singletasking? Da bin ich mir noch nicht sicher, ob Multitasking am Anfang nicht zuviel des Guten ist. Vorbereitet sind wir ja via PM. Mal sehen.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 20:34:53 29.03.2009   Titel:              Zitieren

Erhard Henkes schrieb:

Da bin ich mir noch nicht sicher, ob Multitasking am Anfang nicht zuviel des Guten ist. Vorbereitet sind wir ja via PM. Mal sehen.

multitasking oder nicht, hängt nicht davon ab, ob du den protected mode verwendest.
:)
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 22:14:46 29.03.2009   Titel:              Zitieren

Ja, das ist richtig. Als PC-Betriebssystem kenne ich bisher noch kein Multitasking OS im Real Address Mode (=Real Mode), muss irgendwie an mir vorbei gegangen sein. Kannst Du mir da mal auf die Sprünge helfen?

Prinzipiell ist task switching / context switching unabhängig von der Adressierungstechnik (direkt gekoppelt mit der physikalischen Adresse oder indirekt über Zeigertabellen). Auch Protected oder Unprotected hängt damit nicht zwingend zusammen.

Kannst Du mir Beispiele nennen für folgende Kombinationen:
Code:
1
2
3
4
5
6
7
8
9
10
11
Real Address Mode (0)    Unprotected (0) Singletasking (0)  Example
Virtual Address Mode (1) Protected (1)   Multitasking  (1)  Operating System
---------------------------------------------------------------------------------------------
          0                  0                  0          MS-DOS
          0                  0                  1            ?
          0                  1                  0            ?
          0                  1                  1            ?
          1                  0                  0            ?
          1                  0                  1            ?  
          1                  1                  0            ?
          1                  1                  1          Linux, MS Windows NT, ...    

Ist die Systematik so richtig? Alles wirklich unabhängig voneinander?

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 22:58:25 29.03.2009, insgesamt 2-mal bearbeitet
abc.w
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2008
Beiträge: 1366
Beitrag abc.w Mitglied 22:28:37 29.03.2009   Titel:              Zitieren

Habe mir DJGPP heruntergeladen und konnte 20090327_eh_os erfolgreich kompilieren, linken, zusammenkopieren. Ein ähnliches Problem wie mit copy wieder gehabt, diesmal mit rename:
Code:
1
2
3
4
5
6
7
8
9
C:\BochsMyOS\20090327_eh_os>make
C:\nasm-2.06rc6\nasm -O32 -f bin boot.asm -o boot.bin
C:\nasm-2.06rc6\nasm -O32 -f aout kernel.asm -o kernel.o
c:\djgpp\bin\gcc -c ckernel.c -o ckernel.o
c:\djgpp\bin\ld -T kernel.ld kernel.o ckernel.o
rename a.out ckernel.bin
process_begin: CreateProcess(NULL, rename a.out ckernel.bin, ...) failed.
make (e=2): Das System kann die angegebene Datei nicht finden.
make: *** [all] Error 2

Dann habe ich mein Makefile umgebaut:
Code:
all:
    ...
    cmd /c rename a.out ckernel.bin
    ...

Und so funktioniert es bei mir wieder...
Eine Sache vielleicht noch: Die Funktion outportb() im C-Kernel ist ja als inline gekennzeichnet, "inlinen" tut der GCC anscheinend aber ab Optimierungsstufe -O1:
Code:
all:
    ...
    gcc -c ckernel.c -o ckernel.o -O1
    ...

Man kann sich die Objektdatei ckernel.o mit objdump anschauen, einmal ohne Optimierungsstufe und einmal mit, z.B. so:
Code:
c:\djgpp\bin\objdump.exe -D ckernel.o


Wofür steht eigentlich -O32 beim Aufruf von nasm? -O steht für Optimierung, aber 32... finde grade nichts über Optimierungsstufe 32 in der nasm Doku...
Code:
C:\nasm-2.06rc6\nasm -O32 -f bin boot.asm -o boot.bin


Erhard Henkes schrieb:
Zunächst müssen wir erstmal das NASM/Linker-Problem bei mingw (siehe post von abc.w) lösen, damit wir niemanden verlieren.

Nur aus Neugier, wie viele Leute sind noch dabei ? :) Ich bin aus persönlichem Interesse dabei, weil ich u.a. vorhabe, hobbymässig einen echten 80386 auf einer Lochrasterplatine zum Laufen zu bekommen. Ein PC ist mir zu langweilig ;) Überlege gerade, wie ich die RAM Bausteine 8 Stück je 32 kByte anschliesse. Eins weiss ich inzwischen genau: Auf keinen Fall A20 Gate ;)
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 22:43:26 29.03.2009   Titel:              Zitieren

Zitat:
Habe mir DJGPP heruntergeladen und konnte 20090327_eh_os erfolgreich kompilieren, linken, zusammenkopieren.
Super! Freut mich, dass es bei Dir nun auch klappt. Eigentlich ein Hammer, dass das alte Teil mehr kann als das neue ;) Allerdings hätte mich auch die wirkliche Lösung für den mingw interessiert, aber Hauptsache es geht. Kann man den alten ld vom DJGPP bei den Dateien vom neueren mingw einsetzen?

Zitat:
Ein ähnliches Problem wie mit copy wieder gehabt, diesmal mit rename

Das habe ich inzwischen über Bord geworfen, weil es das ckernel.bin nicht überschrieben hat, hätte man aber vorher mit del löschen können. So sieht es momentan aus (video.c ausgelagert), es wird einfach die Option -o ckernel.bin beim Linker ld angegeben:
http://www.henkessoft.de/OS_Dev/Bilder/make_process.PNG
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
all:
    nasmw -O32 -f bin boot.asm -o boot.bin            
    nasmw -O32 -f aout kernel.asm -o kernel.o        
    gcc -c ckernel.c -o ckernel.o                    
    gcc -c video.c -o video.o            
    ld -T kernel.ld kernel.o ckernel.o video.o -o ckernel.bin --verbose
    cmd /c copy /b boot.bin + ckernel.bin MyOS.bin    
    del video.o
    del kernel.o
    del ckernel.o
    del ckernel.bin
    del boot.bin  
    partcopy MyOS.bin 0 800 -f0


Zitat:
Ich bin aus persönlichem Interesse dabei, weil ich u.a. vorhabe, hobbymässig einen echten 80386 auf einer Lochrasterplatine zum Laufen zu bekommen. Ein PC ist mir zu langweilig ;) Überlege gerade, wie ich die RAM Bausteine 8 Stück je 32 kByte anschliesse. Eins weiss ich inzwischen genau: Auf keinen Fall A20 Gate ;)
:live:
Falls Du das nicht selbst auf einer Homepage verarbeiten willst, sollten wir ein Kapitel über dein Projekt einbauen (natürlich mit Fotos deines Konstrukts, bitte denke an die VDE und Funkabschirmung :D ).


Gibt man "-O32" nasm (das habe ich von Nobuo T übernommen) bei Google ein, so kommen wir hier mit diesem Thread auf Platz eins heraus. :)

namsw -help liefert Folgendes:
Zitat:
-O<digit> optimize branch offsets (-O0 disables, default)


Danke für den Hinweis mit der Optimierungsstufe und den Tipp bezüglich objdump (man kann die Leser eines solchen OS-Tutorials bezüglich Tools gar nicht genug fit machen). ;) Das werde ich ins Tutorial einbauen.

Ohne Optimierung:

Code:
1
2
3
4
5
6
7
8
9
10
11
000000be <_outportb>:
  be:    55                       push   %ebp
  bf:    89 e5                    mov    %esp,%ebp
  c1:    83 ec 04                 sub    $0x4,%esp
  c4:    8b 45 0c                 mov    0xc(%ebp),%eax
  c7:    88 45 ff                 mov    %al,0xffffffff(%ebp)
  ca:    8b 55 08                 mov    0x8(%ebp),%edx
  cd:    8a 45 ff                 mov    0xffffffff(%ebp),%al
  d0:    ee                       out    %al,(%dx)
  d1:    c9                       leave
  d2:    c3                       ret  


Mit Optimierung -O1:

Code:
1
2
3
4
5
6
7
8
000000ac <_outportb>:
  ac:    55                       push   %ebp
  ad:    89 e5                    mov    %esp,%ebp
  af:    8b 55 08                 mov    0x8(%ebp),%edx
  b2:    8a 45 0c                 mov    0xc(%ebp),%al
  b5:    ee                       out    %al,(%dx)
  b6:    5d                       pop    %ebp
  b7:    c3                       ret  

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 01:36:20 30.03.2009, insgesamt 11-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 04:09:48 30.03.2009   Titel:              Zitieren

Zur Zeit schlage ich mich in C mit dem Keyboard Driver herum. Nicht gerade einfach die ganze Thematik, auch didaktisch.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
jenz
Mitglied

Benutzerprofil
Anmeldungsdatum: 29.06.2005
Beiträge: 257
Beitrag jenz Mitglied 09:31:55 30.03.2009   Titel:              Zitieren

Hallo Erhard,

finde ich sehr cool, wie du hier eine mini-OS bastelst, habe ich auch mal versucht und bin irgendwann bis zu einer minigrafischen Oberfäche gekommen.
Ich werde das noch mal rauskramen.

Ich finde, dass du, bevor du den Keyboardtreiber schreibst, dir ein geeignetes Konzept zur Interruptbehandlung zulegst und das auch schon mal Schablonenartig implementierst.

Ich finde diese Prolog/Epilog Konzept sehr gut. Mit entsprechenden Tricks und Hirnschmalz kann man es dann auch schaffen, dass die Interrupts _nie_ ausgestellt werden müssen.

http://www-ivs.cs.uni-mag ....... 1/seminare/seminar8.shtml

Viel Erfolg noch.
Jens
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 09:40:25 30.03.2009   Titel:              Zitieren

Erhard Henkes schrieb:

Als PC-Betriebssystem kenne ich bisher noch kein Multitasking OS im Real Address Mode (=Real Mode), muss irgendwie an mir vorbei gegangen sein. Kannst Du mir da mal auf die Sprünge helfen?

z.b. von cmx-rtx, embOS, freeRTOS, proc, usw, gibts auch versionen für x86-boards (das sind systeme für den embedded-bereich, machen alle timer-gesteuertes multitasking). die meisten davon laufen im real mode.
:)
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 09:45:52 30.03.2009   Titel:              Zitieren

Erhard Henkes schrieb:
Zur Zeit schlage ich mich in C mit dem Keyboard Driver herum. Nicht gerade einfach die ganze Thematik, auch didaktisch.

http://www.computer-engineering.org/ps2protocol/
http://maven.smith.edu/~t ....... Assembly/CH20/CH20-1.html
:)
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 18:04:27 30.03.2009   Titel:              Zitieren

Ein ganz anderer Punkt sind die mathematischen und sonstigen Routinen, die man ständig benötigt, und die aber nicht von einer library abhängig sein dürfen.
Beispiel: Will man eine char-, integer- oder float-Zahl auf dem Bildschirm ausgeben, so muss man zunächst diese in einen "string" umwandeln. Man benötigt also ein "frei schwebendes" k_itoa ohne Routinen aus string.h etc. Selbst im alten K&R wurde ich da nicht fündig, da verweist ständig eine Funktion auf die nächste, wie bei einem russischen Püppchen :D

..

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 10:42:43 05.10.2013, insgesamt 4-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 18:32:57 30.03.2009   Titel:              Zitieren

Zitat:
Ich finde, dass du, bevor du den Keyboardtreiber schreibst, dir ein geeignetes Konzept zur Interruptbehandlung zulegst und das auch schon mal Schablonenartig implementierst.

Ich möchte es zunächst erstmal ohne Interrupts probieren, bin nicht sicher, ob das vernünftig geht, wird dann aber logischerweise der nächste Schritt.

Zitat:
Ich finde diese Prolog/Epilog Konzept sehr gut. Mit entsprechenden Tricks und Hirnschmalz kann man es dann auch schaffen, dass die Interrupts _nie_ ausgestellt werden müssen.

Danke an alle für die tollen Links. Das hilft mir sehr.

Momentan ist mein Hauptproblem, dass ich zwei Rechner benötige, weil ich nicht ständig Windows booten will, wenn das liebe PrettyOS selbst "aus Bochs heraus" meine Tastatur abgeschossen hat. :D

EDIT:
Problem gelöst, Keyboard-Treiber funktioniert, zur Zeit noch ohne Interrupts, wie ich es wollte.
OS fragt die Tastatur in einer Schleife ab, löscht den Bildschirm und druckt in Zeile 0 das ASCII-Zeichen und in Zeile 1 den ASCII-Code (dank k_itoa). Zur Zeichendarstellung benötigt man bereits zwei Keymaps (eine mit und eine ohne Shift-Taste, zur Zeit International US-Tastatur).
http://www.henkessoft.de/ ....... rdDriver_funktioniert.PNG :live:
Gefällt mir didaktisch gut, vor allem noch alles in C außer den Funktionen outportb(...) und inportb(...).

Nun muss ich den Sourcecode noch didaktisch optimieren, sieht teilweise improvisiert ziemlich unordentlich aus, kann man so nicht uploaden. :rolleyes:

Module:

ckernel.c:
main()

video.c:
k_clear_screen()
k_printf(char* message, unsigned int line, char attribute)
void update_cursor(int row, int col)

util.c (wollte es nicht stdlib nennen):
void k_itoa(int value, char* valuestring)
void k_i2hex(unsigned int val, unsigned char* dest, int len)
void float2string(float value, int decimal, char* valuestring)

math.c:
int power(int base,int n)

keyboard.c:
...
...
k_getch()

Wohin gehören outportb, inportb?
Wie würdet ihr überhaupt die Module anordnen?

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 23:30:17 30.03.2009, insgesamt 8-mal bearbeitet
abc.w
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2008
Beiträge: 1366
Beitrag abc.w Mitglied 21:05:37 30.03.2009   Titel:              Zitieren

Erhard Henkes schrieb:
Zitat:
Ich bin aus persönlichem Interesse dabei, weil ich u.a. vorhabe, hobbymässig einen echten 80386 auf einer Lochrasterplatine zum Laufen zu bekommen. Ein PC ist mir zu langweilig ;) Überlege gerade, wie ich die RAM Bausteine 8 Stück je 32 kByte anschliesse. Eins weiss ich inzwischen genau: Auf keinen Fall A20 Gate ;)
:live:
Falls Du das nicht selbst auf einer Homepage verarbeiten willst, sollten wir ein Kapitel über dein Projekt einbauen (natürlich mit Fotos deines Konstrukts, bitte denke an die VDE und Funkabschirmung :D ).

Eine Homepage habe ich nicht... und hätte auch nichts gegen ein Kapitel mit ein Paar Fotos von meinem Board ;) Ein Kapitel, der heissen soll "So nicht" ;) Es ist nämlich so, dass ich inzwischen 20 ICs auf der Platine habe und wenn ich so überlege, noch ziemlich am Anfang stehe. Diese 20 ICs habe ich nicht draufgemacht, weil ich mir Gedanken gemacht habe, wie die Schaltung optimal oder am Besten wäre, sondern, ich hatte sie zufällig in meiner Bastelkiste... Meine Idee ist, vom PC aus ein binäres Programm auf die Platine "runterladen" und dieses Programm vom 80386 ausführen lassen. Die Kommunikation mit dem PC soll über eine UART gehen und die Steuerung soll ein ATmega644 übernehmen. Sprich, ein 8-Bit Mikrocontroller soll volle Kontrolle über eine 32-Bit CPU haben. Der ATmega soll den 80386 im Reset halten, wenn ein Programm über UART gesendet wird und, dieses Programm ins RAM schreiben. Danach soll der 80386 "freigelassen" werden :) Also nicht gerage sinnvoll das Ganze. Nicht, dass jemand denkt, boah, der baut einen PC nach... Ich habe noch nicht mal irgendwelche I/O Bausteine für den 386er. Mein Ziel ist also wirklich "nur" 386er soll ein Programm aus dem RAM ausführen und wenn die Spannung weg ist, dann ist auch das Programm weg. Das Programm könnte natürlich alles Mögliche sein, auch ein kleines OS... nur man müsste dann irgendeine Form von I/O dazubauen und Platz dafür wäre auf der Platine da.
Ich kann Dir gerne ein Paar Fotos von dem Board im jetzigen Stand zuschicken, die RAM Bausteine und der 386er sind aber noch nicht drauf...
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 21:21:31 30.03.2009   Titel:              Zitieren

Zitat:
man müsste dann irgendeine Form von I/O dazubauen

Irgendwie erinnert mich das an diese Robotik-/Elektronik-Boards mit ihren Interfaces nach außen, z.B. I2C-Bus. Vielleicht erhältst Du dort Anregungen.
http://www.roboternetz.de/wissen/index.php/RN-Control

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
abc.w
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2008
Beiträge: 1366
Beitrag abc.w Mitglied 21:55:58 30.03.2009   Titel:              Zitieren

Erhard Henkes schrieb:
Irgendwie erinnert mich das an diese Robotik-/Elektronik-Boards mit ihren Interfaces nach außen, z.B. I2C-Bus. Vielleicht erhältst Du dort Anregungen. http://www.roboternetz.de/wissen/index.php/RN-Control

Dazu ist noch ein weiter Weg, zuerst muss RAM mit seinem 32-Bit Datenbus funktionieren. Die Funktion der 19 ICs besteht im Prinzip darinm, dass der 20. IC, der ATmega, wie ein Master mit 20-Bit Adressbus und 32-Bit Datenbus erscheint plus ein Paar Steuersignale... Die Funktion dieser 19 ICs muss ich noch überprüfen :)
PS: Ups, die UART realisiert mit MAX232 läuft bereits, also sind es nur noch 18 ICs... :)


Zuletzt bearbeitet von abc.w am 21:57:35 30.03.2009, insgesamt 1-mal bearbeitet
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 22:08:41 30.03.2009   Titel:              Zitieren

Erhard Henkes schrieb:

Ein ganz anderer Punkt sind die mathematischen und sonstigen Routinen, die man ständig benötigt, und die aber nicht von einer library abhängig sein dürfen.

such dir was aus: http://penguinppc.org/embedded/howto/library.html

abc.w schrieb:

Es ist nämlich so, dass ich inzwischen 20 ICs auf der Platine habe und wenn ich so überlege, noch ziemlich am Anfang stehe. Diese 20 ICs habe ich nicht draufgemacht, weil ich mir Gedanken gemacht habe, wie die Schaltung optimal oder am Besten wäre, sondern, ich hatte sie zufällig in meiner Bastelkiste...

das ist nicht dein ernst?!

abc.w schrieb:

Meine Idee ist, vom PC aus ein binäres Programm auf die Platine "runterladen" und dieses Programm vom 80386 ausführen lassen.

na, dann wäre vielleicht das hier was für dich: http://www.amd.com/epd/pr ....... am/24.lansc520/index.html
(x86-kompatibel und so)

aber wenn du mehr auf basteln stehst (was ich vermute, siehe oben), dann vielleicht doch eher sowas: http://www.mycpu.eu/
:)
abc.w
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2008
Beiträge: 1366
Beitrag abc.w Mitglied 22:42:20 30.03.2009   Titel:              Zitieren

+fricky schrieb:
abc.w schrieb:

Es ist nämlich so, dass ich inzwischen 20 ICs auf der Platine habe und wenn ich so überlege, noch ziemlich am Anfang stehe. Diese 20 ICs habe ich nicht draufgemacht, weil ich mir Gedanken gemacht habe, wie die Schaltung optimal oder am Besten wäre, sondern, ich hatte sie zufällig in meiner Bastelkiste...
das ist nicht dein ernst?!

Also, es ist nicht so kompliziert, 12 davon sind 74HC244, Tristate Treiber, ein ATmega, ein Paar Schieberegister, Zähler, 3zu8 Dekoder... Würde sagen, lauter Standard-Bausteine.
+fricky schrieb:
na, dann wäre vielleicht das hier was für dich: http://www.amd.com/epd/pr ....... am/24.lansc520/index.html
(x86-kompatibel und so)

Package Pin Count and Type 388 PBGA
das ist nicht dein ernst?! :) Nix für meinen "Schlitz"-Lötkolben. :)
+fricky schrieb:

aber wenn du mehr auf basteln stehst (was ich vermute, siehe oben), dann vielleicht doch eher sowas: http://www.mycpu.eu/
:)
Genau, ich stehe auf Basteln. MyCPU ist interessant, wenn man aber bereits mal mit FPGAs in Berührung gekommen ist und zufällig ein FPGA-Board besitzt, dann, nun ja, 8-Bit CPU, hm, hm... :)
Und wenn man zufällig ein Paar alte 80386 CPUs besitzt, wo man an die Pins auch noch mit nem "Schlitz"-Lötkolben drankommt, warum nicht irgendwas damit bauen. x86 Assembler-Programmierung kann man zwar am PC schön erlernen und vielleicht sogar irgendwie irgendwo anwenden, aber so richtiges Verständnis für die "Physik" fehlt einem irgendwo. Wie ist es mit dem Datenbus, mit dem Adressbus, wie sieht Adressbus aus, welche Steuersignale sind da, was bedeuten sie, was kann man damit machen usw. Eine selbstgebastelte funktioniernde Platine wäre für mich, dass ich u.a. auch diese "Physik"-Ebene verstanden habe...
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 23:09:13 30.03.2009   Titel:              Zitieren

Ich sehe es schon vor mir: Anleitung von abc.w und mir: "Do-it-yourself-PC&OS": Wir basteln uns unseren PC und anschließend coden wir unser OS. :D ;)

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 23:36:32 30.03.2009   Titel:              Zitieren

Mit der Bitte um Feedback bezüglich Design:
HTML:
http://www.henkessoft.de/OS_Dev/Downloads/13 C.zip

(enthält eine Testvariante mit funktionierendem keyboard driver in C, noch nicht im Tutorial veröffentlicht)

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 23:37:51 30.03.2009, insgesamt 2-mal bearbeitet
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 09:17:28 31.03.2009   Titel:              Zitieren

abc.w schrieb:

Package Pin Count and Type 388 PBGA
das ist nicht dein ernst?! :) Nix für meinen "Schlitz"-Lötkolben. :)

ach, du hast doch bestimmt irgendwo 'nen backofen rumstehen.

abc.w schrieb:

Genau, ich stehe auf Basteln. MyCPU ist interessant, wenn man aber bereits mal mit FPGAs in Berührung gekommen ist und zufällig ein FPGA-Board besitzt, dann, nun ja, 8-Bit CPU, hm, hm... :)
Und wenn man zufällig ein Paar alte 80386 CPUs besitzt, wo man an die Pins auch noch mit nem "Schlitz"-Lötkolben drankommt, warum nicht irgendwas damit bauen.

datenbusbreite ist doch nicht wichtig. 8-bitter können auch schnell sein. wenn du sowieso mit FPGA's rumfummelst, musste dir auch keine schaltung aus alten schrott-ICs basteln. mach dir 'nen x86-core und etwas peripherie in deinen FPGA rein, und fertig.
:)
u_ser-l
Unregistrierter




Beitrag u_ser-l Unregistrierter 12:30:08 31.03.2009   Titel:   re            Zitieren

was ist eigentlich aus f-cpu geworden ?
abc.w
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2008
Beiträge: 1366
Beitrag abc.w Mitglied 23:17:51 31.03.2009   Titel:              Zitieren

Hab die 13 C.zip bei mir mal ausprobiert und hatte schon wieder diese komische Fehlermeldung von mingw make (möchte aus welchen Gründen auch immer MinGW Tools verwenden :), habe auch noch die Verzeichnisse in PATH für nasm und DJGPP gar nicht angepasst und benutze im Makefile absolute Pfadangaben):
Code:
del kernel.o
process_begin: CreateProcess(NULL, del kernel.o, ...) failed.
make (e=2): Das System kann die angegebene Datei nicht finden.
make: *** [all] Error 2

Dann im makefile die Aufrufe von del wie den Aufruf von copy geändert:
Code:
1
2
3
4
5
6
7
8
9
10
    cmd /c del kernel.o
   
    cmd /c del ckernel.o
    cmd /c del video.o
    cmd /c del keyboard.o
    cmd /c del math.o
    cmd /c del util.o
   
    cmd /c del ckernel.bin
    cmd /c del boot.bin  
Und es funktioniert auch mit dem mingw make...
Mit der make.exe, die in der zip-Datei mit dabei ist, funktioniert es auch ohne zusätzliches "cmd /c ". Ich sehe grade, dass die make.exe aus der zip-Datei die gleiche ist wie die c:\djgpp\bin\make.exe.
Hm, mingw scheint irgendwie eigenwilliger als DJGPP zu sein. Kleine Inkompatibilitäten und so was...
abc.w
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2008
Beiträge: 1366
Beitrag abc.w Mitglied 23:39:09 31.03.2009   Titel:              Zitieren

+fricky schrieb:
datenbusbreite ist doch nicht wichtig. 8-bitter können auch schnell sein. wenn du sowieso mit FPGA's rumfummelst, musste dir auch keine schaltung aus alten schrott-ICs basteln. mach dir 'nen x86-core und etwas peripherie in deinen FPGA rein, und fertig.

Bezüglich x86 Core habe ich mir mal echt darüber Gedanken gemacht, einen in VHDL zu implementieren. Die "Komplexität" hat mich abgeschreckt, Real Mode, Protected Mode, elf Adressierungsarten, Anzahl der Befehle, Codierung der Befehle wie irgendwelche Präfixe, die mal auf die Berechnung der Adresse, mal auf die Operandenbitbreite Auswirkung haben usw... Ich habe auch mal darüber nachgedacht, eine Art Untermenge von 386 zu "implementieren", einen Core, der bereits im Protected Mode ist, nur wenige Befehle kann usw. Und dann ist noch die Sache bezüglich "lad mal nen Core", man muss ja noch das Programm irgendwie mitladen, wenn denn auf dem FPGA Platz dafür ist...
Gibt es irgendwo einen freien x86 IP ab 80386, am Besten in VHDL?
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 00:32:01 01.04.2009   Titel:              Zitieren

@abc.w: danke für deine Tests mit mingw. Geht denn jetzt auch das Linken? Wie hast Du das geschafft?

Den Code zum Keyboard Driver habe ich hoffentlich noch etwas klarer gemacht. Vielleicht schaffe ich noch eine vereinfachte Variante mit nur einer Keymap und ohne Shift-Abfrage. Muss mir mal andere keymaps anschauen, ob diese einem allgemeinen Standard folgen, denn wir wollen ja auch unsere deutsche Tastatur durch einfaches Übernehmen anderer keymaps nutzen.

Kapitel zum Keyboard Driver im Tutorial:
http://www.henkessoft.de/OS_Dev/OS_Dev1.htm#mozTocId185043
(dort ist auch der Sourcecode zum Download bereit)

Ich hoffe, dass man es noch versteht, was ich da von mir gebe.
Die Grundideen sind ziemlich einfach:
Man holt den Scancode von Port 0x60, analysiert Bit7 (key pressed or released?),
filtriert (=unterdrückt) den Shift-Tasten Scancode, speichert das Ergebnis in einer Variable ShiftKeyDown
und gibt dann den Scancode der nachfolgenden Taste zurück.
Damit steigt man dann in die richtige Keymap (Shift oder Non-Shift) und gibt mittels k_getch() das zum Scancode passende Zeichen zurück.
Das ganze geht sicher auch einfacher, aber ich möchte die Bildung des Scancodes aus Pressed/Released-Bit und 7-Bit-Tasten-Nummerierung klar machen. Da fehlt noch ein Bild.

Dieser kleine ohne Schnörkel daher kommende Text im Internet hat mir am besten geholfen, das Thema Scancode zu verstehen: :)
http://www.qzx.com/pc-gpe/keyboard.txt

Das nächste logische Thema wären dann wohl Interrupts, was denkt ihr? :confused:

@abc.w:
Zitat:
Ich habe mich auch mal mit einem eigenen OS in Assembler beschäftigt zwecks endlich mal den Protected Mode der Intel CPUs zu verstehen. Habe aber diesbezüglich versagt und daraus wurde nichts. Hm, vertane Lebenszeit... hätte lieber in was anderes und sinnvolleres investieren sollen.
Ich hoffe, Du bist dem Protected Mode schon etwas näher gekommen. ;)

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 21:56:44 01.04.2009, insgesamt 8-mal bearbeitet
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 09:15:10 01.04.2009   Titel:              Zitieren

abc.w schrieb:

Gibt es irgendwo einen freien x86 IP ab 80386, am Besten in VHDL?

http://www.opencores.org/?do=project&who=zet86
:)
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 20:14:44 01.04.2009   Titel:              Zitieren

Beim Recherchieren habe ich eine ausführliche neue Tutorial-Serie (bisher 19 Teile) gefunden, didaktisch allerdings nicht geschickt gemacht, dafür in englisch und vollgestopft mit Detail-Infos:
http://brokenthorn.com/Resources/OSDev1.html

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
abc.w
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2008
Beiträge: 1366
Beitrag abc.w Mitglied 23:10:06 01.04.2009   Titel:              Zitieren

@Erhard: Bezüglich Linken mit mingw hab ich es leider nicht hingegriegt. Benutze nun DJGPP. Es ist nur so, dass meine Pfade auf mingw Verzeichnisse eingestellt sind und wenn ich make in der Eingabeaufforderung aufrufe, mingw make ausgeführt wird. Und da kamen wieder die komischen Fehlermeldungen. Und ich wollte wissen, woran es liegt...

Bezüglich des nächsten logischen Themas über Interrupts: Ich halte grade ein älteres Buch von Klaus-Dieter Thies "Die Innovativen 80286/80386 Architekturen" Teil 2. Im ersten Kapitel Basis-Programmier-Modell gibt es einen Unterkapitel "Ausnahmen und Interrupts". Vielleicht wäre das nächste logische Thema nicht nur über Interrupts alleine (als asynchrone Ereignisse), sondern auch über Ausnahmen (als synchrone Ereignisse) sinnvoll...

Erhard Henkes schrieb:
@abc.w:
Zitat:
Ich habe mich auch mal mit einem eigenen OS in Assembler beschäftigt zwecks endlich mal den Protected Mode der Intel CPUs zu verstehen. Habe aber diesbezüglich versagt und daraus wurde nichts. Hm, vertane Lebenszeit... hätte lieber in was anderes und sinnvolleres investieren sollen.
Ich hoffe, Du bist dem Protected Mode schon etwas näher gekommen. ;)
Hm, ja, bisschen :) Aber noch weit davon entfernt, mal aus dem Stegreif eigene Tasks anlegen zu können, die sich nicht gegenseitig kaputtmachen könnten :)

+fricky schrieb:
abc.w schrieb:

Gibt es irgendwo einen freien x86 IP ab 80386, am Besten in VHDL?

http://www.opencores.org/?do=project&who=zet86
16 bit Zet processor equivalent to an Intel 80186. Ich hätte gerne einen ab 80386... :) Ich hatte auch mal danach recherchiert, es gibt irgendwie keine, nicht mal "kostenpflichtige", warum auch immer.
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 23:30:48 01.04.2009   Titel:              Zitieren

Zitat:
Vielleicht wäre das nächste logische Thema nicht nur über Interrupts alleine (als asynchrone Ereignisse), sondern auch über Ausnahmen (als synchrone Ereignisse) sinnvoll...

Ja, das gehört zusammen: Gates, Interrupts, Traps, Exceptions.
Ich bin am nachdenken, wie man dieses Kapitel am besten anpackt.
Mir war es nur wichtig zu zeigen, dass man auch ohne Interrupts Daten per Polling aus dem Tastaturpuffer abholen kann. Das ist aber, als würde man ständig an der Tür stehen, um zu öffnen, falls jemand kommt (eben weitgehend unnötiger Aufwand). Nun wird nach dem Umzug nach PM wieder die "Klingel" eingeführt, damit wir asynchron auf "echten" Bedarf reagieren können. ;)

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 01:44:59 02.04.2009, insgesamt 2-mal bearbeitet
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 09:54:51 02.04.2009   Titel:              Zitieren

Erhard Henkes schrieb:

Ja, das gehört zusammen: Gates, Interrupts, Traps, Exceptions.
Ich bin am nachdenken, wie man dieses Kapitel am besten anpackt.

diese 'call gates' sind eine x86-spezialität. die würde ich getrennt erwähnen.
:)
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 20:33:37 02.04.2009   Titel:              Zitieren

Ich habe eine Nomenklatur-Frage. Man benötigt in den verschiedenen C-Modulen immer wieder eine ganze Menge extern definierter Funktionen. Dies erfolgt oft durch Inkludieren einer Header-Datei namens "system.h", in der man dann alle "externen" Funktionen und einiges andere deklariert/definiert. Mir gefällt der Name "system.h" nicht besonders, weil er nicht wirklich verständlich ist. System kann alles und nichts sein. :rolleyes:

Folgende Ideen habe ich bisher:

functions.h
function_prototypes.h
kernel.h
operating_system.h
os.h

Wie würdet ihr diesen Header nennen, der dann fast in jedem Modul am Anfang zu finden ist? Mein Favorit ist bisher "os.h". Lässt man geistig das "o" weg, landet man tatsächlich bei "system.h".
Vielleicht hat jemand eine viel bessere Idee. :)

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
abc.w
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2008
Beiträge: 1366
Beitrag abc.w Mitglied 20:39:48 02.04.2009   Titel:              Zitieren

#include <PrettyOS.h> ?
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 00:26:52 03.04.2009   Titel:              Zitieren

Die Idee ist o.k. Ich wollte den Namen aber noch ändern können, ist nur der Entwicklungs-Deckname. ;)
Habe mich vorerst für os.h entschieden.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 00:27:25 04.04.2009, insgesamt 1-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 00:11:14 04.04.2009   Titel:              Zitieren

Ich benötige eure Unterstützung, weil ich die Lücke nicht finde. :rolleyes:

Exceptions und Timer Interrupt IRQ 0 gehen.
Wenn ich den keyboard_handler (polling geht ja bestens) zum Testen auf den IRQ0 (18,222 Ticks/sec) umlege, funktioniert er wie beabsichtigt.

Allerdings kommt der Keyboard Interrupt IRQ1 nicht an. :confused: EDIT: Er wird nicht ausgelöst, weil der Tastatur-Puffer nicht leer ist (das berühmte "flushen" hat mich wieder eingeholt).

Hier der gesamte - noch nicht funktionierende - Sourcecode: http://www.henkessoft.de/ ....... 0funktioniert%20nicht.zip

Ich denke, dass der C-Code für die Interrupt-Behandlung in Ordnung ist, habe ihn mehrfach gecheckt. Vielleicht liegt es am Assemblercode isr.asm (Stack?) oder am Linker-Script? Hier ein Screenshot vom OS (timer IRQ geht, habe ihn auf eine Minute im Bildschirm-Ausdruck eingestellt, Zeit stimmt unter Bochs aber nicht): http://www.henkessoft.de/OS_Dev/Downloads/IRQ_Test.PNG

Ich hoffe, das jemand den blöden Fehler bezüglich IRQ1 und vielleicht auch der anderen (welchen kann man am einfachsten testen?) findet, damit wir rasch weiter kommen. Wie gesagt, IRQ0 geht bestens (einfach mal auf key_handler umlegen).
Wenn man mit
Code:
__asm__("int $0x21");
im Kernel Programm main()
den IRQ1 (--> 33 = 0x21) selbst auslöst, kommt auch der keyboard_handler ins Spiel.

Das heißt, warum wird der IRQ1 nicht weiter geleitet? (IDT Problem?)

@Nobuo T, abc.w, Bitsy, +fricky et.al.:
Lasst mich bitte nicht hängen! Wer diesen Mist-Fehler findet, wird im Tutorial extrem gelobt. EDIT: Hauptproblem inzwischen gelöst, aber ich würde mich freuen, wenn ihr trotzdem mal über den Code schaut. Das Thema IDT, IDTR, ISR, Exceptions, ... ist wichtig.



EDIT: In einem anderen Forum habe ich erfahren, dass man den Tastatur-Puffer leeren muss, damit neue Interrupts gesendet werden. Klingt logisch. Daher habe ich einfach folgendes gemacht:

Ein einmaliges
Code:
__asm__("int $0x21");

reicht bereits aus, um den Prozess zu starten.
Soll ich ein
Code:
keyboard_init(){__asm__("int $0x21");}

schreiben, das ich einmal zu Beginn der main() aufrufe??

Es gibt noch eine zweite - evtl. bessere - Lösung:
Code:
1
2
3
4
5
6
7
8
void keyboard_init()
{
    /* Wait until buffer is empty */
    while (inportb(0x64) & 0x01)
      inportb(0x60);
 
    // __asm__("int $0x21"); // ?
};


Hier ist jetzt der funktionierende Code, allerdings alles noch im Experimentierstadium:

http://www.henkessoft.de/ ....... est_IRQ1_funktioniert.zip

Welchen Interrupt würdet ihr nach IRQ0 (Zeit-Ticks) und IRQ1 (Tastatur) als nächstes probieren?

Speichermanagement, Multitasking, ... warten. Allerdings muss ich zugeben, dass das gesamte Thema OSDEV ziemlich knifflig ist und man die Tools wirklich beherrschen muss. meine Tool-Schwachpunkte sind AT&T Syntax und Linker-Skript. Der verwendete DJGPP mit gcc 3.1 ist auf jeden Fall die richtige Wahl.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 02:43:04 04.04.2009, insgesamt 14-mal bearbeitet
Bitsy
Mitglied

Benutzerprofil
Anmeldungsdatum: 01.05.2001
Beiträge: 518
Beitrag Bitsy Mitglied 05:22:46 04.04.2009   Titel:              Zitieren

Probiere mal irgendeinen von 3-8, wobei man das anzusteuernde Device auch auf einen der oberen Interrupts legen können sollte, und dann kümmere Dich um den 2er, weil Du den brauchst, wenn Du an die oberen 8 ran willst. Wenn das Gerät dann auch z.B. mit dem 10er ansprechbar ist, stehen überhaupt erst mal alle IRQs zur Verfügung! Also - erst eine einfache Interruptgeschichte 'unten', und dann schauen, dass sie auch 'oben' läuft.

Wenn der 2er Probleme macht - ich sollte noch einen Sourcecode haben, bei dem ich eine vierfache Serielle angesteuert habe, wobei der letzte Kanal eben nur über IRQ 10 erreichbar war. Die waren damals sehr dankbar, dass es überhaupt mal ein Stück Software gab, mit dem man den überhaupt ansprechen konnte ;)

Freut mich übrigens, dass der 3er DJGPP soweit funktioniert - hatte Dir ja in der Mail die Problematik erklärt.


Zuletzt bearbeitet von Bitsy am 05:32:46 04.04.2009, insgesamt 2-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 12:18:15 04.04.2009   Titel:              Zitieren

@Bitsy:
Das sind die Mechanismen, die versuchsweise eingebaut sind, muss aber noch prüfen, ob alles wirklich funktioniert, bisher wurden ja nur IRQ0 (clock) und IRQ1 (keyboard) behandelt:

..

Daher kann ich mit
C++:
__asm__("int $0x21"); // 0x21 = 33, gemappt auf IRQ1 (Keyboard)

den Keyboard-Interrupt selbst anstoßen.

Das mit den Interrupts finde ich ganz lustig. Die Keyboard-Ports und der Keyboard-Puffer haben mich fast aus der OS-Kreisbahn geworfen, weil man diesbezüglich viel unausgegorenes und verwirrendes Zeug im Internet findet.

@Bitsy: Hast Du eine Idee, wie man das Linker-Problem (mit dem a.out Format) des mingw überwinden könnte? abc.w präferiert diese Toolchain. :confused:

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 10:44:43 05.10.2013, insgesamt 9-mal bearbeitet
abc.w
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2008
Beiträge: 1366
Beitrag abc.w Mitglied 13:11:30 04.04.2009   Titel:              Zitieren

Bezüglich Linker-Problem mit mingw würde mich zwar interessieren, wie man es irgendwie hinkriegen könnte. Aber, wenn es nicht geht, aus welchen Gründen auch immer, ist auch nicht schlimm. Ich habe ja noch DJGPP.
Ich habe mir den Quellcode 14_C_Test_IRQ1_funktioniert geholt und ausprobiert. Eines stört mich jetzt ein wenig. Zunächst, auf der einen Seite haben wir Assembler-Dateien, die mit nasm assembliert werden. Auf der anderen Seite gibt es c-Dateien, die aber hie und da eine Funktion mit Assembler Inline-Code enthalten. Das ist irgendwie nicht konsistent. Einmal nasm, dann gcc, dann inline-gcc. Wäre vielleicht sinnvoll, wenn c-Datei, dann C, wenn Assembler-Datei, dann Assembler nasm. Und die Funktionen mit Assembler Inline-Code rein in Assembler implementieren? Nur als Vorschlag. Optimal wäre natürlich, statt nasm GNU as zu verwenden, weiss aber jetzt nicht genau, ob man 16-Bit Assembler Quellcode mit as assemblieren kann. Vorteil davon wäre noch, dass man nur ein Tool bräuchte: DJGGP. GNU as ist nämlich in DJGPP mitenthalten.
abc.w
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2008
Beiträge: 1366
Beitrag abc.w Mitglied 13:38:24 04.04.2009   Titel:              Zitieren

Eine andere Sache, wollte ein Paar Ausnahmen provozieren mit diesem Code:
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
.global _k_zero_divide
.global _k_undefined_op
.global _k_null_pointer
 
.section .text
 
_k_zero_divide:
    movl $0, %eax
    div %eax
    ret
 
_k_undefined_op:
    ud2
    ret
 
_k_null_pointer:
    movl $0, %eax
    movl %eax, (%eax)
    ret

Division durch 0 und undefinierter Op :live:
Die Funktion k_null_pointer() wir aber ausgeführt und das System läuft :confused: Oder ist Zugriff mit Offset Null ok :confused:
Nobuo T
Moderator

Benutzerprofil
Anmeldungsdatum: 09.10.2001
Beiträge: 4762
Beitrag Nobuo T Moderator 15:01:46 04.04.2009   Titel:              Zitieren

Erhard:
Irgendwie habe ich inzwischen ein wenig den Ueberblick verloren. Kannst du mal irgendwie ein Verzeichnis oder eine Seite einrichten, wo man waehrend der Entwicklung immer mal die aktuellen Codes runterladen kann?

Bei deinem ersten KB-Polling hat mich ehrlich gesagt schon etwas gewundert, dass das ueberhaupt funktionierte. Klassischerweise macht man das AFAIR so, dass man einen Handler fuer IRQ 1 installiert. Dort checkt man erstmal, ob etwas im input buffer ist (port 64h, Bit0). Falls was dran liegt, port 60h auslesen und irgendwie verarbeiten (scancodes oder evtl. sonstige spezial-codes).
Zum Abschluss immer ACK an das keyboard, indem ein reset ausgefuehrt wird: Kurz aus- und wieder einschalten ueber Port 61h, Bit7. Zum Ende natuerlich noch EOI an den PIC. Ist dann zwar immer noch ziemlich primitiv, sollte so aber zumindest keine Probleme geben...

abc.w:
Ich kann nur vermuten, dass einfach (noch?) kein Paging aktiviert ist, mit dem eine Ausnahme beim Zugriff auf einen 0-Pointer ausgeloest wuerde. An der physikalischen Adresse 0 ist nun mal einfach normaler RAM, also an sich kein Problem.

_________________
==Mod im Assembler-Forum==

http://z0r.de/2908
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 15:51:46 04.04.2009   Titel:              Zitieren

Zitat:
nasm, dann gcc, dann inline-gcc. Wäre vielleicht sinnvoll, wenn c-Datei, dann C, wenn Assembler-Datei, dann Assembler nasm. Und die Funktionen mit Assembler Inline-Code rein in Assembler implementieren?

Du hast völlig Recht. Die bisherige "gemischte" Lösung liegt an meinen Problemen mit der AT&T Syntax. Auf der einen Seite ist es wichtig, dass Einsteiger sehen, wie einfach man zwischen C- und ASM-Code hin und her springen kann. Man benötigt nur global, extern und den führenden Unterstrich. Auf der anderen Seite führt dies zu einem Hin- und Hergehüpfe. Ich werde daher versuchen, Deine Idee aufzunehmen. Vielleicht kann Nobuo T da etwas unterstützen. :)

Zitat:
... statt nasm GNU as zu verwenden, weiss aber jetzt nicht genau, ob man 16-Bit Assembler Quellcode mit as assemblieren kann. Vorteil davon wäre noch, dass man nur ein Tool bräuchte: DJGGP. GNU as ist nämlich in DJGPP mitenthalten.

Habe mir die Syntax von as bisher noch nicht angeschaut. AT&T?

Zitat:
Kannst du mal irgendwie ein Verzeichnis oder eine Seite einrichten, wo man waehrend der Entwicklung immer mal die aktuellen Codes runterladen kann?

@Nobuo T:
Ja, wird sofort gemacht: Den letzten Code erhält man ab jetzt immer unter diesem Link (wurde aber im Tutorial noch nicht beschrieben, weil er sich im Entwicklungs-/Testzustand befindet; daher sind gute Ideen - wie oben von abc.w zum Thema Exception - immer gerne gesehen. Bitte ausreichend kommentieren.):

:arrow: :arrow: :arrow: Link zur jeweils aktuellsten Test-Version:
http://www.henkessoft.de/ ....... PrettyOS_last_version.zip

Was abc.w anspricht ist mein Hin- und Herhüpfen zwischen C-Code (vor allem zum Thema Interrupts) und isr.asm.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 16:03:15 04.04.2009, insgesamt 4-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 16:22:42 04.04.2009   Titel:              Zitieren

Zitat:
Die Funktion k_null_pointer() wird aber ausgeführt und das System läuft :confused: Oder ist Zugriff mit Offset Null ok :confused:
Zitat:
Ich kann nur vermuten, dass einfach (noch?) kein Paging aktiviert ist, mit dem eine Ausnahme beim Zugriff auf einen 0-Pointer ausgeloest wuerde. An der physikalischen Adresse 0 ist nun mal einfach normaler RAM, also an sich kein Problem.
Stimmt, Paging wurde noch nicht aktiviert. Das gehört sinnvollerweise als Vorteil zu Multitasking, wenn ich das richtig sehe.

Zitat:
Klassischerweise macht man das AFAIR so, dass man einen Handler fuer IRQ 1 installiert.
Richtig, klassischerweise. Aber es geht eben auch ohne Interrupt. Dieses ineffiziente Polling wollte ich zuerst zeigen, damit die Notwendigkeit der Interrupts verständlich wird.

Diese beiden Punkte bestätigen mich in meiner Vorgehensweise. Ich versuche die didaktische Reihenfolge im Tutorial so aufzubauen, wie man Funktionen/Strukturen in ASM oder C für die beabsichtigte Umsetzung wirklich benötigt. Also pyramidal.

Die bisherige Reihenfolge war deshalb:

- Bootbarer Minikernel
- Bootloader + nachgeladenem Kernel
- Auf Instruktionen im RM reagieren (dank BIOS einfache Handhabung)
- A20-Gate und PM aktivieren, GDT/GDTR (das gehört wohl als Minimum zusammen)
- Sprung vom ASM- zum C-Kernel
- Rudimentäre Textausgabe auf Bildschirm
- Rudimentäre Texteingabe mit Tastatur
- IDT/IDTR, Interrupts, Exceptions allgemein
- IRQ 0 (System Clock Tick jede 18,22 sec)
- IRQ 1 (Keyboard, durch Port 0x60 u. 0x64 etwas komplizierter)
- ... (immer spannend halten) ;)

Ich kann nur hoffen, dass dieses Konzept sinnvoll ist. :confused:

Was würdet ihr als notwendige nächste "Blöcke" auf die Pyramide wuchten?

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 16:58:45 04.04.2009, insgesamt 2-mal bearbeitet
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 22:21:11 04.04.2009   Titel:              Zitieren

Erhard Henkes schrieb:

Zitat:
Klassischerweise macht man das AFAIR so, dass man einen Handler fuer IRQ 1 installiert.
Richtig, klassischerweise. Aber es geht eben auch ohne Interrupt. Dieses ineffiziente Polling wollte ich zuerst zeigen, damit die Notwendigkeit der Interrupts verständlich wird.

ehrlich gesagt, würde ich als noob nicht einsehen, wozu man einen dedizierten keyboard-interrupt braucht, wenn man die tastatur auch pollen kann (auch wenn ich verstanden habe, wie interrupts funktionieren). warum sollte polling ineffizient sein? so lange ich die tastatur häufig genug polle, so daß ich mit der tastenfrequenz eines schnellschreibers klar komme, ist die welt doch in ordnung. und wenn mir einer erzählen würde, dass die cpu beim pollen sinnlos zyklen verballert, würde ich antworten: "na und? dann polle ich eben in der timer-isr. ca. 18 anschläge/s als samplingrate sollte doch reichen".
:)
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 22:34:11 04.04.2009   Titel:              Zitieren

Erhard Henkes schrieb:

Was würdet ihr als notwendige nächste "Blöcke" auf die Pyramide wuchten?

schwer zu sagen. der vollständigkeit halber vielleicht weitere hardwarekomponenten eines 0815-pc's behandeln, wie z.b. ansteuerung/benutzung der RTC, des piezo-piepsers, bustreiber bauen usw. allerdings besteht die gefahr, dass das alles langwierig, kompliziert und langweilig werden kann. vielleicht, um die spannung zu erhalten, das os soweit ausbauen, dass die erste, einfache anwendung laufen kann, z.b ein tetris clone oder so.
:)
Nobuo T
Moderator

Benutzerprofil
Anmeldungsdatum: 09.10.2001
Beiträge: 4762
Beitrag Nobuo T Moderator 23:57:46 04.04.2009   Titel:              Zitieren

Naja, PIT (und damit auch den speaker) und PIC vielleicht mal kurz anschneiden. Das sollte zur Standard-Peripherie IMHO dann aber wirklich erstmal reichen. Was die OS-Thematik betrifft hast du ja bis jetzt eigentlich wirklich nur ganz vorsichtig an der Oberflaeche gekratzt, weitere Nebensaechlichkeiten wie die RTC oder irgendwelche BUS-Geschichten sollte man da IMHO vermeiden.

Mein Vorschlag waere als Anschluss an deine Pyramide dann mal langsam in die abstrakteren, eigentlich interessanten Gefilde des OS-Designs einzusteigen. Da ist das Grundlegenste als naechstes vermutlich die dynamische Verwaltung des RAM: Knappe Einfuehrung in die Problematik und Vorstellung einfacher Loesungsansaetze wie Unterteilung des Speichers in Bloecke statischer Groesse (vielleicht praktischerweise gleich 4KB gross ;) ) und Verwaltung in statischen Arrays, Bitmaps oder dynamischen Free-Lists, Reservierungsstrategie next fit, evtl. ganz knapp noch Wiedereingliederungsproblematik (das weiter auszuwaelzen waere dann IMHO wirklich eher Stoff fuer ein richtiges Buch).
Weitermachen kannst du dann evtl. mit einer knappen Einfuehrung in Paging. Das spielt schliesslich eigentlich auf fast jeder Multitaskingmaschine eine Rolle.

Danach koenntest du dich dann vorsichtig an den Komplex Programme, Prozesse und Multitasking herantasten, mit einem knappen Ueberblick zum Thema Prozesserzeugung und Kontextwechsel, Scheduling und Verdraengung.
Dann vielleicht quasi zum Abschluss noch einen Abstecher zu Privilegien, Adressraumtrennung/Schutzmechanismen und Micro- vs Macro-Kern sowie IPC.

_________________
==Mod im Assembler-Forum==

http://z0r.de/2908


Zuletzt bearbeitet von Nobuo T am 00:08:20 05.04.2009, insgesamt 3-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 00:43:29 05.04.2009   Titel:              Zitieren

Zitat:
"na und? dann polle ich eben in der timer-isr. ca. 18 anschläge/s als samplingrate sollte doch reichen".


EDIT: Die korrekte Frequenz wurde eingefügt, um keinen Verwirrung zu stiften. (thanks to +fricky)
Der Timer "feuert" mit einer Frequenz von 1193182 Hz / 65536 = 18,2065 Hz. Wenn man nichts anderes machen will als Tippen, ist das Polling sicher o.k. :D
Dann stößt man den Keyboard_handler einfach beim Timer_handler mit an. Ich habe das in der Tat genau so gemacht, als ich blöderweise den Tastaturpuffer nicht gelöscht hatte und dadurch kein IRQ1 kam, um zu sehen, ob der Keyboard_handler korrekt funktioniert. Ging tadellos. Von daher könnte man ein IRQ0-gesteuertes Keyboard-Polling als Alternative in Betracht ziehen.
Wirklichen Sinn macht es aber keinen, weil der Interrupt am Master PIC bereits fest vergeben ist. ;)

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 18:35:41 06.04.2009, insgesamt 3-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 01:01:01 05.04.2009   Titel:              Zitieren

Ich fasse mal die wirklich interessante Taskliste von Nobuo T zusammen:

- PIC (die beiden PICs wurden bereits beim remapping von IRQ 0-15 verarbeitet)
- PIT (programmable interval timer)
- Speaker (ja, BEEP (frequence)! Seit Win NT kaputt wegen Behinderung.)
- (video.c vernünftig ausbauen, bisher nur rudimentär)
- OS-Thematik (generell)
- Dynamische RAM Verwaltung:
- Unterteilung des Speichers in Blöcke statischer Groesse (4KB)
- Verwaltung (stat. Arrays, Bitmaps, dynam. Free-Lists)
- Reservierungsstrategie next fit
- Wiedereingliederungsproblematik
- Paging
- Programme & Prozesse
- Multitasking vs Singletasking
- Prozesserzeugung, Kontextwechsel, Scheduling, Verdrängung
- Privilegien / Schutzmechanismen / Adressraumtrennung
- Micro- vs Macro-Kernel
- inter-process communication

Das wird aber noch einige Zeit brauchen, denn ich möchte dies ja auch praktisch fassbar machen.

Kleines Übersichtsbild aus Internet:
http://ezs.kr.hs-niederrh ....... erBuch/html/os_aufbau.png

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 01:24:33 05.04.2009, insgesamt 3-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 01:09:25 05.04.2009   Titel:              Zitieren

@Nobuo T: Könnte man die isr.asm komplett in die C-Module packen? Ich schaffe das leider syntax-mäßig nicht. Mir gefällt es eigentlich auch so, hier wurde aber mehr Ordnung verlangt. Wie siehst Du das?

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 01:14:25 05.04.2009, insgesamt 1-mal bearbeitet
Bitsy
Mitglied

Benutzerprofil
Anmeldungsdatum: 01.05.2001
Beiträge: 518
Beitrag Bitsy Mitglied 10:49:58 05.04.2009   Titel:              Zitieren

Ich glaube, der vorrangigste Punkt wäre nun eine Diskussion über die Architektur des OS an sich - und ob und wie solch ein 'Wunsch-OS' auf dem PC realisierbar ist.

Ich erinnere dabei an den absolut linearen Speicher eines guten alten 68000er-Systems, bei dem z.B. dem Videochip (des Atari) einfach zwei Adressen für den physikalischen und den logischen Bildschirmspeicher mitgeteilt wurden.
Da gibt es einen massiven Unterschied zum Realmode-PC.
(Über die Wichtigkeit eines VBL-interrupts möchte ich mich hier gar nicht auslassen - scheinen einige Grafikkartenhersteller immer noch nicht begriffen zu haben.)

An dieser Stelle spielt nämlich durchaus bereits DMA mit rein.

Ich möchte die Komplexität an einem kleinen Beispiel festmachen:
Nehmen wir mal an, ich möchte einen virtuellen Synthesizer mit dem Rechner realisieren. (Etwas, was auf dem Atari kein Problem war, unter DOS gerade noch ging, und unter Windows schon unter die höheren Künste der Programmierung fällt).
Da gibt es nämlich ein kleines Latenzproblem, dass je nach OS immer größer wird.
Wir haben einmal ein MIDI IN (könnte ja auch was anderes sein), also einen seriellen Stream, der mir Daten über gewünschte Änderungen (im Sound) liefert.
Die Software muss nun hingehen, und das Sample berechnen - und diese Daten so schnell wie möglich in den Speicher schreiben, und zwar - und nun kommt's - unmittelbar vor den derzeitigen Lesepunkt des Sound-DMAs!
Wenn ich - wie ab dem XP - eine 'geschützte' Hardware habe, bin ich auf ein OS angewiesen, was mir entsprechende Funktionen zur Verfügung stellt, die mir solche Aktionen erlauben. Fehlt sowas, kann der Rechner vielleicht wunderbar zig Medien abspielen, aber für diese Anwendung ist er unbrauchbar.

Oder nehmen wir den Fall Robotik:
Da wäre es sinnvoller der Applikation die Masse der Rechenzeit zu geben, weil es einfach wichtig ist, dass nichts durch die Lichtschranke flutscht, anstatt nachzuschauen, was gerade im Internet los ist... Also - dynamische konfigurierbare Prioritäten? Sollten vielleicht auch schon im OS stecken.


Zuletzt bearbeitet von Bitsy am 10:59:36 05.04.2009, insgesamt 3-mal bearbeitet
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 11:10:31 05.04.2009   Titel:              Zitieren

Erhard Henkes schrieb:
Könnte man die isr.asm komplett in die C-Module packen?

musstu die doku deines compilers lesen. oft muss man isr's mit einem pseudo-keyword '__interrupt' beginnen. machmal geht's mit einer #pragma-anweisung. ist halt compiler-abhängig.
:)

Bitsy schrieb:

Da gibt es nämlich ein kleines Latenzproblem, dass je nach OS immer größer wird.
Wir haben einmal ein MIDI IN (könnte ja auch was anderes sein), also einen seriellen Stream, der mir Daten über gewünschte Änderungen (im Sound) liefert.
Die Software muss nun hingehen, und das Sample berechnen - und diese Daten so schnell wie möglich in den Speicher schreiben...

MIDI ist doch ein sau-langsamer bus (32 kbits/s oder so), da kann der computer kaum die bremse sein. eher haste delays, weil der bus selber zu lahm ist. gibt's nicht schon was aktuelleres, als dieses steinzeit-protokoll?
:)
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 11:14:59 05.04.2009   Titel:              Zitieren

Erhard Henkes schrieb:
Zitat:
"na und? dann polle ich eben in der timer-isr. ca. 18 anschläge/s als samplingrate sollte doch reichen".
Da der Timer alle 18,2 ms mit IRQ0 Alarm schlägt

wieso haste ihn so schnell eingestellt? normerweise tickert der mit 18.2Hz, nicht kHz.
:)
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 12:30:21 05.04.2009   Titel:              Zitieren

@+fricky: Ja, Du hast völlig Recht, das habe ich durcheinander gebracht:
Zitat:
By default, this channel of the timer is set to generate an IRQ0 18.222 times per second.

Habe das oben korrigiert, um niemanden zu verwirren.

Im Sourcecode timer.c läuft das zur Zeit so (muss in Bochs nicht exakt stimmen):
C++:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
#include "os.h"
 
int timer_ticks = 0;
 
/* timer fires 18.222 times per second.*/
void timer_handler(struct regs* r)
{
    ++timer_ticks;
    static int z=10;
    if ((timer_ticks % 1093) == 0) // 1093 = 60*18.222
    {
        k_printf("One minute has passed", ++z, 0x0B);
    }
}
 
void timer_wait(int ticks)
{
    unsigned long eticks;
    eticks = timer_ticks + ticks;
    while(timer_ticks < eticks);
}
 
void timer_install()
{
    /* Installs 'timer_handler' to IRQ0 */
    irq_install_handler(0, timer_handler);
}

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 12:38:06 05.04.2009, insgesamt 4-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 12:43:50 05.04.2009   Titel:              Zitieren

Zitat:
dynamische konfigurierbare Prioritäten?
Das ist ein interessantes Thema. Aber da wird noch viel Code den Compiler durchfließen, bevor ich da anlange.

Momentan denke ich darüber nach, welche völlig neuen Impulse man setzen könnte, aber zuerst muss man das alte praktisch nachempfinden, sonst fehlt das Verständnis. Die Verschaltung der Hardware macht ja auch gewisse Vorgaben, die man leider akzeptieren muss.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 14:14:29 05.04.2009   Titel:              Zitieren

Erhard Henkes schrieb:

C++:
void timer_wait(int ticks)
{
    unsigned long eticks;
    eticks = timer_ticks + ticks;
    while(timer_ticks < eticks);
}

^^das sieht nicht überlauffest aus
:)
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 14:38:36 05.04.2009   Titel:              Zitieren

Was ist schon "überlauffest" auf der Welt?

C++:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
#include "os.h"
 
unsigned long timer_ticks = 0;
 
/* timer fires 18.222 times per second.*/
void timer_handler(struct regs* r)
{
    ++timer_ticks;
    static unsigned long z=10;
    const unsigned long N = 109; // 109 = 60/10*18.222
    if (!(timer_ticks % N))
        k_printf("10 seconds have passed", ++z, 0x0B);
}
 
void timer_wait(unsigned long ticks)
{
    unsigned long eticks;
    eticks = timer_ticks + ticks;
    while(timer_ticks < eticks);
}
 
void timer_install()
{
    /* Installs 'timer_handler' to IRQ0 */
    irq_install_handler(0, timer_handler);
}

Besser?

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 14:47:28 05.04.2009   Titel:              Zitieren

Erhard Henkes schrieb:

Besser?

ist doch immer noch das selbe.
so z.b:
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
unsigned long eticks;
 
void timer_handler(struct regs* r)
{
  ...
  if (eticks)
    eticks--;
}
 
void timer_wait (unsigned long ticks)
{
    disable_timer_interrupt();
    eticks = ticks;
    enable_timer_interrupt();
   
    // busy wait...
    while (eticks)
      ;
}

:)
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 17:19:21 05.04.2009   Titel:              Zitieren

Ja, gute Idee, habe es umgesetzt. Thanks @ +fricky.

So sieht momentan timer.c aus:
C++:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
#include "os.h"
 
unsigned long timer_ticks = 0;
unsigned long eticks;
 
void timer_handler(struct regs* r)
{
    ++timer_ticks;
    if (eticks)
        --eticks;
 
    //TEST
    char bufferTimerticks[20];            k_itoa (timer_ticks, bufferTimerticks);
    k_printf("             ",  6, 0x0B);  k_printf(bufferTimerticks, 6, 0x0B);
    char bufferWaitticks[20];             k_itoa (eticks, bufferWaitticks);
    k_printf("             ",  7, 0x0B);  k_printf(bufferWaitticks,  7, 0x0B);
    //TEST
}
 
void timer_wait (unsigned long ticks)
{
    timer_uninstall();
    eticks = ticks;
    timer_install();
 
    // busy wait...
    while (eticks)
    {
        k_printf("waiting time runs",   8, 0x0B);
        /* do nothing */;
    };
    k_printf("waiting time has passed", 9, 0x0B);
}
 
void sleepSeconds (unsigned long seconds)
{
    // based upon timer tick frequence of 18.222 Hz
    timer_wait((unsigned long)18.222*seconds);
}
 
void timer_install()
{
    /* Installs 'timer_handler' to IRQ0 */
    irq_install_handler(0, timer_handler);
}
 
void timer_uninstall()
{
    /* Uninstalls IRQ0 */
    irq_uninstall_handler(0);
}


ckernel.c:
C++:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
#include "os.h"
 
int main()
{
    k_clear_screen();
 
    // GDT, IDT, ISRS, IRQ, timer, keyboard
    gdt_install();
    idt_install();
    isrs_install();
    irq_install();
    timer_install();
    keyboard_install();
 
    k_printf("   ************************************************", 0, 0xA);
    k_printf("   *                                              *", 1, 0xA);
    k_printf("   *          Welcome to PrettyOS 0.05            *", 2, 0xA);
    k_printf("   *                                              *", 3, 0xA);
    k_printf("   *        The C kernel has been loaded.         *", 4, 0xA);
    k_printf("   *                                              *", 5, 0xA);
    k_printf("   ************************************************", 6, 0xA);
 
    update_cursor(8, 0);
        sti();
    while(TRUE)
    {
        static int zz=10;
        sleepSeconds(20);
        k_printf("20 sec have passed", ++zz, 0x0B);
    };
    return 0;
};


Es gibt ein offenbar bisher unerkanntes Problem:
Solange man die Finger vom Keyboard lässt läuft der timer_handler. Sobald man aber die erste Taste nach dem Drücken los lässt, bleibt der Timer (die gezählten timer_ticks) stehen. Nur bei gedrückter Taste läuft er wieder weiter. Rattenscharfer Effekt. :D

Allerdings blicke ich momentan nicht durch, warum das passiert. Da fehlt noch einiges im Keyboard-Bereich. Ich habe den Code hoch geladen, damit ihr euch das mal anschauen könnt. :)
http://www.henkessoft.de/ ....... PrettyOS_last_version.zip

Bei Keyboard Port 0x60 u. 0x64 muss ich noch mal richtig lesen. Da klafft noch eine echte Wissenslücke bei mir.

@Nobuo T: Würdest Du Dir bitte keyboard.c anschauen. Da muss ja der Wurm lauern. Deine konkreten Vorschläge von oben zum Thema Keyboard Controller wurden noch nicht umgesetzt. Mich würde interessieren, was genau den IRQ0 beim Taste-Loslassen "outknockt" und beim Taste-Drücken wieder aktiviert. ;)

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 18:11:36 05.04.2009, insgesamt 2-mal bearbeitet
Nobuo T
Moderator

Benutzerprofil
Anmeldungsdatum: 09.10.2001
Beiträge: 4762
Beitrag Nobuo T Moderator 18:30:25 05.04.2009   Titel:              Zitieren

Ok, mal wieder der Reihe nach:

Bitsy schrieb:
Ich glaube, der vorrangigste Punkt wäre nun eine Diskussion über die Architektur des OS an sich - und ob und wie solch ein 'Wunsch-OS' auf dem PC realisierbar ist.

Ich gehe mal davon aus, dass Erhard sich da schon einen groben Plan gemacht hat, was fuer eine Art von OS er fabrizieren will. Das ob ist da wohl keine Frage, das wie wird hier aktuell diskutiert. ;)

Was du da weiter anfuehrst, sind doch eher Spezialfaelle und Teilgebiete, des Themenbereichs Scheduling (Echtzeit-Prozesse). Solche Ansaetze wie Prioritaetensteuerung oder verschiedene Ansaetze fairer Ressourcenverteilung mit verschiedensten abgefahrenen queue-Konstrukten (da gibt es wirklich eine Menge weit komplizierteres als einfache Prioritaetensteuerung) kann man da vielleicht in einem Ueberblick kurz anschneiden, aber um den Rahmen nicht zu sprengen, waere mein Vorschlag, sich schliesslich einfach auf Round Robin zu beschraenken.

Und DMA-Gefrickel ist ja nun voellig abgehoben. Immer im Hinterkopf behalten, dass das ein Internet-Tutorial und kein Kompendium zur OS-Entwicklung werden soll - das wird wie ich das sehe schon so eine ordentliche Portion Stoff. :D

[OT]BTW ist das Basteln eines Synths auch auf dem PC selbst unter Windows kein groesseres Problem als unter DOS - solange man gute Hardware (am besten mit HW Wavetable Synth) oder zumindest sehr gute Treiber (zumindest directX) hat.[/OT]

Erhard Henkes schrieb:
Würdest Du Dir bitte keyboard.c anschauen. Da muss ja der Wurm lauern. Deine konkreten Vorschläge von oben zum Thema Keyboard Controller wurden noch nicht umgesetzt. Mich würde interessieren, was genau den IRQ0 beim Taste-Loslassen "outknockt" und beim Taste-Drücken wieder aktiviert. ;)

Scharfer Effekt -> reichlich daemlicher Fehler, wenn ich mich nicht verschielt habe:
FetchAndAnalyzeScancode landet in einer Endlosschleife, wenn eine Taste losgelassen wird. Mal abgesehen von dem fehlenden EOI an den PIC duerfte das geloeschte IF wohl ausschlaggebend dafuer sein, dass sich in diesem Fall dann so lange nichts mehr tut, bis du wieder eine Taste drueckst.

Kurz: Die Endlosschleife hat in FetchAndAnalyzeScancode nichts zu suchen.


BTW: Ich hatte in meiner Auflistung noch vergessen, sich mal mit der Kernel-API (und einem HW-Abstraktions/Treiber-Prinzip) deines OS zu befasssen. Alle Kernel-Funktionen, Treiber etc. einfach nur ueber C-Funktionen und header zur Verfuegung zu stellen ist sicher nicht das Wahre. :)
Ich wuerde die Einrichtung eines kleinen Sets der wichtigsten Funktionen zum I/O und spaeter dann Speicher- und Prozessverwaltung ueber Interrupts aehnlich DOS oder Linux vorschlagen.

Je nachdem, was fuer einen Kern du basteln willst (Micro oder Monolith), waere es evtl. sinnvoll, das schon ganz am Anfang beim Aufbauen der ersten abstrakteren OS-Funktionen wie RAM-Verwaltung zu diskutieren, statt erst bei Adressraumtrennung, Privilegien und IPC. Evtl. mit Verweis auf diese spaeteren Themen zur Begruendung.

_________________
==Mod im Assembler-Forum==

http://z0r.de/2908


Zuletzt bearbeitet von Nobuo T am 18:46:36 05.04.2009, insgesamt 2-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 18:49:16 05.04.2009   Titel:              Zitieren

Zitat:
FetchAndAnalyzeScancode landet in einer Endlosschleife, wenn eine Taste losgelassen wird. ...
Kurz: Die Endlosschleife hat in FetchAndAnalyzeScancode nichts zu suchen.

Uups, stimmt. Ich dachte, es wäre etwas komplizierteres. :rolleyes:
Da wimmelt es ja nur so von Endlosschleifen. Shit Polling! :D

Zitat:
Mal abgesehen von dem fehlenden EOI an den PIC duerfte das geloeschte IF wohl ausschlaggebend dafuer sein, dass sich in diesem Fall dann so lange nichts mehr tut, bis du wieder eine Taste drueckst.
Thanks.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 19:32:22 05.04.2009, insgesamt 1-mal bearbeitet
abc.w
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2008
Beiträge: 1366
Beitrag abc.w Mitglied 19:06:39 05.04.2009   Titel:              Zitieren

Erhard Henkes schrieb:
Zitat:
... statt nasm GNU as zu verwenden, weiss aber jetzt nicht genau, ob man 16-Bit Assembler Quellcode mit as assemblieren kann. Vorteil davon wäre noch, dass man nur ein Tool bräuchte: DJGGP. GNU as ist nämlich in DJGPP mitenthalten.

Habe mir die Syntax von as bisher noch nicht angeschaut. AT&T?

Ja, AT&T Syntax mit dem Nachteil von links nach rechts Lesen, so wie man es normalerweise jahrelange macht, und dem Haufen Intel-Doku, wo man von rechts nach links lesen muss. Aber Lesbarkeit scheint ja sowieso der Punkt zu sein, auf den ich hier alleine bestehe.

Ich habe mal aus Neugier die Assembler-Dateien boot.asm, kernel.asm und isr.asm nach AT&T umgesetzt und erfolgreich versucht, einmal allein mit DJGPP (im Sinne ohne nasm) und einmal mit mingw Tools eine funktionierende MyOS.bin zu bauen. Nicht, dass ich darauf bestehe, vollständig auf diese Tools umzusteigen. Ist nur "Machbarkeitsstudie". Mein Makefile dazu sieht so aus:
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
all:
    @echo Select target: mingw or djgpp.
    @echo Exit.
 
djgpp:
    @echo Building with djgpp:
    c:\djgpp\bin\as boot.s -o boot.o
    c:\djgpp\bin\ld boot.o -Ttext 0x7C00 -e _start -o boot.exe
    c:\djgpp\bin\objcopy --strip-all --only-section .text --output-target binary boot.exe boot.bin
    c:\djgpp\bin\as kernel.s -o kernel.o
    c:\djgpp\bin\as isr.s -o isr.o
   
    c:\djgpp\bin\gcc -Wall -c ckernel.c -o ckernel.o -O1  
    c:\djgpp\bin\gcc -Wall -c video.c -o video.o -O1
    c:\djgpp\bin\gcc -Wall -c math.c -o math.o -O1
    c:\djgpp\bin\gcc -Wall -c util.c -o util.o -O1
    c:\djgpp\bin\gcc -Wall -c gdt.c -o gdt.o
    c:\djgpp\bin\gcc -Wall -c idt.c -o idt.o
    c:\djgpp\bin\gcc -Wall -c isrs.c -o isrs.o
    c:\djgpp\bin\gcc -Wall -c irq.c -o irq.o
    c:\djgpp\bin\gcc -Wall -c timer.c -o timer.o
    c:\djgpp\bin\gcc -Wall -c keyboard.c -o keyboard.o
    c:\djgpp\bin\ld -T kernel.ld kernel.o isr.o ckernel.o video.o gdt.o idt.o isrs.o irq.o util.o math.o timer.o keyboard.o -o ckernel.bin
   
    cmd /c copy /b boot.bin + ckernel.bin MyOS    
   
    cmd /c del MyOS.bin
    cmd /c rename MyOS MyOS.bin
    cmd /c erase ..\MyOS.bin
    cmd /c copy MyOS.bin ..\MyOS.bin
 
mingw:
    @echo Building with mingw:
    as boot.s -o boot.o
    ld boot.o -Ttext 0x7C00 -e _start -o boot.exe
    objcopy --strip-all --only-section .text --output-target binary boot.exe boot2.bin
    dd if=boot2.bin of=boot.bin bs=512 count=1
    as kernel.s -o kernel.o
    as isr.s -o isr.o
   
    gcc -Wall -c ckernel.c -o ckernel.o -O1 -s
    gcc -Wall -c video.c -o video.o -O1 -s
    gcc -Wall -c math.c -o math.o -O1 -s
    gcc -Wall -c util.c -o util.o -O1 -s
    gcc -Wall -c gdt.c -o gdt.o -s
    gcc -Wall -c idt.c -o idt.o -s
    gcc -Wall -c isrs.c -o isrs.o -s
    gcc -Wall -c irq.c -o irq.o -s
    gcc -Wall -c timer.c -o timer.o -s
    gcc -Wall -c keyboard.c -o keyboard.o -s
    ld -Ttext 0x8000 -e _start kernel.o isr.o ckernel.o video.o gdt.o idt.o isrs.o irq.o util.o math.o timer.o keyboard.o -o ckernel.exe
    objcopy --strip-all --output-target binary ckernel.exe ckernel.bin
    cmd /c copy /b boot.bin + ckernel.bin MyOS    
   
    cmd /c del MyOS.bin
    cmd /c rename MyOS MyOS.bin
    cmd /c erase ..\MyOS.bin
    cmd /c copy MyOS.bin ..\MyOS.bin

Das einzige Programm, das nicht Teil von DJGPP und mingw ist, ist dd. Ich weiss nicht, wie man unter WinXP eine fest definierte Anzahl von Bytes aus einer Datei in eine andere kopieren kann, also habe ich dd benutzt, was ja von *nix stammt. Wie dem auch sei, so scheint zu gehen, ohne nasm...
Ein Nachteil bezüglich mingw ist noch, dass AntiVir bei von mingw as erzeugten Dateien meckert, sind angeblich irgendwelche Trojanische Pferde :D

Erhard Henkes schrieb:

Was abc.w anspricht ist mein Hin- und Herhüpfen zwischen C-Code (vor allem zum Thema Interrupts) und isr.asm.

Genauer meine ich, dass der gcc spezifische inline-Code in den c-Dateien nicht schön ist, weil, nun, sehr gcc spezifisch...
Nobuo T
Moderator

Benutzerprofil
Anmeldungsdatum: 09.10.2001
Beiträge: 4762
Beitrag Nobuo T Moderator 19:23:48 05.04.2009   Titel:              Zitieren

Kann GAS nicht inzwischen auch Intel-Syntax? Das wuerde die Sache sicher vereinfachen.

_________________
==Mod im Assembler-Forum==

http://z0r.de/2908
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 19:36:54 05.04.2009   Titel:              Zitieren

Erhard Henkes schrieb:
Ja, gute Idee, habe es umgesetzt. Thanks @ +fricky.

keine ursache. später aber, wenn du mal multitasking machen willst, kannste die funktion so nicht mehr verwenden. dann besser einen counter in den 'task control block' (der struct, die den zustand einer task kontrolliert) einbauen, und beim warten nicht einfach rechenzeit verbraten, sondern zur nächten task weiterschalten (plus einer möglichkeit, den 'wait' abbrechen zu können, z.b. von einer anderen task oder aus einem interrupt).
:)
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 19:38:56 05.04.2009   Titel:              Zitieren

Nobuo T schrieb:
Kann GAS nicht inzwischen auch Intel-Syntax? Das wuerde die Sache sicher vereinfachen.

echt, ne? diese bescheuerte at&t-syntax würde mich auch völlig nerven. welcher gehirnamputierte hat sich das bloss ausgedacht?
:)
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 19:44:37 05.04.2009   Titel:              Zitieren

Zitat:
boot.asm, kernel.asm und isr.asm nach AT&T umgesetzt

Würdest Du mir diese Files bitte schicken oder - noch besser - hier posten? Damit ich die AT&T Syntax endlich besser lerne, denn isr.asm könnte man vielleicht auch weitgehend oder völlig in den C-Modulen aufgehen lassen, falls das bezüglich Ordnung mehr Sinn macht. Für mich ist z.B. die Intel Syntax eindeutig besser lesbar.

Das sieht doch irgendwie unnötig kompliziert aus:
C++:
static void idt_load(){ asm volatile("lidt %0" : "=m" (idt_register)); } // load IDT register (IDTR)


Zitat:
Das einzige Programm, das nicht Teil von DJGPP und mingw ist, ist dd. Ich weiss nicht, wie man unter WinXP eine fest definierte Anzahl von Bytes aus einer Datei in eine andere kopieren kann.

Nicht-Linux-User kennen dd nicht, verwenden partcopy (das ist, was Du anstelle dd suchst) oder rawwrite.

Ich bin da aber flexibel, nur möchte ich alles auf MS Windows ermöglichen, was ja bisher keinerlei Problem ist.

Ich möchte auch den Hinweis auf gvim (am Anfang fand ich das nicht uninteressant , weil OSDEV bezüglich des Flairs eher archaische Instrumente benötigt. :D ) verwerfen, weil notepad++ besser aussieht und weniger störrisch ist. Seht ihr das ähnlich? :confused:

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 19:51:58 05.04.2009, insgesamt 2-mal bearbeitet
Nobuo T
Moderator

Benutzerprofil
Anmeldungsdatum: 09.10.2001
Beiträge: 4762
Beitrag Nobuo T Moderator 19:52:13 05.04.2009   Titel:              Zitieren

+fricky schrieb:
Nobuo T schrieb:
Kann GAS nicht inzwischen auch Intel-Syntax? Das wuerde die Sache sicher vereinfachen.

echt, ne? diese bescheuerte at&t-syntax würde mich auch völlig nerven. welcher gehirnamputierte hat sich das bloss ausgedacht?
:)

Total! :D :live:
Wahrscheinlich irgendein weltfremder, idealistischer, langhaariger Linux-Frickler mit Strick-Polunder und Taxischein. :cool:


Erhard Henkes schrieb:
Ich möchte auch den Hinweis auf gvim (am Anfang fand ich das nicht uninteressant , weil OSDEV bezüglich des Flairs eher archaische Instrumente benötigt. :D ) verwerfen, weil notepad++ besser aussieht und weniger störrisch ist. Seht ihr das ähnlich? :confused:

Wie ich das sehe, kann man sich vielleicht denken. :)

_________________
==Mod im Assembler-Forum==

http://z0r.de/2908


Zuletzt bearbeitet von Nobuo T am 19:55:55 05.04.2009, insgesamt 1-mal bearbeitet
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 19:54:59 05.04.2009   Titel:              Zitieren

Erhard Henkes schrieb:

Ich möchte auch den Hinweis auf gvim (am Anfang fand ich das nicht uninteressant , weil OSDEV bezüglich des Flairs eher archaische Instrumente benötigt. :D ) verwerfen, weil notepad++ besser aussieht und weniger störrisch ist. Seht ihr das ähnlich?

klar, wenn man assembler-code auf tiefster low-level ebene schreibt, muss man noch lange keine prähistorischen tools verwenden.
:)
abc.w
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2008
Beiträge: 1366
Beitrag abc.w Mitglied 20:10:32 05.04.2009   Titel:              Zitieren

Bezüglich der Assembler-Dateien in AT&T, die Kommentare sind alle unverändert. boot.s (hier habe ich, glaube, nur die Anzahl der Sektoren auf 40 geändert):
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
.global _start
.section .text
.code16
 
.equ kernel_start, _start + 1024
 
##################################
# setup a stack and segment regs #
##################################
 
_start:
    xorw %ax, %ax
    movw %ax, %ds
    movw %ax, %es
    movw %ax, %ss
    movw %ax, %sp
 
################################
# read kernel from floppy disk #
################################
 
    movb %dl, bootdrive # boot drive stored by BIOS in DL.
                        # we save it to [bootdrive] to play for safety.
 
load_kernel:
    xorw %ax, %ax       # mov ax, 0  => function "reset"
    int $0x13        
    jc load_kernel      # trouble? try again
 
    mov $0x8000, %bx    # set up start address of kernel
 
    # set parameters for reading function
    # 8-bit-wise for better overview
    movb bootdrive, %dl # select boot drive
    mov $40, %al        # read 40 sectors
    mov $0, %ch         # cylinder = 0
    mov $2, %cl         # sector   = 2
    mov $0, %dh         # head     = 0
    mov $2, %ah         # function "read"
    int $0x13        
    jc load_kernel      # trouble? try again
 
    # show loading message
    mov $loadmsg, %si
    call print_string
 
##################
# jump to kernel #
##################
 
    jmp kernel_start    # address of kernel. "jmp bx" might also work.
 
#######################
# call "print_string" #
#######################
 
print_string:
    mov $0x0E, %ah    # VGA BIOS fnct. 0x0E: teletype
1:  
    lodsb             # grab a byte from SI
    testb %al, %al    # NUL?
    jz 2f             # if the result is zero, get out
    int $0x10         # otherwise, print out the character!
    jmp 1b
2:
    ret
 
########
# data #
########
 
bootdrive: .byte 0    # boot drive
loadmsg: .asciz "bootloader message: loading kernel ...\n\r"
 
. = _start + 510
 
.byte 0x55
.byte 0xAA
 
.end


Die Datei kernel.s:
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
###############################################
# HenkesSoft 0.04 (version from Mar 26, 2009) #
###############################################
 
.global RealMode
.global _start
.section .text
.code16
 
#############
# Real Mode #
#############
 
_start:
RealMode:
    xorw %ax, %ax         # set up segments
    mov %ax, %es
    mov %ax, %ds
    mov %ax, %ss
    mov %ax, %sp
 
    mov $welcome, %si
    call print_string
 
    addw $-0x40, %sp    # make room for input buffer (64 chars)
   
loop_start:
    mov $prompt, %si    # show prompt
    call print_string
 
    mov %sp, %di        # get input
    call get_string
    jcxz loop_start   # blank line? -> yes, ignore it  
 
    mov %sp, %si
    mov $cmd_hi, %di    # "hi" command
    call strcmp
    je helloworld
 
    mov %sp, %si
    mov $cmd_help, %di  # "help" command
    call strcmp
    je help
 
    mov %sp, %si
    mov $cmd_questionmark, %di  # "?" command
    call strcmp
    je help
 
    mov %sp, %si
    mov $cmd_exit, %di  # "exit" command
    call strcmp
    je exit
 
    mov %sp, %si
    mov $cmd_pm, %di    # "pm (protected mode)" command
    call strcmp
    je pm
 
    mov $badcommand, %si # unknown command
    call print_string
    jmp loop_start
 
helloworld:
    mov $msg_helloworld, %si
    call print_string
    jmp loop_start
 
help:
    mov $msg_help, %si
    call print_string
    jmp loop_start
 
exit:
    mov $msg_exit, %si
    call print_string
    xorw %ax, %ax
    int $0x16          # Wait for keystroke
    jmp $0xffff, $0x0000 # Reboot
 
pm:
    call clrscr
    mov $msg_pm, %si
    call print_string
    call Waitingloop
 
    cli               # clear interrupts
 
    lgdt gdtr         # load GDT via GDTR
 
# we actually only need to do this ONCE, but for now it doesn't hurt to do this more often when
# switching between RM and PM
    inb $0x92, %al       # switch A20 gate via fast A20 port 92
    cmpb $0xFF, %al     # if it reads 0xFF, nothing's implemented on this port
    je 1f
   
    orb $2, %al         # set A20_Gate_Bit (bit 1)
    andb $0xFE, %al     # clear INIT_NOW bit (don't reset pc...)
    outb %al, $0x92
    jmp 2f
1:         # no fast shortcut -> use the slow kbc...
    call empty_8042  
   
    movb 0xD1, %al      # kbc command: write to output port
    outb %al, $0x64
    call empty_8042
   
    movb $0xDF, %al     # writing this to kbc output port enables A20
    outb %al, $0x60
    call empty_8042
2:
    mov %cr0, %eax      # switch-over to Protected Mode
    orl $1, %eax        # set bit 0 of CR0 register
    movl %eax, %cr0
 
jump_to_protected_mode:
    ljmp $8, $ProtectedMode
 
#########
# Calls #
#########
 
empty_8042:
    call Waitingloop
    inb $0x64, %al
    cmpb $0xFF, %al     # ... no real kbc at all?
    je 1f
   
    testb $1, %al       # something in input buffer?
    jz 2f
    call Waitingloop
    inb $0x60, %al       # yes: read buffer
    jmp empty_8042      # and try again
2:
    testb $2, %al       # command buffer empty?
    jnz empty_8042      # no: we can't send anything new till it's empty
1:
    ret
 
print_string:
    movb $0x0E, %ah
1:
    lodsb               # grab a byte from SI
    testb %al, %al      # test AL
    jz 2f               # if the result is zero, get out
    int $0x10           # otherwise, print out the character!
    jmp 1b
2:
    ret
 
get_string:
    xorw %cx, %cx
1:
    xorw %ax, %ax
    int $0x16           # wait for keypress
    cmpb $8, %al        # backspace pressed?
    je 2f               # yes, handle it
    cmpb $13, %al       # enter pressed?
    je 3f               # yes, we're done
    cmpb $63, %cl       # 63 chars inputted?
    je 1b               # yes, only let in backspace and enter
    movb $0x0E, %ah
    int $0x10           # print out character
    stosb               # put character in buffer
    inc %cx
    jmp 1b
 
2:
    jcxz 1b             # zero? (start of the string) if yes, ignore the key
    dec %di
    movb $0, (%di)      # delete character
    dec %cx             # decrement counter as well
    movb $0x0E, %ah
    int $0x10           # backspace on the screen
    movb $32, %al
    int $0x10           # blank character out
    movb $8, %al
    int $0x10           # backspace again
    jmp 1b              # go to the main loop
 
3:
    movb $0, (%di)      # null terminator
    movw $0x0E0D, %ax
    int $0x10
    movb $0x0A, %al
    int $0x10           # newline
    ret
 
strcmp:
1:
    movb (%si), %al       # grab a byte from SI
    cmpb (%di), %al       # are SI and DI equal?
    jne 2f          # no, we're done.
 
    testb %al, %al        # zero?
    jz 2f           # yes, we're done.
 
    inc %di             # increment DI
    inc %si             # increment SI
    jmp 1b             # loop!
 
2:  
    ret
 
clrscr:
    movw $0x0600, %ax
    xorw %cx, %cx
    mov $0x174F, %dx
    mov $0x07, %bh
    int $0x10
    ret
 
##################
# Protected Mode #
##################
 
.section .text
.code32
 
.p2align 4
 
ProtectedMode:
    movw $0x10, %ax
    mov %ax, %ds      # data descriptor --> data, stack and extra segment
    mov %ax, %ss
    mov %ax, %es
    xorl %eax, %eax    # null desriptor --> FS and GS
    mov %ax, %fs
    mov %ax, %gs
    mov $0x200000, %esp # set stack below 2 MB limit
 
    call clrscr_32
    movb $0x01, %ah
1:
    call Waitingloop
    incb %ah
    andb $0x0F, %ah
    mov $msg_pm2, %esi   # 'OS currently uses Protected Mode.'
    call PutStr_32
    cmpl $(25 * 80 * 2 + 0xB8000), PutStr_Ptr
    jb 1b
    movl $0xB8000, PutStr_Ptr   # text pointer wrap-arround
 
  call _kernel_main # ->-> C-Kernel
  jmp .
   
 
 
Waitingloop:                  
    mov $0x9FFFF, %ebx
1:
    dec %ebx    
    jnz 1b
    ret        
 
PutStr_32:    
    movl PutStr_Ptr, %edi
1:
    lodsb
    testb %al, %al
    jz 2f
    stosw
    jmp 1b
2:
    movl %edi, PutStr_Ptr
    ret
 
clrscr_32:
    movl $0xb8000, %edi
    movl %edi, PutStr_Ptr
    movl $1000, %ecx
    movl $0x07200720, %eax
    rep stosl
    ret
 
PutStr_Ptr: .long 0xb8000
   
# You load the address you want to output to in [PutStr_Ptr],
# the address of the string (has to be NUL terminated)
# you want to print in esi and the attributes in ah
# lodsb loads one byte from esi into al, then increments esi,
# then it checks for a NUL terminator,
# then it moves the char into the write position in video memory,
# then increments edi and writes the attributes,
# loops until it finds NUL pointer at which point it breaks ...
 
###########
# Strings #
###########
 
welcome: .asciz "HenkesSoft 0.05 (test version from Apr 03, 2009)\n\r"
msg_helloworld: .asciz "Hello World!\n\r"
badcommand: .asciz "Command unknown.\n\r"
prompt: .asciz ">"
cmd_hi: .asciz "hi"
cmd_help: .asciz "help"
cmd_questionmark: .asciz "?"
cmd_exit: .asciz "exit"
cmd_pm: .asciz "pm"
msg_help: .asciz "Commands: hi, help, ?, pm, exit\n\r"
msg_exit: .asciz "Reboot starts now. Enter keystroke, please.\n\r"
msg_pm: .asciz "Switch-over to Protected Mode.\n\r"
msg_pm2: .asciz "OS currently uses Protected Mode.  "
 
############
# Includes #
############
 
###################################
## Global Descriptor Table (GDT) ##
###################################
 
NULL_Desc:
.long 0
.long 0
   
CODE_Desc:
.word 0xFFFF    # segment length  bits 0-15 ("limit")    
.word 0         # segment base    byte 0,1      
.byte 0         # segment base    byte 2    
.byte 0b10011010    # access rights
.byte 0b11001111    # bit 7-4: 4 flag bits:  granularity, default operation size bit, 2 bits available for OS
                    # bit 3-0: segment length bits 16-19
.byte 0             # segment base    byte 3    
 
DATA_Desc:
.word 0xFFFF        # segment length  bits 0-15
.word 0             # segment base    byte 0,1
.byte 0             # segment base    byte 2
.byte 0b10010010    # access rights
.byte 0b11001111    # bit 7-4: 4 flag bits:  granularity, big bit (0=USE16-Segm., 1=USE32-Segm.), 2 bits avail.
                    # bit 3-0: segment length bits 16-19
.byte 0             # segment base    byte 3      
 
gdtr:
Limit: .word 24     # length of GDT
Base: .long NULL_Desc    # base of GDT ( linear address: RM Offset + Seg<<4 )


Die Datei isr.s:
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
# Interrupt Service Routine isr0 ... isr32  
.global _isr0
.global _isr1
.global _isr2
.global _isr3
.global _isr4
.global _isr5
.global _isr6
.global _isr7
.global _isr8
.global _isr9
.global _isr10
.global _isr11
.global _isr12
.global _isr13
.global _isr14
.global _isr15
.global _isr16
.global _isr17
.global _isr18
.global _isr19
.global _isr20
.global _isr21
.global _isr22
.global _isr23
.global _isr24
.global _isr25
.global _isr26
.global _isr27
.global _isr28
.global _isr29
.global _isr30
.global _isr31
 
.global _irq0
.global _irq1
.global _irq2
.global _irq3
.global _irq4
.global _irq5
.global _irq6
.global _irq7
.global _irq8
.global _irq9
.global _irq10
.global _irq11
.global _irq12
.global _irq13
.global _irq14
.global _irq15
 
.section .text
 
#  0: Divide By Zero Exception
_isr0:
    cli
    pushl $0
    pushl $0
    jmp isr_common_stub
 
#  1: Debug Exception
_isr1:
    cli
    pushl $0
    pushl $1
    jmp isr_common_stub
 
#  2: Non Maskable Interrupt Exception
_isr2:
    cli
    pushl $0
    pushl $2
    jmp isr_common_stub
 
#  3: Int 3 Exception
_isr3:
    cli
    pushl $0
    pushl $3
    jmp isr_common_stub
 
#  4: INTO Exception
_isr4:
    cli
    pushl $0
    pushl $4
    jmp isr_common_stub
 
#  5: Out of Bounds Exception
_isr5:
    cli
    pushl $0
    pushl $5
    jmp isr_common_stub
 
#  6: Invalid Opcode Exception
_isr6:
    cli
    pushl $0
    pushl $6
    jmp isr_common_stub
 
#  7: Coprocessor Not Available Exception
_isr7:
    cli
    pushl $0
    pushl $7
    jmp isr_common_stub
 
#  8: Double Fault Exception (With Error Code!)
_isr8:
    cli
    pushl $8
    jmp isr_common_stub
 
#  9: Coprocessor Segment Overrun Exception
_isr9:
    cli
    pushl $0
    pushl $9
    jmp isr_common_stub
 
# 10: Bad TSS Exception (With Error Code!)
_isr10:
    cli
    pushl $10
    jmp isr_common_stub
 
# 11: Segment Not Present Exception (With Error Code!)
_isr11:
    cli
    pushl $11
    jmp isr_common_stub
 
# 12: Stack Fault Exception (With Error Code!)
_isr12:
    cli
    pushl $12
    jmp isr_common_stub
 
# 13: General Protection Fault Exception (With Error Code!)
_isr13:
    cli
    pushl $13
    jmp isr_common_stub
 
# 14: Page Fault Exception (With Error Code!)
_isr14:
    cli
    pushl $14
    jmp isr_common_stub
 
# 15: Reserved Exception
_isr15:
    cli
    pushl $0
    pushl $15
    jmp isr_common_stub
 
# 16: Floating Point Exception
_isr16:
    cli
    pushl $0
    pushl $16
    jmp isr_common_stub
 
# 17: Alignment Check Exception
_isr17:
    cli
    pushl $0
    pushl $17
    jmp isr_common_stub
 
# 18: Machine Check Exception
_isr18:
    cli
    pushl $0
    pushl $18
    jmp isr_common_stub
 
# 19: Reserved
_isr19:
    cli
    pushl $0
    pushl $19
    jmp isr_common_stub
 
# 20: Reserved
_isr20:
    cli
    pushl $0
    pushl $20
    jmp isr_common_stub
 
# 21: Reserved
_isr21:
    cli
    pushl $0
    pushl $21
    jmp isr_common_stub
 
# 22: Reserved
_isr22:
    cli
    pushl $0
    pushl $22
    jmp isr_common_stub
 
# 23: Reserved
_isr23:
    cli
    pushl $0
    pushl $23
    jmp isr_common_stub
 
# 24: Reserved
_isr24:
    cli
    pushl $0
    pushl $24
    jmp isr_common_stub
 
# 25: Reserved
_isr25:
    cli
    pushl $0
    pushl $25
    jmp isr_common_stub
 
# 26: Reserved
_isr26:
    cli
    pushl $0
    pushl $26
    jmp isr_common_stub
 
# 27: Reserved
_isr27:
    cli
    pushl $0
    pushl $27
    jmp isr_common_stub
 
# 28: Reserved
_isr28:
    cli
    pushl $0
    pushl $28
    jmp isr_common_stub
 
# 29: Reserved
_isr29:
    cli
    pushl $0
    pushl $29
    jmp isr_common_stub
 
# 30: Reserved
_isr30:
    cli
    pushl $0
    pushl $30
    jmp isr_common_stub
 
# 31: Reserved
_isr31:
    cli
    pushl $0
    pushl $31
    jmp isr_common_stub
 
 
# Common ISR stub saves processor state, sets up for kernel mode segments, calls the C-level fault handler,
# and finally restores the stack frame.
isr_common_stub:
    pusha
    push %ds
    push %es
    push %fs
    push %gs
    mov $0x10, %ax
    mov %ax, %ds
    mov %ax, %es
    mov %ax, %fs
    mov %ax, %gs
    mov %esp, %eax
    push %eax
    mov $_fault_handler, %eax
    call *%eax
    pop %eax
    pop %gs
    pop %fs
    pop %es
    pop %ds
    popa
    add $8, %esp
    iret
 
# 32: IRQ0
_irq0:
    cli
    pushl $0
    pushl $32
    jmp irq_common_stub
 
# 33: IRQ1
_irq1:
    cli
    pushl $0
    pushl $33
    jmp irq_common_stub
 
# 34: IRQ2
_irq2:
    cli
    pushl $0
    pushl $34
    jmp irq_common_stub
 
# 35: IRQ3
_irq3:
    cli
    pushl $0
    pushl $35
    jmp irq_common_stub
 
# 36: IRQ4
_irq4:
    cli
    pushl $0
    pushl $36
    jmp irq_common_stub
 
# 37: IRQ5
_irq5:
    cli
    pushl $0
    pushl $37
    jmp irq_common_stub
 
# 38: IRQ6
_irq6:
    cli
    pushl $0
    pushl $38
    jmp irq_common_stub
 
# 39: IRQ7
_irq7:
    cli
    pushl $0
    pushl $39
    jmp irq_common_stub
 
# 40: IRQ8
_irq8:
    cli
    pushl $0
    pushl $40
    jmp irq_common_stub
 
# 41: IRQ9
_irq9:
    cli
    pushl $0
    pushl $41
    jmp irq_common_stub
 
# 42: IRQ10
_irq10:
    cli
    pushl $0
    pushl $42
    jmp irq_common_stub
 
# 43: IRQ11
_irq11:
    cli
    pushl $0
    pushl $43
    jmp irq_common_stub
 
# 44: IRQ12
_irq12:
    cli
    pushl $0
    pushl $44
    jmp irq_common_stub
 
# 45: IRQ13
_irq13:
    cli
    pushl $0
    pushl $45
    jmp irq_common_stub
 
# 46: IRQ14
_irq14:
    cli
    pushl $0
    pushl $46
    jmp irq_common_stub
 
# 47: IRQ15
_irq15:
    cli
    pushl $0
    pushl $47
    jmp irq_common_stub
 
irq_common_stub:
    pusha
    push %ds
    push %es
    push %fs
    push %gs
 
    mov $0x10, %ax
    mov %ax, %ds
    mov %ax, %es
    mov %ax, %fs
    mov %ax, %gs
    mov %esp, %eax
 
    push %eax
    mov $_irq_handler, %eax
    call *%eax
    pop %eax
 
    pop %gs
    pop %fs
    pop %es
    pop %ds
    popa
    add $8, %esp
    iret


Nicht zu lange draufgucken, schadet den Augen :D


Zuletzt bearbeitet von abc.w am 22:36:54 05.04.2009, insgesamt 1-mal bearbeitet
abc.w
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2008
Beiträge: 1366
Beitrag abc.w Mitglied 20:34:27 05.04.2009   Titel:              Zitieren

Erhard Henkes schrieb:
Zitat:
Das einzige Programm, das nicht Teil von DJGPP und mingw ist, ist dd. Ich weiss nicht, wie man unter WinXP eine fest definierte Anzahl von Bytes aus einer Datei in eine andere kopieren kann.

Nicht-Linux-User kennen dd nicht, verwenden partcopy (das ist, was Du anstelle dd suchst) oder rawwrite.
Ich bin da aber flexibel, nur möchte ich alles auf MS Windows ermöglichen, was ja bisher keinerlei Problem ist.

Ich habe grade geguckt, woher ich dd auf meinem System habe... aus dem Verzeichnis C:\Compiler\WinAVR-20081205\utils\bin. Nicht schön. Benutze ein Programm und weiss überhaupt nicht, woher ich es habe. Das kommt davon, wenn man die PATH Variable einfach mal so modifiziert...

Erhard Henkes schrieb:
Ich möchte auch den Hinweis auf gvim (am Anfang fand ich das nicht uninteressant , weil OSDEV bezüglich des Flairs eher archaische Instrumente benötigt. :D ) verwerfen, weil notepad++ besser aussieht und weniger störrisch ist. Seht ihr das ähnlich? :confused:

Ich benutze in letzter Zeit ausschliesslich gvim... :)
abc.w
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2008
Beiträge: 1366
Beitrag abc.w Mitglied 20:55:45 05.04.2009   Titel:              Zitieren

Nobuo T schrieb:
+fricky schrieb:
Nobuo T schrieb:
Kann GAS nicht inzwischen auch Intel-Syntax? Das wuerde die Sache sicher vereinfachen.

echt, ne? diese bescheuerte at&t-syntax würde mich auch völlig nerven. welcher gehirnamputierte hat sich das bloss ausgedacht?
:)

Total! :D :live:
Wahrscheinlich irgendein weltfremder, idealistischer, langhaariger Linux-Frickler mit Strick-Polunder und Taxischein. :cool:

Ich glaube, AT&T Syntax ist älter als Linux und Intel und GNU zusammen. Ich sehe es so, dass allein aus der Tatsache, dass diese Syntax noch nicht "ausgestorben" ist und eine so lange Periode überdauert hat, muss etwas dahinter stecken. Ich hatte mich am Anfang auch wegen % und $ unbehaglich gefühlt, aber jetzt, sooo schlimm ist das nicht und die Syntax finde ich durchdachter und konsequenter in jeder Hinsicht als jede andere. Wenn wir hier in diesem Thread zurückschauen, wieviele Probleme gab es mit jmp und wieviel Ungewissheit, zumindest bei mir, ob jmp word oder jmp dword, nur weil nasm sowohl das eine als auch das andere erlaubt...
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 22:08:55 05.04.2009   Titel:              Zitieren

@abc.w: Danke für die Übersetzung von Intel nach AT&T und für das DJGPP / mingw makefile. Es sollte nicht von zu vielen Kleinigkeiten und/oder Geschmacksachen abhängen, ob jemand den Zugang zu OSDEV findet. :)

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 22:29:50 05.04.2009   Titel:              Zitieren

Nun können System Clock und Keyboard unabhängig den Bildschirm beschmutzen. Die vielen Polling-Endlosschleifen wurden nun gebrochen. Bisher habe ich die Vorschläge von Nobuo T noch nicht eingebaut, sehe aber auch (noch!) keinen Nachteil.

..

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 10:46:37 05.10.2013, insgesamt 2-mal bearbeitet
abc.w
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2008
Beiträge: 1366
Beitrag abc.w Mitglied 22:34:38 05.04.2009   Titel:              Zitieren

Erhard Henkes schrieb:
@abc.w: Danke für die Übersetzung von Intel nach AT&T und für das DJGPP / mingw makefile. Es sollte nicht von zu vielen Kleinigkeiten und/oder Geschmacksachen abhängen, ob jemand den Zugang zu OSDEV findet. :)

Bitte, aber ich glaube, ich habe da noch den einen oder anderen Fehler eingebaut und es wundert mich, dass es funktioniert:
Code:
1
2
3
4
5
6
7
8
9
10
print_string:
    movb $0x0E, %ah
1:
    lodsb               # grab a byte from SI
    testb %al, %al      # test AL
    jz 2b               # if the result is zero, get out
    int $0x10           # otherwise, print out the character!
    jmp 1b
2:
    ret

Die Zeile jz 2b soll natürlich nicht 2 back sonder 2 forward heissen...
Code:
1
2
3
4
5
6
7
8
9
10
print_string:
    movb $0x0E, %ah
1:
    lodsb               # grab a byte from SI
    testb %al, %al      # test AL
    jz 2f               # if the result is zero, get out
    int $0x10           # otherwise, print out the character!
    jmp 1b
2:
    ret

Entschuldigung... werde es oben gleich korrigieren...
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 22:50:03 05.04.2009   Titel:              Zitieren

Ich denke das nächste, was nun notwendig wird, ist eine vollständige Datei video.c - da gibt es ja nicht viel zu erklären - mit verbesserten Darstellungsmöglichkeiten, denn im jetzigen Zustand kann man das Programm nicht auf die Menschheit los lassen. In keyboard.c fehlt eigentlich auch noch die Abfrage auf weitere Kombinationen mit Sondertasten neben Shift, aber ich bin erstmal froh, dass es nun generell läuft. Mit dem Keyboard Handling stehe ich echt auf Kriegsfuß. :rolleyes:

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 22:51:15 05.04.2009, insgesamt 1-mal bearbeitet
Nobuo T
Moderator

Benutzerprofil
Anmeldungsdatum: 09.10.2001
Beiträge: 4762
Beitrag Nobuo T Moderator 23:31:35 05.04.2009   Titel:              Zitieren

Naja, so ganz sinnvoll sieht mir deine fetchandsigsbums-Funktion noch nicht aus... Meine Vorschlaege (eigentlich waere das ja nur noch eine Sache?) noch nicht drin, dafuer die grosse Endlosschleife noch immer. :p
Mehr als einen Durchgang solltest du in dieser Funktion einfach nicht machen. Auch fuer erweiterte Codes, die aus mehreren Scancodes bestehen, wird jedes Mal ein IRQ ausgeloest.
Mal morgen nochmal drueber schauen...

video.c ... Mein Vorschlag waere erstmal globale Variablen fuer die character attributes und die aktuelle Bildschirmposition, etc. festzulegen. Evtl. sogar in der BDA im entsprechenden Format, wie es das VGA-BIOS tut.
Dann erstmal grundlegende Funktionen zum Positionieren des Cursors, Ausgabe von chars und Strings, setzen der attributes, etc. implementieren.
Darauf kannst du dann vielleicht eine abgespeckte Version von printf aufbauen, die zumindest mit 0-terminierten Strings vernuenftig arbeiten kann und evtl. auch sowas wie %x, %d, %c und %s unterstuetzt.

_________________
==Mod im Assembler-Forum==

http://z0r.de/2908


Zuletzt bearbeitet von Nobuo T am 23:32:38 05.04.2009, insgesamt 1-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 23:38:21 05.04.2009   Titel:              Zitieren

Eine Design-Frage: Wie geht man mit den "Handlern" bezüglich IRQ am besten um?
Der nachstehende keyboard_handler(...) holt ein Zeichen in einen lokalen Puffer.
Wie geht man mit all diesen Informationen egal ob Tick-Info oder ein Zeichen von der Tastatur schnittstellenmäßig am besten um? Hier die zwei bisherigen Beispiele für IRQ0 und IRQ1:

C++:
void timer_handler(struct regs* r)
{
    ++timer_ticks;
    if (eticks)
        --eticks;
}


C++:
1
2
3
4
5
6
7
8
void keyboard_handler(struct regs* r)
{
   // k_printf("keyboard handler works!", 8, 0x2);
 
   unsigned char bufferKEY[10];
   bufferKEY[0] = k_getch();
   k_printf(bufferKEY, 10,0xA); // the ASCII character
}

Die Ergebnisse sind in einem Fall timer_ticks und eticks, im anderen Fall bufferKEY[0]. Was macht man damit sinnvollerweise, um überall damit umgehen zu können? Gibt es diesbezüglich eine allgemeine Theorie?

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 23:52:30 05.04.2009   Titel:              Zitieren

Zitat:
video.c ... Mein Vorschlag waere erstmal globale Variablen fuer die character attributes und die aktuelle Bildschirmposition, etc. festzulegen. Evtl. sogar in der BDA im entsprechenden Format, wie es das VGA-BIOS tut.
Dann erstmal grundlegende Funktionen zum Positionieren des Cursors, Ausgabe von chars und Strings, setzen der attributes, etc. implementieren.
Darauf kannst du dann vielleicht eine abgespeckte Version von printf aufbauen, die zumindest mit 0-terminierten Strings vernuenftig arbeiten kann und evtl. auch sowas wie %x, %d, %c und %s unterstuetzt.

Genau so habe ich mir das auch vorgestellt, ist ja auch das übliche Verfahren bei x*y Textausgabe. Das bisherige k_printf(...) war nur eine Quick&Dirty-Notlösung, um rasch vorwärts zu gelangen.

Zitat:
dafuer die grosse Endlosschleife noch immer.

Das ist ja keine "echte" Endlosschleife, da ich dort mit continue oder break in die jeweils richtige Richtung ein-/aussteigen kann. Habe bisher noch keine perfekte Lösung für die passende Kontrollstruktur gefunden, weil man die while-Schleife verschieden durchlaufen muss. Ich hatte erst while (loopflag) geschrieben und das flag entsprechend gesetzt, dann aber festgestellt, dass man das auch durch ein einfaches break und Tschüss ersetzen kann.

Zitat:
Meine Vorschlaege (eigentlich waere das ja nur noch eine Sache?) noch nicht drin
Ich denke noch darüber nach, habe aber bisher keinen Nachteil im bisherigen Ablauf erkannt, ist aber auch alles noch zu chaotisch auf dem Bildschirm. Ab und zu tauchen da merkwürdige Zeichen an unerwarteten Stellen auf. :D

Auf jeden Fall vielen Dank an alle, die mich hier unterstützen! :live:
Dieses Tutorial ist ein lang gehegter Wunsch. Bisher hatte ich mich aber nicht an die Materie heran gewagt, bin ja kein Informatiker, sondern Autodidakt. Nun bin ich aber bereits soweit eingedrungen in das Thema, dass es kein Zurück mehr gibt, nur noch vorwärts. ;) :D

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 02:01:24 06.04.2009, insgesamt 2-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 00:58:36 06.04.2009   Titel:              Zitieren

@Nobuo T:
Noch zu den Themen: Port 0x61 Bit7, EOI und IF

..


http://wiki.osdev.org/PS2_Keyboard

Nobuo T:
Zitat:
Kurz aus- und wieder einschalten ueber Port 61h, Bit7.


Ich gehe davon aus, dass für das MSB 0->1 u. 1->0 der korrekte Weg ist.

Wann muss man dieses ACK(nowledgement) abgeben?

..

Ich sehe allerdings noch keinen Effekt mit/ohne ACK? :confused:
Es heisst ja auch: "without waiting for another IRQ".
Wir reagieren doch jetzt immer auf einen IRQ1. Also brauchen wir das nun nicht?
Wir hätten es wohl eher beim Polling benötigt??? Da ist es mir aber nicht negativ aufgefallen.

Das EOI wird in irq.c gesendet.

..

Da war doch noch die Rede von einem IF? Ist dies das IF bei der CPU im Flag-Register?
http://de.wikipedia.org/w ....... ter#Interrupt-Enable-Flag

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 10:49:48 05.10.2013, insgesamt 12-mal bearbeitet
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 09:52:43 06.04.2009   Titel:              Zitieren

Erhard Henkes schrieb:
Eine Design-Frage: Wie geht man mit den "Handlern" bezüglich IRQ am besten um?
Der nachstehende keyboard_handler(...) holt ein Zeichen in einen lokalen Puffer.
Wie geht man mit all diesen Informationen egal ob Tick-Info oder ein Zeichen von der Tastatur schnittstellenmäßig am besten um? Hier die zwei bisherigen Beispiele für IRQ0 und IRQ1:

C++:
void timer_handler(struct regs* r)
{
    ++timer_ticks;
    if (eticks)
        --eticks;
}


C++:
1
2
3
4
5
6
7
8
void keyboard_handler(struct regs* r)
{
   // k_printf("keyboard handler works!", 8, 0x2);
 
   unsigned char bufferKEY[10];
   bufferKEY[0] = k_getch();
   k_printf(bufferKEY, 10,0xA); // the ASCII character
}

Die Ergebnisse sind in einem Fall timer_ticks und eticks, im anderen Fall bufferKEY[0]. Was macht man damit sinnvollerweise, um überall damit umgehen zu können? Gibt es diesbezüglich eine allgemeine Theorie?

oft wird sowas objektorientiert gemacht (betriebssysteme schreien förmlich nach einem objektorientiertes design). für frei laufende countdown-timer machste dir z.b. ein paar funktionen:
Code:
1
2
3
4
5
6
7
8
9
10
11
// erzeugt einen neuen timer und meldet ihn beim OS an. gibt 0 zurück, wenn kein timer alloziert werden konnte
timer_t *timer_create(void);
 
// startet den timer, der ab jetzt vom OS von 'timeout' bis 0 runtergezählt wird
void timer_start (timer_t *timer, unsigned long timeout);
 
// prüft ob der timer abgelaufen ist, gibt 0 zurück, wenn der timer noch läuft, sonst 1
int timer_expired (timer *t);
 
// beseitigt den timer (trägt ihn z.b. aus der liste des OS aus und gibt seinen speicher frei)
void timer_free (timer_t *timer);

^^die hardware-isr schaut bei jedem tick in eine verkettete liste, ob timer drin sind, die sie runterzählen muss.

zu den I/O-daten: am besten du benutzt FIFO-buffer für sowas. die ISR (z.b. von der tastatur) trägt empfangene daten in den FIFO ein und die anwendung holt sie sich raus. ein tastatur-FIFO kann recht klein sein und darf ältere daten überschreiben, weil uralte tastendrücke ja nicht mehr interessieren. ein benutzer-prozess kann dann einfach zeichen aus dem FIFO holen, z.b. so:
Code:
// hole ein zeichen aus dem tastatur-buffer. wenn c -1 (oder EOF) ist, war der FIFO leer
int c = getchar();

:)
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 11:04:03 06.04.2009   Titel:              Zitieren

@+fricky: Danke für die Ratschläge, kommt in die Planungs-/TODO-Liste. :live: Momentan fehlt dem OS noch ein solches C-Modul mit Strukturen wie Stack (LIFO), Pipe/Queue/Cache (FIFO), verketteter Liste usw. In C++ wäre dies wirklich leichter zu realisieren, muss mal in meinen alten C-Büchern schmökern. :rolleyes:

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 11:11:19 06.04.2009, insgesamt 1-mal bearbeitet
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 11:36:32 06.04.2009   Titel:              Zitieren

Erhard Henkes schrieb:

Momentan fehlt dem OS noch ein solches C-Modul mit Strukturen wie Stack (LIFO), Pipe/Queue/Cache (FIFO), verketteter Liste usw.

hier hast schon mal was für listen: http://www.c-plusplus.de/ ....... 60978-and-start-is-5.html

Erhard Henkes schrieb:

In C++ wäre dies wirklich leichter zu realisieren...

auf den ersten blick vielleicht, aber letztlich würdest du dich mehr mit c++'s hausgemachten problemen, als mit deinem OS auseinandersetzen. mach den kernel besser in C, c++ (und beliebige andere sprachen) kannst du ja dann für usermode-anwendungnen nehmen.
:)
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 12:19:33 06.04.2009   Titel:              Zitieren

Danke für den Link, habe aber meine alten C-Bücher bereits von der zweiten in die erste Reihe gerückt: Kernighan/Ritchie, Willms, Schröder. Zum Glück habe ich die nicht bereits verschenkt. ;)
Zitat:
c++ (und beliebige andere sprachen) kannst du ja dann für usermode-anwendungnen nehmen.
Ja, so wird's gemacht. :live: Hoffentlich erlebt mein PrettyOS diesen Zeitpunkt noch und bleibt nicht bei 0.42 o.ä. wegen explodierender Taskliste stecken wie so viele Entwürfe. :D

Zitat:
Immer im Hinterkopf behalten, dass das ein Internet-Tutorial und kein Kompendium zur OS-Entwicklung werden soll - das wird wie ich das sehe schon so eine ordentliche Portion Stoff. :D
Ich habe den bisherigen Text mal als pdf gedruckt, da waren es schon fast 100 Seiten, ist schon ein umfassendes Thema, und dabei sind wir noch in der Overtüre. :D

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 18:20:23 06.04.2009, insgesamt 1-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 18:46:31 06.04.2009   Titel:              Zitieren

@Nobuo T:
Zitat:
Evtl. sogar in der BDA im entsprechenden Format, wie es das VGA-BIOS tut.
Könntest Du diesen Punkt bitte genauer ausführen?

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
Nobuo T
Moderator

Benutzerprofil
Anmeldungsdatum: 09.10.2001
Beiträge: 4762
Beitrag Nobuo T Moderator 01:17:47 07.04.2009   Titel:              Zitieren

http://heim.ifi.uio.no/~stanisls/helppc/bios_data_area.html
ab offset 449h. Mir scheint diese Struktur eigentlich im Grossen und Ganzen recht praktisch.

Erhard Henkes schrieb:
Zitat:
dafuer die grosse Endlosschleife noch immer.

Das ist ja keine "echte" Endlosschleife, da ich dort mit continue oder break in die jeweils richtige Richtung ein-/aussteigen kann. Habe bisher noch keine perfekte Lösung für die passende Kontrollstruktur gefunden, weil man die while-Schleife verschieden durchlaufen muss. Ich hatte erst while (loopflag) geschrieben und das flag entsprechend gesetzt, dann aber festgestellt, dass man das auch durch ein einfaches break und Tschüss ersetzen kann.

Ok, mal anders gefragt:
Was fuer Faelle siehst du konkret, bei denen es noetig oder sinnvoll waere, in dieser Schleife mehrere Male hintereinander Scancodes von Port 60h zu lesen?
Ich sehe hoechstens 2, naemlich erweiterte 2-Byte codes (Pfeiltasten, etc.) oder andere, laengere Status codes, die du aber saemtlichst noch nicht beruecksichtigst.
Dagegen springst du so immer noch beim Druecken der Shift-Taste in eine Endlosschleife ohne Sinn und Wiederkehr.
Deshalb mein Tipp: Weg mit der Schleife. Versuche moeglichst pro IRQ nur einmal Port 60h auszulesen, das gelesene direkt zu verarbeiten und gleich wieder zurueckzukehren.
Dazu kannst du zB. in dieser Fetch-Funktion einen speziellen Rueckgabewert fuer Codes einfuehren, die sich nicht direkt in ASCII-Codes umsetzen lassen und zur Bearbeitung der Codes globale Variablen und Flags benutzen (zB. fuer shift, strg, alt down, usw. siehe auch meinen Link zur BDA oben als groben Denkansatz).


Erhard Henkes schrieb:
Zitat:

Kurz aus- und wieder einschalten ueber Port 61h, Bit7.


Ich gehe davon aus, dass für das MSB 0->1 u. 1->0 der korrekte Weg ist.

AFAIR: Ja.

Erhard Henkes schrieb:
Wann muss man dieses ACK(nowledgement) abgeben?

Wenn du das Gelesene nicht mehr brauchst. In dem KB-Treiber, den ich vor Jahren mal geschrieben habe, hatte das direkt vor dem EOI stehen.

Erhard Henkes schrieb:

Würde das so passen?
C++:
1
2
3
4
5
6
7
8
9
10
11
12
    unsigned int FetchAndAnalyzeScancode()
{
  unsigned int scancode; // For getting the keyboard scancode
  while(TRUE) // Loop until a key (w/o shift key) has been pressed
  {
    scancode = inportb(0x60);   // 0x60: get scan code from the keyboard
    // ACK: toggle bit 7 at port 0x61
    outportb(0x61,inportb(0x61) |  0x80); // 0->1
    outportb(0x61,inportb(0x61) &~ 0x80); // 1->0
 
    if ( scancode & 0x80 ) // Key released? ...
    { //...    


oder ist es so besser? (wie oben bei osdev.org)
C++:
     // ACK: toggle bit 7 at port 0x61
    unsigned char port_value = inportb(0x61);
    outportb(0x61,port_value |  0x80); // 0->1
    outportb(0x61,port_value &~ 0x80); // 1->0  


Die 2. Version ist eindeutig besser. Es schadet uebrigens sicher nicht, vor dem Lesen von Port 60h, den Port 64h, Bit 0 zu pruefen, wie du es urspruenglich auch gemacht hast (das meinte ich eigentlich gar nicht mit Endlosschleife, sondern deine aeussere while (true)-Schleife :D).
Vielleicht den Port 64h statt in einer while-Schleife in einer for-Schleife mit Zaehler als zusaetzliche Abbruchbedingung pruefen. Im Fehlerfall springst du dann halt sofort zurueck.


Erhard Henkes schrieb:

Ich sehe allerdings noch keinen Effekt mit/ohne ACK? :confused:
Es heisst ja auch: "without waiting for another IRQ".
Wir reagieren doch jetzt immer auf einen IRQ1. Also brauchen wir das nun nicht?
Wir hätten es wohl eher beim Polling benötigt??? Da ist es mir aber nicht negativ aufgefallen.

Theoretisch richtig, aber praktisch macht dieses x86-Gefrickel eben doch wieder alles anders. :D
Wenn du mit einer Runde Keyboard-Auslesen sicher fertig bist, kann es ganz bestimmt nicht verkehrt sein, mit diesem ACK sicher zu gehen.

Erhard Henkes schrieb:
Da war doch noch die Rede von einem IF? Ist dies das IF bei der CPU im Flag-Register?
[...]
isr.asm: dort findet sich bei jedem IRQ ein cli

Richtig. Und genau deshalb ist eine [laengere/endlose] Schleife in einem IRQ-Handler ziemlich fatal. Damit blockierst du das komplette System. Ein IRQ-Handler muss moeglichst schnell sein: Rein, Hardware auslesen, das absolut Wichtigste kurz aufbereiten und im RAM abladen, ACK und wieder raus.
Im Extremfall kannst du bei einem Micro-Kernel so weit gehen, dass du nur den Scancode in eine FIFO-queue im RAM schiebst und die Interpretation einem eigenen Treiber-Prozess ueberlaesst (wobei ich meine, dass man es nicht so uebertreiben braucht und sich der Keyboard-Input auch noch sehr gut weitgehend komplett im IRQ-Handler interpretieren/in ASCII-Codes umwandeln laesst).

_________________
==Mod im Assembler-Forum==

http://z0r.de/2908
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 17:34:44 07.04.2009   Titel:              Zitieren

@Nobuo T: Vielen Dank für diese umfassenden Ausführungen. Du hast mich überzeugt. :) Ich werde dies Schritt für Schritt umsetzen.

In utils.c habe ich auch noch eine Änderung bei k_i2hex (h und NUL anghängt). Nobuo T hat dankenswerterweise k_itoa weiter optimiert:
..

video.c sieht momentan wie folgt aus (noch ohne brauchbare printf(...), wie von Nobuo T vorgeschlagen):
..

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 10:51:40 05.10.2013, insgesamt 5-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 19:34:42 08.04.2009   Titel:              Zitieren

Leider noch nicht ganz perfekt, aber läuft prinzipiell schon wie es soll:
..

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 10:52:17 05.10.2013, insgesamt 2-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 20:04:43 08.04.2009   Titel:              Zitieren

Das ist - denke ich - noch nicht o.k.:
C++:
case 'u':
                u = va_arg (ap, UINT);
                k_itoa(u, buffer);
                puts(buffer);
                break;

Kennt einer ein utoa(...)?

Bei %d fehlt noch das %i, das auch verwendet wird.
Kleines %x barauche ich auch noch. Da muss ich wohl ein zweites k_i2hex schreiben.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 20:06:14 08.04.2009, insgesamt 1-mal bearbeitet
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 22:53:55 08.04.2009   Titel:              Zitieren

Erhard Henkes schrieb:

Kennt einer ein utoa(...)?

bau doch dein 'itoa' um, aber statt 'int' mit 'nem 'unsigned' input.
Erhard Henkes schrieb:

Kleines %x barauche ich auch noch. Da muss ich wohl ein zweites k_i2hex schreiben.

unnötiger luxus. wer hexziffern als gross/kleinbuchstaben braucht, kann doch toupper() oder tolower() bemühen.
:)
Nobuo T
Moderator

Benutzerprofil
Anmeldungsdatum: 09.10.2001
Beiträge: 4762
Beitrag Nobuo T Moderator 23:33:41 08.04.2009   Titel:              Zitieren

+fricky schrieb:
Erhard Henkes schrieb:

Kennt einer ein utoa(...)?

bau doch dein 'itoa' um, aber statt 'int' mit 'nem 'unsigned' input.

:live: Keine Ahnung, wie die entsprechende Standard-Funktion in C heisst, aber vom Prinzip her ist der Unterschied zu dem itoa minimal.

Ansonsten ist da erstmal wohl alles Wichtige gut dabei. Nur einige Kleinigkeiten noch:

video.c:
k_clear_screen:
Warum nicht gleich
C++:
k_memsetw (vidmem, blank, 80 * 25);

statt die Funktion 25* aufzurufen?

putch:
Grosse if/else-Schlacht... na egal :D
Ist es wirklich normales C-Verhalten, nur chars >= 0x20 auszugeben...?
DOS ist da zB. recht kompromisslos und gibt alles aus, was nicht als Steuerzeichen gewertet wird. Wuerde IMHO auch einen Vergleich sparen. :p

puts:
Wozu extra mit strlen zaehlen, wenn du das Array danach eh nochmal Zeichen fuer Zeichen abwanderst?
Mach's doch gleich so:
C++:
void puts(UCHAR* text)
{
    for (; *text; text++) putchar (*text);
}

(ich liebe es, for-Schleifen derart zu missbrauchen :cool: )

printf:
Ist die Behandlung von \n, \t, usw. hier nicht doppelt? Das wird doch in putch auch schon geprueft...
In dem Zusammenhang nehme ich auch mal an, dass du als default-Fall nicht wirklich "puts" nehmen wolltest?

_________________
==Mod im Assembler-Forum==

http://z0r.de/2908
abc.w
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2008
Beiträge: 1366
Beitrag abc.w Mitglied 23:40:24 08.04.2009   Titel:              Zitieren

Nobuo T schrieb:

C++:
void puts(UCHAR* text)
{
    for (; *text; text++) putchar (*text);
}

(ich liebe es, for-Schleifen derart zu missbrauchen :cool: )

Wenn missbrauchen, dann richtig:
C++:
void puts(UCHAR* text)
{
    for (; *text; putchar (*text++));
}

Weiss nicht obs kompiliert, wenn ja, dann :cool:
Nobuo T
Moderator

Benutzerprofil
Anmeldungsdatum: 09.10.2001
Beiträge: 4762
Beitrag Nobuo T Moderator 23:42:39 08.04.2009   Titel:              Zitieren

Ich bin skeptisch, aber: :D :live:

edit:
Bei genauerer Betrachtung: Wuerde das nicht einfach den referenzierten Wert erhoehen? Das waere ja eher kontraproduktiv... ;)

Wie waere es damit?
C++:
for (; *text; putchar (*text), text++);

:o)

edit2:
ok, einen habe ich noch!
C++:
for (; *text; putchar (*(text++));

Keine Ahnung, ob das kompiliert.

_________________
==Mod im Assembler-Forum==

http://z0r.de/2908


Zuletzt bearbeitet von Nobuo T am 01:59:01 09.04.2009, insgesamt 3-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 00:18:38 09.04.2009   Titel:              Zitieren

gefällt mir wirklich gut! :)
C++:
void puts(UCHAR* text)
{
    for(; *text; putch(*text), ++text);
}


auch sehr schön:
C++:
void k_clear_screen()
{
    k_memsetw (vidmem, 0x20 | (attrib << 8), 80 * 25);
    csr_x = 0; csr_y = 0; update_cursor();
}

:live:

Zitat:
Ist die Behandlung von \n, \t, usw. hier nicht doppelt? Das wird doch in putch auch schon geprueft...
In dem Zusammenhang nehme ich auch mal an, dass du als default-Fall nicht wirklich "puts" nehmen wolltest?

Ja, ich habe es mal auskommentiert. Habe putch(...) anstelle puts(...) gesetzt.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 00:26:43 09.04.2009, insgesamt 1-mal bearbeitet
Bitsy
Mitglied

Benutzerprofil
Anmeldungsdatum: 01.05.2001
Beiträge: 518
Beitrag Bitsy Mitglied 06:50:22 09.04.2009   Titel:              Zitieren

Habt ihr an das Backspace gedacht?
Für die ersten minimalen Editierdinge vielleicht doch wichtig.


Zuletzt bearbeitet von Bitsy am 06:54:23 09.04.2009, insgesamt 1-mal bearbeitet
Nobuo T
Moderator

Benutzerprofil
Anmeldungsdatum: 09.10.2001
Beiträge: 4762
Beitrag Nobuo T Moderator 10:42:38 09.04.2009   Titel:              Zitieren

Ist drin (siehe putch()). Was noch fehlt ist "bell". :p

_________________
==Mod im Assembler-Forum==

http://z0r.de/2908
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 18:58:31 09.04.2009   Titel:              Zitieren

Bell
Zitat:
Was noch fehlt ist "bell". :p
'\a': Was soll denn da passieren?
Ich habe es gerade mal ausprobiert:
C++:
#include <iostream>
 
int main()
{
 for(int i=0;i<100;++i)
     std::cout << '\a' << "bell ";
}

Da kam nichts aus meinem PC! :D
Ich habe einen speaker code (timer, channel 2) probiert, aber da ist alles abgestürzt, hier ist der Code, ging aber nicht, alles abgestürzt. :rolleyes:
..

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 10:53:17 05.10.2013, insgesamt 7-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 19:33:59 09.04.2009   Titel:              Zitieren

Als Belohnung für die, die bisher dabei geblieben sind:
http://www.youtube.com/watch?v=_RyodnisVvU ;)
http://www.youtube.com/watch?v=o8VqCqpfWrk

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 19:51:32 09.04.2009, insgesamt 1-mal bearbeitet
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 23:52:28 09.04.2009   Titel:              Zitieren

Erhard Henkes schrieb:

http://www.youtube.com/watch?v=o8VqCqpfWrk

*gähn*
das sind coole roboter: http://www.bostondynamics ....... /sec.php?section=robotics
(mit verbrennungsmotor und so)
:)
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 11:50:52 10.04.2009   Titel:              Zitieren

OK, will niemanden langweilen, also "back to the grindstone":
http://www.henkessoft.de/ ....... PrettyOS_last_version.zip

Ich habe die GDT/IDT-Infos und Timer-Späßchen auf dem Screen lahm gelegt und begonnen, den Keyboard Treiber zu überarbeiten, damit man endlich Texte mit automatischem Zeilenumbruch und Scroll eintippen kann, so eine Art Primitiv-Editor eben. Nobuo T dürfte sich freuen, die while(TRUE) Story ist vorbei, nun läuft es nur einmal den "Scanner" durch, wie es logischer ist. BACKSPACE, TAB und ENTER funktionieren, aber man hat noch keine Steuerung mit den Pfeiltasten (da bin ich noch vorsichtig, ein move_cursor_right() ist allerdings schon eingebaut; Orientierung an schwarzer DOS-Box (cmd)?), diesbezüglich muss man also noch "übertippen" bzw. sich mit der Kombination aus TAB und BACKSPACE korrekt positionieren. Pos1, Ende, Entf ... sind auch noch nicht aktiviert. Das läuft ja alles via putc(...) als default im printformat(...), siehe keyboard_handler(...).
..

Was fehlt eurer Meinung nach noch bei dem EDIT-Modus des OS?
"Befehle" würde man dann wohl per ENTER entgegen nehmen?
In einem strcmp (analog zur Methode im Real Mode, jetzt nur in C) vergleichen und entsprechend über eine switch/case-Kontrollstruktur reagieren?
Welche Befehle würdet ihr denn als ersten Schritt implementieren?
- Info/info
- Help/help/?
- Reboot/reboot
- ...

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 10:53:59 05.10.2013, insgesamt 3-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 12:12:28 10.04.2009   Titel:              Zitieren

Damit wir nicht den Gesamtüberblick verlieren, hier eine rohe Tasklist / Sammlung aus den bisherigen Posts:
Zitat:

- PIC (die beiden PICs wurden bereits beim remapping von IRQ 0-15 verarbeitet)
- PIT (programmable interval timer)
- Speaker (ja, BEEP (frequence)! Seit Win NT kaputt wegen Behinderung.)
- (video.c vernünftig ausbauen, bisher nur rudimentär)
- OS-Thematik (generell)
- Dynamische RAM Verwaltung:
- Unterteilung des Speichers in Blöcke statischer Groesse (4KB)
- Verwaltung (stat. Arrays, Bitmaps, dynam. Free-Lists)
- Reservierungsstrategie next fit
- Wiedereingliederungsproblematik
- Paging
- Programme & Prozesse
- Multitasking vs Singletasking
- Prozesserzeugung, Kontextwechsel, Scheduling, Verdrängung
- Privilegien / Schutzmechanismen / Adressraumtrennung
- Micro- vs Macro-Kernel
- inter-process communication

- Kernel-API (und einem HW-Abstraktions/Treiber-Prinzip).
Alle Kernel-Funktionen, Treiber etc. einfach nur ueber C-Funktionen und header zur Verfuegung zu stellen,
ist sicher nicht das Wahre. Ich wuerde die Einrichtung eines kleinen Sets der wichtigsten Funktionen zum
I/O und spaeter dann Speicher- und Prozessverwaltung ueber Interrupts aehnlich DOS oder Linux vorschlagen.
Je nachdem, was fuer einen Kern du basteln willst (Micro oder Monolith), waere es evtl. sinnvoll,
das schon ganz am Anfang beim Aufbauen der ersten abstrakteren OS-Funktionen wie RAM-Verwaltung zu diskutieren,
statt erst bei Adressraumtrennung, Privilegien und IPC. Evtl. mit Verweis auf diese spaeteren Themen zur Begruendung.


- Was du da weiter anfuehrst, sind doch eher Spezialfaelle und Teilgebiete, des Themenbereichs Scheduling
(Echtzeit-Prozesse). Solche Ansaetze wie Prioritaetensteuerung oder verschiedene Ansaetze fairer Ressourcenverteilung
mit verschiedensten abgefahrenen queue-Konstrukten (da gibt es wirklich eine Menge weit komplizierteres
als einfache Prioritaetensteuerung) kann man da vielleicht in einem Ueberblick kurz anschneiden,
aber um den Rahmen nicht zu sprengen, waere mein Vorschlag, sich schliesslich einfach auf Round Robin zu beschraenken.

- DMA-Gefrickel ist ja nun voellig abgehoben. Immer im Hinterkopf behalten, dass das ein Internet-Tutorial
und kein Kompendium zur OS-Entwicklung werden soll - das wird wie ich das sehe schon so eine ordentliche Portion Stoff.

Timer:
- für frei laufende countdown-timer machste dir z.b. ein paar funktionen:
// erzeugt einen neuen timer und meldet ihn beim OS an. gibt 0 zurück, wenn kein timer alloziert werden konnte
timer_t *timer_create(void);

// startet den timer, der ab jetzt vom OS von 'timeout' bis 0 runtergezählt wird
void timer_start (timer_t *timer, unsigned long timeout);

// prüft ob der timer abgelaufen ist, gibt 0 zurück, wenn der timer noch läuft, sonst 1
int timer_expired (timer *t);

// beseitigt den timer (trägt ihn z.b. aus der liste des OS aus und gibt seinen speicher frei)
void timer_free (timer_t *timer);

die hardware-isr schaut bei jedem tick in eine verkettete liste, ob timer drin sind, die sie runterzählen muss.


Keyboard:
- zu den I/O-daten: am besten du benutzt FIFO-buffer für sowas.
die ISR (z.b. von der tastatur) trägt empfangene daten in den FIFO ein und die anwendung holt sie sich raus.
ein tastatur-FIFO kann recht klein sein und darf ältere daten überschreiben, weil uralte tastendrücke ja nicht mehr interessieren.
ein benutzer-prozess kann dann einfach zeichen aus dem FIFO holen, z.b. so:
// hole ein zeichen aus dem tastatur-buffer. wenn c -1 (oder EOF) ist, war der FIFO leer
int c = getchar();

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 12:13:24 10.04.2009, insgesamt 1-mal bearbeitet
abc.w
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2008
Beiträge: 1366
Beitrag abc.w Mitglied 15:11:37 10.04.2009   Titel:              Zitieren

Erhard Henkes schrieb:
Was fehlt eurer Meinung nach noch bei dem EDIT-Modus des OS?

vi-Kompatibilitätsmodus? ;)
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 15:55:27 10.04.2009   Titel:              Zitieren

Zitat:
vi-Kompatibilitätsmodus?
Interessanter Punkt. Ich kenne bisher nur dieses gvim und kann mich nur noch dunkel an den DOS editor (EDIT) erinnern. Arbeitet vi wie gvim?

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 17:22:05 10.04.2009   Titel:              Zitieren

Erhard Henkes schrieb:
Zitat:
vi-Kompatibilitätsmodus?
Interessanter Punkt. Ich kenne bisher nur dieses gvim und kann mich nur noch dunkel an den DOS editor (EDIT) erinnern. Arbeitet vi wie gvim?

vim ist ein aufgemotzter vi, also voll kompatibel, aber genau so besch... in der bedienung. btw, ein editor ist doch kein bestandteil eines OS, sondern nur eine gewöhnliche anwendnung. mach besser mit'm OS weiter und nicht noch 'ne baustelle auf.
:)
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 19:11:04 10.04.2009   Titel:              Zitieren

Zitat:
ein editor ist doch kein bestandteil eines OS, sondern nur eine gewöhnliche anwendnung. mach besser mit'm OS weiter und nicht noch 'ne baustelle auf.
"Festina lente" sagt der Lateiner (Lieblingsspruch des Kaisers Augustus). Mir geht es aktuell darum, keyboard.c und video.c vernünftig zu stabilisieren. Diese beiden Module mit ihren Funktionen sind wichtig. Das wird dann auch das Ende von Teil 1 (Booten, RM, A20 Gate, RM -> PM, asm <-> C, GDT, IDT u. IRQ, video, timer und keyboard). Bei Teil 2 geht es mit dem wirklichen OS (Speicher, Multitasking, Prozesse, API, ...) weiter. Aber zuerst muss Teil 1 so abgerundet sein, dass man dort niemand verliert.

Ein echter Editor ist in der Tat ein User-Programm, gehört also nicht zwingend zum OS. Daher werde ich mich bezüglich der Bedienung an den DOS- und Linux-Konsolen orientieren.


Noch eine Detail-Frage: Über den PIT bin ich ja etwas weg gegangen, akzeptiere bisher die Standardeinstellung. Sollte man so etwas in der Art noch einbauen:
C++:
1
2
3
4
5
6
7
8
9
10
11
12
13
void systemTimer_setFrequency( ULONG freq )
{
   ULONG divisor = 1193180 / freq; //divisor must fit into 16 bits
   
   //TODO: save frequency globally
 
   // Send the command byte.
   outportb(0x43, 0x36);
 
   // Send divisor.
   outportb(0x40, (UCHAR)(  divisor     & 0xFF )); // low  byte
   outportb(0x40, (UCHAR)( (divisor>>8) & 0xFF )); // high byte
}


Ich habe es mal mit 100 Hz (Standard: ca. 18 Hz), also alle 10 ms ein Tick, probiert:
C++:
void timer_install()
{
    /* Installs 'timer_handler' to IRQ0 */
    irq_install_handler(0, timer_handler);
    systemTimer_setFrequency( 100 );
}

C++:
void sleepSeconds (ULONG seconds)
{
    // timer_wait((ULONG)18.2065*seconds); // standard
    timer_wait((ULONG)100*seconds);
}

Macht das mit 100 Hz Sinn? Sollte man hier eine Auswahl bieten oder eine Festeinstellung vornehmen? (wird für IRQ-gesteuertes Multitasking interessant)

Beim Keyboard verwende ich nun auch gespeicherte Cursors, falls man z.B. Infos in eine Statuszeile schreibt:
C++:
1
2
3
4
5
6
7
8
void keyboard_handler(struct regs* r)
{
   UCHAR KEY;
   KEY = k_getch();
   restore_cursor();
   printformat("%c",KEY); // the ASCII character
   save_cursor();
}


ckernel.c:
C++:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
#include "os.h"
 
int main()
{
    k_clear_screen();
 
    // GDT, IDT, ISRS, IRQ, timer, keyboard
    gdt_install();
    idt_install();
    isrs_install();
    irq_install();
    timer_install(); //jetzt incl. Frequenz
    keyboard_install();
    sti();
 
    set_cursor(0,0);
    printformat("   ************************************************\n");
    printformat("   *                                              *\n");
    printformat("   *          Welcome to PrettyOS 0.05            *\n");
    printformat("   *                                              *\n");
    printformat("   *        The C kernel has been loaded.         *\n");
    printformat("   *                                              *\n");
    printformat("   ************************************************\n");
 
    settextcolor(4,1);
 
    int y=10;
    while(TRUE)
    {
    sleepSeconds(20);
    if(y>24) y=24;
    set_cursor(0,++y);
    printformat("10 sec have passed");
    };
    return 0;
};

In Bochs klappt dies ganz gut mit den 100 Hz.


Allgemein:
Bezüglich des OS überdenke ich momentan die Reihenfolge. Wäre nun das "Paging" als nächster Schritt angesagt? Man kann diesem Mechanismus ja doch nicht wirklich entfliehen, und ich möchte wegen des interessanten inneren Aufbaus ein Multitasking-OS aufbauen.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 19:50:20 10.04.2009, insgesamt 3-mal bearbeitet
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 20:08:55 10.04.2009   Titel:              Zitieren

Erhard Henkes schrieb:

Wäre nun das "Paging" als nächster Schritt angesagt? Man kann diesem Mechanismus ja doch nicht wirklich entfliehen, und ich möchte wegen des interessanten inneren Aufbaus ein Multitasking-OS aufbauen.

naja, virtual memory und paging/swapping/was-auch-immer kannste auch später noch einbauen. multitasking geht auch, ohne mmu und isolation des speichers der prozesse voneinander. nachträglich lässt sich virtual memory transparent ins system integrieren, ohne dass grossartige umbauten nötig sind. wenn dich das thema interessiert, kannste natürlich sofort damit loslegen. aber irgendwie werd' ich das gefühl nicht los, dass du dir sowas wie 'nen projektplan machen solltest.
:)
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 23:02:31 10.04.2009   Titel:              Zitieren

Zitat:
projektplan
@+fricky: Du siehst das IMHO sehr schematisch. "Projekte" sind zumeist langweilig, ökonomisch getrieben und haben einen engen Zielkorridor. So etwas interessiert mich nur beruflich.

Experimente schaffen dagegen wirklich Neues. Ich habe weitgehend klare Vorstellungen von der prinzipiellen Vorgehensweise. Obwohl es keine klare Theorie über den optimalen Weg gibt, werden vielfach bestehende OS als Ziel nachgeahmt. Als Ziel schwebt mir ein lernfähiges und bezüglich der Anforderungen adaptives OS vor, bin aber nicht sicher, ob dies im ersten Ansatz erreichbar ist.

Zur Zeit geht es erst einmal darum, die Basics stabil und dennoch flexibel zu arrangieren, um zum Experimentieren einzuladen. Das Ganze kann sich auch gabeln, wenn es darum geht interessante Pfade zu verfolgen. Bisher denke ich, habe ich hoffentlich noch keinen neuen wirklich verfolgenswerten Ansatz übersehen.

Einen Fehler muss ich allerdings gestehen, nämlich das Tutorial in deutsch aufgesetzt zu haben. Damit halte ich einige interessierte Mitstreiter aus aller Welt auf Distanz. Vielleicht kann ich noch kapitelweise englische Summaries einflechten, die das Nachvollziehen/Mitdenken erlauben.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 23:31:42 10.04.2009, insgesamt 1-mal bearbeitet
volkard
Mitglied

Benutzerprofil
Anmeldungsdatum: 06.04.2000
Beiträge: 29842
Beitrag volkard Mitglied 23:33:17 10.04.2009   Titel:              Zitieren

Erhard Henkes schrieb:
Einen Fehler muss ich allerdings gestehen, nämlich das Tutorial in deutsch aufgesetzt zu haben. Damit halte ich einige interessierte Mitstreiter aus aller Welt auf Distanz. Vielleicht kann ich noch kapitelweise englische Summaries einflechten, die das Nachvollziehen/Mitdenken erlauben.

wenn du anklingen läßt, daß du dich freuen würdest, wenn das jemand übersetzen würde, dann findet sich vermutlich auch jemand, der sich freut, das offiziell zu übersetzen, natürlich mit namensnennung und link auf die hp des edlen helfers.

_________________
return [ :><%%> ();//c++-trollfish returning void
Ich empfehle dringend, das Problem zu vertagen, bis es akut wird. Dann liegt mehr Erfahrung vor, was wirklich gebraucht wird.
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 23:48:59 10.04.2009   Titel:              Zitieren

Zitat:
wenn du anklingen läßt, daß du dich freuen würdest, wenn das jemand übersetzen würde, dann findet sich vermutlich auch jemand, der sich freut, das offiziell zu übersetzen, natürlich mit namensnennung und link auf die hp des edlen helfers.
Nein, daran habe ich wirklich nicht gedacht, da das Tutorial noch zu sehr im Fluss ist. Vorne den Abschnitt im Real Mode könnte man z.B. noch mit interessanten Befehlen/Funktionen aufbohren. Ich finde z.B. dein C++-Tutorial als didaktisches Vorbild super. Solche Fragestellungen mit Lösungen sind wirklich schön, weil man dadurch die Leser zum Experimentieren und selbst denken anregen kann. Es geht mir darum, auf praktische Weise zu zeigen, welche "Bausteine" beim OS-Bau zur Verfügung stehen, wie diese funktionieren und was man damit praktisch machen kann.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 23:54:34 10.04.2009   Titel:              Zitieren

Zunächst muss ich die Funktionen innerhalb video.c an allgemein übliche Vorgehensweisen anpassen. Mir ist z.B. aufgefallen, dass das "Backspace" noch nicht "löscht", das scheint aber üblich zu sein. http://de.wikipedia.org/wiki/Backspace
"Rücklöschtaste". Das und einiges andere muss ich zunächst anpassen, bevor es weiter geht. So, das sieht schon besser aus, sogar rekursiv :D :
Bei P(0,0) macht es gar nichts mehr, ansonsten geht es eins zurück, löscht (druckt ' ') und geht wieder eins zurück. Am Zeilenanfang muss ein Rücksprung ans Zeilenende eins höher erfolgen.
C++:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
void putch(UCHAR c)
{
    USHORT* pos;
    UINT att = attrib << 8;
 
    if(c == 0x08) // backspace: move the cursor back one space and delete
    {
        if(csr_x)
        {
            --csr_x;
            putch(' ');
            --csr_x;
        }
        if(!csr_x && csr_y>0)
        {
            csr_x=79;
            --csr_y;
            putch(' ');
            csr_x=79;
            --csr_y;
        }
   
    }
    // ...
}


Der Keyboard Handler fängt jetzt auch an, sich um die Sondertasten zu kümmern:
C++:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
void keyboard_handler(struct regs* r)
{
   UCHAR KEY;
   KEY = k_getch();
   restore_cursor();
   switch(KEY)
   {
       case KINS:
           break;
       case KDEL:
           move_cursor_right();
           putch('\b');//BACKSPACE
           break;
       case KHOME:
           move_cursor_home();
           break;
       case KEND:
           move_cursor_end();
           break;
       case KPGUP:
           break;
       case KPGDN:
           break;
       case KLEFT:
           move_cursor_left();
           break;
       case KUP:
           break;
       case KDOWN:
           break;
       case KRIGHT:
           move_cursor_right();
           break;
       default:
           printformat("%c",KEY); // the ASCII character
           break;
   }
   save_cursor();
}


In video.c musste auch noch einiges hinzu gefügt werden.
C++:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
void move_cursor_right()
{
    ++csr_x;
    if(csr_x>=80)
    {
      ++csr_y;
      csr_x=0;
    }
}
 
void move_cursor_left()
{
    if(csr_x)
        --csr_x;
    if(!csr_x && csr_y>0)
    {
        csr_x=79;
        --csr_y;
    }
}
 
void move_cursor_home()
{
    csr_x = 0; update_cursor();
}
 
void move_cursor_end()
{
    csr_x = 79; update_cursor();
}

wie üblich:
http://www.henkessoft.de/ ....... PrettyOS_last_version.zip

Wenn jemand hier bessere Ideen hat, bitte posten.
Ich bin mir z.B. noch nicht sicher, ob man bei der Instruktionseingabe überhaupt einen Wechsel der Zeile - und damit mehrzeilige Eingaben - zulassen sollte.
Bei END springe ich an das Ende der Zeile und nicht an das Ende des Eingetippten. Bei DEL lösche ich auch nur ein Zeichen und schiebe nicht den Rest der Zeile eins nach links.
Vielleicht müsste man zwischen zwei ENTER einen virtuellen Befehlsstring aufbauen, der von HOME bis END geht. Zumindest sieht es bei der DOS-Box (Konsole) so aus. Da bin ich noch flexibel.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 01:14:02 11.04.2009, insgesamt 3-mal bearbeitet
Bitsy
Mitglied

Benutzerprofil
Anmeldungsdatum: 01.05.2001
Beiträge: 518
Beitrag Bitsy Mitglied 10:07:36 11.04.2009   Titel:              Zitieren

Ist auch einfach die Frage, wie komfortabel Du das überhaupt gestalten möchtest.
Ein grundlegender Kommandointerpreter könnte ja einen eigenen Editor mitbringen, sodaß etwas Rudimentäres vollkommen ausreicht. Auf der anderen Seite kannst Du's im Kernel aber bis zum kompletten Memoryhexeditor treiben ;)
Nobuo T
Moderator

Benutzerprofil
Anmeldungsdatum: 09.10.2001
Beiträge: 4762
Beitrag Nobuo T Moderator 10:48:47 11.04.2009   Titel:              Zitieren

IMHO haben konkrete Reaktionen auf Tasteneingaben im IRQ-Handler (HW-Treiber) nichts zu suchen. Das sind Teile einer Anwendung. Ist vielleicht so zu Demo-Zwecken ganz nett, aber mit brauchbarem OS-Design hat das nichts zu tun.
Irgendwie macht das so immer noch den Eindruck, als wuerdest du die Sache ein wenig wie dieses erste Polling-Relikt behandeln.
Also entweder ueberlegst du dir ein vernuenftiges Treiber-Design und machst bei keyboard und video dann mal langsam die Kiste zu (das bedeutet auch, dass du kapselnde Funktionen brauchst, falls du mal mit dem Entwurf einer echten API anfaengst), dann kannst du auf diesen abgeschlossenen Treibern auch etwas rumbasteln, das ueber den Rest des Tutorials im Prinzip so funktionieren sollte, oder du beschraenkst dich hier nur auf das absolut notwendigste. Solche aufwendigen, dennoch halbgaren und bestenfalls bis zum Ende dieses Kapitels brauchbaren Basteleien sind IMHO kontraproduktiv.

_________________
==Mod im Assembler-Forum==

http://z0r.de/2908


Zuletzt bearbeitet von Nobuo T am 10:54:21 11.04.2009, insgesamt 2-mal bearbeitet
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 16:12:26 11.04.2009   Titel:              Zitieren

Zitat:
IMHO haben konkrete Reaktionen auf Tasteneingaben im IRQ-Handler (HW-Treiber) nichts zu suchen. Das sind Teile einer Anwendung. Ist vielleicht so zu Demo-Zwecken ganz nett, aber mit brauchbarem OS-Design hat das nichts zu tun.
Ja, das ist völlig richtig. Ich werde jetzt bei video.c und keyboard.c aufhören, als kleine Demo reichen diese Funktionen bereits. "Externe Anwendungen" sind noch nicht lauffähig. Was ich auf der Stufe noch einfügen möchte, ist ein Kommandozeileninterpreter mit nachgeschaltetem strcmp(...) und entsprechenden Reaktionen so wie beim Real Mode, am besten in main(), diesmal nur in C programmiert und ohne BIOS. Diese Parallele erwartet man irgendwie. :)
Dann geht's im zweiten Teil thematisch mit Paging, Heap, Designfragen weiter. Das wird dann aber alles elend komplex. Da knabbere ich noch dran. Zur Zeit beschimpft mich sogar schon mein Linker, weil ich Paging und Heap modular nicht sauber auseinander halte. Übel, übel, .... :D
EDIT: zumindest das endlich geschafft. :D

@Nobuo T: Wenn ich Dich richtig verstanden habe, würdest Du im Keyboard Handler die Information in eine Queue stecken. Der Kommandozeilen-Interpreter (wo gehört der als "Anwendung" hin? Für mich ist dies noch Teil des Kernels.) müsste sich diese dann dort abholen und verarbeiten, so wie jetzt - zur Demo - bereits im Keyboard Handler erfolgt, richtig? Der Kommandozeilen-Interpreter muss ein Prompt drucken, nach ENTER die Zeile (ohne Prompt) schlucken und verarbeiten mittels strcmp und switch/case-Struktur (wie bei einer Windows-Nachrichten-Pumpe).

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 17:25:00 11.04.2009, insgesamt 8-mal bearbeitet
jenz
Mitglied

Benutzerprofil
Anmeldungsdatum: 29.06.2005
Beiträge: 257
Beitrag jenz Mitglied 18:18:45 11.04.2009   Titel:              Zitieren

Der Keyboardhandler sollte die Eingaben nicht in eine eigene Queue fließen lassen, sondern gleich an die Queue der aktiven Anwendung.
Deshalb würde ich als nächstes damit beginnen Grundstrukturen für Anwendungen zu definieren. Da gehören dann auch die Schnittstellen zu Treibern dazu.

Wenn man die Grundstrukturen hat, dann am besten gleich Multitasking/threading und nen einfach Scheduler einbauen, dann macht es einfach mehr Spaß.

Man kann auch erst mal die Schnittstellen zu den Treibern weglassen und einfach ein paar Anwendungen laufen lassen. Die könnten dann ja alle gleichzeitig in den Bildschirm malen.

Wenn man erst mal zwischen Anwendungen und Kern/System getrennt hat, dann ist es einfacher die Schnittstellen zu entdecken und zu bauen. Das diese dann gleich so angenehm wie möglich sind ist natürlich noch eine ganz andere Frage.

jenz
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 18:49:04 11.04.2009   Titel:              Zitieren

Zitat:
zwischen Anwendungen und Kern/System getrennt
Ja, das ist wohl der entscheidende Punkt.

Zitat:
Der Keyboardhandler sollte die Eingaben nicht in eine eigene Queue fließen lassen, sondern gleich an die Queue der aktiven Anwendung.
Ja, das klingt sinnvoll, damit es keine Verwechslungsprobleme beim Leeren eines gemeinsamen Briefkastens gibt. Das Problem ist, dass wir noch keine Anwendungen laufen lassen können, weil die Strukturen hierzu noch fehlen. Würdest Du den Kommandozeileninterpreter bereits als Anwendung in Privilegstufe 3 laufen lassen?

Zitat:
Am besten gleich Multitasking/Threading und 'nen einfachen Scheduler einbauen, dann macht es einfach mehr Spaß.
Spaß klingt gut. :)

Zitat:
Man kann auch erst mal die Schnittstellen zu den Treibern weglassen und einfach ein paar Anwendungen laufen lassen. Die könnten dann ja alle gleichzeitig in den Bildschirm malen.
Das mache ich momentan mit dem Timer und dem "Editor" Keyboard Handler ja auch, deshalb musste ich schon den Cursor speichern.

Ich experimentiere gerade mit einem Paging-/Heap-Modul, ist kompliziert (schlecht für Didaktik), miteinander vernetzt und klappt leider noch nicht, wie ich es will. Das wollte ich als nächsten Schritt einfügen, noch bevor die Anwendungen im Multitasking laufen. Das gehört aber alles nach Teil 2, der leider viel Zeit braucht (liegt an meinen beschränkten Fähigkeiten und Erfahrungen in diesem Bereich). Macht aber nichts, fahre ja kein Wettrennen.

Teil 1 wollte ich mit einem kleinen Befehlsinterpreter im Kernel (Analogie zur Vorgehensweise im RM) beenden, damit die eingetippten Zeichen Sinn machen. Kann man aber in Teil 2 wohl alles wegwerfen, da hat Nobuo T leider Recht. :rolleyes:
Sehe ich aber nicht als großes Problem.
EDIT: Vielleicht kann man die Idee mit dem BIOS-Briefkasten und dem Abholen der Post dort durch einen Befehlsinterpreter kombinieren. :)

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 18:59:26 11.04.2009, insgesamt 2-mal bearbeitet
Nobuo T
Moderator

Benutzerprofil
Anmeldungsdatum: 09.10.2001
Beiträge: 4762
Beitrag Nobuo T Moderator 18:54:00 11.04.2009   Titel:              Zitieren

Klar waere es ein praktisches Konzept, eine KB-queue pro Anwendung einzurichten. Da das OS in diesem Stadium aber noch nicht mal ein Konzept fuer Anwendungen hat, ist das alles noch Zukunftsmusik und erst im naechsten Kapitel ausfuehrlich zu diskutieren.
Eine globale queue zum Ablegen der KB-Codes (so macht es das BIOS auch) waere im Moment sicher am praktischsten. Diese liesse sich spaeter auch relativ einfach entsprechend den Beduerfnissen des Multitaskings anpassen.
Die ISR liest also die Scancodes vom KB, setzt die Flags, wandelt in ASCII-Codes um, o.Ae. und eine getch-Funktion (vgl. int 16h, ah=0) liest die queue dann im Rahmen der Anwendung (hier einfach des "Kerns") wieder aus.

_________________
==Mod im Assembler-Forum==

http://z0r.de/2908
jenz
Mitglied

Benutzerprofil
Anmeldungsdatum: 29.06.2005
Beiträge: 257
Beitrag jenz Mitglied 18:56:00 11.04.2009   Titel:              Zitieren

Ja, ich würde die Anwendung erst mal im Kern laufen lassen. Erst mal alle Anwendungen.

Die dürfen natürlich von Anfang an nur über entsprechende Methodenaufrufe auf Systemfunktionen zugreifen, da kann man dann den Wechsel von Rang 0 auf 3 oder wie herum auch immer Transparent einbauen.

Aber erst mal muss was laufen. Dann hat man auch leichter die Möglichkeit Aufgaben abzugeben und jemand anderes kann dir Testanwendungen zusammenbauen oder an Treiberfunktionen schrauben.

Ich würde (habe) es (mal mehr mal weniger) schön mit C++, nicht mit C machen (gemacht).

jenz
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 19:02:03 11.04.2009   Titel:              Zitieren

Zitat:
Ich würde (habe) es (mal mehr mal weniger) schön mit C++, nicht mit C machen (gemacht).
Im Kernel bleiben wir bei C.

@Nobuo T: welche Flags meinst Du genau (nehmen wir die BDA als Vorbild) setzen? Diesen Bereich bei 40:17? Gibt es bereits eine vereinfachte (oder auch die komplette) BDA Struktur als C-Struct, die man einsetzen könnte oder muss man das selbst aufbauen? Da könnte man ja auch die statische Queue gleich ablaufen lassen.
Im BDA wird offenbar 40:1E - 40:3D als "circular queue buffer" (32 Byte) verwendet.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 19:17:01 11.04.2009, insgesamt 1-mal bearbeitet
jenz
Mitglied

Benutzerprofil
Anmeldungsdatum: 29.06.2005
Beiträge: 257
Beitrag jenz Mitglied 19:03:24 11.04.2009   Titel:              Zitieren

Schade, kann ich die Begründung weiter oben im Thread lesen?
Wenn nicht, wieso?
Nobuo T
Moderator

Benutzerprofil
Anmeldungsdatum: 09.10.2001
Beiträge: 4762
Beitrag Nobuo T Moderator 20:53:40 11.04.2009   Titel:              Zitieren

Erhard Henkes schrieb:
welche Flags meinst Du genau (nehmen wir die BDA als Vorbild) setzen? Diesen Bereich bei 40:17?

Jup, genau die.

Erhard Henkes schrieb:
Gibt es bereits eine vereinfachte (oder auch die komplette) BDA Struktur als C-Struct, die man einsetzen könnte oder muss man das selbst aufbauen? Da könnte man ja auch die statische Queue gleich ablaufen lassen.
Im BDA wird offenbar 40:1E - 40:3D als "circular queue buffer" (32 Byte) verwendet.

Keine Ahnung, ob es da bereits etwas fertiges gibt. Da was eigenes zu implementieren sollte aber wohl schneller erledigt sein, als nun erst was zu suchen. ;)

Musst ja erstmal auch nicht alles implementieren, und auch nicht genau wie in der BDA. Nicht vergessen: Das ist nur ein moegliches Konzept, das in der Form wahrscheinlich auch nicht gerade ideal fuer Multitasking geeignet ist.

... ...
Evtl. bietet es sich als naechstes dann doch schon mal an, vorausschauend grob etwas ueber das Treiber-Design nachzudenken. zB. erstmal:
Was hast du an Input von der HW? Was davon willst du welchen Anwendungen in welchem Fall mitteilen? Welche Datenstruktur koennte sich dazu eignen? Was fuer Interface-Funktionen koennte man darauf benutzen?

jenz schrieb:
Schade, kann ich die Begründung weiter oben im Thread lesen?
Wenn nicht, wieso?

Ja, das wurde bereits diskutiert und einvernehmlich befunden, dass die Nachteile beim Einsatz von C++ die Vorteile bisher ueberwiegen.

_________________
==Mod im Assembler-Forum==

http://z0r.de/2908
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 23:37:43 11.04.2009   Titel:              Zitieren

Nobuo T schrieb:
IMHO haben konkrete Reaktionen auf Tasteneingaben im IRQ-Handler (HW-Treiber) nichts zu suchen. Das sind Teile einer Anwendung. Ist vielleicht so zu Demo-Zwecken ganz nett, aber mit brauchbarem OS-Design hat das nichts zu tun.
Irgendwie macht das so immer noch den Eindruck, als wuerdest du die Sache ein wenig wie dieses erste Polling-Relikt behandeln.
Also entweder ueberlegst du dir ein vernuenftiges Treiber-Design und machst bei keyboard und video dann mal langsam die Kiste zu (das bedeutet auch, dass du kapselnde Funktionen brauchst, falls du mal mit dem Entwurf einer echten API anfaengst), dann kannst du auf diesen abgeschlossenen Treibern auch etwas rumbasteln, das ueber den Rest des Tutorials im Prinzip so funktionieren sollte, oder du beschraenkst dich hier nur auf das absolut notwendigste. Solche aufwendigen, dennoch halbgaren und bestenfalls bis zum Ende dieses Kapitels brauchbaren Basteleien sind IMHO kontraproduktiv.

alle daumen hoch. dem muss man nichts mehr hinzufügen.

jenz schrieb:

Der Keyboardhandler sollte die Eingaben nicht in eine eigene Queue fließen lassen, sondern gleich an die Queue der aktiven Anwendung.

würde ich nicht so machen. die queue gehört in den keyboard-treiber bzw. in den kernel und anwendungen können sich was daraus abholen. ebenso würde ich mit maus-events verfahren. auch würde ich mir die möglichkeit offen lassen, mehrere mäuse und mehrere keyboards anschliessen zu können, also von vorn herein modulare, objektorientierte strukturen zu schaffen, finde ich ziemlich wichtig.

Erhard Henkes schrieb:

Der Kommandozeilen-Interpreter (wo gehört der als "Anwendung" hin? Für mich ist dies noch Teil des Kernels.)

nee, ein komandozeilen-interpreter ist bestenfalls eine sogenannte 'shell', also eine art bindeglied zwischen benutzer und bestimmten system-services. der gehört genau so wenig in den kernel, wie ein editor oder eine tabellenkalkulation.

jenz schrieb:
Schade, kann ich die Begründung weiter oben im Thread lesen?
Wenn nicht, wieso?

C++ ist unglaublich mächtig, aber auch komplex und 'esoterisch'. man könnte natürlich c++ verwenden, aber dann bräuchte man knallharte coding-richtlinien und leute, die diszipliniert und perfekt im umgang mit dieser sprache sind, sonst wird das nix. C ist im vergleich dazu primitiv und einfach strukturiert. das ist aber der entscheidende vorteil: weniger ist mehr. z.b. sind fehler in einem C-programm, im vergleich zu C++, trivial, leicht zu finden/debuggen und haben weniger weitreichende folgen.
:)
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 23:46:23 11.04.2009   Titel:              Zitieren

Mir würde C++ leichter fallen als C, aber ich weiß von den Robotik-Anwendungen, dass man nur gewisse Features sinnvoll nutzen kann, sozusagen gekapseltes C mit Klassen ist der Idealstil, aber das schafft man auch anders. Daher trage ich die Entscheidung für C eindeutig mit. Wenn man vernünftig damit umgeht, ist es ein herrliches Bindeglied zwischen Assembler und der Hochsprachen-Welt, im OS-Bereich sicher die richtige Wahl.

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 00:17:35 12.04.2009, insgesamt 1-mal bearbeitet
jenz
Mitglied

Benutzerprofil
Anmeldungsdatum: 29.06.2005
Beiträge: 257
Beitrag jenz Mitglied 02:20:18 12.04.2009   Titel:              Zitieren

stimmt, objektorientiert kann man auch mit c entwickeln. ist aber aus meiner sicht eben fehleranfälliger und auch aufwendiger beim schreiben. aber okay, entscheidung ist gefallen.

warum sollen sich die anwendungen denn die ereignisse selbst abholen? man kann die doch besser von anfang gleich eventgesteuert implementieren.
pollen ist doch nicht wirklich schön

jenz
Unregistrierter





Beitrag Unregistrierter 11:06:27 12.04.2009   Titel:              Zitieren

Hat es angesichts der Diskussion über das weitere Vorgehen noch einen Sinn, den jeweils aktuellen Quellcode mal unter die Lupe zu nehmen?
+fricky
Unregistrierter




Beitrag +fricky Unregistrierter 11:42:28 12.04.2009   Titel:              Zitieren

jenz schrieb:

warum sollen sich die anwendungen denn die ereignisse selbst abholen?

weil das z.b. für sequenziell ablaufende programme (ein stinknormales c-programm z.b. das mit 'main' beginnt) einfacher ist und es bedeutet auch weniger verwaltungsaufwand im kernel (der schiebt einfach daten in die dazugehörigen queues und kümmert sich nicht weiter drum). falls du auf sowas wie eventgesteuerte gui-anwendnungen anspielst, die sind ja clients eines 'window-managers', der prinzipiell selber bloss eine anwendung ist. er würde dann z.b. beim eintreffen eines zeichens die window-prozedur des entsprechenden fensterchens aufrufen und damit hätte die gui-anwendung ihre events.

jenz schrieb:

man kann die doch besser von anfang gleich eventgesteuert implementieren.
pollen ist doch nicht wirklich schön.

mit dem 'selbstabholen' hat man doch beide möglichkeiten. beispiele mit einem non-blocking getchar()...

event-gesteuert:
Code:
int c;
wait_for_event (KEYBOARD_EVENT);  // die task schläft, bis mindestens 1 zeichen in der queue ist
c = getchar();  // zeichen abholen

polling:
Code:
1
2
3
4
5
6
7
8
9
10
int c;
c = getchar();  // zeichen abholen, -1 bei fehlschlag
if (c > 0)
{
  // ein zeichen ist da
}
else
{
  // war leider nix
}
Erhard Henkes
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.04.2000
Beiträge: 14843
Beitrag Erhard Henkes Mitglied 13:11:04 12.04.2009   Titel:              Zitieren

Zitat:
Hat es angesichts der Diskussion über das weitere Vorgehen noch einen Sinn, den jeweils aktuellen Quellcode mal unter die Lupe zu nehmen?

Da gäbe es zwei Aspekte, wo ich Unterstützung/Zustimmung brauchen könnte:

1) Ich habe mal versuchsweise einen Paging/Heap-Mechanismus eingebaut, der aber sehr kompliziert ist, also für den ersten Schritt noch vereinfacht werden sollte, und leider noch nicht funktioniert, habe Testroutinen eingebaut, um zu sehen, wo der Code ausflippt: z.Z. beim Umschalten auf das Paging (wahrscheinlich sind Speicheradressen falsch vorgegeben), echte Tüftelei.
Da könnte sich jemand auf die Dateien ordered_array.h/c, kheap.h/c und paging.h/c konzentrieren und diese aus didaktischen Gründen vereinfachen und in PrettyOS zum Laufen bringen (da beiße ich gerade dran rum und komme nicht wirklich weiter). Ich habe diesen Code mal hochgeschickt, in der Hoffnung, dass mir jemand einen guten Tipp gibt:
http://www.henkessoft.de/ ....... _paging_heap_problems.zip

2) s.u. (Circular Queue: füllen, leeren)

_________________
OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm


Zuletzt bearbeitet von Erhard Henkes am 13:18:27 12.04.2009, insgesamt 1-mal bearbeitet
+fricky
Unregistrierter




Beitrag