What is Result Code = -208?
Robert Peirce
Toast Titanium 7 when trying to write a DVD. It had been working fine
up to that point.
I copied the mpeg file to a burn folder and tried to burn it from there.
It is currently burning at 2X, which suggests the problem is with Toast.
--
Robert B. Peirce, Venetia, PA 724-941-6883
bob AT peirce-family.com [Mac]
rbp AT cooksonpeirce.com [Office]
Claude V. Lucas
Robert Peirce <b...@peirce-family.com.invalid> wrote:
>I suddenly started to get a Mac OS Error with this Result Code from
>Toast Titanium 7 when trying to write a DVD. It had been working fine
>up to that point.
>
>I copied the mpeg file to a burn folder and tried to burn it from there.
>It is currently burning at 2X, which suggests the problem is with Toast.
>
Does the DVD play without issues?
I've always gotten the occasional indecipherable error message with
meaningless codes while using Toast in all versions from 7 up to 10.
Usually while writing the leadout except when the blank is no good.
In most cases that's had little to no effect on the playability.
See if it plays...
Try a different blank.
Try a different brand of blanks.
Most burners have preferences in blanks, for some reason...
If anyone has a good pointer to the Rosetta Stone for Mac OS Error Codes,
I'd appreciate a linky, too.
Gregory Weston
Robert Peirce <b...@peirce-family.com.invalid> wrote:
> I suddenly started to get a Mac OS Error with this Result Code from
> Toast Titanium 7 when trying to write a DVD. It had been working fine
> up to that point.
>
> I copied the mpeg file to a burn folder and tried to burn it from there.
> It is currently burning at 2X, which suggests the problem is with Toast.
Incorrect file format. For more detail we'd probably need to know
exactly what Toast was trying to do ... more specific than anything it's
likely presenting to a user.
--
I saw a truck today that had "AAA Batteries / Delivered and Installed" on the
side. My first thought was: That's a really weird business model. How many
inept people have urgent need of skinny little battery cells?
Robert Peirce
Gregory Weston <u...@splook.com> wrote:
> In article <bob-424F41.21090522042009@[199.45.49.11]>,
> Robert Peirce <b...@peirce-family.com.invalid> wrote:
>
> > I suddenly started to get a Mac OS Error with this Result Code from
> > Toast Titanium 7 when trying to write a DVD. It had been working fine
> > up to that point.
> >
> > I copied the mpeg file to a burn folder and tried to burn it from there.
> > It is currently burning at 2X, which suggests the problem is with Toast.
>
> Incorrect file format. For more detail we'd probably need to know
> exactly what Toast was trying to do ... more specific than anything it's
> likely presenting to a user.
This was an mpeg file created by MPEG Streamclip. The disks are TDK
DVD-R. I had just written two discs from VIDEO_TS files followed by four
disks from MPEG Streamclip files. The next two MPEG Streamclip files
failed immediately with a panel that said:
Could not write disk because of a Mac OS Error.
Result Code = -208.
As a test, I tried to write a disk with a file that had already written
successfully and it started to spool properly. I forced quit it before
it could actually start to write anything.
I then reloaded the problem files into MPEG Streamclip and they worked
just fine there.
Should I assume the MPEG Streamclip files have a problem? If so, should
I just load them and resave them or should I rebuild them from the
original files?
Robert Peirce
Robert Peirce <b...@peirce-family.com.invalid> wrote:
> Should I assume the MPEG Streamclip files have a problem? If so, should
> I just load them and resave them or should I rebuild them from the
> original files?
OK. I loaded and resaved the files. That didn't work. I re-edited one
of the sources in MPEG Streamclip and saved that. It didn't work
either!!
I have two movies Toast Titanium 7 doesn't like and I don't know why.
MartinC
> OK. I loaded and resaved the files. That didn't work. I re-edited one
> of the sources in MPEG Streamclip and saved that. It didn't work
> either!!
>
> I have two movies Toast Titanium 7 doesn't like and I don't know why.
You are lucky if it's only two...
To cut a long story short: Although most consumer DVD players are able to
virtually play back any MPEG file, the DVD specification only allows very
specific files - as a matter of fact DVDs actually need specific MPEG-2
files and VCDs need specific MPEG-1 files. iDVD, for example, is *very*
picky - unless every single parameter within the MPEG-2 does exactly match
the required specs it will always re-encode the entire file.
Different to that, Toast was always very forgiving and allowed to burn many
non-standard (including slightly damaged) files. Toast 7 did that, Toast 8
allowed for more files (but introduced bugs that never got fixed), Toast 9
allowed for much more files (but introduced even more bugs that *finally*
got fixed in Toast 9.0.3).
I'm currently so happy with the fixed Toast 9 that I will refuse to buy
Toast 10 unless I really need a new feature...
So, most likely, your two MPEG files simply have some non-standard
parameters that make Toast 7 stumble. There may be a chance that Toast 9
would do it, but even Toast 9 does not burn *every* MPEG file (for example,
if it was catenated from separate chunks, and if some of the chunks have a
different encoding then it will play in Quicktime but won't be burned by
Toast)
Geoffrey S. Mendelson
> To cut a long story short: Although most consumer DVD players are able to
> virtually play back any MPEG file, the DVD specification only allows very
> specific files - as a matter of fact DVDs actually need specific MPEG-2
> files and VCDs need specific MPEG-1 files. iDVD, for example, is *very*
> picky - unless every single parameter within the MPEG-2 does exactly match
> the required specs it will always re-encode the entire file.
The early (circa 2000) ones could only handle a limited set of MPEG-2 and
MPEG-1 files because they used hardware decoding chips designed to fit those
specs and nothing else.
The current crop of players use software (possibly with hardware assitance)
decoding, and can decode almost anything. The ones with USB ports are
the most versatile, they can decode many MPEG formats (and some others too)
as long as they are wrapped in an AVI wrapper.
One of the big problems with home burnt DVD's is that the file names must
be UPPER case and many players ignore them if in lower case.
I don't know if Windows Media player has been fixed, but older versions
would refuse to play DVDs that even real players would if they were slightly
out of spec.
These days, I'm not sure why people would bother to burn a DVD unless they
are mastering one for production or know the people it is for can't play it.
Just about every computer made (except for a few ARM based netbooks) can
play an MPEG-4 (either the "free" version or DIVX) file with an AVI
wrapper, and all(?) current DVD players.
Geoff.
--
Geoffrey S. Mendelson, Jerusalem, Israel g...@mendelson.com N3OWJ/4X1GM
Robert Peirce
MartinC <nor...@hotmail.com> wrote:
> Robert Peirce wrote:
>
> > OK. I loaded and resaved the files. That didn't work. I re-edited one
> > of the sources in MPEG Streamclip and saved that. It didn't work
> > either!!
> >
> > I have two movies Toast Titanium 7 doesn't like and I don't know why.
>
> I'm currently so happy with the fixed Toast 9 that I will refuse to buy
> Toast 10 unless I really need a new feature...
>
> So, most likely, your two MPEG files simply have some non-standard
> parameters that make Toast 7 stumble. There may be a chance that Toast 9
> would do it, but even Toast 9 does not burn *every* MPEG file (for example,
> if it was catenated from separate chunks, and if some of the chunks have a
> different encoding then it will play in Quicktime but won't be burned by
> Toast)
I am currently happy with 7, which fixed a lot of problems with earlier
releases, so I have been reluctant to move forward. Up until now it has
done everything I needed to do without any program failures. I did have
a problem with printable DVDs, but I couldn't write them with anything,
so it wasn't Toast
I think you are probably correct in your analysis. Earlier this morning
I ran the two movies through myDVDEdit to clean up the headers. Then I
converted them to mpeg with MPEG Streamclip and tried to write a DVD
with Toast Titanium 7. It worked! At least it started to multiplex the
files where before it was failing right at the beginning.
Later today I am going to re-edit the files to clean out the commercials
and try to write them again. I think/hope this time it will work.
MartinC
> Later today I am going to re-edit the files to clean out the commercials
> and try to write them again. I think/hope this time it will work.
You should definitely try this first, but from my own experience the odds
are that Toast still refuses - the problems that cause Toast to fail are
typically untouched by MPEG Streamclip.
If all else fails you can open the "Video" panel in Toast and click More >
Encoding and then set the re-encoding option (temporarily) to "always".
Then Toast will entirely re-encode the film even if it would initially
believe that it can handle it without. As long as QT plays the original
source film, this should work.
Robert Peirce
MartinC <nor...@hotmail.com> wrote:
I already fixed the header problems with myDVDEdit and wrote the files
out with MPEG Streamclip. I tested them with Toast and both worked, so
I am hoping further editing the files with MPEG Streamclip will not
screw them up again. It shouldn't, but who knows?
Wes Groleau
> I suddenly started to get a Mac OS Error with this Result Code from
<rant>
In 1980, some eight-bit operating systems had informative
(somewhat) diagnostic messages. There is no excuse for
this kind of crap in 2009.
</rant>
--
Wes Groleau
Recognize these?
http://Ideas.Lang-Learn.us/WWW?itemid=52
Gregory Weston
Wes Groleau <grolea...@freeshell.org> wrote:
> Robert Peirce wrote:
> > I suddenly started to get a Mac OS Error with this Result Code from
>
> <rant>
> In 1980, some eight-bit operating systems had informative
> (somewhat) diagnostic messages. There is no excuse for
> this kind of crap in 2009.
> </rant>
Sure there is. Two actually:
1. Providing informative diagnostic messages for all defined error
conditions takes up a lot of space and costs a lot to generate. Per
language.
2. The explicit definition of any given message from the OS might really
not have much meaning at all to a user without, as I noted in my
response to Robert, context provided by the application developer.
Really, what does "Bad File Format" mean? How does it help anyone
without knowing the operation that emitted it?
Robert Peirce
Robert Peirce <b...@peirce-family.com.invalid> wrote:
That did not work. Apparently, there is something in the first few
sectors that will cause it to fail. I just wrote the whole thing,
commercials and all, to DVD. I don't have enough time to fiddle with it
any more. However, when I have some time, I will try the encoding idea.
Robert Peirce
> > MartinC <nor...@hotmail.com> wrote:
> >
> > > If all else fails you can open the "Video" panel in Toast and click More >
> > > Encoding and then set the re-encoding option (temporarily) to "always".
> > >
> > > Then Toast will entirely re-encode the film even if it would initially
> > > believe that it can handle it without. As long as QT plays the original
> > > source film, this should work.
> >
would not play it either, but that is not the critical factor. In the
end I decided to record the unedited version.
I found I could edit out stuff at the end but the first several frames
are critical. I'm not sure where the cut-off is. I tried leaving the
first frame but that wasn't enough. However, if I left the front alone
I could record it. I'll have to live with that.
Wes Groleau
> Wes Groleau <grolea...@freeshell.org> wrote:
>> Robert Peirce wrote:
>>> I suddenly started to get a Mac OS Error with this Result Code from
>> <rant>
>> In 1980, some eight-bit operating systems had informative
>> (somewhat) diagnostic messages. There is no excuse for
>> this kind of crap in 2009.
>> </rant>
>
> Sure there is. Two actually:
>
> 1. Providing informative diagnostic messages for all defined error
> conditions takes up a lot of space and costs a lot to generate. Per
> language.
Let me expand my rant a little:
In 1980, an eight-bit O.S. called HDOS had English error messages
that were from sixty to 200 bytes long. They were stored in a
human-readable file on the five-inch floppy the O.S. ran on.
The code to convert the error number to the correct line of the file
did not prevent doing useful work in the 48K limit of the machine.
In 2009, there is no excuse for that crap on a machine with
80 Gig of disk space, hundreds of megabytes of RAM, and a processor
hundreds of times more powerful than that Z-80.
> 2. The explicit definition of any given message from the OS might really
> not have much meaning at all to a user without, as I noted in my
> response to Robert, context provided by the application developer.
> Really, what does "Bad File Format" mean? How does it help anyone
> without knowing the operation that emitted it?
HDOS messages (and VAX messages in the 1980s) were much more informative
than "Bad File Format" But "Bad File Format"--though it may not help
very much, is nevertheless more informative than "-208"
--
Wes Groleau
"To know what you prefer, instead of humbly saying
Amen to what the world tells you you should prefer,
is to have kept your soul alive."
-- Robert Louis Stevenson
Claude V. Lucas
All true, but the worst is that the interpretation of "-208" seems to be top secret.
Chris Ridd
> All true, but the worst is that the interpretation of "-208" seems to
> be top secret.
Not very secret. Run /usr/bin/macerror (on Leopard at least):
% macerror -208
Mac OS error -208 (badFileFormat): was not type AIFF or was of bad
format,corrupt
--
Chris
Claude V. Lucas
Gregory Weston
Wes Groleau <grolea...@freeshell.org> wrote:
> Gregory Weston wrote:
> > Wes Groleau <grolea...@freeshell.org> wrote:
> >> Robert Peirce wrote:
> >>> I suddenly started to get a Mac OS Error with this Result Code from
> >> <rant>
> >> In 1980, some eight-bit operating systems had informative
> >> (somewhat) diagnostic messages. There is no excuse for
> >> this kind of crap in 2009.
> >> </rant>
> >
> > Sure there is. Two actually:
> >
> > 1. Providing informative diagnostic messages for all defined error
> > conditions takes up a lot of space and costs a lot to generate. Per
> > language.
>
> Let me expand my rant a little:
> In 1980, an eight-bit O.S. called HDOS had English error messages
> that were from sixty to 200 bytes long. They were stored in a
> human-readable file on the five-inch floppy the O.S. ran on.
> The code to convert the error number to the correct line of the file
> did not prevent doing useful work in the 48K limit of the machine.
> In 2009, there is no excuse for that crap on a machine with
> 80 Gig of disk space, hundreds of megabytes of RAM, and a processor
> hundreds of times more powerful than that Z-80.
That's great. You haven't really addressed the real dollar cost, the
greatly increased number of error conditions and the improved
sensitivity toward the large chunk of the user base that doesn't speak
English. Or, as follows, the context.
> > 2. The explicit definition of any given message from the OS might really
> > not have much meaning at all to a user without, as I noted in my
> > response to Robert, context provided by the application developer.
> > Really, what does "Bad File Format" mean? How does it help anyone
> > without knowing the operation that emitted it?
>
> HDOS messages (and VAX messages in the 1980s) were much more informative
> than "Bad File Format" But "Bad File Format"--though it may not help
> very much, is nevertheless more informative than "-208"
Not really. Not without context. All you can do is report it to the
vendor and tell them what you were doing when it popped up. Same with
the number. And the number is intelligible to a larger portion of the
user base.
Robert Peirce
Ah! Another reason to switch to 10.5. 10.4 does not have this command,
at least not where terminal can find it.
Chris Ridd
<b...@peirce-family.com.invalid> said:
> In article <75d509F...@mid.individual.net>,
> Chris Ridd <chri...@mac.com> wrote:
>
>> On 2009-04-24 06:59:34 +0100, cla...@sonic.net (Claude V. Lucas) said:
>>
>>> All true, but the worst is that the interpretation of "-208" seems to
>>> be top secret.
>>
>> Not very secret. Run /usr/bin/macerror (on Leopard at least):
>>
>> % macerror -208
>> Mac OS error -208 (badFileFormat): was not type AIFF or was of bad
>> format,corrupt
>
> Ah! Another reason to switch to 10.5. 10.4 does not have this command,
> at least not where terminal can find it.
It is present on pre-Leopard systems - if memory serves it was in one
the perl framework/installation somewhere. The name might be
capitalized slightly differently too. Sorry I can't be more specific!
--
Chris
Wes Groleau
> Not very secret. Run /usr/bin/macerror (on Leopard at least):
>
> % macerror -208
> Mac OS error -208 (badFileFormat): was not type AIFF or was of bad
> format,corrupt
My point was that the O.S. should do this automatically instead of
displaying "-208" or "00ed8feb"
The writers of HDOS and other O.S.es figured that one out decades ago.
And obviously, if the error messages and the code to look them up
are already stored in the machine, using them is not going to be a
signifcant resource burden.
--
Wes Groleau
Pat's Polemics
http://Ideas.Lang-Learn.us/barrett
Chris Ridd
> Chris Ridd wrote:
>> Not very secret. Run /usr/bin/macerror (on Leopard at least):
>>
>> % macerror -208
>> Mac OS error -208 (badFileFormat): was not type AIFF or was of bad
>> format,corrupt
>
> My point was that the O.S. should do this automatically instead of
> displaying "-208" or "00ed8feb"
No the OS shouldn't, and in this case the OS isn't anyway.
The *application* could display that in a sensible way, as it also
knows the context in which the error happened. For example was it a
-208 when it was reading an AIFF file, or reading an MPEG file, or
something else? "Reading" covers a multitude of operations too, and it
might be more helpful to indicate which part of the file was considered
corrupt, rather than just the whole thing.
> The writers of HDOS and other O.S.es figured that one out decades ago.
Where's HDOS now though?
> And obviously, if the error messages and the code to look them up
> are already stored in the machine, using them is not going to be a
> signifcant resource burden.
The macerror program might have come with the developer tools.
--
Chris
Gregory Weston
Chris Ridd <chri...@mac.com> wrote:
> On 2009-04-26 05:45:40 +0100, Wes Groleau <grolea...@freeshell.org> said:
>
> > Chris Ridd wrote:
> >> Not very secret. Run /usr/bin/macerror (on Leopard at least):
> >>
> >> % macerror -208
> >> Mac OS error -208 (badFileFormat): was not type AIFF or was of bad
> >> format,corrupt
> >
> > My point was that the O.S. should do this automatically instead of
> > displaying "-208" or "00ed8feb"
>
> No the OS shouldn't, and in this case the OS isn't anyway.
>
> The *application* could display that in a sensible way, as it also
> knows the context in which the error happened. For example was it a
> -208 when it was reading an AIFF file, or reading an MPEG file, or
> something else? "Reading" covers a multitude of operations too, and it
> might be more helpful to indicate which part of the file was considered
> corrupt, rather than just the whole thing.
The additional joy is, of course, that the -208 might not have come from
the OS at all. Library and applications authors are quite able to return
error codes using the same identifiers as the OS, based on their own
validation rules. Just this past week I had to write a routine that
inferred the year for a date presented as MMDD based on the current date
and a knowledge of real-world practices. Of course I validated that the
month is in [1,12]. And of course I used the same response as any OS
routine would on finding an out-of-range value if the month isn't in
that interval.
Now as it happens, I also catch that exception and do something sane
further up the call chain. But the point is: The OS *couldn't* have
given a more sensible message because the OS didn't emit that code in
the first place.
G
Anic297
> The additional joy is, of course, that the -208 might not have come from
> the OS at all. Library and applications authors are quite able to return
> error codes using the same identifiers as the OS, based on their own
> validation rules. Just this past week I had to write a routine that
> inferred the year for a date presented as MMDD based on the current date
> and a knowledge of real-world practices. Of course I validated that the
> month is in [1,12]. And of course I used the same response as any OS
> routine would on finding an out-of-range value if the month isn't in
> that interval.
The Apple Interface Guidelines state that programmers should use the
same error number than the OS does, when applicable.
So, for instance, if your application receives an invalid month, you
should return error -50 (bad parameter).
It means a -208 error should always be returned because of a component
that could not read a file because of its bad format, else, the
programmer that made the component has done something wrong.
Wes Groleau
>> The writers of HDOS and other O.S.es figured that one out decades ago.
> Where's HDOS now though?
Same place as Mac OS system 1, MS-DOS, and AmigaDOS:
in my garage, over by the 250-pound electric piano.
--
Wes Groleau
Aw, it Ain?t Important ?
http://Ideas.Lang-Learn.us/WWW?itemid=58
Wes Groleau
> The Apple Interface Guidelines state that programmers should use the
> same error number than the OS does, when applicable.
> So, for instance, if your application receives an invalid month, you
> should return error -50 (bad parameter).
> It means a -208 error should always be returned because of a component
> that could not read a file because of its bad format, else, the
> programmer that made the component has done something wrong.
I don't really care who gets the blame for being user-hostile,
but somebody certainly does.
--
Wes Groleau
"Brigham Young agrees to confine himself to one woman,
if every member of Congress will do the same."
-- Weekly Republican, 1869
Chris Ridd
> Chris Ridd wrote:
>>> The writers of HDOS and other O.S.es figured that one out decades ago.
>> Where's HDOS now though?
>
> Same place as Mac OS system 1, MS-DOS, and AmigaDOS:
> in my garage, over by the 250-pound electric piano.
Right, so the apparent genius of having error strings instead of error
codes didn't exactly make waves in the marketplace :-)
--
Chris
Geoffrey S. Mendelson
> Right, so the apparent genius of having error strings instead of error
> codes didn't exactly make waves in the marketplace :-)
Hardware choice has a lot to do with it too. Apple has changed it's platform
3 times (6502-68000-ppc-intel), while HDOS was specific to one kind of hardware.
Apple had some false starts, for example the 16 bit CPU in the IIgs, and
the unreleased 80486 Mac prototypes from the "Star Trek" project.
They also had some false starts in software such as the joint Apple/IBM
operating system that never saw the light of day, and the Mach Kernel based
Linux system which did.
The key with Apple is that they were able to keep moving with the base
technology and maintain their customer base while they switched.
Tim Streater
Gregory Weston <u...@splook.com> wrote:
> In article <zB%Hl.2381$b11...@nwrddc02.gnilink.net>,
> Wes Groleau <grolea...@freeshell.org> wrote:
>
> > Robert Peirce wrote:
> > > I suddenly started to get a Mac OS Error with this Result Code from
> >
> > <rant>
> > In 1980, some eight-bit operating systems had informative
> > (somewhat) diagnostic messages. There is no excuse for
> > this kind of crap in 2009.
> > </rant>
>
> Sure there is. Two actually:
>
> 1. Providing informative diagnostic messages for all defined error
> conditions takes up a lot of space and costs a lot to generate. Per
> language.
>
> 2. The explicit definition of any given message from the OS might really
> not have much meaning at all to a user without, as I noted in my
> response to Robert, context provided by the application developer.
> Really, what does "Bad File Format" mean? How does it help anyone
> without knowing the operation that emitted it?
Er yes, you are broadly speaking correct. It's the app that's crap for
not *interpreting* what the code means in the *context* of what it was
trying to do, and emitting a suitable error message. The same error
code, from the same system call, can have entirely different meanings in
different parts of the app because the app is trying to do completely
different things.
--
Tim
"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
Gregory Weston
"Geoffrey S. Mendelson" <g...@mendelson.com> wrote:
> Chris Ridd wrote:
>
> > Right, so the apparent genius of having error strings instead of error
> > codes didn't exactly make waves in the marketplace :-)
>
> Hardware choice has a lot to do with it too. Apple has changed it's platform
> 3 times (6502-68000-ppc-intel),
Where's the love for the 65816?
> while HDOS was specific to one kind of hardware.
> Apple had some false starts, for example the 16 bit CPU in the IIgs, and
> the unreleased 80486 Mac prototypes from the "Star Trek" project.
The IIgs was on the market for more than 6 years. Not much less than the
Amiga's life as a first-tier product.
And don't forget the MC88000 prototypes from the late 1980s. And the
Lisa which aside from a (slower) 68000 didn't have a whole lot
technologically in common with the Mac.
> They also had some false starts in software such as the joint Apple/IBM
> operating system that never saw the light of day, and the Mach Kernel based
> Linux system which did.
The Taligent OS never made it into user hands, but it did get to the
point of being functional and shown at trade shows. There's a reason it
didn't get further. And then there's Copland, which got so far through
development that there were 3rd-party development books published before
it was finally killed.
> The key with Apple is that they were able to keep moving with the base
> technology and maintain their customer base while they switched.
>
> Geoff.
--
Gregory Weston
Wes Groleau <grolea...@freeshell.org> wrote:
> Anic297 wrote:
> > The Apple Interface Guidelines state that programmers should use the
> > same error number than the OS does, when applicable.
> > So, for instance, if your application receives an invalid month, you
> > should return error -50 (bad parameter).
> > It means a -208 error should always be returned because of a component
> > that could not read a file because of its bad format, else, the
> > programmer that made the component has done something wrong.
>
> I don't really care who gets the blame for being user-hostile,
> but somebody certainly does.
Sure. But misplacing the blame is worse than useless. It's up to the
application vendor to catch errors, handle as many of them gracefully as
they can and report the rest in a way that's at least meaningfully able
to be communicated back to them for research and fixing. Dragging the OS
into it is a distraction.
Best would be the error code *and* a human readable string with context.
But I'll still say that absent context the number is slightly more
useful than the text on the simple grounds that more users can read it
and reliably report it back to the vendor.
Wes Groleau
>> Right, so the apparent genius of having error strings instead of error
>> codes didn't exactly make waves in the marketplace :-)
People bought new software because overall is better*
That something is better overall in no way refutes my claim
that it is worse on this particular point
Geoffrey S. Mendelson wrote:
> Hardware choice has a lot to do with it too. Apple has changed it's platform
> 3 times (6502-68000-ppc-intel), while HDOS was specific to one kind of hardware.
Making an error message an English phrase instead of
a number is not a hardware issue.
--
Wes Groleau
Daily lessons & activities & their assessment
http://Ideas.Lang-Learn.us/barrett?itemid=1413
Geoffrey S. Mendelson
> Making an error message an English phrase instead of
> a number is not a hardware issue.
I agree it does not. I was commenting on why HDOS failed to "catch on". It
was for an obscure hardware platform that quickly became obsolete.
Wes Groleau
> Wes Groleau wrote:
>> Making an error message an English phrase instead of
>> a number is not a hardware issue.
>
> I agree it does not. I was commenting on why HDOS failed to "catch on". It
> was for an obscure hardware platform that quickly became obsolete.
Oh, I see. Fair enough. Though I disagree.
I think it failed to catch on because buyers
of that hardware (yes, there were some)
preferred CP/M. And I think they preferred
CP/M not because it was superior, but because
it was available for many platforms.
--
Wes Groleau
Teacher Tip: Organization
http://Ideas.Lang-Learn.us/russell?itemid=1568
Geoffrey S. Mendelson
> Oh, I see. Fair enough. Though I disagree.
> I think it failed to catch on because buyers
> of that hardware (yes, there were some)
> preferred CP/M. And I think they preferred
> CP/M not because it was superior, but because
> it was available for many platforms.
If that were the case, I think that CP/M 86 would have caught on, although on
a $5,000 IBM PC system, it added $150 more than PC/DOS to the price ($250 versus
$99).
Later in life, there were two CP/M options for the PC. One was an emulator
that ran under DOS on a PC/XT and ran CP/M programs, while reading DOS files.
The other was the NEC V20/V30 chips which could run DOS in 8088 mode, or
real CP/M in 8080 mode. By that time many CP/M programs used the extra
instructions of the Z80 processor, which would not work on it, or any of
the other 8080 compatible chips.
I still have my copy of Wordstar 3.3 for DOS which is 100% compatible
with the CP/M version (it was created by running the 8080 assembly
language source code through Intel's 8080->8086 converter) and it
runs on Windows XP.