Getting started with AVR and C

On Friday, November 30, 2012 1:22:12 PM UTC-8, Jon Kirwan wrote:
> On Fri, 30 Nov 2012 09:26:39 -0800 (PST),
> 
> me@linnix.info-for.us wrote:
> 
> 
> 
> >> I believe that C was implemented on the PDP-10. I didn't use
> 
> >> it when I was programming the PDP-10 (I used assembly, then,
> 
> >> and some other languages... but not C, until I worked on Unix
> 
> >> v6 in '78.) But that was a 36-bit machine. And ASCII was
> 
> >> packed into 7 bits so that 5 chars fit in a word. No one used
> 
> >> 8, so far as I recall. That was the standard method. So I'm
> 
> >> curious now what the C implementation did.
> 
> >
> 
> >For Unix, serial I/O was as important as efficient storage of data.
> 
> 
> 
> Given the cost of memory back then, primary or secondary, a
> 
> great many man-hours were spent on efficient storage. Serial
> 
> I/O was almost exclusively used because of how modems worked,
> 
> then, for transmission over long distances. (Some may argue
> 
> that it requires fewer wires, too, in cables. But that was
> 
> less an issue then -- witness the 36-pin and 25-pin Centronix
> 
> cables/connectors which were very wire-heavy.) It turns out
> 
> that terminals, like the ASR-33 and KSR-35, were often used
> 
> without a computer for dial-up modem use over a phone line.
> 
> So they used a serial interface, by design. Which meant that
> 
> Unix needed to cope with it. But I wouldn't say "as important
> 
> as." I worked on the v6 Unix kernel, so I was slightly aware
> 
> of the situation.
> 

But one (perhaps unwritten) goal was for uniform files and I/Os.  So, the lowest denominator (8 bits) is necessary.

Jon Kirwan wrote:

> Of course, I was just bringing up the PDP-10 because of its
> odd way of packing 7-bit codes into a 36-bit word.

Yes.  Odd.  But compact; for data processing you can see their reasons.
Elsewhere, like the GE Datanet-30 communication proccessor, ASCII in a nine-
bit byte meant you could stuff a start bit, 7 data bits and parity into one 
byte-wide buffer register.  Shifting in ones as the data bits shifted out 
meant that (unless somebody intervened by loading another character) you'd 
be left with 0777 after the character was transmitted, and thus you'd be 
driving an idle line as long as needed.

	Mel.

On Fri, 30 Nov 2012 14:10:25 -0800 (PST),
me@linnix.info-for.us wrote:

><snip>
> But one (perhaps unwritten) goal was for uniform files and
> I/Os.  So, the lowest denominator (8 bits) is necessary.

No. It could have been, had this been an IBM machine, that
the lowest common denominator was something else. The 8-bit
choice was a confluence of many factors, not just a simple
deduction that was "obvious." I know. Because I remember
wondering, and having debates, about where this would wind up
in the end. It wasn't "necessary." If it was, we'd all have
seen it that way at the time. And we didn't.

Jon

On Fri, 30 Nov 2012 17:36:28 -0500, Mel Wilson
<mwilson@the-wire.com> wrote:

>Jon Kirwan wrote:
>
>> Of course, I was just bringing up the PDP-10 because of its
>> odd way of packing 7-bit codes into a 36-bit word.
>
>Yes.  Odd.  But compact; for data processing you can see their reasons.
>Elsewhere, like the GE Datanet-30 communication proccessor, ASCII in a nine-
>bit byte meant you could stuff a start bit, 7 data bits and parity into one 
>byte-wide buffer register.  Shifting in ones as the data bits shifted out 
>meant that (unless somebody intervened by loading another character) you'd 
>be left with 0777 after the character was transmitted, and thus you'd be 
>driving an idle line as long as needed.
>
>	Mel.

Thanks for this note, Mel!

Jon

On Fri, 30 Nov 2012 13:22:12 -0800, Jon Kirwan
<jonk@infinitefactors.org> wrote:

>
>>Most serial terminal can't do more than 8 bits, and usually 7E or 7O.
>>So, 8 bit char became standard.

If you think about a mechanical typewriter or line printer, how on
earth would you fit a large character set into it ?

Being able to print numbers was of course the most needed feature,
printing a very limited set of (upper case) letters was a bonus and
some special characters like + or - would also be a bonus.

The English language can be represented with only a few letters, but
even most Latin based languages needed some extra characters and these
were taken in ISO 646 from the special character sets, thus square
brackets were replaced by national variants.

On a line printer you typically had a 64 (upper case only) or 96 (with
lower case) character drums and you had to order a drum made for your
non-anglosaxon country.
  
>
>At the time, there was no real standard at all. I saw equal
>numbers of machines using EBCDIC and 6-bit (5-bit Boudot was
>waning by this time but I also remember old terminals that
>used 5-bit) and 7-bit. 

Baudot 5 bit was of course popular due to the huge number of Telex
terminals that existed in those days. Manchester Mark I used Baudot
for this reason.

Later on 36 bits was quite common, capable of storing six 6 bit (upper
case only) characters or nine 4 bit BCD decimal digits (sufficient for
storing non-inflated dollar values in a single memory word.

>No machine used 8-bit for anything,
>then. The 8th bit was always just looked at as either 'don't
>punch it at all, so the paper tape is more durable' or else
>make it even or odd parity. Some of us would write programs
>to punch out visible English messages on the tape, which was
>one of the few reasons we actually wanted control over 8 bits
>(for those paper punch machines that punched 8.) 

If you forgot to immediately mark your paper tapes with a pen or some
easily recognizable punch figures, you were in great troubles :-)

However 5x7 upper case characters was the norm for dot matrix
displays, so I think 7 controllable bits would be enough ?
 

>Side note: there was only a gradual "coming together" on the
>idea that an 8-bit byte was a "good idea." I think a lot of
>people these days imagine that it was always as obvious and
>as ubiquitous as it is today. But that's not entirely true.
>Things went to 8-bit, gradually. Partly, because 8 bits is a
>nice 2^3 power thing and partly because ASCII was gradually
>taking over as a standard and would fit into a 8-bit byte,
>nicely. There was a confluence of forces going on and this
>kind of "precipitated out" to what it is today.

Computers were originally exclusively used for numerical calculations
and because of the extremely costly division operation in converting a
true binary value into human printable decimal digits, many computers
used decimal digits internally represented as 4 bit BCD numbers
internally (ENIAC was a true decimal machine with tubes with ten
active electrodes).

Thus 4 bit is as natural as 8 bits, both power of 2.

Later on, when the prices came down and it made sense to use larger
memory and processor  widths, the ability to store nine BCD digits
into a 36 bit word made this architecture popular for financial
transactions at that time.

As the memory prices came down, people also wanted to store texts in
computer memory. Storing six 6 bit characters was quite obvious.

However, IBM in their 360 (all around) series chose to use two 4 bit
BCD numbers to store one character and hence the popularity of the 8
bit byte.

>Side note again: Recently, I read a "personal history"
>talking about the complexity of the ASR-33. The author has no
>idea. I also remember quite well the much more complicated
>KSR-35. I worked on repairing both, from time to time. By
>comparison, the ASR-33 was a toy, designed for less lifetime
>and less complex, as well. The earlier KSR-35 was made for
>men, so to speak -- extremely well lubricated system with
>real man-parts and not toy pieces. The ASR-33 had a cute
>little cylinder with the letters on it, not that unlike the
>typewriter ball. The KSR-35 had a large hammer block,
>instead.
>
>Jon

After all these years, I hove always wondered, how such excellent
examples of mechanical engineering could work more than an hour
without maintenance.

These were completely mechanical (including serial to parallel and
parallel to serial conversion) and the only semiconductors were the
power supply rectifier diodes and the transistor in the 20 mA constant
current supply :-).

On Sat, 01 Dec 2012 10:08:42 +0200, upsidedown@downunder.com
wrote:

>On Fri, 30 Nov 2012 13:22:12 -0800, Jon Kirwan
><jonk@infinitefactors.org> wrote:
>
>>>Most serial terminal can't do more than 8 bits, and usually 7E or 7O.
>>>So, 8 bit char became standard.
>
>If you think about a mechanical typewriter or line printer, how on
>earth would you fit a large character set into it ?
>
>Being able to print numbers was of course the most needed feature,
>printing a very limited set of (upper case) letters was a bonus and
>some special characters like + or - would also be a bonus.
>
>The English language can be represented with only a few letters, but
>even most Latin based languages needed some extra characters and these
>were taken in ISO 646 from the special character sets, thus square
>brackets were replaced by national variants.
>
>On a line printer you typically had a 64 (upper case only) or 96 (with
>lower case) character drums and you had to order a drum made for your
>non-anglosaxon country.
>  
>>
>>At the time, there was no real standard at all. I saw equal
>>numbers of machines using EBCDIC and 6-bit (5-bit Boudot was
>>waning by this time but I also remember old terminals that
>>used 5-bit) and 7-bit. 
>
>Baudot 5 bit was of course popular due to the huge number of Telex
>terminals that existed in those days. Manchester Mark I used Baudot
>for this reason.
>
>Later on 36 bits was quite common, capable of storing six 6 bit (upper
>case only) characters or nine 4 bit BCD decimal digits (sufficient for
>storing non-inflated dollar values in a single memory word.
>
>>No machine used 8-bit for anything,
>>then. The 8th bit was always just looked at as either 'don't
>>punch it at all, so the paper tape is more durable' or else
>>make it even or odd parity. Some of us would write programs
>>to punch out visible English messages on the tape, which was
>>one of the few reasons we actually wanted control over 8 bits
>>(for those paper punch machines that punched 8.) 
>
>If you forgot to immediately mark your paper tapes with a pen or some
>easily recognizable punch figures, you were in great troubles :-)
>
>However 5x7 upper case characters was the norm for dot matrix
>displays, so I think 7 controllable bits would be enough ?

We wanted to be able to UNDERLINE stuff!! Very important! Or
to get a better lowercase feeling you used that line for a
little bit of a descender-feeling.

>>Side note: there was only a gradual "coming together" on the
>>idea that an 8-bit byte was a "good idea." I think a lot of
>>people these days imagine that it was always as obvious and
>>as ubiquitous as it is today. But that's not entirely true.
>>Things went to 8-bit, gradually. Partly, because 8 bits is a
>>nice 2^3 power thing and partly because ASCII was gradually
>>taking over as a standard and would fit into a 8-bit byte,
>>nicely. There was a confluence of forces going on and this
>>kind of "precipitated out" to what it is today.
>
>Computers were originally exclusively used for numerical calculations
>and because of the extremely costly division operation in converting a
>true binary value into human printable decimal digits, many computers
>used decimal digits internally represented as 4 bit BCD numbers
>internally (ENIAC was a true decimal machine with tubes with ten
>active electrodes).
>
>Thus 4 bit is as natural as 8 bits, both power of 2.
>
>Later on, when the prices came down and it made sense to use larger
>memory and processor  widths, the ability to store nine BCD digits
>into a 36 bit word made this architecture popular for financial
>transactions at that time.
>
>As the memory prices came down, people also wanted to store texts in
>computer memory. Storing six 6 bit characters was quite obvious.
>
>However, IBM in their 360 (all around) series chose to use two 4 bit
>BCD numbers to store one character and hence the popularity of the 8
>bit byte.

A second thing I recall was the battle between hex and octal.
But once the 8-bit thing caught on... octal was doomed. I
still use octal for one reason... I have a very simple method
of converting back and forth between octal and decimal that I
do on paper. I've posted it before. But it is a lost art for
most. Still, I find it more practical than using hex, when
converting by hand.

>>Side note again: Recently, I read a "personal history"
>>talking about the complexity of the ASR-33. The author has no
>>idea. I also remember quite well the much more complicated
>>KSR-35. I worked on repairing both, from time to time. By
>>comparison, the ASR-33 was a toy, designed for less lifetime
>>and less complex, as well. The earlier KSR-35 was made for
>>men, so to speak -- extremely well lubricated system with
>>real man-parts and not toy pieces. The ASR-33 had a cute
>>little cylinder with the letters on it, not that unlike the
>>typewriter ball. The KSR-35 had a large hammer block,
>>instead.
>
>After all these years, I hove always wondered, how such excellent
>examples of mechanical engineering could work more than an hour
>without maintenance.

I still remember the KSR-35 as an absolute marvel of
mechanical engineering. The person who designed that thing
(and it could NOT have been designed by committee) must have
locked themselves up in an asylum, after. I don't mean that
in a bad way -- it was stunningly well executed. And it was
also incredible to watch in operation.

They worked quite well, I think. I worked on some problems
just twice over the few years I used it. And it was never
something fundamental about the design. It wore evenly and
well. All of it balanced like a fine watch.

That said, other things I worked on around that time didn't
work so well. Ever see an 8k drum drive operating on a PDP-8?
Mostly didn't operate, darned things. They were big and
pointless. The only thing they had going for them was the ..
I think .. 96 read heads or something like that. No seek
time, just rotation delay time and then read time. Tried to
use them, but the supposed benefits didn't seem worth it,
given the down time I saw.

>These were completely mechanical (including serial to parallel and
>parallel to serial conversion) and the only semiconductors were the
>power supply rectifier diodes and the transistor in the 20 mA constant
>current supply :-).

Yup.

Damn. Now I need to see if anyone has one to sell. Crap. My
wife is going to hate it. Luckily, I've got over 7000 sq ft
of space here, so I should be able to find some corner for
it. If I can find one. Would be fun to clean one up and get
it working, if the problems weren't too fundamental after all
these years.

My eyes are probably bigger than my stomach, though.

Jon

On Sat, 01 Dec 2012 10:08:42 +0200, upsidedown@downunder.com wrote:

>On Fri, 30 Nov 2012 13:22:12 -0800, Jon Kirwan
><jonk@infinitefactors.org> wrote:
>
>>
>>>Most serial terminal can't do more than 8 bits, and usually 7E or 7O.
>>>So, 8 bit char became standard.
>
>If you think about a mechanical typewriter or line printer, how on
>earth would you fit a large character set into it ?
>
>Being able to print numbers was of course the most needed feature,
>printing a very limited set of (upper case) letters was a bonus and
>some special characters like + or - would also be a bonus.
>
>The English language can be represented with only a few letters, but
>even most Latin based languages needed some extra characters and these
>were taken in ISO 646 from the special character sets, thus square
>brackets were replaced by national variants.
>
>On a line printer you typically had a 64 (upper case only) or 96 (with
>lower case) character drums and you had to order a drum made for your
>non-anglosaxon country.


Line printers were a varied lot.  A popular design, at least for
higher end models, used a print train or chain with type slugs moving
around the train.  On the popular 1403 printer, for example, the train
had 240 positions, which could, at least theoretically, hold that many
different characters, although that would require a custom train.
 
The standard 1403 trains ("TN") with the largest variety of characters
had two complete copies of 120 different characters.  These were
rather slow trains, and tended to be used only for text-heavy output,
and included, amongst other things, superscript digits, and a variety
of mathematical symbols).  More commonly trains with more copies of
fewer characters were used, the idea being that a slug with the
appropriate character had to rotate past every print position on the
line before the printer could advance to the next line.

I actually saw (custom) trains with over 200 different characters,
which included italics and other funky things.  These were very slow&#4294967295;

Many trains had a mix of frequencies - "PCS-AN", for example, with
four copies of most characters, two copies of some unusual characters,
and eight copies of common characters such as digits.  This would
allow print speeds (1403-3) of 1385, 920 or 550 lines-per-minute,
depending on what characters were on a given line.

The fastest trains had a few as 42 characters ("YN"), but six copies
of 39 of those (and two copies of the other three).  Print speeds were
maximized when avoiding those last three characters.  The fast trains
could often sustain the full (or nearly the full) 1400LPM of the
printers, while a TN train would usually chug along at about a third
that (~550LPM).

Probably more than anyone wanted to know about line printers, but...

Jon Kirwan wrote:
> On Sat, 01 Dec 2012 10:08:42 +0200, upsidedown@downunder.com
> wrote:
>
>> These were completely mechanical (including serial to parallel and
>> parallel to serial conversion) and the only semiconductors were the
>> power supply rectifier diodes and the transistor in the 20 mA constant
>> current supply :-).
>
> Yup.
>
> Damn. Now I need to see if anyone has one to sell. Crap. My
> wife is going to hate it. Luckily, I've got over 7000 sq ft
> of space here, so I should be able to find some corner for
> it. If I can find one. Would be fun to clean one up and get
> it working, if the problems weren't too fundamental after all
> these years.

Up until very recently (this summer) I had quite a bit of old computer 
stuff.  I have sold or given away much of it now, which helps assure 
domestic tranquility.  The 9-track tape drives were about as big as a 
refrigerator, but heavier...  Still have an ADM-3A terminal and other 
70s era computing ephemera, but I let the most bulky stuff go, so I 
still have the tape drive manuals and the PDP-8 manuals but not the 
devices.

Someone should write a VR TTY simulator that includes realistic sound. 
Here's a video clip of a model 28 in action: 
http://www.youtube.com/watch?v=D1ng6v9UMw8

Ed

On Sat, 01 Dec 2012 02:58:58 -0600, Robert Wessel
<robertwessel2@yahoo.com> wrote:

>On Sat, 01 Dec 2012 10:08:42 +0200, upsidedown@downunder.com wrote:
>
>>On Fri, 30 Nov 2012 13:22:12 -0800, Jon Kirwan
>><jonk@infinitefactors.org> wrote:
>>
>>>
>>>>Most serial terminal can't do more than 8 bits, and usually 7E or 7O.
>>>>So, 8 bit char became standard.
>>
>>If you think about a mechanical typewriter or line printer, how on
>>earth would you fit a large character set into it ?
>>
>>Being able to print numbers was of course the most needed feature,
>>printing a very limited set of (upper case) letters was a bonus and
>>some special characters like + or - would also be a bonus.
>>
>>The English language can be represented with only a few letters, but
>>even most Latin based languages needed some extra characters and these
>>were taken in ISO 646 from the special character sets, thus square
>>brackets were replaced by national variants.
>>
>>On a line printer you typically had a 64 (upper case only) or 96 (with
>>lower case) character drums and you had to order a drum made for your
>>non-anglosaxon country.
>
>
>Line printers were a varied lot.  A popular design, at least for
>higher end models, used a print train or chain with type slugs moving
>around the train.  On the popular 1403 printer, for example, the train
>had 240 positions, which could, at least theoretically, hold that many
>different characters, although that would require a custom train.
> 
>The standard 1403 trains ("TN") with the largest variety of characters
>had two complete copies of 120 different characters.  These were
>rather slow trains, and tended to be used only for text-heavy output,
>and included, amongst other things, superscript digits, and a variety
>of mathematical symbols).  More commonly trains with more copies of
>fewer characters were used, the idea being that a slug with the
>appropriate character had to rotate past every print position on the
>line before the printer could advance to the next line.
>
>I actually saw (custom) trains with over 200 different characters,
>which included italics and other funky things.  These were very slow&#4294967295;
>
>Many trains had a mix of frequencies - "PCS-AN", for example, with
>four copies of most characters, two copies of some unusual characters,
>and eight copies of common characters such as digits.  This would
>allow print speeds (1403-3) of 1385, 920 or 550 lines-per-minute,
>depending on what characters were on a given line.
>
>The fastest trains had a few as 42 characters ("YN"), but six copies
>of 39 of those (and two copies of the other three).  Print speeds were
>maximized when avoiding those last three characters.  The fast trains
>could often sustain the full (or nearly the full) 1400LPM of the
>printers, while a TN train would usually chug along at about a third
>that (~550LPM).
>
>Probably more than anyone wanted to know about line printers, but...

This was interesting reading, since I have only used and maintained
drum printers.

Those chain printers must have been quite expensive with switchable
"fonts". Did the printer controller have an actual CPU with local core
memory or was it hard wired with standard RTL/DTL/TTL logic chips ?
 

On Sat, 01 Dec 2012 17:28:03 +0200, upsidedown@downunder.com wrote:

>On Sat, 01 Dec 2012 02:58:58 -0600, Robert Wessel
><robertwessel2@yahoo.com> wrote:
>
>>On Sat, 01 Dec 2012 10:08:42 +0200, upsidedown@downunder.com wrote:
>>
>>>On Fri, 30 Nov 2012 13:22:12 -0800, Jon Kirwan
>>><jonk@infinitefactors.org> wrote:
>>>
>>>>
>>>>>Most serial terminal can't do more than 8 bits, and usually 7E or 7O.
>>>>>So, 8 bit char became standard.
>>>
>>>If you think about a mechanical typewriter or line printer, how on
>>>earth would you fit a large character set into it ?
>>>
>>>Being able to print numbers was of course the most needed feature,
>>>printing a very limited set of (upper case) letters was a bonus and
>>>some special characters like + or - would also be a bonus.
>>>
>>>The English language can be represented with only a few letters, but
>>>even most Latin based languages needed some extra characters and these
>>>were taken in ISO 646 from the special character sets, thus square
>>>brackets were replaced by national variants.
>>>
>>>On a line printer you typically had a 64 (upper case only) or 96 (with
>>>lower case) character drums and you had to order a drum made for your
>>>non-anglosaxon country.
>>
>>
>>Line printers were a varied lot.  A popular design, at least for
>>higher end models, used a print train or chain with type slugs moving
>>around the train.  On the popular 1403 printer, for example, the train
>>had 240 positions, which could, at least theoretically, hold that many
>>different characters, although that would require a custom train.
>> 
>>The standard 1403 trains ("TN") with the largest variety of characters
>>had two complete copies of 120 different characters.  These were
>>rather slow trains, and tended to be used only for text-heavy output,
>>and included, amongst other things, superscript digits, and a variety
>>of mathematical symbols).  More commonly trains with more copies of
>>fewer characters were used, the idea being that a slug with the
>>appropriate character had to rotate past every print position on the
>>line before the printer could advance to the next line.
>>
>>I actually saw (custom) trains with over 200 different characters,
>>which included italics and other funky things.  These were very slow&#4294967295;
>>
>>Many trains had a mix of frequencies - "PCS-AN", for example, with
>>four copies of most characters, two copies of some unusual characters,
>>and eight copies of common characters such as digits.  This would
>>allow print speeds (1403-3) of 1385, 920 or 550 lines-per-minute,
>>depending on what characters were on a given line.
>>
>>The fastest trains had a few as 42 characters ("YN"), but six copies
>>of 39 of those (and two copies of the other three).  Print speeds were
>>maximized when avoiding those last three characters.  The fast trains
>>could often sustain the full (or nearly the full) 1400LPM of the
>>printers, while a TN train would usually chug along at about a third
>>that (~550LPM).
>>
>>Probably more than anyone wanted to know about line printers, but...
>
>This was interesting reading, since I have only used and maintained
>drum printers.
>
>Those chain printers must have been quite expensive with switchable
>"fonts". Did the printer controller have an actual CPU with local core
>memory or was it hard wired with standard RTL/DTL/TTL logic chips ?


Something like a 1403 needed a separate control unit (a 2821) to
attach to a S/360 channel.  The 2821 was a combination of device
specific hardware* and a microsequenced control unit.  They included a
bit of memory necessary for performing their function (a record or two
worth of buffer, and, in the case of printer, a buffer containing the
image of the print train).

Later printers had actual processors in their control units.

The trains were not terribly expensive, several hundred dollars for
the standard ones (although inflation will make that rather more in
today's dollars).

A decent picture:

http://ibmcollectables.com/gallery/album127/IBM_1403_print_train

You can see an installed train at:

http://en.wikipedia.org/wiki/File:IBM_1403_Printer_opened.jpg

The end of the train is sticking out from under the ink ribbon wrapped
around the left side (as viewed) of the gate.  The gate is the part in
the right foreground of the picture, swung out from the printer. Just
below and to the right of the corner of the train is the rather
industrial motor that drove the train.  The print hammers were behind
the paper, and smacked the paper into the ribbon and slug as the slug
passed the appropriate position.

Changing the train was fairly simple, open the gate, remove the
ribbon, flip up to two handles on the train (as seen on the first
photo), and lift it out - then reverse the process for the new train.
You'd then have to load a new mapping buffer into the control unit,
usually from the spooler on the OS driving the printer (typically that
would be semi-automated - the print job would be written to the spool
specifying the required train, when the spooler printed it, and the
wrong train was installed on the printer, he'd stop and tell the
operator to mount the new train, and when the operator acknowledged
doing that, he'd download the new mapping buffer).

Somewhat oddly, the second photograph shows already printed paper
being fed through the printer.


*2821s could control a number of printers, card readers and punches,
you had to order the right hardware (for example a model one could
support one 1403 printer, and one 2540 reader/punch, a model three
could support three 1403 printers).