OSDev.org

jacks wrote:Hi all,

I'm developing an application for DOS. I need to communicate via parallel port.

Currently I'm stuck at how can I determine which of the PCI function's BAR(Base address registers) contain the base address(ie data port address) for that parallel port?

Precisely, is there a industry convention or standard or de-facto standard that a particular BAR will always contain the base address for that parallel port ?

If not, then how can I determine the base address for that PCI parallel port(whether on pci expansion card or integrated on mobo)?

Thanks

turdus wrote:

Since you're in real mode with BIOS support, you should simply read the base port from bios structures: http://pierrelib.pagesperso-orange.fr/h ... _Area.html
It's only one memory read instruction to get it, no need to use PCI BAR. Also read about how to communicate with the chip that keeps paralell port running: http://www.lvr.com/files/ibmlpt.txt

sounds wrote:What is the vendor and device ID of the card you are working with?

sounds wrote:How many parallel ports does it have? Even if you only intend to use 1 of them, to get the card to work you have to be aware of all of them.

The card probably also has serial ports. How many serial ports does it have? The same logic applies - to get the card to work you'll probably have to deal with them at least minimally.

• 1 port on BAR 3
• 1 port on BAR 2
• 1 port on BAR 0
• 2 ports, BAR 0 and 2
• 1 port on BAR 1
• 2 ports, BAR 1 and 3
• 1 port on BAR 4

sounds wrote: How will you know which BAR to use? I still think you have no other choice but to get the Vendor and Device IDs.

Owen wrote:Of course you can assign the base addresses before installing drivers. The BAR itself contains the size of the region...

Owen wrote:My bet is said card exposed the standard PCI parallel port class

puc.c wrote: * These devices could be (and some times are) described as
* communications/{serial,parallel}, etc. devices with known
* programming interfaces, but those programming interfaces (in
* particular the BAR assignments for devices, etc.) in fact are not
* particularly well defined.

Brynet-Inc wrote:OpenBSD has a driver for PCI com/lpt devices named puc(4) - "PCI Universal Communications", glue for attaching MI com(4) and lpt(4) drivers.

There doesn't appear to be an actual standard for this though, it just so happens that generalizations could be made due to similarities.. from a comment in OpenBSD's driver:

 
struct puc_device_description {
	u_int16_t	rval[4];           // 4 vendor(or device) ids ????
	u_int16_t	rmask[4];        // why mask?
	struct {
		u_char	type;
		u_char	bar;
		u_short	offset;
	}			ports[PUC_MAX_PORTS];
};

Owen wrote:If you looked at the list I linked to, you would have seen one of the subclass devices is "ECP 1.X parallel port"

I imagine that single port cards use this class; and dual port cards probably implement it twice as two features. I imagine it's the 3+ cards where there is lots of variation