Assembler usw

ich schließ mich an

da schließ ich mich ma an ;)
kannste plz mal ein beispiel-proggy machen, das ein bild anzeigt ..wär echt nett :)

zu den bildern habich nochne frage....in dem, was zuletzt geschrieben wurde hörte es sich eher so an, als könne man die bmp-files direkt ausgeben... muss man sie denn nun compilen oder nicht?
 
gut ich setz mich nacher mal hin und schreib n beispiel... oder bei gelegenheit vieleicht gleich n tut zum thema...

is leider nur so das ich mein buch wo die register und so beschrieben werden verborgt hab.. naja ich find die infos auch im inet wenns is...

gut erstmal die restlichen biträge hier im forum und dann mach ich das...


und ja das bild wird NICHT rein kompiliert sondern direkt aus der bmp datei geladen...
 
gut wie versprochen zeig ich hier wie man im mode 12 die graka anspricht...

Code:
[bits 16]
[org 0x100]


call _SetMode12
call _ClrScreen

mov ax, 13 
mov bx, 3  
mov cx, 639

_loop1:
pusha
call _PlotPixel
popa
dec cx
jnz _loop1

mov ax, 1
mov bx, 5
mov cx, 639

_loop2:
pusha
call _PlotPixel
popa
dec cx
jnz _loop2

mov ah, 08h
int 21h
mov ah, 4ch
int 21h

_SetMode12:
  mov ax, 12h
  int 10h
  mov dx,03ceh
  mov ax,0205h
  out dx,ax
  ret

_ClrScreen:
  mov   ax, 0xA000
  mov   es,ax
  mov   di,00h
  mov   ax,00h
  mov   cx,19200
  rep   stosw
  ret

_PlotPixel:  ;ax = farbe ;bx = y koordiante ;cx = x koordinate
  push ax
  mov   ax,0xA000
  mov   es,ax
  mov   di,bx
  shl   di,6
  shl   bx,4
  add   di,bx
  mov   bx,cx
  shr   bx,3
  add   di,bx
  and   cx,7
  mov   ah,128
  shr   ah,cl
  mov   dx,03ceh
  mov   al,8
  out   dx,ax
  mov   dl,[es:di]
  pop   ax 
  mov   [es:di],al
  ret

es handelt sich um ein kleines beispielprogramm das 2 linien auf dem screen zreichnet, für euch interessant ist vermutlich die funktion _PlotPixel

wie man sieht reicht es nicht aus nur einfach die entsprechenden bytes im graphikspeicher anzusprechen, hier muss man auch entsprechend auf die graphikregister noch zugreifen... außerdem wichtig ist etwas was häufig vergessen wird und dann große probleme bereitet, nämlich das man zuerst das byte das man ändert LESEN muss bevor man es schreibt, ansonsten kann es sein das es auf ettlichen graphikkarten nicht funktioniert.

im prinzip jedoch passiert nichts anderes als das zuerst der offset berechnet wird, der dann in di gespeichert ist, dann ein schreibzugriff auf dem graphik controler ausgeführt wird, und dann das byte geschrieben wird..


es existiert natürlich für diese aufgabe auch eine bios funktion (ah = 0Ch - int 10h) diese ist jedoch NICHT zu empfehlen da die verarbeitungsgeschwindigkeit der bios funktion etwa 1/100 vom dem beträgt was sie bei einer sauber programmierten treiber funktion hatt... außerdem ist die treiberfunktion auch im pmode anwendbar, man muss einfach nur einen eintrag in der GDT erstellen der auf 0xA0000 zeigt und die konstante von 0xA000 auf den offset der GDT richten...
 
Zuletzt bearbeitet:
Hi chibisuke

Ist dieses Beispiel für NASM geschrieben?
Ich Frage, weil bei einen anderen Beispiel habe ich einen Teil von diesen Code gesehen und es gab damit probleme!

Ok ich wärde es mal Testen, falls ich wieder Hilfe brauche mit den modus 12
Schreib ich wieder

Danke;)
 
ja das ist NASM code...

auf lowlevel ebene benutz ich NASM, JLOC, ALINK, dJGPP, TC
nasm = assembler
jloc = relocator
alink = linker
djgpp = 32bit C++ compiler
tc = 16bit C compiler

alle beispiele die ich poste sind von mir getestet und auch mit dem NASM compiler kompiliert und bei bedanf mit alink gelinkt (nicht erforderlich bei den hier angegebenen beispielen)

die befehlsteile für den assemblier vorgang lautet:

nasmw -fbit -o datei.com datei.asm

entsprechend sollte auch der code keine probleme machen ;-)

ich häng das beispiel von gestern nochmal als assemblierte com datei an...
 

Anhänge

  • graph1.zip
    237 Bytes · Aufrufe: 49
hmm..schade..wieso denn?
haste so viel anderes zu tun?..oder is der code sooo lang?
..naja..hauptsache du machstes ;)

schon ma im voraus ;-)
 
zum einen weil ich auch andere arbeit hab als da beispielcode zu schreiben... immerhin hab ich nebenbei n komplettes MMO-RPG zu entwickeln...

auf der anderen seite, muss die ganzen bios funktionien für dateihandling nachschlagen und das dauert...

trotzdem hier mal ein stück pseudocode

OpenFile()
file = ReadFileIntoMemory()
CheckFileFormat(file)
BlitFile(file + bitmapheader)

wobei checkfileformat nur prüft ob das bitmap format für den screenmode auch angemessen ist, BlitFile tut nix anderes als das gesamte bild in den graphikspeicher zu kopieren und die graphikregister zu setzen

um das zu verstehen muss man den aufbau des BMP dateiformates kennen...
die BMP datei enthällt zuerst generelle informationen über das bitmap, den s.G. Header, den man beim blitten dann überspringen muss...
nachdem man ihn übersprungen hatt findet man die bitmap dateien wenn man glück hatt genau in dem format vor das man braucht, dazu muss einfach der screenmode und der bitmapmode angeglichen sein...
das heißt ein 256farb bitmap werde ich im idealfall im mode 13 blitten ein 16farb bitmap werde ich im idealfall im mode12 blitten...

und dann ist eigendlich die gesamte aufgabe noch das array als pixeln richtig im grpahikspeicher abzulegen...eventuell aufpassen wenn die breite des bitmaps ne andere is als die des bildschirms, denn dann kann man nicht direkt ein memcpy auf das gesamte anwenden, sondern muss zeile für zeile kopieren...
 
Zurück