Re: OT: DOS programming EPP

On Thu, 26 Jan 2006 08:55:12 GMT, Robert Baer <robertbaer@xxxxxxxxxxxxx> wrote:

>budgie wrote:
>
>> On Wed, 25 Jan 2006 06:56:08 GMT, Robert Baer <robertbaer@xxxxxxxxxxxxx> wrote:
>>
>>
>>>budgie wrote:
>>>
>>>>On Tue, 24 Jan 2006 09:28:22 GMT, Robert Baer <robertbaer@xxxxxxxxxxxxx> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> 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).
>>>>
>>>>
>>>>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.
>>
>>
>>> 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".
>>
>>
>> which certainly suggests that you can select from all of those three modes.
>>
>>
>>
>>>>I'm not sure I followed why your C5 is high for only a microsecond - was that
>>>>your code?
>>>
>>> *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.
>>
>>
>> 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.
>>
>>
>>> Since the code is in BASIC and running p-code, it is fairly fast, and
>>>one microsecond is not out of line.
>>
>>
>> But why is your code only putting a transient 1 on C5? See above.
>>
>>
>>>>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.
>>
>>
>>> 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.
>>>
>>>
>>>>> 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.
>>
>>
>> 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.
>>
>>
>>
>>>>Again, I'm not sure whether you issue is with the hardware or your software
>>>>implementation.
>>
>>
>>> 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.
>>
>>
>> Until I understand why you are only getting a ~1uS high on C5, I wouldn't be
>> junking the mobo.
> In any program one can only read a port or write a port at a given
>time; it is impossible to do both.

Obviously - although a read when the port is set to OUTPUT will read back the
contents of the register as last written. This doesn't read the pins' status of
course.

> If the hardware is supposed to latch the Control bytes, then all i
>can say, it does not happen in my MB.

The control register in a properly functioning mobo's LPT port should act like
any other register, holding the contents of the most recent byte-write. If it
doesn't, IMHO it is stuffed.

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

How long the instruction "lasts" is not a relevant point. A write to a register
is a write to a register. If the reg is functioning properly, the write
"sticks". There is no "hardware timeout" on the register I/O.

You don't need assembler to check what is happening - you can read the control
register in (Q)Basic. If C5 doesn't match what you last wrote, there is a
malfunction. But do allow a finite time between port direction changes and
read/write attempts. I had one project stalled for over a year looking for an
external hardware issue because I was changing C5 0->1 and then writing a byte,
which was not being read properly by the attached device. A short delay loop
between setting C5=1 and writing the byte solved the problem (QB4.5, P1-133 and
P3-666).

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

As per the description above, if it isn't behaving as I described then I would
be getting another mobo.
.

Relevant Pages

  • Re: How to debug inside the BIOS and/or interrupt?
    ... I'm not sure I can help with your specific code problem but if the program works when you read only one chunk of data at a time from disk, but locks up after a while if you read multiple chunks, then probably one of two things is happening -- some memory is being corrupted or an interrupt is taking too long somewhere. ... one nice way to debug interrupt problems on such hardware is to modify your interrupt routine so that it toggles a pin that you can look at with a 'scope. ... That's usually not wise to attempt within an interrupt but you can simulate such a thing by doing something like writing to a fixed, preallocated error log in memory, or to a hardware register. ... Again you might find the printer port convenient for this, or if you have at least an EGA compatible display on your hardware, you can do things like change the background color of the screen by writing to the overcan register. ...
    (comp.lang.asm.x86)
  • Re: [PATCH 1/2] VMware detection support for x86 and x86-64
    ... wrong or what kinds of problems can this cause on native hardware. ... You accessed an unknown I/O port. ... Read access to port 3686 returns the status register and any ...
    (Linux-Kernel)
  • Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
    ... sequence IIRC - i think the vidport is even ignored for the input direction by most hardware, there's a separate input register. ... The 0x3cc port is a well-defined VGA register which should be unused on non-VGA hardware. ...
    (Linux-Kernel)
  • Re: [linux-kernel] Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
    ... some OSes use port 0x80 as a hardware available scratch ... register. ...
    (Linux-Kernel)
  • Re: Via VT 6410 Raid Controller
    ... Using 1 I/O APICs Using ACPI for SMP configuration information Allocating PCI resources starting at 20000000 Built 1 zonelists mapped APIC to ffffd000 ... Allocate Port Service ... USB Universal Host Controller Interface driver v2.2 ... IFWLOG: register target usbcore: registered new driver usblp drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver parport: PnPBIOS parport detected. ...
    (Linux-Kernel)