Nachrichten

41

Das Wiki / Genuine Reihe - Beta Leser

« am: 24. August 2006, 22:37 »

Use the power of google
Ansonsten kommt man recht schnell an Informationen, z.B. beim Herausgeber der ATA-6-Spezifikation T13 oder bei Tecchannel oder auf http://ata-atapi.com/ oder im Linux-Quellcode. Man muss sich nur mal umschauen, die Infos sind überall.
Kleiner Tipp: such mal in der ATA-6 Spezifikation nach "Bus Mastering" oder ähnlichem, und sag mir wie oft du das findest ^^.

42

Das Wiki / Genuine Reihe - Beta Leser

« am: 24. August 2006, 14:40 »

Wieso?
DMA ist ein eindeutiger Name.

Stimmt ja auch, aber nicht für das womit du dich hauptsächlich in deinem Tutorial auseinandersetzt. Bei dir geht es zu 90% darum, wie man den alten i8237 DMAControler anspricht. Bei deinem Titel aber würde ich von einem umfassenderen Werk ausgehen, welches sich auch mit den anderen Möglichkeiten von DMA-Transfers auseinandersetzt. Allerdings sehe ich keine. Und die halbe Seite "Busmaster DMA" fällt ja komplett aus dem Konzept "Programming the ..." raus.

Busmastering DMA (umgangssprachlich) bedeutet UDMA

Nicht wirklich. Busmastering ist die Möglichkeit einer Steckkarte Kontrolle über den Bus zu erlangen und losgelöst von der CPU darauf zu arbeiten. PCI DMA (und auch schon ISA DMA) nutzt dies um seine Übertragungen zu ermöglichen/zu beschleunigen. UltraDMA, was jetzt ein noch speziellerer Begriff ist, den es nur bei IDE-Controllern gibt, ist nur eine verbesserte Übertragungsweise, die ähnlich dem Übertragungskonzept von DDR-RAM ist. Desweiteren gibt es ja auch noch Single-Word und Multi-Word DMA bei IDE-Controllern, was dann wieder ein paar Dinge für ein "genuine" Dokument währen, die nicht angesprochen werden.
Ich hoffe du verstehst worauf ich hinaus will?

43

Das Wiki / Genuine Reihe - Beta Leser

« am: 23. August 2006, 18:45 »

Schon seit fast einem Jahrzehnt sind IDE Controller über den PCI Bus angeschlossen . In der Regel jedoch nicht als separate Karte sondern innerhalb der Southbridge fest verdrahtet. Um Kompatibilität mit alten Betriebssystemen zu halten haben diese PCI IDE Controller fast immer 2 Modi -> Legacy Mode um wie eine "alte" ISA Karte zu funktionieren und den Standard DMA Controller zu nutzen ; und den Native Mode, in dem die Konfiguration über die PCI Configuration Register geht, andere Ports als üblich und außerdem MemoryMappedIO verwendet wird. Hier wird auch PCI DMA genutzt, welches im Gegensatz zum "alten" DMA Controller den 32bit Addressraum ansprechen kann. Durch PCI Busmastering kann der Übertragungsprozess sogar noch beschleunigt werden, indem der Controller für eine gewisse Zeit  den PCI Bus für sich allein haben kann.
Für SATA Controller wird man eigentlich immer einen eigenen Treiber brauchen, weil da erst gar kein "Legacy Mode" integriert wurde. Aber es gibt einen Standard: AHCI.
Inwiefern der eingehalten wird weis ich allerdings nicht, aber mindestens genauso gut wie viele andere ^^.
@T0ast3r: du solltest dein Tutorial vielleicht nicht DMA sondern DMAC oder 8237 DMAC nennen, weil es sich sicher nur auf diese einen "alten" Controller bezieht

44

Lowlevel-Coding / BIOS kaputt ?

« am: 21. August 2006, 17:31 »

Also ich kann dir sagen das entweder dein Mainboard oder deine CPU durch das Netzteil gekillt wurden. Denn das ist am Anfang das einzige, was der BIOS braucht um zu starten. Ohne Speicher oder mit fehlerhaften Speicher kommen bestimmte Piepser. Ohne CPU oder mit kaputter bräuchtest du schon ein externen Diagnosechip, was das alte Mainboard sicher nicht hat. Solltest mal schauen das du eine ganze CPU bekommst und testen kannst, dürfte nicht allzu teuer sein, oder vielleicht hat auch jemand eine rumliegen, genauso das Mainboard. Ansonsten R.I.P.

45

Lowlevel-Coding / Grafikkarteninformationen aus Windows-Treibern

« am: 21. August 2006, 17:17 »

W32DASM war glaub ich ein sehr gutes Reverse Engineering Tool für Windows. Hab ich mal vor Jahren benutzt. Und das mit den I/O Ports bei NVidia Grakas: leider sind die nur der geringste Teil -> das meiste geht über MemoryMappedIO, d.h. jedes MOV, STOxx, und eigentlich (fast) jeder Befehl kann die Graka ansprechen, da dauert das rausfinden natürlich etwas länger.

46

Offtopic / Programm zum erstellen von Images ...

« am: 30. July 2006, 23:21 »

Also ich benutz dafür Shell-Skripte^^

47

Lowlevel-Coding / Im laufenden OS den Grafikmodus wechseln.

« am: 30. July 2006, 23:17 »

Em, nein. Die können sie von Modellreihe zu Modellreihe ändern, und das tun sie auch öfters (Von Hersteller zu Hersteller sind sie sowieso komplett anders). Aber nicht nur die Ports (MemoryMapped IO) sondern auch der Inhalt ändert sich ab und zu. Also wenn du Wert A in Register B schreibst, kann das auf einer GF2 andere Auswirkungen als auf einer GFFX haben.

48

Lowlevel-Coding / Im laufenden OS den Grafikmodus wechseln.

« am: 30. July 2006, 15:39 »

Also mit den VGA-Registern wird man nicht allzuweit kommen, es sei denn 320x240x256 oder 640x480x16 ist einem genug Auflösung. Für die höheren Auflösung brauchts entweder den VESA-BIOS oder einen Grafiktreiber. Kannst ja mal die XFree86 Sourcen oder den Linux-Kern schauen, da sind Routinen für den Grafikmodus drin. Die haben nur 2 Nachteile (z.B. bei NVidia): 1. sind die Teilweise gecopyrighted, 2. teilweise total unverständlich (it's just magic).

49

Offtopic / Experimentele Programmiersprache

« am: 30. July 2006, 15:30 »

Also meines Wissens benutzen JavaVMs einen Mark&Compact Garbage Collector, der nix mit Reference-Counting zu tun hat. Der Algorithmus startet einfach eine Suche, die bei den Variablen beginnt und dann alle Pointer nachverfolgt. An jedem Objekt wo die Suche vorbeigekommen ist, wird ein Flag gesetzt, dass das Objekt noch erreichbar ist. Die die am Ende dieses Flag nicht haben werden aus dem Speicher gehauen und die anderen Speicherbereiche werden zusammengeschoben, um die Speicherfragmentierung gering zu halten. Mit x-Fach-Verketteten Listen kommt das Ding sehr gut zurecht. Wie schon gesagt tritt dein Problem nur bei ReferenceCounting-GarbageCollectoren auf, die aber nicht wirklich oft eingesetzt werden.

50

Offtopic / Wie greift ihr auf eure Diskimages zu?

« am: 29. July 2006, 00:59 »

Wenn es nicht gehen würde, würde ich es nicht machen Vor dem Start eines Emulators, bzw. nach dem Verändern von Dateien im Image führe ich jedoch auch noch 'sync' aus. Somit hat sich die Sache und alles läuft prima.

51

Offtopic / Wie greift ihr auf eure Diskimages zu?

« am: 27. July 2006, 17:17 »

Fstab ist auch ne nette Variante. Ich persönlich bevorzuge allerdings die sudo Methode, bzw. benutz ich eine GUI-Version (gksu). Bevor ich anfange zu arbeiten lasse ich meine Images mounten, progge dann, arbeite auf den Images und lass alles auch durch Bochs,QEMU und VMware laufen, und wenn ich keinen Bock mehr habe, lasse ich das ganze umounten.
Das sind dann 2 Passworteingaben, und übrigens nicht das Root-Passwort sondern das User Passwort ^^ (es sei denn man hat bei beiden das gleiche ).

52

Offtopic / Wie greift ihr auf eure Diskimages zu?

« am: 26. July 2006, 23:08 »

mount -o loop,uid=MeinUser,gid=MeineGruppe image.img ./directory ?

53

Lowlevel-Coding / 64 Bit bei Intel CPUs

« am: 14. July 2006, 16:31 »

Die Intel-CPUs mit "EM64T" sind voll zu AMD64 kompatibel.

54

Lowlevel-Coding / Im 64 Bit Modus einen Far jmp machen.

« am: 14. July 2006, 16:29 »

Hi,

ich gehe mal davon aus das du im LongMode arbeitest. Nun das Problem: da die Segementierung in diesem Modus abgeschafft wurde, gibt es keinen wirklichen 64bit far-jump! Deswegen wird sich auch FASM dagegen wehren! Ich wüsste auch nicht so wirklich wofür man den brauchen könnte. Dein RETF-Workaround ist fast die einzige Möglichkeit. Andererseits könntest du auch noch an eine im Speicher gehaltene Adresse springen (indirekter FarJump), allerdings nur mit 16/32Bit Offsets. Schau mal ins AMD64 Manual 3, da stehen die Instruktionen und die Einschränkungen drin.

55

OS-Design / Idee zum 36 bzw. 64 bit großen Addressraum

« am: 06. July 2006, 16:04 »

- Speichern von dateien? Wie soll das gehandahbt werden?

Dirty-Bits abfragen und geänderte Daten zurückschreiben

- Dateien read only öffnen?

Read-Only Bit setzen

- Arbeiten mit mehreren dateien? ( was passiert wenn eine datei, z.B. eine log datei immer grösser wird. was passiert mit der datei, die danach im speicher liegt?

Vorher maximalen Bereich festlegen, Dateiverlängerungen können durch Page-Faults abgefangen werden.

- Wie soll sich das system verhalten, wenn dateien von anderen prozessen verändert werden? z.B. logdateien, die du mit einem program beobachtest?

Ganz einfaches Leser-Schreiber-Problem, kann man mit Semphoren, Monitoren etc. lösen.

56

OS-Design / Idee zum 36 bzw. 64 bit großen Addressraum

« am: 06. July 2006, 15:53 »

Also bei PII/PIII und den anderen IA32 Prozessoren liegst du leider voll daneben. Der Physische Adressraum kann da 36Bit sprich 64GB fassen, virtuell hast du aber immernoch nur 32Bit sprich 4GB, auf die du zu einem Zeitpunkt zugreifen kannst, geht also nicht. Nur Teile der Datei können so im Speicher gemappt werden, was aber nix neues ist, Linux macht das schon möglich.
Bei 64Bit kann man es komplett machen. Momentan hat man da 256TB (48Bit) auf AMD64 Prozzis an Adressraum und maximal 2^52 Byte an RAM zur Verfügung.
I/O Operation fallen auch nicht wirklich weg, man verlagert nur die Aufgabe auf einen Page-Fault-Handler, wobei dieser sehr genau darauf achten muss, wo wann was geschreiben wurde, damit es am Ende auch auf der Festplatte landet.

57

Lowlevel-Coding / Parameterübergabe an Kernel

« am: 05. July 2006, 01:12 »

Wie wärs mit einer Registerübergabe wie bei GRUB ?

58

OS-Design / Spinlocks/Scheduling

« am: 01. July 2006, 00:51 »

Ich sags mal so: da die meisten Konzepte eh schon bis zu 40 Jahre auf dem Buckel haben kann so ein Buch nicht wirklich veralten ^^

59

Lowlevel-Coding / Softwaremultitasking, aber wie?

« am: 29. June 2006, 17:36 »

Da die 64 Bit CPUs von AMD 100% abwärtskompatibel zu allen 32bit x86ern ist geht da natürlich auch noch Hardwaremultitasking in den "alten" Modi.
Softwaremultitasking funktioniert im Prinzip ganz einfach. Du rufst ja in Regelmäßigen Zeitabständen den Timerinterupt auf. Bei diesem wird im Stack CS:EIP,SS:ESP und eFlags abgelegt die beim IRET wieder ausgelesen werden. Wenn du nun vor dem IRET deine alten Register von Task A abgespeichert hast und die von Task B lädst und dabei auf deine Stackwerte umänderst, springst du beim IRET in deine Task B

60

Offtopic / I-Pod - Fans aufgepasst!

« am: 22. June 2006, 20:26 »

Dann lass es bitte im Offtopic und schick keine Spam Mails!!!!!!!!!!!!!!!!!!!!!!!!!!!!