Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Debug.exe Memory location.

17 views
Skip to first unread message

Jean pierneef

unread,
Dec 26, 2022, 4:33:44 AM12/26/22
to
For the purpose of getting to grips with debug.exe on MSDOS 6.22 I have the following code example:

.model tiny
.data
msg DB 'test string',0
.code
start:
mov al,msg
end start

When I compile it with tasm /zi t.asm and link it with tlink t I get the following behaviour in debug.exe:

When pressing 'r' to show registers and next command, I get:

mov al,[0008] as the next instruction to execute.

I was expecting the memory location of 'test string' to thus be at ds:0008 but when I do:

d ds:0108

I find 'test string' there instead (and garbage at ds:0008).

Can somebody please explain why 0100h is 'subtracted' from 0108h when I do the 'r' command in debug.exe ?

Jean pierneef

unread,
Dec 26, 2022, 6:18:51 AM12/26/22
to
I have tried this on an MSDOS 6.22 running in Virtual Box (tasm v2.0, unknown debug.exe version) as well as on Doxbox (tasm 2.51, debug.exe 1.25 which I presume comes from some open source project).

I do not understand why "test string" is at location ds:0108h in memory, but why debug says it wants to mov 0008 into the al register. Why the discrepancy ?

wolfgang kern

unread,
Dec 26, 2022, 7:18:57 AM12/26/22
to
MOV AL,msg ;loads the low byte of the ADDRESS 0108 into AL
MOV AL,[msg] ;loads the content of this address

I don't know Tasm, it may need a keyword (ptr?) instead of brackets
__
wolfgang

R.Wieser

unread,
Dec 26, 2022, 7:34:00 AM12/26/22
to
Jean,

> Can somebody please explain why 0100h is 'subtracted' from 0108h
> when I do the 'r' command in debug.exe ?

It isn't subtracted. The "problem" is that DS is pointing at the programs
"header" (0x0100 bytes infront of the code), while CS is pointing at the
code itself. Using the "tiny" model you first need to load DS with
whatever is currently in CS.

Suggestion : do a "U DS:0100" and look at what you're getting. Do you
recognise it ?

Also do a "D DS:0 100" and see if you recognise it. To make the recognision
easier add a few arguments when you load your program into the debugger
("debug t.exe the quick brown fox")

Regards,
Rudy Wieser


JJ

unread,
Dec 26, 2022, 5:20:32 PM12/26/22
to
At program start, DS is initially set to the PSP - which may not be the same
as the program's data segment. Depending on the memory model, the program's
data segment may be same as the program's code segment. e.g. Tiny model.
Unless Tiny model is used, and the code starts at 100h, and the source is
compiled to a COM binary (i.e. with `tlink /t`), the program's code segment
will be different than the PSP segment.

Your code is not compiled into a COM binary, so PSP, data segment, and code
segment, are all different. At program startup, DS points to the PSP
segment. Not the data segment. For programs where its code and data segments
are different, the program must manually set the DS register to point to its
data segment. Usually, it's done at program startup like below.

mov ax, dgroup
mov ds, ax

DEBUG does not execute any of the program code when loading a program. So,
any program's initialization code, are not executed. Meaning that, the DS
register still point to the PSP, and not the data segment. Since your code
doesn't set the DS register to its data segment, below code:

mov al, msg

It takes data from the PSP, rather than the data segment.

Kerr-Mudd, John

unread,
Dec 28, 2022, 6:37:31 AM12/28/22
to
On Mon, 26 Dec 2022 13:05:38 +0100
wolfgang kern <now...@nospicedham.nevernet.at> wrote:

> On 26/12/2022 12:08, Jean pierneef wrote:
> > On Monday, December 26, 2022 at 11:33:44 AM UTC+2, Jean pierneef wrote:
> >> For the purpose of getting to grips with debug.exe on MSDOS 6.22 I have the following code example:
> >>
> >> .model tiny
> >> .data
> >> msg DB 'test string',0
> >> .code
> >> start:
> >> mov al,msg
> >> end start
> >>
> >> When I compile it with tasm /zi t.asm and link it with tlink t I get the following behaviour in debug.exe:
> >>
> >> When pressing 'r' to show registers and next command, I get:
> >>
> >> mov al,[0008] as the next instruction to execute.
> >>
> >> I was expecting the memory location of 'test string' to thus be at ds:0008 but when I do:
> >>
> >> d ds:0108
> >>
> >> I find 'test string' there instead (and garbage at ds:0008).
> >>
> >> Can somebody please explain why 0100h is 'subtracted' from 0108h when I do the 'r' command in debug.exe ?


I don't use masm; but if coding a .com I always start with:

org 0x100

> >
> > I have tried this on an MSDOS 6.22 running in Virtual Box (tasm v2.0, unknown debug.exe version) as well as on Doxbox (tasm 2.51, debug.exe 1.25 which I presume comes from some open source project).
> >
> > I do not understand why "test string" is at location ds:0108h in memory, but why debug says it wants to mov 0008 into the al register. Why the discrepancy ?
>
> MOV AL,msg ;loads the low byte of the ADDRESS 0108 into AL
> MOV AL,[msg] ;loads the content of this address
>
> I don't know Tasm, it may need a keyword (ptr?) instead of brackets


Masm needs

mov al,offset msg

IIRC.

--
Bah, and indeed Humbug.

Etienne Marais

unread,
Dec 29, 2022, 3:03:48 PM12/29/22
to
Thank you everybody for the replies.

The PSP 'header' does indeed explain what is happening here.

0 new messages