Unable to use COM1 port on IBM PC/AT

[G0HZU_JMR]

Originally Posted by Dave Moll

For reference, the software and instructions are available at https://sites.google.com/site/herald...mming-software.

I had a quick look at your link and downloaded PDS and unzipped it
I looked inside the unzipped folder and found several DOS exe files

eg V10one.exe. Is this the correct exe file?

If I disassemble this program I can see how it communicates to the serial port using the INT14 interrupt and how it sets the COM port number in the code in the exe file. I think it should be quite easy to alter the data word that holds the COM port address for different COM ports.

eg 0, 1, 2 or 3 probably refer to COM ports 1, 2, 3 or 4

At the minute it is set to 0000 which is presumably COM1. It moves this word into the dx register which INT14 uses as the pointer to the COM port for serial port comms.

To change it away from COM1 would just mean editing one byte in the exe file using any simple hex file editor.

[paulsherwin]

The MODE command has no effect on the IRQ number or IO address. It is used to set parity and data rate when the port is accessed via the BIOS, but most DOS programs ignore the BIOS and access the hardware directly.

When the AT was young it was never envisaged that end users would want to mess around with the serial port hardware settings.

[mike_newcomb]

Hi Paul, I would disagree with you on this.

When the IBM PC XT first came out, we purchased a Bristol Compatible for around £1000 which was half the IBM price, and is now in stored in a friend's attic. This had a multi function I/O card which had many straps, for the various settings as referred to by yourself and others earlier in this thread.

However I found its straps never required changing from the default settings. Only time I had a problem with IRQ and /or address was when an internal modem card was added which itself wanted to be COM1 or 2. As these were already in existence, using the straps on the modem card, I set it to COM 3 and 4.

Yesterday to refresh my memory on the MODE command, I referred back to the Bristol's DOS 3.3 manual.

The command was needed for the Bristol's serial ports as we had serial printers and other devices. If an incorrect MODE parameter was used (e.g. 6 data bits, intstead of 8) things did not work as expected. I found handshaking methods quite a learning curve - e.g. did anyone use XON/XOFF?

Had to do same when the AT's appeared.

I still have my RS232 Breakout box which helped greatly when there were problems.

As the MODE command is used to switch/redirect a LPT hardware port to a COM port, I suggested it might work on COM ports only. Although ideally here the aim is to use COM1.

Regards - Mike

[paulsherwin]

The MODE command changes values in the BIOS code for programs which use a BIOS interrupt to access the serial port - 7 or 8 bit bytes, odd, even or no parity, xon/xoff flow control, data rate etc. It's ages since I looked at this, but I think the BIOS code uses a very small data buffer - 2 bytes? - leading to lost data, and the application has to perform an interrupt for each byte. Commercial software generally didn't use the BIOS interface and addressed the hardware directly.

[Dave Moll]

Here is the serial/parallel I/O card from the AT:


Having had a closer look at the above, I have a confession to make! The 9-pin connector is, in fact COM1 rather than COM2, and the 25-pin connector is a parallel port rather than serial. If my memory of such ports hadn't been so hazy, I would have realised that the gender is wrong for a serial port! I claim as additional mitigating circumstances that a) the card for the monitor also has a parallel port (I think that's what that one is), and b) that the 9-pin to 25-pin adapter that I grabbed from my box of such things happened to be the one that was a gender-bender.

Although nothing is connected to the "ASYN2" connector on the board, I do have a spare 25-pin male connector (on a back-plane strip) which I can connect to it. I may, therefore end up going down the route suggested above by G0HZU_JMR of locating and changing the COM settings in the various programs used by the PDS system. N.B. V10ONE.EXE is only one of the nine programs used - one for each phase of the customisation (V10ZERO.EXE to V10SEVEN.EXE plus V10NINE.EXE - phase eight being "exit to DOS" and not requiring a program).

I have tried substituting other I/O cards from my box of spares, but those that I have tried so far appear to be incompatible with the AT - causing it to claim that it cannot access the floppy drives.

[cmjones01]

What are the I/O settings for the COM ports on that board? There is a whole row of jumpers along the top which are probably the ones to set the I/O ports for the serial and parallel ports, but I can't read the legends to see how they're set. COM1 should be 3F8 and COM2 should be 2F8. If you're getting write errors, I would suspect the I/O port setting as being wrong rather than the IRQ setting. I can remember that incorrect IRQ settings for serial ports generally stopped them receiving data, rather than causing write errors. Have you got the manual for that I/O card?

By the way, it's quite normal for the video card (especially if it's a Hercules or MDA one) to have a parallel port on it. This was mapped at I/O 3BC and was LPT1:. The one on the I/O card is probably at I/O 378 and will be LPT2: in your system, but would automagically become LPT1: if there wasn't one on the video card. I always found that confusing.

Chris

[Dave Moll]

Originally Posted by cmjones01

There is a whole row of jumpers along the top which are probably the ones to set the I/O ports for the serial and parallel ports, but I can't read the legends to see how they're set.

Therein lies the problem. There do not appear to be any legends on this row of jumpers other than saying "P2-15" along the top.

[G0HZU_JMR]

Originally Posted by Dave Moll

N.B. V10ONE.EXE is only one of the nine programs used - one for each phase of the customisation (V10ZERO.EXE to V10SEVEN.EXE plus V10NINE.EXE - phase eight being "exit to DOS" and not requiring a program).

I had a look through the way these exe files are launched/managed and it looks like you can change the COM port number inside the text in the various batch file(s) in that folder?

Have you already tried this?

[arjoll]

Originally Posted by Dave Moll

Here is the serial/parallel I/O card from the AT:

That card has IDE, floppy and a game port as well - so if those are original PC/ATs the card is quite a bit newer.

Originally Posted by Dave Moll

I have tried substituting other I/O cards from my box of spares, but those that I have tried so far appear to be incompatible with the AT - causing it to claim that it cannot access the floppy drives.

I'd assume this one has its floppy port disabled and the others you tried may not have, hence the issue with the built-in floppy controller. Try disabling everything except the COM ports in the other ones you have.

Originally Posted by Dave Moll

Therein lies the problem. There do not appear to be any legends on this row of jumpers other than saying "P2-15" along the top.

I can see the jumpers for IRQ and DMA channel selection, but yes I'd guess the ones along the top pick the other functions, one of them would have disabled the floppy and probably IDE is disabled as well. I've found references to the chip, but it's a generic part on lots of controllers. I'm guessing you've goggled the Winbond part numbers to see if any of the boards found match yours?

One thing with these cards is that they often had a selection for COM1/COM2 and IRQ4/IRQ3 separately, with the COM selection just being the port address.

[Dave Moll]

I had a bit more of a play last night. First, I found another I/O card that seems to be compatible with the current setup of the AT. Unfortunately, the symptoms are identical: write failure to COM1 and reportedly successful copy to COM2.

Now we get to the point where I am becoming totally confused. I happened to notice that the startup was attempting to initialise a serial mouse in COM1. I knew that I had been using such a mouse when firing up Windows (1.0 to 3.0) on that machine, but had forgotten that it also had a DOS mouse driver. Anyway, I disabled the mouse driver and rebooted - unfortunately to no avail. I then reinstated the mouse driver and connected the mouse to COM1. Hey presto, on reboot it reports that the serial mouse is successfully initiated on COM1 address 3F8, IRQ4. I have confirmed that the mouse does indeed work in both DOS and Windows (3.0).

This would seem to indicate that the problem is specific to the way PDS is attempting to set up the port. My brain hurts!

I think my next experiment is to dig out my copy of PCKermit and see whether I can get the two ATs talking to each other via a null modem cable - which will also need finding.

[Dave Moll]

Originally Posted by G0HZU_JMR

I had a look through the way these exe files are launched/managed and it looks like you can change the COM port number inside the text in the various batch file(s) in that folder?

Have you already tried this?

I didn't think that the MODE commands affected which port was used by the V10... programs, merely setting up the speed and format of the communication. Now that I have a COM2 port connected, however, I will have another go with my COM2 version of the PDS BAT file later on today.

[mike_newcomb]

Hi Dave,

if the PC is configured for a serial mouse using COM1, I would think to disable the mouse, changes to *both* CONFIG.SYS *and* AUTOEXEC.BAT are required.

Once the mouse is disabled, COM1 should be completely available for your tests.

Regards - Mike

[Dave Moll]

There is no mention of the mouse driver in CONFIG.SYS - I checked.

[Paul Stenning]

Originally Posted by Dave Moll

Therein lies the problem. There do not appear to be any legends on this row of jumpers other than saying "P2-15" along the top.

Have a look at "Total Hardware 99" - there's several copies online including here http://th99.bl4ckb0x.de/ - it has info on thousands of cards, motherboards etc.

[Dave Moll]

Thanks for the link, Paul. I am wondering, however, whether the I/O card is something of a red herring - with the problem actually lying elsewhere.

I think the next step is to see whether, as I mentioned above, I can get the two ATs to talk to each other via their serial ports - once I have located the appropriate cable and software.

[Alistair D]

All you need to know about interlnk(correct spelling) seems to be covered in this link.

http://www.pcxt-micro.com/dos-interlink.html

All you need is a null modem cable.

Al

[Dave Moll]

Originally Posted by Dave Moll

I think the next step is to see whether, as I mentioned above, I can get the two ATs to talk to each other via their serial ports.

With the help of a copy of LAPLINK and a null modem cable I have confirmed that the two ATs are indeed on speaking terms via their respective COM1 ports, so it would appear that the issues reside within the PDS suite of programs.

Now here comes the bit that really has me scratching my head: despite having an I/O card with both COM1 and COM2 enabled and set to IRQ4 and IRQ3 respectively, neither LAPLINK nor a program I came across in the meantime, called CHECKIT, recognise the presence of a COM2 port - yet this is the one that claims to have received a test byte successfully! Again, I have tried both of the I/O cards - one of which, an "Everex Magic I/O" card, specifically describes itself as "for the IBM PC/XT/AT". Any thoughts on why COM2 is not being recognised?

I think it may be more appropriate for me to raise my PDS problems with the Telephone Heritage Group now that I have established that this issue does not appear to be with my computer hardware, and concentrate here on the COM2 issue.

[Dave Moll]

After leaving this project in limbo for ten months, as mentioned in my thread on an Amstrad SM2400 modem, I have now circumvented this problem by using modems at each end - in fact at the Pentara end a pukka BT Test Equipment And Modem (TEAM) recently acquired - and have successfully copied the Pentara database to a floppy disc.

For some reason, it would only successfully complete at the painfully slow 300 baud. When copying at 1200 baud (the so-called "fast" option) it gets 50% through and gives a data error.

Now that I know it works when connecting via modems, I suspect that the problem I was having with the direct link is with the way I've wired the connecting cable. I'm pretty sure I've wired it as per the instructions, but it is just possible there's an error in those instructions. I shall go back and check my wiring against both the instructions and the way the TEAM's data cable is wired.

[paulsherwin]

It sounds as if there may be a flow control problem. This was always one of the less well standardised parts of modem operation. Some modems use RTS/CTS signalling, some waggle DSR on and off, some do it in software with XON/XOFF characters, and so on. The devices at each end have to be correctly configured to use the appropriate handshaking with their modems or buffer overruns will take place.

This can be a real headache when connecting differing devices and modems, and I'm profoundly grateful I don't have to deal with it any more. Now you've found a solution that works I suggest you stick with it

[JohnBHanson]

When in dos run debug
A>debug
-d40:0
(Note output)
-q


This will display the bios data area. The first 4 words (8 bytes) are the addresses of
the com ports that the bios has detected. This should help. Com 1 should be
at address 3f8 and com2 at address 2f8

Hope that helps.