Nachrichten

21

Lowlevel-Coding / Re:Multiboot Vesa aktivieren

« am: 29. June 2010, 09:37 »

Hm, Musst du wohl selber experimentieren, Habe grade jedenfalls weder bei uns noch bei osdev.org Infos dazu gefunden (nur Wiki).
Würde aber eh davon abraten das zu machen. A) Wenige Bootloader die das mitmachen (GRUB nur gepatcht, oder GRUB2 - beides imho eher selten vorhanden), B) Keine Möglichkeit zum Moduswechsel im laufenden Betrieb, C) Du kannst dir nicht so ganz sicher sein das deine Wünsche auch respektiert werden. afaik kann ich (dem gepatchten grub zumindenst) auch sagen setz lieber den Modus. Und dann gehn die Probleme los
Implementier lieber VM86. Dauert ne Ecke, ist dafür aber ganz praktisch. Und VBE dann selber anzusprechen, ist echt kein Problem und schnell erledigt.

22

Offtopic / Re: Frage zu GUI-Programmierung(Linux)

« am: 25. June 2010, 19:54 »

Uhm, nein, wird nicht. Es läuft der X-Server (im Regelfall xorg), der die komplette Verwaltung Grafik raus Eingabe rein übernimmt. Ob/Wie dann weitere Sachen geladen werden, hängt von anderen Stellen ab. Typische Initskripte starten z.b. einen X Display Manager (xdm, gdm, kdm), der stellt dir dann die Loginmaske zur Verfügung (und startet bei erfolgreichem Login dann die Startskripte für diverse Desktopumgebungen).

Grafikmodi setzen, machst du (im Regelfall) via X-Server. Wobei man da beachten muss, das das am besten beim Start funktioniert, im laufenden Betrieb Auflösung wechseln kann (je nach Treiber, Weiteren Einstellungen wie z.b. nem zweiten Monitor) garnicht via X machbar sein, sondern muss z.b. über Setupdialoge der Treiberhersteller gemacht werden (z.b. bei nVidia-Karten mit nvidia-treiber, bei twinview/Mehr-Monitor-Setup).

Ausnahme: Man kann ohne den X-Server arbeiten. Die zwei Variante die mir da einfallen wäre DirectFB (http://www.directfb.org/), oder direkter Zugriff auf KMS (Kernel Mode Setting, da sind Teile der Grafiktreiber, nämlich eben das Setzen des Modus, in den Kernel ausgelagert). DirectFB kommt (afaik) ohne Hardwarebeschleunigung, KMS erfordert vollständige Grafiktreiber. Also beides nicht unbedingt _die_ Optionen.

Für nen Einstieg in Programmierung direkt am X-Server siehe z.b. http://www.pronix.de/pronix-28.html . Aber ganz ehrlich, im Regelfall willst du das nicht. Für Spiele / Alles was ernsthaft schnelle Grafik benötigt, solltest du normal zu OpenGL greifen, als Schicht zum Initialisieren bietet sich SDL an. Für normale Anwendungen das Framework der Präferenz - gtk (Gnome) oder Qt (KDE).

23

OS-Design / Re: Frage zum Bootloader

« am: 19. December 2009, 17:10 »

Uhm, Frage: zu welchem Bootloader?
Wenn der Bootloader fat32 kann kann der im Regelfall dann auch einfach die Datei "chainloaden", also laden und annen Start springen. Sowohl GRUB als auch NTLDR sind dazu in der Lage. müssen natürlich entsprechend konfiguriert werden

Lies dir am besten die Artikelreihe im Wiki durch (http://lowlevel.brainsware.org/wiki/index.php/OS-Dev_f%C3%BCr_Einsteiger), das sollte schonmal viele Fragen beantworten.

24

Lowlevel-Coding / Re: Ins Video Memory schreiben

« am: 10. December 2009, 22:00 »

Genau auf die Adressen achten
Das wurd als sicher angenommen, weil das nen ganzes Stück außerhalb des verwendbaren/vorhandem war (0xb0000 > 0x7ffff) - da is nix mit verschenken.

25

Offtopic / Re: RawWrite neu erfinden

« am: 24. November 2009, 19:10 »

Achtung, Ungeprüftes Halbwissen

Afaik musst du halt nur das Gerät an sich öffnen. Gerätepfade beginnen unter Win mit \\, Für Floppy A müsstest du \\.\a: öffnen (evtl. auch ohne den Doppelpunkt). Der ganze Spaß wird allerdings Adminrechte erfordern

26

Lowlevel-Coding / Re: Diskettentreiber

« am: 12. November 2009, 17:44 »

Korrigiert mich wenn ich falsch liege, aber ist DMA nicht nur quasi eine optimierte Variante von in/out? Demnach müsstest du alles was du via DMA an daten rausschickst auch via in/out liefern können.

Ist aber nicht zu empfehlen - die CPU-Last die dabei entsteht ist beachtlich. Bei Floppys zwar noch fast vernachlässigbar, aber spätestens für Platten machst du dir das System so unbenutzbar.

27

OS-Design / Re: Von USB-Stick booten

« am: 12. November 2009, 17:38 »

Was auch eine Möglichkeit wäre, ist dass es am Stick liegt...
Es gibt bootable USB-Devices, die eine andere Spezifikation erfüllen. Erfüllt der Stick diese nicht, kann es sein, dass er gebootet wird, es kann allerdings auch sein, dass das BIOS dann Probleme macht... 

Nach meinem Wissensstand ist das absoluter Murks - das is ne Sache vom BIOS ob das lesen kann oder nicht, der Stick selber kann da überhaupt nix für. Google bestätigt *g*

28

Lowlevel-Coding / Re: Diskettentreiber

« am: 11. November 2009, 20:03 »

Ich glaub es ging eher darum dass diese Art von "Treiber" als esoterischer Code zu bezeichnen ist, Weniger dass was dabei rumkommt wenn du selber einen schreibst.

Fertige Floppytreiber gibt es z.b. bei tyndur, afaik sogar einen als CDI

29

tyndur / Re: 0.3 - Ideen und Ziele

« am: 11. November 2009, 13:59 »

Werde ich tun...
Mal so ganz neben bei, gibt es eigentlich schon einen Treiber für die Maus?

PS/2-Mäuse werden von kbc unterstützt.

Und wie sieht es mit dem Stand der gui aus? Anscheinend gibt es ja schon ein Modul hierfür...

In welchem Source schaust du? In meinem Branch gibt es dafür definitiv keinen Code mehr - der setzt auch auf eine vollkommen andere Codebasis, hat ergo garkeine Chance zu funktionieren. War aber auch nicht sonderlich weit, afaik.

EDIT
Irgend etwas stimmt nicht...
Ich sehe keinen Ordner "gfxtest", wenn ich diesen aber in der URL angebe, komme ich rein...

Siehe #2 - Hast du wirklich den richtigen Branch geklont, oder meinen master - der ist nämlich auf tyndur.git/master-Stand

30

tyndur / Re: 0.3 - Ideen und Ziele

« am: 10. November 2009, 21:24 »

Leider ist es nicht möglich, die Version 0.2.1 zum laufen zu bringen, da unter bochs der Prozess kbc einen Timeout auslöst. Aus dem Grund konnten dann die Prozesse vterm, getterm4 und default nicht gestartet werden...

Ist ein bekannter Bug in Kombination mit bochs - andere Emulatoren funktionieren. Übrigens nach meinem Kenntnissstand auch aktuell nicht gefixt, kann also gerne untersucht werden

Ich wollte einfach mal ein bisschen mit den Grafiktreibern unter tyndur experimentieren, also z.B. Bildschirm komplett Blau ausfüllen oder in eine andere Auflösung wechseln oder mal einen Kreis zeichen... 

Aktuelle Grafiktreiber gibts in meinem Entwicklerrepo im Branch "video-devel", zu finden unter http://git.tyndur.org/?p=tyndur/alex.git;a=log;h=refs/heads/video-devel
Ist nicht der perfekte Code, und teilweise wird auch rumgebastelt, zum ausprobieren und spielen reichts aber Zum testen vorzugsweise qemu verwenden (andere funktionieren ziemlich sicher nicht) - einfach kompilieren (Relevant sind die Module cdi/vesa und gfxtest), im Emulator

Code: [Auswählen]

start modules/vesa
gfxtest

Der Code von gfxtest (src/modules/c/gfxtest/) sollte selbsterklärend sein, ansonsten einfach Nachfragen

31

Offtopic / Re: fdformat

« am: 10. November 2009, 16:26 »

Hab ich doch gesagt

Du musst wirklich alles was in Frage kommt laden und dann suchen.

Nicht ausprobieren welcher der beiden Treiber funktioniert, sondern entsprechend den Treibermöglichkeiten alle Dateisysteme laden, und auf denen dann nach nem Erkennungsmerkmal (z.b. der gesuchten Datei) suchen. Der PIC kann dir da nicht helfen, einzige Option wäre wohl inner BIOS Data Area und CMOS nachzuschauen ob da nen Floppy eingetragen ist, ich würds jedenfalls für denkbar halten dass die nur echte listen. Aber alle Angaben ohne Gewähr

32

Offtopic / Re: fdformat

« am: 09. November 2009, 23:22 »

Sorry dich da enttäuschen zu müssen, aber: Keine Möglichkeit

Die USB-Laufwerke sind im BIOS entsprechend fest eingebunden und ersetzen vonnen id's her die normalen eingebauten (d.h. wenn du von ner USB-HDD startest ist das bootdrive was dein bootloader vom bios bekommt immernoch 0x80, als obs die erste Festplätte wäre). Du musst wirklich alles was in Frage kommt laden und dann suchen.

Gleiches Spiel findet sich übrigens bei Linux Live-Distributionen, die machen das genauso wenn die von CD oder USB starten

33

Lowlevel-Coding / Re: Com ports

« am: 09. November 2009, 21:13 »

Generell: Ich fand qemu dafür zum Testen am angenehmsten. Da gibt es einfach die Option "-serial stdio", womit die Konsole in der qemu gestartet wird an die erste Schnittstelle gehängt wird.
Das Testen von Einstellungen ist dabei immer so ne Sache, qemu ignoriert das schlichtergreifend, out aufm richtigen Port führt auch zum gewünschten Ergebnis. Keine Ahnung wie andere Emulationen das handhaben. Generell sollten sich aber alle Einstellungen setzen lassen - das maximal mögliche bestimmt die Gegenseite, und auch da nur durch eine Annahmegeschwindigkeit, d.h. zu hoch einstellen ist bei sehr wenig senden egal - eine Erkennung dafür gibt es nicht. Und es gibt keinen Grund warum nen Emulator nicht alle gängien Modi bis zu 115200 Baud mitmachen sollte.

Zu den genauen Einstellungen unter Bochs kann ich dir nichts sagen, das hab ich nie ausprobiert, unter Vbox hab ich den Kram noch nie zum laufen bekommen - auch keine Weitergabe an nen File.

34

Offtopic / Re: OS in Pascal

« am: 05. November 2009, 20:02 »

Wenn du nen "normalen" Port hast, eher nicht. Und vorhanden sein sollte es, ich wüsste nicht wie nen gcc dir sonst was ausführbares produzieren sollte
Was verwendest du denn alles für deine Entwicklungsumgebung?

35

OS-Design / Re: Von USB-Stick booten

« am: 05. November 2009, 17:56 »

Versuchst du die Installation auch als root? Zugriff auf /dev/sdX sollte sonst nicht möglich sein Ohne geht das ganze wirklich nur mit nem richtigen Image.
Fehler aka "In Verwendung" könnten entstehen wenn das Device noch gemountet ist. Prüfen

36

Lowlevel-Coding / Re: kernel.bin auf 512 Bytes vergrößern.

« am: 02. November 2009, 21:13 »

Merkwürdig. Entweder nasm hat unter Vista ne Macke, oder es legt ohne zutun sparse-files an und gibt die benutzte Größe - was aber mehr sein sollte, bei Blockgrößen jenseits der 512 Bytes. Steht wenn du ins Eigenschaftenmenü der Datei gehst irgendwo eine andere Größe?

Zum Wiki, wir haben da einige sehr aktive Autoren, wenn man denen nur sagt was gewünscht ist oder besser gemacht werden könnte. Also, konkretisieren!

37

Offtopic / Re: Wird OS-Programmierung in Zukunft ein Kinderspiel sein?

« am: 02. November 2009, 20:47 »

Bitte als Interpreter, damit ich auch ne Spracherkennung gut drauf ansehen kann

Zum Thema, da kann man sich nur anschließen. Was diese 3-Zeilen-Dinger können ist nicht viel, und ganz sicher nicht genug um als OS bezeichnet zu werden. Und damit das ganze gut wird, muss man schon Ahnung haben was man macht und welche Algorithmen / Mechanismen brauchbar sind.  Ergo Königsdisziplin

38

Lowlevel-Coding / Re: kernel.bin auf 512 Bytes vergrößern.

« am: 02. November 2009, 20:42 »

Hört sich eher komisch an, Quelltext wäre gut

Ansonsten liegt das Problem nicht bei qemu, sondern schlichtergreifend daran, dass die Bootsignatur am Ende des ersten Sektors gesucht wird - und ein Sektor ist bei Disketten nunmal 512 Bytes lang

39

Das Wiki / Re: Umstrukturierung des Forums

« am: 10. October 2009, 14:19 »

Die Forenstruktur wirklich komplett nach Entwicklungsschritten oder Teilkomponenten eines OS zu gliedern ist imho ziemlicher Unsinn - da kommen einfach zu viele zu leere Foren bei rum.
Sinnvoll wären wirklich Coding-Foren, ggf. unterteilt in ASM, C (und C++?), Pascal (wird ja auch noch sehr viel verwendet soweit ich das sehe) und Andere. Nen Eigenes Forum für Hardwarefragen wäre wohl ebenso sinnvoll, ebenso wie eines für die "Software"-Seiten des Kernels (aka Speicher/Prozess/sonstwas-Verwaltung).
Ein Bootloader-Forum würde da wohl auch zupassen, stellt sich die Frage ob sich das wirklich lohnt - verwenden ja doch ziemlich viele GRUB. Aber im Zweifelsfall, einrichten. Regelmäßig und genügend drüber diskutiert wird ja *g*.

Offtopic muss natürlich bleiben, das aktuelle "wiki"-Forum verallgemeinern halte ich auch für keine schlechte Idee.

Den alten Kram meiner Meinung nach erstmal in ein Archiv packen.

40

Lowlevel-Coding / Re: Tastatur ohne Interrupts abfragen

« am: 06. September 2009, 23:14 »

Was den Unterschied angeht: Gibt keinen. Interruptnummern werden via einer Tabelle Codestücke zugeordnet, die angesprungen werden (vereinfacht). bios-ints werden halt nur beim rechnerstart initialisiert, mit sinnvollen handlern die definierte tätigkeiten ausführen.

Zum was besser ist, Kommt wie immer dadrauf an was du jetzt genau vor hast. Solange du im Realmode bist ist es eigentlich doofe Codeduplikation wenn du nen eigenen Tastaturtreiber schreiben willst, ergo sind bios-ints angebracht. Da du im PMode eigentlich keine bios-ints mehr hast erübrigt sich die Frage da auch

Wie du auf Hardware(un)abhängigkeit kommst ist mir jetzt ein Rätsel. Solange du auf x86 (und kompatiblen) arbeitest gibt es ints, die funktionieren halt so, und fertig. Hardwareabhängigkeit kommt ja erst rein wenn du mit spezifischer Hardware arbeitest. Für Tastaturen musst du dich aber um nix kümmern (eigentlich, sobald nen USB-Treiber ins Spiel kommt fällt für USB-Tastaturen die PS/2-Emulation weg).

Generell, siehe die Wiki-Artikel zu Interrupts und KBC, die sollten eigentlich alle Fragen beantworten