Nachrichten

561

Lowlevel-Coding / Bootloader

« am: 01. March 2004, 19:57 »

@bscreator

Das mit den Arrays kannst du so machen:

So erstellst du ein 100 byte langes Array dessen Startoffset "Test" ist:
Variable  db 0
times 99 db 0

Wenn du nun auf das Array zugreifen willst, dann machst du das wie folgt:

So schreibst du in das erste Element eine 9:
mov       [Variable  ],  BYTE 9

So schreibst du in das 6te Element eine 10:
mov       [Variable+5], BYTE 10

geschnallt?

562

Lowlevel-Coding / Bootloader

« am: 01. March 2004, 19:51 »

Zum Bootloader.


Dieser enthält nur die Minimalfunktionen um:
- Die FAT-Tabelle in den Speicher zu laden.
- Einträge aus der FAT-Tabelle zu lesen
- Das Root-Directory nach einer Datei zu durchsuchen
- Die Datei komplett in den Speicher zu lesen
- Die Datei auszuführen (Sprich an die Speicherstelle zu springen an welche die Datei geladen wurde).

Da ich mich auf die 512 Bytes begrenzt habe, blieb kein Platz mehr um in den PMode zu schalten.
Ich halte es auch nicht für Sinnvoll, da jeder ja seine eigen GDT für sein OS einrichten möchte/sollte. Und daher wäre es wohl blöd das im Bootloader vorwegzunehmen.


Sobald ich aber damit fertig bin, werde ich Code und Zusatztools mit denen man "bequem" in den PMode schalten kann im Resource-Center posten.

563

Lowlevel-Coding / osloader mit protected mode und vga

« am: 01. March 2004, 19:47 »

Ist zwar noch ziemlich in der Entwicklung. Jedoch schaltet es schonmal in den PMode.

Grafikmodus musst du aber selbst noch schalten lassen.

Einen Bootloader hab ich weiter oben auch gepostet.
Dieser läd dir zumindest eine binäre Datei in den Speicher. Dieser Datei muss aber selbst noch Code enthalten die in den PMode schaltet.

Dazu kannst du Ansatzweise diesen hier benutzen.
Der ist aber noch nicht ausgereift und ich empfehle es auch nicht umbedingt diesen 1 zu 1 zu kopieren.

Wenn der Code mal fertig ist, wird er im Resource-Center gepostet.

Code: [Auswählen]

[BITS 16]
    jmp        start
   
gdt_null:
    dw        0
    dw        0
    dw        0
    dw        0
   
gdt_code:
    dw        0xFFFF        ;Segmentgröße Byte 0/1
    dw        0            ;Segmentbasisadresse Byte 0/1
    db        0            ;Segmentbasisadresse Byte 2
    db        10011010b    ;Zugriffsberechtigungen
    db        11001111b    ;Zusatz + Segmentgröße Bits 16 - 19
    db        0            ;Segmentbasisadresse Byte 3
   

gdt_data:
    dw        0xFFFF
    dw        0
    db        0    
    db        10010010b
    db        11001111b
    db        0

gdt_end:    

gdt:
Limit    dw    0
Base    dd    0


start:
   
    cli

    mov        ax, 0x1000
    mov        ds, ax
    mov        es, ax
   
    mov        ax, cs
    and        eax, 0xFFFF
       
    shl        eax, 4            ;Physikalische Startadresse der GDT errechnen
    add        eax, gdt_null
    mov        [Base], eax
   
    mov        ax, cs
    and        eax, 0xFFFF
    shl        eax, 4
    mov        WORD [gdt_code+2], ax
    shr        eax, 16
    mov        BYTE [gdt_code+4], al
   
    mov        WORD [Limit], gdt_end - gdt_null
   
    lgdt    [gdt]
   
    mov        eax, cr0
    or        eax, 1
    mov        cr0, eax
   
    mov        eax, 0x10
    mov        ds, ax
    mov        ss, ax
    mov        es, ax
       
    db        0xea
    dw        PMODE
    dw        08h
   

[BITS 32]
extern    _main

global  _EnableA20Gate

;#######################################################################

PMODE:
    mov        esp, 0xFFFF
       
    jmp        PMODE
   
sti


;#######################################################################

_EnableA20Gate:
    cli
    push    ecx

.0:
    mov        ecx, 5
   
.1:
    mov        eax, 0
    in        al, 64h
    test    al, 00000001b
    je        .1
   
    mov        al, 0xD0
    out        64h, al
   
.2:
    mov        eax, 0
    in        al, 64h
    test    al, 00000001b
    jne        .2
   
    mov        eax, 0
    in        al, 60h
   
    push    eax

.3:
    mov        eax, 0
    in        al, 64h
    test    al, 00000001b
    je        .3
   
    mov        al, 0xD1
    out        64h, al
   
.4:    
    mov        eax, 0
    in        al, 64h
    test    al, 00000001b
    je        .4
   
    pop        eax
   
    or        al, 00000010b
    out        60h, al
   
.5:
    mov        eax, 0
    in        al, 64h
    test    al, 00000001b
    je        .5
   
    mov        al, 0xD0
    out        64h, al
   
.6:
    mov    eax, 0
    in        al, 64h
    test    al, 00000001b
    je        .6
   
    mov        eax, 0
    in        al, 60h
   
    test    al, 00000001b
    je        .Enabled
   
    loop    .0
   
.Failed:
    sti
    pop        ecx
    mov        eax, 0
    ret
   
.Enabled:
    sti
    pop        ecx
    mov        eax, 1
    ret



564

OS-Design / Konsole mit Assembler

« am: 01. March 2004, 19:43 »

Ich hab im Resource-Center einen Beispielcode für eine Console gepostet.

565

Das Wiki / Inhalte für nächstes Magazin

« am: 01. March 2004, 19:42 »

Naja ich stimme dir zu. Es ist immer ganz toll wenn man was schönes zu Gesicht bekommt auf dem Moni.

Aber darauf zielt es hier wohl nicht ab. Ich denke es sollte eher der Reihe nach gehen.

Erst wenn mal eine gescheite Konsole, das arbeiten mit Platte, Diskette und vielleicht ein paar anderen Hardwaresachen steht, kann man sich gedanken um eine GUI machen.

Weil man sollte das ganze schon etwas planen und nicht einfach drauf los hacken. Das führt zwar schnell zu Ergebnissen, jedoch sind diese meist sehr unausgereift und bieten kaum gute Erweiterungsmöglichkeiten.

Das ganze Gerüst (das man NICHT sehen kann) muss erstmal stimmen, bevor man darauf aufsetzt.

Wenn du dir mal angeschaut hast, wirst du sehen das das Handbuch zu VESA recht ordentlich ist.
Des weiteren kannst du aus dem PMode entweder garnicht oder nicht so einfach auf die VESA-Funktionen zugreifen, weil dieser über BIOS-Interrupts zu verfügung gestellt werden. Man müsste also entweder kurzzeitig in den Real-Mode zurückschalten oder einen Virtual86-Mode haben. Und dazu benötigt man schon wieder Multitasking.

Verstehst nun warum das nicht so einfach ist?

566

Das Wiki / gute grafik muss weg ?

« am: 01. March 2004, 19:37 »

@mastermesh

Klar ist das mehr Aufwand.
Aber es gibt bestimmt genug Leute die sich da hinsetzen würden

Vielleicht erinnert sich ja jemand. Für Duke Nukem 3D gabs mal einen recht coolen Leveleditor. Der war zwar auf Anhieb nicht so einfach zu bedienen, aber nachdem wir es raus hatten, haben ein paar Kumpels und ich uns immer gegenseitig neue Levels gebaut die wir dann im Singleplayer spielen konnten.
Das Ding war echt cool!

567

OS-Design / Protected Mode

« am: 01. March 2004, 18:30 »

Wenn Bedarf besteht, dann uppe ich auf meine HP das Intel Manual bezüglich der Opcodes.
Da steht genau drin wie die Befehle Codiert werden.
Hatte ich mir mal geladen, weil ich mir irgendwann mal nen eigene Assembler schreiben wollte.

568

Das Wiki / gute grafik muss weg ?

« am: 01. March 2004, 18:27 »

Story ist auch so ne Sache.
Das Spiel Call of Duty fand ich wirklich sehr gut! Absolut coole Action und Story!
Das Porblem ist halt das es zu linear ist. Man spielt es 1 oder 2 Mal durch und das wars.

Aber auf jeden Fall haben die sich da Mühe gegeben.

Ich finde man sollte es für Mods möglich machen auch theoretisch ein Singleplayergame zu erstellen, das zusammenhängend ist.

Das würde ein Spiel auf lange Zeit wohl sehr beliebt machen,
Die meisten Mods sind ja nur für MUltiplayer.

569

Das Wiki / Inhalte für nächstes Magazin

« am: 01. March 2004, 18:24 »

Ich hab mir mal die Mühe gemacht und das Intel Manual bezüglich System Programming durchgelesen.

Und da wollte ich ein Tut schreiben, was es so im PMode alles zu beachten gibt. Was für Optionen es da gibt, wie diese Funktionieren und halt auch wie man in den PMode schaltet.

Dazu hab ich bis jetzt auch schonmal ein kleines Konsolen-App geschrieben mit dem man sich bequem die Deklarationen für Descriptoren erstellen lassen kann.

570

Lowlevel-Coding / Simple Konsole

« am: 01. March 2004, 18:19 »

Während ich das FAT12 Tutorial geschrieben habe, hatte ich mir nebenher auch ein wenig 16 Bit Real-Mode Code geschrieben um das ganze auszuprobieren. Dabei hatte ich auch eine sehr simple Konsole entwickelt.
Da im Forum schon über eine solche Diskutiert wurde, möchte ich diese hier mal veröffentlichen.
Dazu muss ich sagen das sie leider nicht kommentiert ist und wohl auch sehr sehr spärlich ist. Jedoch hiflt es vielleicht dem einen oder anderen auf eine Idee zu kommen.

Hier zuerst die Variablen:

Code: [Auswählen]

COMMAND_Command    resb 256

COMMAND_CMD_Hello        db    "hello",0
COMMAND_CMD_ReadBootSec    db    "readbootsec",0
COMMAND_CMD_Reboot        db    "reboot",0

COMMAND_MSG_Invalid        db    "INVALID COMMAND!!",13,10,0
COMMAND_MSG_Hello        db    "Hello there!",13,10,0
Hier nun die Funktion, welche einen String von der Tastatur entgegennimmt und in die Variable COMMAND_Command schreibt.
Sobald Enter gedrückt wird, wird ein NULL-Byte an das Ende des Strings gesetzt und die FUnktion zum auswerten der Befehle aufgerufen:

Code: [Auswählen]

func_COMMAND_GetCommand:
    push    bp
    mov        bp, sp
   
    push    ax
    push    bx
    push    cx
    push    dx
    push    di
    push    es
   
    mov        bx, cs
    mov        es, bx

label_COMMAND_GetCommand_Start:
    mov        di, COMMAND_Command
    mov        bx, 0x0007
    mov        cx, 10
   
label_COMMAND_GetCommand_ReadChar:
    mov        ah, 0
    int        0x16
    cmp        al, 0x0D
    je        label_COMMAND_GetCommand_LastChar
    cmp        al, 0x08
    je        label_COMMAND_GetCommand_Backspace
    mov        ah, 0x0E
    int        0x10
    stosb
    dec        cx
    jcxz    label_COMMAND_GetCommand_LastChar
    jmp        label_COMMAND_GetCommand_ReadChar

label_COMMAND_GetCommand_Backspace:
    cmp        cx, 10
    je        label_COMMAND_GetCommand_ReadChar
   
    inc        cx
    dec        di
    mov        ah, 3
    mov        bh, 0
    int        0x10
    dec        dl
    mov        ah, 2
    int        0x10
    mov        al, 0x20
    mov        ah, 0x0E
    mov        bx, 0x0007
    int        0x10
    mov        ah, 2
    int        0x10
    jmp        label_COMMAND_GetCommand_ReadChar
   
label_COMMAND_GetCommand_LastChar:
    mov        al, 0
    stosb
    mov        ah, 0x0E
    mov        al, 0x0D
    int        0x10
    mov        al, 0x0A
    int        0x10
    push    COMMAND_Command
    push    ds
    call    func_STRING_ToLower
    add        sp, 4
    call func_COMMAND_ExecuteCommand

label_COMMAND_GetCommand_End:
    pop        ds
    pop        di
    pop        dx
    pop        cx
    pop        bx
    pop        ax
   
    mov        sp, bp
    pop        bp
    ret
Hier die Funktion welche die Befehle auswertet.
Es werden einfach der Reihe nach sämtliche Befehle mit dem eingegeben String verglchen und dann eine entsprechende Aktion ausgeführt:

Code: [Auswählen]

func_COMMAND_ExecuteCommand:
    push    bp
    mov        bp, sp
   
    push    ax

;--------------------------------------------------
   
    push    COMMAND_Command
    push    cs
    push    COMMAND_CMD_Hello
    push    cs
    call    func_STRING_CompareStrings
    add        sp, 8
    cmp        ax, 1
    je        label_COMMAND_CMD_Hello

   
    push    COMMAND_Command
    push    cs
    push    COMMAND_CMD_ReadBootSec
    push    cs
    call    func_STRING_CompareStrings
    add        sp, 8
    cmp        ax, 1
    je        label_COMMAND_CMD_ReadBootSec


    push    COMMAND_Command
    push    cs
    push    COMMAND_CMD_Reboot
    push    cs
    call    func_STRING_CompareStrings
    add        sp, 8
    cmp        ax, 1
    je        label_COMMAND_CMD_Reboot
   
    jmp        label_COMMAND_CMD_Invalid

;--------------------------------------------------

label_COMMAND_CMD_Hello:
    push    COMMAND_MSG_Hello
    push    cs
    call    func_STRING_PrintString
    add        sp, 4
    jmp        label_COMMAND_ExecuteCommand_End


label_COMMAND_CMD_ReadBootSec:
    call    func_FAT12_ReadBootSector
    jmp        label_COMMAND_ExecuteCommand_End


label_COMMAND_CMD_Reboot:
    db        0xEA
    dw        0x0000
    dw        0xFFFF    
;    jmp        label_COMMAND_ExecuteCommand_End


label_COMMAND_CMD_Invalid:
    push    COMMAND_MSG_Invalid
    push    cs
    call    func_STRING_PrintString
    add        sp, 4
    jmp        label_COMMAND_ExecuteCommand_End
   
;--------------------------------------------------
   
label_COMMAND_ExecuteCommand_End:
    pop        ax

    mov        sp, bp
    pop        bp
    ret
Bei Fragen bezüglich zum Code einfach hier posten.

571

Das Wiki / gute grafik muss weg ?

« am: 01. March 2004, 16:43 »

Schaut euch Doom, Quake oder UT an.

Meiner Meinung nach ist das Spielprinzip seit jeher immer das selbe. Lediglich die Grafik is besser geworden.
Und mit der ZEit find ich das einfach langweilig.

572

Lowlevel-Coding / Bootloader

« am: 01. March 2004, 16:05 »

Japp

Du könntest auch schreiben:
Variable db 0
times 100 db 0

So hättest du ein 101 Byte großes Array das am Offeset Variable beginnt.

Damit hättest du wohl auch keine Warnung mehr und du könntest also auch sehen wie groß das Array ist.

573

Lowlevel-Coding / Bootloader

« am: 01. March 2004, 15:25 »

Das ist nur eine Warnung und kein Fehler.
Das besagt nur das du ein Array erstellst, dessen Werte nicht initalisiert sind.
Das macht aber nix, da du das Array ja erst zur Laufzeit mit Buchstaben füllst und DANN erst benutzt.

Du kannst auch folgedendes machen:

Variable db "                       "

Sprich du erstellst einen String der mit lauter Leerzeichen gefüllt ist.
Damit hast du dann keine Fehlermeldung mehr. Jedoch ist es schwer zu erkennen wie groß dein Array ist.

Die Warnung kannst du also ignorieren. Ist nur ein Hinweis das du dich nicht fälschlicher weise darauf verlässt das den Array zu Beginn schon sinnvolle Daten enthält.

574

OS-Design / Konsole mit Assembler

« am: 01. March 2004, 15:22 »

Soll dein OS in PMode oder Real-Mode laufen?

AFAIK ist FDOS für den Real-Mode geschrieben und eine "Art Kopie" von DOS.

575

OS-Design / Protected Mode

« am: 01. March 2004, 15:21 »

ASM ist ansich purer Machinencode. Die Ausssage kann man als Wahr nehmen, weil ein Assembler jeden ASM-Befehl in genau einen Maschinenbefehl umsetzt.
Das heisst also, was du in ASM codest, das kommt auch bei Dissassembeln wieder raus.

Die Eingabeaufforderung muss nicht in ASM geschrieben sein. Aber zumindest ein paar Dinge zur Vorbereitng müssen in ASM realisiert werden.
So müssen zumindest mal interrupt-Handler für das Keyboard geschrieben sein. Und die benötigen auf jeden Fall assembler.
Wenn du erstmal die nötigen Funktionen für den Zugriff auf Platte/Diskette, das lesen und erstellen eines Dateisystems und das auslesen des Keyboardpuffers realisiert hast (das benötigt alles irgendwo ASM), DANN ist es sinnvoll eine Shell zu bauen. VOn dieser aus kannst du dann die nötigen ASM-Funktionen von einem C-Code aufrufen.

576

Das Wiki / Inhalte für nächstes Magazin

« am: 01. March 2004, 15:16 »

Alloa.

Ich denke es würde zu viel Aufwand machen gleich 2 Magazine zu entwickeln.
WIr bemühen uns ja extra die Artikel auch für Anfänger verständlich zu schreiben.

Zum Thema Protected Mode bin ich gerade am schreiben eines möglichst umfangreichen Tuts.
Allerdings kann das natürlich noch ein bisschen dauern.

Da werde ich dann auch Quelltexte und Zusatztools zum umschalten in den PMode beilegen.

Das mit der GUI denke ich hat noch ein bisschen Zeit.
Als erstes sollte man wohl mal eine einfache Shell bauen und ein Dateisystem sowie das lesen von Platte und Diskette integrieren.

GUI ist sehr aufwendig, da man dort wohl kaum um das Multitasking herumkommen wird, was auch nochmal ein großer Sprung sein wird.

Also habt bitte etwas nachsicht und fordert nicht gleich zu viel.

577

Das Wiki / Grub ??

« am: 01. March 2004, 15:13 »

Soweit ich weiß ist das ein Bootloader der auch mehrere OS laden kann.

Schau am besten einach mal bei Google nach GRUB. Soweit ich weiß gibts dazu ne eigene HP wo steht was das Ding alles kann.

578

Lowlevel-Coding / Bootloader

« am: 29. February 2004, 23:32 »

Variable resb 100

So erstellst du ein Array das 100 bytes lang ist.
Das erste Byte wird über das Offset "Variable" adressiert.
Alle weitere Bytes adressierst du mit einem Displacement.
Sprich Variable+1, Variable+2

Ich hatte mal eine Art Shell programmiert.
Da hab ich es so gemacht, das ich ein 100 Byte langes Array hatte.
Wenn eine taste gedrückt wird, wird das Zeichen in das Array geschrieben.
Wenn nun Return gedrückt wurde, so wird ein NULL-Byte hinter das letzte eingegebene Zeichen geschrieben.
So kannst du dann die Eingabezeile als String ansprechen.
Du musst natürlich überprüfen das nicht mehr als 99 Zeichen eingegeben werden, weil du ja noch Platz für das NULL-Byte brauchst.

Auch musst du berücksichtigen das man mit Backspace ein Zeichen löschen kann.

579

Das Wiki / Best of the Best

« am: 29. February 2004, 23:03 »

Ich denke ich Spreche für Alle wenn ich mich für dien Kompliment bedanke.

Ob es besser als jedes Buch ist, ist Ansichtssache.
Ich würde mal sagen es ist vielleicht besser auf die Leser zugeschnitten.

Wir sind ja alle keine Profis sondern haben selbst auf dem Gebiet noch einiges zu lernen

580

Das Wiki / gute grafik muss weg ?

« am: 29. February 2004, 22:44 »

Das Problem liegt wohl daran das es eine Menge Leute gibt die umbedingt immer Hammerqualität in der Grafik sehen möchten. Und eine 3D-Engine die wirklich gut aussieht benötigt wohl auch eine Menge Entwicklungszeit.
Und da kommt dann wohl das Leveldesign zu kurz. Auch sind die Entwicklungskosten relativ hoch.

Dennoch ist das natürlich keine Entschuldigung.
Gerade eben hatte ich mir mal das Spiel Bad Boys 2 angeschaut. Ich fands grauenvoll. Sowohl vom Gameplay als auch von der Grafik sieht es aus wie sonstwas. Da kam absolut keine Freude auf.
Das ist auch ein Manko. Da wird wohl hauptsächlich mit dem bekannten Filmnamen versucht die Kunden zu locken. Siehe dazu auch Terminator 3. Habs selbst nicht probiert, aber laut Aussagen von anderen scheint es echt schlecht zu sein.