Eigenes OS?

Erhard Henkes

..

Nobuo T

;fricky schrieb:

Erhard Henkes schrieb:

Du kennst die ARM-Systeme in 20 Jahren noch nicht, kann genau so enden wie bei x86. Nennt sich Abwärtskompatibilität.

naja, wenn die ARMs nicht mehr mit zusätzlichen befehlen und macrocells erweitert werden können (z.b. die normalen register R0...R15 auf 64 bits aufgebläht werden o.ä. x86-krankheiten), dann ist's wohl auch damit vorbei. *heul*

Tja, keine Architektur lebt ewig. Dann lieber einmal komplett from scratch ueberholen.
Richtig schlimm wird es doch erst, wenn tausend neue obskure Register, krumme OpCodes und irgendwelche (Kompatibilitaets)Modi eingefuehrt werden.

Erhard Henkes

Ich bin noch nicht lange dabei beim OSDEV (genau genommen ernsthaft seit dem 13.03.2009, siehe Beginn dieses Threads), mache es auch nur aus grundlegendem Interesse, spielerischer Neugier und basierend auf dem Wunsch, die Dinge möglichst knapp, bildhaft und vor allem praktisch umsetzbar zu erklären. Denn ich denke, dass die Einstiegshürde relativ hoch ist. Da gehören beim x86 das A20-Gate und der Umstieg von RM nach PM dazu. Mir persönlich ist z.B. das Multitasking schwer gefallen, bis ich eine brauchbare Vorgehensweise bei tyndur fand. Auch das Paging bei x86 hat mich oft durcheinander gebracht. Das Wichtigste beim OSDEV ist, dass man "dran" bleibt. Das ist kein Thema für ein Wochenende, sondern ein mehrjähriges Projekt, also nur etwas für Leute, die sich in etwas "hinein bohren" können und wollen und dann auch nicht los lassen, wenn es zäh und holprig wird.

Wenn man aber über diese Einstiegshürde hinweg ist, dann ist es wie beim Tanzen: Man hat Lust dem eigenen Repertoire ab und zu eine neue Figurabfolge hinzu zu fügen.

Hier z.B. das Lesen von Sektoren von Floppy Disk im Kernel:
http://www.henkessoft.de/OS_Dev/OS_Dev3.htm#mozTocId967150
Diesbezüglich ist mir wichtig, dass ich solche externen Module möglichst einfach an PrettyOS anflanschen kann. Bezüglich IRQ-Interface ist unser Aufbau hier einfacher und damit eleganter, so dass man einiges einfach weglassen konnte.

Ich kann nur hoffen, dass ich mit meinem Tutorial im deutschen Sprachraum etwas dazu beitrage, dass Einsteiger in diese absolut empfehlenswerte Materie schnell praktische Erfolgserlebnisse haben. Das würde mich freuen.

wirst du denn auch versuchen windows und linux konkurrenz zu machen?

Erhard Henkes

Mal eine ganz andere Diskussion: Das Blöde und vielleicht zur Zeit dennoch Gute an Computern ist, dass man sie nicht individualisieren kann. Was müsste passieren, um PrettyOS ein lernfähiges oder zumindest adaptives Interface zum User zu verpassen? Ich denke mal, das gehört in den Bereich Shell / User-Space. Gibt es da schon Beispiele?

Erhard Henkes

wirst du denn auch versuchen windows und linux konkurrenz zu machen?

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

Als Gegenleistung bekommt man in der Regel nur den Genuss der intellektuellen Herausforderung, denn gegen MS Windows, Linux oder andere etablierte OS anzutreten, hat sicher keine Einzelperson vor. Wozu sollte das auch gut sein?

MS Windows ist ein hoch-professionelles OS mit Millionen von Code-Zeilen und Heerscharen von Fulltime-Planern, -Codern, -Testern. Linux, das ich bewundere, aber ungern selbst verwende, schafft es kaum, mit diesem Giganten aus USA mitzuhalten.

Nachdem nun die Grundlagen auf Basis x86 dargestellt wurden, würde es mich reizen, auf der User-Ebene etwas Neues zu schaffen, das in Richtung KI geht. Alleine kann ich allerdings nur Impulse setzen.

Erhard Henkes schrieb:

Linux, das ich bewundere, aber ungern selbst verwende, schafft es kaum, mit diesem Giganten aus USA mitzuhalten.

http://www.top500.org/stats/list/33/osfam

u_ser-l schrieb:

Erhard Henkes schrieb:

Linux, das ich bewundere, aber ungern selbst verwende, schafft es kaum, mit diesem Giganten aus USA mitzuhalten.

http://www.top500.org/stats/list/33/osfam

Das sagt leider rein gar nichts über die Code Qualität des Linux Kernels und die nicht gerade vertrauenserweckenden Praktiken des Maintainerteams (Kindergarten!) aus. Ich bin zwar auch ein Fan von Linux, aber ob der Kernel so gut und objektorientiert ist, wie der von Wind00f, da habe ich meine Zweifel.

Erhard Henkes

Zur Zeit freue ich mich aber noch über jeden kleinen Schritt, z.B. dass es mir gelungen ist, die Floppy-Sektor-Read-Funktion mit einigen Änderungen auch zu einer zusätzlichen Sektor-Write-Funktion umzuwandeln (alles via DMA). Nun habe ich endlich einen zweiten Ausgabekanal neben dem Bildschirm, allerdings noch rein binär.

hack0r schrieb:

Das sagt leider rein gar nichts über die Code Qualität des Linux Kernels und die nicht gerade vertrauenserweckenden Praktiken des Maintainerteams (Kindergarten!) aus.

[Ironie on:]

klar - der durchschnittliche Ottonormal-User ist ja in der Wahl seines OS auch kompetenter als der Architekt von mio. $ teurer Hardware in der Spitzenforschung.

[Ironie off:]

aber ob der Kernel so gut und objektorientiert ist, wie der von Wind00f, da habe ich meine Zweifel.

Ersteres ist hoffentlich ein (schlechter) Witz, und Letzteres ist absolut nicht abzusehen, es sei denn, du verdienst deinen Lebensunterhalt bei jenem mittelständigschem Unternehmen aus Redwood...
Ach kommt, bitte kein Linux vs. Windows Geflame hier. Das Tutorial mal "Linux-kompatibel" zu machen hätte zwar was für sich, aber wenn der Autor nun einmal Windows einsetzt , dann ist das halt so.

Edit:
Sehr richtig. Deshalb werde ich auch alles Weitere in Richtung dieser "Diskussion" loeschen.

Erhard Henkes

Ich habe momentan das Problem, das zwei Sektoren anstelle von einem Sektor geschrieben wird. Wo wird die Zahl der Sektoren bezüglich DMA genau gesteuert?
http://lowlevel.brainsware.org/forum/index.php?topic=2244.0
http://www.henkessoft.de/OS_Dev/Downloads/100.zip
Vielleicht kann jemand helfen? Die Daten werden via DMA gelesen/geschrieben (0x1000 als Puffer).

Erhard Henkes schrieb:

Ich habe momentan das Problem, das zwei Sektoren anstelle von einem Sektor geschrieben wird.

teste die read/write funktionen separat. wird wirklich nur ein sektor (512 bytes) beschrieben und gelesen (benutze ein externes programm, z.b. 'nen disk-editor wie z.b. 'winhex' zur prüfung)?
falls nicht, schau im user manual des DMA-controllers nach. vielleicht transfererierst du 16-bit words anstelle von bytes oder sowas.

Erhard Henkes

..

Erhard Henkes schrieb:

Klappt aber nicht lückenlos. Es werden weniger als 18 Sektoren geschrieben.

Vermutlich ein "Kantenproblem". Folgender Ausdruck :

#define FLPY_SECTORS_PER_TRACK 18

void flpydsk_write_sector_imp(unsigned char head, unsigned char track, unsigned char sector) {
(...)
 flpydsk_send_command( ( ( sector + 1 ) >= FLPY_SECTORS_PER_TRACK ) ? FLPY_SECTORS_PER_TRACK : sector + 1 );
(...)
}

liefert für "sector = 17" und "sector = 18" das gleiche Ergebnis.

Woraus folgt, der Ausdruck unterscheidet nicht zwischen "sector == 17" und "sector == 18". (Und "sector == 1" wird nicht zur Kenntnis genommen).

Erhard Henkes

Ja, genau da liegt der Hase im Pfeffer. Diese Zeile ist nicht zielführend. Wurde von mir durch folgendes ersetzt:

flpydsk_send_command( 18 );

Nun werden 18 Sektoren geschrieben (fkt. auch mit anderen Zahlen), allerdings muss man beim Schreiben genau an einem Track-Anfang (gemäß LBA) beginnen: 0, 18, 36, ...
Ansonsten wird nämlich auch noch dort jeweils geschrieben. Merkwürdiger Effekt.

Erhard Henkes

Nun habe ich das Thema langsam im Griff, durch FDC und DMA nicht ganz übersichtlich. Hier das Analysieren des Stammverzeichnisses einer Diskette:
http://www.henkessoft.de/OS_Dev/OS_Dev3.htm#mozTocId610721
http://www.henkessoft.de/OS_Dev/Downloads/104.rar

Erste Rückmeldungen: Läuft offenbar nicht auf allen PCs, aber in Bochs. Für Tipps wäre ich dankbar.

Hier einige gute Links zu dem Thema:
http://www.isdaman.com/alsos/hardware/fdc/floppy.htm
http://lowlevel.brainsware.org/wiki/index.php/FDC#Data_Address_Mark
http://www.brokenthorn.com/Resources/OSDev20.html
http://www.eit.lth.se/fileadmin/eit/courses/eit015/FAT12Description.pdf

Wenn jemand Lust hat, mich zu unterstützen, würde mich freuen. Es ist jetzt viel Detail-Arbeit angesagt. Ich würde gerne mit engagierten Leuten ohne Zeitdruck eine eigene OS-Community aufbauen:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-247814.html

Ich denke, das Thema OSDEV im leicht fortgeschrittenen Stadium passt nicht mehr richtig in dieses Forum. Die Diskussionen werden unspezifisch. Die anstehenden Aufgaben erfordern Detailwissen über PrettyOS, C, Assembler, Erfahrung mit der Toolchain, konstruktive Kreativität, analytisches Vorgehen, Tiefgang und generell Lust am Thema OS-Development (viel Arbeit, wenig Belohnung).

@Erhard: Erstmal ein für die großartigen Tutorials, sehr interessant und informativ.

Nun habe ich aber folgendes Problem:
Ich versuche zur Zeit einige der Beispiele aus deinem Tutorial auf einem Ubuntu-System über Bochs zum Laufen zu bekommen. Allerdings hagelt es bei mir immer wieder "Boot failed: could not read the boot disk" beim Laden meiner selbstgenerierten MyOS.bin-Datei.
Die nasm-Befehle sind ja praktisch die gleichen wie unter Windows, allerdings verwende ich statt dem copy /b-Befehl ein "cat boot.bin kernel.bin>MyOS.bin". Der Pfad zur OS.bin-Datei ist in der Konfigurationsdatei auch korrekt gesetzt. Die Quelldateien entsprechen 1:1 denen des ersten Beispiels im Protected-Mode-Abschnitt.

Benutze ich das bereits vorgefertigte Sourcepaket(inkl. der MyOS.bin), so gibt es in Bochs keinerlei Probleme beim Booten. Könnte es sein, dass hier der cat-Aufruf das Problem verursacht? Denn beim generieren des allerersten Beispiels, das jediglich aus der Datei kernel.bin bestand, gab es auch noch keinerlei Probleme.

Tobiking2

Ich benutze auch die ganze Zeit Ubuntu und habe keinerlei Probleme gehabt. Allerdings nehme ich QEmu, da der QEmu-Launcher meiner Meinung nach etwas komfortabler ist wenn man öfters mal etwas an den Einstellungen ändert.

Ich hab das mit cat in zwei Befehlen gemacht "cat boot.bin > MyOS" und "cat ckernel.bin >> MyOS" aber sollte auf das gleiche hinauslaufen.

Hi,

das Problem hat sich mittlerweile erledigt. Ich habe beim Aufruf von nasm einfach mal die Option -O32 weggelassen und schon funktionierte es.