cp/m exe

[muta...@gmail.com]

Is there any real disadvantage in having CP/M use
tiny memory model executables as seen on MSDOS
instead of .com files?

It seems a bit odd executing code immediately.

I don't mind if CP/M doesn't validate anything and
just assumes it is tiny memory model and skips
over the header and unconditionally starts executing.

That would be no worse than what happened with
COM files, and gives more flexibility for a "future"
(MSDOS) operating system to have more robust
checking and more functionality (relocation).

Thanks. Paul.

[s_dub...@yahoo.com]

On Friday, February 24, 2023 at 5:46:01 AM UTC-6, muta...@gmail.com wrote:

There isn't a cpm.exe unless, perhaps you are talking of an emulator called by that name.

o CP/M aka CP/M-80 is built for, and around, the intel 8080 cpu equipped Intel MDS,
the micro-processor development system.
- The 8080 requires reservation of the page-zero (the first 0100h bytes) for itself.
Address 0000h is the RST0 vector followed by RST1..RST7.
Address 007Dh, 007Eh, 007Fh are byte variables needed by the diskette controller,
followed by Address 0080h..00FFh which is the diskette transfer buffer area. Note
that this is 128 bytes for the diskette sector size, as data is read or written in complete
Sectors, and sectors were sized at 128 bytes at that time.
Later, sector sizes were 512 bytes, and cp/m-80 used a software procedure called
'blocking and deblocking' to manage the sector size issue.

o CP/M-86 is built for the S100 buss systems, and IBM 5150 using the Intel 8086/8088.
- Because Patterson named his executables with the suffix .COM and later .EXE, DRI
chose to name executables with .CMD for CP/M-86, also to distinguish from CP/M-80
.COM files. Since the file system for cp/m-86 was functionally the same as cp/m-80,
both types of files could stored on the same media.

> Is there any real disadvantage in having CP/M use
> tiny memory model executables as seen on MSDOS
> instead of .com files?

I don't understand the question.
Memory model designators are tool specific.
CP/M-80 only has one memory model, practically, for 64k addressing.
CP/M-86 deals with 16 x 64k in its own unique ways.

DOS .COM is architectually borrowed from cp/m-80. It assumes CS, DS, ES, SS all have
the same value, actually the loader makes sure it is so, afaict.

CP/M-86 doesn't use .COM executables, only .CMD files.
The tools for CP/M-86 allows for building different memory models including an 8080
model where the data of the page zero is placed first followed by code designated at
ORG 0100h.

CP/M-86 and MP/M-86 evolved into CDOS for the 8086 which also could execute
early DOS .EXE's

> It seems a bit odd executing code immediately.

Why? The cpu does this:
The 8080 Program Counter begins cpu execution at 0000h.
The 8086 Instruction Pointer begins cpu exectution at FFFF:0000h, which is 16 bytes
before address roll-over.

>
> I don't mind if CP/M doesn't validate anything and
> just assumes it is tiny memory model and skips
> over the header and unconditionally starts executing.
>

Taking your comment as meaning CP/M-80, blame the 8080 cpu architecture.

> That would be no worse than what happened with
> COM files, and gives more flexibility for a "future"
> (MSDOS) operating system to have more robust
> checking and more functionality (relocation).
>

MSDOS never did reach the multi-tasking/multi-processing of MP/M-80 and
later MP/M-86.

> Thanks. Paul.

hth,
Steve