OT: DOS programming EPP

There are lots of sites with info on programming Parallel port. here is just one.

I also found the "Extended Capabilities Port Protocol and ISA Interface Standard" on microsoft site.

The formal definition of EPP port is, I believe, an IEEE publication, that you can buy, however, to get an idea of the electrical aspects of the port, I suggest simply finding out what the popular driver chips are that are used in Intel PCs... and hence find the particular specs you're interested in. (eg max I/O current of these chips).

Im currently using a EPP to emulate a minimal ISA bus for a "WinRadio".

You dont mention what you mean by programming "..in DOS"... windows? old MS DOS? (IE via DOS driver) OR direect to port? Win / DOS drivers are aimed at printers, so sometimes make it harder than simply writing your own driver.

Good luck Dave M.

I thank you for the references and will check them out. Like i said, the parallel port is implimented in an ASIC and so there are *no* "driver chips" period. I am going to use "real" DOS; any version from 1.0 to 7.1 will work for what i need as the program will read and write diretly to the port.

*($%@#%!$% Microsoft, seems that their "search" function does not work with Netscape. Would you be so kind as to provide the Knowledge Base number?

More m$ BS...when using an "approved" browser, the search in the KB for "Extended Capabilities Port Protocol and ISA Interface Standard" yields two "results": something about ISDN and something about Win2K SP4...obviously perfect hits!!!!!!!!!

Go back to the beyond logic page and read the parallel port FAQ from the beginning. The EPP page assumes you did. You need to set up the extended control register (BASE + 0x400). In EPP mode Strobe is the WRITE/NOT READ bit and an output. I think you need to do some C or BASIC code to do any of this. I don't think you can just use DOS shell commands.

Paul C

Coming into this thread late but I've set the parallel port on my PC to different modes through the BIOS.

Robert

Okay, but then what do you do with it? I've always written C programs using inportb and outportb to read and write from the parallel port. I guess print will write a file to the port, but is there a command to read a file in?

Paul C

Not that I'm aware of. Some are bidirectional and some get their inputs from the control lines which can be read in.

See:

and others for details.

Robert

PaulCsouls wrote:

I said *NOTHING* about DOS shell commands! What follows is a listing of a BASIC program that i have used for preliminary investigation (use monospacing font width 90):

' Attempt to read data from parallel port using EPP protocol DEFINT A-Z PRNT = &H378 DATAs = PRNT + 0: STATUS = PRNT + 1: CONTROL = PRNT + 2 'SPP ' ^--r/w ^--read only ^--r/w (from IBM) ADDRESSrw = PRNT + 3: DATArw = PRNT + 4 'EPP ' ^--pin 17 pulse* ^--pin 14 pulse* *=if only one used BIT5 = &H20: PIN17 = &H8 ' The following pins (as output) must be high: ' Address Strobe=pin 17, Data Strobe=pin 14, Write=pin 1, Reset=pin 16. ' NOTE: After system boot, all pins default high except data pins and pin 17. ' CONTROL bit 5 defaults low.

CLS LOCATE 1, 1 PRINT " First read STATUS bits (cannot write them) meas OK? init" SEN = INP(STATUS) PRINT "D0:"; (SEN AND &H1)/&H1, "ghost Pin 01 /STROBE (reads inverted) 1 N 0" PRINT "D1:"; (SEN AND &H2)/&H2, "ghost Pin 14 /AUTO FD (reads inverted) 1 N 1" PRINT "D2:"; (SEN AND &H4)/&H4, "ghost Pin 16 /INIT 1 Y 1" PRINT "D3:"; (SEN AND &H8)/&H8, "Pin 15 /ERROR 1 Y 1" PRINT "D4:"; (SEN AND &H10)/&H10, "Pin 13 SLCT (from printer) 1 Y 1" PRINT "D5:"; (SEN AND &H20)/&H20, "Pin 12 PE (reads inverted) 1 Y 1" PRINT "D6:"; (SEN AND &H40)/&H40, "Pin 10 /ACK (reads inverted) 1 Y 1" PRINT "D7:"; (SEN AND &H80)/&H80, "Pin 11 BUSY (reads inverted) 1 Y 0" PRINT " Then read CONTROL bits" CTL = INP(CONTROL) PRINT "D0:"; (CTL AND &H1)/&H1, "Pin 01 /STROBE (reads inverted) 1 Y 0" PRINT "D1:"; (CTL AND &H2)/&H2, "Pin 14 /AUTO FD (reads inverted) 1 Y 0" PRINT "D2:"; (CTL AND &H4)/&H4, "Pin 16 /INIT 1 Y 1" PRINT "D3:"; (CTL AND &H8)/&H8, "Pin 17 /SLCT IN (to printer) 0 N 1" PRINT "D4:"; (CTL AND &H10)/&H10, "no pin IRQ EN 0" PRINT "D5:"; (CTL AND &H20)/&H20, "no pin bidirectional (added for EPP) 0" PRINT "D6:"; (CTL AND &H40)/&H40, "ghost Pin 10 /ACK (reads inverted) 1 Y 1" PRINT "D7:"; (CTL AND &H80)/&H80, "ghost Pin 11 BUSY (reads inverted) 1 Y 1" PRINT " Read SPP data:"; HEX$(INP(DATAs)); ";"; PRINT " Read EPP address:"; HEX$(INP(ADDRESSrw)); ";"; PRINT " Read EPP data:"; HEX$(INP(DATArw)) PRINT "One can pulse pin 14 high by writing anything to EPP DATA port." PRINT "Setting bit 3 in CONTROL low makes pin 17 high. NCTL = CTL OR BIT5 'sets I/O bit WHILE INKEY$ = "" SOUND 2000, 1 FOR I = -32767 TO 32766 OUT CONTROL, NCTL 'output 1uSec pulses seen during pin 1 high pulse: OUT DATArw, &H0 ' high 2.3V@2.2K load from 0.08V low OUT DATArw, &HFF ' low 2.4V@2.2K load from 3.5V high NEXT I WEND PRINT "CONTROL PORT INIT:"; HEX$(CTL), "NOW:"; HEX$(INP(CONTROL)) OUT CONTROL, &HCC 'Does not completely reset... SYSTEM

****** It is obvious that the data port (pins 2-9) "wants" to be an input, but only when pin 1 is high. Also, *NO* pin seems to act like an input at *any* time. I am afraid of using a heavier load, as at all times all pins are active drivers (outputs) except perhaps during the "magic" time. I certainly do not want to damage my motherboard!

0" 1" 1" 1"

Y 1"

Y 1"

Y 1"

Y 0"

0" 0" 1" 1" 0" 0"

Y 1"

Y 1"

Okay, sorry for confusion. This helps alot. The beyond logic page says

there possibly be to set up?

Data and Address Ports, the port must

nAddress Strobe, nData Strobe, nWrite

before starting any EPP Cycle. Therefore

Registers. Writing XXXX0100 to the control port will do this.

Write cycle cannot be performed. Therefore it is also wise

Bit 5 of the Control Register should result in an more enjoyable

EPP port may not function correctly. A common scenario

should be cleared for reliable operation, and constantly checked.

I don't see you doing this.You don't write xxxx0100 to the control port and you're setting bit 5 when you should be clearing it. Bit 5 sets the direction of the port. EPP wants it forward to start. During operation, you don't need to set the direction of the port. Just read/write to the address(BASE+3) and date (BASE+4) and the EPP takes care of the handshaking and direction. I have a schematic somewhere. I believe I just used the address strobe for the ALE (address latch enable) and the Data strobe for the output enable of my registers. Then NAND the data strobe and address strobe to create the WAIT signal with maybe a couple of more gates to delay it. Then just hang what you want to control on the registers.

The inputs and outputs of IEEE-1284 are defined.

I hope this helps.

Paul C

I found this program for testing 16 bit addressing. I used one of the control bits for an upper byte/lower byte switch. It works.

Paul C

This way of programming was used by the old "standard" printer interface. Every change of every bit was done in software. (Either the BIOS or another driver but nevertheless.) Using EPP mode, some things are taken over by hardware and you can't even write all the bits without meshing things up. You've to stick on writing the registers according to the specs. (see Beyond Logic: Programmming the EPP port). Data- and address strobes, direction and that things are done by the hardware.

As for the load, FAIK all parallel printer ports still support the old "Centronics" interface. Even the elderly printer I have from those days, an Epson FX100, runs from the parallel port of my latest Pentium 4 mobo. The hardware of that interfaces was build using LS-TTL so you will be on the safe side staying within the LS-TTL specs.

Besides, some extra precautions will be worthwhile:

- Don't use the mobos but a printer interface card. At least as long as you're experimenting.

- Always use buffers between de actual circuit and the printer port.

- Don'n plug in the (printer)cable at random while the PC is running. Still printerportconnections need to be made or broken while power down.

petrus bitbyter

0" 1" 1" 1"

Y 1"

Y 1"

Y 1"

Y 0"

0" 0" 1" 1" 0" 0"

Y 1"

Y 1"

there possibly be to set up?

Data and Address Ports, the port must

nAddress Strobe, nData Strobe, nWrite

before starting any EPP Cycle. Therefore

Registers. Writing XXXX0100 to the control port will do this.

Write cycle cannot be performed. Therefore it is also wise

Bit 5 of the Control Register should result in an more enjoyable

EPP port may not function correctly. A common scenario

should be cleared for reliable operation, and constantly checked.

If you look at the documentation in the program, you will note that bit 5 *is* clear by default. For the time being, let us ignore all of the folderol; DC source and DC sink measurements show me that any pin acting as an output has the characteristic of a low power TTL totempole driver.

Refer to the "infinite" loop in the program. Using a scope triggered from pin 1 and looking at any data pin, if i load that pin with 2.2K, i see that the data pin is not in output mode

*only* when CONTROL Bit5 is high (lasts only one microsecond). Furthermore, and most disturbing, the data pin is not in an input mode that is realistic - not even if one assumes it is emulating a *high power TTL* input! It is worse!

Seems to me that my MB is moused and so is useless for EPP. What i am going to do is go back to an old computer, dig out a spare parallel card, re-wire the CONTROL decoder so that Bit5 drives the OE pin of the LS374 data latch. That will make the card electrically and programmatically compatible with the EPP protocol; one just has to do the work in software instead of having it done "automatically".

"C" and i do not get along with each other. Firstly, the last time i looked, the printer port was 8 bits = a byte, so why fiddle with 16 bits? Secondly, i do not see what the program is attempting to do; please do not attempt to explain.

I followed the guides specified, and after a lot of fiddling, discovered what i documented in the program. Yes, i was able to determine that an output pin has the characteristics of a low power TTL driver (measured output voltage when low and sinking 2mA as well as when high and sourcing 2mA). And (like i mentioned elsewhere in this thread) when a pin is not in an output mode, it acts worse than the input of a high power TTL input (and that lasts only for a microsecond, only for the microsecond when CONTROL Bit5 is high). I am giving up, as it seems this MB is hosed; going to an old machine and be discreet about the logic, be backwards and shun integration of logic.

Control Bit5 high sets the data port to high-impedance mode, supporting 8-bit input (where this is implemented in the hardware). If you DON'T get a high-Z characteristic, it isn't implemented.

I'm not sure I followed why your C5 is high for only a microsecond - was that your code?

Be aware also that although the Status port input lines are TTL (and the Data port when in output mode), the Control port lines are open collector outputs.

Again, I'm not sure whether you issue is with the hardware or your software implementation.

The BIOS allows one to set SPP, EPP or ECP modes, so one would expect that all of those modes to be implimented. The manual for the MB states "SPP/EPP/ECP mode compliant parallel port".

*Only* when the program forces Bit5 does the data lines "get away" from being an output; one might say it "wants" to be an input, but a 2.2K resistor to ground pulls the line to 2.4V during that time. I see one microsecond of that operation using a scope, and the rest of the time (in the loop) the data lines are outputting whatever i write/wrote to them. Since the code is in BASIC and running p-code, it is fairly fast, and one microsecond is not out of line.

Yes, certain pins are *supposed* to be inputs, even in SPP mode, buy i do not read that. At any time that any given pin is "supposed" to be an input (any mode that you wish to talk about, any programming scheme you wish to use), it acts crappy: i read 2.4V with a 2.2K load to ground. Hence the following statement.

No matter what i do in software, i get this garbage response, and so that means the hardware is totally useless for my purposes. At least it still runs my old impact printer.

which certainly suggests that you can select from all of those three modes.

Your program should write a 1 to C5 whenever you want to do input. It's not a case of strobing C5, you must maintain that 1 continuously.

But why is your code only putting a transient 1 on C5? See above.

It may be.

In my case I use a paralle port in SPP mode for extensive I/O (programming a specialised EPROM programmer I designed) and I haven't had any problems relating to port behaviour. Outputs all act like TTL outputs, and inputs like TTL inputs. Be also aware that output pins 1/C0, 14/C1 and 16/C2 are inverted, as is input 11/S7.

Until I understand why you are only getting a ~1uS high on C5, I wouldn't be junking the mobo.

relating

In any program one can only read a port or write a port at a given time; it is impossible to do both. If the hardware is supposed to latch the Control bytes, then all i can say, it does not happen in my MB. Either the instruction that writes the one lasts a few tens of nanoseconds and the hardware timeout makes it go to zero in about one microsecond, OR the instruction writes for a whole microsecond; it is imposible to tell without experimenting with assembly code. Since no pins want to act like any decent inout at any time under any condition, it is not worth my time to do any more. I will keep the MB since it does work with the old printers i have. And am in the process of getting some old discrete TTL parallel interface cards for an old computer.