... now that Europe has the Euro currency, except for the Brits, the Swedes
and Denmark, I propose an update of the C64 character set to make it more
current.
Here's my proposed Euro symbol to be included in the character ROM:
..****.. $3c
.**...*. $62
*****... $f8
.**..... $60
*****... $f8
.**...*. $62
..****.. $3c
........ $00
As for selecting the character of the C64 that is to be replaced and easily
accessible using the keyboard, I suggest the British pound sign for a number
of reasons:
1. It's placed handy and easily accessible.
2. It's pretty superfluous in a couple years when the Brits finally adopt
the Euro.
3. Who needs the Brits anyway in Europe? ;-)))
Seriously, replacing the British pound symbol would IMHO be the best choice of
all possible choices. Whaddaya think?
--
cul8er,
Paul
oo
pa...@gmx.net ~( "> paul_f...@s.maus.de
PF> Seriously, replacing the British pound symbol would IMHO be the
PF> best choice of all possible choices. Whaddaya think?
My C64s and 128s has the character Ö instead of £. And why anyone
would want the Euro character is beyond me...
--
___ . . . . . + . . o
_|___|_ + . + . + . . Per Olofsson, konstnär
o-o . . . o + Mage...@cling.gu.se
- + + . http://www.cling.gu.se/~cl3polof/
> My C64s and 128s has the character Ö instead of £. And why anyone
> would want the Euro character is beyond me...
... why not? It keeps it current. :-)
>As for selecting the character of the C64 that is to be replaced and easily
>accessible using the keyboard, I suggest the British pound sign for a
number
>of reasons:
>
>1. It's placed handy and easily accessible.
>2. It's pretty superfluous in a couple years when the Brits finally adopt
> the Euro.
>3. Who needs the Brits anyway in Europe? ;-)))
>
>Seriously, replacing the British pound symbol would IMHO be the best choice
of
>all possible choices. Whaddaya think?
Most of the software that I use on my C-128 is communications software.
Several characters are redefined to become ASCII characters that Commodore
left out of the PETscii character set. For example, the British pound
symbol is redefined to become a backslash, and the uparrow becomes a caret.
Perhaps a software solution could be used for productivity software such as
spreadsheets and word processors also. If I remember correctly, some
American software redefined the British pound key to the American cent
symbol.
I vote for the software solution rather than changing the ROM's :-)
Best regards,
Sam Gillett aka Mars Probe @ Starship Intrepid 1-972-221-4088
Last 8-bit BBS in the Dallas area. Commodore lives!
Paul> As for selecting the character of the C64 that is to be replaced
Paul> and easily accessible using the keyboard, I suggest the British
Paul> pound sign for a number of reasons:
Why not the Commodore key, as it already resembles that symbol? You'd
just need to patch the keyboard driver a little. :-)
Marko (who voted against joining in the EU)
For this reason I don't think the pound sign is a good solution.
Does anyone know if and where in the standard 8bit (or even 7 bit)
ascii character set does the euro symbol go? (it would seem it would
have to replace some existing symbol..)
>Perhaps a software solution could be used for productivity software such as
>spreadsheets and word processors also. If I remember correctly, some
>American software redefined the British pound key to the American cent
>symbol.
>
>I vote for the software solution rather than changing the ROM's :-)
Haha.. me too. Now if there is a reason to add the symbol to the char
set in NT10 I will..
Errol Smith || Strobe
errol <at> ros (dot) com [period] au
http://www.ros.com.au/~errol/64.html
Errol> Does anyone know if and where in the standard 8bit
Errol> (or even 7 bit) ascii character set does the euro symbol go?
I don't know of a 7-bit mapping (which would be a revision of ISO
646), but in ISO 8859-15 (a.k.a. Latin-9), the euro symbol replaces
the "currency symbol" (¤) of ISO 8859-1 (a.k.a. Latin-1, the default
encoding of HTML pages), which was mapped at position $a4 ($24+$80,
where $24 is the $ symbol).
The "currency symbol" looks like a killed squirrel whose tail has been
removed (a round body with 4 legs pointing to NW, SW, NE, SE). Or at
least that's my interpretation, since squirrel skins used to be the
currency of Finland some hundreds of years ago. :-)
The Windows non-standard character set (I think CP-1232 or something)
defines the Euro symbol at the position $80, in the area $80-$9f that
is reserved for control characters.
Marko
>>>>>> "Paul" == Paul Foerster <pa...@gmx.net> writes:
>
>Paul> As for selecting the character of the C64 that is to be replaced
>Paul> and easily accessible using the keyboard, I suggest the British
>Paul> pound sign for a number of reasons:
>
>Why not the Commodore key, as it already resembles that symbol? You'd
>just need to patch the keyboard driver a little. :-)
In a lot of Commodore software the C= key is used like the ALT key on the PC
to access hotkey commands. It is also used to access about half of the PET
graphic symbols, and half of the C64 colors.
I don't think Commodore anticipated a consolidated European currency system.
The Euro kinda slipped up on 'em! :-)
> For this reason I don't think the pound sign is a good solution.
>Does anyone know if and where in the standard 8bit (or even 7 bit)
>ascii character set does the euro symbol go? (it would seem it would
>have to replace some existing symbol..)
I really don't know exactly what the Euro symbol is supposed to look like,
but maybe the character at ASCII 238 could be substituted for it. I sort of
hesitate to suggest that the English pound symbol at ASCII 156 be redefined.
At least not this year... :-)
As for the 7-bit characters, ASCII 0 through 127, I doubt approval could be
obtained to redefine any of them. As far as I know they are all needed for
radio-telegraph communications, as well as wire based teletype. In this age
of digital satellite communications teletype and radio-telegraph are
obsolete, but I don't think they have been declared officially dead yet.
> For this reason I don't think the pound sign is a good solution.
> Does anyone know if and where in the standard 8bit (or even 7 bit)
> ascii character set does the euro symbol go? (it would seem it would
> have to replace some existing symbol..)
There's no such thing as a "8-bit ASCII character set", and ASCII does
not have the Euro symbol (as it was invented decades ago). There are
two eight-bit ISO standardized characer encodings that do include the
Euro symbol, ISO 8859-15 and ISO 8859-16. They both encode it at
position 164 (¤).
But anyway, just writing "e" is in most cases good enough. Inventing a
new symbol for a currency is IMHO quite a bad idea...
--
\\//
peter - still using "kr", both NOK and SEK.
Statement concerning unsolicited e-mail according to Swedish law:
http://www.softwolves.pp.se/peter/reklampost.html
>There's no such thing as a "8-bit ASCII character set", and ASCII does
>not have the Euro symbol (as it was invented decades ago). There are
>two eight-bit ISO standardized characer encodings that do include the
>Euro symbol, ISO 8859-15 and ISO 8859-16. They both encode it at
>position 164 (¤).
All ASCII characters above ASCII 127 (i.e., ASCII 128 to ASCII 254) are part
of the 8-bit ASCII character set.
there *is* no 8-bit ASCII character set..
--
Martijn van Buul - Pi...@dohd.org - http://www.stack.nl/~martijnb/
Geek code: G-- - Visit OuterSpace: mud.stack.nl 3333
Kees J. Bot: The sum of CPU power and user brain power is a constant.
> But anyway, just writing "e" is in most cases good enough. Inventing a
> new symbol for a currency is IMHO quite a bad idea...
I think the official "EUR" is better then just "e".
Ciao,
Marc 'BlackJack' Rintsch
>It occurred to me that Sam Gillett wrote in comp.sys.cbm:
>
>> All ASCII characters above ASCII 127 (i.e., ASCII 128 to ASCII 254) are
part
>> of the 8-bit ASCII character set.
>
>there *is* no 8-bit ASCII character set..
>
"ASCII provides for 256 codes divided into two sets-standard and extended-of
128 each. These sets represent the total possible combinations of either 7
or 8 bits, the latter being the number of bits in 1 byte. The basic, or
standard, ASCII set uses 7 bits for each code, yielding 128 character codes
from 0 through 127 (hexadecimal 00H through 7FH). The extended ASCII set
uses 8 bits for each code, yielding an additional 128 codes numbered 128
through 255 (hexadecimal 80H through FFH)" [1]
Looking at other sources I find that some groups accept the extended set as
part of the ASCII set, and some do not. Therefore, the question, "Is there
an 8-bit ASCII set?" is like the question, "What is the best
microprocessor?" There will be many differing opinions, but no definitive
answer.
[1]"ASCII," Microsoft Encarta 96 Encyclopedia
Best regards,
Sam Gillett aka Mars Probe @ Starship Intrepid 1-972-221-4088
Last 8-bit BBS in the Dallas area. Commodore lives!
P.S. I did make a typo in the message quoted. 254 should have been 255.
:-)
Sam Gillett schrieb:
>
> Martijn van Buul wrote ...
>
> >It occurred to me that Sam Gillett wrote in comp.sys.cbm:
> >
> >> All ASCII characters above ASCII 127 (i.e., ASCII 128 to ASCII 254) are
> part
> >> of the 8-bit ASCII character set.
> >
> >there *is* no 8-bit ASCII character set..
> >
> "ASCII provides for 256 codes divided into two sets-standard and extended-of
> 128 each. These sets represent the total possible combinations of either 7
> or 8 bits, the latter being the number of bits in 1 byte. The basic, or
> standard, ASCII set uses 7 bits for each code, yielding 128 character codes
Ok, standard 7-bit-ASCII.
> from 0 through 127 (hexadecimal 00H through 7FH). The extended ASCII set
> uses 8 bits for each code, yielding an additional 128 codes numbered 128
> through 255 (hexadecimal 80H through FFH)" [1]
The Question is, what shall be displayed/controlled when the upper 128
Characters
are printed ?
> Looking at other sources I find that some groups accept the extended set as
> part of the ASCII set, and some do not. Therefore, the question, "Is there
> an 8-bit ASCII set?" is like the question, "What is the best
> microprocessor?" There will be many differing opinions, but no definitive
> answer.
>
> [1]"ASCII," Microsoft Encarta 96 Encyclopedia
Never believe what Billyboy proposes, especially concerning Standards.
But, who cares anyhow, let's better discuss PETSCII,
the ultimate World-Standard in printing :-)!
Andre Kaesmacher
PS: ASCII stupid Question
get a stupid ANSI!
>PS: ASCII stupid Question
>get a stupid ANSI!
Revolting. :-P
--
Cameron Kaiser * cka...@stockholm.ptloma.edu * posting with a Commodore 128
personal page: http://www.armory.com/%7Espectre/
** Computer Workshops: games, productivity software and more for C64/128! **
** http://www.armory.com/%7Espectre/cwi/ **
>Sam Gillett schrieb:
>
>> "ASCII provides for 256 codes divided into two sets-standard and
extended-of
>> 128 each. These sets represent the total possible combinations of either
7
>> or 8 bits, the latter being the number of bits in 1 byte. The basic, or
>> standard, ASCII set uses 7 bits for each code, yielding 128 character
codes
>
>Ok, standard 7-bit-ASCII.
>
>> from 0 through 127 (hexadecimal 00H through 7FH). The extended ASCII set
>> uses 8 bits for each code, yielding an additional 128 codes numbered 128
>> through 255 (hexadecimal 80H through FFH)" [1]
>
>The Question is, what shall be displayed/controlled when the upper 128
>Characters
>are printed ?
I understand that this varies widely from country to country. And it is
perfectly understandable that a Japanese printer would have a different
character set that of a Swedish printer.
>> Looking at other sources I find that some groups accept the extended set
as
>> part of the ASCII set, and some do not. Therefore, the question, "Is
there
>> an 8-bit ASCII set?" is like the question, "What is the best
>> microprocessor?" There will be many differing opinions, but no
definitive
>> answer.
>>
>> [1]"ASCII," Microsoft Encarta 96 Encyclopedia
>
>Never believe what Billyboy proposes, especially concerning Standards.
I don't think Billy Bob had much to do with the extended ASCII set. In fact
he used a different set of extended characters in Windows than that used by
the rest of the world. Outside of Windows, the upper 128 characters on, for
example, an IBM computer will be the same as on a Compaq computer. If
straight text is sent to a printer, the extended character set on an Epson
printer will be the same as on a Hewlett Packard printer.
Of course an Apple printer will have a different extended character set, but
that one is not the one favored by Billy Bob either. BTW my old Epson
printer had a dip switch to change from the IBM extended set to the Mac set.
>But, who cares anyhow, let's better discuss PETSCII,
>the ultimate World-Standard in printing :-)!
Yes, it is too bad the PET set wasn't adopted as the standard (if we can say
standard) extended character set. Although lacking in international
characters the PETscii set does have a nice set of graphic characters. I
have seen some pretty nice pictures drawn with the Commodore "lo-rez"
graphics in the PET set.
Back in "the day" many Commodore BBS's would have a monthly graphics
contest. Users could submit their PETscii art as uploaded text files. The
other users, who did not enter the contest, could download the artwork and
vote for first, second, and third place winners.
Eh. You still didn't leave the PC-arena here. And you haven't even leaved
the influence of DOS.
There are lots of different mappings for the upper 128 characters. There
are multiple standards for that. None of the can claim to be "the true one".
> Of course an Apple printer will have a different extended character set, but
> that one is not the one favored by Billy Bob either. BTW my old Epson
> printer had a dip switch to change from the IBM extended set to the Mac set.
Even my good old Star printer had several nationalized character sets, so
that point is moot. There *is* no standard.
> Yes, it is too bad the PET set wasn't adopted as the standard (if we can say
> standard) extended character set. Although lacking in international
> characters the PETscii set does have a nice set of graphic characters.
So does the IBM character set.
> "ASCII provides for 256 codes divided into two sets-standard and
> extended-of 128 each.
Well, that's wrong. ASCII is a 128-character character set encoded
using a seven-bit encoding. There is not, and has never been, any "high
ASCII" or "8-bit ASCII".
--
\\//
peter - iDOC= - http://www.softwolves.pp.se/idoc/
> I think the official "EUR" is better then just "e".
The comic books I subscribe to have the price given in "Finnish euro
(FIN EUR)" on the cover since issue 2002:1, in addition to the price in
Finnish marks (and Swedish kronor)...
--
\\//
peter - iDOC= - http://www.softwolves.pp.se/idoc/
Statement concerning unsolicited e-mail according to Swedish law:
http://www.softwolves.pp.se/peter/reklampost.html
Note that the quoted definition comes from Micro$oft Encarta 96
Encyclopedia...
--
White Flame (aka David Holz)
http://fly.to/theflame
(spamblock in effect)
>Sam Gillett:
>
>> "ASCII provides for 256 codes divided into two sets-standard and
>> extended-of 128 each.
>
>Well, that's wrong. ASCII is a 128-character character set encoded
>using a seven-bit encoding. There is not, and has never been, any "high
>ASCII" or "8-bit ASCII".
Many people who use the extended ASCII character set every day will tend to
see it as something that does exist. Those who never use it can easily
choose to ignore its existance.
The question, "Is there an 8-bit ASCII set?" is like the question, "What is
the best microprocessor?" There will be many differing opinions, but no
definitive answer.
[much snippage]
>There are lots of different mappings for the upper 128 characters. There
>are multiple standards for that. None of the can claim to be "the true
one".
>
>Even my good old Star printer had several nationalized character sets, so
>that point is moot. There *is* no standard.
>
I will agree that there is no international standard. And there does not
seem to be an official, or sanctioned standard in the US. There is,
however, an unofficial standard that originated from common usage of the
same extended character set by all major hardware manufacturers (with Apple
being the only notable exception. Of course Commodore _was_ a notable
exception, prior to the bankruptcy :-)).
Consequently it seems that there is no _official_ extended ASCII character
set. However, a de facto standard does exist. One that varies in many
regions based on the language in common use. In spite of that, many of us
use the extended set frequently.
SG> There is, however, an unofficial standard that originated from
SG> common usage of the same extended character set by all major
SG> hardware manufacturers (with Apple being the only notable
SG> exception. Of course Commodore _was_ a notable exception, prior to
SG> the bankruptcy :-)).
Which hardware vendors would that be? MS-DOS machines had their own,
unix machines traditionally have 7-bit ascii but has migrated to the
ISO-8859 standard, Windows uses its own (although it's compatible with
ISO-8859 (embrace and extend)), Macs have their own, Amiga uses 8859,
and I'm not sure about Ataris. Oh, and they all have their own ideas
on how lines should end, Amiga and UNIX being the only two that are
compatible.
It's amazing how hard it is to store something as basic as text.
> The question, "Is there an 8-bit ASCII set?" is like the
> question, "What is the best microprocessor?" There will
> be many differing opinions, but no definitive answer.
There are 8-bit character sets that are supersets of the
7-bit ASCII character set. But there is no point in calling
them "8-bit ASCII character sets", as a name without a
definition does not mean anything.
-- znark
>>>>>> "SG" == Sam Gillett <samgi...@msn.com> writes:
>
>SG> There is, however, an unofficial standard that originated from
>SG> common usage of the same extended character set by all major
>SG> hardware manufacturers (with Apple being the only notable
>SG> exception. Of course Commodore _was_ a notable exception, prior to
>SG> the bankruptcy :-)).
>
>Which hardware vendors would that be? MS-DOS machines had their own,
Except for IBM, not the computer makers, but the graphic adaptor vendors
(CGA, then VGA and SVGA, etc.) and printer makers (note that Epson called
the extended character set "Epson Extended Graphics" rather than Extended
ASCII). Both the basic and extended character set are in ROM on the various
video adapter cards. This function is increasingly being moved to the MB on
some newer motherboards.
To make a long story short, for the sake of compatibility, other vendors
used the same character set that IBM used in the CGA card that was optional
on the IBM XT. Any incompatibilities could have spelled doom for their
products.
People had a strange idea... they expected what came out of their printers
to look like what they had on their monitors. So printer makers put the
same character set in their ROM's.
>unix machines traditionally have 7-bit ascii but has migrated to the
>ISO-8859 standard, Windows uses its own (although it's compatible with
>ISO-8859 (embrace and extend)), Macs have their own, Amiga uses 8859,
>and I'm not sure about Ataris. Oh, and they all have their own ideas
>on how lines should end, Amiga and UNIX being the only two that are
>compatible.
I think the misunderstanding here has been due to differences in
terminology. What some call extended ASCII, others call ISO-8859. Just as
Europeans may have another name for what we call ANSI graphics. (ANSI
graphics are the extended ASCII set with escape codes added to change text
color, background color, enable/disable flash, move the cursor, etc. Of
course C= users are used to such things, as most of these functions are
built into PETascii also.)
I know that you are already aware of that... just threw it in for the
benefit of others who may read this.
>It's amazing how hard it is to store something as basic as text.
Really we have it pretty easy. We can do it with an 8-bit character set,
and sometimes with a 7-bit set. The Japanese have almost completed (they
may have it complete by now) a 16-bit character set. The Chinese are not
very happy about 16-bit sets. They are pushing for a 32-bit character set.
And mainland China wants a totally different set from the Chinese on Tiawan.
To keep _everyone_ happy we might need a 64-bit set. Where will it all end?
script:
>I will agree that there is no international
> standard. And there does not seem to
>be an official, or sanctioned standard in
> the US.
Before you get in to deep, I might remind you that ASCII stands for
"_American_ _Standard_ Code for Information Interchange." If it ain't
'Murican, 'tain't ASCII. If it ain't standard, 'tain't ASCII. I think
that we are waiting for an ISCII. :))
salaam,
dowcom
--
http://community.webtv.net/dowcom/DOWCOMSAMSTRADGUIDE
DOShead Credo:
a) Try it! It might work.
b) GOTO a).
Reminds me of that price tag I saw recently, coming from a fashion shop in
Maastricht (which is quite close to both Germany as well as Belgium, and
traditionally used three currencies). It had three different prices for
Belgian Euros, German Euros and Dutch Euros. Somehow, I found that worrysome.
> Reminds me of that price tag I saw recently, coming from a fashion shop in
> Maastricht (which is quite close to both Germany as well as Belgium, and
> traditionally used three currencies). It had three different prices for
> Belgian Euros, German Euros and Dutch Euros. Somehow, I found that worrysome.
Nerds visiting fashion shops worries me even more!
A few years ago I bought a tie with computer mice (with eyes) on it in
Maastricht.
--
Etienne von Wettingfeld [Powered by FreeBSD]
Voice mail & Fax: +31 (84) 8835157 -//- www.doomdark.demon.nl
{ -*- Nam Et Ipsa Scientia Potestas Est -*- } MMII
You think we're going to fill up a 32-bit character set with over 4
*billion* characters any time soon? :-o
> Why not the Commodore key, as it already resembles that symbol? You'd
> just need to patch the keyboard driver a little. :-)
... it's not the key that is important. It's the character number in the
character set that is important because it means that exactly one character of
the traditional character set has to be sacrificed to let the € symbol slip
in.
--
cul8er,
Paul
oo
pa...@gmx.net ~( "> paul_f...@s.maus.de
>You think we're going to fill up a 32-bit character set with over 4
>*billion* characters any time soon? :-o
Personally, I am happy with an 8-bit set. :-)
It's the Chinese that are insisting on a 32-bit set.
Not too many years ago very few programs required over 256k of RAM, and very
few home computers had over 512 kb. Now there are programs that require 64
megs of RAM and computers with 512 megs are common. Who would have even
imagined that 20 years ago?
In 1982 who would have believed that a Commodore 64 could have 16 megs of
RAM (thanks to CMD)? When was it that Commodore announced a 512k REU? 1985
or 1986? I remember everyone thought that was pretty amazing at the time.
Given a couple of decades the Chinese might be able to fill a 32-bit
character set! Who knows? :-)
A certain Mr. Moore.
Quoting the Jargon directory:
Moore's Law /morz law/ prov. The observation that the logic density of
silicon integrated circuits has closely followed the curve (bits per square
inch) = 2^(t - 1962) where t is time in years; that is, the amount of
information storable on a given amount of silicon has roughly doubled every
year since the technology was invented. This relation, first uttered in 1964 by
semiconductor engineer Gordon Moore (who co-founded Intel four years later)
held until the late 1970s, at which point the doubling period slowed to 18
months. The doubling period remained at that value through time of writing
(late 1999). Moore's Law is apparently self-fulfilling. The implication is that
somebody, somewhere is going to be able to build a better chip than you if you
rest on your laurels, so you'd better start pushing hard on the problem.
> Note that the quoted definition comes from Micro$oft Encarta 96
> Encyclopedia...
Never trust what Microsoft tells you.
> Many people who use the extended ASCII character set every day will
> tend to see it as something that does exist.
Since there is no such thing, the amount of people using the extended
ASCII character set every day is zero, so there's no problem
involved...
>Sam Gillett:
>
>> Many people who use the extended ASCII character set every day will
>> tend to see it as something that does exist.
>
>Since there is no such thing, the amount of people using the extended
>ASCII character set every day is zero, so there's no problem
>involved...
Supermarket automatic doors open for me, therefore I do exist.
I use the extended ASCII characters, therefore they do exist.
A quote from the help file in an old DOS word processor:
"Professional Write can display these ASCII
characters on the screen: 20, 21, and 32-255."
--Professional Write version 2.11
Some of the extended line drawing characters are quite useful for creating
charts that look quite nice when printed.
Also, on my Commodore BBS I use some of the PETascii characters to draw a
line around, and divide some of the menus into sections. When I am using my
C-128 for other purposes I place a PC based BBS on line. On the PC version,
the extended ASCII characters are used to outline, and divide into logical
sections, several of the menus.
If they did not exist, I could not use them. Since they do exist, I do use
them.
This seems to be a problem of terminology. What is commonly known as
extended ASCII here is obviously known by another name in your part of the
world.
> I use the extended ASCII characters, therefore they do exist.
Well, you can continue to believe that if you want to, and we others
will just keep to the facts.
> "Professional Write can display these ASCII
> characters on the screen: 20, 21, and 32-255."
And thus you draw the conclusion that ASCII has characters >127? Read
the standard describing ASCII and you'll see that it is only 7-bit, and
there is no such thing as "extended ASCII" described in it. A lot of
character sets and encodings are of course "extensions *of* ASCII", but
none are "extended ASCII".
> If they did not exist, I could not use them. Since they do exist, I
> do use them.
I've never said that your characters don't exist, just that they aren't
"extended ASCII", since "extended ASCII" is not defined. Your PC uses
"IBM codepage 437" (most likely), whereas your Windows machine uses
"Microsoft codepage 1252".
>I've never said that your characters don't exist, just that they aren't
>"extended ASCII", since "extended ASCII" is not defined. Your PC uses
>"IBM codepage 437" (most likely), whereas your Windows machine uses
>"Microsoft codepage 1252".
About 15 years ago, this same discussion occured on several local bulletin
board systems. The Unix camp insisted that ASCII was a 7-bit thing. IBM
(and clone) users insisted that it is 8-bit. Probably because on their
machines it was. For the most part, Commodore users just read the
discussion and snickered. After all we had our own 8-bit character set,
PETascii, which we felt was far superior to both the Unix and the IBM set.
Neither side ever won that argument. It just faded away, to be replaced by
other topics. Which is what should happen to this discussion also. But
first, a little background on ASCII.
7-bit ASCII was not developed for use on computers. Long ago, long distance
communication was by telegraph, using Morse code (a 1-bit protocol). Morse
code worked well, but soon the need for a faster and more error free method
of communication became apparent.
At the moment, I forget the name of the company that developed the teletype
terminal. So, I shall call them simply Teletype Company. To continue, The
Teletype Company, Western Union, and AT&T worked with one another to develop
the first teletype terminals. TELETYPE, by the way, is a contraction of
TELEgraph TYPEwriter and was developed _long_ before the first transistor,
and of course, the microchip.
The first teletype terminals used a 5-bit character set, with upper case
letters only. Another problem with the 5-bit character set was that it
required an escape sequence before sending control characters. AT&T,
Western Union, and The Teletype Company again worked together and developed
a 7-bit terminal and a character set for use with the new terminal. It is
worth noting that they left 32 characters free on the bottom of the set for
use as control codes that did not require an escape sequence.
At first no governing body was involved with the development of the
character set. None was needed. If both Western Union and AT&T said, "This
is the character set." Then that _was_ the character set. These two
companies constituted a monolopy of the telecommunications industry in the
middle of the last century.
Some of the first useful computers used punched cards as a means of
input/output, and data storage. These were difficult for humans to read.
Then some bright engineers conceived a scheme by which they would make
strange bedfellows of a 7-bit terminal and an 8-bit computer. The teletype
terminal became a common computer terminal.
Later, the CRT terminal was developed. When the CRT terminal came into
common use a 7-bit character code became as obsolete as the teletype
terminal that required it.
As far as I know, Kermit and UUencoding are some of the last vestiges of a
7-bit world. Zip is far superior to UUencoding, and there are dozens of
packet protocols that make Kermit obsolete. And thus, 7-bit character sets
are also obsolete.
So that someone will not misread this, I did not say Kermit is no longer
used, only that it is obsolete. I still use a Commodore, knowing full well
that it is obsolete. I only use it because I enjoy it. May all those who
use a 7-bit character set enjoy that as well.
Have fun!
um, zip and uuencode are 2 separate things. Zip is a compressor/archiver,
while uuencode is a format converter.
--
White Flame (aka David Holz)
>"Sam Gillett" <samgi...@msn.com> wrote in message
>news:rJ_98.1340$cq2.6...@paloalto-snr1.gtei.net...
>> Zip is far superior to UUencoding, and there are dozens of
>> packet protocols that make Kermit obsolete.
>
>um, zip and uuencode are 2 separate things. Zip is a compressor/archiver,
>while uuencode is a format converter.
UUencode converts binary files to text so that they can be sent as internet
email attachments. The resulting file is usually larger than the original
file. Not a very efficient way of doing things. I wonder how long it will
be before the current format for email, and usenet too, gives way to
something more efficient.
Some corporations already FTP their internal mail as zipped bundles between
various sites. Keeps more bandwidth open for customers and other purposes.
To me it is surprising that the current internet system for email has not
been replaced yet.
I hate it when I get a 2 MB email that could have been compressed to less
than a meg. No one asked me... but I do think it is time for change. Other
information is transfered across the net without conversion to/from text.
Why not .zip attachments to email?
Think I should duck before the flames begin? :-)
Best regards,
> UUencode converts binary files to text so that they can be sent as
> internet email attachments.
Due to some e-mail and news software only accepts 7-bit data. UUencode
(and Base64 too) also encodes the lower 32 control characters.
> Some corporations already FTP their internal mail as zipped bundles
FTP however, can AFAIK transmit data as either ASCII (7-bit) or binary
(8-bit) streams. Although a mail server probably could be written as
a FTP server, all mail readers must then take a peek at the "mail folder"
to see what type of file it is -- text, ZIP, WAV, JPG etc.
> Keeps more bandwidth open for customers and other purposes.
Speaking of which, I've heard that Microsoft reserves 10-15% of the
available bandwidth in Windows XP for its own use, no matter if the
bandwidth is 56 kbps or 2.4 Gbps.
> I hate it when I get a 2 MB email that could have been compressed
Me too. I prefer to get a URL to somewhere I can pick up the large
file, either through HTTP or FTP. This is also a good solution to when
somebody wants to send a *very* large file to *many* users, but only a
few might really be interested in it.
--
Anders Carlsson
> As far as I know, Kermit and UUencoding are some of the last vestiges of
> a 7-bit world.
What about mail and news? It's plain 7 bit protocols. You may send 8 bit
characters in mail but it's absolutly possible that a mail server on the
way to the recipient will throw away the highest bit.
Ciao,
Marc 'BlackJack' Rintsch
>>um, zip and uuencode are 2 separate things. Zip is a
>>compressor/archiver, while uuencode is a format converter.
>
> UUencode converts binary files to text so that they can be sent as
> internet email attachments. The resulting file is usually larger than
> the original file.
It's always larger.
> Some corporations already FTP their internal mail as zipped bundles
> between various sites. Keeps more bandwidth open for customers and
> other purposes. To me it is surprising that the current internet system
> for email has not been replaced yet.
You have to invent a new format that has to run parallel to the old one.
So you have to convince all mail server admins on the world to run your
new protocol to have the same availibility of email like it is today. And
the mail programs have to be able to talk the new protocol too.
Ciao,
Marc 'BlackJack' Rintsch
"Sam Gillet" <samgi...@msn.com> wrote in message
> > I hate it when I get a 2 MB email that could have been compressed
Even if somebody e-mails you a .zip file, it still goes through the MIME
base64 encoding, which expands it almost as much as uuencode.
--
White Flame (aka David Holz)
>Speaking of which, I've heard that Microsoft reserves 10-15% of the
>available bandwidth in Windows XP for its own use, no matter if the
>bandwidth is 56 kbps or 2.4 Gbps.
Wouldn't know anything about that. Windows changes so often that I stopped
trying to keep up with the latest changes. I do save a little Windows humor
for reuse...
Yesterday it worked.
Today it is not working.
Windows is like that.
>Me too. I prefer to get a URL to somewhere I can pick up the large
>file, either through HTTP or FTP. This is also a good solution to when
>somebody wants to send a *very* large file to *many* users, but only a
>few might really be interested in it.
I agree. Although I sometimes attach a 10 or 20 kb file, I consider it
impolite to attach a larger file, unless it has been requested.
>You have to invent a new format that has to run parallel to the old one.
>So you have to convince all mail server admins on the world to run your
>new protocol to have the same availibility of email like it is today. And
>the mail programs have to be able to talk the new protocol too.
One thing that is sure to happen in the world of computers is change.
At one time, no Commodore user would have thought CBM would replace the PET
with something else. Then the C64 came along. 10 years ago the thought of
Windows replacing DOS was something to laugh at. 5 or 6 years ago Linux was
not expected to actually compete with Windows... at least not by anyone
outside the groups developing Lunix.
It is only a matter of time before the current email protocol fades away as
a new one takes its place. It won't happen overnight, but over a period of
time. Just as desktop PC's did not replace dumb terminals overnight, but
over a period of years.
I won't pretend to know _how_ it will happen. A guess is that at first a
new protocol will be a superset of the current system, allowing the old
system to continue operating as a subset until, in time, it is phased out.
Sort of like "fast-talkers", like the 1571 and "slow-talkers" like the 1541
can exist on the same C128 serial bus.
> Even if somebody e-mails you a .zip file, it still goes through the
> MIME base64 encoding, which expands it almost as much as uuencode.
I think Sam didn't mean when someone sends a .zip file through email,
but the other way around, your total inbox (or the new messages only)
is stored in compressed format and you pick it up though a file
transfer other than through a mail server.
--
Anders Carlsson
>Windows replacing DOS was something to laugh at. 5 or 6 years ago Linux was
>not expected to actually compete with Windows... at least not by anyone
>outside the groups developing Lunix.
^^^^^^
It's an interesting idea you mentioned here. Do you mean, that in few
years Lunix may be competing with Windows? ;)
Anyway, Windows is actually still something to laugh at.
-Miika
>>You have to invent a new format that has to run parallel to the old one.
>>So you have to convince all mail server admins on the world to run your
>>new protocol to have the same availibility of email like it is today.
>>And the mail programs have to be able to talk the new protocol too.
>
> One thing that is sure to happen in the world of computers is change.
>
> At one time, no Commodore user would have thought CBM would replace the
> PET with something else. Then the C64 came along. 10 years ago the
> thought of Windows replacing DOS was something to laugh at. 5 or 6
> years ago Linux was not expected to actually compete with Windows... at
> least not by anyone outside the groups developing Lunix.
But while all those changes in hardware and software happened, the
protocol for e-mail hasn't changed much from the days when a C64 was
better than an IBM PC (clone).
I don't think it will change that much. I think more and more
communication will be wrapped in encryption protocols in the future. And
those protocols may feature transparent compression too (like SSH). That
would solve the bandwidth problem.
Currently the trend is, using/inventing text based data formats (XML)
instead of binary ones. The processing power and the amount of RAM and
disk space is growing all the time so it's possible to create human
readable and somewhat self documenting formats.
Ciao,
Marc 'BlackJack' Rintsch
>It's an interesting idea you mentioned here. Do you mean, that in few
>years Lunix may be competing with Windows? ;)
Linux _is_ competing with Windows in the small to medium server market.
Several major server manufacturers are recommending to their customers that
they buy machines with Linux installed, instead of Windows server software.
When Linux productivity software that can go head to head with Windows
software becomes readily available, Lunix may replace Windows as the number
one operating system on desktop computers. It will probably take really
good Lunix games before Lunix makes much headway in the home computer
market.
>But while all those changes in hardware and software happened, the
>protocol for e-mail hasn't changed much from the days when a C64 was
>better than an IBM PC (clone).
Anything that hasn't changed much since the days of the C64 would seem
overdue for change. :-) Processors have gone from 8-bit to 32-bit.
Disks have gone from 5.25" floppies to CD. Hard drives from 20 megs to 20
gigs. RAM from 64k to 64mb (or more). A comparable change in email
efficiency could be just around the corner.
Then again, it could be several years away...
You obviously missed Miika's subtle pun ;)
While there are a few protocols which could use a complete rewrite as far
as I'm concerned (FTP, NNTP (Usenet-over-IP protocol)), SMTP is relatively
OK. It's got some issues, but most of it is still adequate.
> Processors have gone from 8-bit to 32-bit. Disks have gone from 5.25"
> floppies to CD. Hard drives from 20 megs to 20 gigs. RAM from 64k to 64mb
> (or more). A comparable change in email efficiency could be just around the
> corner.
What, making it more efficient by bloating it, and making it human-unreadable?
You have one strange mind.
>Speaking of which, I've heard that Microsoft reserves 10-15% of the
>available bandwidth in Windows XP for its own use, no matter if the
>bandwidth is 56 kbps or 2.4 Gbps.
This is off topic here, but this can be fixed with a simple twirl of the
policy editor:
http://www.tweakxp.com/tweakxp/display.asp?id=282
--
CBM, Amiga and PEZ-nut, Scout, Glider pilot, Administrator
Email: vjo...@sci.fi, URL: http://www.sci.fi/~vjouppi/
GSM: +358-40-5679999, IRCNet: Jope
Arabuusimiehet World Domination