Asm icompréhension

Résolu/Fermé
r00t3r - Modifié le 10 oct. 2018 à 19:06
 Utilisateur anonyme - 11 oct. 2018 à 21:32
Bonjour,

Bonjour j'aivais une petite question, j'ai réalisé cette routine ci-desous qui récupére une input du clavier puis la stocker dans un buffer qui pointe sur DS:SI , je suis en 16 bits en mode réel, je m'amuse juste rien de professionnel

; prompt 
prompt:
 ; reset buffer prompt
 mov ax, 0x00
 mov si, buffer
 mov cx, 0xff
 call memset

 ; PS
 mov si, ps
 mov bl, 0x02
 call print

.loopread:
 
 xor ax, ax
 int 0x16
 cmp al, 0x0D
 je .endread
 cmp cx, 0xff
 je .loopread
 mov [si], al
 inc si
 
 mov ah, 0x0E
 mov bx, 0x0002
 int 0x10
 inc cx 
 jmp .loopread

.endread:
 push esi
 mov bl, 0x02
 mov si, crlf
 call print

 mov bl, 0x02
 mov si, buffer
 call print
 
 mov bl, 0x02
 mov si, crlf
 call print

loopback:
 jmp prompt



Dans .loopread je récupére le char ASCII de l'interrupt 0x16 puis je le place sont contenu dans mon buffer jusque la rien alarmant si je tape :

foo
le buffer affiché sera foo

par contre si je tape :

foo et que je revien ensuite sur le premier "o" avec mon curseur pour rectifier par "far" mon buffer sera égale à :

far

mais ce que je comprend pas c'est que dans ma routine le registre SI est incrémenté mêe si le curseur de l'ecran soit a x ou x-5 le buffer avance pour moi je pensais avoir un bufer comme ceci :

fooar

je n'arrive pas à compendre, j'ai peut être loupé une chose ? je ne suis pas bloqué mais j'aimerais comprendre, je le l'ais pas debugger car le debugger console je trouve pas top, j'aurais aimer avoir la version gui de bochs mais je n'arrive pas à la lancer en mode graphique..

A voir également:
  • Asm icompréhension
  • N asm - Télécharger - Édition & Programmation

1 réponse

Utilisateur anonyme
Modifié le 10 oct. 2018 à 20:45
Bonjour

Quand tu dis que ton buffer est égal à far au lieu de fooar, l'as-tu vraiment vérifié dans le buffer, ou te fies-tu à l'affichage qui est fait à la fin de ton programme ?

À mon avis, dans ton buffer, il y a foo←←ar (où ← represente la touche qui faite reculer le curseur) et quand tu affiches ça, tu ne vois que far parce que le curseur recule comme quand tu as saisi.
0
Merci de ta réponse, oui j'ai vérifier le buffer en debut, car j'ai uen routine memset ou j'y est affecter "@" à mon buffer dans totalité et quand le buffer s'affciher il y avait ma chaine puis les "@"comme

foo@@@@@@@@@@....x251 \0

et le buffer et bien

far@@@@@@@@x251 \0 et non fooar@@@@@@@x249 \0

c'est pour cela que je ne comprenais pas, mais j'y est penser mais j'ai check le buffer.

Sinon ça fonctionne, mais bon c'est bien la première fois après réflexion pour moi y a une erreur est elle est logique et non... je me dit que c'est peut-être émilateur qui fait ça ?
0
Utilisateur anonyme
Modifié le 11 oct. 2018 à 12:01
Peux-tu montrer une copie d'écran de l'affichage en hexadécimal du contenu de la mémoire de ton buffer?
0
Je t'avais repondu un pavé mais une erreur de parsing à delete mon message surment donc je suis allé à l'éssentiel.

En faite je n'utilisé pas les Arrow mais avec les backspace :

Etat 0

0x000100bc <bogus+       0>:	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00
...
...
0x000101b4 <bogus+       0>:	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00


foo
0x000100bc <bogus+       0>:	0x00	0x66	0x6f	0x6f	0x5c	0x5c	0x5c	0x5c
0x000100c4 <bogus+       8>:	0x5c	0x5c	0x5c	0x5c	0x5c	0x5c	0x5c	0x5c
0x000100cc <bogus+      16>:	0x5c	0x5c	0x5c	0x5c	0x5c	0x5c	0x5c	0x5c
....
...
0x000101b4 <bogus+      16>:	0x5c	0x5c	0x5c	0x5c	0x5c	0x5c	0x5c	0x5c


Déjà mon premier byte reste à zero ^^.

après foo + ( backspace )*2 + ar

0x000100bc <bogus+       0>:	0x00	0x66	0x6f	0x6f	0x08	0x08	0x61	0x72
0x000100c4 <bogus+       8>:	0x5c	0x5c	0x5c	0x5c	0x5c	0x5c	0x5c	0x5c
....
...
0x000101b4 <bogus+      16>:	0x5c	0x5c	0x5c	0x5c	0x5c	0x5c	0x5c	0x5c


En faite lors de l'affichage les 0x08 backspace, puis repositionne les curseur du prompt et continue jusqu'au byte null

de la le : far

maintenant pour les arrows ils inscrivent des zéro dans le buffer.

0x000100bc <bogus+       0>:	0x00	0x66	0x6f	0x6f	0x00	0x00	0x08	0x08
0x000100c4 <bogus+       8>:	0x61	0x72	0x5c	0x5c	0x5c	0x5c	0x5c	0x5c
0x000100cc <bogus+      16>:	0x5c	0x5c	0x5c	0x5c	0x5c	0x5c	0x5c	0x5c
....
...
0x000101b4 <bogus+      16>:	0x5c	0x5c	0x5c	0x5c	0x5c	0x5c	0x5c	0x5c


donc ducoup j'ai interdit l'inscriprion de zero dans le buffer.

	cmp al, 0
	je .loopread


Pour le moment je m'en contente, surtout que c'est juste pour apprendre.

img de bochs : https://ibb.co/nBKJOp

je suis un peu honteux car j'ai l'habitude de toujour debugger, comme c'est en console...avec un peu de motivation.

Merci est désoler encore.
0
Utilisateur anonyme
11 oct. 2018 à 18:36
Donc tout est normal et se passe comme je te l'avais dit hier.
Sauf le premier octet à 0 : mais je vois que pour enregistrer les touches frappées, tu initialises SI avec ps et non pas avec buffer. ps ne serait pas égal à buffer+1 ?
0
Non c'est bon, BC c'est le 0 du buffer précedent de PS


section .data

	ps:
		db "wos@free:/$ ",0
	buffer:
		resb 	0xFF
	crlf:
		db 13,10,0


donc

bin.o

. TEXT
.DATA
kernelMgrBuff . ps ce termine en 0xBC . buffer . crlf

.END
0