File DL12
17 messages in this thread
Yes, and you can thank Ward Christianson and CP/M for the legacy of a
protocol that violates the first mandate of a protocol, that of leaving the
data alone, unchanged, wth nothing added and nothing taken away. Of course
it just goes to show you that IBM OS's are really nothing more than CP/M
with a different name.
I wouldn't go that far. Xmodem was designed for CP/M and worked
just fine for that since CP/M saved files in 128 byte chunks. In that
case, Xmodem did in fact leave the data alone. It's the fact that folks
decided that Xmodem was a neat thing and tried to adapt it to other
environments that has caused the 'problem' with up/downloads….not the
protocol itself. It was never designed, nor intended to be an all purpose
protocol…it just worked out that way.
I think we have gone through this before. 🙂
Basically, a file in CP/M, though saved in 128 bte chuncks, does not have
(necessarily), valid data right out to the end of the save area. I still
maintain that the first and foremost job of a protocol is to transfer only
the data, leaving it alone, neither changing, adding or deleting any part
of it. Whatever the reasons, it was poor protocol design.
This would not be significant if the entire world hadn't decided it was the
best way to do things, but then what can you expect from a bunch that
thought Kansas City Standard was "A Good Thing"?
Exactly…and since the bytes beyond the EOF were garbage…who cared
what they were….garbage is garbage as long as the data was untouched.
The KCS standard wasn't good or bad…it worked and gave us cheap
(relatively) disk drives.
All in what you consider to be data I guess. To me, garbage is data that
happens to be aded on.
regarding Kansas City Standard… the problem with it was manyfold, but the
biggest were speed and the method most of the implementations were done.
Since it was nothing more or less than redundant phase encoding, a far
better method was to simply make it phase encoding, saving a lot of cycles
better spent reading more data instead of trusting a semi-analog ciruit to
hopefully lock on to the current bit. I designed and built a circuit that
was cheaper and more reliable than KCS, and had the additional advantage of
running at 4200 baud. I didn't have much good to say about KCS then, and
still don't. It showed the influence of a lot of outspoken people who
pushed things through while ignoring the pleas of the more knowledgeable
who were trying to get something that would do the best job accepted.
Garbage is garbage is garbage….it's that simple. CP/M added it to
the real data when it wrote the file, because it was 'what happend to be
after the EOF marker in the write buffer'. It could have been anything, all
Ward Christensen did was make it all EOF's.
To me data is something that is useful, and in that respect, Xmodem
as used in the CP/M world was a proper protocol. In other words, it was 100%
transparent to the user and to the real data.
As to KCS, I agree it wasn't the best thing to come down the pike,
all I said was that it was a 'standard' (good or bad) and as a result, gave
manufacturers a common reference point. Commonality meant lower price.
is there a word for a 'semi-protocol? <grin>
At the time KCS was developed, there were no 'lower prices'… you had to
build your own.
Exactly my point….with no 'standard' everyone went their own way
with no possibility of interchange. With a 'standard' interchange is
possible or at the very least…the use of common parts across different
hardware systems.
Exactly the same reason we have standards for anything…if you have
a broken part X in manufacturer's Y's machine, you can buy a part from
manufacturer Z and it will work (or fit as the case may be). The
developement of a standards was one of the major driving forces behind the
industrial revolution. Prior to that, almost everything was 'hand made' and
broken parts had to be custom made. Even nuts and bolts didn't have standard
threads. A nut from Joe's Foundry wouldn't necessairly fit a bolt from
Bill's Iron Works even thou they 'fit' the same hole.
Think of what it would cost if the Amiga used 3 3/8" drives while
Apple used 3 5/8" drives and IBM used 3 1/3" drives. Guess who'd get disk
production priority? Guess who'd be paying $2.00/disk and who'd be paying
$25.00/disk.
Don,
While all that is true, there is the other side of the coin. Standards have
also been known to hold back progress, to promote inferiority in general, and
to stifle creativity.
What bothers me the most is that at the time KCS was being promoted as the
be-all and end-all of data storage, more sane voices were completely ignored.
The reason for that totally escapes me, but there must have been one.
-larry
The reason: marketing.
Guys, you're arguing over things that are basically water under the bridge.
They're gone! Just keep in mind, Larry that with the old CPM machine with 4K,
it was a bit difficult to implement TCP/IP or DECNET 😉
– Steve –
And in a lot of CP/M programs, the garbage *really* started at the stuff
that loads into 0x0100… 🙂 Hmm. That applies to MS-DOS, too.
Larry,
It wasn't considered a Good Thing; It WAS the ONLY thing. (argh! Schmidt
Triggers! Argh!) Sorry, Flashback. I feel much better now.
Doug,
Thing is, they used phase-locked loops to try to lock on to one of two
frequencies, sometimes successfully, sometimes not. All that was really
needed was a reasonable frequency and a tiiming pulse… if it changed during
the puls, it was a 1, if not, it was a zero. Simple, cheap, efficient, and
about 6 or 7 times faster, minimum.
-larry
Larry,
Simple,yes. But an effective 300 baud when using tape storage does not a
speed demon make. (actualy, it was some odd value like 345 baud, but I have
forced myself to forget, and now rest easier for it 8)
Who says they where the "good ol' days?"
Doug
Have you got a Kansas City interface for the Amiga? I think I have a tape of
TREK80 around here someplace, maybe it'll boot in the CP/M emulator, if we
can hack a Processor Tech screen emulator for it…
A: Har!