Vorstellung

freecrac_ · Beitrag von **freecrac_** » Mi 21. Apr 2010, 11:56

Hallo, ich programmiere gerne kleine DOS-Anwendungen und helfe auch gerne anderen DOSianer dabei.

Dirk

Gast · Beitrag von **Gast** » Mi 21. Apr 2010, 12:01

Gast hat geschrieben:Hallo, ich programmiere gerne kleine DOS-Anwendungen und helfe auch gerne anderen DOSianer dabei.

Dirk

Ups, als Gast werde ich wohl nicht freigeschaltet. Hier nun meine Benutzername innerhalb der Rauten.

Dirk

Gast · Beitrag von **Gast** » Mi 21. Apr 2010, 12:16

Mein gewünschter Benutzername: "freecrac"

Dirk

DOSferatu · Beitrag von **DOSferatu** » Mi 21. Apr 2010, 12:43

Cool, noch ein DOS-Programmierer!
In welcher Sprache (oder Sprachen) programmierst Du denn?
(Ich programmiere halt auch unter DOS, deshalb interessiert mich das.)

Gast · Beitrag von **Gast** » Mi 21. Apr 2010, 13:35

DOSferatu hat geschrieben:Cool, noch ein DOS-Programmierer!
In welcher Sprache (oder Sprachen) programmierst Du denn?
(Ich programmiere halt auch unter DOS, deshalb interessiert mich das.)

Ich programmiere am liebsten Assembler und benutze MASM 5, oder MASM 6 (mit link.exe von MASM 5) und für ganz kleine Sachen nehme ich auch debug.
Ich habe dieses Forum gefunden als ich über google nach "Vesa" suchte. Neben vielen Beiträgen die ich selber über dieses Thema geschrieben habe fand ich hier auch solche Beiträge hier im Forum.
Bei diesem Thema habe ich selber noch offene Fragen and auch Antworten für jene die Rat suchen.

Für Vesa bevorzuge ich den Unrealmode/Bigrealmode(16 Bit Adressmode) um VBE3-Modi(auf meinen 19"-CRT mit eigenen Refreshrate bis 160hz) und mit linearen Framebuffer(bis zu 1920x1200x32) zu verwenden.
Erste Versuche mit hardware triple buffering erfolgten auf meiner GF4 TI 4200(64MB) in 1024x768x32@100hz.

...

So fing ich an ein DOSianer zu werden:
Meine ersten Versuche mit MSDOS 5(später dann 6 und 7) machte ich mit einem 80286, dann 80386 SX(mit FPU-Emulator). Bevor ich jedoch die DOS-Befehle näher kennen lernte, habe ich nur debug gestartet und damit versucht die dortige
CPU+Speicher-Landschaft zu ergründen. Als ich dann ein ungefähres Verständniss davon hatte wie sich ein X86er von einem C64er unterscheidet habe ich mir dann auch mal die Beschreibung der DOS-Befehle durchgelesen.

Wenn ich heute so zurückblicke habe ich die meisten Informationen über DOS die für mich relevant sind im "RBIL" gefunden.

Dirk

Beitrag von **ChrisR3tro** » Mi 21. Apr 2010, 19:48

Hallo Dirk und willkommen im Forum!

Habe deinen Account freigeschaltet. Viel Spaß bei uns!

Gruß,
locutus

freecrac · Beitrag von **freecrac** » Mi 21. Apr 2010, 21:49

Herzlichen Dank für die schnelle Freischaltung.

Dirk

DOSferatu · Beitrag von **DOSferatu** » Mi 21. Apr 2010, 22:13

Yeah!, ein Coder! Was hast Du denn schon so alles gemacht? Gibt's ne Webseite?

freecrac · Beitrag von **freecrac** » Do 22. Apr 2010, 01:05

DOSferatu hat geschrieben:Yeah!, ein Coder! Was hast Du denn schon so alles gemacht? Gibt's ne Webseite?

Ein Webseite mit Assemble-Demos für DOS hatte ich mal, das ist aber schon ein paar Jahre her.
Auch ist meine derzeitige HP(mit selbgebastelten Maps für Joint Operations(Egoshooter))bei meinem ISP offline. Ich habe schon einige Anfragen deswegen an mein ISP gesendet, leider bisher ohne Reaktion.

Was ich alles für DOS programmiert habe kann ich auf die Schnelle gar nicht sagen. Ich habe einiges über GraKas gelernt angefangen mit 16 Farb-Modi und benutze wenn es geht gar keine DOS-IRQs.
Ich frage PS2-Mouse lieber selber ohne Treiber ab und hole mir die Werte von der Tastatur lieber über Port-Zugriffe direckt vom Tastaturcontroller. In meiner Config.sys ist meist nur Himem.sys angetragen
aber kein emm386.exe und auch kein vergleichbarer Memmorymanager, da ich selber in den PM schalten möchte um in den Unrealmode zu gelangen. Ich benutze den physikalischen Speicher ab dem 65MB
bis 4GB(bzw. was dort oben nicht belegt und frei ist) für eigenen Anwendungen als Datenspeicher.

Dirk

DOSferatu · Beitrag von **DOSferatu** » Do 22. Apr 2010, 01:27

Ja, ich programmiere auch einiges lieber direkt und hardwarenah. Bei Maus hab ich noch nicht PS/2 benutzt - an meinem DOS-Rechner hängt eine Maus am seriellen Port (und serielle Maus hab ich auch schon "direkt" - also ohne Treiber - programmiert, aber das ist ja auch weiter kein Problem).
Und Tastatur frage ich mitunter auch lieber mit Portzugriffen ab - wenn man Tastatursteuerung für Spiele programmiert, muß man das ja sowieso...
Vielleicht interessiert Dich ja auch evtl. mein Zeug. Ein etwas größeres Projekt, das als Preview auf meiner Seite zu finden ist, ist mein Spiel "Xpyderz". Ist aber nicht in VESA, sondern in VGA programmiert (Mode X, 320x200).
Das Ding hatte ich vor vielen Jahren mal als kleines Nebenprojekt angefangen und später immer mehr verändert und Code ausgewechselt - aber trotzdem ist der Source (die Sourcen) dafür mittlerweile etwas Kraut- und Rüben... Man sieht es dem Teil zwar von außen nicht an, aber wenn ich die Sourcen jetzt so sehe und auch einiges, was ich da angestellt habe, würde ich das ganze Ding am liebsten noch mal von vorne coden...

Aber naja, genug von mir. Aber wenn Deine Webseite nicht erreichbar ist... Du hast doch sicher die Sachen nicht ausschließlich dort (im Internet) gelagert, sondern die von Dir entwickelten Sachen auch noch zu Hause. OK, will aber auch nicht nerven.

freecrac · Beitrag von **freecrac** » Do 22. Apr 2010, 18:03

DOSferatu hat geschrieben:Ja, ich programmiere auch einiges lieber direkt und hardwarenah. Bei Maus hab ich noch nicht PS/2 benutzt - an meinem DOS-Rechner hängt eine Maus am seriellen Port (und serielle Maus hab ich auch schon "direkt" - also ohne Treiber - programmiert, aber das ist ja auch weiter kein Problem).

Serielle Ports verwende ich schon lange nicht mehr. Mein neuestes Mainboard hat nicht mal mehr einen PS2-Mouseanschluss, deswegen habe ich mir ein PS2-to-USB-Adapter besorgt und im BIOS USB-legacy auf enable gestellt. So kann ich die PS2-Mouse auch weiterhin unter DOS wie eine Mouse die am PS2-Anschluss eingesteckt wurde abfragen.

Und Tastatur frage ich mitunter auch lieber mit Portzugriffen ab - wenn man Tastatursteuerung für Spiele programmiert, muß man das ja sowieso...

Ich mache es z.B. so:
Tastaturabfrage über Port:

Code: Alles auswählen

; Zum Anfang schalte ich den Tastastatur-IRQ ab:
          cli                          ; Software-Interrupts ausschalten
          mov      al, 2           ; IRQ 1 sperren
          out       21h, al
          sti

; Hauptschleife:

P1:
          in       al, 64h  ; Tastatur-Status holen
	  test     al, 1
	  jz  P1
	  test     al, 20h
	  jnz P1  ; wenn PS2-Mouse weiter
	  in       al, 60h  ; Tasten-Code holen
	  cmp      al, 1  ;  Escape ?
	  jz  XRAUS
;---------------------------------------------
;  E x t r a - T a s t e n   a b f r a g e n
;---------------------------------------------
	  mov      si, OFFSET SONTAB   ; Zeiger auf Extra-Tasten-Tabelle
	  mov      cl, Extablen        ; länge
XSUCH:    cmp      al, [si]            ; Taste suchen
	  jz  XFOUND                   ;  gefunden ?
	  lea      si, [si+1]
	  dec      cl
	  jnz XSUCH
;---------------------------------------------
;  T a s t e n   a b f r a g e n
;---------------------------------------------
	  mov      si, OFFSET TASTTAB  ; Zeiger auf Tasten-Tabelle
	  mov      cx, tablen          ; länge
	  mov      bx, OFFSET TEXTTAB  ; Offset auf Text
SUCH:     cmp      al, [si]            ; Taste suchen
	  jz  short FOUND              ;  gefunden ?
	  lea      si, [si+1]
	  dec      cx
	  jnz SUCH
	  jmp  P1
;---------------------------------------------
FOUND:

;---------------------------------------------
XFOUND:

;---------------------------------------------
XRAUS:

; Zum Ende schalte ich den Tastastatur-IRQ wieder an:
          cli
          xor      al, al              ; IRQ 1 freigeben
          out      21h, al
          sti
          mov      ah, 1            ; Tastatur-Puffer löschen
          int    16h

;---------------------------------------------
;  Datenbereich
;---------------------------------------------
TASTTAB DB 02h,03h,04h,05h,06h,07h,08h,09h,0Ah,0Bh,0Ch,0Dh
	DB 10h,11h,12h,13h,14h,15h,16h,17h,18h,19h,1Ah,1Bh,1Eh,1Fh
	DB 20h,21h,22h,23h,24h,25h,26h,27h,28h,29h,2Bh,2Ch,2Dh,2Eh,2Fh
	DB 30h,31h,32h,33h,34h,35h,39h
	DB 56h
tablen =  ($-TASTTAB)

TEXTTAB DB "1234567890ß'"
	DB "qwertzuiopü+as"
	DB "dfghjklöä^#yxcv"
	DB "bnm,.- "
	DB "<"
Textablen  =  ($-TEXTTAB)
;---------------------------------------------------------------------------
;          Tab,shift li.,shift re.,HOME,UP,LEFT,RIGHT,END,DOWN
;----------
SONTAB  DB 0Fh,2Ah,36h,47h,48h,4Bh,4Dh,4Fh,50h
Extablen  =  ($-SONTAB)
	DB 0,0,0
SHIFT   DW 0

Vielleicht interessiert Dich ja auch evtl. mein Zeug. Ein etwas größeres Projekt, das als Preview auf meiner Seite zu finden ist, ist mein Spiel "Xpyderz". Ist aber nicht in VESA, sondern in VGA programmiert (Mode X, 320x200).
Das Ding hatte ich vor vielen Jahren mal als kleines Nebenprojekt angefangen und später immer mehr verändert und Code ausgewechselt - aber trotzdem ist der Source (die Sourcen) dafür mittlerweile etwas Kraut- und Rüben... Man sieht es dem Teil zwar von außen nicht an, aber wenn ich die Sourcen jetzt so sehe und auch einiges, was ich da angestellt habe, würde ich das ganze Ding am liebsten noch mal von vorne coden...

So geht es mir auch immer.

Aber naja, genug von mir. Aber wenn Deine Webseite nicht erreichbar ist... Du hast doch sicher die Sachen nicht ausschließlich dort (im Internet) gelagert, sondern die von Dir entwickelten Sachen auch noch zu Hause. OK, will aber auch nicht nerven.

Ich helfe gerne.

PS2-Mouse-Abfrage über int15h:
RBIL->inter61a.zip->INTERRUP.C

Code: Alles auswählen

--------M-15C200-----------------------------
INT 15 - SYSTEM - POINTING DEVICE BIOS INTERFACE (PS) - ENABLE/DISABLE
	AX = C200h
	BH = new state
	    00h disabled
	    01h enabled
Return: CF set on error
	AH = status (see #00522)
Note:	IBM classifies this function as required
SeeAlso: AX=C201h,AX=C207h,AX=C208h

(Table 00522)
Values for pointing device function status:
 00h	successful
 01h	invalid function
 02h	invalid input
 03h	interface error
 04h	need to resend
 05h	no device handler installed
--------M-15C201-----------------------------
INT 15 - SYSTEM - POINTING DEVICE BIOS INTERFACE (PS) - RESET
	AX = C201h
Return: CF set on error
	    AH = status (see #00522)
	CF clear if successful
	    BH = device ID
	    BL = value returned by attached device after reset
		AAh if device is a mouse
Notes:	after successful completion of this call, the pointing device is set
	  as follows: disabled, sample rate 100 Hz, resolution 4 counts/mm,
	  scaling 1:1, unchanged data package size
	this function should be called before rebooting the system (see
	  INT 15/AH=4Fh), since otherwise the mouse may behave erratically on
	  some systems after the boot.	Before calling this function, the 
	  caller should check that the INT 15h vector is in fact initialized
	  (on some very old machines the IVT may contain 0000h:0000h).
	IBM classifies this function as required
SeeAlso: INT 33/AX=0000h,AX=C200h,AX=C207h
--------M-15C202-----------------------------
INT 15 - SYSTEM - POINTING DEVICE BIOS INTERFACE (PS) - SET SAMPLING RATE
	AX = C202h
	BH = sampling rate
	    00h 10/second
	    01h 20/second
	    02h 40/second
	    03h 60/second
	    04h 80/second
	    05h 100/second
	    06h 200/second
Return: CF set on error
	    AH = status (see #00522)
SeeAlso: INT 33/AX=001Ch
--------M-15C203-----------------------------
INT 15 - SYSTEM - POINTING DEVICE BIOS INTERFACE (PS) - SET RESOLUTION
	AX = C203h
	BH = resolution (see #00523)
Return: CF set on error
	    AH = status (see #00522)

(Table 00523)
Values for pointing device resolution:
 00h	one count per mm
 01h	two counts per mm
 02h	four counts per mm
 03h	eight counts per mm
--------M-15C204-----------------------------
INT 15 - SYSTEM - POINTING DEVICE BIOS INTERFACE (PS) - GET TYPE
	AX = C204h
Return: CF set on error
	    AH = status (see #00522)
	CF clear if successful
	    BH = device ID
--------M-15C205-----------------------------
INT 15 - SYSTEM - POINTING DEVICE BIOS INTERFACE (PS) - INITIALIZE
	AX = C205h
	BH = data package size (1 - 8 bytes)
Return: CF set on error
	    AH = status (see #00522)
Note:	the pointing device is set as follows: disabled, 100 Hz sample rate,
	  resolution 4 counts/mm, scaling 1:1
SeeAlso: AX=C201h
--------M-15C206-----------------------------
INT 15 - SYSTEM - POINTING DEVICE BIOS INTERFACE (PS) - EXTENDED COMMANDS
	AX = C206h
	BH = subfunction
	    00h return device status
		Return: BL = pointing device status (see #00524)
			CL = resolution (see #00523)
			DL = sample rate, reports per second
	    01h set scaling at 1:1
	    02h set scaling at 2:1
Return: CF set on error
	    AH = status (see #00522)

Bitfields for pointing device status:
Bit(s)	Description	(Table 00524)
 0	right button pressed
 1	reserved
 2	left button pressed
 3	reserved
 4	0 if 1:1 scaling, 1 if 2:1 scaling
 5	device enabled
 6	0 if stream mode, 1 if remote mode
 7	reserved
--------M-15C207-----------------------------
INT 15 - SYSTEM - POINTING DEVICE BIOS INTERFACE (PS) - SET DEVICE HANDLER ADDR
	AX = C207h
	ES:BX -> FAR user device handler or 0000h:0000h to cancel
Return: CF set on error
	    AH = status (see #00522)
Note:	when the subroutine is called, it is passed the following values on
	  the stack; the handler should return with a FAR return without
	  popping the stack:
		WORD 1: status (see #00525)
		WORD 2: X data (high byte = 00h)
		WORD 3: Y data (high byte = 00h)
		WORD 4: 0000h
SeeAlso: INT 33/AX=000Ch

Bitfields for pointing device status:
Bit(s)	Description	(Table 00525)
 15-8	reserved (0)
 7	Y data overflowed
 6	X data overflowed
 5	Y data is negative
 4	X data is negative
 3	reserved (1)
 2	reserved (0)
 1	right button pressed
 0	left button pressed
---------------------------------------------------

Für Treucolor-Modi benutze ich einen freigestellten Mousezeiger(Hintergrund schwarz) der in einem Targa-Bild(*.tga; 24Bit) enthalten ist und beliebige Ausmasse und Formen besitzen kann. Ich lade das Bild in den Speicher und lege mir vom Inhalt eine Tabelle an, wo von jedem gesetzten Pixel eine 4GB-Offset -Adresse(4Byte) und die Farbe(4 Byte) abgelegt wird. Meine Routine zum Positionieren des Mousezeigers braucht dann nur noch aus dieser Tabelle die Adressen und jeweiligen Farben herausholen und betreffende Pixel in den Framebuffer schreiben.
(Ohne Bankumschaltung kann der Mouszeiger ohne viel Aufwand sich quasi über mehrere Banken hinaus sich erstrecken und beliebig gestaltet sein.)

Beispiel-Codeschnipsel für PS2-Mouse im linearen Vesamode mit 32Bit-Truecolor:

Code: Alles auswählen

START:    mov      eax, 1              ; request for feature flags
       DB 0Fh, 0A2h                    ; CPUID instruction
	  test     edx, 00800000h      ;  is MMX feature flag(bit 23) set ?
	  jz  NOMMX                    ; NEIN, kein MMX

          call CHECKPS2
          jc  NOMOUSE
          call PS2ON
          jc  NOMOUSE

          call MREPOS                 ; Mousebegrenzung setzen(Hauptseite)
          cli
          mov WORD PTR[XACK], MXpos   ;  X-Pos. Maus  
          mov WORD PTR[YACK], MYpos   ;  Y-Pos. Maus
          sti

	  xor      ecx, ecx
	  xor      edx, edx
	  xor      ebx, ebx
	  xor      esi, esi
	  xor      edi, edi

	  mov      ebp, DWORD PTR[MAUEND]
	  call M1ST   

; ---Hauptschleife---

         call GETMPOS                 ; Mouse-Zeiger holen/setzen

;----------------------------------------------------------------------------
; Subroutinen
;----------------------------------------------------------------------------
 org START + ((($-START)/16)*16)+16             ; Code-Alignment
;------------------------------------------------------
CHECKPS2: int    11h                  ; get equipment list
          test    al, 3
          jz  short NOPS2             ; jump if PS/2-Mouse not indicated
          mov     bh, 3               ; data package size (1 - 8 bytes)
          mov     ax, 0C205h
          int 15h                     ; initialize mouse, bh=datasize
          jc  short NOPS2
          mov     bh, 3               ; 03h	eight counts per mm
          mov     ax, 0C203h
          int 15h                     ; set mouse resolution bh
          jc  short NOPS2
          mov     ax, cs
          mov     es, ax
          mov     bx, OFFSET PS2TEST
          mov     ax, 0C207h
          int 15h                     ; mouse, es:bx=ptr to handler
          jc  short NOPS2
          xor     bx, bx
          mov     es, bx              ; mouse, es:bx=ptr to handler
          mov     ax, 0C207h
          int 15h
          ret

NOPS2:    stc
          ret
;----------------------------------------------------------------------------
 org START + ((($-START)/16)*16)+16             ; Code-Alignment
;----------------------------------------------------------------------------
PS2ON:    call PS2OFF
          mov    ax, cs
          mov    es, ax
          mov    bx, OFFSET PS2IRQ
          mov    ax, 0C207h           ; es:bx=ptr to handler
          int 15h
          jc  short NOPS2
          mov     bh, 1               ; set mouse on
          mov     ax, 0C200h
          int 15h
          ret
;-------------------------------------
 org START + ((($-START)/16)*16)+16             ; Code-Alignment
;-------------------------------------
PS2OFF:   xor     bx, bx              ; set mouse off
          mov     ax, 0C200h
          int 15h
          xor     bx, bx
          mov     es, bx
          mov     ax, 0C207h          ; es:bx=ptr to handler
          int 15h
          ret
;----------------------------------------------------------------------------
 org START + ((($-START)/16)*16)+16             ; Code-Alignment
;----------------------------------------------------------------------------
PS2IRQ:   push    ds
          pusha
          mov     ax, DATEN
          mov     ds, ax
          mov     bp, sp
          mov     bx, [bp+22+6]   ; status byte(buttons,Sign,Overflow)
          mov     cx, [bp+22+4]   ; X movement
          mov     dx, [bp+22+2]   ; Y movement
          mov     ax, [XACK]
          test    bx, 10h         ; Sign X  Mouse goes right
          jz short MOGOR
          neg     cl
          sub     ax, cx
          cmp     ax, [BHMIN]     ; (Hmin) Mouse-Zeiger zu weit links ?
          jb  short IY0
;          test   bx, 40h          ; Overflow X
;          jz  short IY0
IX1:      jmp short IX2           ; X schreiben
;---------
MOGOR:    add     ax, cx
          cmp     ax, [BHMAX]     ; (Hmax) Mouse-Zeiger zu weit rechts ?
          ja  short IY0
;          test   bx, 40h          ; Overflow X
;          jz  short IY0
IX2:      mov     [XACK], ax
;---------------------------------
IY0:      mov     ax, [YACK]
          test    bx, 20h         ; Sign Y Mouse goes down
          jnz short MOGOU
          sub     ax, dx
          cmp     ax, [BVMIN]     ; (Vmin) Mouse-Zeiger zu hoch ?
          jb  short IIZ
;          test    bx, 80h         ; Overflow Y
;          jz  short IIZ
IY1:      jmp short IY2           ; Y schreiben
;---------
MOGOU:    neg     dl
          add     ax, dx
          cmp     ax, [BVMAX]     ; (Vmax)  Mouse-Zeiger zu tief ?
          ja  short IIZ
;          test     bx, 80h        ; Overflow Y
;          jz  short IIZ
IY2:      mov     [YACK], ax
;---------------------------------
IIZ:      and     bx, 3           ; only buttons, remove Sign + Overflow
          mov     [TACK], bx
;---------
          popa
          pop     ds
PS2TEST:  retf
;----------------------------------------------------------------------------
; Mousezeiger zum Bildschirm
;----------------------------------------------------------------------------
 org START + ((($-START)/16)*16)+16             ; Code-Alignment
;----------------------------------------------------------------------------
GETMPOS:  cli
          xor      ecx, ecx
          xor      edx, edx
          mov      cx, [XACK]          ; cx = X-Positon   holen
          mov      dx, [YACK]          ; dx = Y-Position  holen
          mov      bx, [TACK]          ; bx = Mouse-Taste holen
	  lea      ecx, [ecx*4]
	  lea      edx, [edx*4]
	  mov      [RETCLIC], bx
	  cmp      ecx, DWORD PTR[MX]
	  jnz short MSOI
	  cmp      edx, DWORD PTR[MY]
	  jz  NOMOUT                   ; wenn dieselbe Pos., dann nicht setzen

MSOI:     mov     DWORD PTR[MY], edx
	  mov      dx, Rast_Port
	  mov      bl, 8
	  mov     DWORD PTR[MX], ecx   ; Mouse-Zeiger setzen

RAST:     in       al, dx              ; Bewegung mit Raster-Strahl
	  and      al, bl              ; synchronisieren
	  jnz RAST
RASTER:   in       al, dx
	  and      al, bl
	  jz  RASTER

	  call RESTAU                     ; Mouse-Hintergrund restaurieren

M1ST:     mov      ebx, DWORD PTR[MY]     ; erster Mouse-Ansprung
	  mov      ebx, [ebx]             ; Zeilen-Offset holen
	  mov      esi, DWORD PTR[MAUHI1] ; Zeiger auf Rett-Sprite-Tabelle
	  add      ebx, DWORD PTR[MX]     ; plus X
	  mov     DWORD PTR[RETTPOS], ebx ; neue Bild-Position retten

OBJECT2:  mov      edi, [esi]             ; Offset aus Tabelle holen
	  mov      eax, [edi+ebx]         ; Farbe vom Bildschirm holen

	mov      ecx, [esi+8]
	DB 67h, 0Fh, 6Eh, 1Ch, 19h        ; movd mm3, [ecx+ebx]

	  mov      [esi+4], eax           ; Farbe in  Tabelle retten

	DB 67h, 0Fh, 7Eh, 5Eh, 0Ch        ; movd [esi+0Ch], mm3
	lea      esi, [esi+10h]
	  cmp      esi, ebp               ;  Ende erreicht ?
	  jb  OBJECT2

	  mov      esi, DWORD PTR[MAUKA1] ; Zeiger auf Sprite-Tabelle
	  mov      ebp, DWORD PTR[MAUHI1] ; Tabellen-Ende

OBJECT3:  mov      edi, [esi]             ; Adresse aus Tabelle holen
	  mov      eax, [esi+4]           ; Farbe  aus Tabelle holen

	mov      ecx, [esi+8]
	DB 67h, 0Fh, 6Eh, 5Eh, 0Ch        ; movd mm3, [esi+0Ch]
	lea      esi, [esi+10h]
	  mov      [edi+ebx], eax         ; Farbe zum Bildschirm

	DB 67h, 0Fh, 7Eh, 1Ch, 19h        ; movd [ecx+ebx], mm3

	  cmp      esi, ebp               ;  Ende erreicht ?
	  jb  OBJECT3
	  mov      bx, [RETCLIC]
 	  mov      ecx, DWORD PTR[MX]
	  mov      edx, DWORD PTR[MY]
NOMOUT:   sti
	  ret
;----------------------------------------------------------------------------
;  Mouse-Hintergrund  restaurieren
;----------------------------------------------------------------------------
 org START + ((($-START)/16)*16)+16             ; Code-Alignment
;--------------------------------------------
RESTAU:   mov      esi, DWORD PTR[MAUHI1]    ; Zeiger auf Rett-Sprite-Tabelle
	  mov      ebx, DWORD PTR[RETTPOS]   ; alte Bild-Position holen
	  mov      ebp, DWORD PTR[MAUEND]    ; Tabellen-Ende

RESTAU2:  mov      edi, [esi]                ; Offset aus Tabelle holen
	  mov      eax, [esi+4]              ; Farbe  aus Tabelle holen

	mov      ecx, [esi+8]
	DB 67h, 0Fh, 6Eh, 5Eh, 0Ch           ; movd mm3, [esi+0Ch]
	lea      esi, [esi+10h]
	  mov      [edi+ebx], eax            ; Tabellen-Farbe zum Bild-Bereich

	DB 67h, 0Fh, 7Eh, 1Ch, 19h           ; movd [ecx+ebx], mm3

	  cmp      esi, ebp                  ;  Ende erreicht ?
	  jb  RESTAU2
	  ret
;--------------------------------------------
 org START + ((($-START)/16)*16)+16             ; Code-Alignment
;--------------------------------------------
MREPOS:   cli
          mov WORD PTR[BHMAX], Hmax
          mov WORD PTR[BHMIN], Hmin
          mov WORD PTR[BVMAX], Vmax
          mov WORD PTR[BVMIN], Vmin
          sti
          ret

; Den Datenbereich und die dafür verwenden  Speicherstellen die dazu gehören lasse ich hier mal weg.

Initiallisierung: Mouse-Interruppt(siehe "PS2IRQ") über 15h anschalten.

Funktionsablauf der Mousepositionierung:
Ganz am Anfang vor dem ersten setzen des Mousezeigers wird der Bildhintergrund des Bereiches in eine Tabelle gerettet, wo die Pixel des Mousezeigers gesetzt werden sollen.(Siehe "M1ST") Diese Tabelle ist genauso aufgebaut wie der Mousezeiger: 32Bit-Offset-Adresse, Pixelfarbe, usw... Zum Positionieren des Mouszeigers werden die Positionsdaten die wir vom "PS2IRQ" bekommen geholt und verglichen ob es die selbe Position ist wie vorher. Fall das nicht der Fall ist wird auf das Ende des Rasterstrahls gewartet und dann der Bereich wo sich der Mouszeiger befindet restauriert, danach der neue Bereich gerettet und anschliessend der Mouszeiger gesetzt.

Dirk

wobo · Beitrag von **wobo** » Sa 23. Okt 2010, 12:30

Hallo freecrac (und alle anderen!),

Du benutzt ja den Unreal-Mode und hast ihn auch schon hier
http://www.dosforum.de/viewtopic.php?f=15&t=2921
ausführlich diskutiert und vorgestellt.

Da der Unreal Mode eigentlich nicht Thema des vorgenannten Topics war, stelle ich einfach meine Fragen hier bei Dir direkt, weil Du ihn auch im Rahmen Deiner Vorstellung angesprochen hattest...

1. Ich stelle den Unreal-Mode immer noch so ein, wie ich ihn erstmals 1990 in der Zeitschrift DOS International (Martin Althaus, "4 Gbyte im Real-Mode") kennengelernt habe. Dabei wird nur das Segment-Register GS auf 4 Gbyte ausgedehnt. Aussage damals in diesem Artikel und in der anderen Literatur bis 1995 war, dass man das Standard-Register DS nicht auf 4 Gbyte ausdehnen solle, weil es Software gäbe, die die 64k-Beschränkung voraussetzte.

Ich habe jetzt festgetellt, dass die Benützung des DS Registers auf meinem 386sx16 einen spürbaren Performanceschub bringt, wohl, weil die Benützung des DS - Registers die Intel-Befehle kürzer macht (nix genaues weiß ich nicht). Ich habe nun probeweise den Unreal-Mode über das DS-Register eingestellt und meine Software auf verschiedenen anderen PC und in der Dosbox getestet. Probleme hatte ich keine.

Da ich gelesen habe, dass Du den Unreal über das Register DS initialisierst, meine Frage: Hattest Du jemals Probleme, die Du darauf führtest, dass ein Programm einen 64k-Überlauf (o.ä.) beim DS-Register benötigte?

2. Beim Beenden Deines Programms stellst Du wieder die 64k-Beschränkung her? Ich habe jahrelang dies nicht getan (bei Verwendung des GS-Registers allerdings), d.h. nach Verlassen meines Programms blieb die 4 GByte-Erweiterung eingestellt. Probleme hatte ich bisher deswegen nie bemerkt, auch dann nicht, als in den 90ern mein PC stundenlang lief...

wobo

DOSferatu · Beitrag von **DOSferatu** » Sa 23. Okt 2010, 12:50

Ich kann erklären, woher das kommt.
FS und GS werden von reinen 16bit Programmen (für 286er und darunter) nicht benutzt, da nicht vorhanden.
DS ist das STandard-Datenregister, das immer benutzt wird. Weil es als Standard-Datenregister benutzt wird, braucht man im Maschinencode vor die Befehle kein Register-Override-Präfix-Byte setzen, wenn man DS benutzen will (außer bei Befehlen, deren indirekte Adressierung das Register BP enthalten, da ist das StandardSegmentregister nämlich SS). Weil das fehlende Präfixbyte die BEfehle kürzer macht, ist es auf einigen Rechnern dann schneller (die noch pro Befehlsbyte Zyklen brauchen)

Daß man auf 64k Segmentgröße zurücksetzt, kann wichtig sein, weil 16bit Programme davon ausgehen, daß die Adressen bei 16bit "wraparounded" werden und daher...
Wenn man zB im 4G Mode die oberen 16bits der Register EBX, EBP, ESI oder EDI auf etwas anderes als 0 setzt und dann im 16bit mit diesen auf etwas indirekt adressiert (davon ausgehend, daß nur die unteren 16 Bit (BX, BP, SI, DI) benutzt werden, dann landet man irgendwo anders, nämlich an der gewünschen Adresse plus 65536*obere16bit.
Auch im RealMode kann man übrigens seit 386er die Register in 32bit-Breite benutzen (und setzen etc) und ebenfalls die SegmentRegister FS und GS. Also sollte man IMMER, nachdem man den 4G Mode benutzt hat, sicherheitshalber wieder alles auf die Ausgangssituation setzen.
Meine Programme (obwohl 16Bit) beispielsweise, benutzen die 32bit Register und auch FS und GS. Die würden sich z.B. in die Hose machen, wenn eins der SegmentRegister auf 32-Bit-Address-Mode gesetzt wäre.

wobo · Beitrag von **wobo** » Sa 23. Okt 2010, 16:04

@DosFeratu:

Welche CPUs brauchen denn noch "pro Befehlsbyte Zyklen"? (Ich nehme an, Du meinst damit, dass die CPU für einen Befehl noch mehr als einen Taktzyklus braucht, wenn ich Dich richtig verstanden habe.) Mein 386sx16, aber auch mein 486dx40 sind jedenfalls spürbar schneller, wenn ich anstelle von gs/fs ds verwende.

Übrigens: habe gerade meine Flat4G - Unit Deinem Rat entsprechend angepaßt. Bei Verlassen des Programms wird jetzt das verwendete Segmentregister wieder auf 64k zuückgesetzt. Nicht daß ich mal ein Programm Deiner Homepage lade und dann klappt das nicht.

Außerdem wird jetzt auch die Adressleitung A20 wieder gesperrt, wenn sie vorher gesperrt war. Korrekterweise müßte man auch das Segmentregister nur dann auf 64k zurücksetzen, wenn es auch vor Aufruf des Programms auf 64k gesetzt war. Das aber abzufragen, dürfte nur im Protected Mode gehen und den rühre ich nicht an.

Meines Wissens ist es nämlich nicht immer so, daß die Register gs/fs stets auf 64k - Segmente gesetzt sind. Ich habe schon öfters gehört (genaues weiß ich nicht), dass es BIOSe geben soll, die zum Speichertest in den Flat4G/rm ("Unreal") schalten und die Register gs/fs auf 4GB belassen.

wobo

DOSferatu · Beitrag von **DOSferatu** » Sa 23. Okt 2010, 20:55

Ja, man sollte es so herstellen, wie es vorher war.
EMM386 benutzt ja auch andere Zugriffe als reines 16Bit.
Aber natürlich weiß ich, daß der 4G Mode nicht geht, wenn EMM386 schon läuft. Weil der in den Virtual86 Mode schaltet und von da aus kann dann ein anderes Programm nicht mehr.... usw
Und übrigens, weil Du sagst, daß Du den Protected Mode nicht anfassen willst....
EIGENTLICH schaltet man ja kurz in den Protected Mode, um überhaupt den 4G Mode zu aktivieren. Im 16bit Mode geht das ja garnicht.

Das mit den Zyklen pro Befehlsbyte... weiß grad nicht, ab welcher CPU Generation das nicht mehr gilt....
Aber davon abgesehen, irgendwo hab ich halt mal gelesen, daß frühere CPUs auf Befehle mit ihrem Standardsegmentregister (meistens DS) optimiert sind.
Und MÖGLICHERWEISE liegt das mit dem "mit DS läuft es schneller" daran, wenn die CPU einen recht kleinen Prefetch Queue hat und je kürzer die Befehle, umso mehr passen rein...

Vorstellung

Vorstellung

Re: Vorstellung

Re: Vorstellung

Re: Vorstellung

Re: Vorstellung

Re: Vorstellung

Re: Vorstellung

Re: Vorstellung

Re: Vorstellung

Re: Vorstellung

Re: Vorstellung

Re: Vorstellung

Re: Vorstellung

Re: Vorstellung

Re: Vorstellung