Reconfigure laptop ECP parallel port to SPP/bidi operation?

I want to utilize my HP ze5300 laptop parallel port to input data to process. I have created x86 assembly language applications to input/process/display incoming parallel data. These applications also need to be portable to other users. They work fine on DOS, Win98, etc platforms with SPP/bidi ports. I need to know how to have my asm applications reconfigure the ECP port for SPP and bidi operation. My input sources (8 bits DATA or 5 bits STATUS) provide only data and no handshaking. Apparently my port is configured as ECP which, hopefully, should be downward compatible to SPP/bidi. I need to configure it to SPP/bidi. I found no Phoenix BIOS controls (F2 setup) to reconfigure ECP to SPP/bidi. BIOS has found the port at 03BC but XP device manager says it is at 0378. Reading/writing the 03BC register works internally but the data signals are not at the parallel port connector pins. 0378 does not work. I tried using x86 asm to set the ECP ECR register (at base+402H) bits 7-5 to 000 (SPP), 001 (bidi) with no luck. I cannot r/w the ECR. The ECP parallel port works fine with an old SPP printer. HP chat/phone support have no idea what I am talking about! Has anyone used x86 asm to reconfigure an ECP port to SPP/bidi?

Comments

  • : I want to utilize my HP ze5300 laptop parallel port to input data to process. I have created x86 assembly language applications to input/process/display incoming parallel data. These applications also need to be portable to other users. They work fine on DOS, Win98, etc platforms with SPP/bidi ports. I need to know how to have my asm applications reconfigure the ECP port for SPP and bidi operation. My input sources (8 bits DATA or 5 bits STATUS) provide only data and no handshaking. Apparently my port is configured as ECP which, hopefully, should be downward compatible to SPP/bidi. I need to configure it to SPP/bidi. I found no Phoenix BIOS controls (F2 setup) to reconfigure ECP to SPP/bidi. BIOS has found the port at 03BC but XP device manager says it is at 0378. Reading/writing the 03BC register works internally but the data signals are not at the parallel port connector pins. 0378 does not work. I tried using x86 asm to set the ECP ECR register (at base+402H) bits 7-5 to 000 (SPP), 001 (bidi) with no luck. I cannot r/w the ECR. The ECP parallel port works fine with an old SPP printer. HP chat/phone support have no idea what I am talking about! Has anyone used x86 asm to reconfigure an ECP port to SPP/bidi?
    :
    :

    Are you trying to access the LPT port in a DOS (cmd) shell under XP?
    XP/NT variants will block you from accessing those ports (and almost everything else.)

    To get around this, you can download a driver called "giveio.sys".
    Once the driver is installed under NT/XP, you can then have your DOS mode program do a normal file open command to open "\.giveio".

    The open file command will fail, but suddenly you'll have access to all the I/O ports!


    ECP should indeed be backwards compatible to bidirectional.

    I'm a little concerned that it's installed at 3BC though. 378 or 278 are much safer/compatible places for a parallel port to be.

    -jeff!

  • : : I want to utilize my HP ze5300 laptop parallel port to input data to process. I have created x86 assembly language applications to input/process/display incoming parallel data. These applications also need to be portable to other users. They work fine on DOS, Win98, etc platforms with SPP/bidi ports. I need to know how to have my asm applications reconfigure the ECP port for SPP and bidi operation. My input sources (8 bits DATA or 5 bits STATUS) provide only data and no handshaking. Apparently my port is configured as ECP which, hopefully, should be downward compatible to SPP/bidi. I need to configure it to SPP/bidi. I found no Phoenix BIOS controls (F2 setup) to reconfigure ECP to SPP/bidi. BIOS has found the port at 03BC but XP device manager says it is at 0378. Reading/writing the 03BC register works internally but the data signals are not at the parallel port connector pins. 0378 does not work. I tried using x86 asm to set the ECP ECR register (at base+402H) bits 7-5 to 000 (SPP), 001 (bidi) with no luck. I cannot r/w the ECR. The ECP parallel port works fine with an old SPP printer. HP chat/phone support have no idea what I am talking about! Has anyone used x86 asm to reconfigure an ECP port to SPP/bidi?
    : :
    : :
    :
    : Are you trying to access the LPT port in a DOS (cmd) shell under XP?
    : XP/NT variants will block you from accessing those ports (and almost everything else.)
    :
    : To get around this, you can download a driver called "giveio.sys".
    : Once the driver is installed under NT/XP, you can then have your DOS mode program do a normal file open command to open "\.giveio".
    :
    : The open file command will fail, but suddenly you'll have access to all the I/O ports!
    :
    :
    : ECP should indeed be backwards compatible to bidirectional.
    :
    : I'm a little concerned that it's installed at 3BC though. 378 or 278 are much safer/compatible places for a parallel port to be.
    :
    : -jeff!
    :
    Jeff, thanks for the response. I am running XP but use the DOS Prompt on the desktop to open up a window to get me to the DOS command line at which I run my assembly programs. This seems to work fine in other applications which happen not to use any ports. Do you believe that operating in this mode will prevent access to LPT ports? I do not recognize the "\.giveio" format but can 'open' a file using the assembly instructions from within my program as:

    MOV DX,filename;Start mem loc of c:giveio.sys
    MOV AL,00H ;Normal Read/Write file attribute
    MOV AH,3DH ;Open File function
    INT 21H ;Open File ;File handle is in AX

    filename:DB'C:GIVEIO.SYS?'

    I can also install 'giveio.sys' in the AUTOEXEC.NT_ and/or CONFIG.NT_ files. When you said 'normal file open command to open "\.giveio".', were you referring to either of these approaches or something else? When you said 'installed under NT/XP', were you referring to using the ADD/REMOVE SOFTWARE approach for the 'giveio.sys' file?

    In an email, HP wrote that the 'Parallel port shipped with this unit supports only ECP standards. Since most of the parallel port devices that are used supports the ECP standard, this port is not backward compatible. However, you can install a PCMCIA Parallel that supports both ECP and SPP standards.' I have since asked if my port is IEEE 1284 compatible.

    The port address is interesting. BIOS displays at 0:0400 that LPT1 is at 03BCH, LPT2 is at 0378H and LPT3 is at 0278H even though I find no other evidence of an LPT2 or LPT3 port. XP Device Manager shows the LPT1 port at 0378H and to be ECP. Using assembly instructions, writing and reading the 03BCH registers works internally but the signals do not appear at the connector. W/R to 0378H or 0278H registers do not work at all internally. The majority of the evidence suggests the port is at 03BCH. I have found evidence that suggests that ECP registers at 03BCH may not be accessible. I have not been able to W/R the 03BCH ECR register at 03BCH+402H.

    Given that my ECP port may not be backward compatible to bidi, I am considering making my peripheral interfaces ECP compatible (tail wagging the dog). My question is: Will the assembly instruction 'IN AL,DX' cause the HP ECP interface hardware to automatically issue the necessary handshaking signals to input data from the interface? Future testing will hopefully answer this question. Any other thoughts out there? triggerme

  • : :
    : Jeff, thanks for the response. I am running XP but use the DOS Prompt on the desktop to open up a window to get me to the DOS command line at which I run my assembly programs. This seems to work fine in other applications which happen not to use any ports. Do you believe that operating in this mode will prevent access to LPT ports?

    Yep. XP/NT "dos" shells are extremely limited in what they are allowed to access. This is your problem, I've been there many times before!


    I do not recognize the "\.giveio" format but can 'open' a file using the assembly instructions from within my program as:
    :
    : MOV DX,filename;Start mem loc of c:giveio.sys
    : MOV AL,00H ;Normal Read/Write file attribute
    : MOV AH,3DH ;Open File function
    : INT 21H ;Open File ;File handle is in AX
    :
    : filename:DB'C:GIVEIO.SYS?'

    Just change
    filename:DB'C:GIVEIO.SYS?'
    to
    filename:DB'\.GIVEIO'

    the \. is a special handle that windows uses to access drivers.
    You are technically not opening the actual driver file itself, but calling the loaded driver in the OS.

    You can do the same type of thing by "opening" it with debug:

    debug \.giveio

    debug will respond with a "file not found" (as will your INT 21 call)
    but the driver is called and I/O access is granted.

    There are other LPT port access granting programs out there too.
    If you do a google for 'LPT port I/O NT' or similar, I've seen at least 2 others.

    I like giveio.sys because it opens up the entire range of ports, where as others often only open up stuff from 0 up to 3FF. The other drivers also have windows front ends to them that require user interactions, whereas giveio.sys is invisible to the end user once it's installed.

    The problem with giveio.sys (for me at least) is that under XP when in a full screen dos window, the keyboard locks up. I havent figured out a way around that one yet. If you don't run full screen it works fine.
    (I'm researching a work around, but haven't had time to try it yet)

    :
    : I can also install 'giveio.sys' in the AUTOEXEC.NT_ and/or CONFIG.NT_ files. When you said 'normal file open command to open "\.giveio".', were you referring to either of these approaches or something else? When you said 'installed under NT/XP', were you referring to using the ADD/REMOVE SOFTWARE approach for the 'giveio.sys' file?

    No, giveio.sys is an XP/NT windows driver, not a DOS driver. Don't put it in your config.sys

    You can download the driver and a tiny batch file to install it here:
    http://www.waste.org/~winkles/throttle

    (it's toward the end of the page)

    You may need to modify the install.bat file so that it copies the driver into the correct subdirectory. THat batch file was written for an NT machine.


    :
    : In an email, HP wrote that the 'Parallel port shipped with this unit supports only ECP standards. Since most of the parallel port devices that are used supports the ECP standard, this port is not backward compatible. However, you can install a PCMCIA Parallel that supports both ECP and SPP standards.' I have since asked if my port is IEEE 1284 compatible.
    :

    Don't believe them for a second. If all you're trying to do is read/write a couple signals on the LPT port, you've got nothing to worry about.

    Heck, boot the same machine up in DOS (get XP and all of it's nonsense port blocking and LPT port remapping out of the way) and see if your program works. If it does (and it probably will) then you've only got to wrangle XP under your control and you're golden.

    -jeff!

  • : : :
    : : Jeff, thanks for the response. I am running XP but use the DOS Prompt on the desktop to open up a window to get me to the DOS command line at which I run my assembly programs. This seems to work fine in other applications which happen not to use any ports. Do you believe that operating in this mode will prevent access to LPT ports?
    :
    : Yep. XP/NT "dos" shells are extremely limited in what they are allowed to access. This is your problem, I've been there many times before!
    :
    :
    : I do not recognize the "\.giveio" format but can 'open' a file using the assembly instructions from within my program as:
    : :
    : : MOV DX,filename;Start mem loc of c:giveio.sys
    : : MOV AL,00H ;Normal Read/Write file attribute
    : : MOV AH,3DH ;Open File function
    : : INT 21H ;Open File ;File handle is in AX
    : :
    : : filename:DB'C:GIVEIO.SYS?'
    :
    : Just change
    : filename:DB'C:GIVEIO.SYS?'
    : to
    : filename:DB'\.GIVEIO'
    :
    : the \. is a special handle that windows uses to access drivers.
    : You are technically not opening the actual driver file itself, but calling the loaded driver in the OS.
    :
    : You can do the same type of thing by "opening" it with debug:
    :
    : debug \.giveio
    :
    : debug will respond with a "file not found" (as will your INT 21 call)
    : but the driver is called and I/O access is granted.
    :
    : There are other LPT port access granting programs out there too.
    : If you do a google for 'LPT port I/O NT' or similar, I've seen at least 2 others.
    :
    : I like giveio.sys because it opens up the entire range of ports, where as others often only open up stuff from 0 up to 3FF. The other drivers also have windows front ends to them that require user interactions, whereas giveio.sys is invisible to the end user once it's installed.
    :
    : The problem with giveio.sys (for me at least) is that under XP when in a full screen dos window, the keyboard locks up. I havent figured out a way around that one yet. If you don't run full screen it works fine.
    : (I'm researching a work around, but haven't had time to try it yet)
    :
    : :
    : : I can also install 'giveio.sys' in the AUTOEXEC.NT_ and/or CONFIG.NT_ files. When you said 'normal file open command to open "\.giveio".', were you referring to either of these approaches or something else? When you said 'installed under NT/XP', were you referring to using the ADD/REMOVE SOFTWARE approach for the 'giveio.sys' file?
    :
    : No, giveio.sys is an XP/NT windows driver, not a DOS driver. Don't put it in your config.sys
    :
    : You can download the driver and a tiny batch file to install it here:
    : http://www.waste.org/~winkles/throttle
    :
    : (it's toward the end of the page)
    :
    : You may need to modify the install.bat file so that it copies the driver into the correct subdirectory. THat batch file was written for an NT machine.
    :
    :
    : :
    : : In an email, HP wrote that the 'Parallel port shipped with this unit supports only ECP standards. Since most of the parallel port devices that are used supports the ECP standard, this port is not backward compatible. However, you can install a PCMCIA Parallel that supports both ECP and SPP standards.' I have since asked if my port is IEEE 1284 compatible.
    : :
    :
    : Don't believe them for a second. If all you're trying to do is read/write a couple signals on the LPT port, you've got nothing to worry about.
    :
    : Heck, boot the same machine up in DOS (get XP and all of it's nonsense port blocking and LPT port remapping out of the way) and see if your program works. If it does (and it probably will) then you've only got to wrangle XP under your control and you're golden.
    :
    : -jeff!
    :
    :==================================================================
    Jeff:
    Thanks again for the help. I have downloaded the tht_nt.zip file and modified the install.bat to change from 'nt' to '32'. I will look at GIVEIO.SYS trying to convince myself if something goes wrong, I can recover. If this works, I wlll prefer to run in a full DOS window to take advantage of my program's display output features. I hope my keyboard does not lock up. If you find an answer to that problem, I would appreciate knowing about it.

    I initially tried to run my assembly parallel port programs from a DOS 6.22 floppy boot. I also wanted to run my DOS INTERLNK and INTERSVR file transfer programs from the floppy boot but failed. In both cases, my 60GB C: HDD is not accessible and the parallel port does not work either. This process works fine with my DOS computers and from the Win98 DOS window. Not true with my existing BIOS and XP.
    triggerme
  • :
    : I initially tried to run my assembly parallel port programs from a DOS 6.22 floppy boot. I also wanted to run my DOS INTERLNK and INTERSVR file transfer programs from the floppy boot but failed. In both cases, my 60GB C: HDD is not accessible and the parallel port does not work either. This process works fine with my DOS computers and from the Win98 DOS window. Not true with my existing BIOS and XP.
    : triggerme
    :

    You probably can't see the HDD because DOS6.22 doesn't support FAT32 based file systems (I think). Your HDD may also be formatted with NTFS, in which case you won't be able to see if if you boot to the floppy.

    Try making a bootable disk on one of your windows98 machines and see if you can then see your 60G drive on the XP machine. This won't help with your LPT issue, but at least you'll be able to get to your C: drive.


    Does your BIOS have a "plug and play operating system" selection?
    If it does (most phoenix bioses do) set it to NO and see if the LPT port starts working in DOS. Also, make sure the LPT port is set to enabled, not AUTO. (if you have those options)

    If this still fails, I've still got a trick or two up my sleeve, so don't give up!

    -jeff!
  • : :
    : : I initially tried to run my assembly parallel port programs from a DOS 6.22 floppy boot. I also wanted to run my DOS INTERLNK and INTERSVR file transfer programs from the floppy boot but failed. In both cases, my 60GB C: HDD is not accessible and the parallel port does not work either. This process works fine with my DOS computers and from the Win98 DOS window. Not true with my existing BIOS and XP.
    : : triggerme
    : :
    :
    : You probably can't see the HDD because DOS6.22 doesn't support FAT32 based file systems (I think). Your HDD may also be formatted with NTFS, in which case you won't be able to see if if you boot to the floppy.
    :
    :Try making a bootable disk on one of your windows98 machines and see if you can then see your 60G drive on the XP machine. This won't help with your LPT issue, but at least you'll be able to get to your C: drive.

    :
    : Does your BIOS have a "plug and play operating system" selection?
    : If it does (most phoenix bioses do) set it to NO and see if the LPT port starts working in DOS. Also, make sure the LPT port is set to enabled, not AUTO. (if you have those options)
    :
    : If this still fails, I've still got a trick or two up my sleeve, so don't give up!
    :
    : -jeff!
    :
    ================================================================
    Jeff: Thanks for your input.

    "You probably can't see the HDD because DOS6.22 doesn't support FAT32 based file systems (I think). Your HDD may also be formatted with NTFS, in which case you won't be able to see if if you boot to the floppy."

    You are correct on both counts.

    "Try making a bootable disk on one of your windows98 machines and see if you can then see your 60G drive on the XP machine. This won't help with your LPT issue, but at least you'll be able to get to your C: drive."

    I agree and will try it. It might be interesting.

    "Does your BIOS have a "plug and play operating system" selection?
    If it does (most phoenix bioses do) set it to NO and see if the LPT port starts working in DOS. Also, make sure the LPT port is set to enabled, not AUTO. (if you have those options)"

    My Phoenix BIOS leaves a lot to be desired, including the inability to reconfigure the ECP port to SPP/bidi. It does not have the PnP option, nor does it have any LPT options. I tried the GIVEIO.SYS approach but neither the DATA or CONTROL port signals appear at the parallel port connector. I can see the effect internally by reading the corresponding 03BCH and 03BEH registers once I write to them. I also wake up the printer message saying that I have 'print jobs waiting'. So some things are happening but not at the connector. It is almost as if the connector is not yet connected to the internal registers. I confirmed that the GIVEIO.SYS driver is in the windowssystem32drivers location. I was not able to find the Registry location REGISTRYMACHINESYSTEMCurrentControlSetGIVEIO to look for GIVEIO. Do you know where it might be? What other checks csn be performed to insure that GIVEIO has been given a decent chance to perform its magic? I tried both the "DB'\.GIVEIO" and "DB'\.GIVEIO.SYS" forms for the OPEN instruction file location.

    "If this still fails, I've still got a trick or two up my sleeve, so don't give up!"

    I guess that I am ready for a few more ideas. Let 'em rip!
    Thanks again, triggerme

    ps:I'll be down for a few days while I return home from vacation.

  • : My Phoenix BIOS leaves a lot to be desired, including the inability to reconfigure the ECP port to SPP/bidi. It does not have the PnP option, nor does it have any LPT options.

    sheeesh. As a phoenixBIOS developer, whoever did your BIOS had to spend a lot of time REMOVING those options from the stock build!
    That stuff is stock in every build you get from phoenix. I suppose they went with the simplest user interface over the "tweakers" model.

    : I was not able to find the Registry location REGISTRYMACHINESYSTEMCurrentControlSetGIVEIO to look for GIVEIO. Do you know where it might be? What other checks csn be performed to insure that GIVEIO has been given a decent chance to perform its magic?

    I honestly don't know what the registery entry would be; I don't have it installed on this machine I'm working on at the moment.

    In DOS, you can try to load up debug and see if you can write/read to I/O port 80h. That's the diagnostic port for POST codes. Provided something (like the southbridge) is catching those writes, you should be able to change the value presented there.
    You could also try to read/write from the PCI index and data I/O registers, located at CF8h and CFCh. If all you get back is FF's, then giveio is not installed.


    : "If this still fails, I've still got a trick or two up my sleeve, so don't give up!"
    :
    : I guess that I am ready for a few more ideas. Let 'em rip!
    : Thanks again, triggerme

    heh, well, perhaps the idea of having multiple tricks was a bit of a stretch. This one is a longshot, but perhaps there is something to the fact that the LPT port is set to ECP that makes this stuff break.

    Can you give me any information as to what hardware is installed on this machine? If we can nail down what superIO is installed on it, I can probably write you some code to strongarm the LPT mode into any mode you'd like. I'm (mostly) confident that it's a software issue that's keeping you from getting the LPT port assigned as bi, and hardware can *always* be convinced to cooperate, provided it supports it. ;)

    We might be boring the folks on this message board with this conversation, so perhaps we should go offline? Send me a private message through programmer's heaven here and we'll go email.

    (unless there are others who are following this thread and don't want us to leave? speak now!)

    -jeff!
  • I'm finding this interesting, it's not like it's off topic or anything anyway.
  • Jeff:
    This is a summary of my HP laptop ze5300 configuration:

    HDD Toshiba MK6021GAS
    Disp Adap Radeon IGP 345M
    DVD/CD-ROM Sony DVD+RW DW-P50A
    Std FDD Cont
    IDE ATA/ATAPI ALi M5229 PCI BusMast IDE
    IEEE 1394 TI OHCI
    ATi Fast IR
    Std Kybd
    Synaptics PS/2 Touchpad
    Coexant 56K ACLink Modem
    1024x768 Mon
    Net Adapt
    -1394
    -MAC Bridge Miniport
    -NSC DP83815/816 10/100 MacPhyter PCI
    PCMCIA 02Micro OZ6912 CardBus
    ECP Printer Port (LPT1)
    P4 2.4GHz
    System
    -Audio CODECs
    -Legacy Audio
    -Legacy Video
    -Media Cont
    -Unimodem 1/2 Dup Audio
    -Video CODECs
    Net
    -ALi PCI to ISA Bridge
    -ATI RS200/RS200M AGP
    -ISA PNP Read Data Port
    -PCI Bus
    USB

    If you need more specifics, let me know.

    I have not tried the other tests for GIVEIO installation, but will write some code to do so.

    I sent you a message with my email address. Thanks again.

    ===================================================================

    : : My Phoenix BIOS leaves a lot to be desired, including the inability to reconfigure the ECP port to SPP/bidi. It does not have the PnP option, nor does it have any LPT options.
    :
    : sheeesh. As a phoenixBIOS developer, whoever did your BIOS had to spend a lot of time REMOVING those options from the stock build!
    : That stuff is stock in every build you get from phoenix. I suppose they went with the simplest user interface over the "tweakers" model.
    :
    : : I was not able to find the Registry location REGISTRYMACHINESYSTEMCurrentControlSetGIVEIO to look for GIVEIO. Do you know where it might be? What other checks csn be performed to insure that GIVEIO has been given a decent chance to perform its magic?
    :
    : I honestly don't know what the registery entry would be; I don't have it installed on this machine I'm working on at the moment.
    :
    : In DOS, you can try to load up debug and see if you can write/read to I/O port 80h. That's the diagnostic port for POST codes. Provided something (like the southbridge) is catching those writes, you should be able to change the value presented there.
    : You could also try to read/write from the PCI index and data I/O registers, located at CF8h and CFCh. If all you get back is FF's, then giveio is not installed.
    :
    :
    : : "If this still fails, I've still got a trick or two up my sleeve, so don't give up!"
    : :
    : : I guess that I am ready for a few more ideas. Let 'em rip!
    : : Thanks again, triggerme
    :
    : heh, well, perhaps the idea of having multiple tricks was a bit of a stretch. This one is a longshot, but perhaps there is something to the fact that the LPT port is set to ECP that makes this stuff break.
    :
    : Can you give me any information as to what hardware is installed on this machine? If we can nail down what superIO is installed on it, I can probably write you some code to strongarm the LPT mode into any mode you'd like. I'm (mostly) confident that it's a software issue that's keeping you from getting the LPT port assigned as bi, and hardware can *always* be convinced to cooperate, provided it supports it. ;)
    :
    : We might be boring the folks on this message board with this conversation, so perhaps we should go offline? Send me a private message through programmer's heaven here and we'll go email.
    :
    : (unless there are others who are following this thread and don't want us to leave? speak now!)
    :
    : -jeff!
    :

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories