Maker Pro
Maker Pro

send more than 8 bits with parallel port

We're using a parallel port for motion control. We're building the
hardware logic for the device we're going to control, and want to be
able to send a packet containing 2 bytes of information, and let the
circuit we build translate it and drive our device.
I know that parallel port was designed with a standard for printers,
using a 1 byte data regisiter. What I want to know is how to hack it
so that I can use more than pins 2-9 to output data from our computer.
The control register has pins 1, 14, 16, 17. I take it that i can set
whatever I want to these (TTL), and on the device end, translate it
however I choose. So i need 4 more pins from something.
I know that pins 18-25 are ground. I think that makes them out of the
question, though if anyone knows how I could use some of them to
transmit data I'd be interested.
The info i have on status register says its read only, and that data
written there is ignored. What ignores it, the computer or the
printer? Is there a way to get around it?

thanks
James
 
J

Jonathan Kirwan

Jan 1, 1970
0
We're using a parallel port for motion control. We're building the
hardware logic for the device we're going to control, and want to be
able to send a packet containing 2 bytes of information, and let the
circuit we build translate it and drive our device.
I know that parallel port was designed with a standard for printers,
using a 1 byte data regisiter. What I want to know is how to hack it
so that I can use more than pins 2-9 to output data from our computer.
The control register has pins 1, 14, 16, 17. I take it that i can set
whatever I want to these (TTL), and on the device end, translate it
however I choose. So i need 4 more pins from something.
I know that pins 18-25 are ground. I think that makes them out of the
question, though if anyone knows how I could use some of them to
transmit data I'd be interested.
The info i have on status register says its read only, and that data
written there is ignored. What ignores it, the computer or the
printer? Is there a way to get around it?

What's wrong with latching two bytes, sequentially? I assume you can
write software to handle that. Or using a serial to parallel chain
and driving that synchronous-serial using the parallel port? There
are actually some 4-bit wide chips often used (in olden days, anyway)
when there was only an 8-bit wide path to parse. But with the PC
parallel port you are in high cotton. You can use the 8255, if you
want. You can hook up to /RD /WR A0 A1 and with a tiny bit of logic
you can use /RD and /WR in combo to generate the /CS and RESET, as
well. That gives you 24 bits to play with, I think.

Jon
 
S

Si Ballenger

Jan 1, 1970
0
We're using a parallel port for motion control. We're building the
hardware logic for the device we're going to control, and want to be
able to send a packet containing 2 bytes of information, and let the
circuit we build translate it and drive our device.
I know that parallel port was designed with a standard for printers,
using a 1 byte data regisiter. What I want to know is how to hack it
so that I can use more than pins 2-9 to output data from our computer.
The control register has pins 1, 14, 16, 17. I take it that i can set
whatever I want to these (TTL), and on the device end, translate it
however I choose. So i need 4 more pins from something.
I know that pins 18-25 are ground. I think that makes them out of the
question, though if anyone knows how I could use some of them to
transmit data I'd be interested.
The info i have on status register says its read only, and that data
written there is ignored. What ignores it, the computer or the
printer? Is there a way to get around it?

It is a hardware issue, as there is no internal way to change the
voltage on the pins. You usually can control the control pins
like the data pins. I've got some simple parallel port stuff on
the below pages that might be of interest.

http://www.geocities.com/zoomkat/status.htm
http://www.geocities.com/zoomkat/output.htm
http://www.geocities.com/zoomkat/ppswitcher3.htm
 
C

Chris

Jan 1, 1970
0
Jonathan said:
What's wrong with latching two bytes, sequentially? I assume you can
write software to handle that. Or using a serial to parallel chain
and driving that synchronous-serial using the parallel port? There
are actually some 4-bit wide chips often used (in olden days, anyway)
when there was only an 8-bit wide path to parse. But with the PC
parallel port you are in high cotton. You can use the 8255, if you
want. You can hook up to /RD /WR A0 A1 and with a tiny bit of logic
you can use /RD and /WR in combo to generate the /CS and RESET, as
well. That gives you 24 bits to play with, I think.

Jon

Jon has given most of the easy ones. I've used his second solution
many times, with two 74HCT595 serial-to-parallel shift registers. By
using serial-in-parallel-out (SIPO) shift tegisters, you only need 5
parallel port pins for any number of outputs. It should only take
several of microseconds to shift out the data for 16 bits in assembler,
and even in a high-level language, it should be far faster than your
time requirements for real time motion control.

http://www.onsemi.com/pub/Collateral/MC74HC595A-D.PDF

It's a 16-pin IC, available for less than a buck each in single
quantities, and the wiring and control logic is pretty much
self-evident if you read the data sheet.

You get 8 more outputs with every '595 chip you daisy chain, without
adding any more parallel port pins. You can realistically have just
about as many outputs as you want with those 5 pins, limited only by
the time you have to shift out the data. Remember you'll need an
external 5V power source for the '595s, or you can use power from the
PC (drive power cable extender).

Good luck
Chris
 
B

Bob

Jan 1, 1970
0
We're using a parallel port for motion control. We're building the
hardware logic for the device we're going to control, and want to be
able to send a packet containing 2 bytes of information, and let the
circuit we build translate it and drive our device.
I know that parallel port was designed with a standard for printers,
using a 1 byte data regisiter. What I want to know is how to hack it
so that I can use more than pins 2-9 to output data from our computer.
The control register has pins 1, 14, 16, 17. I take it that i can set
whatever I want to these (TTL), and on the device end, translate it
however I choose. So i need 4 more pins from something.
I know that pins 18-25 are ground. I think that makes them out of the
question, though if anyone knows how I could use some of them to
transmit data I'd be interested.
The info i have on status register says its read only, and that data
written there is ignored. What ignores it, the computer or the
printer? Is there a way to get around it?

thanks
James

One issue is that you need to indicate, to the receiving hardware, where the
first part of the word is. If you truly have only eight bits at-a-time, you
can dedicate one of the bits as the start-of-frame indicator, and use the
other seven as the data path. If you use this technique, then it's probably
simplest to send four data bits per transfer, and do four transfers to get
each sixteen bit word.

If it turns out that you can find an extra bit, then it can be become your
start-of-frame indicator.

A CPLD would be an ideal candidate for the receiving hardware (and they're
cheap). You just need to learn and little HDL (either VHDL or Verilog).

Remember, all sorts of data paths use only one bit at-a-time to send all
kinds of data types (widths), so having eight bits is a real luxury.

Bob
 
P

petrus bitbyter

Jan 1, 1970
0
We're using a parallel port for motion control. We're building the
hardware logic for the device we're going to control, and want to be
able to send a packet containing 2 bytes of information, and let the
circuit we build translate it and drive our device.
I know that parallel port was designed with a standard for printers,
using a 1 byte data regisiter. What I want to know is how to hack it
so that I can use more than pins 2-9 to output data from our computer.
The control register has pins 1, 14, 16, 17. I take it that i can set
whatever I want to these (TTL), and on the device end, translate it
however I choose. So i need 4 more pins from something.
I know that pins 18-25 are ground. I think that makes them out of the
question, though if anyone knows how I could use some of them to
transmit data I'd be interested.
The info i have on status register says its read only, and that data
written there is ignored. What ignores it, the computer or the
printer? Is there a way to get around it?

thanks
James

James,

You'd better first learn more about programming the paralllel printer port.
For instance:
http://www.beyondlogic.org/
It should be clear that even the last ECP is not able to transfer 16 bits at
a time. But there's no need to. If you check out the EPP specification
you'll find that you can send two bytes sequentially, one data and one
address, and latch each of them into its own LS163, LS364 or similar.

petrus bitbyter
 
B

Bob Masta

Jan 1, 1970
0
We're using a parallel port for motion control. We're building the
hardware logic for the device we're going to control, and want to be
able to send a packet containing 2 bytes of information, and let the
circuit we build translate it and drive our device.
I know that parallel port was designed with a standard for printers,
using a 1 byte data regisiter. What I want to know is how to hack it
so that I can use more than pins 2-9 to output data from our computer.
The control register has pins 1, 14, 16, 17. I take it that i can set
whatever I want to these (TTL), and on the device end, translate it
however I choose. So i need 4 more pins from something.
I know that pins 18-25 are ground. I think that makes them out of the
question, though if anyone knows how I could use some of them to
transmit data I'd be interested.
The info i have on status register says its read only, and that data
written there is ignored. What ignores it, the computer or the
printer? Is there a way to get around it?

thanks
James

Others have answered the hardware aspect of your
question. However, note that if you plan to use this
on PCs running Windows versions later than 9x,
you will have to use a special ring 0 device driver to have
access to the printer port. (GIVEIO and USERPORT are
two that I have heard of, put haven't tried myself.)
That might be one advantage for using the serial
port, which can be accessed through more-or-less
standard Windows API functions.

Another thing to think about is that parallel printer ports
are rumored to be slated for extinction... but then again,
aren't we all!

Best regards,



Bob Masta
dqatechATdaqartaDOTcom

D A Q A R T A
Data AcQuisition And Real-Time Analysis
www.daqarta.com
Home of DaqGen, the FREEWARE signal generator
 
J

Jonathan Kirwan

Jan 1, 1970
0
Others have answered the hardware aspect of your
question. However, note that if you plan to use this
on PCs running Windows versions later than 9x,
you will have to use a special ring 0 device driver to have
access to the printer port. (GIVEIO and USERPORT are
two that I have heard of, put haven't tried myself.)
That might be one advantage for using the serial
port, which can be accessed through more-or-less
standard Windows API functions.

Another thing to think about is that parallel printer ports
are rumored to be slated for extinction... but then again,
aren't we all!

You know? What bugs me about this very true point is that we are
losing all of the really good hobbyist interfaces for adapting a PC.
The ISA bus was really nice and not too complex for a serious hobbyist
to use, in adding boards. Gone now, or nearly so. Ever consider
trying to do a PCI card as a hobbyist? Reflection wave bus, 2ns clock
skew on 33MHz and 1ns clock skew on 66MHz with a 1.5" +/- 0.1" trace
length for the clock (often serpentined in order to get there), etc.
Just getting equipment to monitor the analog characteristics for
debugging a design is a fortune. Lose the parallel, lose the serial,
add USB 2.0, replace the old IDE controller cables with SATA 2, and
what are you left with to use, anymore? It's getting to be a pain in
the ...

Well, of course, there are microcontroller boards. But then you lose
out on the excellent and easy availability of very excellent and well
documented development tools.

Jon
 
C

Chris

Jan 1, 1970
0
Jonathan said:
You know? What bugs me about this very true point is that we are
losing all of the really good hobbyist interfaces for adapting a PC.
The ISA bus was really nice and not too complex for a serious hobbyist
to use, in adding boards. Gone now, or nearly so. Ever consider
trying to do a PCI card as a hobbyist? Reflection wave bus, 2ns clock
skew on 33MHz and 1ns clock skew on 66MHz with a 1.5" +/- 0.1" trace
length for the clock (often serpentined in order to get there), etc.
Just getting equipment to monitor the analog characteristics for
debugging a design is a fortune. Lose the parallel, lose the serial,
add USB 2.0, replace the old IDE controller cables with SATA 2, and
what are you left with to use, anymore? It's getting to be a pain in
the ...

Well, of course, there are microcontroller boards. But then you lose
out on the excellent and easy availability of very excellent and well
documented development tools.

Jon

Contrivers of contrivances are going to have a more difficult time when
the ol' parallel port is no more, Jon. Of course, we can squirrel away
more older PCs (that is, until the War Department issues the Ultimatum
again). I would guess, though, you'll be seeing more standardized USB
experimenter-type interfaces to replace the parallel port for classroom
and hobbyist work. You'll also see more use of PCI DIO type boards for
the parallel I/O. You will be seeing a lot less hobbyist bus
interface.

But it should still beat those "thrilling days of yesteryear" (early
'80s), when PCs cost thousands, you had to wait in line for one, and
you took your career in your hands every time you turned on the power
for a new prototype, consigning it as well as everything else in the
box and possibly your job to the tender(?) mercies of a harsh 85 watt
switching power supply.

I learned about the advantages of the trailing edge back then, picking
up cheapie Kaypro IIs for their serial and parallel ports as IBM and
Micro Soft (two words back then) cleaned Kaypro's and CP/M's clocks.
Everyone who wanted to replace VisiCalc with Lotus had their first
obsolete computer (aaaaww!), and after having it sit around unused for
a few months, was willing to practically give it away (for a couple
hundred dollars).

Those were the days. Womenfolk swooned as real engineers and techs
walked by, TI-57s bobbling suggestively from their belt loops. ;-)

Cheers
Chris
 
J

Jonathan Kirwan

Jan 1, 1970
0
Contrivers of contrivances are going to have a more difficult time when
the ol' parallel port is no more, Jon. Of course, we can squirrel away
more older PCs (that is, until the War Department issues the Ultimatum
again).

You should see my collection. I still multi-IO boards, floppy
interface boards, etc.
I would guess, though, you'll be seeing more standardized USB
experimenter-type interfaces to replace the parallel port for classroom
and hobbyist work.

That adds complexity that can be difficult to diagnose. But worse,
how do you arrange for precise timing control of I/O pins?? And under
Windows?!?!?! It's just not the same thing, you know.

Only a few years back, I developed software for aligning and
calibrating a medical infusion pump motor/cam system. I had to spin
the motor and monitor it in real time, because this is how the
alignment worked -- at operational speed, I had to see how the cam
alignment looked with respect to the optical quadrature encoder. It
was different, stopped or very slow, because of the cam follower's lag
as it ran. The quadrature encoder gave me 10,000 pulses per rev. And
I ran the motor at 50, 150, and 300 RPM. At 300, that's 5 revs per
second. And I was getting 50,000 pulses each second on A and B side
channels.

It was absolutely no problem on a modern CPU with an I/O card plugged
into the ISA. I sat in a tight loop and pulled out I/Os at 750ns
each. I coded the quadrature decoder in assembly.

Now?? What, with some USB thing?? How will I code that, in assembly,
under DOS?? And if I use Windows, what chance do I have?

No, this is a serious loss.
You'll also see more use of PCI DIO type boards for
the parallel I/O. You will be seeing a lot less hobbyist bus
interface.

Well, there is that. But you cannot build them yourself and PCI isn't
all that easy under DOS-only. I often need to completely remove
Windows when doing embedded PC instrumentation, as timing is crucial
to control and a lot of stuff I do is _fast_ and I require very tight
control over latencies. Under Windows, this is ... very difficult,
and will require VxD work to get there, if at all.

I've developed PCI testing software for Intel, while running a
multi-CPU O/S of my own development. We'd load up Xilinx-FPGA cards
with code so that we could literally fill up the PCI bus with dense
traffic and try and break the chipset with it.

I'm really not looking forward to using PCI for instrumentation. In
the case I earlier mentioned, about the testers, the customer is a
very large medical instrumentation builder but their need for testers
is perhaps a dozen or two systems. In some cases, I've actually done
systems where there were only two. They may, themselves, test a large
number of devices very quickly, but they are in effect one-off systems
-- custom for the need and don't represent large volume to anyone,
part-wise. Buying the boards won't mean much to the vendor, so
support won't be all that great. For PCI, they may not even bother
with a DOS-based PCI driver. And setting up the PCI board under DOS
may require my configuring all of the PCI boards, if I don't like the
BIOS defaults -- which the board maker may not even care about because
Windows is PNP-aware and they don't have to mess with it much.

That's assuming, of course, that I can find what I need in PCI. In
ISA, at least, I can do a board design and wire wrap it up on my own
and test it out. Then do a final board(s) for the customer that meets
the needs. PCI?? No way. I just don't have the equipment or the
knowledge, except that I know enough to watch out.
But it should still beat those "thrilling days of yesteryear" (early
'80s), when PCs cost thousands, you had to wait in line for one, and
you took your career in your hands every time you turned on the power
for a new prototype, consigning it as well as everything else in the
box and possibly your job to the tender(?) mercies of a harsh 85 watt
switching power supply.

What I'd like to do is be able to capitalize on modern low-cost
systems and still have access to low-development-cost interfacing for
small-run or one-off tester systems for customers or personal use.
There is no sense in taking on an expensive PCI design project for
what would otherwise merely be a simple, customized I/O board for
external instrument control. Think of chicken hatcheries, IC testers,
LED binning, etc. etc. Highly integrated, labor-intensive, one-off
systems with a lot of knowledge buried in them about the specific
requirements. ISA still makes sense for these, as even a custom logic
board is a no-brainer to do and test out. PCI raises the bar so high
that many of these projects would find their labor growing very
substantially for no good reason except the fact that ISA has
disappeared.
I learned about the advantages of the trailing edge back then, picking
up cheapie Kaypro IIs for their serial and parallel ports as IBM and
Micro Soft (two words back then) cleaned Kaypro's and CP/M's clocks.
Everyone who wanted to replace VisiCalc with Lotus had their first
obsolete computer (aaaaww!), and after having it sit around unused for
a few months, was willing to practically give it away (for a couple
hundred dollars).

Those were the days. Womenfolk swooned as real engineers and techs
walked by, TI-57s bobbling suggestively from their belt loops. ;-)

My first Kaypro was a 286i that I bought for about $3k, new. It was
the first PC-compatible on the market that was really PC-compatible
based on careful testing. The other systems would fail to even run PC
applications at least 10% of the time. More, often. But this one
would run everything I tried, out of the box. And was the only system
at the time, other than an IBM of course, that could.

I remember when visicalc first came out -- not on the PC, but I
believe on the Apple II, as the PC didn't exist then (early 1980, I
think, when I first saw it.) I laughed at it, because I thought
"who'd buy this?" It seemed way too technical to reach any popular
market and I figured programmers could just program the equations.

Oh, well. What do I know?

Jon
 
P

petrus bitbyter

Jan 1, 1970
0
Jonathan Kirwan said:
You should see my collection. I still multi-IO boards, floppy
interface boards, etc.


That adds complexity that can be difficult to diagnose. But worse,
how do you arrange for precise timing control of I/O pins?? And under
Windows?!?!?! It's just not the same thing, you know.

Only a few years back, I developed software for aligning and
calibrating a medical infusion pump motor/cam system. I had to spin
the motor and monitor it in real time, because this is how the
alignment worked -- at operational speed, I had to see how the cam
alignment looked with respect to the optical quadrature encoder. It
was different, stopped or very slow, because of the cam follower's lag
as it ran. The quadrature encoder gave me 10,000 pulses per rev. And
I ran the motor at 50, 150, and 300 RPM. At 300, that's 5 revs per
second. And I was getting 50,000 pulses each second on A and B side
channels.

It was absolutely no problem on a modern CPU with an I/O card plugged
into the ISA. I sat in a tight loop and pulled out I/Os at 750ns
each. I coded the quadrature decoder in assembly.

Now?? What, with some USB thing?? How will I code that, in assembly,
under DOS?? And if I use Windows, what chance do I have?

No, this is a serious loss.


Well, there is that. But you cannot build them yourself and PCI isn't
all that easy under DOS-only. I often need to completely remove
Windows when doing embedded PC instrumentation, as timing is crucial
to control and a lot of stuff I do is _fast_ and I require very tight
control over latencies. Under Windows, this is ... very difficult,
and will require VxD work to get there, if at all.

I've developed PCI testing software for Intel, while running a
multi-CPU O/S of my own development. We'd load up Xilinx-FPGA cards
with code so that we could literally fill up the PCI bus with dense
traffic and try and break the chipset with it.

I'm really not looking forward to using PCI for instrumentation. In
the case I earlier mentioned, about the testers, the customer is a
very large medical instrumentation builder but their need for testers
is perhaps a dozen or two systems. In some cases, I've actually done
systems where there were only two. They may, themselves, test a large
number of devices very quickly, but they are in effect one-off systems
-- custom for the need and don't represent large volume to anyone,
part-wise. Buying the boards won't mean much to the vendor, so
support won't be all that great. For PCI, they may not even bother
with a DOS-based PCI driver. And setting up the PCI board under DOS
may require my configuring all of the PCI boards, if I don't like the
BIOS defaults -- which the board maker may not even care about because
Windows is PNP-aware and they don't have to mess with it much.

That's assuming, of course, that I can find what I need in PCI. In
ISA, at least, I can do a board design and wire wrap it up on my own
and test it out. Then do a final board(s) for the customer that meets
the needs. PCI?? No way. I just don't have the equipment or the
knowledge, except that I know enough to watch out.


What I'd like to do is be able to capitalize on modern low-cost
systems and still have access to low-development-cost interfacing for
small-run or one-off tester systems for customers or personal use.
There is no sense in taking on an expensive PCI design project for
what would otherwise merely be a simple, customized I/O board for
external instrument control. Think of chicken hatcheries, IC testers,
LED binning, etc. etc. Highly integrated, labor-intensive, one-off
systems with a lot of knowledge buried in them about the specific
requirements. ISA still makes sense for these, as even a custom logic
board is a no-brainer to do and test out. PCI raises the bar so high
that many of these projects would find their labor growing very
substantially for no good reason except the fact that ISA has
disappeared.


My first Kaypro was a 286i that I bought for about $3k, new. It was
the first PC-compatible on the market that was really PC-compatible
based on careful testing. The other systems would fail to even run PC
applications at least 10% of the time. More, often. But this one
would run everything I tried, out of the box. And was the only system
at the time, other than an IBM of course, that could.

I remember when visicalc first came out -- not on the PC, but I
believe on the Apple II, as the PC didn't exist then (early 1980, I
think, when I first saw it.) I laughed at it, because I thought
"who'd buy this?" It seemed way too technical to reach any popular
market and I figured programmers could just program the equations.

Oh, well. What do I know?

Jon


Well,

You seem to be in good company Jon. Whoever said the world would need only a
couple of computers? Who said a PC would never require more then 640k
memory? Guess your bank account did not line up with the ones of that guys
:)

Still have some empty ISA boards laying around. Good chance they'll never be
used as such. Lack of ISA-slots in present-day machines. But don't be too
sad. The new interfaces give new opportunities as well. USB-interface chips
are almost as cheap as the TTL-buffers were in the old days. You'll sure
have to do little more work in those micros and maybe in the hardware but I
consider it a part of the fun. Besides it will be less easy to copy your
application. As for PCI I was told you can buy chips or even boards with the
PCI-part already implemented. Did not check out as I did not need it myself.
Still enough challenges in this crazy world. The times they were a changing
in that old days. They still are.

petrus bitbyter
 
M

Michael A. Terrell

Jan 1, 1970
0
Jonathan said:
You know? What bugs me about this very true point is that we are
losing all of the really good hobbyist interfaces for adapting a PC.
The ISA bus was really nice and not too complex for a serious hobbyist
to use, in adding boards. Gone now, or nearly so. Ever consider
trying to do a PCI card as a hobbyist? Reflection wave bus, 2ns clock
skew on 33MHz and 1ns clock skew on 66MHz with a 1.5" +/- 0.1" trace
length for the clock (often serpentined in order to get there), etc.
Just getting equipment to monitor the analog characteristics for
debugging a design is a fortune. Lose the parallel, lose the serial,
add USB 2.0, replace the old IDE controller cables with SATA 2, and
what are you left with to use, anymore? It's getting to be a pain in
the ...

Well, of course, there are microcontroller boards. But then you lose
out on the excellent and easy availability of very excellent and well
documented development tools.

Jon

PC-104 is just a reconfigured ISA bus and the cards stack rather than
plug into a motherboard. The last ones I worked with had a Cyrix 586
CPU, and were running embedded NT in the Microdyne/L3-com RCB2000
telemetry receiving system. I still have some of the data on the board
around here, somewhere.

--
Service to my country? Been there, Done that, and I've got my DD214 to
prove it.
Member of DAV #85.

Michael A. Terrell
Central Florida
 
J

Jonathan Kirwan

Jan 1, 1970
0
PC-104 is just a reconfigured ISA bus and the cards stack rather than
plug into a motherboard. The last ones I worked with had a Cyrix 586
CPU, and were running embedded NT in the Microdyne/L3-com RCB2000
telemetry receiving system. I still have some of the data on the board
around here, somewhere.

Yes. But I think the PC-104 is dying. As I understand it, from
talking with a few key manufacturers in that business, the ability to
secure PC-compatible CPUs _with_ the ability to provide PC-104
signaling isn't likely to survive many more years. They are meeting
(or were) to try and see if they could collectively (some of the
bigger ones, anyway) pony up for their own ASIC design to handle the
PC-104 bus, before the remaining suppliers stop making their parts.
But I fear this whole attempt will fail and they will be forced to use
PC-104+ only (PCI.)

I'm not privy to the whole picture, but here is about how I see it.

There were some CPU manufacturers who provided x86 CPUs with ISA
interfaces. But there are several pressures away from what remains of
these, if anything does. For one, customers are usually looking for
faster and faster CPUs, even in the PC-104 business. And faster CPUs
probably use the front side bus arrangement for the CPU, followed by a
chip that mediates between that and the PCI, followed by another chip
that mediates between the PCI and the ISA and has all kinds of
sideband channels back to the chip that handles the front side to PCI,
since ISA DMA transactions cannot be properly remapped as PCI
transactions and require "special support." No one wants to keep
making the PCI to ISA bridge for that mess -- except maybe the PC-104
folks. But they don't have the business level to keep those current
makers making those chips. And I don't think they have the steam
themselves to get into that business.

So it will go away, soon. I think.

Jon
 
J

John Jardine.

Jan 1, 1970
0
[...]
Yes. But I think the PC-104 is dying. As I understand it, from
talking with a few key manufacturers in that business, the ability to
secure PC-compatible CPUs _with_ the ability to provide PC-104
signaling isn't likely to survive many more years. They are meeting
(or were) to try and see if they could collectively (some of the
bigger ones, anyway) pony up for their own ASIC design to handle the
PC-104 bus, before the remaining suppliers stop making their parts.
But I fear this whole attempt will fail and they will be forced to use
PC-104+ only (PCI.)
[...]

Jon

Having also designed machine controllers based on PC's complete with the
"older" interfaces, I agree wholeheartedly on how a cheap PC, is (was)
capable of massively slashing project times and costs when used within an
industrial environment.
One 486/DOS/ISA/Powerbasic test/measuring system I designed 7 years ago has
been running 24/7/350. Impossible to conceive doing the same using TDM
windows c/w and bloatware.
Looked at PC104s but found them (very) expensive and limiting and agree
that they will die out in time. From a customers POV, a big no-no is the
PC104 has a "Look at me, I'm special equipment" aspect. If the kit fails
then another unit can't just be picked up locally for next to nothing.
I've had enough of busses. I'm out of here.
ISA/EISA/MCA/PCI/Express/AGP/USB/Claphamcommon,
It's just not worth the time and mental effort. Decided I'll only (can
only!) interface with the truly crap RS232, which I suspect will be around
long after the pityfully apalling USB, has been junked in favour of the
apalling Firewire.
Just finishing off on an industrial project which uses a number of these,
http://www.redlion.net/Products/HumanMachineInterface/OperatorInterface.html
Final deciding factor for it's use was direct byte control of the
RS232/RS485 ports (crazy world).
Who now cares about industrial technology?. In UK, focus is on 'supply of
services'. All they want from a PC is email and pretty pictures, yet for a
pittance they are handed a supercomputer.
john
 
J

Jonathan Kirwan

Jan 1, 1970
0
[...]
Yes. But I think the PC-104 is dying. As I understand it, from
talking with a few key manufacturers in that business, the ability to
secure PC-compatible CPUs _with_ the ability to provide PC-104
signaling isn't likely to survive many more years. They are meeting
(or were) to try and see if they could collectively (some of the
bigger ones, anyway) pony up for their own ASIC design to handle the
PC-104 bus, before the remaining suppliers stop making their parts.
But I fear this whole attempt will fail and they will be forced to use
PC-104+ only (PCI.)
[...]

Jon

Having also designed machine controllers based on PC's complete with the
"older" interfaces, I agree wholeheartedly on how a cheap PC, is (was)
capable of massively slashing project times and costs when used within an
industrial environment.
One 486/DOS/ISA/Powerbasic test/measuring system I designed 7 years ago has
been running 24/7/350. Impossible to conceive doing the same using TDM
windows c/w and bloatware.
Looked at PC104s but found them (very) expensive and limiting and agree
that they will die out in time. From a customers POV, a big no-no is the
PC104 has a "Look at me, I'm special equipment" aspect. If the kit fails
then another unit can't just be picked up locally for next to nothing.
I've had enough of busses. I'm out of here.
ISA/EISA/MCA/PCI/Express/AGP/USB/Claphamcommon,
It's just not worth the time and mental effort. Decided I'll only (can
only!) interface with the truly crap RS232, which I suspect will be around
long after the pityfully apalling USB, has been junked in favour of the
apalling Firewire.
Just finishing off on an industrial project which uses a number of these,
http://www.redlion.net/Products/HumanMachineInterface/OperatorInterface.html
Final deciding factor for it's use was direct byte control of the
RS232/RS485 ports (crazy world).
Who now cares about industrial technology?. In UK, focus is on 'supply of
services'. All they want from a PC is email and pretty pictures, yet for a
pittance they are handed a supercomputer.

Sounds like you and I are singing the same song. Even to your last
sentence, which rings with me.

Jon
 
Top