Posts by GunnerInc

Nobody is taught to use comments anymore? It is so important to comment your code in Assembly, ESPECIALLY in ancient 16bit code where functions don't have names but numbers!!

Your getting weird characters because after you get the input character, you are modifying it by adding 20h to dl.

To print each letter on a new line, you need to add a call to your nlcr in your y loop, but you must also save the register dx

This should get you started:

 main proc
        mov     ax,@data
        mov     ds, ax

        mov     ah, 9
        lea     dx, string
        int     21h

        call    nlcr

        mov     ah, 9
        lea     dx, string2
        int     21h

        mov     ah, 1       ; get user input
        int     21h
        mov     dl, al

        call    nlcr        ; print CRLF 

        mov     cx, 25      ; print 25 chars in loop
        inc     dl          ; adjust to print input char on 1st iteration
    PrintChar:
        mov     ah, 2       ; print char
        dec     dl
        int     21h

        call    nlcr        ; print CRLF

        loop    PrintChar   ; repeat loop until cx == 0

        mov     ah, 4ch     ; goodbye
        int     21h
    main endp

    nlcr proc
        push    dx          ; save dx since dl contains char to print

        mov     ah, 2
        mov     dl, 13
        int     21h

        mov     dl, 10
        int     21h

        pop     dx          
        ret
    nlcr endp

Yes, and also when writing an OS/boot loader. Unless a newbie is going to write an OS, they are better off at the beginning to skip 16bit unless they really need it, it is a PITA to learn verses 32bit.

Yes there IS a really BIG difference writing 64bit Assembly code verses 32bit code. Especially when it comes to Windows Programming (I am sure Linux is the same). You have a different calling convention, "shadow space", more memory addresses, more registers, stack should be/has to be aligned.

Learn 32bit first to get a firm understanding of how memory, cpu, program flow works. Then lean 64bit, skip 16bit it is dead.

Well, if you like MASM take a look at JWASM. It is fully MASM compatable (Meaning if you have an app written in MASM, JWASM will Assemble it without many complaints) Plus, it is 64bit compatible AND cross-platform

Right above the editor to enter a reply, you should see something like:

Has this thread been answered?
If this thread has been successfully resolved, please Mark this Thread as Solved so that it can be added to our Knowledge Base and help others. Also, posters who replied appreciate knowing that they were helpful.

My code that I posted works just fine:

10010000000100000000100111010011b (iPanda.asm, 12)
di = 8 (iPanda.asm, 31)

10010001100100011001100111010011b (iPanda.asm, 12)
di = 3 (iPanda.asm, 31)

10000000000000000000000000000001b (iPanda.asm, 12)
di = 30 (iPanda.asm, 31)

10000000000000000000000000000000b (iPanda.asm, 13)
di = 31 (iPanda.asm, 32)

00000000000000000000000000000001b (iPanda.asm, 13)
di = 31 (iPanda.asm, 32)

00000000001000000000000000000001b (iPanda.asm, 13)
di = 20 (iPanda.asm, 32)

10010001100100011001100111010011b (iPanda.asm, 13)
di = 3 (iPanda.asm, 32)

10010001100000011001100111010011b (iPanda.asm, 13)
di = 6 (iPanda.asm, 32)

Shr moves the least significant bit into CF either 1 or 0

How are you using the code and where? Are you adding it right after

notZero:

    shr a,1

jc notZero

because that is NOT needed, the code I posted does not need that.

Logic is a bit wrong.
No need for the variables biggest or counter. si = counter and di = biggest

This should work:

mov     cx, 32

NextOne:
    shr     a, 1
    jnc     ItsZero
    mov     si, 0
    jmp     Next
    
ItsZero:
    inc     si
    cmp     si, di
    jbe     Next
    mov     di, si
    
Next:
    dec     cx
    jnz     NextOne     

    ; display result in di here

Works for me:

1,1,1,1
2,2,2,2
3,3,3,3
4,4,4,4
5,5,5,5

:-)

You are telling WriteFile to write 40 bytes (your buffer size) so it will write what you grab from the console, write them to file then write nulls.

That second CreateFile is NOT needed! You already created the file, and have a handle to the file.
change your WriteFiles to:

invoke  Str_length, addr buffer
    INVOKE  WriteFile,		; write text to file
            fileHandle,		; file handle
            ADDR buffer,		; buffer pointer
            eax,		; number of bytes to write
            ADDR bytesWritten,	; number of bytes written
            0

Few things, why do folks who use Irvine, not use the correct case for the function calls? There is no such function as CRLF, instead it is Crlf. I don't know how the Irvine users don't get errors when Assembling!

Put your 2 buffers in the uninitialized data section - .data?
StringSize - we don't need it, why? ReadString returns the size of the string it reads in.

.data
pleaseEnter 	BYTE 'Please enter your name: ', 0
yourName	BYTE 'Hello, ', 0
reverseName 	BYTE 'Here is your name backwards: ', 0

.data?
StringName 	BYTE 30 DUP (?)
StringReversed	BYTE 30 dup (?)

.code
main PROC

    mov 	edx, OFFSET pleaseEnter
    call 	WriteString 
    
    mov 	edx, OFFSET StringName 
    mov 	ecx, SIZEOF StringName - 1

    call 	ReadString
    mov		ecx, eax     ; <<<<<<<<<<<<<< save the string length
    
    call 	Crlf
    mov 	edx, OFFSET yourName
    
    call 	WriteString
    mov 	edx, OFFSET StringName
    
    call 	WriteString
    call 	Crlf
    call 	Crlf
    
    mov 	edx, OFFSET reverseName
    call 	WriteString 

    lea		esi, StringName
    lea		edi, StringReversed
    dec		ecx ; <<<<<<<<<<<<<< Decrease the counter

@@:
    test	ecx, ecx
    js		Done	; <<<<<<<<<<<<<<  are we below zero?
    mov		al, byte ptr [esi + ecx] ; <<<<<<<<<<<<<< move the char in esi to al
    mov		byte ptr [edi], al ; <<<<<<<<<<<<<< now move into edi
    inc		edi ; <<<<<<<<<<<<<< increase pos of edi
    dec		ecx ; <<<<<<<<<<<<<<  decrease our counter
    jmp		@B ; <<<<<<<<<<<<<< reverse next char
    
Done:
    mov		edx, offset StringReversed
    call	WriteString
    call 	Crlf
    call	WaitMsg ; <<<<<<<<<<<<<< good to have so you …

Where is the rest of the code?

Nevermind

Uh, = is not equals it should be 2 equal signs == as in (ecx == 0) || (ecx == 2) etc...

The funny thing with macros (yes .if/.while are macros) is the error number will happen after the macro call...

Exactly what the error description says - you cannot nest procedures.

Try this instead:
INCLUDE Irvine32.inc

.data
 
	ccolor DWORD 13
	bcolor DWORD 16
	SetColor PROTO,cc:DWORD,bc:DWORD
	prompt BYTE "Hi",0
 
.code
main PROC
 
	INVOKE SetColor,ccolor,bcolor
	mov edx,OFFSET prompt
	call WriteString
	
	exit
main ENDP

SetColor PROC,cc:DWORD,bc:DWORD
		mov eax,cc
		add eax,bc
		call SetTextColor
		ret
SetColor ENDP
END main

Um, where do you want it displayed? On a billboard, command prompt, in the sky, DOS, in the dirt, windows? What OS does this display device use?

Your Fibo algo works fine.

It prints wrong because you are passing the wrong thing to the write file function

mov edx,OFFSET pointarray

this is wrong, this is a pointer to a pointer. Remove offset and it will work. Better yet, cut down on uneeded globals and just do

mov edx,offset array

fix that and it will write the proper file. You cannot open it in notepad and get the correct results, you can open in a hex editor or what the homework says.

Er, um, you are not writing what you want to write to the file!

;
; Writes a buffer to an output file.
; Receives: EAX = file handle, EDX = buffer offset,
; ECX = number of bytes to write
; Returns: EAX = number of bytes written to the file.

Line 44 eax, has the file handle from the return from CreateOutputFile BUT you are overwriting it with the contents of fileHandle which is 0. Change line 44 to:

mov    fileHandle, eax

Next, edx is supposed to be a pointer to the buffer to write to the file NOT the filename.

If you wrote a program in Assembly, then when you pass your code through the assembler you get a "one to one" translation (what you wrote in Assembly is what will be in the exe file), now if on the other hand, you thought you wrote in Assembly and passed your code through a compiler, then yes you will have more code in the debugger/disassembler.

Also, if you link to static libs in your program than yes, you will seem to have more code then you explicitly wrote since that code is added during the assembly process. The assembler you used could also add padding to your sections, procs, etc for alignment purposes, replace some mnemonics for optimization, you might be seeing relocations not sure without seeing your disassembly... but in general, what you write in assembly is what you will see in the debugger... (Not sure about 16 bit asm)

Probably line 31? You are trying to move a DWORD into a BYTE... in MASM it would be:

mov    al, BYTE PTR [ebx]

in this way the assembler knows we only want to move a byte from ebx to al.

Wait, HLA is backwards right? you are moving from al to ebx right? either way, BYTE PTR should be correct.

That 16bit code in the .code section will/should work with any 16bit assembler that uses Intel syntax which NASM/NASMX uses... What you need to find out is the differences in sections between TASM and NASM, and the differences in the header of the asm files. FASM works on Linux, you might want to look into that, or use GAS or something similar (EWWWW AT&T syntax), either way (FASM or NASM) you will need some modifications.

Well, you if you have 2 processors/cores and use CreateThread the OS decides which to use? Or you can look into SetProcessAffinityMask and SetThreadAffinityMask Windows API to delegate what processor/core you want to use