On Tue, 30 Mar 2021 12:57:40 -0700, muta...@gmail.com wrote:

> 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?

Let's fire up debug.exe and see what those bytes look like disassembled:

```
C:\>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:

```
>>> hex((0xf01d << 4) + 0xfef0)
'0x1000c0'

>>> hex((0xf01d << 4) + 0xfef0 & 0xfffff)
'0xc0'
```

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.

Ciao,
Marc 'BlackJack' Rintsch
--
“It is well known that a vital ingredient of success is
not knowing that what you're attempting can't be done.”
-- Terry Pratchett, Equal Rites

On Monday, May 3, 2021 at 9:46:55 PM UTC+10, Marc 'BlackJack' Rintsch wrote:

Thanks so much for resolving that mystery!

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

It's a FAR CALL, not a FAR JMP.

> > 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:
>
> ```
> C:\>debug
> -e 1000 9a f0 fe 1d f0
> -u 1000 1004
> 07D7:1000 9AF0FE1DF0 CALL F01D:FEF0

Cool. I'd forgotten about debug, and forgotten how to use it too.

> So it is not a distributed instruction but all bytes together are the (far)
> CALL. Does it lead to address 000c0h? Yes it does:
>
> ```
> >>> hex((0xf01d << 4) + 0xfef0)
> '0x1000c0'
>
> >>> hex((0xf01d << 4) + 0xfef0 & 0xfffff)
> '0xc0'
> ```

Wonderful.

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

BFN. Paul.

On Monday, May 3, 2021 at 10:38:46 PM UTC+10, muta...@gmail.com wrote:
> 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.

Actually, the A20 line doesn't need to be disabled to
solve this problem. What is needed is for MSDOS to
install a JMP to 00C0 at 0x1000C0.

BFN. Paul.