Nachrichten

241

OS-Design / Re: diskettenimage erstellen unter windows

« am: 03. July 2009, 13:00 »

Na ja, es ist offensichtlich ein Byte zu groß... Also bei dem Timesbefehl ein Byte abziehen:

Code: [Auswählen]

times db 1474047-($-$$) db 0Ist aber merkwürdig, dass ein Byte zu viel ist... Deshalb weiß ich nicht, ob das mit dem Abziehen wirklich funktioniert.

242

Lowlevel-Coding / Re: Bekomme Tastenkombinationen (teilweise) nicht hin

« am: 03. July 2009, 12:31 »

Zu Hartmut und matheguru: Ein @ und ein µ kann man sehr wohl im Textmodus ausgeben. Ein @ ist im ASCII-Zeichensatz drin, ein µ im erweiterten (Codepage 437, siehe FreakyPenguin). Für das €-Zeichen benutze ich persönlich übrigens das Zeichen an der Stelle 0xEE.

243

OS-Design / Re: diskettenimage erstellen unter windows

« am: 03. July 2009, 12:26 »

Mir fällt jetzt erstmal ein, dass der Bootsektor mit 0xAA55 enden sollte - wobei ich denke, dass das bei dir so ist. Außerdem sollte das Image bestimmt die Größe einer normalen Diskette (also 1440 kB) haben, das ist bei dir vermutlich nicht der Fall. Ich kann mir vorstellen, dass VMware und VirtualPC Images von einer anderen Größe nicht als Diskettenimages erkennen und sie somit als fehlerhaft werten.
Du könntest zur Lösung deinen Kernel entsprechend groß machen, sodass er den Rest der Diskette vollmacht.
Wenn boot.bin 512 Bytes groß ist und sonst nur kernel.bin auf dem Image sein soll, dann solltest du das an kernel.asm anhängen (sollte eigtl. funktionieren):

Code: [Auswählen]

times db 1474048-($-$$) db 0Das sollte kernel.bin 1474048 Bytes groß machen, zusammen mit den 512 Bytes des Bootloaders sollten das dann 1474560 Bytes, also 1440 kB sein.

244

Offtopic / DAS GEHEIMNIS MEINES NICKNAMENS!!!</capslock>

« am: 03. July 2009, 12:09 »

Joa, ich hab einfach nach was Schönem gesucht, dazu "Per Anhalter durch die Galaxis" aufgeschlagen und mal so gesucht... Da gab es irgendwas, das mit "Xan" anfing und was anderes, das mit "Clic" aufhörte - zusammengefügt war das dann "XanClic".

245

Offtopic / Re: Warum kann man keine Themen im Resourcen Monitor öffnen?

« am: 26. June 2009, 20:28 »

Ich könnte mir vorstellen, dass es nicht gelöscht wird, weil die Themen eben archiviert wurden. Muss man ja nicht löschen, könnten ja nützlich sein. Und das alles ins Wiki zu verschieben und zusammenzufügen ist wohl zu kompliziert und IMO auch sinnfrei.

246

Lyrisches Eck / Re: DAS LEBEN EINES PROGRAMMIERERS

« am: 26. June 2009, 13:25 »

Schön, dass es hier mal wieder einen Thread gibt!

(Auch wenn das leider keine Lyrik, sondern Epik ist... )

247

Lowlevel-Coding / Re: 64 bit fpc und elf32

« am: 17. June 2009, 19:58 »

<ot>

Leider habe ich noch keine Kompetentzen zu diesem Thema

Der Button ist mit "antworten" und nicht mit "Statusmeldung abgeben bzw. Interesse anzeigen" beschriftet... 
(sry, konnte es nicht zurückhalten)
</ot>

248

tyndur / Re: 0.3 - Ideen und Ziele

« am: 23. May 2009, 13:46 »

Ich fände eine Make-Portierung sehr schön.

249

Lowlevel-Coding / Re: Kann mir mal jemand helfen

« am: 03. May 2009, 13:51 »

AFAIK könnte es unter Windows auch "nasmw" statt "nasm" heißen...

250

Lowlevel-Coding / Re: 64kB-Problem

« am: 25. April 2009, 20:32 »

Guuut... Ersten Punkt ausgewählt (auf GRUB umsteigen) - und alles funktioniert.

Bisher hatte ich mich immer gegen GRUB gesträubt, weil es mein FS nicht unterstützt... Aber das ehemalige Image kann man ja gepackt als Modul laden lassen...

Vielen Dank also!

P. S.: Unterschwelliger Tipp eventuell an matheguru: Das Umschreiben des Kernels für GRUB hatte ich in zwei Tagen fertig, und ich bin nicht der beste Programmierer...

251

Lowlevel-Coding / 64kB-Problem [gelöst]

« am: 20. April 2009, 20:35 »

Hallo,

Tja, mein Kernel nähert sich so langsam der 64kB-Marke (ist eben ein Monolith) und da tauchen die Probleme auf. Ich habe keine Ahnung, woran es liegen kann, mein Bootloader kann zweifellos über RealMode-Segmentgrenzen hinaus laden und das Restsystem läuft im ProtectedMode mit Paging, sollte also keine Probleme mehr mit diesen 64kB haben.

Also, die Probleme sind:
- Globale Variablen, die initialisiert werden (z. B.: "char *ConsoleBase = (char *)0x800B8000)") sind im Programm uninitialisiert.
- Unter QEMU gibt es einen TripleFault, wenn ich eine Zeile Code zusätzlich schreibe oder eine zusätzliche Variable einfüge (wo auch immer), entferne ich diese wieder, ist alles in Ordnung. Übrigens geht dem TripleFault ein Pagefault voraus, laut dem der Stack nicht gemappt sei.
- Gestartete Programme beenden sich zuerst mit einem Pagefault, starte ich sie später mit den gleichen Parametern noch einmal, ist alles in Ordnung.

Aber das wohl merkwürdigste ist, dass der Kernel noch gar nicht 64kB groß ist. Er hat bloß eine Größe von jetzt genau 62700 Bytes...
Bis jetzt habe ich ihn einfach dadurch klein gehalten, dass ich die Alignflags im Linkerscript entfernt (bzw. auf 1 gesetzt) habe, doch jetzt ist das alles ausgereizt.

Ich dachte, dass es an einem RealMode-Stack liegen könnte, der in den Kernel hineinwächst (der Kernel wird nach 0x10000 geladen, es hätte ja einen Stack bei 0x1000:0xFFFF geben können), doch dem ist nicht so (mein ProtectedMode-Stack liegt übrigens bei 0x4FFFFF). Der Bootloader überschreibt auch keine Daten des Kernels oder so.

Bis jetzt habe ich versucht, dieses Problem einfach - so gut es ging - zu ignorieren, doch das wird nun immer schwerer (neue Treiber sind unmöglich geworden). Ich hoffe, jemand von euch hat eine Ahnung, woran das ganze liegen könnte.



P. S.: Bitte sagt mir jetzt nicht, dass das ein guter Zeitpunkt zum Umsteigen auf einen Microkernel wäre...

252

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

« am: 17. March 2009, 20:52 »

Ja, wobei ich nicht GRUB, sondern einen eigenen Bootloader benutze (alles schön buggy halten ). Der lädt dann alles vom Kernel bis zur about.txt in den Speicher.
Ich hätte zwar einen Diskettentreiber "in der Hinterhand", aber ich habe nur ein USB-Diskettenlaufwerk und da ist BIOS besser. Und eine Funktion zu implementieren, die mir im UnrealMode die ganze Diskette einliest, hatte ich noch keine Lust/Zeit...

253

Offtopic / MyXomycota

« am: 15. March 2009, 23:18 »

Entschuldigung...

Ich muss diesen alten Thread einfach aus der Versenkung holen, weil ich es einfach so toll finde, dass ich FASM auf meinem OS (MyXomycota) zum Laufen gebracht habe...

Weil es so spät ist, kann ich nur noch einen Screenshot uploaden:




Tja, ich hoffe, ihr könnt mir verzeihen

254

Lowlevel-Coding / KEIN GPF beim Zugriff auf allokierten Speicher

« am: 13. March 2009, 22:56 »

[Schade, ich hatte gehofft, es hätte noch niemand geantwortet und ich könnte den Thread jetzt löschen...]

Ich hatte beim IRQ0-Handler folgendes geschrieben:

Code: [Auswählen]

pop   gs
pop   fs
pop   es
pop   fsEs hätte am Ende (natürlich) aber

Code: [Auswählen]

pop   ds heißen müssen... So konnte ich nach dem malloc zwar noch auf lokale Variablen zugreifen, bei globalen bekam ich aber natürlich einen GPF (da "ds" vom Prozessor auf 0 gesetzt worden war, um nicht bei CPL3 auf ein DPL0-Descriptor zu verweisen)...

255

Lowlevel-Coding / GPF... [gelöst]

« am: 11. March 2009, 22:12 »

Schönen guten Abend,

Nachdem ich nun endlich auf C und Paging umgestiegen bin, habe ich es auch geschafft, Multitasking mit CPL0-Prozessen zu implementieren. Beim Umstieg auf CPL3 habe ich aber noch (mindestens) ein Problem: Wenn ich über einen Syscall Speicher anfordere, dann wird die entsprechende Adresse auch korrekt zurückgegeben, beim Versuch des CPL3-Prozesses, darauf zuzugreifen, enden aber sämtliche "normalen" Computer und BOCHS mit einem GPF, bei QEMU und VirtualBox funktioniert jedoch alles.
Der zurückgegebene Speicher ist korrekt gemappt (der Kernel kann ohne Probleme darauf zugreifen) und eigentlich sollte er auch von Userprozessen verwendet werden können - das Ausführen des Codes funktioniert schließlich und der ist ebenso gemappt.
Am TLB kann es auch nicht liegen, da "invlpg" nach der Allokation ausgeführt wird (ich habe es auch mit Neuschreiben von CR3 versucht).

Falls es wichtig sein sollte: Die IDT besteht aus 256 Elementen, alle sind zumindest auf einen einfachen iret-Handler umgeleitet, der Sysint ist 0x80. Die GDT enthält 6 Elemente (Null-Handler, Systemcode (Von 0 bis 4 GB, DPL=0), Systemdaten (ebenso), Benutzercode (Von 0 bis 2 GB, DPL=3), Benutzerdaten (ebenso) und TSS (nur esp0 und ss0 gesetzt)). Der Kernel ist nach 0x80000000 (bzw. 0x80010000) gemappt.

Daten, die mein BlueScreen(tm) liefert:
ErrorCode = 0
CS:EIP = 0x1B:0x0000094C ("for (i = 0; tmem; i++)" - tmem ist der allokierte Speicher (Typ (char*))
SS:ESP = 0x23:0x000FFD28
(kernel: SS:ESP = 0x10:0x81239FE8)
DS, ES, FS, GS = 0x23
TR = 0x28
GDT ab 0x81000000
IDT ab 0x80017200


Ich hoffe, irgendjemand hat eine Ahnung, woran es liegen könnte...

P. S.: Wenn ich Code posten soll, kein Problem. Es könnte nur ein bisschen unübersichtlich sein (und ich benutze bei Inlineassembler die Intelsyntax (bei GCC)).

256

Offtopic / Re: Editor(en)/Entwicklungsumgebung(en) C/C++ und ASM

« am: 05. October 2007, 20:37 »

Na ja, es ist nicht wirklich ein "Compiler", es ist eher eine Art "Übersetzer" (aber kein Interpreter)... Er nimmt (bis jetzt nur äußerst einfache!) Befehle entgegen und wandelt die dann in Assembly für FASM um... Ist aber nur eine Notlösung, weil ich ehrlich gesagt nicht wirklich mit dem richtigen C klarkomme (kapiere Linker nicht, etc.)...

257

Lowlevel-Coding / Re: Erste (und ggf. zweite Festplatte) hängt an welchen Controller?

« am: 26. September 2007, 18:23 »

Es gibt doch so ein ATAPI-Kommando, ebenfalls "IDENTIFY"... Das wird genau wie das IDE-Identify gesendet, bloß dass Festplatten nicht darauf antworten (glaube ich...)... Soweit ich weiß, heißt das IDE-Identify-Kommando 0xEC und das ATAPI-Identify-Kommando 0xA1... Das wird wirklich genau so wie ein normales IDE-Kommando gesendet, auch das Empfangen des Rückgabewertes ist gleich... Nur eben, dass Festplatten theoretisch nicht darauf antworten dürfen...

258

Offtopic / Re: Editor(en)/Entwicklungsumgebung(en) C/C++ und ASM

« am: 09. September 2007, 17:58 »

Ich benutze einen selbstgeschriebenen C-Compiler (nicht wirklich C, so was in der Art halt ). Deshalb benutze ich auch notepad++, da man dort ja ganz einfach neue Syntaxregeln für das Highlighting hinzufügen kann. Als Assembler schließlich benutze ich FASM.

So, dett war mein Ketchup, ääh - Senf.

259

Lowlevel-Coding / Re: Merkwürdiges LGDT-Problem

« am: 10. August 2007, 09:13 »

So etwas dachte ich mir, habe mich dann aber gewundert, warum der Assembler keine Warnung ausgibt (wenn er versucht eine 32bit-Adresse in 16 bit darzustellen)...

260

Lowlevel-Coding / Betreff

« am: 09. August 2007, 15:42 »

Ich habs jetzt: Die Adresse ist korrekt, jedoch zu hoch. Irgendwie darf LGDT nicht mit einer Adresse über 64KB benutzt werden (verursacht einen GPF)...
Ich kopiere meine GDT und den Descriptor jetzt unter die 0x10000-Marke, das klappt.

Trotzdem vielen Dank!