Hi David,
-> SB> I'm not sharing IRQ's between adaptor cards. I currently have
-> SB> 1 port enabled on the motherboard (com1, irq4), and I have 4
-> SB> ports enabled on the serial card (com1-4, irq3).
->
-> What brand and model of 4port card. If it uses different controller
-> chips for each port or pair of ports it will not share well. My STB
-> AT-IO6 is specifically designed to share ports. Is your card? Does it
-> say in the docs or is it mentioned by Ray Gwinn as an acceptable card
-> for sharing?
I'm using a Turbo 4COM I/O Adapter model #TC-400 with 16650 UARTS.
Purchased from ByteRunner. The four biggest chips on the card are
the 4 UARTS, which look just like the UARTS from an old serial card.
Other than those, there are no significantly big chips. All the rest are
about the size of an old XT ram chip. It's not mentioned in Ray's docs,
but then very few are :( It claim to support IRQ sharing. It *looks*
like a fairly high-spec card with the number of options for port/irq/
base addressing.
-> Where is your mouse connected? On the serial ports or somewhere else?
-> (ie PS2)
->
-> SB> It's connected to the standard com1 port on the motherboard.
->
-> OK, and the secone port is disabled? Try changing what IRQ your
-> shared ports use. Pull the sound card out and use IRQ5 as a test.
I have used different IRQ's in the past with the same results, but I
will again try using IRQ5 just to be sure. (You know when trying to
track down a problem like this, you start off by knowing very little
about the hardware configuration, and by the end you're an expert. So
it may just be that my last change of IRQ test was done at a time when
I had something else misconfigured... hence the 'to be sure').
-> Some DOS programs refuse to give up the handle even after they are
-> done. Try to use SU and see if you can force a reset of the port
-> after the program is done. Also, try to make sure that your DOS
->
-> SB> I never thought of that. Maybe I'll see if that will work.
-> SB> Thanks.
I tried SU but it seemed to think there was nothing wrong with the
port. However in Dos, it was reported as in use. Sorry, for the
vagueness there. But for sure there were conflicting reports about
what the status of the com port was when i tried to test it under
OS and OS/2.
The last time I experienced this error (which just to remind us, is
intermittent) it was on COM1, which usually has been trouble free,
and it occurs mostly (almost solely) on COM2. The only other com port
in use is COM3 which is used for the internet dial-up line. So this
problem with switching between DOS/OS2 use of the com port isn't a
problem on COM3. My contention is when it happens (intermittently) it
happens 98% of the time on COM2 and 2% of the time on any other com
port used for the bbs (which is the program switching these DOS/OS2
sessions). So we can say that it does occur on any of these ports.
-> SB> What are the names of these tools?
->
-> From the Sept 1997 Hobbes CDs, disk 2, /shellutl/ directory:
-> startdos.zip 96480 08-11-96 REXX: Start DOS sessions with DOS
-> settings | in script
I found that on the April 97 CD as well. So I'll take a look at that
later.
-> SIO adds several options under DOS session settings that can
-> eliminate many cross chatter problems between different DOS sessions
-> stepping on other nodes toes:
->
-> SIO_Allow_Access_COM1
-> SIO_Allow_Access_COM2
-> SIO_Allow_Access_COM3
-> SIO_Allow_Access_COM4
-> SIO_Idle_Sensitivity
-> SIO_Mode_DTR
-> SIO_Mode_FIFO_Load_Count
-> SIO_Mode_IDSR
-> SIO_Mode_OCTS
-> SIO_Mode_ODSR
-> SIO_Mode_RTS
-> SIO_Mode_XON/XOFF
-> SIO_Screen_Sync_Kludge
-> SIO_Share_Access_With_OS/2
-> SIO_Virtualize_16550A
-> SIO_Virtualize_COM_Ports
I have looked at these setting before and tried many. So they all need
to be set for a multiport card to work with SIO? Anyhow, it's been a
while since I played with these, so maybe I should return to them and
have another play. Are there any obviously critical ones I should take
care of, knowing my situation?
-> SB> I'm not sure this is possible, since all the 4 ports on the
-> SB> serial card are non-std. Unless I miss your meaning again :(
->
-> Yup, missed my meaning and that section of the docs... Read
-> SIOREF.txt, specifically Appendix D, pay very close attention to IRQ
-> reflection and IO port mapping to DOS sessions:
->
-> Appendix D, Advanced SIO Options . .
-> Protection . . . . . . . . . . .
-> Locked Baud Rate . . . . . . . .
-> IRQ Reflection to DOS Process .
-> I/O Port Mapping to DOS Process
OK, I'll re-read that again. Thanks for your help and patience. I may
not be able to get back to you for a couple of weeks since I've got to
go out of town, this weekend.
Rgds,
Stewart
--- PCBoard (R) v15.4 (OS/2) 10 Beta
---------------
* Origin: The Chili Channel * Manila, Philippines * Fidonet (6:751/222)
|