Projekt: OS-Development

• C

  BIOS zurücksetzen
  • Cuervo  

  5
  0
  Stimmen
  5
  Beiträge
  4288
  Aufrufe

  A

  http://www.memtest.org/
• M

  Konvention: Laufwerkskennzeichnung, Dateipfade
  • Mr X  

  26
  0
  Stimmen
  26
  Beiträge
  47367
  Aufrufe

  E

  Es läuft inzwischen. Als klassischer Windows-User finde ich es bisher ganz brauchbar.
• E

  usbStick mit FAT12 formatieren
  • Erhard Henkes  

  7
  0
  Stimmen
  7
  Beiträge
  10646
  Aufrufe

  E

  Interessant!
• E

  Master Boot Record (MBR)
  • Erhard Henkes  

  2
  0
  Stimmen
  2
  Beiträge
  2359
  Aufrufe

  A

  Es gibt von Microsoft ein Dokument: FAT32 File System Specification. Man muss hier ein "License agreement" akzeptieren: http://www.microsoft.com/whdc/system/platform/firmware/fatgen.mspx und dann kommt man auf eine Seite, wo man ganz rechts im Kleingedruckten, damit man es leicht übersieht, eine doc-Datei herunterladen kann. Ich kann die Datei grad nicht öffnen, aber ich erinnere mich, dort werden alle Strukturen genau beschrieben, auch die von Boot Sector. Vielleicht hilft es weiter...
• R

  Fehlerhaftes malloc
  • Ramsis  

  4
  0
  Stimmen
  4
  Beiträge
  2701
  Aufrufe

  E

  darf der heap auch über dem stack liegen? ^^ wäre das eine Lösung? #ifndef KHEAP_H #define KHEAP_H #include "os.h" //// Memory configuration //// // BE AWARE, THE MEMORY MANAGEMENT CODE STILL HAS SOME HARDCODED // ADDRESSES, SO DO NOT CHANGE THESE ONES HERE! // Where the kernel's private data is stored (virtual addresses) #define KERNEL_DATA_START ((uint8_t*)0x0C0000000) // 3 GB #define KERNEL_DATA_END ((uint8_t*)0x100000000) // 4 GB // PCI/EHCI memory location for MMIO #define PCI_MEM_START ((uint8_t*)0x0FF000000) #define PCI_MEM_END ((uint8_t*)0x100000000) // 4 GB // Virtual adress area for the kernel heap #define KERNEL_HEAP_START KERNEL_DATA_START #define KERNEL_HEAP_END PCI_MEM_START #define KERNEL_HEAP_SIZE ((uint8_t*)((uintptr_t)KERNEL_HEAP_END - (uintptr_t)KERNEL_HEAP_START)) // Placement allocation #define PLACEMENT_BEGIN ((uint8_t*)0x1000000) // 16 MB #define PLACEMENT_END ((uint8_t*)0x1400000) // 20 MB // User Heap management #define USER_HEAP_START ((uint8_t*)0x1420000) // 20 MB plus 128 KB #define USER_HEAP_END ((uint8_t*)(KERNEL_DATA_START - 0x1000000)) // 3 GB minus 16 MB // User Stack #define USER_STACK 0x1420000
• S

  Pixel output mit PrettyOS
  • Scarabol  

  7
  0
  Stimmen
  7
  Beiträge
  2630
  Aufrufe

  E

  @Scarabol: Kannst Du bitte etwas ausführlicher darstellen, was bei dir funktioniert und dich erfreut?
• D

  "jmp $" ?
  • DerRatlose  

  11
  0
  Stimmen
  11
  Beiträge
  30042
  Aufrufe

  A

  Mr X schrieb: Man kann es auch einfach weglassen: Wenn was schiefgelaufen ist, das den ganzen Kernel zum Absturz bringt, dann ists wohl egal, was wir danach machen, denn das Interessiert dann wohl kaum, da das OS abgeschossen ist und ein Reboot unumgänglich ist. ... Genau, man hat ja sonst keine Verantwortung auf der Kernel-Ebene, im Ring 0
• A

  Kurze Frage zu Headerdateien
  • Andyman  

  6
  0
  Stimmen
  6
  Beiträge
  2345
  Aufrufe

  A

  Danke werde das mal durcharbeiten
• N

  pci.c z.155 die rückgabe von pci_config_read() ist doch ein uint32_t?
  • noob_lolo  

  20
  0
  Stimmen
  20
  Beiträge
  32021
  Aufrufe

  T

  Ich hab das grad mal ausprobiert mit Splint und das kommt gar nicht durch den Code durch. Es stößt sich erst an den va_args builtins von gcc. Danach scheint es an jeder Stelle, wo "void* variablenname = ..." nicht am Anfang einer Funktion steht, mit einem parse error zu stoppen.
• N

  maus treiber 0xFA ack nach mouse_write
  • noob_lolo  

  7
  0
  Stimmen
  7
  Beiträge
  3052
  Aufrufe

  C

  so, Ausgabe war verschoben! http://c-plusplus.net/forum/viewtopic-var-p-is-1884501.html#1884501
• N

  debug messages in ein macro auslagern
  • noob_lolo  

  17
  0
  Stimmen
  17
  Beiträge
  31746
  Aufrufe

  V

  Mr X schrieb: Dann könnten wir vlt. besser eine inline-Fkt. nehmen... Sogar outline. Aber das isses gar nicht mehr so kompliziert. #ifdef _DIAGNOSIS_ #define kdebug(...) kdebugfunc(__VA_ARGS__) #else #define kdebug(...) ((void(4711)) #endif
• N

  bit operationen in architektur spezifische datei auslagern
  • noob_lolo  

  1
  0
  Stimmen
  1
  Beiträge
  2494
  Aufrufe

  N

  hätte eine kleine frage zu der paging.c, in dieser sind die meisten bit operationen in c programmiert. da architekturen (x86) dafür extra assembler befehle anbieten könnte man die in separate inline functionen auslagern welche dann geg. für verschiedene architekturen ausgetauscht werden könnten. evtl. hält man noch eine fallback version in c bereit 202 // Find the number of a free bit 203 uint32_t val = bittable[first_free_dword]; 204 uint32_t bitnr = 0; 205 while (val & 1) 206 val>>=1, ++bitnr; evtl. ist da etwas brauchbares dabei http://lxr.free-electrons.com/source/arch/x86/include/asm/bitops.h#L355 lg lolo
• E

  Grundsatzdiskussionen zu C
  • Erhard Henkes  

  21
  0
  Stimmen
  21
  Beiträge
  45412
  Aufrufe

  M

  Wir haben uns ja inzwischen auch im IRC geeinigt, einfaches return als legitim anzusehen. Daher ist dieser "Streitpunkt" auch geklärt (Zum Glück mit dem Ergebnis "Pro-Return")
• E

  Funktion ftoa - Rundungsproblem
  • Erhard Henkes  

  4
  0
  Stimmen
  4
  Beiträge
  5044
  Aufrufe

  T

  Ich hatte im IRC ja schon geschrieben gehabt, dass man floats nicht mit höherer Genauigkeit ausgeben kann als sie im Speicher liegen. Um "schönere" Ausgaben zu kriegen kann man natürlich nach 6 Stellen abschneiden oder runden. Dabei dürfte allerdings im Allgemeinen die Abweichung ansteigen. Und wenn man mit den Zahlen weiterrechnen will, dann interessiert einen meistens die genaue Zahl im Speicher und keine gerundeter Wert.
• N

  frage gdt.c:28 / gdt.c:42-45
  • noob_lolo  

  2
  0
  Stimmen
  2
  Beiträge
  1652
  Aufrufe

  E

  ist berechtigt der einwand, kann weg.
• C

  Grafikkonzept
  • Cuervo  

  12
  0
  Stimmen
  12
  Beiträge
  30037
  Aufrufe

  N

  Aehm, ich will euch ja nicht den Spass verderben, aber waere es nicht vielleicht hilfreicher, zumindest die Feature-Listen auf den ersten 20 Seiten der VBE3-Spezifikation zu ueberfliegen, bevor ihr weiter im Nebel stochert und anfangt wild an irgendwelchen Riesenprojekten herumzuklempnern? Achtung, Spoiler: Mit der VBE kann man sehr wohl Hardware Double Buffering verwenden - AFAIR sogar wenigstens seit Version 2. Seit Version 3 sogar Tripple Buffering mit Hardware-Unterstuetzung und noch vieles mehr. Fuer die Basics ist das allemal ausreichend. Zudem ist die VBE 3 AFAIR wenigstens seit den 4er AGP-Karten selbst in jeder noch so billigen PC-Graka implementiert. Dabei wird allerdings nichts umkopiert, sondern der Einfachheit halber die Startadresse des Frame Buffers verschoben. Ich wuerde euch raten, zunaechst mal ein wirklich durchdachtes Konzept mit hinreichend genauer Spezifikation der Anforderungen, mehreren Loesungsansaetzen und Schnittstellen zu entwickeln, bevor ihr euch im Kleinklein irgendwelcher Hardwarebeschleunigung verliert. Sonst koennt ihr es auch bei kleinen Hardwaredemos belassen.
• C

  Tools für OS Development
  • Cuervo  

  4
  0
  Stimmen
  4
  Beiträge
  1933
  Aufrufe

  C

  v1.2 mit experimentellem MIDI-Support ist raus Update: v1.3 mit neuer Updatefunktion und Beep-Vorschau ist raus
• E

  Ideen für das "Projektmanagement"
  • Erhard Henkes  

  12
  0
  Stimmen
  12
  Beiträge
  31327
  Aufrufe

  M

  Ich werde dort nun auch die aktuellste Todo-Liste (im IRC besprochen) einpflegen.
• C

  PrettyOS Dokumentation
  • Cuervo  

  20
  0
  Stimmen
  20
  Beiträge
  31235
  Aufrufe

  E

  Meiner Meinung nach sollte das Erstellen der Dokumentation halt automatisch funktionieren, damit da niemand ständig hinterherrennen muss und die Dokumentation anpasst. Das ist das entscheidende Argument für Doxygen.
• E

  Dateiformat FAT12
  • Erhard Henkes  

  11
  0
  Stimmen
  11
  Beiträge
  5069
  Aufrufe

  E

  Da sich die Entwicklung von USB 2.0 basierend auf EHCI doch schwieriger und langwieriger gestaltet, wird doch noch die Möglichkeit geschaffen, Daten im FAT12-Format auf die Floppy zu schreiben (siehe Rev. 279 ff.).