home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.asm.x86      Ahh, the lost art of x86 assembly      4,675 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 3,998 of 4,675   
   rick.c.hodgin@nospicedham.gmail.com to All   
   Re: Isn't this anomalous behavior? What    
   26 Dec 19 02:30:31   
   
   On Thursday, December 26, 2019 at 4:53:21 AM UTC-5, bilsch01 wrote:   
   > The code below writes 5 words to memory at 0x37000. I verified the words   
   > are there using code not shown (for simplicity), but it's easy to see   
   > that the words should be there. After that the 2 lines:   
   >   
   > 	mov si,3   
   >     	mov ax,word[fs:si]   
   >   
   > should put dd66 in ax register but instead it puts a byte from each of 2   
   > other words in ax, specifically 77bb. The routine at the end prints the   
   > result 77BB when it should print DD66.   
   >   
   > I have a situation where I really need something like this to work. How   
   > can I do it?   TIA.   Bill S.   
   >   
   > bits 16   
   > org 0x0000   
   >   
   > SECTION  .data   
   >   
   > fat5 dw 0xaa99,0xbb88,0xcc77,0xdd66,0xee55,0xff44   
   >   
   > SECTION  .text   
   >   
   > 	push 0   
   > 	pop ss   
   > 	mov sp,0x7aff   
   > 	push 0x1000   
   > 	pop ds   
   > 	push 0xb800   
   > 	pop es   
   > 	   
   > ; write 5 words to mem at 0x37000   
   >   
   > 	push 0x3700	   
   > 	pop fs   
   > 	mov di,0   
   > 	mov si,fat5   
   > 	mov cx,5   
   > fatlu:	mov ax,word[ds:si]   
   > 	mov word[fs:di],ax   
   > 	add si,2   
   > 	add di,2   
   > 	loop fatlu   
      
   You can use ds:[si] and es:[di] and some CPU features if you   
   want:   
      
           push    0x1000   
           pop     ds   
           push    0x3700   
           pop     es   
      
           mov     si,fat5   
           xor     di,di   
           mov     cx,5   
      
          ; May need to set the direction flag here   
       ==> rep     movsw   
      
   The one line removes several lines of loop code, provided you   
   are able to use ds: and es: instead of ds: and fs:.   
      
   > ; here's the test   
   >   
   > 	mov si,3   
   >     	mov ax,word[fs:si]   
   >   
   > 	push ax   
   > 	jmp vuhex	;prints 77BB   
   > 			;should be DD66   
   >   
   > ; prints 4 hex digits from stack   
   >   
   > vuhex:	pop ax		;4 hex digits   
   > 	mov di,3832	;l.r. corner   
   > 	mov cx,4	;;# of hex digits   
   > vh01:	rol ax,4	;hi digit on right   
   > 	push ax		;push rol'd ax   
   > 	and al,0x0f	;;masks right digit   
   > 	add al,'0'	;0 thru 9   
   > 	cmp al,'9'   
   > 	jbe vh02   
   > 	add al,0x7		;A thru F   
   > vh02:	mov byte[es:di],al   
   >   	inc di   
   > 	mov byte[es:di],0x0f	;blk/wht   
   > 	inc di   
   > 	pop ax		;pop rol'd ax   
   > 	loop vh01   
   >   
   > 	jmp $   
      
   Can you run this code in DOS and verify it's working there?   
   You can use a debugger to assist you, and it won't matter if   
   you destroy your runtime environment in DOS because you can   
   just reboot once you get what information you need from the   
   debugger.  I used to do things like this in the CodeView 3.x   
   debugger as it was faster than the 4.x series.   
      
   And then for my OS project, I wrote a tiny boot-time debugger.   
   It was essentially two 64 KB modules, one handling the debugger   
   logic, the other handling the disassembler.   
      
   I added some extra code at the start of my 512 KB boot sector   
   to read in the debugger and disassembler, each which existed   
   at a fixed location on disk, and read into a fixed locations   
   in memory.  After loading, I'd call the setup function and it   
   would hook into the appropriate interrupt vectors, and then   
   return and then I continue to boot up like normal.   
      
   It added about 70 bytes of code to my boot sector, but then I   
   had a full debugger available at boot time.  I could single-   
   step through my code, examine memory, alter memory, etc.   
      
   It only worked in 16-bit mode, as after I entered 32-bit mode   
   I had my own protected mode kernel debugger available, and   
   could use that.   
      
   I recommend finding / creating something like that to help you   
   out with all of your boot-time assembly needs.  The real-mode   
   debugger I wrote was able to be run and tested in DOS as a .COM   
   file using a custom loader to simulate the boot-time load.  I   
   used it to debug itself at various times. :-)   
      
   -----   
   I have the source code for my debugger if you're interested.   
   I called it xDebug.  It was written entirely in MASM 6.11d.  I   
   can put it up on my website if you'd like to download it.  If   
   so, let me know.   
      
   --   
   Rick C. Hodgin   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca