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 - Korona

Seiten: 1 2 [3] 4 5
41
OS-Design / Re: Seit langer Zeit...
« am: 10. January 2008, 13:53 »
Du kannst die General Purpose 32Bit Register auch im Rm benutzen, die CPU kennt ein Operand Size Override Prefix (0x66) dafür. Dein Assembler sollte es automatisch einfügen, wenn du im 16 Bit Modus mit 32 Bit Registern hantierst.
42
Offtopic / Re: OS dev Tree
« am: 27. November 2007, 20:59 »
Die Dokumentreihe scheint mir sehr unvollständig. Du gibst zwar einige Hintergrundinformationen, mit denen man allerdings nichts anfangen kann, solange man die offiziellen Spezifikationen nicht gelesen hat. Die Dokumentreihe sieht eher aus wie ein Schnupperkurs durch verschiedene Hardware und Softwarekomponenten, bietet aber keine tieferen Einblicke in die Materie. Als Referenz oder Tutorial versagt die Dokumentreihe, wenn ich einen Treiber für einen USB Host oder ein USB Device schreiben will bringt mir die Dokumentreihe gar nichts. Sie vermittelt einfach nur ein paar zusammenhangslose Informationen die zwar interessant für jemanden sein mögen, der sich mit dem Thema nicht befassen möchte, aber sonst nicht zu gebrauchen sind, schon allein deswegen, dass die Themen nicht gründlich behandelt werden und nur Bruchstücke aus einem Thema herausgerissen werden.
43
Offtopic / Re: OS dev Tree
« am: 27. November 2007, 20:34 »
Ich würde das Programm nie einem PDF oder einer Website vorziehen. (Schon allein deshalb weil ich mir das PDF ausdrucken kann) Das Programm nutzen könnte ich jedoch sowieso nicht, da es nur für Windows verfügbar ist.
Die Devices die du aufzählst sind außerdem nicht besonders interessant, man findet im Internet massig Informationen. Interessant wären Infos über kompliziertere Themen: ACPI, PCI/PCIe, USB oder EFI. Wenn ich für so ein Programm zahlen müsste, würde ich mich fragen, ob ich mit den offiziellen Spezifikationen nicht mehr anfangen kann, als mit einem auf relativ grundlegende Geräte ausgelegten und im Inhalt unvollständigen Programm. Die meisten Informationen über die von dir aufgezählten Devices erhalte ich in weitaus ausführlicherer Form aus frei zugänglichen Intel und AMD Manuals (PIC, PIT, FDC, CPU, APM etc.) oder aus anderen Spezifikationen (ATA). Ich sehe einfach nicht den Nutzen des Programms gegenüber einer Website bzw. gegenüber google oder bereits bestehenden OS-Dev Seiten.
44
Lowlevel-Coding / Re: Funktionen Portieren
« am: 20. November 2007, 22:02 »
Imho ist x86 Assembler nicht besonders kompliziert. Es ist kompliziert ein "ganzes Programm" darin zu schreiben, aber die Instruktionen sind nicht besonders schwer zu verstehen. Du musst wissen, welche Register du zur Verfügung hast, welche Instruktionen es gibt und wie du auf die Hardware oder auf Betriebssystem/BIOS Funktionen zugreifen kannst.

An Registern wären da die GPRs (General Purpose Registers) EAX, EBX, ECX, EDX, ESI und EDI zu nennen, welche wie der Name schon sagt "normale" Daten (Integer, jedoch keine Fließkommazahlen oder spezielle Flags) enthalten. Sie werden durch Instruktionen wie MOV, ADD, SUB etc. manipuliert. Die meisten Instruktionen können neben Registern auch auf Speicheraddressen in der Form [basis + index * scale + disp] zugreifen, wobei basis und index GPRs sind, scale entweder 0, 1, 2 oder 4 ist und disp eine Integerkonstante ist.

Bespiel:
mov eax, [ebx + ecx * 4 + 1024]

Hier wird zuerst ebx + ecx * 4 + 1024 berechnet und der 32 Bit Wert der bei dieser Addresse steht in eax geschrieben. Die [ ] markieren in NASM Speicherzugriffe. Da wir im 32 Bit Protected Mode sind manipuliert die Instruktion standardmässig 32 Bit Daten.

Um auf die Hardware zuzugreifen werden die Instruktionen "IN" bzw. "OUT" benutzt. Manche Hardwarekomponenten lassen sich auch über bestimmte Speicherbereiche direkt ansprechen. (Beispiel: Der Framebuffer der VGA Karte im Textmodus liegt bei Speicheraddresse 0xB8000. Das OS kann einfach mit "mov [0xB8000], irgentwas" auf die VGA Karte zugreifen.

Das BIOS wirst du im Realmode auf jeden Fall brauchen, auch wenn du so schnell wie möglich in den PM (Protected Mode) schalten möchtest (weil du nur dort vernünftig mit C++ arbeiten kannst und genügend Speicher zur Verfügung hast). Verwende GRUB als Bootloader um unnötige Assemblerprogrammierung zu umgehen. Falls du deinen Bootloader dennoch selber schreiben möchtest, musst du auf BIOS Funktionen zurückgreifen. Sie werden fast immer über Interrupts aufgerufen. (=> "INT" Instruktion)

Ansonsten solltest du dir einfach mal einen kleinen C/C++ Kernel ansehen, der bereits Interrupts und Schreiben von Buchstaben auf den Screen unterstützt. Ich habe meine Assembler Grundlagen hauptsächlich durch das Lesen von Beispielcode erlernt. Wenn du in C/C++ schreibst wirst du Assembler nur für die Kommunikation mit der Hardware und für einige Funktionenstubs brauchen, die spezielle Prolog und Epilog Sequenzen haben müssen. (Interrupthandler müssen mit IRET statt normalem RET zum Caller zurückkehren, außerdem müssen sie oft auch alle Register sichern, damit der Caller nicht eine veränderte Situation vorfindet etc. für fast alles andere kommst du mit einigen Zeilen Inlineassembler in deinem Code aus.)

Wenn du wirklich ein ASM Tutorial brauchst, kannst du dir das hier ansehen:
http://maven.smith.edu/~thiebaut/ArtOfAssembly/artofasm.html

Eine Referenz aller BIOS-Interrupts gibts hier:
http://www.ctyme.com/intr/int.htm

Das NASM Manual weiß alles über die Syntax von NASM und enthält sogar eine Instruction-Referenz:
http://alien.dowling.edu/~rohit/nasmdoc0.html

Ansonsten steht alles wissenswerte in den Intel und AMD Docs, für die ich aber gerade keinen Link habe.
45
Du wirst wohl SMP Unterstützung brauchen, um beide Core benutzen zu können. Andere Möglichkeiten beide Cores zu nutzen gibt es AFAIK nicht, oder?
46
Offtopic / Re: IOPL, bochs -> was bedeutet das?
« am: 12. October 2007, 15:09 »
Stimmt, es sind nur EFLAGS Flags. Ich hatte irgentwie im Kopf das VIP und VIF Flag wären Teil von CR4.^^
47
Offtopic / Re: IOPL, bochs -> was bedeutet das?
« am: 11. October 2007, 15:18 »
Das sind Flags der EFLAGS, CR0 und CR4 Register, ihre Bedeutung kannst du in den Intel oder AMD Manuals nachlesen.
48
OS-Design / Re: CD + Fetplatte!
« am: 12. September 2007, 18:19 »
Du kannst verschiedene Dateisysteme integrieren, du musst dich nicht auf ein bestimmtes Dateisystem festlegen. Du kannst so viele implementieren wie du willst / Zeit hast.
Ob du Dateien auf eine Partition eines anderen Os schreibst oder nicht ist dir auch freigestellt, das Design deines Os liegt weitgehend in deinen Händen, du kannst implementieren was du möchtest. Wenn das Os erstmal einigermaßen stabil läuft wirst du warscheinlich ein Tools zum Partitionieren basteln wollen, damit du eigene Partionen erstellen kannst. Dafür sollte dein Kernel aber erstmal Speicher und Prozesse verwalten können, das Dateisystem brauchst du erst, wenn du die Grundlegenden Funktionen fertiggestellt hast.
49
OS-Design / Re: CD + Fetplatte!
« am: 12. September 2007, 17:28 »
Damit du auf die Festplatte schreiben kannst, brauchst du sowohl einen Festplattentreiber, mit dem du einzelne Sektoren (512 Byte Abschnitte der Platte) lesen kannst. Darauf aufbauend brauchst du dann Treiber für das Dateisystem, das du benutzen willst. Wenn du Linux benutzt, wäre Ext2 vorteilhaft, für Windows wäre Fat geeignet.
50
Als Editor benutze ich jEdit (in Java geschrieben, lässt sich leicht auf mein Os portieren, das auf einer Vm basiert und auch sonst ein sehr guter Editor), C verwende ich in meinem Os nicht, der Kernel ist in einer eigenen Programmiersprache geschrieben. Als Assembler benutze ich im Moment YASM, da NASM relative Relokationen nur mit Jump Instructions und nicht in der Form
dd address - $ unterstützt :/.
51
Die meisten Os benutzen einen Systemcall, der mehr Pages in das aktuelle PD/in den aktuellen Prozess mappt. malloc() speichert in Listen, Trees oder anderen Strukturen welche Speicherbereiche frei sind, wenn keine mehr frei sind ruft malloc() diesen Systemcall auf, bei Unix kompatibeln System wäre das brk(), sbrk(), mmap() oder morecore(). Der Systemcall sucht sich dann eine freie physikalische Page, mappt sie irgentwo in das PD, setzt das Present-Bit und gibt einen Pointer auf sie zurück.
52
Lowlevel-Coding / Re: DS,SI,ES und DI-Probleme
« am: 26. July 2007, 16:20 »
SI kann auch bei Strings überlaufen die kürzer als 2^16 Bytes sind, falls der String nicht am Segmentanfang beginnt.

Ich versteh deine Funktion nicht ganz. Was soll z.B. die 5. Zeile bewirken? Du schreibst die Segmentaddresse von DS nach SI, DS:SI ist danach doch eine vollkommen unsinnige Addresse?!

Du könntest das Problem z.B. mit String-Instructions lösen:
; DS:SI = Quellstring
; ES:DI = Zielstring
; CX = Stringlänge (mit Nullbyte)

add di, cx
dec di

copy:
cld
lodsb ; byte lesen
std
stosb ; byte schreiben
loop copy ; cx mal wiederholen

ret

Oder etwa so ohne:
add di, cx

copy:
dec di
mov al, [ds:si]
mov [es:di], al
inc si
loop copy
ret

Wozu fügst du die Null-Bytes am Ende der Strings ein? Enthällt der Quellstring kein Nullbyte? Meine Funktionen oben könntest du natürlich auch so ändern, dass sie das Nullbyte am Ende einfügen (vermeidet ja einen Speicherzugriff *gg*), etwa mit
xor al, al
stosb.
53
Lowlevel-Coding / Re: FDCs und Floppy Drives erkennen
« am: 14. July 2007, 16:00 »
Im Moment noch nicht, dazu ist es noch etwas zu früh^^.
Ich werd ein SVN bereitstellen, wenn man einige einfache Anwendungen ausführen kann =).
54
Lowlevel-Coding / Re: Nach Laden > Reboot
« am: 14. July 2007, 15:59 »
Diese Nachricht kommt von GRUB und nicht von deinem Kernel. Du kannst einfach alle Zeichen auf dem Bildschrim mit Leerzeichen überschreiben oder die Farb-Attribute so setzten, dass man den Text nicht sieht.
55
Lowlevel-Coding / Re: FDCs und Floppy Drives erkennen
« am: 13. July 2007, 21:03 »
Einfach mal was hinsenden und versuchen etwas sinnvolles zu kriegen hatte ich mir schon gedacht, es hätte ja sein können, dass es einen speziellen Befehl dafür gibt.

@M.Nemo
Ja, stimmt, ich hab mich wohl vertippt. ^^
56
Lowlevel-Coding / FDCs und Floppy Drives erkennen
« am: 10. July 2007, 15:20 »
Hi,
ich bastel gerade an einem Floppy Treiber rum, und würde gerne erkennen können, was für FDCs installiert sind. Afaik kann es ja zwei FDCs geben, einen mit Port 0x1F0 und einen mit 0x170. Wie kann ich erkennen ob sie vorhanden sind und was für Floppy Laufwerke an den Controllern hängen (ohne das CMOS abzufragen)?
mfg Korona
57
Lowlevel-Coding / Re: Sektoren lesen dauert so lange
« am: 21. June 2007, 17:56 »
ATA/ATAPI benutzt nicht den 8237 DMA Chip wie der FDC sondern andere Chips. (Ultra DMA etc.)
58
Lowlevel-Coding / Re: Sektoren lesen dauert so lange
« am: 21. June 2007, 10:56 »
Wie ließt du denn die Sektoren? DMA, direkter Portzugriff? Direkte Portzugriffe sind schneller als der DMA allerdings werden dadurch sehr viele IRQs aufgerufen (für jedes Byte iirc), was die Performance von Multitasking Systemen schlecht beeinflusst. (In heutigen Systemen mit 3+ ghz wird das aber wsl. fast keinen Unterschied machen)
59
Lowlevel-Coding / Re: Verwirrt durch Interrupts
« am: 01. June 2007, 10:27 »
Afaik wird
dw label ; und
dw (label >> 16)
zumindest in NASM nicht funktionieren. (die Addresse von label wird erst durch den Linker bestimmt und kann daher nicht Teil eines Ausdrucks sein. Eventuell funkioniert der Code wenn du zu einer flachen Binary kompilierst, NASM überträgt zwischen seinen Stages aber normalerweise nur wenig Informationen, daher funzt das afaik auch nicht.)

Die beste Lösung ist wie Bluecode gesagt hat:
mov eax, label
mov [blabla], ax
shr eax, 16
mov [blabla2], ax
60
Lowlevel-Coding / Re: Probleme mit Variablen
« am: 20. May 2007, 11:35 »
Wenn du ihn zu einer bin assemblierst muss oben
org 0x10000Wobei du 0x10000 durch die Addresse ersetzten musst, wo der Code hingeladen wird.
Seiten: 1 2 [3] 4 5

Einloggen