Nachrichten

621

Lowlevel-Coding / der tastatur-int geht nicht

« am: 27. April 2005, 20:58 »

Wegen dem EOI-Senden an beide PICs wenn es unnötig ist hatte ein anderer Entwickler Probleme wenn ich mich richtig erinnere ...

622

Lowlevel-Coding / der tastatur-int geht nicht

« am: 27. April 2005, 19:35 »

Hmm, ich hatte auch mal sowas, bei mir war das folgendes:

Ich hatte alle IRQs aktiviert im PIC, und nur nen leeren ASM Stub zur Behandlung für die meisten IRQs (meine Logik sollte über C++ zu Java gehen ). Natürlich hatte ich ne Java-Methode für den Keyboard-ISR.

Jedoch passierte nix. Was war los? Ich hatte natürlich den PIT-IRQ 0 mitaktiviert. Der wurde ausgelöst und die CPU sprang ohne EOI aus dem ISR zurück, wodurch natürlich dann der Keyboard IRQ nicht mehr durchgereicht wurde.

Vielleicht hast du ja auch sowas ...

623

Lowlevel-Coding / der tastatur-int geht nicht

« am: 27. April 2005, 19:04 »

Standardfrage: STI haste auch aufgerufen?

624

OS-Design / GUI/Schrift

« am: 26. April 2005, 18:07 »

Dann aber direkt in der richtigen Grösse ohne Zoomalgorithmus, was die Qualität doch etwas deutlich steigert!

625

OS-Design / GUI/Schrift

« am: 26. April 2005, 17:53 »

Du kannst ja probieren es aus Polynomstücken zusammenzusetzen - das wäre mathematisch einfacher, programmtechnisch müsste man wohl mehr Fälle beachten und daraus nen guten Font zu machen wird noch viel schwieriger!

Deswegen wäre wohl ne Bitmap wohl am besten im Moment - wie es 3D Engines ja auch machen!
Aber den Pfad für Fonts aus Vektoren würde ich mir trotzdem noch offen halten!

626

OS-Design / GUI/Schrift

« am: 26. April 2005, 14:51 »

Ich will keine Engines von irgendwo nutzen, ich progge doch ein OS damit ich alles selbst machen kann. Wo ist denn da der Witz bei^^

Also ich hab damit mal angefangen, weil ich mir gedacht habe das das so wie es mit Windows oder Linux läuft, kann es ja nicht funktionieren, sonst würde ich wohl grad weiter 3d Engines basteln. Da kann auch der Sinn drin liegen!

Deswegen würde ich schon evtl. "externe" Sachen mir ansehen, vielleicht passen sie ja, und das Rad neu zu erfinden macht generell keinen Sinn! Freetype sah meiner Meinung nach auch relativ vernünftig aus (für ne C-API ).

Wenn du alles selber machen willst, dann ist das natürlich was anderes - aber dann wirst du dir wohl überlegen wollen, ob du nicht selber die TrueType Fonts parst und umsetzt - das wird dann allerdings einiges an Arbeit, so wie ich das mitbekommen hab ...

627

OS-Design / GUI/Schrift

« am: 25. April 2005, 21:55 »

Kannst ja probieren Freetype zu benutzen - dann allerdings vorsicht beim Veröffentlichen des Systems, nicht das da ne geschützte Schrift dabei ist!; )

628

OS-Design / Wie Windows arbeitet ...

« am: 22. April 2005, 15:00 »

Wenns ne DLL ist kann dein Programm die bestimmt in seinen Addressraum laden - auf Ring 3, um dann beim ersten Auftreten von in/out Instruktionen gekillt zu werden!

629

OS-Design / C++ Kernel?

« am: 19. April 2005, 19:48 »

Wenn du C nutzen willst, dann kann ich nur http://www.osdever.net/tutorials/basickernel.php?the_id=12.

Mit *etwas* (*ähäh*) aufarbeit und ner neuen print funktion ist das echt gut. Habs auch als Grundlage für meine Kernel benutzt.

Ups, und da steht noch mein Name drunter!

630

Lowlevel-Coding / Paltz im Segment schaffen

« am: 19. April 2005, 13:38 »

Dann sollte man aber generell nicht selber mit dem Datensegment arbeiten. Falls er einen 512-byte Array hat ... google nach malloc!

631

Lowlevel-Coding / 64bit Kernel

« am: 19. April 2005, 13:37 »

Nun, jede x64 CPU sollte CPUID beherrschen, deswegen würde ich diese Instruktion dafür benutzen als 1. Idee, vielleicht gibt es aber noch ne einfachere.

632

OS-Design / Wie Windows arbeitet ...

« am: 19. April 2005, 01:27 »

Warum ein HAL sinnvoll lässt sich ganz einfach erklären - nur so hat ein und der selbe Treiber überhaupt eine Chance Veränderungen im Kernel zu überdauern ohne ständig angepasst werden zu müssen und zwischen verschiedenen Architekturen doch noch portabel zu sein.

633

Lowlevel-Coding / Paltz im Segment schaffen

« am: 19. April 2005, 01:24 »

Nun, wahrscheinlich antwortete keiner weil es als OS Entwickler (und wohl zu auch Designer) gerade deine Aufgabe ist ein Speicherlayout zu entwickeln - oder einen Algorithmus der dies für dich tut, sprich so etwas wie die malloc()-Funktion aus der C Bibliothek.

634

Lowlevel-Coding / 64bit Kernel

« am: 19. April 2005, 01:22 »

Was DJGPP angeht - aktuelle GCC Versionen sind 64 bit fähig, also solltest du einen Cross Compiler für 64 Bit aus den Sourcen bauen können - ist wahrscheinlich ein Flag beim ./configure lauf.

635

Lowlevel-Coding / Was passiert beim booten von CD?

« am: 19. April 2005, 01:20 »

Ohne ATAPI Treiber hast du nur die Möglichkeit die Daten von einer Floppy-Emulation zu laden - diese jedoch funktioniert nur wenn du die BIOS Routinen zum Zugriff auf die Floppy benutzt.