[comp.sys.ibm.pc] Where is the paralell port???

rcj@killer.DALLAS.TX.US (Robert Johnson) (12/12/88)

Help!

   I need to know how to access the paralell port!  There are four pins on
the paralell port which can be made to send a continuos +5v current, and
I need to know which ones, and how to do it...Please help!

    Any replies will be appreciated,
                   Robert Johnson
                     ..!texsun!killer!rcj
                     rcj@killer.DALLAS.TX.US

P.S. I need to do this in order to control a motor via a relay circuit through
     the paralell port.

joss@uhura.cc.rochester.edu (Josh Sirota) (12/12/88)

In article <6393@killer.DALLAS.TX.US> rcj@killer.DALLAS.TX.US (Robert Johnson) writes:
>   I need to know how to access the paralell port!  There are four pins on
>the paralell port which can be made to send a continuos +5v current, and
>I need to know which ones, and how to do it...Please help!

The real question is this -- someone on this group last year told me where
in low memory to find the table that contains the base registers for each of
the three standard parallel ports.

I can tell this guy how to control the pins very easily once I know where
the base registers are ... in fact I've already done that.  40:40 rings a
bell, but I don't know why (and it's not right ... I looked there).

Josh
-- 
Josh Sirota
INTERNET: joss@uhura.cc.rochester.edu        BITNET: joss_ss@uordbv.bitnet
          sirota@cs.rochester.edu            UUCP: ...!rochester!sirota

jc58+@andrew.cmu.edu (Johnny J. Chin) (12/12/88)

I am not exactly sure which pin it is on the parallel port, but I do know
that if you have an IBM-to-CENTRONICS cable hooked up to it, the +5 volts
is on pin 35 of the Centronics connector.

Or at least that was what a PC-Technician told me.

I hope this gives you clue on where to look.

                                        -- J. Chin (a.k.a. Computer Dr.)
 xxxxxxxxxx
xxx  xxx  xx  ------------------ Carnegie Mellon University ------------------
xxx  xxx  xx  4730 Centre Ave. #412     ARPAnet: Johnny.J.Chin@andrew.cmu.edu
xxxxxxxxxxxx  Pittsburgh, PA  15213     BITnet:  jc58@andrew.BITNET
x xxxxxxxx x  (412) 268-8936            UUCP: ...!harvard!andrew.cmu.edu!jc58
xx        xx  ----------------------------------------------------------------
 xxxxxxxxxx   Smile!

Disclaimer:   The views expressed herein are STRICTLY my own, and not CMU's.

pete@octopus.UUCP (Pete Holzmann) (12/13/88)

The table of serial port addresses is at 40:0 (16 bits per port), but
should probably be ignored. Most software just assumes that COM1 is
3F8 (or whatever it is), etc.

The table of parallel port addresses is at 40:8. This table should NOT
be ignored. LPT1 is at whatever I/O address is stored in the 16 bits at
40:8, LPT2 at 40:0a, etc.

e.g.:

unsigned far *lpts = 0x00400008L;  /* Define a pointer to the LPT ports */

unsigned LPT1Base = lpts[0];


... or whatever you like to do...

Pete
-- 
  OOO   __| ___      Peter Holzmann, Octopus Enterprises
 OOOOOOO___/ _______ USPS: 19611 La Mar Court, Cupertino, CA 95014
  OOOOO \___/        UUCP: {hpda,pyramid}!octopus!pete
___| \_____          Phone: 408/996-7746

simon@ms.uky.edu (Simon Gales) (12/13/88)

In article <464@octopus.UUCP> pete@octopus.UUCP (Pete Holzmann) writes:
>be ignored. LPT1 is at whatever I/O address is stored in the 16 bits at
>40:8, LPT2 at 40:0a, etc.
>
>unsigned far *lpts = 0x00400008L;  /* Define a pointer to the LPT ports */
>unsigned LPT1Base = lpts[0];
>

should be:

unsigned far *lpts = 0x00000408L;  /* Addr = Segment * 16 + Offset */
unsigned Lpt1Base  = lpts[0];			

/--------------------------------------------------------------------------\
  Simon Gales@University of Ky         UUCP:   {rutgers, uunet}!ukma!simon 
                                       Arpa:   simon@ms.uky.edu 
  MaBell: (606) 263-2285/257-3597      BitNet: simon@UKMA.BITNET  
-- 
/--------------------------------------------------------------------------\
  Simon Gales@University of Ky         UUCP:   {rutgers, uunet}!ukma!simon 
                                       Arpa:   simon@ms.uky.edu 
  MaBell: (606) 263-2285/257-3597      BitNet: simon@UKMA.BITNET  

hollen@spot.megatek.uucp (Dion Hollenbeck) (12/14/88)

From article <10690@s.ms.uky.edu>, by simon@ms.uky.edu (Simon Gales):
> In article <464@octopus.UUCP> pete@octopus.UUCP (Pete Holzmann) writes:
>>be ignored. LPT1 is at whatever I/O address is stored in the 16 bits at
>>40:8, LPT2 at 40:0a, etc.
>>
>>unsigned far *lpts = 0x00400008L;  /* Define a pointer to the LPT ports */
>>unsigned LPT1Base = lpts[0];
>>
> 
> should be:
> 
> unsigned far *lpts = 0x00000408L;  /* Addr = Segment * 16 + Offset */
> unsigned Lpt1Base  = lpts[0];			
> 
WRONG, WRONG, WRONG.  The original poster was correct.  FAR or HUGE
pointers are stored by MSC and TURBO C as 16bits of segment and
16bits of offset, hence 0x0040:0008 make up the segment:offset
far pointer. 

	Dion Hollenbeck             (619) 455-5590 x2814
	Megatek Corporation, 9645 Scranton Road, San Diego, CA  92121

                                seismo!s3sun!megatek!hollen
                                ames!scubed/

kneller@cgl.ucsf.edu (Don Kneller) (12/14/88)

In article <424@megatek.UUCP> hollen@spot.megatek.uucp (Dion Hollenbeck) writes:
>> In article <464@octopus.UUCP> pete@octopus.UUCP (Pete Holzmann) writes:
>>>be ignored. LPT1 is at whatever I/O address is stored in the 16 bits at
>>>40:8, LPT2 at 40:0a, etc.
>>>
>>>unsigned far *lpts = 0x00400008L;  /* Define a pointer to the LPT ports */
>>>unsigned LPT1Base = lpts[0];
>>>
>> 
>FAR or HUGE >pointers are stored by MSC and TURBO C as 16bits of segment
>and 16bits of offset, hence 0x0040:0008 make up the segment:offset
>far pointer. 
>

Both MSC and TURBO C provide a relatively easy method of producing
far pointers without you having to know the internal details of
how the pointers are broken down.  For example, with MSC you can
build the above pointer with:

#include <dos.h>

	FP_SEG(lpts) = 0x0040;
	FP_OFF(lpts) = 0x0008;

I don't know the syntax for TURBO, but they have a "make_far_ptr"
macro which takes a segment and offset and does the bite-twiddling
for you.  Using these macros is much more transparent (i.e. "better
programming style") than hard coding the internal representation
of far pointers into the constant.
-----
	Don Kneller
UUCP:		...ucbvax!ucsfcgl!kneller
INTERNET:	kneller@cgl.ucsf.edu
BITNET:		kneller@ucsfcgl.BITNET