so many questions, so many troubles

[jj2007]

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

[FORTRANS]

Hi,

   Fixed an error in Reply #44.  Oops.

Some 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.

[dedndave]

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

[FORTRANS]

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

[dedndave]

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

[FORTRANS]

Hi Dave,

   Okay, that explains things nicely.  I should have noticed that
sequence of events.

Thanks,

Steve N.

[dedndave]

back in the day, i had disassembled SymDeb and made a nice source i could modify   
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