Nachrichten

21

Lowlevel-Coding / Re: Projekt: Eigener Emulator

« am: 12. November 2006, 13:21 »

@nooooooooos: Thx
@bitmaster: Am meisten sieht man bei GUI 0.0.1. Alles ist sehr bunt und es wird ne Fehlermeldung ausgegeben, aber immerhin

Die nächste Version wird vermutlich nicht mehr so viele Neuerungen haben, sondern hauptsächlich aus Bugfixes und kleineren Änderungen bestehen. Mit etwas Glück funktioniert dann auch DOS... Vielleicht gibts in 0.3 auch nen kleinen Debugger; aber was genau alles dazukommt werd ich noch mit bluecode besprechen.

---EDIT---
Ich hab mal die Tabelle mit den unterstützten Opcodes aktualisiert: Link

22

Lowlevel-Coding / Re: Projekt: Eigener Emulator

« am: 11. November 2006, 22:26 »

Hi,
Eine neue Version ist jetzt fertig. 
Es hat zwar alles etwas länger gedauert aber was solls. An Neuerungen gibts dafür einiges: Alle 8086 und fast alle 80186 Opcodes werden emuliert. Bei ein paar gibts noch kleine Probleme, aber im großen und ganzen sollten die funktionieren. Außerdem werden jetzt einige Devices emuliert, namentlich CMOS, PIC, Floppy, DMA und Keyboard. Die sind natürlich bei weitem nicht fertig, aber die Kern-Features sollten bei jedem drin sein. Dann gibt es jetzt noch ein eigenes BIOS, das schon einige wichtige Interrupts bereitstellt.

Naja, DOS läuft immer noch nicht, aber immerhin wird was angezeigt Was sich zum Testen aber ganz gut eignet ist JonOS (http://sail.to/jonos).

Und last but not least gibts endlich ne neue Website, die hässliche graue Seite ist also endgültig Geschichte

Link: http://myemu.masen-inhabitants.com/index.php
Danke fürs Testen 

23

Offtopic / Re: Windows oder Linux unter Bochs

« am: 25. October 2006, 22:39 »

QEMU ist genau wie bochs ein OpenSource Emulator. Nur deutlich schneller da eine andere Methode zur Emulation eingesetzt wird (bochs interpretiert die Opcodes und Qemu verwendet Dynamic Translation). Für Qemu gibt es außerdem ein PlugIn, das die Geschwindigkeit nochmal deutlich erhöhen soll.
Website: http://fabrice.bellard.free.fr/qemu/

24

Lowlevel-Coding / Re: Printing numbers

« am: 25. October 2006, 22:32 »

Ich habs jetzt nochmal getestet und die Zahl wird richtigrum ausgegeben...

Dieser Code gibt jedenfalls 123 aus.

Code: [Auswählen]

#include <iostream>
using namespace std;

void PrintDec(long num)
{
char buffer[11];
int i = 10;

do
{
buffer[--i] = '0' + (char)(num % 10);
num /= 10;
} while (num > 0);

buffer[10] = '\0';
cout << buffer+i << endl;
}

int main(int argc, char *argv[])
{
PrintDec(123);
return 0;
}

Ich fülle ja den Buffer von hinten nach vorne, sozusagen. i wird mit 10 initialisiert und dann immer kleiner.

25

Lowlevel-Coding / Re: Printing numbers

« am: 25. October 2006, 22:19 »

  Das mit der Klippe is ne ganz schlechte Idee.
Wenn du schon ne Funktion für eine einfach Stringausgabe hast, guck dir das mal an:

Code: [Auswählen]

void PrintDec(long num)
{
char buffer[11];
int i = 10;
do
{
buffer[--i] = '0' + (char)(num % 10);
num /= 10;
} while (num > 0);

buffer[10] = '\0';
Print(buffer + i);
}
Früher oder später ist aber eine richtige printf-Funktion, sehr hilfreich.

26

Offtopic / Re: bitmaster vs. thetrue reloaded

« am: 23. October 2006, 12:48 »

DirectX10 gibts zwar nur für Vista, aber es soll eine weitere DirectX9L für XP nachgeschoben werden welche zumindest einige der neuen Grafikkartenfunktionen (Shader 4.0) unterstützen wird.

Das war aber wohl ne Falschmeldung von einer Website (ich komm nicht mehr auf den Namen...), die sich dann verbreitet hat. So weit ich weiß, ist DX9.0L nur für Vista und sorgt für die Abwärtskompatibilität. Link

27

Offtopic / Re: Forumsoftware

« am: 11. October 2006, 16:41 »

Ja, sowas fehlt wirklich. Vor allem in einem Forum in dem es hauptsächlich um Programmierung geht.
Hat aber im alten Forum auch gefehlt, da war der komplette Code immer so grünlich.

28

Das Wiki / Ausgabe 10

« am: 05. October 2006, 16:34 »

Hi,
für Ausgabe 10 wurde ja als Thema Algorithmen vorgeschlagen, und ich denke mal dass nix dagegen spricht dieses Thema auch zu nehmen.
Als Ideen für Tutorials hätte ich da:

• Scheduling
• (Deadlocks und deren Verhinderung)
• Speicherverwaltung
• IPC
• Evtl. etwas mit Filesystems; z.B. Dateien suchen

Wenn also jemand, zu einem von diese Themen etwas schreiben will, oder auch zu einem anderen Thema, kann er sich hier melden.
Sobald genug Inhalt da ist und keiner mehr was schreiben will, kommt das ganze wie gewohnt ins Wiki.

29

Lowlevel-Coding / Re: GCC "Programm kann nicht ausgeführt werden"

« am: 04. October 2006, 18:49 »

Hast du auch das bin-Directory von DJGPP in deine PATH Variable eingetragen?
Das mit den Argumenten stimmt, aber das dürfte hier nicht das Problem sein weil einfach das was zu viel ist abgeschnitten wird. Das gcc am Anfang bleibt also.

@Dein Edit
Versuchs mal damit:
gcc -nostdinc -fno-builtin -I./include -c -o main.o main.c
Das ist eigentlich auf ein Minimum reduziert.

30

Offtopic / Re: Hosen runter! Zeigt eure OS ;)

« am: 02. October 2006, 17:06 »

Hi,
tolles OS. Dass das Fenster verschieben aber etwas dauert, kann ich nur bestätigen. Aber die Performance ganz allgemein ist nicht wirklich schlecht, finde ich. Die Maussensitivität find ich eigentlich auch ganz gut, so in etwa hab ich die eh immer eigestellt.
Du könntest aber die Taskleiste immer in den Vordergrund setzen. Momentan kann man die ja mit einem Fenster überdecken, was ja meistens nicht erwünscht ist.  Und QEMU zeigt etliche Fehlermeldungen an, dass die DMA Commands 0x10 und 0x14 nicht supported werden. Ich glaub das gleiche Problem gabs auch schon bei OS-M + GUI

31

Offtopic / Re: Neuer Style

« am: 27. September 2006, 19:43 »

Also mit Firefox 1.5.0.7 unter Linux sieht alles okay aus. Unter Windows ist das Statistikfenster zu klein, die unterste Zeile steht also über. Das gleiche Problem haben ja auch andere. Mit der IE7 Beta siehts genauso aus wie im Firefox. Also überstehender Text, und auch sonst alles gleich. Irgendwas was nach Glow Effekt oder Schatten aussieht hab ich jedenfalls nicht gesehen.

32

Lowlevel-Coding / Re: Was bedeutet das in Qemu?

« am: 27. September 2006, 14:29 »

Es gibt ja 2 PICs, die unabhängig voneinander programmiert werden können. Deshalb 2 Zeilen. Während der Programmierung, wird irq_base gesetzt. Da drin steht die Interrupt-Nummer des ersten IRQ des entsprenchenden PICs. IRR ist das Interrupt Request Register, hier steht also drin welcher Interrupt gerade requested wird. IMR ist das Interrupt Mask Register; indem man den Wert hier ändert kann man IRQs (de)aktivieren. hrprio hängt mit dem Prioritätssystem der IRQs zusammen, manche IRQs haben eine höhere Priorität als andere. Aber in der Regel braucht man das nicht.
Die letzten 3 Werte kenn ich jetzt ehrlich gesagt auch nicht...

33

Offtopic / Re: Neuer Style

« am: 26. September 2006, 15:05 »

Also bei mir sieht im Firefox alles okay aus. Das Statistikfenster ist auf der gleichen Höhe wie das User Info Fenster daneben. In Opera siehts genauso aus...

Btw. wenns geht wär natürlich ein Link zum Wiki toll. Vielleicht kann man den ja neben diese Buttons wie Suchen, Profil, Logout, usw. setzen.

34

Offtopic / Re: Neuer Style

« am: 24. September 2006, 18:44 »

Gibts eigentlich ne Möglichkeit zu sehen, welche Posts man schon in einem Thread gelesen hat? Vorher gabs so kleine Icons vor jeden Post, entweder in grau oder in organge.
Die Icons gibts zwar noch, aber (bei mir) immer in grau.

35

Lowlevel-Coding / Speicherbereich über 1MB

« am: 20. September 2006, 15:17 »

Soweit ich das jetzt richtig verstanden hab, müsste man dafür CS im Protected Mode auf nen GDT Eintrag setzen, weil ja CS automatisch für den auszuführenden Code als Segment Register genommen wird und man das auch nicht ändern kann. Problem sind halt hier die Bios Interrupts (s. Wikipedia Zitat oben). Die einzige Möglichkeit wäre also nach jeder Aktion bei der CS geändert werden könnte, wieder den Unreal Mode neu zu aktivieren.
Oder man versucht sich was zu schreiben, was Code automatisch in einen ausführbaren Bereich kopiert, wenn dorthin gesprungen wird.

36

Lowlevel-Coding / Speicherbereich über 1MB

« am: 18. September 2006, 20:05 »

Ersetz das am besten erstmal durch nen echten Befehl:

Code: [Auswählen]

jmp 0x08:pm

Und hinter dem pm: muss evtl. ein [BITS 32] (oder wie auch immer das bei Fasm heißt) stehen, kann zwar auch sein dass das in dem Fall überflüssig ist, aber schaden kanns nicht. Wenn man das ergänzt, braucht man natürlich auch ein [BITS 16] vor dem rm:

37

Lowlevel-Coding / Speicherbereich über 1MB

« am: 18. September 2006, 15:39 »

Hi,
keine Ahnung für welchen Assembler der Code ursprünglich war.

Aber hier nochmal was allgemeines aus Wikipedia:

To enable unreal mode, the program has to enter protected mode, locate a flat descriptor in the GDT or LDT or create such, load some of the segment registers with the respective protected mode "selector" , then cancel back protected mode. When jumping back to RM, the processor will continue using the cached descriptors as established in PM, at least until the segment registers are reloaded - thus allowing access to 4 GiB of "extended" memory from inside real mode.

Also ich versteh das so, dass das auch nur solange funktioniert wie die Segment Register unverändert bleiben.

The catch however is that the reloading of the segment descriptor caches now holding "unreal" values might occur asynchronously inside an exception/interrupt handler, and then even if the handler correctly attempts to reload the segment before IRET (returning from the interrupt/exception), it will fail as the hidden descriptor would be reloaded under the rules of the real mode resulting in the loss of the flat descriptor and imminent catastrophe! Hence one must either forbid interrupts while accessing "unreal" addresses - which can be for a small duration only, - or use a segment register (FS or GS) that the OS/BIOS/any drivers are absolutely guaranteed not to touch.

Hier steht nochmal ein Beispiel: Im Fall von einem Interrupt oder einer Exception werden die Segment Register natürlich verändert, beim IRET werden wieder die alten Werte wiederhergestellt. Problem: Jetzt ist man ja im Real Mode, das heißt, das ganze endet im totalen Chaos.
Einzige Lösung: Unreal Mode nur temporär benutzen mit deaktivierten Interrupts, oder halt FS/GS benutzen, da die vom Bios, etc. nicht geändert werden.

Naja, überzeugt mich noch nicht so, der Unreal Mode

38

Lowlevel-Coding / Speicherbereich über 1MB

« am: 15. September 2006, 18:45 »

Hm, stimmt. Wenn man die BIOS Funktionen noch braucht, ist das sicher besser als der PMode Alternativ kann man den Kernel natürlich unter die 1MB Grenze laden, und dann im Bootloader nach dem PM Switch kopieren.

39

Lowlevel-Coding / Speicherbereich über 1MB

« am: 15. September 2006, 15:37 »

Das hab ich jetzt so spontan gefunden: http://de.wikipedia.org/wiki/Benutzer:INFNIC/Makro_um_FS_und_GS_auf_4_GB_zu_erh%C3%B6hen
Aber ich würde ehrlich gesagt nicht im Bootloader in den Unreal Mode wechseln, nur um später den Kernel dann doch im Pmode laufen zu lassen. Also wenn schon dann gleich in den Protected Mode.

40

Das Wiki / Neue alte Tutorials

« am: 14. September 2006, 21:00 »

Das mit den Algorithmen klingt nicht verkehrt. Die Frage ist halt wie weit man da geht. Also Scheduling Algorithmen sind da praktisch Pflicht, aber gehören auch noch Such/Sortier/...-Algorithmen für Listen etc. dazu, weil man damit ja Prozesse, Dateien, oder so verwalten kann?
Wegen der Sprache: Im Prinzip braucht man dafür ja überhaupt keinen Code. Man kann halt nur Beispiel Implementierungen zeigen.
Ideen für Tutorials zu diesem Thema findet man sicher in jedem Tanenbaum, die Bücher sind ja voll damit.

@blitzmaster:
Das geht im Prinzip auch jetzt: Einfach neuen Artikel mit dem Namen vom Projekt erstellen, und ans Ende diese Zeile kopieren:
[[Category:Betriebssysteme]]
Damit wird das ganze automatisch in diese Kategorie einsortiert.