assembler x86 16bit - masm windows: running my program via the debugger (cv) bring different result that without debuging

Question

I have got a project to do as a student and i was about to finish him when i occured a strange thing - when i running my program via the cv debugger i get diffrent result than by running it simply....

Here is my code, he suppose to do this thing :

.model small
.stack 100h
.data 
.code
time proc
     mov ah, 02ch
     int 21h 
     mov bl, ch 
     call printit
     ret 
time endp
printit proc 
     mov  al, bl
     aam               ; divide by 10: quotient in ah, remainder in al (opposite of DIV)
     add  ax, "00"
     xchg al, ah
     mov  dx, ax
     mov  ah, 02h
     int  21h
     mov  dl, dh
     int  21h
     ret 
printit endp 
print4register proc 
     mov cx, 0 
LOOP1:
     inc cx 
     cmp cx, 5 
     jge ENDLOOP
     mov dx, 0 
     mov bx, 16
     div bx 
     cmp dx, 9 
     jg ABCDE
     add dl, '0' 
     push dx 
     jmp LOOP1
ABCDE:
     sub dl, 10 
     add dl, 'A'
     push dx 
     jmp LOOP1
ENDLOOP:     
     pop dx 
     mov ah, 02h 
     int 21h 
     pop dx 
     int 21h 
     pop dx 
     int 21h 
     pop dx 
     int 21h
     ret 
print4register endp 
date proc
     mov ah, 02ah
     int 21h 
     mov bl, dl 
     call printit
     ret 
date endp
start:   
     mov cl, byte ptr ds:[80h]    
     mov bx, 82h 
     mov ax, ds:[bx]
     cmp al, 'T'
     je TIMET 
     cmp al, 'D'
     je DATED
     cmp al, 'I'
     je INTI 
     jmp FINISH
TIMET:
     inc bx 
     mov ax, ds:[bx]
     cmp al, 'I'
     je TIMEI
     jmp FINISH
TIMEI:
     inc bx 
     mov ax, ds:[bx]
     cmp al, 'M'
     je TIMEM
     jmp FINISH
TIMEM:
     inc bx 
     mov ax, ds:[bx]
     cmp al, 'E'
     je TIMEE
     jmp FINISH
TIMEE:
     call time
DATED:
     inc bx 
     mov ax, ds:[bx]
     cmp al, 'A'
     je DATEA
     jmp FINISH
DATEA:
     inc bx 
     mov ax, ds:[bx]
     cmp al, 'T'
     je DATET
     jmp FINISH
DATET:
     inc bx 
     mov ax, ds:[bx]
     cmp al, 'E'
     je DATEE
     jmp FINISH
DATEE:
     call date
INTI:
     inc bx 
     mov ax, ds:[bx]
     cmp al, 'N'
     je INTN
     jmp FINISH
INTN:
     inc bx 
     mov ax, ds:[bx]
     cmp al, 'T'
     je INTT
     jmp FINISH
INTT:
     inc bx 
     mov ax, ds:[bx] 
     sub al, '0' 
     add al, al 
     add al, al ; mul al, 4  
     mov di, 0 
     mov ah, 0 
     add di, ax 
     mov ax, 0h 
     mov es, ax 
     mov ax, es 
     mov si, es:[di]
     mov di, es:[di + 2]
     mov ax, di 
     call print4register
     mov dl, ':'
     mov ah, 02h 
     int 21h 
     mov ax, si
     call print4register         

FINISH:
     mov ah, 4ch
     int 21h
end start

The task:

Write the program "DO_ALL" that accepts a single parameter from the MS-DOS command line.

i.e. type in the dosbox:

C:> DO_ALL DATE

or

C:> DO_ALL TIME

to run your program with the command "DATE" or "TIME" respectively.

The DO_ALL program should figure out the appropriate command and perform as

follows:

DATE – present the date (use int21/2A) – present only the day

TIME – present the time (use int21/2C) – present only the hour

INTx (here x is 1 digit, for example INT4 or INT0) – print the CS:IP of the ISR

of interrupt number x.

Hint: use the information in the PSP to figure out the command (The last 2

fields)

Unfortuently, as I said, when i run it like that - cv DO_ALL INT4 i get this result - 043F:038E ( after running the program in the debugger ) .

And when I run it like that - DO_ALL INT4 i get this result - 0070:0008

Someone know what to do :((

My dos running results

Debuggers often need to do odd things (such as catching "Arithmetic overflow" which is what [int 4](http://philipstorr.id.au/pcbook/book2/intlist.htm) is for). So perhaps cv remaps certain interrupts as part of how it works under DOS? — David Wohlferd, Jul 06 '18 at 19:52
That is very likely normal behaviour, the debugger is also DOS program, and it executes your exe next, so the environment is already modified by the debugger, like your code has lot less free memory available, is loaded lot more into upper region of memory, and debugger can have its own ISRs installed... Debug your code to make sure the ISR address is correctly printed (like put there fake address values to try different values and verify your hex formatter), and that's it. You may even install your own INTx handler at the start of code just to see if the output is then as expected (as test). — Ped7g, Jul 06 '18 at 20:59
I loaded up codeview and can confirm some (not all) of the interrupts are redirected by the debugger. When viewing the interrupts directly starting at 0x0000:0x0000 your output does appear to be correct. — Michael Petch, Jul 06 '18 at 21:12
@MichaelPetch - So, what would be some 'safe' interrupts OP could use to test his code? — David Wohlferd, Jul 06 '18 at 21:23
If debugging with CV it seems to intercept all but one of the first 10 interrupts. INT8 doesn't appear to be redirected. In DOSbox it will likely point to the interrupt handlers in the 0xF000 BIOS segment (at least that is where they go on mine) — Michael Petch, Jul 06 '18 at 21:47

assembler x86 16bit - masm windows: running my program via the debugger (cv) bring different result that without debuging

0 Answers0