Hi,
I just looked at the recent SVN commits to fix that CALL 5 stuff. The new
commentary about it contains some errors. I'm appending the things I would
improve about it. It's not meant to annoy you, although I imagine it
could. (Does it?)
Regards,
Christian
---
This comment was put into the PSP structure in one of the header files:
/* offsets 5-9 are a far call to absolute address 0:000Ch
coded so that CP/M apps can do a near call to psp:5, does a
far call but ensures word at offset 6 is size of COM file
e.g. FEF0h by using 1MB wrap around address 0F01D:FEF0
(jmp code stored at 0:000C should be duplicated in HMA FFFF:00D0)
Note: MS-DOS has value as FEEE which wraps to 0:00BEh */
The address of 0:000Ch is wrong and should read 0000:00C0h. (It might be
interesting that this is where interrupt vectors 30h and 31h should be
stored, and this is the reason these interrupts can't be used/called in
DOS.) The word at offset 6 is usually not the exact size of the first
segment, because at least the low nibble is fixed to zero. It does not
depend on the size of the .COM file. If pointing out that a duplicate is
stored in the HMA, it might be interesting why this is done: to catch
"call 5"s while the A20 line is on.
The note seems not really correct, as mentioned in RBIL (Int21.26, PSP
description) this is a bug of MS-DOS's DEBUG program (not duplicated by FD
DEBUG as far as I know). Might be that RBIL is wrong with that however. Is
it?
---
This comment was put into entry.asm:
; For CP/M compatibility allow a program to invoke any DOS API function
; between 0 and 24h by doing a near call to psp:0005h which embeds a far
call
; to absolute address 0:00C0h (int vector 30h & 31h) or FFFF:00D0 (hma).
; Note: int 31h is also used for DPMI
; Upon entry the stack has a near return offset (desired return address)
and
; far return seg:offset (useless return to data at offset 0ah after far
call
; in psp). We convert it to a normal call and correct the stack to appear
same
; as if invoked via an int 21h call including proper return address.
The note is inappropriate (or incomplete) because DPMI explicitely uses
Int31 only in Protected Mode, and therefore only modifies the Protected
Mode IVT's entry 31h. It might be noted that not the complete return data
is useless, only the ip (offset) value. (Unless you assume cs = current
PSP, which the code doesn't.)
---
Might be just my conclusion, but won't it be better to document this just
in one file? Then you could as well add a short notice to the header file,
pointing to entry.asm (or the other way around, I just personally prefer
NASM style "%if 0" comments over C's star-and-slash constructs, and
usually write such extensive commentary into source rather than header
files). Some correct information (like the Int30 & Int31 notice, and
(incomplete) mention of DPMI) was present in one of the files but not in
the other one.
---
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
