Universal Parallel Bus -- why not?

GreenXenon

unread,

Mar 20, 2010, 10:33:19 AM3/20/10

to

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

Jamie

unread,

Mar 20, 2010, 11:38:44 AM3/20/10

to

GreenXenon wrote:

Yes it would be how ever, that cost more..

GreenXenon

unread,

Mar 20, 2010, 11:38:56 AM3/20/10

to

On Mar 20, 8:38 am, Jamie

Significantly more?

Tim Williams

unread,

Mar 20, 2010, 11:59:45 AM3/20/10

to

You're 30 years too late. They called it the Parallel Port. Used on
everything.

Its fundamental limitations are: 1. attached to the 8MHz ISA bus (baud <
~1Meg/s), cable length or signal quality (limited to about 1 meter), and the
cable contains 25 wires = it's a heavy bastard and requires lots of
connections = more to go wrong.

I suppose one could make a PCI or PCI-E clocked "parallel port", maybe using
LVDS and terminated transmission lines, but then you'd be right back at
something like 100MBit ethernet (CAT5 = four parallel pairs).

USB has only four wires. They fit nicely into a robust connector. Can't
beat that.

Tim

--
Deep Friar: a very philosophical monk.
Website: http://webpages.charter.net/dawill/tmoranwms

"GreenXenon" <gluce...@gmail.com> wrote in message
news:658ff416-fea2-4105...@a37g2000prd.googlegroups.com...

Charlie E.

unread,

Mar 20, 2010, 12:01:16 PM3/20/10

to

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

John Larkin

unread,

Mar 20, 2010, 1:25:10 PM3/20/10

to

At very high speeds you start to get skew in the prop delay between
different data lines of a parallel bus... the bits arrive at the
destination at different times. The higher the clock rate and the
longer the bus, the worse this problem gets.

A signal traveling over a single twisted pair has no skew problems.
And electrical losses/dispersion can be fixed with per-lane adaptive
equalizers. For higher data rates, you add more lanes, each with its
own transmitter/equalizer/receiver/fifo, and merge the data streams
digitally. So long, fast serial busses scale much better than parallel
busses. They are smaller and use less connector and IC pins, too.

John

lang...@fonz.dk

unread,

Mar 20, 2010, 1:38:13 PM3/20/10

to

On 20 Mar., 18:25, John Larkin

<jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
> On Sat, 20 Mar 2010 07:33:19 -0700 (PDT), GreenXenon
>

and toggling a wide bus slowly will use just about as much power as
toggling a narrow bus fast so theres no magic gain in efficiency

-Lasse

k...@att.bizzzzzzzzzzzz

unread,

Mar 20, 2010, 1:50:39 PM3/20/10

to

On Sat, 20 Mar 2010 07:33:19 -0700 (PDT), GreenXenon <gluce...@gmail.com>
wrote:

>Hi:
>
>I keep hearing about Universal Serial Bus [USB]. Why hasn't a
>Universal Parallel Bus [UPB] been implemented yet?

It has. It's often called the "Printer Port".

>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?

No. and HELL NO.

Grant

unread,

Mar 20, 2010, 2:00:53 PM3/20/10

to

Of course, look at the old Centronics port printer cable compared to
a modern USB cable.

A common fast parallel bus was the SCSI port for HDDs, and these days
they use SAS (Serial Attached SCSI) because it's faster than old
parallel form, which went from narrow, wide and ultrawide before
going serial to run even faster.

And the reason is as other posters state, data skew between parallel
lines limits max data rate. It's faster to go serial. That's why
hard drives now use SATA rather than the old ribbon cable.

USB is also self powered, it grew from the serial keyboard connection
where the requirement was met by four lines: power, data, clock and
ground to get the cheapest hardware solution.

Also, USB's self clocking gets rid of the old serial port's parameter
setting issues.

Grant.

MooseFET

unread,

Mar 20, 2010, 7:43:48 PM3/20/10

to

Look up IEEE-488

It was an attempted semi-universal parallel bus system. It had
several
problems. One being that the specs were written by lawyers. They
were
very hard to understand. There was also one part to do with the
serial
pole method that was ambiguous. Two systems could comply but not be
compatible with each other.

Jim Yanik

unread,

Mar 20, 2010, 7:47:15 PM3/20/10

to

"k...@att.bizzzzzzzzzzzz" <k...@att.bizzzzzzzzzzzz> wrote in
news:dl2aq5dumrb6r3bit...@4ax.com:

> On Sat, 20 Mar 2010 07:33:19 -0700 (PDT), GreenXenon
> <gluce...@gmail.com> wrote:
>
>>Hi:
>>
>>I keep hearing about Universal Serial Bus [USB]. Why hasn't a
>>Universal Parallel Bus [UPB] been implemented yet?

because cables for them would be far more complex and costly.
How many bits were you considering for your "universal bus"?
A 32 bit bus is going to need 32 wire pairs(signal and GND) or 32 coaxial
cables of equal length,along with clocks,power and grounds.
And now we're at 64 bit buses.
Just look at the old printer cables.

TV stations had the same problem when they went to digital video.and they
only used a 10 bit bus.

>
> It has. It's often called the "Printer Port".
>
>>Wouldn't a UPB be faster than a USB at the same clock rate?

Yes.
..but....more expensive,complex,and more prone to breakage.
Also,fewer cables could be run in the same ducts.

>>If so,
>>this would mean the same speed with less energy comsumption. Right?
>
> No. and HELL NO.
>

MORE energy consumption,because your driver port has to drive all those
outputs,instead of a single output.

TANSTAAFL.

--
Jim Yanik
jyanik
at
localnet
dot com

k...@att.bizzzzzzzzzzzz

unread,

Mar 20, 2010, 8:06:32 PM3/20/10

to

On Sat, 20 Mar 2010 18:47:15 -0500, Jim Yanik <jya...@abuse.gov> wrote:

>"k...@att.bizzzzzzzzzzzz" <k...@att.bizzzzzzzzzzzz> wrote in
>news:dl2aq5dumrb6r3bit...@4ax.com:
>
>> On Sat, 20 Mar 2010 07:33:19 -0700 (PDT), GreenXenon
>> <gluce...@gmail.com> wrote:
>>
>>>Hi:
>>>
>>>I keep hearing about Universal Serial Bus [USB]. Why hasn't a
>>>Universal Parallel Bus [UPB] been implemented yet?
>
>because cables for them would be far more complex and costly.
>How many bits were you considering for your "universal bus"?
>A 32 bit bus is going to need 32 wire pairs(signal and GND) or 32 coaxial
>cables of equal length,along with clocks,power and grounds.
>And now we're at 64 bit buses.
>Just look at the old printer cables.
>
>TV stations had the same problem when they went to digital video.and they
>only used a 10 bit bus.
>>
>> It has. It's often called the "Printer Port".
>>
>>>Wouldn't a UPB be faster than a USB at the same clock rate?
>
>Yes.

No. Skew.

whit3rd

unread,

Mar 20, 2010, 8:28:11 PM3/20/10

to

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. IEEE-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.

AZ Nomad

unread,

Mar 20, 2010, 8:34:57 PM3/20/10

to

On Sat, 20 Mar 2010 07:33:19 -0700 (PDT), GreenXenon <gluce...@gmail.com> wrote:

>Hi:

nope. Serial is faster nowadays. Compare SATA-300 to PATA-133.

Bitrex

unread,

Mar 20, 2010, 9:05:33 PM3/20/10

to

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. IEEE-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.

Audio equipment like samplers and keyboard workstations also used SCSI,
both for sample transfer between a PC and the hardware and for mass
storage. Audio manufacturers were quite slow to switch from SCSI to
flash memory/USB for storage/transfer; it was possible to buy new
equipment with internal or external SCSI-1 ports well into the 21st
century. SCSI-1 compact flash readers sell for big money on Ebay for
retrofitting older equipment.

k...@att.bizzzzzzzzzzzz

unread,

Mar 20, 2010, 9:23:31 PM3/20/10

to

On Sat, 20 Mar 2010 17:28:11 -0700 (PDT), whit3rd <whi...@gmail.com> 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. IEEE-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.

Nonsense. You could attach anything you wanted to them. The parallel port on
the PC has always been bidirectional.

>Bus, from 'omnibus' meaning 'for everyone' implies that all
>bus signals are served by all devices, not just two.

ALL devices? My PCI bus doesn't serve my memory. You're just making things
up now.

a7yvm1...@netzero.com

unread,

Mar 20, 2010, 9:55:17 PM3/20/10

to

On Mar 20, 8:23 pm, "k...@att.bizzzzzzzzzzzz"
<k...@att.bizzzzzzzzzzzz> wrote:

> On Sat, 20 Mar 2010 17:28:11 -0700 (PDT), whit3rd <whit...@gmail.com> 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. IEEE-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.
>
> Nonsense. You could attach anything you wanted to them. The parallel port on
> the PC has always been bidirectional.

Nope.
http://en.wikipedia.org/wiki/Parallel_port

>
> >Bus, from 'omnibus' meaning 'for everyone' implies that all
> >bus signals are served by all devices, not just two.
>
> ALL devices? My PCI bus doesn't serve my memory. You're just making things
> up now.

So are you.

TerryKing

unread,

Mar 21, 2010, 3:50:40 AM3/21/10

to

> 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.

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...

Robert Baer

unread,

Mar 21, 2010, 5:01:38 PM3/21/10

to

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

I have had NO trouble using 100 feet of cable on a parallel port (R/W
too...).

Robert Baer

unread,

Mar 21, 2010, 5:07:01 PM3/21/10

to

Well, it turns out that the ORIGINAL PC/XT in 1980 had all of the
hardware on board to do full 8-bit I/O.
Are you perhaps alluding to an earlier version??

Spehro Pefhany

unread,

Mar 21, 2010, 12:11:40 PM3/21/10

to

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...)

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.

Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
sp...@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com

Message has been deleted

MooseFET

unread,

Mar 21, 2010, 11:44:23 AM3/21/10

to

The "standard" PC printer port of the PC/XT was the 8255.
This chip could go both directions. Later PCs integrated the
printer port function into a chip and removed some of the
abilities.

k...@att.bizzzzzzzzzzzz

unread,

Mar 21, 2010, 1:23:33 PM3/21/10

to

On Sat, 20 Mar 2010 18:55:17 -0700 (PDT), a7yvm1...@netzero.com wrote:

>On Mar 20, 8:23 pm, "k...@att.bizzzzzzzzzzzz"
><k...@att.bizzzzzzzzzzzz> wrote:
>> On Sat, 20 Mar 2010 17:28:11 -0700 (PDT), whit3rd <whit...@gmail.com> 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. IEEE-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.
>>
>> Nonsense. You could attach anything you wanted to them. The parallel 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 only)
so it was not easily possible to feed data in to the computer. However, a
workaround was possible by using 4 of the 5 status lines. A circuit could be
constructed to split each 8-bit byte into two 4-bit nibbles which were fed
in sequentially through the status lines. Each pair of nibbles was then
re-combined into an 8-bit byte. This same method (with the splitting and
recombining done in software) was also used to transfer data between PCs
using a laplink cable.

i.e. bidirectional.

The 8255 *was* bidirectional.

>>
>> >Bus, from 'omnibus' meaning 'for everyone' implies that all
>> >bus signals are served by all devices, not just two.
>>
>> ALL devices? My PCI bus doesn't serve my memory. You're just making things
>> up now.
>So are you.

IKWYABWAI is just SUCH a convincing argument. What a maroon!

Phil Hobbs

unread,

Mar 21, 2010, 2:15:08 PM3/21/10

to

On 3/20/2010 9:23 PM, k...@att.bizzzzzzzzzzzz wrote:
> On Sat, 20 Mar 2010 17:28:11 -0700 (PDT), whit3rd<whi...@gmail.com> 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. IEEE-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.
>
> Nonsense. You could attach anything you wanted to them. The parallel port on
> the PC has always been bidirectional.
>

No. It originated with the Monochrome Display/Parallel Port card for
the PC, which was hardwired at I/O address 0x3bc. (Later versions had
jumpers so you could move it to 0x378). It could be modded to run
bidirectionally--I've done several--but it was unidirectional to start
with. Later parallel port hardware, especially mobo parallel ports,
usually used 0x378 or 0x278 (originally LPT2: and LPT3) to avoid
conflicts with the monochrome/parallel card.

The old LapLink parallel file sharing software used the data lines to
talk in one direction and the control lines in the other.

Cheers

Phil Hobbs

>> Bus, from 'omnibus' meaning 'for everyone' implies that all
>> bus signals are served by all devices, not just two.
>
> ALL devices? My PCI bus doesn't serve my memory. You're just making things
> up now.

--
Dr Philip C D Hobbs
Principal
ElectroOptical Innovations
55 Orchard Rd
Briarcliff Manor NY 10510
845-480-2058
hobbs at electrooptical dot net
http://electrooptical.net

Grant

unread,

Mar 21, 2010, 5:36:49 PM3/21/10

to

The PC-AT in '84 was bidirectional in the sense that there was a '245
or like to read output data pins, but no output disable on the on the
output data latch/driver. I had the PC-AT technical manual with
circuits, been a while since I read it though.

So if you wrote all ones to port, you could read 8 bit input, providing
external device was TTL logic that sinks many times the high level output
current. IOW, TTL can be active low wire ORed. The nybble r/w method
is far more reliable for any type of parallel port.

Grant.

Tim Williams

unread,

Mar 21, 2010, 6:04:49 PM3/21/10

to

<k...@att.bizzzzzzzzzzzz> wrote in message
news:3clcq552ic5jonnru...@4ax.com...

>>> Nonsense. You could attach anything you wanted to them. The parallel
>>> 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
> only)
> so it was not easily possible to feed data in to the computer.

Duh: the data lines were not bidirectional.

I do not know of any other definition of "bidirectional" which allows
different unidirectional wires to count as bidirectional. Bidirectional
means two directions on the same wire (and in terms of implementation,
usually two directions on the same port address, which certainly isn't true
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
unidirectional.

k...@att.bizzzzzzzzzzzz

unread,

Mar 21, 2010, 7:14:01 PM3/21/10

to

On Sun, 21 Mar 2010 17:04:49 -0500, "Tim Williams" <tmor...@charter.net>
wrote:

><k...@att.bizzzzzzzzzzzz> wrote in message
>news:3clcq552ic5jonnru...@4ax.com...
>>>> Nonsense. You could attach anything you wanted to them. The parallel
>>>> 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
>> 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
2 Data0 In/Out Data-0
3 Data1 In/Out Data-1
4 Data2 In/Out Data-2
5 Data3 In/Out Data-3
6 Data4 In/Out Data-4
7 Data5 In/Out Data-5
8 Data6 In/Out Data-6
9 Data7 In/Out Data-7
10 nAck In Status-6
11 Busy In Status-7
12 Paper-Out In Status-5
13 Select In Status-4
14 Linefeed Out Control-1
15 nError In Status-3
16 nInitialize Out Control-2
17 nSelect Out Control-3
18-25 Ground

Robert Baer

unread,

Mar 22, 2010, 3:40:56 PM3/22/10

to

Well, include me as one of those crotchety old farts that did the mod
_without_ the use of a dremel tool (am a bit sneaky at times, then being
a new dog at old tricks).
The hardware was there, only a slight improvement was needed...

Robert Baer

unread,

Mar 22, 2010, 3:48:18 PM3/22/10

to

Nope; IBM Technical Reference Manual, First Edition, August 1981 on
page D-34 clearly shows a LS374 for data out, and a LS244 for data in.

TerryKing

unread,

Mar 22, 2010, 3:51:59 AM3/22/10

to

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...

MooseFET

unread,

Mar 22, 2010, 9:32:31 AM3/22/10

to

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

JosephKK

unread,

Mar 25, 2010, 1:58:37 AM3/25/10

to

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

>On Sat, 20 Mar 2010 10:38:44 -0500, Jamie
><jamie_ka1lpa_not_v...@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.

JosephKK

unread,

Mar 25, 2010, 2:01:33 AM3/25/10

to

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

JosephKK

unread,

Mar 25, 2010, 2:07:19 AM3/25/10

upsid...@downunder.com

unread,

Dec 3, 2016, 5:47:53 AM12/3/16

to

On Fri, 02 Dec 2016 21:49:24 -0800, Robert Baer
<rober...@localnet.com> wrote:

>ljnor...@gmail.com wrote:
>> How about one fiboroptic bus with photonic logic processor made out of etched glass? I like the UPB idea,
>> but I think the future of computing will be computers that contain optics and LED's.

One problem with high speed parallel connections is the need to keep
the path lengths exactly the same for each connection to be able to
direct sample full words. At high speeds, you need to use some self
clocking on each wire and after clock skew elimination to build a full
word.

The device complexity is similar as multiple serial connections
bundled together. You could as well send serially all bits of a word
on one wire, the nest word on the next wire etc.

> Optics, yes. Sure and hell NOT parallel bus unless one manages to
>wavelength multiplex 8, 16 or 32 channels.

CWDM would be attractive, but would need lasers.

What is the propagation spread on different wavelengths for different
fiber types ? Would it be possible to sample each wavelength in
parallel or would some self clocking signal be needed for each lamda ?

> LEDs? are they not a bit slow?

The spectral purity would be an issue even for 2-4 lamda CWDM.

Robert Baer

unread,

Dec 4, 2016, 4:37:25 AM12/4/16

to

upsid...@downunder.com wrote:
> On Fri, 02 Dec 2016 21:49:24 -0800, Robert Baer
> <rober...@localnet.com> wrote:
>
>> ljnor...@gmail.com wrote:
>>> How about one fiboroptic bus with photonic logic processor made
>>> out of etched glass? I like the UPB idea, but I think the future
>>> of computing will be computers that contain optics and LED's.
>
> One problem with high speed parallel connections is the need to keep
> the path lengths exactly the same for each connection to be able to
> direct sample full words. At high speeds, you need to use some self
> clocking on each wire and after clock skew elimination to build a
> full word.
>
> The device complexity is similar as multiple serial connections
> bundled together. You could as well send serially all bits of a word
> on one wire, the nest word on the next wire etc.
>
>> Optics, yes. Sure and hell NOT parallel bus unless one manages to
>> wavelength multiplex 8, 16 or 32 channels.
>
> CWDM would be attractive, but would need lasers.

* Which are a bit faster than LEDs and so a better match to this concept.

>
> What is the propagation spread on different wavelengths for
> different fiber types ?

* a definite problem; a dumb solution is to have each channel "clocked"
at slow rate commensurate to guarantee clean recovery in all channels.

> Would it be possible to sample each wavelength in parallel or would
> some self clocking signal be needed for each lamda ?

* Self-clocking is possible for each channel, but the slowest one will
limit the overall data rate.

>
>> LEDs? are they not a bit slow?
>
> The spectral purity would be an issue even for 2-4 lamda CWDM.

* Well so far, this is just an idea, sort-of sci-fi.
Does not mean not possible or not practical.

>

jrwal...@gmail.com

unread,

Dec 5, 2016, 8:14:53 AM12/5/16

to

On Saturday, 3 December 2016 10:47:53 UTC, upsid...@downunder.com wrote:

> One problem with high speed parallel connections is the need to keep
> the path lengths exactly the same for each connection to be able to
> direct sample full words. At high speeds, you need to use some self
> clocking on each wire and after clock skew elimination to build a full
> word.

Even if the path lengths are exactly the same there is dispersion to
deal with. The propagation velocity is frequency dependent, so data-
dependent timing errors creep in.

Long ago I was involved in transmitting digital TV signals around a
building. To cut costs the designer tried using twisted pair
telephone wire with one bit per pair plus a clock pair. It was
impossible to get reliable operation at 50m range because of dispersion
no matter how much tweaking of timing delays was done.

John

upsid...@downunder.com

unread,

Dec 5, 2016, 2:38:55 PM12/5/16

to

This is a well known phenomenon.

While working with (physically) big computers in the 1970's in which
1/2 inch 9 track (8 data bits+(odd)parity was used). The 800 BPI (bits
per inch) drives were quite unreliable.

The assumption was that odd parity with 8 data bits would generate a
clean synch for all tracks.

Depending on the read head azimuth angle, this was seldom the case.

In reality, you had to manually adust the azimuth angle for each tape
written on a separate drive.

The 1600 BPI tapes were much better due to the chancel specific self
clocking encoding.

Robert Baer

unread,

Dec 5, 2016, 6:01:28 PM12/5/16

to

Which gives a good lesson of what not to do and what to look for.
So a UPB needs a relatively low dispersion data path and a clock rate
that is limited by frequency dependent issues.
If speed is of the essense, use of different wavelengths for each
channel would most likely limit total path length to an "impractical"
amount (ie design cost not worth t).
Still, a CPU board using light instead of wires/traces could be
designed that would "kick ass" for parallel, multi-processing.

unread,

Dec 6, 2016, 2:41:45 AM12/6/16

to

On 2016-12-06 00:01, Robert Baer wrote:
[...]

> Still, a CPU board using light instead of wires/traces could be
> designed that would "kick ass" for parallel, multi-processing.
>

Why? What advantage do you imagine that might have?

Jeroen Belleman

upsid...@downunder.com

unread,

Dec 6, 2016, 5:41:30 AM12/6/16

unread,

Dec 6, 2016, 10:26:45 AM12/6/16

to

On Tue, 6 Dec 2016 09:13:41 -0500, Phil Hobbs
<pcdhSpamM...@electrooptical.net> wrote:

>On 12/06/2016 05:55 AM, upsid...@downunder.com wrote:
>> On Tue, 6 Dec 2016 08:41:40 +0100, Jeroen Belleman
>> <jer...@nospam.please> wrote:
>>
>>> On 2016-12-06 00:01, Robert Baer wrote:
>>> [...]
>>>> Still, a CPU board using light instead of wires/traces could be
>>>> designed that would "kick ass" for parallel, multi-processing.
>>>>
>>>
>>> Why? What advantage do you imagine that might have?
>>
>> If you are building something similar to the Connection Machines
>> Hypercube computer, using CAT6 cabling would quickly consumes most of
>> the cube module volume.
>>
>> Using fiber optic cables with multiple fibers and using WDM on each
>> fiber will have a huge throughput for a specific cable volume. It
>> might even make possible direct connection between any two nodes in
>> the cube.
>
>WDM isn't too helpful in general except for long links, but fibre has
>been used inside large computers and data centers for yonks.

I was thinking about some rack size fiber loops with an add/drop
interface at each box or actually a drop/add fiber system.

What is the practical performance in some passive drop/add box along
the fiber loop ? Is it realistic to assume that the drop box will
attenuate the loop signal enough that a new signal could be inserted
into the loop ?

Phil Hobbs

unread,

Dec 6, 2016, 12:00:42 PM12/6/16

to

On 12/06/2016 10:26 AM, upsid...@downunder.com wrote:
> On Tue, 6 Dec 2016 09:13:41 -0500, Phil Hobbs
> <pcdhSpamM...@electrooptical.net> wrote:
>
>> On 12/06/2016 05:55 AM, upsid...@downunder.com wrote:
>>> On Tue, 6 Dec 2016 08:41:40 +0100, Jeroen Belleman
>>> <jer...@nospam.please> wrote:
>>>
>>>> On 2016-12-06 00:01, Robert Baer wrote:
>>>> [...]
>>>>> Still, a CPU board using light instead of wires/traces could be
>>>>> designed that would "kick ass" for parallel, multi-processing.
>>>>>
>>>>
>>>> Why? What advantage do you imagine that might have?
>>>
>>> If you are building something similar to the Connection Machines
>>> Hypercube computer, using CAT6 cabling would quickly consumes most of
>>> the cube module volume.
>>>
>>> Using fiber optic cables with multiple fibers and using WDM on each
>>> fiber will have a huge throughput for a specific cable volume. It
>>> might even make possible direct connection between any two nodes in
>>> the cube.
>>
>> WDM isn't too helpful in general except for long links, but fibre has
>> been used inside large computers and data centers for yonks.
>
> I was thinking about some rack size fiber loops with an add/drop
> interface at each box or actually a drop/add fiber system.

It limits your connectivity, and doesn't save that much space compared
with point-to-point links.

Also fibre within racks is all 850 nm multimode (orange sleeve), whereas
WDM is done at 1550 nm, single mode (yellow sleeve).

Cheers

Phil Hobbs

>
> What is the practical performance in some passive drop/add box along
> the fiber loop ? Is it realistic to assume that the drop box will
> attenuate the loop signal enough that a new signal could be inserted
> into the loop ?
>

krw

unread,

Dec 6, 2016, 8:16:05 PM12/6/16

to

On Tue, 06 Dec 2016 12:55:44 +0200, upsid...@downunder.com wrote:

>On Tue, 6 Dec 2016 08:41:40 +0100, Jeroen Belleman
><jer...@nospam.please> wrote:
>
>>On 2016-12-06 00:01, Robert Baer wrote:
>>[...]
>>> Still, a CPU board using light instead of wires/traces could be
>>> designed that would "kick ass" for parallel, multi-processing.
>>>
>>
>>Why? What advantage do you imagine that might have?
>
>If you are building something similar to the Connection Machines
>Hypercube computer, using CAT6 cabling would quickly consumes most of
>the cube module volume.

Use something like the TI or Max Video SerDes. One copper pair gets
>5Gb, for some distance.

muhammadi...@gmail.com

unread,

Feb 24, 2019, 10:08:14 PM2/24/19

to

Parallel was faster than serial, why isn't there an UPB - "Universal Parallel Bus"?

muhammadi...@gmail.com

unread,

Feb 24, 2019, 10:13:20 PM2/24/19

to

On Saturday, March 20, 2010 at 7:33:19 PM UTC+5, 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

but

k...@notreal.com

unread,

Feb 24, 2019, 10:14:23 PM2/24/19

to

On Sun, 24 Feb 2019 19:08:10 -0800 (PST),
muhammadi...@gmail.com wrote:

>Parallel was faster than serial, why isn't there an UPB - "Universal Parallel Bus"?

Because jitter, skew, and cost are bigger problems than bandwidth.

John Larkin

unread,

Feb 25, 2019, 12:15:17 AM2/25/19

to

On Sun, 24 Feb 2019 19:08:10 -0800 (PST),
muhammadi...@gmail.com wrote:

>Parallel was faster than serial, why isn't there an UPB - "Universal Parallel Bus"?

There was: ISA, and later PCI.

Given N wires or twisted pairs, each can carry a self-clocking data
stream, and that's generally faster than using those same wires for
parallel data.

That's why a PCI Express link with N pairs uses each lane for serial
data.

--

John Larkin Highland Technology, Inc

lunatic fringe electronics

unread,

Feb 25, 2019, 10:07:54 AM2/25/19

to

Yes. PCIe is (somewhat) adaptive to the number of functional pairs.
And any board from 1 to 16 lanes will work in a 1-lane socket.

Lasse Langwadt Christensen

unread,

Feb 25, 2019, 12:58:33 PM2/25/19

to

and afaiu many motherboard also support splitting the pairs between boards
so you can have two 8 lane cards in a 16 lane socket

jurb...@gmail.com

unread,

Feb 25, 2019, 3:13:57 PM2/25/19

to

>"A common fast parallel bus was the SCSI port for HDDs"

I got a 50 pin SCSI CD CHANGER that fits in a standard bay. How'd you like to have to design that ? (especially the LASER which obviously has to pass through all the holes in the disks under the one being read, shit, usually they can't focus if the spindle height is only about 1mm from where it belongs, usually caused by someone putting more than one disk in at the same time)

jurb...@gmail.com

unread,

Feb 25, 2019, 3:16:55 PM2/25/19

to

I just realized how old this thread is...

But now that I think of it, what about firewire ? It was supposed to be "all that" but seems to have gone the way of the betamax.

Clifford Heath

unread,

Feb 25, 2019, 9:23:11 PM2/25/19

to

On 25/2/19 10:35 pm, Uwe Bonnes wrote:
> John Larkin <jjla...@highlandtechnology.com> wrote:
>> On Sun, 24 Feb 2019 19:08:10 -0800 (PST),
>> muhammadi...@gmail.com wrote:
>>
>>> Parallel was faster than serial, why isn't there an UPB - "Universal
>>> Parallel Bus"?
>>
>> There was: ISA, and later PCI.
>>
>> Given N wires or twisted pairs, each can carry a self-clocking data
>> stream, and that's generally faster than using those same wires for
>> parallel data.
>>
>> That's why a PCI Express link with N pairs uses each lane for serial
>> data.
>>
>>
> How many cable pair uses USB3-x?

Billions, and they're shipping more all the time. :)

Oh, did you want to know how many cable pairs in one USB3 cable? :P