Universal Parallel Bus -- why not?

IF all you wanted to do on the Old Original Printer ports was get 8
bits OUT and 8 bits IN
AND you were willing to write you own code, you just used the Bi-
Directional bits as inputs, and that
added up to 8 input bits..

If you want to play with the Old Skool stuff, try this:
http://terryking.us/parport/

Quote:
All you need to do is think of your machine as having

   1. An 8-bit OUTPUT port, with the 8 bits connected to pins 2 thru 9
on the connector
   2. An 8-bit INPUT port, with the 8 bits connected to pins 10 thru
17 on the connector (Pins 18 thru 25 are GROUND).

You've probably heard of how weird the parallel port is! It's true,
but this software fixes it by moving the funny input bits around and
inverting those that need it. This level of software is for those who
write their own programs in Turbo Pascal (From Borland) and want to
control the parallel port.

If you're just starting out and don't want to write any software YET,
use SEEBITS.EXE  (Above)

I had a lot of fun with school kids wiring all kinds of junk up to the
bits, back in the day...

On Mar 22, 12:48=A0pm, Robert Baer <robertb...@localnet.com> wrote:
> MooseFET wrote:
> > On Mar 21, 2:07 pm, Robert Baer <robertb...@localnet.com> wrote:
> >> whit3rd wrote:
> >>> On Mar 20, 7:33 am, GreenXenon <glucege...@gmail.com> wrote:
> >>>> I keep hearing about Universal Serial Bus [USB]. Why hasn't a
> >>>> Universal Parallel Bus [UPB] been implemented yet?
> >>> It has been done, twice. =A0IEEE-488 for instruments, and SCSI
> >>> for small computers.
> >>> Expensive cables made IEEE-488 a boutique item, and SCSI
> >>> (which got up to 320 MBytes/sec) was usually kinda high-end
> >>> Most Macintosh computers from 1986 to 1998 used SCSI.
> >>> Parallel ports DO NOT COUNT, because they aren't a bus;
> >>> the early ones weren't even bidirectional, and there was
> >>> never any good support for more than two connections.
> >>> Bus, from 'omnibus' meaning 'for everyone' implies that all
> >>> bus signals are served by all devices, not just two.
> >> =A0 =A0Well, it turns out that the ORIGINAL PC/XT in 1980 had all of t=
he
> >> hardware on board to do full 8-bit I/O.
> >> =A0 =A0Are you perhaps alluding to an earlier version??
>
> > The "standard" PC printer port of the PC/XT was the 8255.
> > This chip could go both directions. =A0Later PCs integrated the
> > printer port function into a chip and removed some of the
> > abilities.
>
> =A0 =A0Nope; IBM Technical Reference Manual, First Edition, August 1981 o=
n
> page D-34 clearly shows a LS374 for data out, and a LS244 for data in.

Perhaps I am corrected.
My PC was not a real IBM.

On Sat, 20 Mar 2010 09:01:16 -0700, Charlie E. <edmondson@ieee.org> =
wrote:

>On Sat, 20 Mar 2010 10:38:44 -0500, Jamie
><jamie_ka1lpa_not_valid_after_ka1lpa_@charter.net> wrote:
>
>>GreenXenon wrote:
>>
>>> Hi:
>>>=20
>>> I keep hearing about Universal Serial Bus [USB]. Why hasn't a
>>> Universal Parallel Bus [UPB] been implemented yet?
>>>=20
>>> Wouldn't a UPB be faster than a USB at the same clock rate? If so,
>>> this would mean the same speed with less energy comsumption. Right?
>>>=20
>>>=20
>>> Thanks,
>>>=20
>>> Green Xenon
>>Yes it would be how ever, that cost more..
>>
>Against my better judgemnet, since I know GX is just a troll, I will
>answer his question...
>
>When you have one signal line, and you send a bit, then once you are
>able to determine the status of that bit, you are ready for the next
>one.  You can do this very quickly.
>
>However, when you have two lines, then you have to be able to know,
>not just the status of one of those lines, but that of both of them,
>at the same time.  This takes a little longer to be certain, and
>therefore, it goes slower.  One line or the other may be a little
>longer, or have a slightly different impedance, or any number of other
>reasons that makes it different.  Yes, this is ofen more than twice as
>long as for a single line.
>
>As you add signal lines, the problem grows.  You have to wait till you
>can be sure that ALL the lines have reached the correct state, before
>you can move on to the next.  Now, you may think that this doesn't
>grow too fast, and you are right.  But, at the same time, your
>hardware has also increased.  Your clock speed has gone down, and your
>hardware cost has gone up.  This makes a parallel signal not very
>attractive=20
>
>So, how do you get faster throughput?  You use multiple serial lines,
>like LVDS, each taking a part of the flow, and add them all togther at
>the the other end.
>
>Charlie

Yep, that is just what PCIExpress does, up to 16 lanes (serial line=20
group?) does.

On Sun, 21 Mar 2010 00:50:40 -0700 (PDT), TerryKing <terry@terryking.us> =
wrote:

>> So, how do you get faster throughput? =A0You use multiple serial =
lines,
>> like LVDS, each taking a part of the flow, and add them all togther at
>> the the other end.
>
>Good point, Charlie...
>
>This is being pushed to it's extreme, with multiple Very High Speed
>serial busses On-Chip and Off-Chip these days.
>
>My kid is working on simulating these at IBM.. They are around 10 GHz
>and each serial 'bus' has adaptive transmitters and receivers so the
>same design can be used for a variety of signal paths without
>redesign..
>
>The electronics world is getting weird :-)
>
>I got off the BUS just in time...

Next the poly bus packet trains.  No, i am not kidding.  The=20
time has come.  It will be normal in about 5 to 10 years.

On Sat, 20 Mar 2010 10:59:45 -0500, "Tim Williams" =
<tmoranwms@charter.net> wrote:

>You're 30 years too late.  They called it the Parallel Port.  Used on=20
>everything.
>
>Its fundamental limitations are: 1. attached to the 8MHz ISA bus (baud <=
=20
>~1Meg/s), cable length or signal quality (limited to about 1 meter), and=
 the=20
>cable contains 25 wires =3D it's a heavy bastard and requires lots of=20
>connections =3D more to go wrong.
>
>I suppose one could make a PCI or PCI-E clocked "parallel port", maybe =
using=20
>LVDS and terminated transmission lines, but then you'd be right back at=20
>something like 100MBit ethernet (CAT5 =3D four parallel pairs).
>
>USB has only four wires.  They fit nicely into a robust connector.  =
Can't=20
>beat that.
>
>Tim

Right so far, see USB 3.0.

On Sun, 21 Mar 2010 18:14:01 -0500, "krw@att.bizzzzzzzzzzzz" =
<krw@att.bizzzzzzzzzzzz> wrote:

>On Sun, 21 Mar 2010 17:04:49 -0500, "Tim Williams" =
<tmoranwms@charter.net>
>wrote:
>
>><krw@att.bizzzzzzzzzzzz> wrote in message=20
>>news:3clcq552ic5jonnrut4n2g7ejp6hn8lg4u@4ax.com...
>>>>> Nonsense. You could attach anything you wanted to them. The =
parallel=20
>>>>> port on
>>>>> the PC has always been bidirectional.
>>>>
>>>>Nope.
>>>>http://en.wikipedia.org/wiki/Parallel_port
>>>
>>> Hoisted by your own petard:
>>>
>>>  In early parallel ports the data lines were unidirectional (data out=
=20
>>> only)
>>>  so it was not easily possible to feed data in to the computer.
>>
>>Duh: the data lines were not bidirectional.
>
>Bullshit.
>
>The Monochrome and printer adapter pinout:
>
>Pin No 	Signal     Direction   Register-bit
>DB25    Name
>1 	nStrobe     Out        Control-0 =09
>2 	Data0 	    In/Out     Data-0 =09
>3 	Data1       In/Out     Data-1 =09
>4 	Data2       In/Out     Data-2 =09
>5 	Data3       In/Out     Data-3 =09
>6 	Data4       In/Out     Data-4 =09
>7 	Data5       In/Out     Data-5 =09
>8 	Data6       In/Out     Data-6 =09
>9 	Data7       In/Out     Data-7 =09
>10 	nAck        In 	       Status-6=20
>11 	Busy	    In 	       Status-7=20
>12 	Paper-Out   In 	       Status-5=20
>13 	Select 	    In	       Status-4=20
>14 	Linefeed    Out        Control-1
>15 	nError 	    In	       Status-3=20
>16 	nInitialize Out        Control-2
>17 	nSelect     Out        Control-3
>18-25 	Ground 	 =20
>
>>I do not know of any other definition of "bidirectional" which allows=20
>>different unidirectional wires to count as bidirectional.  =
Bidirectional=20
>>means two directions on the same wire (and in terms of implementation,=20
>>usually two directions on the same port address, which certainly isn't =
true=20
>>of the four status bits on the parallel port).
>>
>>> The 8255 *was* bidirectional.
>>
>>Still is.  But they never used it.  They used discrete latches, hence=20
>>unidirectional.

Not 8255.  The 8 databus lines of the printer port (Centronics) were=20
implemented with a 74LS374 in XT and earlier.  Bidirectional was later.

On Sun, 21 Mar 2010 13:07:01 -0800, Robert Baer <robertbaer@localnet.com>=
 wrote:

>whit3rd wrote:
>> On Mar 20, 7:33 am, GreenXenon <glucege...@gmail.com> wrote:
>>=20
>>> I keep hearing about Universal Serial Bus [USB]. Why hasn't a
>>> Universal Parallel Bus [UPB] been implemented yet?
>>=20
>> It has been done, twice.  IEEE-488 for instruments, and SCSI
>> for small computers.
>>=20
>> Expensive cables made IEEE-488 a boutique item, and SCSI
>> (which got up to 320 MBytes/sec) was usually kinda high-end
>> Most Macintosh computers from 1986 to 1998 used SCSI.
>>=20
>> Parallel ports DO NOT COUNT, because they aren't a bus;
>> the early ones weren't even bidirectional, and there was
>> never any good support for more than two connections.
>> Bus, from 'omnibus' meaning 'for everyone' implies that all
>> bus signals are served by all devices, not just two.
>   Well, it turns out that the ORIGINAL PC/XT in 1980 had all of the=20
>hardware on board to do full 8-bit I/O.
>   Are you perhaps alluding to an earlier version??

You are just referring to the wrong connector, those were ISA card slots.
The 74LS374 running the printer port data lines is not a bidirectional =
device.
Get a schematic if you do not believe me.

On Sun, 21 Mar 2010 11:11:40 -0500, Spehro Pefhany =
<speffSNIP@interlogDOTyou.knowwhat> wrote:

>On Sun, 21 Mar 2010 13:07:01 -0800, the renowned Robert Baer
><robertbaer@localnet.com> wrote:
>
>>whit3rd wrote:
>>> On Mar 20, 7:33 am, GreenXenon <glucege...@gmail.com> wrote:
>>>=20
>>>> I keep hearing about Universal Serial Bus [USB]. Why hasn't a
>>>> Universal Parallel Bus [UPB] been implemented yet?
>>>=20
>>> It has been done, twice.  IEEE-488 for instruments, and SCSI
>>> for small computers.
>>>=20
>>> Expensive cables made IEEE-488 a boutique item, and SCSI
>>> (which got up to 320 MBytes/sec) was usually kinda high-end
>>> Most Macintosh computers from 1986 to 1998 used SCSI.
>>>=20
>>> Parallel ports DO NOT COUNT, because they aren't a bus;
>>> the early ones weren't even bidirectional, and there was
>>> never any good support for more than two connections.
>>> Bus, from 'omnibus' meaning 'for everyone' implies that all
>>> bus signals are served by all devices, not just two.
>>   Well, it turns out that the ORIGINAL PC/XT in 1980 had all of the=20
>>hardware on board to do full 8-bit I/O.
>>   Are you perhaps alluding to an earlier version??
>
>You sure about that? I recall that inputs had to be done 4 bits at a
>time (nibble mode) to assure compatibility. I have a chunk of code
>around somewhere that defines all the printer control signals in a
>sensible way for general purpose control (some are inverted IIRC...)=20
>
>Checking Jan Axelson's seminal publication "Parallel Port Complete", I
>see she says:-
>
>The original PC's parallel port had eight outputs, five inputs, and
>four bidirectional lines.... On many newer PCs, the eight oututs can
>also serve as inputs..."
>
>Now, the really crotchety old farts will remember that there was a
>hardware modification you could do to the original parallel port cards
>(wot used LS TTL parts) to cut the /ENABLE pin of the output latch so
>it wasn't permanently grounded, and jumper it to allow it to be
>controlled for birectional I/O, but I wouldn't claim that this "had
>all the hardware on board" when soldering irons and dremels are
>involved...
>
>Of course all this stuff has been in a corner of an LSI chip for
>decades now, so you're stuck with whatever IP is used for the chip,
>but you used to be able to do it.=20
>
>
>
>Best regards,=20
>Spehro Pefhany

Yep, and any "0" being output by the ls374 tended to override any "1"=20
from any other device.  Wired and, which ever device said "0" (low) won.
With the PC or XT ls374 wired on, it did not really make that good of=20
bidirectional.

On Sat, 20 Mar 2010 19:34:57 -0500, AZ Nomad =
<aznomad.3@PremoveOBthisOX.COM> wrote:

>On Sat, 20 Mar 2010 07:33:19 -0700 (PDT), GreenXenon =
<glucegen1x@gmail.com> wrote:
>>Hi:
>
>>I keep hearing about Universal Serial Bus [USB]. Why hasn't a
>>Universal Parallel Bus [UPB] been implemented yet?
>
>>Wouldn't a UPB be faster than a USB at the same clock rate? If so,
>>this would mean the same speed with less energy comsumption. Right?
>
>nope.  Serial is faster nowadays.  Compare SATA-300 to PATA-133.

Gladly, PATA-133 does 125 MBytes/s; SATA-2 at 3.0 Gb/s does about=20
240 MBytes/s.  There is some transaction overhead for each of them.
The disk spinning at 7200 rpm can provide about 50 MBytes/s.  The=20
difference in real use: not all that much, you are still getting=20
eaten alive by rotational latency.=20

On Wed, 24 Mar 2010 22:58:37 -0700, "JosephKK"<quiettechblue@yahoo.com> wrote:

>On Sat, 20 Mar 2010 09:01:16 -0700, Charlie E. <edmondson@ieee.org> wrote:
>
>>On Sat, 20 Mar 2010 10:38:44 -0500, Jamie
>><jamie_ka1lpa_not_valid_after_ka1lpa_@charter.net> wrote:
>>
>>>GreenXenon wrote:
>>>
>>>> Hi:
>>>> 
>>>> I keep hearing about Universal Serial Bus [USB]. Why hasn't a
>>>> Universal Parallel Bus [UPB] been implemented yet?
>>>> 
>>>> Wouldn't a UPB be faster than a USB at the same clock rate? If so,
>>>> this would mean the same speed with less energy comsumption. Right?
>>>> 
>>>> 
>>>> Thanks,
>>>> 
>>>> Green Xenon
>>>Yes it would be how ever, that cost more..
>>>
>>Against my better judgemnet, since I know GX is just a troll, I will
>>answer his question...
>>
>>When you have one signal line, and you send a bit, then once you are
>>able to determine the status of that bit, you are ready for the next
>>one.  You can do this very quickly.
>>
>>However, when you have two lines, then you have to be able to know,
>>not just the status of one of those lines, but that of both of them,
>>at the same time.  This takes a little longer to be certain, and
>>therefore, it goes slower.  One line or the other may be a little
>>longer, or have a slightly different impedance, or any number of other
>>reasons that makes it different.  Yes, this is ofen more than twice as
>>long as for a single line.
>>
>>As you add signal lines, the problem grows.  You have to wait till you
>>can be sure that ALL the lines have reached the correct state, before
>>you can move on to the next.  Now, you may think that this doesn't
>>grow too fast, and you are right.  But, at the same time, your
>>hardware has also increased.  Your clock speed has gone down, and your
>>hardware cost has gone up.  This makes a parallel signal not very
>>attractive 
>>
>>So, how do you get faster throughput?  You use multiple serial lines,
>>like LVDS, each taking a part of the flow, and add them all togther at
>>the the other end.
>>
>>Charlie
>
>Yep, that is just what PCIExpress does, up to 16 lanes (serial line 
>group?) does.

Does PCI-E dynamically deskew each lane?