Übersicht
Wiki
Hilfe
Suche
Einloggen
Registrieren
1
Lowlevel-Coding / Fragen zum Aufbau eines (Timer-) IRQs
« am: 30. November 2005, 11:23 »
hmmm... taüsch ich mich etwa da? Muss das EOI nich nach behandeln des IRQ gesendet werden ?
20. April 2024, 00:24
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.
2
Lowlevel-Coding / Tastatur LEDs
« am: 01. June 2005, 10:55 »
Kann es sein das du vergessen hast das Acknowledge vom Keyboardcontroller abzufangen ?
3
Lowlevel-Coding / suche floppy tut
« am: 30. May 2005, 13:12 »
Ich denke auch das es von der Programmierung her einfacher sein sollte, bei den anderen Methoden muss man selber auswerten was man jetz aus dem Datenregister ausliest.
4
Lowlevel-Coding / suche floppy tut
« am: 30. May 2005, 13:04 »
Soweit ich weiss gibt`s 3 Arten der Übertragung. DMA übertragung, interrupt-getriebener datenaustausch, und reines polling.
5
Lowlevel-Coding / Eigenes OS in 4 Monaten?
« am: 18. May 2005, 06:54 »
Ich würd dir empfehlen, ne kleine API auf die BIOS-Int`s aufzusetzen, das ist durchaus in 4 Monaten schafbar, und letztendlich macht DOS das nich anders.
Die Frage ist halt nur wie umfangreich die API wird.
Für die Facharbeit würde ich dir dann empfehlen, eher die grundsätzliche Funktion eines OS zu behandeln, und als kleines Bonbon dann deine RM-API vorzustellen.
Mit dem PM solltest du dich in deiner Arbeit nur theoretisch beschäftigen.
In den 4 Monaten kannst du dich halt darauf beschränken die API immer umfangreicher zu machen.
Die Frage ist halt nur wie umfangreich die API wird.
Für die Facharbeit würde ich dir dann empfehlen, eher die grundsätzliche Funktion eines OS zu behandeln, und als kleines Bonbon dann deine RM-API vorzustellen.
Mit dem PM solltest du dich in deiner Arbeit nur theoretisch beschäftigen.
In den 4 Monaten kannst du dich halt darauf beschränken die API immer umfangreicher zu machen.
6
Lowlevel-Coding / KeyboardTreiber
« am: 22. March 2005, 16:43 »
Achja 0xFA steht übrigens für Acknowledge das soll eine Bestätigung sein, das ein befehl ausgeführt wurde bzw. ein datenbyte abgeholt wurde.
7
Lowlevel-Coding / Keyboard: IRQ vs. Nicht IRQ
« am: 22. March 2005, 11:29 »
Du kannst auch einen Mischmasch verwenden, bei der Funktion getche() willst du ja nen Polling erreichen. Also du könntest beim Aufruf dieser Funktion deinen Standart Treiber deaktivieren in dem du Irq 1 maskierst, aber ansonsten würd ich halt ganz normal über die interrupts gehen.
8
Offtopic / Doppelt verkettete Listen in C
« am: 18. March 2005, 23:11 »
Vorsicht Vorsicht !! Nich einfach irgendwelche Adressen setzen ^^.
Also Als erstes element machste erstma nen root Element, die Pointer mit 0 initialisieren..., und dann einfach immer die Elemente durch malloc dran hängen, am besten machst du das inner schleife die 1. immer das vorherige Element merkt und solang die Liste ab der Wurzel unteruscht bis 0 kommt und da dann ein neues Element dranhängt.
Also Als erstes element machste erstma nen root Element, die Pointer mit 0 initialisieren..., und dann einfach immer die Elemente durch malloc dran hängen, am besten machst du das inner schleife die 1. immer das vorherige Element merkt und solang die Liste ab der Wurzel unteruscht bis 0 kommt und da dann ein neues Element dranhängt.
9
Offtopic / Welches OS für einen 286
« am: 24. December 2004, 15:25 »
Jo der Source is auch extra als Lehrmittel ausgelegt, übrigens die zwei Bücher dazu sind sehr zu empfehlen
10
Offtopic / Welches OS für einen 286
« am: 24. December 2004, 13:00 »
Soweit ich weiss schon hatte letztens das Buch von Tannenbaum in der Hand.
11
Lowlevel-Coding / DMA im PM
« am: 22. December 2004, 15:01 »
Jo genau richtig, das Problem ist das is zu jedem DMA Kanal nen Page-Register zugeschaltet wird um über 1MB adressieren zu können, läuft so ähnlich wie die Adressierung im RM. Beim Floppy wird dieses Page-register soweit ich weiss ignoriert
12
Offtopic / Wer ist alles im RM?
« am: 22. December 2004, 13:18 »
Jein mit movsb stosb und kompanen biste definitiv besser beraten wenn du ganze speicher bereiche kopieren willst.
13
Offtopic / Wer ist alles im RM?
« am: 21. December 2004, 15:43 »
Jo meine Meinung Joachim z.B. lügt sich ein wenig um den PM rum. Deinen Ansatz hätte man auch von der anderen Seite sehen können, da es dir ja scheinbar nur um die BIOS-Int`s geht. Du hättest dein MT und Paging im PM realisieren können mithilfe des Prozessors, und nur für die BIOS-Int`s zurückspringen können. Wie gesagt der RM is halt net wirklich für MT und Paging ausgelegt, und deshalb sollte man wenn man das implementiert auch den PM benutzen.
15
Lowlevel-Coding / Deskriptor
« am: 09. December 2004, 10:47 »
Ausserdem würd ich auch das attribut _PACKED_ verwenden denn es könnte sein das er sonst die structs falsch im Speicher anordnet
16
Lowlevel-Coding / Wieder mal ein paar Fragen (PMode, IDT)
« am: 03. December 2004, 00:39 »
Hast du denn ne IDT erstellt ?
17
Lowlevel-Coding / Dateizugriff auf FAT32 Festplatte
« am: 02. December 2004, 08:36 »
ich würd sagen du musst erstma den Festplatten treiber unabhängig von FAT32 coden und da dann FAT32 aufsetzen, hier gibts nen Tut von TeeJay über FAT12 das würd ich mal lesen FAT32 lässt sich daraus gut ableiten
18
Das Wiki / LowlevelOs
« am: 02. December 2004, 08:31 »
Jo vor allem ist es bie mir zum Beispiel so wenn ich sinngemäss was verstehe es aber net selber schreibe mir die übung fehlt
20
OS-Design / Microkernel besser ?
« am: 20. November 2004, 15:33 »
Naja nen Microkernel is halt schwerer zu realisieren...
Ich würde dir vorschlagen nen monolithischen Kernel zu entwerfen..
Was ich für am besten halte is ein Mix aus monolithischen und microkernel.
Linux entwickelt sich auch dahin.
Du musst dir halt folgendes überlegen ein monolithischer Kernel müsste aufjedenfall schneller sein als ein Microkernel weil z.B. die Treiber direkt in den Kernel kompiliert sind und du deshalb kein Interface für sowas implementieren musst was wieder etwas an Perfomance bringt, dafür is ein monolithischer Kernel natürlich sehr unflexibel.
Ich würde dir vorschlagen nen monolithischen Kernel zu entwerfen..
Was ich für am besten halte is ein Mix aus monolithischen und microkernel.
Linux entwickelt sich auch dahin.
Du musst dir halt folgendes überlegen ein monolithischer Kernel müsste aufjedenfall schneller sein als ein Microkernel weil z.B. die Treiber direkt in den Kernel kompiliert sind und du deshalb kein Interface für sowas implementieren musst was wieder etwas an Perfomance bringt, dafür is ein monolithischer Kernel natürlich sehr unflexibel.