OT: EPP problems

I'm a bit lostbas to what this code is trying to do. Do you have a loopback connection on the port?

Also, why are you trying to read back from base address (&H378)+4?

Why dont you forget turnaround and time delays. Just try the simple test: set the post to high-Z and then read and display the bit values, and then progressively pull them up/down with a low value resistor while watching the displayed bit values.

If that doesn't work, you don't have a bidi-capable port.

Let us know the result.

And in answer to your question, yes I do conduct serious I/O through the LPT1: port on this and other PC's without interrupts, and all in QuickBasic.

Robert, Does the "EPP standard" actually claim that when pins are set to be an input, that it must be a standard TTL input - or that it cant be pulled high internally? ( I doubt it). I suspect whether pins are set as outputs or inputs, the inputs should work when driven by a single external standard TTL dirver, and when set as outputs, will work into a standard external TTL receiver. The actual in or out impedance probably varies between designs, and the presence of pull-up resistors regardless of in/out state is not surprising... in fact, it is standard practice for some interfaces, because it simplifies the external driver circuit, because it only needs to "pull the input" low using open-collector circuit.

Just make sure your external TTL driver can drive hi or lo through the

2.4KOhms.

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

ground."

I guess you did not read my post. I *said* that i tried to make lines an input, AND i said that there ain't no such thing as "high-Z"; 2.4K internal pullup to +5V is *NOT* "high-Z"!

All of the documentation, and the BIOS says EPP, *and* (like i said but you did not read), i tried other boards, including an ISA parallel board that supports SPP, EPP and ECP.

Well, then would you be so kind as to post the software, and the hardware interface?

As far as i know there is absolutely *NO* information concerning the V/I curves when a given pin is high or low or an "input". The info i am using is from what *was* disclosed by IBM in their Technical Reference Manual, First Edition (August 1981). When ASICs ("squashed bugs") came out (i think in the 486 and later), a number of changes were made and *not* disclosed. For example, CP/M equipment and the PCs all could read and write Deleted Records; that capability was used in databases for fillers between ordinary records - one had to tell the program at the start how much data one was going to expect in the future and how much was going to be entered "now". So of expected data was 10 times present data, one regular record would be created, and nine deleted records would be created as a set (for each one to be used), during the "formatting" process by the database program. That feature was removed in the ASIC hardware BIOS support for the

486 (maybe earlier, cannot say). So, if the CMOS process is used in these ASICs, the makers have to do something a bit special to emulate TTL for input and output.

The pullup i see is *inside* the ASIC. Many of the pins on the parallel port can be switched between "input" and output. Therefore, for pins that are nominally output (eg: 8 data lines), one

*must* be careful so as to not destroy the fragile ASIC by a short to ground (when the pin is an output high and the external driver is a low) OR a high current from the external driver as a high and the output as a low. Someone in their "explaination" of how EPP etc works, states one can short the pins to ground (does no good to point fingers).

In order to have a minimal low, the largest series protection resistor would be 420 ohms, which gives about the 0.8V maximum low defined for TTL. BUT since the "inputs" are not defined or described, one does not have a clue as to the threshold level (1.4V at 25C for TTL or 0.5*Vcc for old CMOS, or....), or if hysteresis is used.

And last time i posted, someone carped that i did not make BIT5 in the control register low - when it *defaults* low (making it high seems to disable data "input").

Almost all registers are read/write, and most of the pins (register driven, BTW) are read/write...and that is from the original IBM PC/XT

1981 schematics! Heck, one can take an old IBM PC parallel board and cut the ground trace to pin 1 of the LS374 Data Register and connect it to pin 15 of the LS174 Control Register, and BIT5 then could tri-state the Data Register (low=enable, hi=tri-state). The only loading on the board is from an LS244 for reading the data pins, and some 2.2nF caps.

I did read it, and it led me to one conclusion.

Either you're right and eveyone else is wrong, or ......

Didn't catch your answer to that.

set

I DID tell you what I believed you should try, and report back. You didn't do that.

Please tell us all why you are trying to read back from base address (&H378)+4.

This particular piece of hardware is a custom EPROM programmer for a particular client. An NDA prevents posting schematics or the substance of the code. As a result, much of the code has been omitted but enough remains to hopefully convey what is being done.

The "interface" comprises:

. the 8 data I/O lines (pins 2-9) directly connected to the data I/O lines on the EPROM carrier. (no buffers).

. the STROBE output (pin 1) directly drives 74HC logic.

. other outputs (pins 14, 16, 17) directly drive 74HC logic.

. inputs (pins 10, 12, 13, 15) directly driven by 74HC logic.

. pin 11 is unused.

This hardware has performed flawlessy on a variety of Pentium class machines with on-board LPT: ports.

The relevant parts of the code - which might seem cumbersome and inefficiently written - are at the end of this post.

You will note the calls to SETHIZ and SETOUT which control the direction of the I/O port via C5. I hope this is enough to guide you.

______________________________________________________________

' Define Port Addresses ' Port LPT1: LPT2: ' DATA 378H 278H ' 888d 632d ' STATUS +1 +1 ' CONTROL +2 +2 NOTES: ' Port bit assignments 'DATA port = Base Address 'STATUS port = Base+1 'CONTROL port = Base+2 'DATA port - all 8 bits (pins 2-9) for data I/O 'STATUS port & CONTROL port assignments as follows:

'D-PIN BIT BITWEIGHT ROLE '1 /C0 1 Prog pulse initiate '10 S6 64 Prog pulse "done" '11 /S7 128 NC '12 S5 32 NC '13 S4 16 NC '14 /C1 2 Reset (RL31) '15 S3 8 Full count - "chip done" '16 C2 4 Clock '17 /C3 8 Vpp enable (RL32) '-- C5 32 Data port direction (0 = out, 1 = Hi-Z) DAT = 888: ' Edit as required STA = DAT + 1: CONT = DAT + 2

OUT DAT, 0: OUT CONT, 32: ' Initial states - Data Port 0 and hi-Z

LETSGO: N = 0: ' Byte number

IF (INP(CONT) AND 32) 32 THEN STOP: 'Make sure we are Hi-Z

NXT: (some snips) T1: 'first clock high - strobe address from U11 into '574 latches GOSUB SETCLK

T1.5: 'first clock low - enable U13 output GOSUB CLRCLK

T2: 'second clock high - strobe U13 output to module latch GOSUB SETCLK

T2.5: 'second clock low - disable U13 output GOSUB CLRCLK

T3: 'third clock high - action on write only GOSUB SETCLK IF BURN THEN GOSUB SETOUT: ' Set data port to output BYTE = A(N) GOSUB PUSH: ' Put data on I/O port END IF

T3.5: 'third clock low - enable U12 output to module GOSUB CLRCLK IF BURN THEN GOSUB DELAY: ' Allows address lines to settle GOSUB PROGNOW X = 1 DO UNTIL X = 0 GOSUB PULSEDONE: ' Wait for end of prog pulse LOOP END IF GOSUB SETHIZ

T4: 'fourth clock high - set module /OE low to enable reading GOSUB SETCLK 'Enables module output - data now available 'to read (verify if on a write operation) FOR I = 1 TO 1000: NEXT: 'Wait for output enable GOSUB PULL A(N) = BYTE T4.5: 'fourth clock low - disable U12 output GOSUB CLRCLK ' Address lines no longer valid

T5: 'fifth clock high - module /OE high; increment address counter U11 GOSUB SETCLK

T5.5: 'fifth clock low GOSUB CLRCLK

T6: 'sixth clock high - resets sequence controller U21 to zero GOSUB SETCLK

T6.5: GOSUB CLRCLK: ' U21 should have reset by now

N = N + 1: IF N < SIZE THEN GOTO NXT: ' Next byte IF (INP(STA) AND 8) = 0 THEN STOP: 'CHIP DONE should be available now. IF (INP(CONT) AND 32) 32 THEN STOP: 'Should never happen GOSUB SETHIZ: 'To be sure, to be sure

(rest of in-line processing)

'*************************************************************************** '************** MODULE INTERACTION SUBROUTINES ********************* '***************************************************************************

PUSH: GOSUB DELAY OUT DAT, BYTE: ' Write a byte to port GOSUB DELAY : RETURN PULL: BYTE = INP(DAT): ' Read a byte from port : RETURN SETHIZ: OUT CONT, INP(CONT) OR 32: 'Set Data port to high-Z for Read (or safety) GOSUB DELAY : RETURN SETOUT: OUT CONT, INP(CONT) AND 223: 'Set Data port to OUT GOSUB DELAY : RETURN

RSTON: OUT CONT, INP(CONT) OR 2: 'Set RESET active GOSUB DELAY2 : RETURN RSTOFF: OUT CONT, INP(CONT) AND 253: 'Clear RESET GOSUB DELAY2 : RETURN

SETCLK: OUT CONT, INP(CONT) OR 4: 'Set CLOCK high GOSUB DELAY : RETURN CLRCLK: OUT CONT, INP(CONT) AND 251: 'Set CLOCK low GOSUB DELAY : RETURN

DELAY: 'Delay 100uS for clock and port mode FOR I = 1 TO T100: NEXT : RETURN

DELAY2: 'Delay for Vpp enable/disable and Reset FOR I50 = 1 TO 50: GOSUB DELAY: NEXT : RETURN

PROGNOW: OUT CONT, INP(CONT) OR 1 FOR P = 1 TO T10: NEXT OUT CONT, INP(CONT) AND 254 : RETURN PULSEDONE: X = INP(STA) AND 64 : RETURN ______________________________________________________________

.

set

(&H378)+4.

convey

----------- SNIPped for brevity --------- Thanks for the program; i find that use of the subroutines make for greater readability. There is very little time penalty for a call to and return from a subroutine. Will look it over the next few days.

As far as why i am reading that port? Well, if one looks at the EPP documentation (which it seems you missed), that is the EPP data R/W port and one is supposed to read incoming data there. On the old SPP cards, one can readback data that has been sent to the printer (ie: written to the data output latch and thus the pins). That capability has been retained, but instead of actually sensing the pin levels like IBM did in their printer port cards, the newer cards seem to wimp out and read the register. That same failure to conform to the IBM "standard" happened in a number of the 286, 386 and 486 printer cards. So...the only way to actually read pin logic levels seems to be via the EPP data I/O port.

***** A low level TTL input pullup is 40K and a low level schottky input pullup is 20K. That is the standard as defined by Texas Instruments. I had nothing to do with that and have no control over that. The pins of all EPP ports that i have looked at have three states: output low, output high, and "neither"; the third state acts like a 2.4K pullup to +5V with a 2.2K or a 1K pulldown. Certainly *not* like an input to any TTL device! I also have nothing to do with that nor do i have any control over that unless i damage them by over current in either direction. Theoretically, a 420 ohm resistor to ground would get about 0.8V for a low and IFFI (if and only if) the "input" logic threshold abides by TTL standards, then that becomes marginally acceptable. A 200 ohm pulldown would be far better, but that could possibly result in a few watts of dissipation in the ASIC if all pins were high. Granted, one can use a decent TTL tristate driver with 200 ohm protection resistors in series, and enable output *only* when the EPP pins are supposed to be an input; that would make the life of the ASIC better.

particular

a

convey

You'll see from my code that I read in data (PULL) at the base address. That's all I've ever done, and it has always worked. From discrete printer/Multi-I/O cards on a '286 to on-board ASIC implementations. This platform is a P3-667 and the only things NOT on-board are video and NIC.

I try to not get too tangled in what the IBM TRM or anyone else's documentation, or "standard" or implementation does. I just "do it". Call me a humming-bird if you will.

Maybe it's not a bug but a feature.

The parallel port is not necessarily an ordinary chip-to-chip logic interface. If you look at what it does, it's a driver (/receiver) for a transmission line. At high speeds, you may want a much smaller line termination impedance than you would for a short chip-to-chip connection (and even there you might design in some termination on the PCB).

In the real high speed communications ports the impedances would be written into the spec.

particular

a

convey

and

documentation,

I read the code and have tried only a little part of it; basically i can flip pin#1 high or low and the data either output or "input". Still, the so-called "hi-z" is crap; am using 200 ohm for safety pulldown to low. What is intriguing is that yuor program controls the machine, instead of the full EPP read protocol where the \\WAIT would allow hardware handshaking for the data read - but *only* if the machine presents the data during the wait time (yes - it *does* time out). If the machine is slow, then data is not read and something must be done in the software for a "oops" and re-try.

One major problem is that there is absolutely no disclosure concerning the ASCI parallel port electrical specs.

particular

As a

convey

That's

and

documentation,

I haven't seen any timeout issues even when debugging with breakpoints all the way through.

I don't claim the way I posted is the "right way" or is in accordance with anybody's specification or documentation. I do it that way because "it works". Hummingbird.

My code (not shown) determines the value of variable T100 on the current platform so the DELAY is ~100uS as near as can be simply resolved - I don't use the PC timers at all. That way I am independent of platform speed. The only catch is if someone runs this on an old machine with an active turbo switch, determines a T100 value and then switches. But the worst that happens is bad data transfer (read or write) to/from the EPROM.

I don't know what an "ASCI" parallel port is, but there is full electrical specification for an IEEE 1284 parallel port. Here's an unofficial interpretation:

Sams Photofact CSCS-10 covers the IBM XT and all the boards. It has the schematic of the parallel printer board, if you can find a copy. You might be able to get it on an inter-library loan. It might be in the documentation provided with the Heath/Zenith XT clone computers sold to the US government. I don't know if my copies survived the hurricanes over the last couple years. They were on shelves in my garage that I still can't get to.

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

I once built an ordinary, TTL (or maybe LSTTL) output-only printer port directly from the schematic in the "IBM PC Technical Reference", which had _all_ of the schematics of the whole thing, and a complete BIOS listing. I had a "2 serial, 1 parallel" adapter, and the parallel part was some cheap Chinese 40-pin chip that blew out every time I plugged in the printer. So I made a little daughterboard, and had to lash up a crystal oscillator for the clock for the serial chip - the parallel chip had also had the clock oscillator for the serial side of the board. I was pretty proud of that!

Input should be almost trivial, like one connection - I've seen that documented somewhere on the web, too. I can't imagine that EPP is _that_ much different.

Cheers! Rich

particular

As a

convey

That's

and

documentation,

works".

What is nice about your approach is that the external machine (whatever it is) is "triggered" by the computer, so ther can be no problems unless the triggering is too fast. The full EPP scheme requires reading from the EPP data register, and the machine damn well better respond within the WAIT timeput period. And if it (randomly?) does not respond, then the software better be designed to recognize that fact and re-try (forever??).

In any event, i got the machine to work (paper tape reader)..sort-of. It is a mechanical problem with the stepper that advances the tape; seems to have gotten a little rusty and only advanced sometimes. Some WD-40 has helped considerably, but each step is like light banging of a tuning fork - the tape "bounces" back and forth for multiple reads (strobing on the sprocket hole) - up to 3 times for valid reads, and up to 15 times if one looks at the photocell (ignoring threshold). But the worst thing is, the damn motor sometimes "bounces" backwards, and on rare occasion "bounces" two frames backwards. Making a slight change of the hardware and software, i do a read and then step the motor and wait for a given time. That fixes the multiple read "bounce" problem (before advancing), but not the backwards tape "bounce" problem. Maybe i need to use some rusty electrons?

I have the IBM Technical Reference manual as printed in August 1981 (First Edition), so do not need to search for a Sams. If ther is some part that you would like me to scan to a PDF, let me know.

(snip)

Yes, that was a design imperative for me. It's about programming a module with an EPROM and some address line latches, so a conventional programmer can't be used. I set up a state machine and I clock it through the states (T numbers reflect these) with timed delays. Works a treat.

I can't see a situation where the triggering could be too fast for the HC counters in the state machine. There is a limit on how fast the port can rise/fall and I can't see it overrunning the HC logic. But the delays fix that ;-)

Forget the fancy stuff. Stick to basics.

I'm not sure how I'd go about addressing a stepper that had bounce.

That doesn't sound good. Is there maybe something wrong with the driver circuit, one dead half bridge perchance? I wouldn't expect bouncing if the coils are kept energized in the hold position, maybe you can make them energize for a half second or so and then turn off if you want to reduce idle power consumption.

To really reduce bouncing, I'd consider going to a micro-stepping driver - it drives both coils with proportional currents so it can move through positions intermediate between two steps. Using that to slow down the complete steps to be less impulsive would slow the machine down, but not nearly as much as your settling delay does. Ideally you'd find a speed where you could run the tape continuously...

Geckodrive is a popular brand microstepping driver with the hobby CNC crowd (steppers on milling machines) and is designed to be pulsed from a parallel port.

Oh, just ALL OF IT!!!!!!!!!

;-P

Thanks! Rich