Does anyone have the exact bytes in a MSDOS PSP as documented here:
INTERRUP.F:
Format of Program Segment Prefix (PSP):
Offset Size Description (Table 01378)
00h 2 BYTEs INT 20 instruction for CP/M CALL 0 program termination
the CDh 20h here is often used as a signature for a valid PSP
02h WORD segment of first byte beyond memory allocated to program
04h BYTE (DOS) unused filler
(OS/2) count of fake DOS version returns
05h BYTE CP/M CALL 5 service request (FAR CALL to absolute 000C0h)
BUG: (DOS 2+ DEBUG) PSPs created by DEBUG point at 000BEh
06h WORD CP/M compatibility--size of first segment for .COM files
08h 2 BYTEs remainder of FAR JMP at 05h
It's just offset x'05' and x'08' and x'09' that I am
interested in. How did they (allegedly) organize
a call to 0000:00C0? And they're claiming both a
CALL and a JMP. Which one is it?
Thanks. Paul.
On Sun, 28 Mar 2021 03:57:14 -0700 (PDT), muta...@gmail.com wrote:
Does anyone have the exact bytes in a MSDOS PSP as documented here:
INTERRUP.F:
Format of Program Segment Prefix (PSP):
Offset Size Description (Table 01378)
00h 2 BYTEs INT 20 instruction for CP/M CALL 0 program termination
the CDh 20h here is often used as a signature for a valid PSP
02h WORD segment of first byte beyond memory allocated to program
04h BYTE (DOS) unused filler
(OS/2) count of fake DOS version returns
05h BYTE CP/M CALL 5 service request (FAR CALL to absolute 000C0h)
BUG: (DOS 2+ DEBUG) PSPs created by DEBUG point at 000BEh
06h WORD CP/M compatibility--size of first segment for .COM files
08h 2 BYTEs remainder of FAR JMP at 05h
It's just offset x'05' and x'08' and x'09' that I am
interested in. How did they (allegedly) organize
a call to 0000:00C0? And they're claiming both a
CALL and a JMP. Which one is it?
Thanks. Paul.
Both. It's just a splitted FAR CALL instruction.
i.e. @05h= instruction, @06h= operand.
Both. It's just a splitted FAR CALL instruction.
i.e. @05h= instruction, @06h= operand.
@06 on CP/M is the address of the BIOS in high
memory (within 64K) but that is sort of not
possible with MSDOS.
So @06 on MSDOS is instead the segment size
according to RBIL above.
I'm curious as to what exactly that is. A split
instruction that skips the word at @06? That's
a pretty strange split.
BFN. Paul.
Both. It's just a splitted FAR CALL instruction.
i.e. @05h= instruction, @06h= operand.
@06 on CP/M is the address of the BIOS in high
memory (within 64K) but that is sort of not
possible with MSDOS.
So @06 on MSDOS is instead the segment size
according to RBIL above.
Oops. That should be @08h. Not @06h. Sorry.
I'm curious as to what exactly that is. A split
instruction that skips the word at @06? That's
a pretty strange split.
Not sure, but I'm guessing that @05h and @08 were a later CP/M implementation. i.e. @05 was initially used for different purpose or was reserved.
Running under MSDOS 5.0 gives this PSP:
What I want to know is how MSDOS managed to
make @05, @08 and @09 a far call to 00C0. If
we can see a PSP from MSDOS for a .com file
it should have the answer. If we can disassemble
that, anyway.
What I want to know is how MSDOS managed to
make @05, @08 and @09 a far call to 00C0. If
we can see a PSP from MSDOS for a .com file
it should have the answer. If we can disassemble
that, anyway.
05h BYTE CP/M CALL 5 service request (FAR CALL to absolute 000C0h)
06h WORD CP/M compatibility--size of first segment for .COM files
08h 2 BYTEs remainder of FAR JMP at 05h
000000 CD20C09F 009AF0FE 1DF0DC01 F70E4B01 . ............K.
On Wednesday, March 31, 2021 at 6:47:54 AM UTC+11, muta...@gmail.com wrote:
So:What I want to know is how MSDOS managed to05h BYTE CP/M CALL 5 service request (FAR CALL to absolute 000C0h)
make @05, @08 and @09 a far call to 00C0. If
we can see a PSP from MSDOS for a .com file
it should have the answer. If we can disassemble
that, anyway.
06h WORD CP/M compatibility--size of first segment for .COM files
08h 2 BYTEs remainder of FAR JMP at 05h
000000 CD20C09F 009AF0FE 1DF0DC01 F70E4B01 . ............K.
05h = 9A
06/07 = FEF0
08h = 1D
09h = F0
So the 06/07 "segment size" of nearly 64k is basically
just maxing out the memory available to the .com
program.
But how does 9A + 1D + F0 translate into a call to 00C0?
Maybe it is relative to the load point. Let me see if I
can extract that.
BFN. Paul.
dumppsp Abc Def Ghiloaded at 10242f0e
On Wednesday, March 31, 2021 at 6:47:54 AM UTC+11, muta...@gmail.com wrote:
What I want to know is how MSDOS managed to
make @05, @08 and @09 a far call to 00C0. If
we can see a PSP from MSDOS for a .com file
it should have the answer. If we can disassemble
that, anyway.
05h BYTE CP/M CALL 5 service request (FAR CALL to absolute 000C0h)
06h WORD CP/M compatibility--size of first segment for .COM files
08h 2 BYTEs remainder of FAR JMP at 05h
000000 CD20C09F 009AF0FE 1DF0DC01 F70E4B01 . ............K.
So:
05h = 9A
06/07 = FEF0
08h = 1D
09h = F0
So the 06/07 "segment size" of nearly 64k is basically
just maxing out the memory available to the .com
program.
But how does 9A + 1D + F0 translate into a call to 00C0?
debug-e 1000 9a f0 fe 1d f0
'0x1000c0'hex((0xf01d << 4) + 0xfef0)
'0xc0'hex((0xf01d << 4) + 0xfef0 & 0xfffff)
05h BYTE CP/M CALL 5 service request (FAR CALL to absolute 000C0h)
06h WORD CP/M compatibility--size of first segment for .COM files
08h 2 BYTEs remainder of FAR JMP at 05h
But how does 9A + 1D + F0 translate into a call to 00C0?Let's fire up debug.exe and see what those bytes look like disassembled:
```
debug-e 1000 9a f0 fe 1d f0
-u 1000 1004
07D7:1000 9AF0FE1DF0 CALL F01D:FEF0
So it is not a distributed instruction but all bytes together are the (far) CALL. Does it lead to address 000c0h? Yes it does:
```
'0x1000c0'hex((0xf01d << 4) + 0xfef0)
'0xc0'hex((0xf01d << 4) + 0xfef0 & 0xfffff)
```
Apparently DOS puts the size at 06h/07h and calculates a segment for 08h/09h that gives an effective address of 000c0h, taking into account that the number
”wraps” at 20 bits back to zero.
'0xc0'hex((0xf01d << 4) + 0xfef0 & 0xfffff)
On Monday, May 3, 2021 at 9:46:55 PM UTC+10, Marc 'BlackJack' Rintsch wrote:
hex((0xf01d << 4) + 0xfef0)
'0x1000c0'
Apparently DOS puts the size at 06h/07h and calculates a segment for 08h/09h
that gives an effective address of 000c0h, taking into account that the number
”wraps” at 20 bits back to zero.
And that explains why so much care needed to be
given to disable the A20 line. I was wondering who
was coding stuff that relied on address wrap.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 415 |
Nodes: | 16 (2 / 14) |
Uptime: | 105:55:50 |
Calls: | 8,692 |
Calls today: | 1 |
Files: | 13,250 |
Messages: | 5,948,272 |