Beiträge anzeigen

Diese Sektion erlaubt es dir alle Beiträge dieses Mitglieds zu sehen. Beachte, dass du nur solche Beiträge sehen kannst, zu denen du auch Zugriffsrechte hast.


Nachrichten - babyrabbit

Seiten: [1]
1
OS-Design / Re: Wie geht ihr an die Entwicklung eures OS heran?
« am: 26. December 2011, 21:10 »
Erstmal Frohe Weihnachten im Nachhinein!
Danke für die vielen Inspirationen :)

Deswegen direkt mit dem OS anfangen und sich nicht auf Nebenkriegsschauplätzen verlieren. Wenn man wirklich will, kann man den eigenen Bootloader noch machen, wenn das OS funktioniert.
Find ich gut! Also werd ich mich mal in GRUB einarbeiten, um dann mein Projekt endlich ordentlich beginnen zu können.

Am einfachsten und performantesten ist natürlich Assembler, weil man hier alles optimieren kann. Der eigene geschriebene Bootloader darf natürlich auch nicht fehlen wie das eigene Dateisystem und die Shell im Kernel - hochperformant und super schnell.
Das ist dann mein vorletztes Ziel :D Wobei mir da wieder die Frage im Kopf herumschwirrt: GUI auf Shell aufsetzen oder direkt auf den Kernel?
In der Planung würd ich mich spontan eher für zweiteres entscheiden.

Als persönliche Königsdisziplin will ich das ganze noch in einer eigenen Programmiersprache umsetzen :-P
Ich weiß dass sich das nicht in 30 Jahren ausgehen wird, aber ich bleib optimistisch.

Aber eins muss es immer machen: Spaß :) Wenn du Stunden um Stunden für das perfekte Design verbringst und dir den Kopf zermaterst über das einzig wahre und perfekte Design ohne bislang eine Zeile Code zu schreiben machst du in meinen Augen etwas falsch.
Definitiv ist meine Entwicklung festgefahren, weil ich mich zu sehr auf den "perfekten" Bootloader konzentriert habe.

ich persönlich bevorzuge TOP-DOWN. Ich entwickle erst mal eine grobe Idee was ich eigentlich erreichen möchte, danach zerlege ich die sich ergebenen Probleme in ihre Teile und fange dann für jedes einzelne Teil-Problem von vorne an. Das klingt aufwendig und das ist es auch aber es ist IMHO die einzigste Methode mit der man wirklich ein gutes Ergebnis erreichen kann.
Das "gute" Ergebnis ist nach meinen Erfahrungen nur logisch gut.
Wenn man die Hardware-Spezifikationen und die Optimierungshintertürchen kennt, kann man das bei der Planung berücksichtigen und gleich ein physisch gutes Ergebnis erzielen.

Auf jeden Fall kostet eine sauber strukturierte Vorgehensweise einiges an Disziplin und Zeit aber ich behaupte das man mit der chaotischen Variante, erst mal Code tippen und dann hinterher herausfinden was nicht stimmt, für das selbe Ergebnis in Summe mehr Zeit aufwenden muss (wegen den vielen Fehlschlägen) und letztendlich doch von oben nach unten plant (nur merkt man das dann nicht so deutlich weil es iterativ und eben als chaotischer Prozess passiert).
Zeit ist bei mir rar geworden :/
Wenn ich ein kleines Java-Tool schreibe, dann überleg ich mir on-the-fly das passende Design von oben herab - bei kleinen Programmen mag das funktionieren, aber sobald es über 3K Zeilen hinausgeht steigt die Schwierigkeit, alle Details im Kopf zu behalten.
2
OS-Design / Wie geht ihr an die Entwicklung eures OS heran?
« am: 19. December 2011, 00:12 »
Bis jetzt bin ich über den Bootloader nicht wirklich hinausgekommen - ich habe einfach zu wenig Zeit neben der Arbeit.
In den letzten Tagen beschäftigt mich aber dennoch ein paar Fragen:

Wo beginnt man?
=> TOP-DOWN oder BOTTOM-UP

Designed man zuerst das was man als Endergebnis erwartet (das was man später mit dem OS machen kann) oder entwickelt man zuerst den Bootloader, etc. bis ins kleinste Detail?
Setzt man auf "Objektorientierung" oder rein prozeduralen Code?

Mehrere Wege führen ans Ziel, doch welcher Weg ist einfacher, besser, performanter?

LG
3
deine ORG 0x07C0 passt auf keines von beiden.

Wow herzlichen Dank!!
Und wieder so ein "einfacher" Fehler, der Wochen lang nicht entdeckt wurde  :roll: :-D

Hab das jetzt so abgeändert:
ORG 0x7C00
JMP 0x0000:stage1.start ; CS:IP -> 0x0000:(0x7C00+x)

%include "bpb.asi"
%include "io.asi"

stage1:
;Festlegen des Stacks und Initialisierung der Register
.start:
MOV AX, 07C0h + 544
CLI
MOV SS, AX
MOV SP, 0x1000
MOV BP, SP
STI

Ist die 2. Zeile praktisch gesehen dann eh das was du meintest mit dem setCS_IP?
Es haut jetzt so jedenfalls hin.

Und auch ein Danke für den Lesbarkeits-Tipp!

Wahrscheinlich weil ich mit den vom Assembler berechneten Adressen im Bereich 0x0500 - 0x7BFF (unused) war, kamen nur Nullen (ASCII 0x00).
4
Moin ^^

Wenn ich keinen Stack verwende und die Farbwerte manuell nach BX vor dem Call schreibe funktionierts und es ist schön bunt.
Sobald die Parameter aber über den Stack gehen setzt es in der Stage1 aus.

Du nutzt ja ein Macro um die Parameter auf den Stack zu pushen, wenn ich das richtig verstehe ist der erste Parameter derSstring und der zweite die Farbe.
f_print fd_read, 0x0009
Im stage2 nutzt du bei dem Text der ausgegeben wird 0x000F eventuell liegts daran das du nur den Text sehen kannst?
Ja, mit einem Makro - richtig. Das find ich persönlich besser vom Handling, weil man nur 1x den korrekten Funktionsaufruf inkl. Stack-Operationen programmieren muss.
Mit der Farbe hat das aber nichts zu tun, sonst würde der Text von der Stage2 nicht ganz links oben erscheinen.


Folgendes kann ich als Fehlerquelle definitiv ausschließen:
  • Parameter String(adresse) bzw. Farbe
  • Unterprogramm "setVideomode"

Ich hab mir schon überlegt, ob es nicht sein kann, dass nach dem Initialisieren des Stacks irgendwas geflusht werden muss, damit es auch übernommen wird (ähnlich wie beim far jump zum P-Mode Code? <- wenn ich das richtig verstanden hab)
Gibts da irgendwelche Befehle?


DEBUG-STUFF
rax: 0x00000000:00000e00 rcx: 0x00000000:00000000
rdx: 0x00000000:00000000 rbx: 0x00000000:00000000
rsp: 0x00000000:00000ff4 rbp: 0x00000000:00000ffa
rsi: 0x00000000:000e08ad rdi: 0x00000000:0000ffac
r8 : 0x00000000:00000000 r9 : 0x00000000:00000000
r10: 0x00000000:00000000 r11: 0x00000000:00000000
r12: 0x00000000:00000000 r13: 0x00000000:00000000
r14: 0x00000000:00000000 r15: 0x00000000:00000000
rip: 0x00000000:00007c58
eflags 0x00000046: id vip vif ac vm rf nt IOPL=0 of df if tf sf ZF af PF cf


Stack address size 2
 | STACK 0xadf4 [0x0ff6] TEST: aktueller SP gepusht
 | STACK 0xadf6 [0x09e0] TEST: SS gepusht
 | STACK 0xadf8 [0x0ffa] TEST: neuer BP (= alter SP) gepusht
 | STACK 0xadfa [0x1000] alter BP / 1. Zeile im Unterprogramm
 | STACK 0xadfc [0x7c85] BP+2 > Rücksprung
 | STACK 0xadfe [0x0007] BP+4 > Param1: Lightgray
 | STACK 0xae00 [0x0000] >>> ANFANG <<<

-------------------------------------------------------------------------------------------
__TESTWERTE__
SS:SP = 0xadf6 > SP=0x0ff4 OK. (SUB SP 2) kommt erst nach dem PUSH (siehe RSP)
SS:BP = 0xadfa OK.
SS:SP_alt = 0xadfa OK.
SS:BP_alt = 0xae00 OK.
-------------------------------------------------------------------------------------------

Der Stack ist also auch nicht das Problem, wenn die Werte korrekt draufliegen.

... ich, wie sehr wahrscheinlich gleich auch noch mehrere andere, rate dir dazu Grub zu benutzen.
von GRUB bin ich keinesfalls abgeneigt :)
ich möchte nur mal schauen, wei weit ich selber komme - zwecks Verständnis undso ;)

Greets
5
Hallo!

Ich hab mich jetzt auch hier registriert, da ich mich ernsthaft mit der Entwicklung eines OS beschäftigen will.
Tutorials hab ich schon ein paar durchgearbeitet und verstehe in etwa die grundlegenden Dinge, die für die Programmierung eines Bootloaders erforderlich sind.

Also der grundsätzliche Ablauf in meinem Fall:

Stage1: (Bootsektor)
  • ok: Stack einrichten
  • fail: verschiedene Meldungen ausgeben
  • ok: Stage2 von Floppy laden (liegt roh im 2. Sektor, ist noch nicht größer als 512 Bytes)
  • ok: zu Stage2 springen

Stage2:
  • versch. Meldungen ausgeben
  • in den Protected Mode schalten (kommt erst später)

Während Stage1 abgearbeitet wird erscheint keine Meldung auf dem Schirm - ab Stage2 arbeitet die Ausgabefunktion / der Stack korrekt so wie es sein soll. :?

*edit:
Tools: NASM und Bochs 2.4.6
Auch in Boch 2.4.5 war das Problem bereits sowie auf einem alten P4-System mit Floppy-Laufwerk.




Der Stage1-Loader:
[BITS 16]
ORG 07C0h
JMP stage1.start

%include "bpb.asi"
%include "io.asi"

stage1:
;Festlegen des Stacks und Initialisierung der Register
.start:
MOV AX, 07C0h
ADD AX, 544
CLI
MOV SS, AX
MOV SP, 0x1000
MOV BP, SP
STI
XOR AX, AX
MOV DS, AX
MOV ES, AX
MOV [boot_drv], DL

.main:
CALL setVideomode
f_print boot_msg, 0x0007

f_print fd_reset, 0x0009
.reset:
MOV AH, 00h
MOV DL, [boot_drv]
INT 13h
JC .reset
f_print boot_ok, 0x000A

f_print fd_read, 0x0009
.read:
MOV AX, 0x100
MOV ES, AX
XOR BX, BX

MOV AH, 02h
MOV AL, 1
MOV CH, 0
MOV CL, 2
MOV DH, 0
MOV DL, [boot_drv]
INT 0x13
CMP AL, 0
JC .read

.end:
f_print boot_ok, 0x000A
JMP 0x100:0

boot_drv DB 0
boot_msg DB "booting stage1...",13,10,0
boot_ok  DB "OK",13,10,0
boot_ko  DB "FAIL",13,10,0
fd_reset DB 9,"Drive reset:",9,0
fd_read  DB 9,"Drive read: ",9,0
TIMES 510-($-$$) DB 0
DB 0x55
DB 0xAA

Die Ausgabefunktion wird von Stage1 und Stage2 verwendet:
%macro f_print 2
PUSH word %2 ;color
MOV SI, %1 ;string
CALL print
ADD SP, 2
%endmacro

print:
PUSH BP ; -> alten BASE-POINTER sichern
MOV BP, SP ; -> BASE-POINTER auf den aktuellen STACK-POINTER setzen

MOV AH, 0Eh
.next:
LODSB
OR AL, AL
JZ .end
MOV BX, [SS:BP+4] ; Zugriff auf 1. Parameter
INT 10h
JMP .next
.end:
MOV SP, BP ; <- alten STACK-POINTER wiederherstellen (siehe oben: BP = alter SP)
POP BP ; <- alten BASE-POINTER wiederherstellen
RET

aus Stage2:
[BITS 16]
ORG 0x1000
JMP stage2.start

%include "io.asi"
%include "gdt.asi"

stage2:
.start:
f_print boots2_msg, 0x000F
CLI
HLT



Anmerkung: Ich verwende die Endung *.asi für "ASsembler Include". :wink:
"bpb.asi" enthält den BIOS-Parameter-Block


Ich hab schon unzählige Versuche unternommen, das Stacksegment und den -Pointer anders zu initialisieren, doch es bleibt immer wieder der selbe "Fehler".
Es scheint so, als ob in BX durch MOV BX, [SS:BP+4] nichts reingeschrieben werden kann bzw. aus irgendeinem Grund der Wert im Register immer 0x0 ist / wird / bleibt.
==> Nur der Text booting stage2... (in Weiß) wird ausgegeben


Hat von euch jemand einen Lösungsvorschlag für das Problem?


Greets
Seiten: [1]

Einloggen