Origin of the 8.3 Filename Convention
Gene Wirchenko
credible answer here or anywhere else. This is despite much
searching. I'll try again:
What is the origin of the 8.3 filename convention?
This has gone beyond that it is worth a 1% bonus in course I'm
taking (as I mentioned first time around). This is a piece of
knowledge that could be on the verge of extinction.
Does anybody know?
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
Ignatios Souvatzis
ge...@mail.ocis.net (Gene Wirchenko) writes:
> I asked this question a few months ago. I have yet to see a
> credible answer here or anywhere else. This is despite much
> searching. I'll try again:
>
> What is the origin of the 8.3 filename convention?
Seeing that the ~2 dozen discussion in this very newsgroup, with the
different contributions outlined, doesn't satisfy you ...
what is your definition of "origin"?
Regards,
-is
Rupert Pigott
news:3cb1a34...@news.ocis.net...
> I asked this question a few months ago. I have yet to see a
> credible answer here or anywhere else. This is despite much
> searching. I'll try again:
>
> What is the origin of the 8.3 filename convention?
Are you sure you're asking the right question ?
Furthermore - why the hell does it matter ? :)
Cheers,
Rupert
Peter Ibbotson
> credible answer here or anywhere else. This is despite much
> searching. I'll try again:
>
> What is the origin of the 8.3 filename convention?
>
> This has gone beyond that it is worth a 1% bonus in course I'm
> taking (as I mentioned first time around). This is a piece of
> knowledge that could be on the verge of extinction.
>
> Does anybody know?
>
The short answer is not really, MSDOS and windows definitely got it from
CPM, and I suspect that CPM picked up the three letter extension stuff from
DEC but expanded the filename size from 6 to 8 letters. (PIP and DDT are
commands available for both DEC & CPM systems so some common ancestory here)
I suspect the answer being looked for here is "CP/M" but quite why CP/M used
8.3 is lost (they had two spare bytes in the directory format which could
have been used to give 10.3) .
--
Work pet...@lakeview.co.uk.plugh.org | remove magic word .org to reply
Home pe...@ibbotson.co.uk.plugh.org | I own the domain but theres no MX
Jim Haynes
Peter Ibbotson <spa...@ibbotson.co.uk> wrote:
>I suspect the answer being looked for here is "CP/M" but quite why CP/M used
>8.3 is lost (they had two spare bytes in the directory format which could
>have been used to give 10.3) .
Now DEC used, at least in the PDP-11, Radix-50 coding of the alphabet in
file names. Seems like this got them 3 ASCII characters into 16 bits, or
something like that.
Alan J. Wylie
> Now DEC used, at least in the PDP-11, Radix-50 coding of the
> alphabet in file names. Seems like this got them 3 ASCII characters
> into 16 bits, or something like that.
Not ASCII.
The 50 in Rad50 is octal.
50 octal = 40 decimal
(decimal) 40 ^ 3 = 64000
2 ^ 16 = 65536
A-Z 26
0-9 10
punctuation 4 ("$", "." ???)
--
40
--
Alan J. Wylie http://www.glaramara.freeserve.co.uk/
"Perfection [in design] is achieved not when there is nothing left to add,
but rather when there is nothing left to take away."
Antoine de Saint-Exupery
Bernie Cosell
Not ascii and not into 16 bits. Pre-PDP-11, DECs computers had
multiple-of-6-bit word lengths [18 and 36] and the 'natural' character
coding on the system was [not surprisingly] 6-bit-chars. And so the
software naturally gravitated to 6 [and 9 for some langs, I think]
character symbols. The hack with Rad50 was that in the symbol table, you
could pack three characters into 17 bits. This gave you two 'free' bits
[for a 6-char-symbol] to use as flag bits, one in each word. I once knew
what those bits were used for in Midas [the assembler we used to use] but
the memory is long-gone.
/Bernie\
--
Bernie Cosell Fantasy Farm Fibers
ber...@fantasyfarm.com Pearisburg, VA
--> Too many people, too few sheep <--
Gene Wirchenko
>On Mon, 08 Apr 2002 14:05:35 GMT, ge...@mail.ocis.net (Gene Wirchenko)
>sprachen:
>
>>This is a piece of
>>knowledge that could be on the verge of extinction.
>
>It's obviously already extinct. Which is a bit wierd for such a modern
>idea. Anyway I'm dying to know, did you get the 1%? What was your
>prof's explanation?
I haven't gotten it yet, and he hasn't given the explanation.
The course isn't over yet.
Jim Haynes
Alan J. Wylie <alan....@glaramara.freeserve.co.uk> wrote:
>
>Not ASCII.
>
OK, I shoulda said what I meant, a subset of ASCII consisting of A-Z,
0-9, and a few other things.
Eric Sosman
No; that's a subset of EBCDIC. Or of the MIX 1009 characters.
(In other words: ASCII is not just a set of glyphs and control
functions, but a particular encoding for them. RAD50 encodes some
of the same glyphs found in ASCII and EBCDIC and other codes, but
since the encoding is completely different, RAD50 is neither of
those codes, nor is it a subset of those codes.)
Stephen G. McKenna
"Peter Ibbotson" <spa...@ibbotson.co.uk> wrote in message
news:1018284458.7287.0...@news.demon.co.uk...
Elliott Roper
<xtLs8.31021$cN1....@news01.bloor.is.net.cable.rogers.com>, Stephen
G. McKenna <steve.RE...@mckenna.ca> wrote:
> Its been about 20 years, but I recall using 8.3 file names with PDP-11/Rsx
Can you remember any filenames in RSX that were more than 6.3?
It's that RAD-50 again. Any three from a set of 40 crammed into a 16
bit word. Rad-50? Sort of a bad joke in octal notation.
You remember the cheatsheet blue booklet with the sailing ship on the
front, complete with a snippet of the John Masefield poem?
"And all I ask is a tall ship and a star to steer her by,"
With the RAD-50 table toward the back. RSX11M-3.2 The best RSX of all.
Charles Richmond
instead of developing their own???
--
+-------------------------------------------------------------+
| Charles and Francis Richmond <rich...@plano.net> |
+-------------------------------------------------------------+
Douglas H. Quebbeman
> Eric Sosman wrote:
> >
> > Jim Haynes wrote:
> > >
> > > In article <wgsn66g...@nospam.glaramara.freeserve.co.uk>,
> > > Alan J. Wylie <alan....@glaramara.freeserve.co.uk> wrote:
> > > >
> > > >Not ASCII.
> > > >
> > > OK, I shoulda said what I meant, a subset of ASCII consisting of A-Z,
> > > 0-9, and a few other things.
> >
> > No; that's a subset of EBCDIC. Or of the MIX 1009 characters.
> >
> > (In other words: ASCII is not just a set of glyphs and control
> > functions, but a particular encoding for them. RAD50 encodes some
> > of the same glyphs found in ASCII and EBCDIC and other codes, but
> > since the encoding is completely different, RAD50 is neither of
> > those codes, nor is it a subset of those codes.)
> >
> So why did CDC *not* adopt RAD50 as their 6-bit character set,
> instead of developing their own???
Mark Crispin has stated he thought that Radix-50 was in use on the
PDP-1, which would date it back to what, '61? He says he's sure it
was in use on the PDP-6 during the pre-timesharing days.
HOWEVER, the design of the CDC 6000 series computers began in 1959,
and if RAD50 was in use by that time, it wasn't likely being used
widely. And they appear to have not wanted to continue using BCD...
Regards,
-doug q
Eric Sosman
>
> So why did CDC *not* adopt RAD50 as their 6-bit character set,
> instead of developing their own???
I'm not familiar with what CDC came up with, but RAD50 is
obviously not a "6-bit character set." If anything, it's a
5.32193-bit character set.
(Hmmm: Did anybody ever come up with a use for the
0.034216 bit wasted when three RAD50 characters occupied
one sixteen-bit word? 1536 unused codes were available;
did anybody use, say, 0177777 as a special flag value?)
Don Stokes
>G. McKenna <steve.RE...@mckenna.ca> wrote:
>> Its been about 20 years, but I recall using 8.3 file names with PDP-11/Rsx
>Can you remember any filenames in RSX that were more than 6.3?
>It's that RAD-50 again. Any three from a set of 40 crammed into a 16
>bit word. Rad-50? Sort of a bad joke in octal notation.
>You remember the cheatsheet blue booklet with the sailing ship on the
>front, complete with a snippet of the John Masefield poem?
>"And all I ask is a tall ship and a star to steer her by,"
>With the RAD-50 table toward the back. RSX11M-3.2 The best RSX of all.
RSX uses 9.3, stored in RAD-50 format in three 16 bit words for the file
name plus one for the extension.
RT11 and RSTS/E use 6.3.
-- don
CBFalconer
> Eric Sosman wrote:
> >
... snip ...
> >
> > (In other words: ASCII is not just a set of glyphs and control
> > functions, but a particular encoding for them. RAD50 encodes some
> > of the same glyphs found in ASCII and EBCDIC and other codes, but
> > since the encoding is completely different, RAD50 is neither of
> > those codes, nor is it a subset of those codes.)
> >
> So why did CDC *not* adopt RAD50 as their 6-bit character set,
> instead of developing their own???
It is not a character set. It is a way of packing 3 of a 40 char
set into 16 bits. You also need a translation table or
equivalent. The usual set is 'A'..'Z', '0'..'9', ' ', and your
choice of 3 more glyphs, in no particular order.
If the chars are represented by integers 0..39, then the 16 bit
value of chars xyz will be:
(((x)*40 + y)*40 +z)
and keeping the blank representation as 0 is handy, because it
allows you to do string compares with integer instructions. MOD
40 is used to extract.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
CBFalconer
>
... snip ...
>
> Not ascii and not into 16 bits. Pre-PDP-11, DECs computers had
> multiple-of-6-bit word lengths [18 and 36] and the 'natural'
> character coding on the system was [not surprisingly] 6-bit-chars.
> And so the software naturally gravitated to 6 [and 9 for some
> langs, I think] character symbols. The hack with Rad50 was that
> in the symbol table, you could pack three characters into 17 bits.
> This gave you two 'free' bits [for a 6-char-symbol] to use as flag
> bits, one in each word. I once knew what those bits were used for
> in Midas [the assembler we used to use] but the memory is long-gone.
See the packing algorithm I posted elsethread. You can actually
let one of the three packed chars have 41 possible values,
provided you preselect the position. And the word is 16, not 17
bits. No need for it with an 18 bit word, you can just pack 6 bit
chars.
Jim Haynes
>
> Jim Haynes wrote:
> >
> > In article <wgsn66g...@nospam.glaramara.freeserve.co.uk>,
> > Alan J. Wylie <alan....@glaramara.freeserve.co.uk> wrote:
> > >
> > >Not ASCII.
> > >
> > OK, I shoulda said what I meant, a subset of ASCII consisting of A-Z,
> > 0-9, and a few other things.
>
> No; that's a subset of EBCDIC. Or of the MIX 1009 characters.
>
> (In other words: ASCII is not just a set of glyphs and control
> functions, but a particular encoding for them. RAD50 encodes some
> of the same glyphs found in ASCII and EBCDIC and other codes, but
> since the encoding is completely different, RAD50 is neither of
> those codes, nor is it a subset of those codes.)
>
subset of ASCII is that for the machines I'm talking about the software
and terminals used ASCII as the character code. The software provides
functions to convert between ASCII codes and RAD50 codes. It's these
codes, not the glyphs, that appear inside the machine.
Jim Haynes
>>
>> Jim Haynes wrote:
>> >
>> > In article <wgsn66g...@nospam.glaramara.freeserve.co.uk>,
>> > Alan J. Wylie <alan....@glaramara.freeserve.co.uk> wrote:
>> > >
>> > >Not ASCII.
>> > >
>> > OK, I shoulda said what I meant, a subset of ASCII consisting of A-Z,
>> > 0-9, and a few other things.
>>
>> No; that's a subset of EBCDIC. Or of the MIX 1009 characters.
>>
>> (In other words: ASCII is not just a set of glyphs and control
>> functions, but a particular encoding for them. RAD50 encodes some
>> of the same glyphs found in ASCII and EBCDIC and other codes, but
>> since the encoding is completely different, RAD50 is neither of
>> those codes, nor is it a subset of those codes.)
>>
ASCII is that for the machines I'm talking about ASCII was the character
code of the software and terminals. The software provided functions to
convert between RAD50 and ASCII. The software doesn't know about the
glyphs; it only knows the codes that represent them.
Brian Inglis
No, but the two extra bits per word on 18 bit machines e.g PDP-15
were used to encode a variable's data type in the symbol table
e.g. TTRRR TTRRR where T are the type bits and R the 6 RAD50
chars allowed per symbol.
IIRC in PDP-15 4K/8K ForTran one set of type bits were used to
encode the base data type (int, float, double) and the other the
number of array dimensions, or something like that.
They might also have been used in the reserved word table as
length flags or for dispatching, but it's been a long while.
RAD50 made a lot more sense than the "standard" 5x7 ASCII packing
conventionally used for strings on DEC's 18/36 bit machines.
Six and nine bit bytes would have been a lot easier to deal with.
--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
Brian....@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
fake address use address above to reply
tos...@aol.com ab...@aol.com ab...@yahoo.com ab...@hotmail.com ab...@msn.com ab...@sprint.com ab...@earthlink.com ab...@cadvision.com ab...@ibsystems.com u...@ftc.gov
spam traps
Bernie Cosell
} Bernie Cosell wrote:
} >
} ... snip ...
} >
} > Not ascii and not into 16 bits. Pre-PDP-11, DECs computers had
} > multiple-of-6-bit word lengths [18 and 36] and the 'natural'
} > character coding on the system was [not surprisingly] 6-bit-chars.
} > And so the software naturally gravitated to 6 [and 9 for some
} > langs, I think] character symbols. The hack with Rad50 was that
} > in the symbol table, you could pack three characters into 17 bits.
} > This gave you two 'free' bits [for a 6-char-symbol] to use as flag
} > bits, one in each word. I once knew what those bits were used for
} > in Midas [the assembler we used to use] but the memory is long-gone.
}
} See the packing algorithm I posted elsethread. You can actually
} let one of the three packed chars have 41 possible values,
} provided you preselect the position. And the word is 16, not 17
} bits. No need for it with an 18 bit word, you can just pack 6 bit
} chars.
If you're talking about the RAD50, the first I ran into it was on the PDP1
which *DID* have 18 bit words and the 'packing' was used to program-bum a
couple of flag bits into the symbol table. I wasn't addressing the
question of whether RAD-50 was used later on other computers and with other
packing schemes. /bernie\
Charlie Gibbs
hay...@alumni.uark.edu (Jim Haynes) writes:
Those codes are generated by the routine that unpacks RAD50 codes.
They're not intrinsic to RAD50. I once wrote a program that read
a tape containing RAD50 data on an EBCDIC machine; by your logic
I could argue just as strongly that RAD50 is a subset of EBCDIC.
For that matter, you could legitimately say that RAD50 is a subset
of any character code that includes the 40 characters in question.
But that's pretty meaningless, really. Now you could start making
mathematical statements about whether the set of all characters that
can be represented in RAD50 is a subset of the set of all characters
represented by any other encoding - Baudot, Fieldata, or whatever -
and that might be of interest if you're trying to determine whether
it's possible to properly interpret RAD50 on a particular machine.
But at this point I'm starting to see those old high-school Venn
diagrams, and my head is beginning to hurt...
--
cgi...@sky.bus.com (Charlie Gibbs)
Remove the first period after the "at" sign to reply.
I don't read top-posted messages. If you want me to see your reply,
appropriately trim the quoted text and put your reply below it.
Russell P. Holsclaw
first system to have 8.3 names. How did Gary Kildall come up with that
combination?
My theories:
1. The standard CP/M disk sector size was 128 bytes, and he wanted to have
32-byte directory entries, so that they would come out even ... a whole
number per sector. It had to be a power of 2, anyway. He laid out all the
fields that the directory entry needed according to his file system ideas,
and there were 11 bytes left over for the file name and extension. Since DEC
systems were already using 3-character extensions, which seemed to be a
practical minimum, that left 8 for the name.
2. There is evidence that Gary was one of those rare individuals with both
DEC and IBM influences in his background. DEC had established the
3-character file extension as a standard on its systems, and IBM mainframes
of the time had 8 characters as a common namespace size. Put the two
together, and you get 8.3. (BTW, the IBM influence can be seen his his PL/M
language, with PL/I-like syntax and his choice of PL/I for his first
application language compiler.)
--
Russ Holsclaw
Peter Ibbotson
news:xOmt8.84$LA3....@news.uswest.net...
Number 1 I don't like as there are two spare bytes left over in CPM 1.4
directory structure (Perhaps gary did this on purpose)
Number 2 I like much better and perhaps he felt that he'd like some spare in
the directory structure (Possibly he was thinking of time and date stamping
later on?)
I suppose the best question would be to ask what Intel development systems
had?
Russell P. Holsclaw
> directory structure (Perhaps gary did this on purpose)
don't remember what for.
I do recall that one of the things was the existence of the "user number",
which was used to distinguish files owned by different users of the
computer, although I think it was only a 4-bit number (users numbered 1-15
with user#0 used to indicate files that were commonly owned (like system
files). Also CP/M 1.4 only supported floppy disks of a certain size, and
later versions supported other disks, including hard drives. The extra two
bytes may have been spent on something related to hard drive support.
I have some documentation at home for CP/M 2.x, and I'll try to find the
references.
> Number 2 I like much better and perhaps he felt that he'd like some spare
in
> the directory structure (Possibly he was thinking of time and date
stamping
> later on?)
As I said above, I recall the other bytes getting used later. Timestamps
were not part of it, though. I don't remember seeing timestamps until MS-DOS
1.1 (1.0 didn't even have them, although they were planned.)
> I suppose the best question would be to ask what Intel development systems
> had?
CP/M *was* the Intel development system, as far as I can remember. At least
it was proposed to them for that purpose by Digital Research, who developed
the PL/M language for them. As I remember it, Intel didn't view their
microprocessor chips as being suitable for general-purpose computing, but
only as embedded controllers (you know... traffic lights, microwave ovens,
etc). Therefore, they didn't really envision a native "development
environment" They used cross-assemblers and PL/M cross-compilers for code
development. It was the hobbyists who finally convinced them that an 8080
could really serve as the CPU for a "personal computer". Until then, they
rejected the idea of CP/M, or any operating system at all --- so therefore
Intel didn't have any independent idea of a file system for microcomputers.
It was a classic example of a "paradigm shift". The people who made
microprocessors really didn't envision the personal computer. They set their
sights much lower. It was the hobbyists who created the revolution, not the
semiconductor companies. The chip-makers didn't realize the implications of
what they had created. The idea of an affordable computer for the home was
just too far-out for them to contemplate, so they rejected any idea that
suggested that possibility until they were forced to deal with it.
Peter Ibbotson
"Russell P. Holsclaw" <rhol...@nospam.xxx.fatline.com> wrote in message
news:xfCt8.400$rB5....@news.uswest.net...
> > Number 2 I like much better and perhaps he felt that he'd like some
spare
> in
> > the directory structure (Possibly he was thinking of time and date
> stamping
> > later on?)
>
> As I said above, I recall the other bytes getting used later. Timestamps
> were not part of it, though. I don't remember seeing timestamps until
MS-DOS
> 1.1 (1.0 didn't even have them, although they were planned.)
There were a few schemes that did and I think CPM3.0 had at least one. One
of the other bytes was used for making files bigger than 512K on CPM2.2
More info at http://www.seasip.demon.co.uk/Cpm/formats.html
>
> > I suppose the best question would be to ask what Intel development
systems
> > had?
>
> CP/M *was* the Intel development system, as far as I can remember. At
least
> it was proposed to them for that purpose by Digital Research, who
developed
> the PL/M language for them. As I remember it, Intel didn't view their
> microprocessor chips as being suitable for general-purpose computing, but
> only as embedded controllers (you know... traffic lights, microwave ovens,
> etc). Therefore, they didn't really envision a native "development
> environment" They used cross-assemblers and PL/M cross-compilers for code
> development. It was the hobbyists who finally convinced them that an 8080
I meant the "cross compiler" Intel used before CPM got started, if that
system had 8 character files names then it would be natural to give 8
character files on the newer development system.
jchausler
"Russell P. Holsclaw" wrote:
> CP/M *was* the Intel development system, as far as I can remember. At least
> it was proposed to them for that purpose by Digital Research, who developed
> the PL/M language for them. As I remember it, Intel didn't view their
> microprocessor chips as being suitable for general-purpose computing, but
> only as embedded controllers (you know... traffic lights, microwave ovens,
> etc). Therefore, they didn't really envision a native "development
> environment" They used cross-assemblers and PL/M cross-compilers for code
> development. It was the hobbyists who finally convinced them that an 8080
> could really serve as the CPU for a "personal computer". Until then, they
> rejected the idea of CP/M, or any operating system at all --- so therefore
> Intel didn't have any independent idea of a file system for microcomputers.
This thinking wasn't limited to Intel. I was an early Motorola 6800 "hacker"
and Moto's thinking was the same. (I actually didn't think of the 8080 as
a computer, at least not enough of one to want to use it. Only when the 6800
came along with its PDP-11 style operation did I "byte" ;-) I think Moto
eventually developed their own OS for their development system but the
hobby user already had a choice of several OS's to work with by that time.
I don't think Moto ever adopted any of them although they did make a foray
into the hobby SS-50 bus with a SS-50 bus dynamic memory card. I
eventually went with FLEX for both the 6800 and 6809.
I did once buy CP/M 2.2 in 81 for an Intel MDS development system but
then never used it as at the customer site there was an IMSAI already
available with CP/M on it to use as a development system (developing
code for a Moto 6801 target :-) I still have the virgin CP/M distribution
diskette and docs. The whole development was over in two months and
I was back in mini land so I never had a use for it.
> It was a classic example of a "paradigm shift". The people who made
> microprocessors really didn't envision the personal computer. They set their
> sights much lower. It was the hobbyists who created the revolution, not the
> semiconductor companies. The chip-makers didn't realize the implications of
> what they had created. The idea of an affordable computer for the home was
> just too far-out for them to contemplate, so they rejected any idea that
> suggested that possibility until they were forced to deal with it.
This was true out in industry too. I worked primarily in a software
development group using mini's at that time. An entirely different group,
with little communications between us, was doing micro work. Our
background was software, theirs was hardware design. At that time
typical hardware designer's did not think much about or of software.
All you have to do is read some of the vendor docs to see this.
The feeling was that a mini was a "computer" and a micro was just
a "part", that there was no real commonality between the two worlds.
This, of course, had previously occurred between the mainframe and
mini worlds as well. Now all the same mistakes were being made a
third time with micros. Anyway, a sort of turf war developed.
At this time, early 77, I acquired my first micros, a Moto D2 kit
shortly followed by a D1 kit. Most of my software colleagues
looked at the simple printed circuit cards with their few chips
on it and said "not a computer", what are you bothering with
it for? I was always impressed that my mentor at the time, who had
no hardware experience or interest looked at the instruction card
and said, "Its a computer, what's the big deal?" The D1 required
an external terminal, an ASR 33 tty to be specific. The micro
folks across the hall had a number of them and so I went over
there one day and got permission to use them and their lab after
hours to "play" with my D1. My management got pissed at me
and theirs at them. This didn't change the arrangement but was
"funny" none the less. My management's complaint was that
because "they" had allowed me in their world, now "we" would
have to allow them into ours and it was all my fault. Fortunately
the man I had made the arrangement with was one of their
managers and had more sense than that and ignored his
colleagues' complaints.
Chris
AN GETTO$;DUMP;RUN,ALGOL,TAPE
$$
Dee
> > I suppose the best question would be to ask what Intel development systems
> > had?
>
> CP/M *was* the Intel development system, as far as I can remember. At least
> it was proposed to them for that purpose by Digital Research, who developed
> the PL/M language for them.
Wrong. Gary Kildall was contracted to develop the PL/M language and
(cross) compiler for Intel. He then proposed to develop CP/M for
Intel, who rejected the proposal because they already have their own
OS project underway (called ISIS originally, later called ISIS-II).
Gary Kildall then started Digital Research for the purpose of
marketing CP/M (notice this is all AFTER his Intel contracts). CP/M
was developed on the same Intel Microprocessor Development System
(MDS, which was a marketing term only for Intel, not to be confused
with Mohawk Data Systems, who has the term MDS trademarked) that Intel
used to run their own ISIS-II on. The MDS was given by Intel for
Kildall to do compiler development/test. And for you real historians,
the origin of the BIOS is the Intel MDS, which has a small monitor in
ROM at high memory.
The original PL/M was developed on a PDP-10 system by Kildall. As for
the Intel ISIS-II system, it has file names of the form
:XX:YYYYYY.ZZZ, where XX is a 2-character device name (:CI: for
console in, :CO: for console out, :Fn: for the floppy or hard drive,
:LP: for line printer, etc.), followed by a 6-character file name with
a 3-character extension.
Heinz W. Wiggeshoff
>
...
That's interesting. I used PL/M at a defunct John Kelly outfit called
NABU on a Z80 CP/M system, back in Sept. 82. (Some people in Ottawa
may recall the names.) I will swear on a stack of Bible/Torah/Koran/
McKeeman-Wortman-Hornings that PL/M is directly derived from XPL, the
latter's simple PL student language for compiler writing.
That it ever crossed over to PDP is amazing, given it's heavy IBM 360
heritage.
Eric Smith
> CP/M *was* the Intel development system, as far as I can remember.
Nope. Intel shipped the systems with ISIS-II. I presume that before
ISIS-II there was an ISIS-I or an ISIS with no suffix, but I've never
seen that.
ISIS-II is a lot different than CP/M, but it does use 8+3 filenames IIRC.
Dave Daniels
Heinz W. Wiggeshoff <ab...@FreeNet.Carleton.CA> wrote:
> That's interesting. I used PL/M at a defunct John Kelly outfit called
> NABU on a Z80 CP/M system, back in Sept. 82. (Some people in Ottawa
> may recall the names.) I will swear on a stack of Bible/Torah/Koran/
> McKeeman-Wortman-Hornings that PL/M is directly derived from XPL, the
> latter's simple PL student language for compiler writing.
> That it ever crossed over to PDP is amazing, given it's heavy IBM 360
> heritage.
I heard of PL/M a few years ago. When the source code of CP/M
became available I took the opportunity to have a closer look at
the language as much of CP/M and MP/M are written in it. I was
impressed by it and thought it was quite a neat little systems
programming language. I would say that it is of a lower level than
C but has a cleaner syntax. The way it handled things like data
structures (declare a variable with the given structure, not a
type) was interesting. The 'literally' facility struck me as being
like C macros with most of the opportunities for evilness removed.
Variables, both global and local, were limited to more-or-less the
equivalent of 'static' variables in C. No recursion - Eek! OTOH,
CP/M consists of yards and yards of source code, and not a
bicapitalised variable name in sight. Lovely. You can get a
compiler for PL/M that runs on a PC, so you can write and compile
PL/M programs, but I have not found a way of running them yet. From
what I have seen, I think it would still be a useful language today
and feel it would be quite rewarding to write programs in it.
However, there does not seem to be that much information on it
around. Also, Digital Research seem to have switched to C for later
versions of CP/M, for example, CP/M 68K. It looks to me as if PL/M is
regarded as a dead language by the majority today, but that sort of
thing have never stopped this newsgroup, has it?
Dave Daniels
Jonathan Griffitts
<eric-no-s...@brouhaha.com> writes
I remember ISIS-II fondly. It was nicer than CP/M in a lot of ways. The
filesystem was much better -- CP/M filesizes were multiples of 128 bytes
where ISIS allowed arbitrary filesizes. Also, CP/M did all disk I/O
operations in 128-byte sectors, ISIS let you stream arbitrary numbers of
bytes.
The major downside to ISIS-II was that its floppy handling was horribly
inefficient, spending all its time seeking back and forth across the
disk. I believe it was doing this to update a freespace bitmap on track
0, after every write operation. It took an outrageous amount of time to
do a compilation. It worked much better if you had one of the CDC Hawk
hard drives. Those would rock back and forth, but the seek time was
quick enough to take the pain out of it.
IMHO CP/M was seriously lame. Sometimes I see MS-DOS being compared
unfavorably with CP/M, and I wonder if those writers ever actually used
CP/M.
I once wrote an ISIS emulator to run under CP/M. 8080 assembly
language, of course. Now that was a fun hack! It worked -- I got the
Intel PLM/80 compiler running under it on an Altair 8800 (which was
itself modified with homebrew memory and I/O). It was interesting,
because the low-memory structures of CP/M dovetailed nicely with the
ISIS-II low-memory map without interference. I always suspected that
this was not an accident, that CP/M might have been developed under ISIS
or that they had to coexist at some point.
I still have that ISIS emulator on 8" CP/M floppies, stored in the
garage. Wonder if they're still readable.
--
Jonathan Griffitts
AnyWare Engineering Boulder, CO, USA
voice/fax: 303 442-0556 email jgrif...@spamcop.net
Goran Larsson
Jonathan Griffitts <jgrif...@spamcop.net> wrote:
> IMHO CP/M was seriously lame. Sometimes I see MS-DOS being compared
> unfavorably with CP/M, and I wonder if those writers ever actually used
> CP/M.
I have compared CP/M and MS-DOS in the past. If you compare MS-DOS
and CP/M from the same era before CP/M development stopped then you
will find that CP/M version 3 was way ahead of MS-DOS in 1982.
Comparing CP/M 2.2 to MS-DOS 5 is not fair.
Did you ever use CP/M version 3 on a system with more than 64KB
of memory? It was a quite nice system with password protection
on files, timestamp on files, automatic loading of system extensions
(a form of early DLL-files), I/O redirection in the CCP, etc.
--
Göran Larsson http://www.mitt-eget.com
Klemens Krause
is a relabeled Intel MDS-800 system. ISIS means:
Intel Systems Implementation Supervisor.
The ISIS-I-System had only 16K of memory and came without relocation or linking
facility. It had only an absolute assembler.
(ref.: Intel Microcomputer Systems Data Book 1976)
And Intel means: INTegrated ELectronics
On the ISIS-II filenames are 6+3. Extensions may be used, but have no meaning:
My system utilities have names like:
CREDIT
GANEF
KERMIT
PLM48
Extensions were used for source files:
TEST.ASM
KERMIT.PLM
and so on.
The first version of CP/M was developped on such an Intel MDS-800 system. It
was written in PL/M. The first version of PL/M was written in FORTRAN and
ran on DECs PDP-10.
In FORTRAN a maximal length of identifiers of 6 characters was not unusual.
Also on the small DEC-machines (PDP/8 under OS/8) filenames were of the 6+2
format: 6 charcters of 6 Bit fitted in three 12-Bit words, and an additional
word of 12 Bit contained the extension. (Memory was cotly at that time).
Klemens
Jonathan Griffitts schrieb:
>
> In article <qhk7rcx...@ruckus.brouhaha.com>, Eric Smith
> <eric-no-s...@brouhaha.com> writes
> >"Russell P. Holsclaw" <rhol...@nospam.xxx.fatline.com> writes:
> >> CP/M *was* the Intel development system, as far as I can remember.
> >
> >Nope. Intel shipped the systems with ISIS-II. I presume that before
> >ISIS-II there was an ISIS-I or an ISIS with no suffix, but I've never
> >seen that.
> >
> >ISIS-II is a lot different than CP/M, but it does use 8+3 filenames IIRC.
>
> I remember ISIS-II fondly. It was nicer than CP/M in a lot of ways. The
> filesystem was much better -- CP/M filesizes were multiples of 128 bytes
> where ISIS allowed arbitrary filesizes. Also, CP/M did all disk I/O
> operations in 128-byte sectors, ISIS let you stream arbitrary numbers of
> bytes.
>
email jgrif...@spamcop.net
--
----------------------------------------------
Klemens Krause
Universitaet Stuttgart / Inst. f. Informatik
Breitwiesenstr. 20-22 / 70565 Stuttgart
Tel.: 0711/7816 341
jmfb...@aol.com
"Douglas H. Quebbeman" <dqueb...@ixnayamspayacm.org> wrote:
>"Charles Richmond" <rich...@ev1.net> wrote in message
news:3CB47A4B...@ev1.net...
>> Eric Sosman wrote:
>> >
>> > Jim Haynes wrote:
>> > >
>> > > In article <wgsn66g...@nospam.glaramara.freeserve.co.uk>,
>> > > Alan J. Wylie <alan....@glaramara.freeserve.co.uk> wrote:
>> > > >
>> > > >Not ASCII.
>> > > >
>> > > OK, I shoulda said what I meant, a subset of ASCII consisting of
A-Z,
>> > > 0-9, and a few other things.
>> >
>> > No; that's a subset of EBCDIC. Or of the MIX 1009 characters.
>> >
>> > (In other words: ASCII is not just a set of glyphs and control
>> > functions, but a particular encoding for them. RAD50 encodes some
>> > of the same glyphs found in ASCII and EBCDIC and other codes, but
>> > since the encoding is completely different, RAD50 is neither of
>> > those codes, nor is it a subset of those codes.)
>> >
>> So why did CDC *not* adopt RAD50 as their 6-bit character set,
>> instead of developing their own???
>
>Mark Crispin has stated he thought that Radix-50 was in use on the
>PDP-1, which would date it back to what, '61? He says he's sure it
>was in use on the PDP-6 during the pre-timesharing days.
MACRO-10 used it for the hash tables. (Don't ask me what that
means, it's just something I heard over the wall.) We did not
use if for the filenames that were stored on the disk in the
RIBs.
/BAH
>
>HOWEVER, the design of the CDC 6000 series computers began in 1959,
>and if RAD50 was in use by that time, it wasn't likely being used
>widely. And they appear to have not wanted to continue using BCD...
>
>Regards,
>-doug q
>
Subtract a hundred and four for e-mail.
jmfb...@aol.com
ab...@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) wrote:
>Dee (d_...@my-deja.com) writes:
>>
>....
> That's interesting. I used PL/M at a defunct John Kelly outfit called
> NABU on a Z80 CP/M system, back in Sept. 82. (Some people in Ottawa
> may recall the names.) I will swear on a stack of Bible/Torah/Koran/
> McKeeman-Wortman-Hornings that PL/M is directly derived from XPL, the
> latter's simple PL student language for compiler writing.
>
> That it ever crossed over to PDP is amazing, given it's heavy IBM 360
> heritage.
Why is it amazing? Look. A university would go from IBM to DEC
PDP-10. Now all those kiddies who had waited in line for their
batch jobs could pound the terminal to their hearts' (or at least
RUNMAX) content. Directors of those computer centers, who grew
up with IBM, wanted to feel warm and loved. So they "assigned"
their work study kiddies, (or homework), to develop whatever the
directors liked about the IBM.
Why do think those PDP-10s were bought? You could do just about
anything with a -10...including getting screwed.
/BAH
Dee
There is no connection between PL/M and XPL. PL/M did not "cross over
to PDP", it was developed from scratch on the PDP-10 by Kildall. The
original compiler was written in FORTRAN, and it was "ported" to most
mainframes of the day, including IBM, CDC, etc.. The source to the
compiler is a deck of punched cards. When the PL/M-80 compiler was
made native on the 8080 based ISIS-II system, it was re-written in
PL/M by a company named "Caine Farber and Gordon" in the '70s (they
are still in business at www.cfg.com).
Steve O'Hara-Smith
Jonathan Griffitts <jgrif...@spamcop.net> wrote:
JG> IMHO CP/M was seriously lame. Sometimes I see MS-DOS being compared
JG> unfavorably with CP/M, and I wonder if those writers ever actually used
JG> CP/M.
I have often compared MS-DOS unfavourably with MP/M - I think that
is quite justified. Most of my clients at the time went from MP/M to XENIX
when they found that the mighty IBM PC couldn't do more than one thing at a
time. I used to get very good results out of bank switched CP/M machines
with 256K of memory - better than I could get out of XT clones with 640K.
--
C:>WIN | Directable Mirrors
The computer obeys and wins. |A Better Way To Focus The Sun
You lose and Bill collects. | licenses available - see:
| http://www.sohara.org/
Jonathan Griffitts
writes
>In article <dKyXHbFH...@qadas.com>,
>Jonathan Griffitts <jgrif...@spamcop.net> wrote:
>
>> IMHO CP/M was seriously lame. Sometimes I see MS-DOS being compared
>> unfavorably with CP/M, and I wonder if those writers ever actually used
>> CP/M.
>
>I have compared CP/M and MS-DOS in the past. If you compare MS-DOS
>and CP/M from the same era before CP/M development stopped then you
>will find that CP/M version 3 was way ahead of MS-DOS in 1982.
I'll admit I never saw CP/M 3 anywhere. I would have taken active
action to avoid using it, but in fact I don't recall ever having the
opportunity. When did CP/M 3 come out? I seem to remember 2.2 still
being mainstream in 1983.
>Comparing CP/M 2.2 to MS-DOS 5 is not fair.
I agree. Was someone doing that?
CP/M 2 looks pretty sick compared to MS-DOS 2. I can't remember MS-DOS
1 clearly enough to make that comparison. And my major point (you
snipped it) was that CP/M looks really bad in comparison with ISIS-II,
which predates it.
MS-DOS is lame and irritating in a lot of ways, also. It never came
close to taking advantage of the available hardware. But CP/M was not
just limited, it was (IMO) seriously misdesigned.
Goran Larsson
Jonathan Griffitts <jgrif...@spamcop.net> wrote:
> When did CP/M 3 come out? I seem to remember 2.2 still
> being mainstream in 1983.
I think it was some time in 1982. Due to, for me, unknown reasons
most manufacturers continued with CP/M 2.2. The difference between
2.2 and 3 is quite large. Many features, like relocatable files,
was inherited from MP/M.
> And my major point (you
> snipped it) was that CP/M looks really bad in comparison with ISIS-II,
> which predates it.
What I saw of ISIS-II did not impress me. The Intel MDS system impressed
me even less after seeing my software running on it the first time. So
much hardware for so little result...
> But CP/M was not
> just limited, it was (IMO) seriously misdesigned.
What was so misdesigned about CP/M? For its time it was one of the
few systems that ran on different hardware from many different
manufacturers. It ran on systems with very little RAM. It managed
to grow from the original limited CP/M 1 to CP/M 3 with memory
management, passwords, timestamps, etc without major compatibility
problems. Compared with systems of today it was limited and primitive,
but I can't agree that it was misdesigned.
Gene Wirchenko
[snip]
>Why is it amazing? Look. A university would go from IBM to DEC
>PDP-10. Now all those kiddies who had waited in line for their
>batch jobs could pound the terminal to their hearts' (or at least
>RUNMAX) content. Directors of those computer centers, who grew
>up with IBM, wanted to feel warm and loved. So they "assigned"
>their work study kiddies, (or homework), to develop whatever the
>directors liked about the IBM.
>
>Why do think those PDP-10s were bought? You could do just about
>anything with a -10...including getting screwed.
Flexible hardware!
Didn't you say in another thread about JMF derailing rants on the
Next Big Thing with "But can it fuck?"
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
Charles Richmond
>
> ab...@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) wrote in message news:<a988g4$jq1$1...@freenet9.carleton.ca>...
> > Dee (d_...@my-deja.com) writes:
> > >
> > ...
> > > The original PL/M was developed on a PDP-10 system by Kildall. As for
> > ...
> > That's interesting. I used PL/M at a defunct John Kelly outfit called
> > NABU on a Z80 CP/M system, back in Sept. 82. (Some people in Ottawa
> > may recall the names.) I will swear on a stack of Bible/Torah/Koran/
> > McKeeman-Wortman-Hornings that PL/M is directly derived from XPL, the
> > latter's simple PL student language for compiler writing.
> >
> > That it ever crossed over to PDP is amazing, given it's heavy IBM 360
> > heritage.
>
> There is no connection between PL/M and XPL.
>
IMHO there *is* a connection between PL/M and XPL. The connection
is that *both* were developed by people who were using PL/I as
a model. So, PL/I *is* the connection...
--
+-------------------------------------------------------------+
| Charles and Francis Richmond <rich...@plano.net> |
+-------------------------------------------------------------+
jmfb...@aol.com
ge...@mail.ocis.net (Gene Wirchenko) wrote:
>jmfb...@aol.com wrote:
>
>[snip]
>
>>Why is it amazing? Look. A university would go from IBM to DEC
>>PDP-10. Now all those kiddies who had waited in line for their
>>batch jobs could pound the terminal to their hearts' (or at least
>>RUNMAX) content. Directors of those computer centers, who grew
>>up with IBM, wanted to feel warm and loved. So they "assigned"
>>their work study kiddies, (or homework), to develop whatever the
>>directors liked about the IBM.
>>
>>Why do think those PDP-10s were bought? You could do just about
>>anything with a -10...including getting screwed.
>
> Flexible hardware!
And usually when you weren't looking.
>
> Didn't you say in another thread about JMF derailing rants on the
>Next Big Thing with "But can it fuck?"
Not JMF. That one was TW's line (Tony Wachs).
In TW's opinion, if any idea coming from the first floor
was so great, it had better include some sex. TW had many
lines that became famous in the -10 world.
Douglas H. Quebbeman
> In article <AtigOrTEV0u8EAr$@qadas.com>,
> Jonathan Griffitts <jgrif...@spamcop.net> wrote:
>
> > When did CP/M 3 come out? I seem to remember 2.2 still
> > being mainstream in 1983.
>
> I think it was some time in 1982. Due to, for me, unknown reasons
> most manufacturers continued with CP/M 2.2. The difference between
> 2.2 and 3 is quite large. Many features, like relocatable files,
> was inherited from MP/M.
The Resident System Extension (RSX) mechanism came with CP/M 3,
or CP/M+ as it was more widely known. I back-ported the mechanism
and a a few RSXs to CP/M 2.2, may still have that stuff somewhere.
CP/M+ shipped as the OS for the Z-80 CPU in the Commodore 128, IIRC.
-dq
Stan Barr
<dqueb...@ixnayamspayacm.org> wrote:
>"Goran Larsson" <h...@invalid.invalid> wrote in message =
>news:GuMvJ...@approve.se...
>> In article <AtigOrTEV0u8EAr$@qadas.com>,
>> Jonathan Griffitts <jgrif...@spamcop.net> wrote:
>> > When did CP/M 3 come out? I seem to remember 2.2 still
>> > being mainstream in 1983.
>> I think it was some time in 1982. Due to, for me, unknown reasons
>> most manufacturers continued with CP/M 2.2. The difference between
>> 2.2 and 3 is quite large. Many features, like relocatable files,
>> was inherited from MP/M.
>
>The Resident System Extension (RSX) mechanism came with CP/M 3,
>or CP/M+ as it was more widely known. I back-ported the mechanism
>and a a few RSXs to CP/M 2.2, may still have that stuff somewhere.
>
>CP/M+ shipped as the OS for the Z-80 CPU in the Commodore 128, IIRC.
I had CP/M+ for my Einstein and my brother ran it on an Amstrad 464
so it must have been fairly common.
There was also ZCPR3...
--
Cheers,
Stan Barr st...@dial.pipex.com
The future was never like this!
gray...@yahoo.com
A system that couldn't (really) format disks for itself!
Will Salt
It was the Amstrad CPC6128 that came with CP/M+. You got CP/M 2.2
(IIRC) if you bought a CPC664, or the disk drive upgrade to the
CPC464. The 6128 was supplied with both, for compatibility.
It was possible to upgrade a 464 so it was essentially a 6128, though;
I remember a magazine project which involved getting the extra memory
and a 6128 firmware rom, and wiring them up in a wee box which
connected to the expansion port and had a switch to select which
computer you wanted to run.
--
Will Salt
Simon Bowring
>As I said above, I recall the other bytes getting used later. Timestamps
>were not part of it, though. I don't remember seeing timestamps until MS-DOS
>1.1 (1.0 didn't even have them, although they were planned.)
I'm certain CP/M 3.x (CP/M+) had filestamps (but in many ways CP/M 3.x
was better than MS/PC DOS 1.x, which was a giant leap backwards)
I have the sources somewhere.....!
Simon
Simon Bowring
>IMHO CP/M was seriously lame. Sometimes I see MS-DOS being compared
>unfavorably with CP/M, and I wonder if those writers ever actually used
>CP/M.
Oooooh, bait me!
I don't agree or understand how you came to that conclusion!
MS-DOS 1.0 was really QDOS which was a quick and dirty "clone" of
CP/M 2.2-ish, so at best MS-DOS 1.0 was approximately equivalent
to CP/M 2.2 (can't think of anything they "improved" off-hand?).
However by the time IBM PCs running PC-DOS 1.1, were on the streets,
the superior CP/M 3.0 ("CP/M plus") was out IIRC, shortly followed
by 3.1
CP/M 3.x was a big increment on CP/2.2, and certainly still
better than MS DOS 1.x, though for *serious* use CP/M 3.x required
an HD (a large £600 5Mb one would do ;-) I used to have a ginormous
43Mb HD on my CP/M system, years before DOS could handle a 32Mb unit!
3.0 had a proper RSX system (TSRs done right; have you ever had to
program serious TSRs like I have?), supported a larger TPA than 2.2
by allowing bank switching (our Cifer systems had 128(-256)kB fitted
with TPAs of up to about 61kB, the rest of RAM being used for
disk-cache), CP/M supported the "user area" concept (poor man's
directories) before MS-DOS had any dirs, it also had file system
time-stamps, and a better architecture (BIOS, CBIOS and BDOS
separation stuff), and supported interesting ideas like bothering
to have an on-line help system (modelled after DECs).
You could do stuff like configure CP/M 3's "search paths" e.g. to
run a .SUB (".BAT") file before a .com (.EXE) of the same name, so
that you could wrap programs up in a script, and PIP was way better
than COPY
Also quite a lot of "added value" was often deployed "behind" CP/M
e.g.many OEMs allowed booting off arbitrary devices, offered better FD
capacity (800kB vs 360kB), interrupt driven async comms etc, although
this is admittedly a different argument!!
Simon
Neil Franklin
> On Sun, 14 Apr 2002 23:45:43 -0600, Jonathan Griffitts wrote:
>
> >IMHO CP/M was seriously lame. Sometimes I see MS-DOS being compared
> >unfavorably with CP/M, and I wonder if those writers ever actually used
> >CP/M.
>
> I don't agree or understand how you came to that conclusion!
>
> MS-DOS 1.0 was really QDOS which was a quick and dirty "clone" of
> CP/M 2.2-ish, so at best MS-DOS 1.0 was approximately equivalent
> to CP/M 2.2 (can't think of anything they "improved" off-hand?).
I can think of one thing: precise file lengths.
Of course that does not change your basic statement that MS-DOS 1.x
was inferiour to CM/P 2.2.
--
Neil Franklin, ne...@franklin.ch.remove http://neil.franklin.ch/
Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer
- Make your code truely free: put it into the public domain
Charlie Gibbs
(Neil Franklin) writes:
>"Simon Bowring" <sbowrin...@mpc-data.co.uk> writes:
>
>> MS-DOS 1.0 was really QDOS which was a quick and dirty "clone" of
>> CP/M 2.2-ish, so at best MS-DOS 1.0 was approximately equivalent
>> to CP/M 2.2 (can't think of anything they "improved" off-hand?).
>
>I can think of one thing: precise file lengths.
...which made CP/M's EOF character (0x1A) completely unnecessary,
but MS-DOS clung to it anyway. This caused all sorts of data loss.
Also, as someone else pointed out, CP/M's PIP was superior to
MS-DOS's COPY, if for no other reason than that it would copy
zero-length files.
Speaking of zero-length files, did anyone else use that trick
of creating a zero-length .COM file? Nothing would load, but
the machine would jump to 0x100. If the last program you ran
was serially re-usable, this was a quick way to re-run it.
>Of course that does not change your basic statement that MS-DOS 1.x
>was inferiour to CM/P 2.2.
Or, as they say, CP/M was a great improvement on its successors.
--
cgi...@sky.bus.com (Charlie Gibbs)
Remove the first period after the "at" sign to reply.
I don't read top-posted messages. If you want me to see your reply,
appropriately trim the quoted text and put your reply below it.
Daniel P. B. Smith
"Douglas H. Quebbeman" <dqueb...@ixnayamspayacm.org> wrote:
> "Charles Richmond" <rich...@ev1.net> wrote in message
> news:3CB47A4B...@ev1.net...
> > Eric Sosman wrote:
> > >
> > > Jim Haynes wrote:
> > > >
> > > > In article <wgsn66g...@nospam.glaramara.freeserve.co.uk>,
> > > > Alan J. Wylie <alan....@glaramara.freeserve.co.uk> wrote:
> > > > >
> > > > >Not ASCII.
> > > > >
> > > > OK, I shoulda said what I meant, a subset of ASCII consisting of A-Z,
> > > > 0-9, and a few other things.
> > >
> > > No; that's a subset of EBCDIC. Or of the MIX 1009 characters.
> > >
> > > (In other words: ASCII is not just a set of glyphs and control
> > > functions, but a particular encoding for them. RAD50 encodes some
> > > of the same glyphs found in ASCII and EBCDIC and other codes, but
> > > since the encoding is completely different, RAD50 is neither of
> > > those codes, nor is it a subset of those codes.)
> > >
> > So why did CDC *not* adopt RAD50 as their 6-bit character set,
> > instead of developing their own???
>
> Mark Crispin has stated he thought that Radix-50 was in use on the
> PDP-1, which would date it back to what, '61? He says he's sure it
> was in use on the PDP-6 during the pre-timesharing days.
Yes, Radix-50 was used on the PDP-1. But maybe not in the way you'd
expect. The PDP-1 had an eighteen-bit word and six-bit characters, so
the NATURAL packing was three six-bit characters into a word.
And you can't cram four letters of the alphabet into an eighteen bit
word; 26^4 is greater than 2^18, or to put it another way the fourth
root of 2^18 is 22.6...
Anyway, I no longer remember the exact application but there WERE PDP-1
applications that used Radix-50 to store three characters in an 18-bit
word and made some creative use of the two extra bits. I have an idea
that perhaps some assemblers stored their symbol tables that way.
Kind of surprising, in retrospect, since the PDP-1 had an 0.2 MHz clock
and I believe that integer multiplies and divides took a significant
number of clock cycles...
--
Daniel P. B. Smith
Email address: dpbs...@world.std.com
"Lifetime forwarding" address: dpbs...@alum.mit.edu
Eric Smith
> CP/M 2.2-ish, so at best MS-DOS 1.0 was approximately equivalent
> to CP/M 2.2 (can't think of anything they "improved" off-hand?).
One obvious improvement is that IBM-DOS (and MS-DOS) support
byte-granularity for the end-of-file mark.
Klemens Krause
>
> In article <6ug01sd...@chonsp.franklin.ch> ne...@franklin.ch.remove
> (Neil Franklin) writes:
>
> >"Simon Bowring" <sbowrin...@mpc-data.co.uk> writes:
> >
> >> MS-DOS 1.0 was really QDOS which was a quick and dirty "clone" of
> >> CP/M 2.2-ish, so at best MS-DOS 1.0 was approximately equivalent
> >> to CP/M 2.2 (can't think of anything they "improved" off-hand?).
> >
> >I can think of one thing: precise file lengths.
>
> ...which made CP/M's EOF character (0x1A) completely unnecessary,
> but MS-DOS clung to it anyway. This caused all sorts of data loss.
>
I think CP/M was a bad clone of the older DEC-operating systems, especially
PS/8 and OS/8 from 1970. Those systems ran in 8K (12Bit) memory machines.
Room for directory entries was limited, so they had no exact file lengths
entries used 6.2 filenames and needed the EOF-character.
But: They had a date stamp for file generation. Even if it was limited to
8 years. Also to save room in the directory.
OS/8 had:
* A multilevel HELP-system with topics and subtopics. Greetings
to VMS.
* A sorted directory listing (name, extension, date), 1 column, 2 columns
3 columns as you like it.
* The possibility to assign logical devicenames to an physical device.
Standard device names are SYS: and DSK: You can for example assign
the DSK: device to a RK05-disk or to one of many DEC-Tape drives as
needed. This is have way to subdirectories.
* PIP. A multipurpose program, which also can copy files. It could be
used to copy files, to show directories so you had not to leave it, while
doing a multi-file copy, to unerase files, to install the operating system
and others.
* CCL a command processor which in CP/M became CCP. OS/8 is able to run
without this CCL to speed up the system.
> Also, as someone else pointed out, CP/M's PIP was superior to
> MS-DOS's COPY, if for no other reason than that it would copy
> zero-length files.
>
> Speaking of zero-length files, did anyone else use that trick
> of creating a zero-length .COM file? Nothing would load, but
> the machine would jump to 0x100. If the last program you ran
> was serially re-usable, this was a quick way to re-run it.
>
In OS/8 .SV-files there is a header which contains some usefull tags:
One indicates, that a program can be restarted without reloading it.
If the program ist not restartable, CCP answers
NO!
if you try it.
Another bit indicates if the programm uses system areas in the memory.
If yes, they are reloaded after the program finished, if not, this is
not done and you save speed.
Some said, CP/M is lame:
Is it really? OS/8 running with RK05 drives is very fast, OS/8 running
with RX01-floppies is lame. I only know CP/M systems running with
floppies. I never worked with a hardisk CP/M.
> >Of course that does not change your basic statement that MS-DOS 1.x
> >was inferiour to CM/P 2.2.
>
> Or, as they say, CP/M was a great improvement on its successors.
>
Please let me change this to:
OS/8 was a great improvement to ...
Klemens
Simon Bowring
>I can think of one thing [DOS 1.x improved over CP/M 2.2]: precise file
lengths.
You're absolutely right of course, but do you realise that file-lengths
are *still* ACU under Windows today???!!
DOS/Windows (like Unix) has no concept of a file-type, but if an application
opens a file in text mode, it will appear truncated at the first ^Z
character, even if if it's the 2nd byte in a 12Mb file or whatever!!
If you open the same file in binary mode, it will not appear to
end at byte 2, but will go on to 12Mb as expected!
>Of course that does not change your basic statement that MS-DOS 1.x
>was inferiour to CM/P 2.2.
Indeed!
Simon
Charlie Gibbs
sbowrin...@mpc-data.co.uk (Simon Bowring) writes:
>DOS/Windows (like Unix) has no concept of a file-type, but if an
>application opens a file in text mode, it will appear truncated
>at the first ^Z character, even if if it's the 2nd byte in a 12Mb
>file or whatever!!
Now just imagine what happens if a byte gets corrupted to 0x1a,
or if such a byte somehow appeared in an input stream...
If you open a file for append in text mode (fopen ("foo", "ab")),
the library has to check the last byte of an existing file to see
whether it's 0x1a - if so, it backs up the file pointer so the
first write overwrites it. We discovered the hard way that
versions of COMMAND.COM back around 3.1 didn't do this if you
redirected stdout with append (e.g. dir >>foo). The appended
data was there, but hiding behind the 0x1a. We lost a lot of
logs before I realized the awful truth - and promptly wrote my
own program, which I could trust to do the append correctly.
IMHO the EOF character is one of the most evil aspects of
MS-DOS/Windows.
Neil Franklin
> Speaking of zero-length files, did anyone else use that trick
> of creating a zero-length .COM file? Nothing would load, but
> the machine would jump to 0x100. If the last program you ran
> was serially re-usable, this was a quick way to re-run it.
Now that is a nice hack.
Hmmm, .COM files reminds me of one of the sillier things I once did
(over 10 years ago):
- have an MS-DOS PC (and be an total PC user, no clue of VMS)
- have networking software (DEC Pathworks) with an VAX/VMS system as
server (I was the first to get Ethernet in our group)
- mount VMS home directory to PC, as intended
- list its directory (yipee this network thing works!)
- see an unknown "program" LOGIN.COM (must be from the network software)
- wonder what it is and run it -> One PC crashed real fast
For non-VMS-ers: .COM on VMS are command files (like .BAT under
MS-DOS, LOGIN.COM is users equivalent AUTOEXEC.BAT or rather Unix
.profile). 80486 does not like executing ASCII.
> >Of course that does not change your basic statement that MS-DOS 1.x
> >was inferiour to CM/P 2.2.
>
> Or, as they say, CP/M was a great improvement on its successors.
That was the line I was looking for.
Jonathan Griffitts
<sbowrin...@mpc-data.co.uk> writes
>On Sun, 14 Apr 2002 23:45:43 -0600, Jonathan Griffitts wrote:
>
>>IMHO CP/M was seriously lame. Sometimes I see MS-DOS being compared
>>unfavorably with CP/M, and I wonder if those writers ever actually used
>>CP/M.
>
>Oooooh, bait me!
>
>I don't agree or understand how you came to that conclusion!
When I wrote the note that started this subthread, I included that one
throwaway sentence you've quoted. Apparently, mentioning MS-DOS pushed
too many buttons and everyone is discussing only that sentence. That
was a mistake on my part, because MS-DOS wasn't important to my point
(and I'm not a huge fan of MS-DOS either).
So please let me restate: when CP/M was new, long before MS-DOS
existed, I despised CP/M and felt that it compared badly to the state of
the art.
I'll expand on that, for those who care. First a little context:
Prior to the advent of microcomputers, I had programmed a motley
assortment of machines including punch-card batch on IBM OS/360 and
1130, also CDC KRONOS, and others, TTYs and dumb CRT terminals on XDS
940, HP 2000, DG Nova. others. CDC Plato terminals.
The first 8-bit micros I played with were proprietary things including a
homebrew of my own. I did quite a bit of low-level code (proprietary OS
and I/O driver work) and experienced the Intel MDS "Blue Box"
boat-anchor along the way.
With that background, I then got very familiar with CP/M 1.4 including
writing BIOSes to adapt it to two different machines. I also wrote an
emulator to run ISIS-II programs under CP/M. After that experience, I
tried to avoid contact with CP/M but did have some exposure to CP/M 2.2.
I don't think I ever saw CP/M 3, and in fact until this thread I had
forgotten its existence.
Elsewhere in the thread,
In article <GuMvJ...@approve.se>, Goran Larsson <h...@invalid.invalid>
writes
. . .
>What was so misdesigned about CP/M?
. . .
The file system, for one thing. The most obvious defect was that it did
everything in 128-byte sector increments (including file sizes and
read/write operations).
The filesystem was also very fragile, storing all the file directory
structure in track zero of the disk and then frequently trashing that.
ISIS-II, by comparison, stores file allocation chains as linked lists
through the disk, so if you lose the master directory you lose the
filenames but the file chains are recoverable. Other proprietary
filesystems I saw in the late 70s (on 8-bit microprocessors) did similar
things.
The FCB (File Control Block) stuff was awfully clumsy and exposed the
guts of the filesystem to user code. CP/M required user code to
frequently swap the FCB data in and out of the default FCB slots.
Screwing up the FCBs would corrupt the directory on disk.
The filesystem (for CP/M 1.4 anyway) was completely built around 128
byte sector sizes, and IIRC did a wierd 6-way software interleave of
sector numbers (instead of doing the interleave during diskette
formatting). The whole setup looked to me as if the architect of CP/M
had a poor understanding of disks/diskettes. If you were trying to work
with a system that wanted other sector sizes or interleaves, CP/M forced
you to commit kludge. (I seem to recall that this stuff may have been
improved in CP/M 2.2)
CP/M used a dollar-sign as a string terminator in several cases. What a
strange choice -- perhaps they never expected anyone to trust CP/M with
any work involving money?
The memory map was pretty strange, too. The BIOS (? and BDOS ?) were
located at the *high* end of memory, so a boot disk had to have the code
relinked specifically for the amount of memory in the target machine.
This interacts oddly with memory bank-switching schemes, and it's a pain
if you want to move between machines with different amounts of memory.
The 8080 hardware reset starts PC at location zero so an obvious system
design would put a boot ROM at zero, but CP/M was not compatible with
this -- the boot ROM had to make itself disappear and map RAM in its
place sometime early in the boot process (called "phantom ROM" as I
recall).
PIP worked but was obscure. I always found myself having to go for the
manual to remember how to work PIP.
There was no reasonable text editor. There was an extremely brain-dead
line editor, only marginally usable. BTW at the time I was very
comfortable with line editors in general, but this one was BAD.
That's what I can remember off the top of my head. It's been 20 years
since I thought about this stuff.
Back in those days, I spent considerable time cursing CP/M, I'll stick
with my opinion -- CP/M wasn't just primitive, it was badly designed.
Gary Renaud
.COM programs were simple binary images, yet could be used on any CP/M
system, since they always started at the same address. You didn't need
any kind of relocating loader, saving execution time and space. The
8080 didn't have a lot of either.
I don't know if this was the right decision, but it is defensible.
--
RIP Coconut 16 APR 02. The best dog in the whole world.
2 years was far less than he deserved.
Gary Renaud (Cami too!) gre...@acm.org <--- Please use this
For contact info, see: http://home.earthlink.net/~sleepyjackal/contact.htm
Goran Larsson
Jonathan Griffitts <jgrif...@spamcop.net> wrote:
> The filesystem was also very fragile, storing all the file directory
> structure in track zero of the disk and then frequently trashing that.
Track zero was used for booting so there is no directory there. I can't
remember having even one trashed directory.
> The filesystem (for CP/M 1.4 anyway) was completely built around 128
> byte sector sizes, and IIRC did a wierd 6-way software interleave of
> sector numbers (instead of doing the interleave during diskette
> formatting).
I didn't see any interleave in CP/M 2 or CP/M 3. CP/M 2 could do any
sector size by adding code to the BIOS, CP/M 3 could do any sector
size with code already in the BDOS.
William Hamblen
wrote:
>I didn't see any interleave in CP/M 2 or CP/M 3. CP/M 2 could do any
>sector size by adding code to the BIOS, CP/M 3 could do any sector
>size with code already in the BDOS.
Interleave in this context meaning disk sectors not in sequence,
"standard" CP/M 8" single density disks were off by six: sectors were
numbered 1, 7, 13, 19, etc. CP/M 1 was hard coded for IBM 8" disks
and you had to cobble up your CBIOS to make CP/M think it was running
on an 8" floppy. CP/M 2 had tables that let you specify most of the
disk characteristics but you had to do blocking/deblocking in your
CBIOS.
CP/M 2 was pretty minimal as it would run on an 8080 with only 20K of
RAM. If CP/M sucked, some other 8080 disk systems sucked harder.
There wasn't any difference between a "user" program and a
"supervisor" program on an 8080, except that imposed by self
discipline. That unfortunate fact also was true for the 8088.
Richard E. Hawkins
>Why do think those PDP-10s were bought? You could do just about
>anything with a -10...including getting screwed.
So like so many other things, computer sex originates with DEC? :)
hawk
--
Richard E. Hawkins, Asst. Prof. of Economics /"\ ASCII ribbon campaign
doc...@psu.edu Smeal 178 (814) 375-4700 \ / against HTML mail
These opinions will not be those of X and postings.
Penn State until it pays my retainer. / \
dawks
<william...@nashville.com> wrote:
>On Sat, 20 Apr 2002 04:28:42 GMT, h...@invalid.invalid (Goran Larsson)
>wrote:
>
>>I didn't see any interleave in CP/M 2 or CP/M 3. CP/M 2 could do any
>>sector size by adding code to the BIOS, CP/M 3 could do any sector
>>size with code already in the BDOS.
>
>Interleave in this context meaning disk sectors not in sequence,
>"standard" CP/M 8" single density disks were off by six: sectors were
>numbered 1, 7, 13, 19, etc. CP/M 1 was hard coded for IBM 8" disks
>and you had to cobble up your CBIOS to make CP/M think it was running
>on an 8" floppy. CP/M 2 had tables that let you specify most of the
>disk characteristics but you had to do blocking/deblocking in your
>CBIOS.
>
>CP/M 2 was pretty minimal as it would run on an 8080 with only 20K of
>RAM. If CP/M sucked, some other 8080 disk systems sucked harder.
Yeah, i wrote one. In my defence, there was only 3/4K bytes of ram
available.
Interleaving was soimething of an exercise since a lot depended on how
much work the app needed to do with a sector. There was also an issue
of powering down the drive motor which lent a new meaning to latency.
Formatting was done on a separate machine that had enough memory to
hold a complete track.
>
>There wasn't any difference between a "user" program and a
>"supervisor" program on an 8080, except that imposed by self
>discipline. That unfortunate fact also was true for the 8088.
>
Had no complaints with the 8080 as it was a very simple microprocessor
and at least it had a call instruction, unlike some. However, the
8086/8088 was a major disappointment; i was at least looking for some
sort of half usable supervisor mode. I think the PC would have moved
along faster had it been Moto 68K based.
phil.
--
The world is divided into two sorts of people: those that believe
that the world is divided into two sorts of people and those that don't.
jmfb...@aol.com
ha...@fac13.ds.psu.edu (Richard E. Hawkins) wrote:
>In article <a9eh90$4dv$9...@bob.news.rcn.net>, <jmfb...@aol.com> wrote:
>
>>Why do think those PDP-10s were bought? You could do just about
>>anything with a -10...including getting screwed.
>
>So like so many other things, computer sex originates with DEC? :)
We didn't originate it; we just made it easier to commit.