Nachrichten

1601

Lowlevel-Coding / VGA: Adresse des Pixels berechnen.

« am: 04. December 2004, 19:18 »

also der modus 12h kann auch ziemlich schnell sein. z.b. beim kopieren. die bits sind übrigens nicht unbedingt r,g,b und nochwas, sondern einfach zahlen. man kann ja die "bedeutung" der 16 farben mit der palette einfach verändern kann.

also die quellcodes, die ich gesehen habe haben vor jedem speicherzugriff auch irgendwelche i/o befehle ausgeführt. ich habe leider die urls nicht mehr, bis auf die hier, weil mich das eher weniger beschäftigt hat: http://www.bsdg.org/SWAG/EGAVGA/0222.PAS.html

1602

Lowlevel-Coding / Mappen und dismappen

« am: 04. December 2004, 19:05 »

das shl ax,3 würd ich lieber zum shl eax,3 machen. sonst kannst du nur zahlen < 8192 korrekt verarbeiten.

Code: [Auswählen]

xor ax,ax
mov es,ax
mov ds,ax
muss raus. du lädst ds und es mit nulldeskriptoren, was du wohl nicht wirklich beabsichtigst. dein int 0x67, function 0x08 lädt die ja außerdem schon mit korrekten 4GB selektoren.

das ist alles was mit dazu auffällt ...

achso, du kannst übrigens auch direkt werte in esi und edi schreiben. den umweg über eax musst du nicht machen ...

1603

Lowlevel-Coding / PM-Jump

« am: 03. December 2004, 22:46 »

Zum Abschluss ist noch der gdt table falsch. Es fehlt der Dummy Eintrag (Da ein Selektor nicht null sein darf).

Der erste Selektor in der GDT kann für alles mögliche "missbraucht" werden. Auch für das GDTR. Ist Gang und Gebe das so zu machen.

Code: [Auswählen]

mov eax,dseg-GDT
mov ds,eaxes heißt ax!!

eax geht auch. im 32bit modus ist das ein byte pro instruktion kürzer und funktioniert exakt genauso wie mit ax.

Außerdem kann dseg-GDT nicht klappen, da nach dem GDT label noch dw+dd kommen...

das geht schon. beides sind offsets die NASM problemlos beim assemblieren voneinander abzieht. man muss bei der verschachtelung von GDT und GDTR nur aufpassen, dass man hinter das GDTR 2 bytes anhängt, damit der nullselektor auch wirklich 8 byte groß ist. (Wie joachim_neu es auch gemacht hat.)

1604

Lowlevel-Coding / Mappen und dismappen

« am: 02. December 2004, 14:56 »

ja der code scheint zu funzen.

aber er schreibt nicht in den bereich über 1 mbyte. du lädst ds und es mit 0x0000. das sind immer noch 16bit register, die immer noch nur werte von 0x0000 bis 0xFFFF aufnehmen. der rest wird abgeschnitten. dann schreibst du ans offset 0. du schreibst also gerade in der IVT rum.

beweisen kann man es in dem du am anfang eax mal mit 0xF0000000 (=3,75 GByte) lädst und dann das auf einem rechner ausprobierst, der weniger als 3,75 GByte RAM hat. Das wird auf dem auch funzen, weil eben die oberen 16bit abgeschnitten werden und ds und es mit 0x0000 geladen werden.

1605

Lowlevel-Coding / Mappen und dismappen

« am: 01. December 2004, 21:46 »

hehe ich bin beruhigt ^^

also um die anderen leute hier mal auf den aktuellsten standzubringen:
man darf im FRM wie vermutet ds und es usw. nicht ändern. ich habs durch probieren rausbekommen, sicherlich wäre das auch durch nachlesen gegangen ...

man muss um ds und es mit selektoren zu laden im echten protected mode sein. es gibt also zwei möglichkeiten:
1. beim booten in den protected mode wechseln, dsund es mit 4GB selektoren beladen und in den unreal mode gehen (bit 0 von cr0 löschen). Danach kann man zwar schön im ganzen arbeitsspeicher herumwüten, muss aber dafür sorgen, dass ds und es unter keinen umständen beschrieben werden.

2. man lässt die sau raus und macht was man will mit ds und es, muss aber jedes mal um sie zu ändern in den protected mode gehen, sie dann ändern und dann wieder in den unreal mode gehen. ist langsam und aufwändig. ist mMn keine echte alternative.

achso unreal mode = flat real mode = FRM

1606

Lowlevel-Coding / Mappen und dismappen

« am: 01. December 2004, 21:04 »

ich seh da zur Zeit nur, dass du ds und es mit einem ungültigen selektor lädst. du musst den 32bit daten selektor (dein dseg) da reinladen. ich hoffe mal der dseg-selektor ist dein dritter (wenn man so zählt, dass der null-selektor der erste ist).

das:

Code: [Auswählen]

xor ax,ax
mov es,ax
mov ds,ax
müsste also so lauten:

Code: [Auswählen]

mov ax, 0x10
mov es,ax
mov ds,ax

was mir dabei einfällt ist, dass ich mir nicht sicher bin ob man im FRM die selektoren überhaupt ändern darf. ich habe das nie getestet, aber ich habe die vermutung, dass wenn du mov ax, 0x10 und dann mov ds, ax oder so machst, dass du dann keinen selektor mehr lädst, sondern ein normales, langweiliges 16bit-segment. das werd ich mal testen...

meine ICQ#: 173196533

in dem teil, das ich gelesen habe stand aber, dass man dem assembler mitteilen muss, wenn man 32 bit benutzt...

jepp, du musst ihm sagen in wieviel bit der code geschrieben ist. und das ist im flat real mode 16bit. sonst wäre es schon protected mode. die bits bei den daten operationen verklickerst du dem assembler ja schon, indem du statt ax, si, di usw. einfach eax, esi, edi usw. schreibst.

edit: übrigens schreibst du ziemlich viel von deinem arbeitsspeicher voll mit int 0x67, function 6. von 0x10000 schreibst du ein halbes megabyte (0x80000) voll. pass auf, dass du dein programm nicht dabei erwischst.   ich hoffe mal, du hast dein programm unter 0x10000 oder über 0x90000 geladen.

mfg porkchicken

1607

Lowlevel-Coding / Merkwürdiger Fehler bei INT 13h

« am: 01. December 2004, 19:33 »

ich glaub er meint den wert des segment registers es

1608

Lowlevel-Coding / Dateizugriff auf FAT32 Festplatte

« am: 01. December 2004, 17:48 »

Wenn du scharf darauf bist das mit Asm zu machen, kannst du dir mal die Sourcen von MenuetOS anschauen. Das ist auch in Assembler geschrieben.

Ich würd aber mal behaupten es ist einfacher ein FS in C zu schreiben, weil es sonst dann doch unter Umständen etwas unübersichtlich werden könnte.

-> MenuetOS: http://www.menuetos.org/
-> Verschiedene Dokumente zu FAT32: http://www.nondot.org/sabre/os/articles/FileSystems/

1609

Lowlevel-Coding / Mappen und dismappen

« am: 01. December 2004, 17:40 »

hi

wenn du im flat real mode bist muss der gesamte code 16bit code sein. nur die datenaddressierung ist 32 bit. also ich würde erstmal die ganzen [BITS 32] und [BITS 16] rausmachen.

du lädst ds und es (schon wieder ) mit einem offset. in ds und es kommen nur selektoren. in esi und edi kommen die offsets.

btw, statt
mov ax, cx
mov bx, 0x08
mul bx
würd ich eher schreiben:
mov ax, cx
shl ax, 3
spart ein reg

mfg porkchicken

1610

Lowlevel-Coding / Speicherbestückung überprüfen

« am: 01. December 2004, 17:28 »

zu 1. nein das hast du falsch verstanden. du lädst ds und es mit einem selektor. in deiner gdt sollte einer deiner selektoren ein 32bit datenselektor sein.

ds und es sind noch 16bit register, die aber einen sogenannten hidden part haben. in dem stehen die basis und das limit. wenn du einen wert in ds oder es lädst schaut die cpu in der gdt nach und liest dort basis und limit aus und schreibt es in diesen hidden part.

du lädst z.b. ds mit dem selektor 0x10, den du in der gdt zuvor als datenselektor mit basis 0x01000000 (16 MByte) und limit 0xFFFFF (4 GByte) festgelegt hast. wenn du dann in esi z.B. 0x100000 (=1 MByte) stehen hast und dann ein dword aus ds:esi einliest, kann hast du in eax den wert, der im speicher an 0x01100000 (=0x01000000 + 0x00100000, also 17 MByte) steht. Das echte Offset berechnet sich aus der Basis plus angegebenen Offset.

Ich hoffe das ist verständlich. ich weiss jetzt auch nicht wie ich das anders ausdrücken könnte.

zu 2.+3.: ja ich weiss, aber du fängst ja nicht bei 1 mb an sondern bei 0 (esi = edi = 00000000!).

nein du bist nicht unbedingt bei es = 0x10 auf 1 mbyte. 0x10 ist ein selektor. aus der 0x10 lässt sich nicht rückschließen wo du bist. das kommt drauf an was du in deiner gdt stehen hast.

1611

Lowlevel-Coding / Speicherbestückung überprüfen

« am: 30. November 2004, 20:47 »

Code: [Auswählen]

mov eax,0x100000
mov ds,eax
mov es,eax
das geht nicht. du versuchst da ds und es mit einem 32bit wert (soll wohl ein offset sein) zu laden. sie werden danach den wert 0 haben, weil sie 16bit register sind. (die oberen 16 bit sollten abgeschnitten werden) mich wundert dass du keine exception bekommst. du musst sie mit einem gültigen 32bit datenselektor mit basis 0x00000000 und limit 0xFFFFF (4GB) laden.

Code: [Auswählen]

check_ram_loop:
mov al,0x80
stosb
xor al,al
lodsb
cmp al,0x80
je check_ram_loop
diese schleife testet in 1 byte schritten! das ist ein bisschen langsam und sinnlos. besser wären schritte von 1 MByte. vor allem weil du das mit einer division sowieso nochmal in MByte umrechnest.  außerdem überschreibst du den gesamten arbeitsspeicher. du könntest wichtige datenstrukturen kaputt machen/beeinflussen! du solltest zumindest die einzelnen speicherstellen sichern, dann testen und dann wieder die "sicherung" zurückschreiben.

außerdem überschreibst du dein eigenes programm, denn du fängst bei 0 an. den startwert solltest du in edi und esi laden, nicht in die segment register. (aber eigentlich hättest du vorher eine exception bekommen müssen, weil du einen nullselektor geladen hast. vielleicht ist das ein bug in bochs, der denkt "0x100000 ist ungleich 0, also alles ok" oder so ...)

porkchicken

1612

Lowlevel-Coding / EMS und Int 0x67

« am: 28. November 2004, 13:07 »

Ja, die Expanded Memory Specification (EMS) mit dem emm386 ist eigentlich Extented Memory Specification (XMS), bzw. hängt da irgendwie dran. Ist einfach ein anderes Interface für doofe Programme die kein XMS sondern nur EMS können. (Denk ich mal.)

1613

Lowlevel-Coding / EMS und Int 0x67

« am: 28. November 2004, 11:16 »

Also das original EMS funzt ungefähr so:
In deinem PC steckt eine extra PCI-/ISA-Karte die mit 1 bis 2 MByte Arbeitsspeicher bestückt ist.
Mit einem speziellen Treiber kannst du dann an der Adresse D000:0000 max. 64KByte gleichzeitig davon dort einblenden. Das geht u.a. mit den LIM-EMS-Treiber (LIM ist ein Standard von Lotus (glaub ich), Intel und Microsoft) der an Int 0x67 hängt.

Es gibt aber noch emm386-Treiber, die auch an der Adresse D000:0000 Speicher zur Verfügung stellen. Aber wie der Name schon andeutet nur mit dem Protected Mode vom 386er funzen. DOS läuft dann im Virtual Real Modus und der Speicher wird mittels Paging zur Verfügung gestellt. Heutzutage (bzw. seit 10 Jahren) wird eigentlich nur noch diese Methode angewendet.

1614

OS-Design / Boch von echter CDRom booten lassen?

« am: 23. November 2004, 14:06 »

also theoretisch geht es so:

in deiner configurations datei bochsrc musst du folgende zeile einfügen/anpassen:

Code: [Auswählen]

ata0-slave: type=cdrom, path=e:, status=inserted

du musst das ata0-slave anpassen, je nachdem wo du das cdromlaufwerk in bochs haben willst, und path=e: halt entsprechend deinem cdromlaufwerksbuchstaben unter windows ändern.

mehr -> http://bochs.sourceforge.net/doc/docbook/user/bochsrc.html#AEN1252

da wo du warst, geht es um die einzelnen gastbetriebssysteme. der teil ist anscheinend nicht ganz fertig.

1615

Lowlevel-Coding / Fs, Ds

« am: 17. August 2004, 01:10 »

so ich hab mehr herausgefunden, was es mit dem Selektor 30h auf sich hat. Es hat laut meiner neuen Quelle, wirklich das Limit 1fff (und nicht 1) und zeigt auf die processor control region (PCR). Was auch immer das sein soll.

Ach ja meine Quelle:
comp.lang.asm.x86
Da stehen auch noch ein paar andere interessante Selektoren beschrieben.

1616

Lowlevel-Coding / Fs, Ds

« am: 16. August 2004, 21:45 »

Tja, was Limit 1 sein soll, weiss ich auch nicht.

Das mit Basis=0, Limit=4GB ist durchaus richtig, weil ja immer noch das Paging aktiviert ist, was das Herumgeschreibe in fremden Speicherbereichen verhindert. Wenn du mal bei einer normalen Windowsanwendung dir DS, ES und SS ausgeben lässt, steht in denen übrigens auch 0x23.

1617

Lowlevel-Coding / Fs, Ds

« am: 15. August 2004, 22:04 »

Hi,

also der Selektor 0x23 (genauer gesagt der 0x20 und RPL=3, oder so) ist ein Data-Selektor (RW) mit Basis=00000000, Limit=000fffff und DPL=3.
Der Selektor 0x30 ist schon spannender: Basis=ffdff000, Limit=00000001, und DPL=0. Und wieder Data (RW). Was das sein soll, weiss ich nicht. Sieht aber nett aus.
Quelle: Powerpoint-Präsentation: Operating Systems Case Study Windows 2000 (NT) von Greg O'Shea, Microsoft Research. 22 Februar 2000 (Google könnte helfen.)

MfG PorkChicken

1618

Lowlevel-Coding / Port Liste

« am: 07. March 2004, 12:45 »

In Ralf Browns Interrupt Liste ist auch eine Liste aller Ports der x86er dabei.

Ich weiss nicht genau welche der zip-Dateien die Liste enthält, aber die Portlisten heissen ports.a, ports.b und ports.c.

Ralf Brown's Interrupt List gibt es hier:

http://www-2.cs.cmu.edu/afs/cs/user/ralf/pub/WWW/files.html