Greetings feom Syria, how is everything going you guys???
so I'm taking Assemblry language this semester, and am tottaly clueless with the IDE, I have some questions, hope you could help me:
am using win7, 32 bit so:
1- are the instructions used in MASM 6.11 work on MASM32 v11??? you know the one we could download from this site, the Qeditor?? in exactly the same syntax???
2- I still can't figure out what's wrong with this simple example:
.MODEL SMALL
.DATA
var1 db 33h
var2 dw 0101h
var3 dd 0aaaa5555h
include io.mac
.code
.386
mov ax,0
mov al,0ah
mov [bx],al
mov [bx+1],al
mov eax,12345678h
.exit
end
when I try to console Assemble and link this, the error A1000: cannot open file io.mac keeps appearing????
we have studied this in class and it worked just fine on WinXp 32 bit masm 6.11???? I mean any include I make (loke windows.inc and so) gives the same error???
3- when I delete this io.mac thing, a linking error appears:LNK2001, unresolved external symbol mainCRTstartup???? what in the world is that???
4- is there any courses I can follow??? you know that starts with me from the very beginning?
5- is debugging, tracing registers and memory locatons available in Qeditor???
thank you guys, LOVE YOU ALL
Sam,
The code you have posted is 16 bit DOS code and there are two problems, it most probably will not run on Win7 unless you use an XP emulator of some type and it will not directly build using MASM32 which is primarily for 32 bit Windows code. Find out what you university course work requires as 16 bit code is not much use any longer unless you run an old operating system version. MASM32 is for building 32 bit code and it comes with a reasonable amount of example code and help files.
Hi Sam,
Your code runs fine on Win7-32 if
a) you add the start: label,
b) you add end start
c) you use the 16-bit linker in \masm32\bin\link16.exe (Hutch will explain to you how to do that from qEditor - I use my own editor).
Greetings to Syria,
JJ
.MODEL SMALL
.DATA
var1 db 33h
var2 dw 0101h
var3 dd 0aaaa5555h
; include io.mac
.code
.386
start:
mov ax,0
mov al,0ah
mov [bx],al
mov [bx+1],al
mov eax,12345678h
.exit
end start
You expect me to remember a 16 bit OMF linker command line ? :biggrin:
Sam,
greetings to Syria and welcome to the forum.
Gunther
Quote from: hutch-- on November 04, 2013, 05:28:49 PM
You expect me to remember a 16 bit OMF linker command line ? :biggrin:
That is the simple part, Hutch:
\masm32\bin\link16 myfileThe less simple part is to do that from qEditor's menu, therefore I counted on you ;-)
Mutter, I have not played with 16 bit dos since 1994.
SAM.ASM
.386
.MODEL SMALL
.DATA
var1 db 33h
var2 dw 0101h
var3 dd 0aaaa5555h
;;; include io.mac ; you have to supply the file IO.MAC
.code
start: ; the start label
mov ax, 0
mov al, 0ah
mov [bx], al
mov [bx+1], al
mov eax, 12345678h
end start
Builds with the following batch file in the same directory,
@echo off
\masm32\bin\ml.exe /omf sam.asm
\masm32\bin\link16.exe sam.obj,sam.exe ,,, /nod /noe /packc /stack:4096
dir sam.exe
pause
on the link16 command line, you can place the switches before the file list
then provide the asm and exe names, seperated by commas
then, use a semicolon to tell the linker to use default responses for the rest of the required fields
if you recall, the old linker would prompt for inputs if the command line didn't provide them :P
the semicolon turns that off - useful in batch files
you are running 32-bit windows 7, so you should be able to run the program
the problem is - why is the instructor teaching 16-bit code ? - lol
the io.mac file is a macro file that you had on a previous exercise
perhaps provided by the instructor
make sure it is in the same folder as the asm file - or set the include path to where it does exist
i suspect you are going to want it, at some point
as for any courses to follow - i take it you mean tutorials
i am sure they exist - just don't know of too many for 16-bit, offhand
if you google around a little, you might find an old copy of Randall Hyde's Art Of Assembly online
not really a tutorial - it's a book that is presented in html form
http://cs.smith.edu/~thiebaut/ArtOfAssembly/artofasm.html (http://cs.smith.edu/~thiebaut/ArtOfAssembly/artofasm.html)
for old 16-bit code, you can use DEBUG or SYMDEB
again, google is your friend
What the EXE is missing is a program termination, vaguely it was int 21h function 4Ch but I don't think I have 16 bit reference material floating around and don't want it anyway.
This seems to be it.
mov ah, 4Ch
int 21h
.EXIT takes care of that, although i never use it
QuoteWhen the program terminates, you can return an exit code to the operating
system. Applications that check exit codes usually assume that an exit code of 0
means no problem occurred, and that an exit code of 1 means an error
terminated the program. The .EXIT directive accepts a 1-byte exit code as its
optional argument:
.EXIT 1 ; Return exit code 1
.EXIT generates the following code that returns control to MS-DOS, thus
terminating the program. The return value, which can be a constant, memory
reference, or 1-byte register, goes into AL:
mov al, value
mov ah, 04Ch
int 21h
If your program does not specify a return value, .EXIT returns whatever value
happens to be in AL.
it is, however, missing .STARTUP
again, i never use the macro
for a small model program, it will set the DS register to the @data segment, which is actually DGROUP
as shown, the current code does not access the data segment, so it's ok
but as soon as he tries to access one of the variables, he'll be wondering why it isn't right or crashes
Here is a small test piece that uses the simplified segment directives. Build it with the same batch file as above.
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
.model small
.dosseg
.stack 1024
; -----------------
; terminate the app
; -----------------
bye_bye MACRO
mov ah, 4Ch
int 21h
ENDM
.data
txt db "Howdy Sam, this is a",13,10, \
"small memory model DOS exe file$" ; the "$" terminates the string for DOS function 09h
.code
.startup
; ----------------------
; display a text message
; ----------------------
mov ah, 09h
mov dx, OFFSET txt
int 21h
bye_bye
;; .exit 0
end
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
this is what i use as a SMALL model template...
.MODEL Small
.STACK 4096
.DOSSEG
.386
OPTION CaseMap:None
;####################################################################################
.DATA
s$Msg db 'Hello World !',0Dh,0Ah,24h
;************************************************************************************
.DATA?
;####################################################################################
.CODE
;************************************************************************************
_main PROC FAR
mov dx,@data
mov ds,dx
mov dx,offset s$Msg
mov ah,9
int 21h
mov ax,4C00h
int 21h
_main ENDP
;####################################################################################
END _main
Here's another template, using the handle based I/O functions:
stdin equ 0 ; Standard Input Handle
stdout equ 1 ; Standard Output Handle
stderr equ 2 ; Standard Error Handle
cr equ 0dh ; ASCII Carriage Return
lf equ 0ah ; ASCII Line Feed
DGROUP group _DATA,STAK ; declaration automatic data group
_TEXT segment word public 'CODE'
assume cs:_TEXT,ds:DGROUP,ss:STAK
main proc far ; main procedure
mov ax, DGROUP ; make data segment addressable
mov ds, ax
mov ah, 40h ; write via handle
mov bx, stdout ; bx = Standard Output Handle
mov cx, msglen ; cx = string length
mov dx, offset msg ; ds:dx -> String
int 21h ; transfer to DOS
mov ax, 4c00h ; terminate
int 21h
main endp
_TEXT ends
_DATA segment word public 'DATA'
msg db cr,lf ; string to print
db 'Hallo Assembly Language World!'
db cr,lf
msglen equ $-msg ; string length
_DATA ends
STAK segment para stack 'STAK'
db 64 dup (?) ; 64 Byte Stack
STAK ends
end main
Gunther
What is the default setting for BX on DOS startup.. I cannot remember :biggrin:
Curious about these 3 lines
mov al,0ah
mov [bx],al
mov [bx+1],al
8)
i think ES:BX points to the environment table - i forget
AL and AH are FCB indicators 0 if empty, FF if filled (AL for first FCB, AH for second)
DS has the PSP segment
but, you're right, Van - he probably meant to initialize BX to point to the vars
meaning that DS must also be initialized
Dave,
Quote from: dedndave on November 05, 2013, 08:37:19 AM
i think ES:BX points to the environment table - i forget
that's right: es:bx -> program's environment block.
Gunther
Hi,
The "MS-DOS Programmer's Reference" says that DS and ES
point to the PSP when the program starts. The environment is
a different area in memory that has strings for the path and variables
that are set by the SET command for instance.
The Hugi contest had some information on the registers on program
load. Here is a cut and paste from their "GENERAL.TXT".
Quote=============================================================================
h u g i s i z e c o d i n g c o m p e t i t i o n
g e n e r a l i n f o
=============================================================================
QuoteYou may assume that
... the registers have these values (all in hex):
(xx - means an unknown value which MUST NOT be assumed)
EAX = xxxx****
AL = 00 if first FCB has valid drive letter, FF if not
AH = 00 if second FCB has valid drive letter, FF if not
EBX = xxxx****
BL = 00 if first FCB has valid drive letter, FF if not
BH = 00 if second FCB has valid drive letter, FF if not
ECX = xxxx00FF
EDX = xxxxxxxx
DX = CS = DS = ES = SS = xxxx, 0080 <= DX <=9000.
ESI = xxxx0100
EDI = xxxxFFFE
EBP = xxxx09xx
ESP = xxxxFFFE
EIP = xxxx0100
Regards,
Steve N.
hi Steve
those look like values for, possibly, a .COM program
however, i think you're right about ES:BX not pointing to the environment table
the segment for the environment block is in the PSP, someplace
the ES:BX thing may have applied for the Exec loader (i don't remember the INT number)
for a .COM program, CS = DS = ES = SS = PSP segment
for a .EXE program, CS = code, DS = ES = PSP, and SS = stack segment
as far as i recall, AX is the only general register that carried any info
the others were set to 0
when the CPU is reset, the DX register has something in it - i forget what
16-bit exe on Win XP SP3:
include \masm32\MasmBasic\DosBasic.inc ; download (http://masm32.com/board/index.php?topic=94.0) the complete MasmBasic library
PrintReg MACRO arg
pushad
mov ebx, arg
ifidn <arg>, <esp>
add ebx, 32
endif
Print Hex$(bx), " is &arg", 13, 10
popad
ENDM
Init ; DosBasic inspired by DednDave
PrintReg eax
PrintReg ebx
PrintReg ecx
PrintReg edx
PrintReg esi
PrintReg edi
PrintReg ebp
PrintReg esp
Inkey "bye" ; wait for a key
Exit ; ExitProcess, DOS style
end start
Output:
0FC2 is eax
0000 is ebx
00FF is ecx
0F85 is edx
0000 is esi
0200 is edi
091E is ebp
0200 is esp
your Init macro alters some registers
EAX, at least - that looks like the data segment :P
you might try
pushad
Init
mov ebp,esp
;[EBP+28] ;EAX
;[EBP+24] ;ECX
;[EBP+20] ;EDX
;[EBP+16] ;EBX
;[EBP+12] ;ESP
;[EBP+8] ;EBP
;[EBP+4] ;ESI
;[EBP] ;EDI
you can test AL and AH by filling the FCB's
C:\>programname somevalidfilename1 somevalidfilename2
Quote from: dedndave on November 05, 2013, 11:09:44 AM
your Init macro alters some registers
EAX, at least - that looks like the data segment :P
Thanks, that's right, but it concerns eax only:
mov ax, @DATA ; set the DS register to DGROUP
mov ds, ax ; for ds:si (lods)
mov es, ax ; for es:di (scas, stos)
Real eax is zero.
:t
what about PrintReg - it probably preserves everything
EDX looks like it might be the code segment
This is the structure from the Microsoft documentation... complete with the we-could-tell-you-what-they-are-but-then-we'd-have-to-kill-you members.
PSP STRUC
pspInt20 dw ?
pspNextParagraph dw ?
pspReserved1 db ?
pspDispatcher db 5 dup(?)
pspTerminateVector dd ?
pspControlCVector dd ?
pspCritErrorVector dd ?
pspReserved2 dw 11 dup(?)
pspEnvironment dw ?
pspReserved3 dw 23 dup(?)
pspFCB_1 db 16 dup(?)
pspFCB_2 db 16 dup(?)
pspReserved4 dd ?
pspCommandTail db 128 dup(?)
PSP ENDS
Ralf has descriptions of the other fields, which vary from OS to OS of course :P
but, it's nice to see the "official" names - thanks Michael :t
it's a little nostalgic to see the old "STRUC" keyword - lol
Quote from: dedndave on November 05, 2013, 10:09:52 AM
hi Steve
those look like values for, possibly, a .COM program
Hi Dave,
Correct. For a size competition *.COM programs are smaller
than *.EXE. I just showed the other info to show what they had
found.
The MS-DOS reference only mentions the setting of AH, AL, the
segment registers, IP, and SP. The rest are not mentioned. ES,
and DS point to the PSP for both *.COM and *.EXE programs, as
you showed below. And as AH and AL are treated the same in
both program types, maybe the other registers would be also.
Quote
however, i think you're right about ES:BX not pointing to the environment table
the segment for the environment block is in the PSP, someplace
the ES:BX thing may have applied for the Exec loader (i don't remember the INT number)
for a .COM program, CS = DS = ES = SS = PSP segment
for a .EXE program, CS = code, DS = ES = PSP, and SS = stack segment
as far as i recall, AX is the only general register that carried any info
the others were set to 0
when the CPU is reset, the DX register has something in it - i forget what
The 386, and later, powers up with stepping information in DX
or EDX. This is from memory, with all the usual disclaimers.
Regards,
Steve N.
i'm going to go out on a limb, here, and say that
BX, CX, DX, SI, DI, and BP are undefined
Jochen shows they have some values in them
but, if you fire up a COM or EXE in DEBUG, they are mostly 0's
it uses BX:CX to show loaded file size - strictly a DEBUG thing
AX will be 0 unless you place some parsable filenames on the command line
this is a DOS thing
Hi,
Yes, starting in DEBUG gives different results. That has bitten
me at least once. Though I cannot find anything that says what
or when it was.
But I did find a few other things. One of which is a link that has
some tests of various versions of DOS.
http://www.fysnet.net/yourhelp.htm
Regards,
Steve N.
i am going to update my EXE template
mov dx,@data
mov ds,dx
that way, the contents of AX are not destroyed
Jochen may want to make the same change in his Init macro
Quote from: jj2007 on November 04, 2013, 05:20:56 PM
Hi Sam,
Your code runs fine on Win7-32 if
a) you add the start: label,
b) you add end start
c) you use the 16-bit linker in \masm32\bin\link16.exe (Hutch will explain to you how to do that from qEditor - I use my own editor).
Greetings to Syria,
JJ
.MODEL SMALL
.DATA
var1 db 33h
var2 dw 0101h
var3 dd 0aaaa5555h
; include io.mac
.code
.386
start:
mov ax,0
mov al,0ah
mov [bx],al
mov [bx+1],al
mov eax,12345678h
.exit
end start
hey buddy so I did that and the editor went crazy I gave like tons of this error: A2044 invalid character in file, and it actually in this link16.exe
Quote from: hutch-- on November 04, 2013, 07:07:00 PM
Mutter, I have not played with 16 bit dos since 1994.
SAM.ASM
.386
.MODEL SMALL
.DATA
var1 db 33h
var2 dw 0101h
var3 dd 0aaaa5555h
;;; include io.mac ; you have to supply the file IO.MAC
.code
start: ; the start label
mov ax, 0
mov al, 0ah
mov [bx], al
mov [bx+1], al
mov eax, 12345678h
end start
Builds with the following batch file in the same directory,
@echo off
\masm32\bin\ml.exe /omf sam.asm
\masm32\bin\link16.exe sam.obj,sam.exe ,,, /nod /noe /packc /stack:4096
dir sam.exe
pause
thanks my frnd for ur help
so waht am I suppposed to do with this batch thing?? am I supposed to just copy it to the code??
Quote from: hutch-- on November 04, 2013, 11:45:45 PM
What the EXE is missing is a program termination, vaguely it was int 21h function 4Ch but I don't think I have 16 bit reference material floating around and don't want it anyway.
This seems to be it.
mov ah, 4Ch
int 21h
yeah but isn't the .exit directive supposed to do that????
Quote from: dedndave on November 06, 2013, 02:18:42 AM
i am going to update my EXE template
mov dx,@data
mov ds,dx
that way, the contents of AX are not destroyed
Jochen may want to make the same change in his Init macro
One byte shorter, and it keeps all regs (why is trashing dx better than trashing ax?):
push @data
pop ds
push ds
pop es
because AX has information in it
AL = 0 if first FCB empty, FF if first FCB has a parsed filename
AH = 0 if second FCB empty, FF if second FCB has a parsed filename
the contents of DX seem to be undefined
but - nothing wrong with push/pop, really - a couple cycles slower, maybe :P
as for setting the ES register - better to leave that alone
or - set DS, save ES to a wPspSeg variable, then set it
DS and ES contain the PSP segment - and i don't remember a way to retrieve it afterwards
Quote from: hutch-- on November 05, 2013, 12:43:42 AM
Here is a small test piece that uses the simplified segment directives. Build it with the same batch file as above.
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
.model small
.dosseg
.stack 1024
; -----------------
; terminate the app
; -----------------
bye_bye MACRO
mov ah, 4Ch
int 21h
ENDM
.data
txt db "Howdy Sam, this is a",13,10, \
"small memory model DOS exe file$" ; the "$" terminates the string for DOS function 09h
.code
.startup
; ----------------------
; display a text message
; ----------------------
mov ah, 09h
mov dx, OFFSET txt
int 21h
bye_bye
;; .exit 0
end
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
thanks hutch when I tries to run that the following error happened:
A2006: undefined symbol:DGROUP
Quote from: dedndave on November 04, 2013, 09:12:11 PM
on the link16 command line, you can place the switches before the file list
then provide the asm and exe names, seperated by commas
then, use a semicolon to tell the linker to use default responses for the rest of the required fields
if you recall, the old linker would prompt for inputs if the command line didn't provide them :P
the semicolon turns that off - useful in batch files
you are running 32-bit windows 7, so you should be able to run the program
the problem is - why is the instructor teaching 16-bit code ? - lol
the io.mac file is a macro file that you had on a previous exercise
perhaps provided by the instructor
make sure it is in the same folder as the asm file - or set the include path to where it does exist
i suspect you are going to want it, at some point
as for any courses to follow - i take it you mean tutorials
i am sure they exist - just don't know of too many for 16-bit, offhand
if you google around a little, you might find an old copy of Randall Hyde's Art Of Assembly online
not really a tutorial - it's a book that is presented in html form
http://cs.smith.edu/~thiebaut/ArtOfAssembly/artofasm.html (http://cs.smith.edu/~thiebaut/ArtOfAssembly/artofasm.html)
for old 16-bit code, you can use DEBUG or SYMDEB
again, google is your friend
thanks for the course buddy, I think it's amazing
you might like the Bild.bat file i made a while back
http://masm32.com/board/index.php?topic=1770.0 (http://masm32.com/board/index.php?topic=1770.0)
Sam,
Assembling and linking a 16-bit DOS app from within the MASM32 Quick Editor is no problem. You simply create a makeit.bat file, and you can readily do this to from within the editor, store it in your working directory, and with your ASM source loaded into the editor select Makeit.bat from the Project menu. And in case it's not clear, "working directory" here means the directory where your ASM source is stored and where the object module, executable, etc will be stored.
For the ML 6.14 in the MASM32 package, or the later ML 6.15, the batch file to create a 16-bit EXE can be as simple as:
\masm32\bin\ml /c %1.asm
pause
\masm32\bin\link16 %1.obj;
pause
Note that the Create EXE makeit.bat command on the Script menu is for 32-bit executables.
Quote from: dedndave on November 06, 2013, 02:54:03 AM
DS and ES contain the PSP segment - and i don't remember a way to retrieve it afterwards
QuoteAnother way to obtain the PSP address, in DOS 5.0 and later, is to make a DOS call. If you load ah with 51h and execute an int 21h instruction, MS-DOS will return the segment address of the current PSP in the bx register.
(AoA (http://cs.smith.edu/~thiebaut/ArtOfAssembly/CH13/CH13-8.html#HEADING8-103))
However, I can't get that DOS call to work.
i remember having problems with that, back in the DOS 3.3 era
that's why i suggest storing the value from ES into a variable :P
along the lines of what Jochen was working with....
push @data
pop ds
mov wPspSeg,es
push ds
pop es
would seem simple enough
Quote from: dedndave on November 06, 2013, 02:54:03 AM
as for setting the ES register - better to leave that alone
or - set DS, save ES to a wPspSeg variable, then set it
DS and ES contain the PSP segment - and i don't remember a way to retrieve it afterwards
Hi Dave,
I see jj2007 beat me to it. Oh well.
There are MS-DOS functions 51H and 62H, "Get PSP Address".
62H was introduced with DOS 3.0. 51H was in earlier versions,
but undocumented until DOS 5.0. The address is returned in the
BX register. They call the same code. And I have used them,
usually 62H, and it worked for me.
Regards,
Steve N.
i see what my problem may have been
i tried it just now with SymDeb
and the value in BX does not jive with the current code segment
well, duh - it's probably the PSP segment for the SymDeb executable - not my little program :biggrin:
C:\DOCUME~1\Dave\Desktop => symdeb
Microsoft (R) Symbolic Debug Utility Version 4.00
Copyright (C) Microsoft Corp 1984, 1985. All rights reserved.
Processor is [80286]
-a
0EEF:0100 mov ah,51
0EEF:0102 int 21
0EEF:0104 int 20
0EEF:0106
-bp0 104
-g
AX=5100 BX=05E4 CX=0000 DX=0000 SP=F000 BP=0000 SI=0000 DI=0000
DS=0EEF ES=0EEF SS=0EEF CS=0EEF IP=0104 NV UP EI PL NZ NA PO NC
0EEF:0104 CD20 INT 20 ;BR0
-q
C:\DOCUME~1\Dave\Desktop =>
which is ok.....
but, if you want code that you can debug, use the value from ES :t
Quote from: dedndave on November 06, 2013, 04:48:31 AM
i see what my problem may have been
i tried it just now with SymDeb
and the value in BX does not jive with the current code segment
well, duh - it's probably the PSP segment for the SymDeb executable - not my little program
Hi Dave,
Ouch. Yeah, "Undocumented DOS" says that function just
returns the last value set. I guess the DOS loader does set it.
And SymDeb didn't bother.
Regards,
Steve
It was interesting that 16 bit programs will run on Win 7.
I had read that they would not.
Andy
they won't run on 64-bit windows, at least not without some help (like DosBox, etc)
Hi Dave,
I was trying to reproduce your failure in Reply #40. And failed.
I was using a program I wrote a while back, so it is an EXE, not
your COM. And there is some cruft from what I was doing from
back then. But the general idea should be the same, give or take.
Any idea what is going on? I hate it when things are not reproducible.
D:\MASM\WORK>..\symdeb test-reg.exe
Microsoft Symbolic Debug Utility
Version 3.00
(C)Copyright Microsoft Corp 1984
Processor is [80286]
-g1a
This program will display the initial register values on program start up.
Version 0.1 α
DS: ES: PSP Cmd#
0D8C: 0D8C
:AX=023A BX=0000 CX=01F1 DX=003A SP=0100 BP=0000 SI=0D00 DI=0000
DS=0DAC ES=0D8C SS=0D9C CS=0DB4 IP=001A NV UP EI PL NZ NA PO NC
0DB4:001A B462 MOV AH,62 ;'b'
-p
AX=623A BX=0000 CX=01F1 DX=003A SP=0100 BP=0000 SI=0D00 DI=0000
DS=0DAC ES=0D8C SS=0D9C CS=0DB4 IP=001C NV UP EI PL NZ NA PO NC
0DB4:001C CD21 INT 21
-p
AX=623A BX=0D8C CX=01F1 DX=003A SP=0100 BP=0000 SI=0D00 DI=0000
DS=0DAC ES=0D8C SS=0D9C CS=0DB4 IP=001E NV UP EI PL NZ NA PO NC
0DB4:001E 8BC3 MOV AX,BX
-
Tested in and out of DEBUG and SymDeb in a VDM, and in
and out of SymDeb in an NTVDM on Win2000.
Regards,
Steve N.
Edit 38 -> 40.
Steve,
Some say it's 51h, but both work (Win7-32, XP SP3):
0E18 is Psp0
0E18 is Psp()
0E18 should be Psp0, too
0E18 should be Psp0, too
push @DATA ; set the DS register to DGROUP
pop ds ; for ds:si (lods)
mov Psp0, es ; credits to Dave
push ds
pop es ; for es:di (scas, stos)
...
mov ax, 6200h ; ah=62h, al=0
int 21h
Print Hex$(bx), " should be Psp0, too", 13, 10
mov ax, 5100h
int 21h
Print Hex$(bx), " should be Psp0, too", 13, 10
For 51 & 62 documentation, see RBIL (http://www.ctyme.com/intr/rb-3140.htm)
Hi,
Fixed an error in Reply #44. Oops.
QuoteSome say it's 51h, but both work
Right, see Reply #39. "Undocumented DOS" used those in an
example, where they traced a DOS Int 21H function call through
to where it was executed. Both end up executing the exact same
code. In "Microsoft MS-DOS Programmer's Reference" it stated
"Functions 62h and 51h are identical." And both work for me
(Win2k, XP). But Dave showed a failure in Reply #40 that I could
not reproduce.
"Undocumented DOS" has an early copy of RBIL on a diskette,
and an excerpt of it in its appendix. And its main text covers a
bunch of DOS information that I have found useful. Though it
does not work well as a reference. (I often cannot locate
information that I know they covered in a reasonable amount of
effort.) While they mention some DOS problems, I do not
remember any relating to functions 51H and 62H.
Regards,
Steve N.
well - you are using a different version of SymDeb - that may be the issue
but - try again
notice that i entered the program in debug using the "a" command
that, alone, shouldn't matter
but, then notice the commands i used to set a breakpoint and execute
that should work with any version of SymDeb
also - you can use INT 21h, AH = 50h to set the PSP segment to any word value :P
so - it doesn't appear to be super-critical
Hi Dave,
By gosh. Keying it in the way you did, does fail. Well my version
didn't work quite like yours, but it did fail as I Proceeded though the
program. Weird, very weird. Does not explain what is going on.
But shows it is going on for whatever reason.
Thanks, I guess.
Regards,
Steve
ahh - that's interesting
that means that if SymDeb loads a program, it sets the PSP segment (probably using INT 21h, 50h)
if you don't load a program - or if you type one in manually, it doesn't make that change
at any rate, this behaviour may vary over different versions of SymDeb and Debug
and that's why i store the initial value of ES if i want to access the PSP later in the program
i guess, if you wanted to have a "better" debugger, you could modify it
when at the prompt, the PSP segment is set to that of SymDeb.exe
when tracing or executing, the PSP segment is set to that of the debug target
Hi Dave,
Okay, that explains things nicely. I should have noticed that
sequence of events.
Thanks,
Steve N.
back in the day, i had disassembled SymDeb and made a nice source i could modify :badgrin:
i simply wanted to eliminate the comments of the "u" unassemble command
i forget if they used INT 21h, AH=50h, or if they used the exec loader call
i would guess that the exec loader probably calls INT 21h, AH=50h