Why ain't this code running properly?

2»

Comments

  • : : : [b][red]This message was edited by opiumdreamer at 2004-9-30 8:17:51[/red][/b][hr]
    : : : : How would you do this in TASM
    : : : : [code]
    : : : : mov di, OLDVID
    : : : :
    : : : : Maybe?
    : : : :
    : : : : mov di, offset OLDVID
    : : : : [/code]
    : : : :
    : : : : Just curious, I'm use to using NASM and I'm still learning myself. :-)
    : : : :
    : : :
    : : :
    : : : The first one is correct. I use masm syntax but assemble the code with tasm but for that matter, if using TASMs IDEAL mode the mov instruction would look exactly the same: mov dest,source
    : : :
    : : : mov di,offset VARIABLE would put the offset to VARIABLE into di as expected and in this case it is not wanted since I want to transfer the data from AL that will contain the current video mode after the [b]mov ah,0Fh[/b] has been executed and that is why i need to store that very value into the variable OLDVID or any other place. one does not always know what mode it was in when executed.
    : : :
    : : : (I'll send you the executable)
    : : :
    : : :
    : : :
    : :
    : : [red]Now[/red] I'm even more confused, gotta go back to the books before spamming the horse out of this place. just noticed when assembled those instructions in a previous post of yours concerning this matter.
    : :
    : : when assembling this
    : : [code]
    : : mov bx,OLDVID
    : : mov al,[bx]
    : : [/code]
    : :
    : : I get an error that says:
    : :
    : : [b]Assembling file: Prog5-5.asm
    : : mov bx,OLDVID
    : : **Error** Prog5-5.asm(116) Operand types do not match
    : : [/b]
    : : but when prefixing the offset in front of OLDVID it is legal as shown
    : : [code]
    : : mov bx,offset OLDVID
    : : mov al,[bx]
    : : [/code]
    : :
    : : [b]Tool completed successfully[/b]
    : :
    : : so it appears that, at least when using TASM,
    : : [code]mov reg,VARIABLE[/code]
    : : is not the same as
    : : [code]mov reg,offset VARIABLE[/code]
    : :
    : : :/
    : :
    : [green]
    : Looks like I might of misspoke in my later post. Since your compiling an .exe and not a .com you'll have to move the segment address of the ds into es for an string operation.
    :
    : So[/green]
    : [code]
    : mov ax, ds
    : mov es, ax
    : mov di, offset OLDVID
    : stosb
    : [/code]
    : [green]
    : That should be correct but I don't have much experience working in the segmented memory model. I'm still working on the realmode flat model.
    : [/green]
    :
    :

    Great, than we're both learning something despite the misunderstanings :) I haven't really made that decision yet, I mean in which mode to actually code yet. Have to keep on coding and reading in different styles through sleep and illness a couple of more months before I'll know what's best, so... now I'm just trying to make things work and I'm still fuzzy about why this sample code won't run as expected.

    But we'll drop this for now and I'm sure to be back :) I like this place and thanks again for a lot of fast help!
  • [b][red]This message was edited by CroW at 2004-10-1 6:5:37[/red][/b][hr]
    i prefer always using the OFFSET statement when loading an offset and bracket and PTR when loading from/to memory to make the code easier to read and clearer to understand:
    [code]
    mov ax,OFFSET MyVar ; loading AX with offset of MyVar
    mov al,BYTE PTR [MyVar] ; loading one byte from MyVar
    [/code]

    : When dealing with di and si you need to remember that di's default segment is es and si's default segment is ds.
    [red]
    NO, DI and SI both using DS as default segment.its just the string-commands LODSx/STOSx which change this.everything you load (with LODSx) comes from data-segment to (e)Ax and everything you store (STOSx) goes to extrasegment.the normal 'MOV' always uses DS when using indexed addressing.just using the SP/BP registers to access memory will result in SS register used as segment.
    [/red]

    another thing:

    you cannot MOV an offset to AL since offsets always 16bit/2bytes in dos realmode and 32bit/4byte under win32 and most protected-mode targets while segment-registers are always 16 bits large


  • : : hmm,any side-effects with turbo-debuggers graphics/mouse-system?does your code behave in single-step-mode different than running the code from TD without any breakpoints?
    : :
    : :
    : :
    : well, it skips back to windows (windows xp sp1) both when executing by pressing F9 and when stepping through with F8 with and without breakpoints.
    :
    : I have heard rumours (that's probably true but I haven't have them confirmed) that TD and it's mouse driver does NOT like the ntvdm in fullscreen mode, so there might be a driver issue there or such, however, it don't work properly. I run Windows 98 inside VM Ware, btw.
    : And you are off course right about MSDOS 6.22 :)
    :
    : Any ideas of how to get the program to "work" as described in xp?
    :
    :

    i noticed some problems under winxp without any SP.it wont run in any screenmode fitting in a window or a fullscreen under winxp.difficulty to work when having to scroll-around all the time ;)
  • : [b][red]This message was edited by CroW at 2004-10-1 6:5:37[/red][/b][hr]
    : i prefer always using the OFFSET statement when loading an offset and bracket and PTR when loading from/to memory to make the code easier to read and clearer to understand:
    : [code]
    : mov ax,OFFSET MyVar ; loading AX with offset of MyVar
    : mov al,BYTE PTR [MyVar] ; loading one byte from MyVar
    : [/code]
    :
    : : When dealing with di and si you need to remember that di's default segment is es and si's default segment is ds.
    : [red]
    : NO, DI and SI both using DS as default segment.its just the string-commands LODSx/STOSx which change this.everything you load (with LODSx) comes from data-segment to (e)Ax and everything you store (STOSx) goes to extrasegment.the normal 'MOV' always uses DS when using indexed addressing.just using the SP/BP registers to access memory will result in SS register used as segment.
    : [/red]

    [green] Your absolutely right. I did mean string operations using specifically those commands but thanks for clarifying.[/green]

    : another thing:
    :
    : you cannot MOV an offset to AL since offsets always 16bit/2bytes in dos realmode and 32bit/4byte under win32 and most protected-mode targets while segment-registers are always 16 bits large

    [green]
    True, his assembler is different than mine, and thats what threw me off, still learning myself you know. ;-) Anyways, I ran his program through debug and I couldn't find anything wrong with his code except what you pointed out earlier. Maybe you could give him some suggestions?
    [/green]

  • : [b][red]This message was edited by CroW at 2004-10-1 6:5:37[/red][/b][hr]
    : i prefer always using the OFFSET statement when loading an offset and bracket and PTR when loading from/to memory to make the code easier to read and clearer to understand:
    : [code]
    : mov ax,OFFSET MyVar ; loading AX with offset of MyVar
    : mov al,BYTE PTR [MyVar] ; loading one byte from MyVar
    : [/code]
    :
    : : When dealing with di and si you need to remember that di's default segment is es and si's default segment is ds.
    : [red]
    : NO, DI and SI both using DS as default segment.its just the string-commands LODSx/STOSx which change this.everything you load (with LODSx) comes from data-segment to (e)Ax and everything you store (STOSx) goes to extrasegment.the normal 'MOV' always uses DS when using indexed addressing.just using the SP/BP registers to access memory will result in SS register used as segment.
    : [/red]
    :
    : another thing:
    :
    : you cannot MOV an offset to AL since offsets always 16bit/2bytes in dos realmode and 32bit/4byte under win32 and most protected-mode targets while segment-registers are always 16 bits large
    :
    :
    :
    [green]Appearently the only way to load an offset if assembling with TASM, is to prefix the data which offset is to be loaded, with OFFSET, I noticed yesterday when trying to assemble a snippet without the offset prefix.[/green] So to me that has been the only way to do it since I never "knew better" and it looks as I shouldn't look for another way :)

    About SI and DI it made me a little suspicious too and a quick glance in the books confirmed your words about it defaulting to the data segment. However I didn't know about how the STOSx and LODSx instrucktions really work yet, I'm in an early learning state.

    And off course when you say it (as with everything else that one has to be told to understand ;-) ) the offset adress would not fit into an 8bit register :)

    Thanks for clarifying everything to me and others.

    Cheers
  • [code]
    mov ax,OFFSET MyVar ; loading AX with offset of MyVar
    mov al,BYTE PTR [MyVar] ; loading one byte from MyVar
    [/code]
    [blue]
    im using TASM for realmode dos and MASM for windows,my syntax works under both of them.

    not enough colors for all theese add-on comments :)
    [/blue]

    : [green]
    : True, his assembler is different than mine, and thats what threw me off, still learning myself you know. ;-) Anyways, I ran his program through debug and I couldn't find anything wrong with his code except what you pointed out earlier. Maybe you could give him some suggestions?
    : [/green]
    :
    :

  • : : : hmm,any side-effects with turbo-debuggers graphics/mouse-system?does your code behave in single-step-mode different than running the code from TD without any breakpoints?
    : : :
    : : :
    : : :
    : : well, it skips back to windows (windows xp sp1) both when executing by pressing F9 and when stepping through with F8 with and without breakpoints.
    : :
    : : I have heard rumours (that's probably true but I haven't have them confirmed) that TD and it's mouse driver does NOT like the ntvdm in fullscreen mode, so there might be a driver issue there or such, however, it don't work properly. I run Windows 98 inside VM Ware, btw.
    : : And you are off course right about MSDOS 6.22 :)
    : :
    : : Any ideas of how to get the program to "work" as described in xp?
    : :
    : :
    :
    : i noticed some problems under winxp without any SP.it wont run in any screenmode fitting in a window or a fullscreen under winxp.difficulty to work when having to scroll-around all the time ;)
    :

    [green]hehe yup that sucks[/green]

    But is it not strange that the code I posted does crash in Windows 98 under VMWare just giving me a CS:IP to the error that is all.
    Would you mind assembling the code and try it out no matter what OS you're running? (unless non-windows is used, :))

    If you have the time and will someday, please notify me what the results are. I'm moving on without getting into this problem any deeper. My knowledge is to bad yet and it is not very important, I'm just the kind of guy that want an explanation to why things don't work ( and work :))
  • : : : : hmm,any side-effects with turbo-debuggers graphics/mouse-system?does your code behave in single-step-mode different than running the code from TD without any breakpoints?
    : : : :
    : : : :
    : : : :
    : : : well, it skips back to windows (windows xp sp1) both when executing by pressing F9 and when stepping through with F8 with and without breakpoints.
    : : :
    : : : I have heard rumours (that's probably true but I haven't have them confirmed) that TD and it's mouse driver does NOT like the ntvdm in fullscreen mode, so there might be a driver issue there or such, however, it don't work properly. I run Windows 98 inside VM Ware, btw.
    : : : And you are off course right about MSDOS 6.22 :)
    : : :
    : : : Any ideas of how to get the program to "work" as described in xp?
    : : :
    : : :
    : :
    : : i noticed some problems under winxp without any SP.it wont run in any screenmode fitting in a window or a fullscreen under winxp.difficulty to work when having to scroll-around all the time ;)
    : :
    :
    : [green]hehe yup that sucks[/green]
    :
    : But is it not strange that the code I posted does crash in Windows 98 under VMWare just giving me a CS:IP to the error that is all.
    : Would you mind assembling the code and try it out no matter what OS you're running? (unless non-windows is used, :))
    :
    : If you have the time and will someday, please notify me what the results are. I'm moving on without getting into this problem any deeper. My knowledge is to bad yet and it is not very important, I'm just the kind of guy that want an explanation to why things don't work ( and work :))
    :

    im using winxp without any SP and win98 on my other.you can send me your code and ill test it here.

    [red]
    please check your mail
    [/red]
  • : : : : : hmm,any side-effects with turbo-debuggers graphics/mouse-system?does your code behave in single-step-mode different than running the code from TD without any breakpoints?
    : : : : :
    : : : : :
    : : : : :
    : : : : well, it skips back to windows (windows xp sp1) both when executing by pressing F9 and when stepping through with F8 with and without breakpoints.
    : : : :
    : : : : I have heard rumours (that's probably true but I haven't have them confirmed) that TD and it's mouse driver does NOT like the ntvdm in fullscreen mode, so there might be a driver issue there or such, however, it don't work properly. I run Windows 98 inside VM Ware, btw.
    : : : : And you are off course right about MSDOS 6.22 :)
    : : : :
    : : : : Any ideas of how to get the program to "work" as described in xp?
    : : : :
    : : : :
    : : :
    : : : i noticed some problems under winxp without any SP.it wont run in any screenmode fitting in a window or a fullscreen under winxp.difficulty to work when having to scroll-around all the time ;)
    : : :
    : :
    : : [green]hehe yup that sucks[/green]
    : :
    : : But is it not strange that the code I posted does crash in Windows 98 under VMWare just giving me a CS:IP to the error that is all.
    : : Would you mind assembling the code and try it out no matter what OS you're running? (unless non-windows is used, :))
    : :
    : : If you have the time and will someday, please notify me what the results are. I'm moving on without getting into this problem any deeper. My knowledge is to bad yet and it is not very important, I'm just the kind of guy that want an explanation to why things don't work ( and work :))
    : :
    :
    : im using winxp without any SP and win98 on my other.you can send me your code and ill test it here.
    :
    : [red]
    : please check your mail
    : [/red]
    :
    [blue]Mail is being continously checked every 2 minutes and I have recieved and replied to your mail. You should recive it any second unless you allready have :)
    [/blue]

  • [b][red]This message was edited by AsmGuru62 at 2004-10-2 5:38:5[/red][/b][hr]
    : so it appears that, at least when using TASM,
    : [code]mov reg,VARIABLE[/code]
    : is not the same as
    : [code]mov reg,offset VARIABLE[/code]

    [blue]They obviously can not be the same - offset means address, and no offset means the value. The error earlier may be due to mismatch of types - exactly what TASM says:
    [code]
    MOV BX, mode
    [/code]
    BX is 16 bits and if 'mode' is 8 bits (a byte defined as DB) - it will fail to compile.
    [/blue]


  • : [b][red]This message was edited by AsmGuru62 at 2004-10-2 5:38:5[/red][/b][hr]
    : : so it appears that, at least when using TASM,
    : : [code]mov reg,VARIABLE[/code]
    : : is not the same as
    : : [code]mov reg,offset VARIABLE[/code]
    :
    : [blue]They obviously can not be the same - offset means address, and no offset means the value. The error earlier may be due to mismatch of types - exactly what TASM says:
    : [code]
    : MOV BX, mode
    : [/code]
    : BX is 16 bits and if 'mode' is 8 bits (a byte defined as DB) - it will fail to compile.
    : [/blue]
    :
    :
    :
    I have understood that far and that is what confused me but as you probably read it turned out that you could do it that way with NASM. Anyway that was nothing that worried me for a long time, hehe.

    This post has gotten far enough from its original issue now but the only way I can get the code posted in the first post is to run it in DOSBox Shell.
  • Hi!

    For all it's worth:

    I'd just want to ask first what's the assembler and linker you're using?

    I ask because here's what I found out about your code:

    1) The source code when compiled as is, produces the same error you talked about. So what I did was to modify the code a bit, and compiled it to a .COM file, not an .EXE file:

    [red].MODEL small[/red] becomes [green].MODEL tiny[/green]
    [red].STACK 64[/red] is removed or commented out
    [green]ORG 100h[/green] is inserted immediately after [red].CODE[/red]
    [red]mov @ax,data[/red] is removed
    [red]mov ds,ax[/red] is also removed

    Thus, the resulting code is now:
    [code]
    .MODEL small
    ;.STACK 64
    ; DATA segment stays the same
    .CODE
    org 100h
    MAIN PROC ;programs entry point
    ;mov ax,@data ;load the data segment adress
    ;mov ds,ax ;assign adress to ds

    mov ah,0Fh ;get current video mode
    int 10h
    [/code]

    The code
    [code]
    mov ax,@data
    mov ds,ax
    [/code]
    is unnecessary since a TINY model assumes that the DS & ES (at least, am not sure if that's the case with SS) segments reside in the same segment as the CODE segment.
    Compile via the usual manner: [green]TASM prog5-5[/green]
    Link using the /t option (case sensitive) to generate a .COM file: [green]TLINK /t prog5-5[/green]

    [hr]
    2) I also found out that your code works as is, just make sure you're using the older versions of TASM & TLINK. When I compiled the code with TASM v2.01 & TLINK v3.01, lo and behold, it ran smoothly.

    Let me just point out that I'm currently running Win98SE with your code; if you're using XP then that might be another source of the problem because from what I read, WinXP's command prompt is no longer DOS, and any DOS graphics functions should be handled by your program.

    That's about it...
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories