31 Jan
2008
31 Jan
'08
9:21 a.m.
Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines?
From: Jim Battle <frustum at pacbell.net>
Date: Thu, 31 Jan 2008 02:01:43 -0600
To: General Discussion: On-Topic and Off-Topic Posts <cctalk at
classiccmp.org>
Holger Veit wrote:
....
If one takes a moment some of that was INTEL MDS artifact that were
programmed around. Also there are plenty of unused RST vectors.
For the later systems the 8259 was available and it inserted a
CALL XXXX where XXXX was anywere in addressable memory. The Z80
in mode2 interrupt also could vector anywhere in ram. DMA
is not impacted by how the low page is used.
Generally it's a non-issue and easy to work with.
The interrupt and DMA handling was also lousy
thanks to DR abusing some
8080 and even worse Z80 RST vector locations for the BDOS and CCP
buffers and FCBs. ...
That is one thing I always wondered about. CP/M has "CALL 0005H" as the
BIOS entry point. Why didn't they map it to 0008H instead? Considering
that code space was at a premium, saving two bytes off of every BIOS
call would have been an obvious optimization, I would have thought. On the other hand, I never wrote any 8080 code that
used RST, so maybe
there is some gotcha that I don't know about.
No it's a one byte call to 8 canned locations in the bottom of ram.
RST0 is to 0000h (warm boot)
(locations 0000-0007 are used by cpm)
RST1 is to 0008h (nothing there)
RST2 is to 0010h
RST3 is to 0018h
RST4 is to 0020h
RST5 is to 0028h
RST6 is to 0030h
RST7 is to 0038h (used by DDT as trap)
None of the 8085 hardware RSTx.5 or Trap interrupt
lines conflict with anything as they fall i the nothing
there range.
Z80 NMI lands at 66h which is in the default
FCB/DMA area that goes from 005Ch to 00FFh
Anyone have opinions why it was done with CALL 0005H
instead?
It's explicit either works but only one allows coding to look like:
Call BDOS ; Bdos defined as 0005h
which reads easier than
RST5 ; call location 005
The only thing I can come up with is that DR might have
entertained,
early on, making CP/M relocatable to different addresses (eg, some
vendor wants an OS that lives in high memory). In the process of
patching all the code for the high addresses, substituting "CALL 0FF05H"
instead of "CALL 0005H" is trivial, but substituting "CALL 0FF05H" for
"RST 1" would be a problem. Yes, one could require such systems to have
a "ORG 0005H / JMP 0FF05H" vector. I'm grasping at straws here.
Yes straws.
CP/M loads to the last typically 8k of high ram and sparsely uses the
first 256byte page as a system area. Everything inbetween is open land
but CP/M convention is executables start at 100H and have space that can
continue as high as the start of the BIOS (if you need cold boot) or 3.5K
lower if you need BDOS services. The CCP is considered overlayable.
Allison
1 Feb
1 Feb
3:36 a.m.
Allison wrote:
I'm not sure I understand what "it" of "it's" in the previous
sentence
is referring to. Using CALL? Using RST?
It reads to me like hardware didn't rely on RST so much, which only more
strongly makes the case that DR could have easily used RST1 instead of
CALL 0005H without upsetting things.
[ factual stuff about RST<n> behavior that wasn't in question deleted ]
"only one allows coding to look like ..." -- that isn't true. Had DR
moved the vector to 0008 instead of 0005, RST1 and CALL 0008H would both
work -- pick either one that suits your needs.
Also, people did *plenty* of ugly stuff to save a few bytes back then,
as you know. RST1 isn't particularly ugly anyway. And if for some
reason one did find it unpleasant, you could use a macro to make it to
your liking.
we agree. :-) I had a vague recollection of a faint memory of hearing
third hand that CP/M was ported to some heathkit machine, but that the
machine already had a ROM in low memory, and so instead of "CALL 0005H",
one had to use "CALL 2005H" or some such. CP/M programs could be very
easily reassembled/patched for this, but stock CP/M binaries wouldn't
work. rather than repeating this slanderous story, I didn't bring it up
and pretended it was just a supposition. ooops, but now the cat is out
of the bag.
Anyway, I'm left thinking that DR was simply paranoid that systems might
have already reserved RSTn for their own purposes, so they tried to not
use them (well, except RST0 and RST7) to make CP/M maximally portable.
It isn't just a coincidence that JMP xxxx at locaton 0005 stops just
before where RST1 starts.
Subject: Re:
"CP/M compatible" vs. "MS-DOS Compatible" machines?
From: Jim Battle <frustum at pacbell.net>
Date: Thu, 31 Jan 2008 02:01:43 -0600
To: General Discussion: On-Topic and Off-Topic Posts <cctalk at
classiccmp.org>
Holger Veit wrote:
....
If one takes a moment some of that was INTEL MDS artifact that were
programmed around. Also there are plenty of unused RST vectors.
For the later systems the 8259 was available and it inserted a
CALL XXXX where XXXX was anywere in addressable memory. The Z80
in mode2 interrupt also could vector anywhere in ram. DMA
is not impacted by how the low page is used.
Generally it's a non-issue and easy to work with. The interrupt and DMA handling was also lousy
thanks to DR abusing some
8080 and even worse Z80 RST vector locations for the BDOS and CCP
buffers and FCBs. ...
That is one thing I always wondered about. CP/M has
"CALL 0005H" as the
BIOS entry point. Why didn't they map it to 0008H instead? Considering
that code space was at a premium, saving two bytes off of every BIOS
call would have been an obvious optimization, I would have thought. Anyone have
opinions why it was done with CALL 0005H instead?
It's explicit either works but only one allows coding to look like:
Call BDOS ; Bdos defined as 0005h
which reads easier than
RST5 ; call location 005 The only thing
I can come up with is that DR might have entertained,
early on, making CP/M relocatable to different addresses (eg, some
vendor wants an OS that lives in high memory). In the process of
patching all the code for the high addresses, substituting "CALL 0FF05H"
instead of "CALL 0005H" is trivial, but substituting "CALL 0FF05H"
for
"RST 1" would be a problem. Yes, one could require such systems to have
a "ORG 0005H / JMP 0FF05H" vector. I'm grasping at straws here.
Yes straws. 
2 Feb
2 Feb
8:54 p.m.
On Friday 01 February 2008 03:36, Jim Battle wrote:
(Snip)
Also, people did *plenty* of ugly stuff to save a few
bytes back then,
as you know. RST1 isn't particularly ugly anyway. And if for some
reason one did find it unpleasant, you could use a macro to make it to
your liking.
Yup...
(Snip)
we agree. :-) I had a vague recollection of a faint
memory of hearing
third hand that CP/M was ported to some heathkit machine, but that the
machine already had a ROM in low memory, and so instead of "CALL 0005H",
one had to use "CALL 2005H" or some such. CP/M programs could be very
easily reassembled/patched for this, but stock CP/M binaries wouldn't
work. rather than repeating this slanderous story, I didn't bring it up
and pretended it was just a supposition. ooops, but now the cat is out
of the bag.
I believe the H-8 did indeed have a ROM at low memory. Never worked with that
machine, though. There were also some TRS-80 boxes that I seem to recall
having a need of a special version of CP/M as well.
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
3 Feb
3 Feb
5:10 p.m.
On Sat, 2 Feb 2008, Roy J. Tellason wrote:
I believe the H-8 did indeed have a ROM at low memory.
Never worked with that
machine, though. There were also some TRS-80 boxes that I seem to recall
having a need of a special version of CP/M as well.
Models 1 and 3
FMG distributed a relocated CP/M.
Various companies (Omicron, Parasitic Engineering, etc.) sold hardware
solutions to remap the ROM. and also add 8" support
6010
days inactive
6013
days old
3 comments
4 participants
participants (4)
-
ajp166＠bellatlantic.net -
cisin＠xenosoft.com -
frustum＠pacbell.net -
rtellason＠verizon.net