Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#101 problems with serial i/o on Intel D2500HN motherboard

open
nobody
FreeCOM (7)
5
2013-11-26
2012-12-13
Charles Patton
No

Problems with SIO show in at least two ways:
1) type in: "copy file.txt con:" The file will be displayed on the screen, but then the following line is issued:
Unable to write to file 'con'
2) type in "copy file.txt com2:" FreeDOS returns three lines:
file.txt => com2
Error reading from device COM2: write fault
(A)bort, (I)gnore, (R)etry, (F)ail?
This test is basically done without a real modem on the port -- just a scope, so handshake lines aren't activated.

Type command "MODE" and what is returned is:
.*** SERIAL PORT 1 STATUS ***
Port status: [ xmit-shift-empty xmit-hold-empty ]
.*** SERIAL PORT 2 STATUS ***
Port status: [ xmit-shift-empty xmit-hold-empty ]
...more report follows

Using DEBUG 'D" shows that at 40:0 and 40:2 (BIOS addresses to show where SIO port addresses should be), shows the proper 0x3F8 and 0x2F8 respectively, but
DEBUG "D 0:3f8 3FF" shows all zeros
DEBUG "D 0:2f8 2FF" shows all zeros
None of the data of the SIO settings are being returned

Another data point. The point of this project was to use new Intel D2500HN motherboards to replace 20-year old 386 motherboards used in a automation control setup before those old motherboards failed. The control program used is QuickBasic. Everything seemed to be going fine. I used Rufus to make bootable USB sticks, then added the old files for QB and pgms. Nothing seemed wrong. DOS booted and QB pgm started and SIO link was being transmitted to. But then the fun started. The SIO link wasn't responding Much troubleshooting later I realized that the link was transmitting 4800,N,8,1, not 4800,E,8, 2 as originally designed and cannot be changed as it is transmitting to Motorola MC14469's, where the format is built into the silicon. Here a bit of explanation is necessary. When you initialize the SIO port in QB you cannot use com2:4800,e,8,2 because of a flaw in QB of a 10 bit TX buffer. But I had the work around as follows:
OPEN "com2:4800,n,8,1,bin,ds0,cd0,cs0" FOR RANDOM AS #2
OUT &H2FB, &H1F 'this dings the SIO chip LCR (Line Control Register) to put it into even parity, 2 stop bits
But this is not working on the Intel bd. I also tried:
OPEN "com2:4800,n,8,1,bin,ds0,cd0,cs0" FOR RANDOM AS #2
SHELL "MODE com2:4800,e,2"
This also doesn't work -- nothing changes.

So in summary, this probably isn't directly a FreeDOS problem, but MODE doesn't seem to be working properly here, either. I am fairly certain it's a BIOS problem on the Intel bd talking to the Winbond W836270HG-P legacy I/O chip using the LPC bus.

One other point of interest -- a web search found "http://lists.freebsd.org/pipermail/freebsd-stable/2012-July/068802.html"
where they did a load dump and look at time(?) 3.580072]
[ 3.580072] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
[ 3.600806] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 3.621608] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[ 3.672837] 00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 3.693711] 00:0b: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A

So a Linux load seems to get the same answer -- but I don't understand the "00:0a:" in "[ 3.672837] 00:0a: ttyS0"

This is beyond my level of competence -- I'm hoping maybe someone can shed some light on this problem.
Thanks,
Charles Patton

Related

Bugs: #101

Discussion

  • Charles Patton
    Charles Patton
    2012-12-13

    Well, as Emily Latella of Saturday Night Live would say, "Never mind!" I'm just too rusty at this stuff. Once I started using the DEBUG I and O for port I/O, then the 0x3f8 and 0x2f8 addresses started to function.
    OPEN "com2:4800,n,8,1,bin,ds0,cd0,cs0" FOR RANDOM AS #2
    OUT &H3FB, &H1F
    I hadn't noticed that the D 40:1 returned F8 02 F8 03. So the BIOS is flipping the port addresses to the software QB pgm, but my OUTPUT statement went to the wrong port.
    Sorry to have bothered you.

    I appreciate having FreeDOS in order to keep my 20-year old dinosaur pgm working. Rebuilding from scratch would really be unbearable.

    Thanks again for FreeDOS,
    Charles Patton

     
  • Stas Sergeev
    Stas Sergeev
    2013-11-26

    We have investigated the same problem
    under dosemu recently:
    https://sourceforge.net/p/dosemu/support-requests/261/?limit=10&page=2#3ebc

    DOS reads an LSR but doesn't check its
    bits properly, and keeps sending chars
    with int14h even when the LSR.THRE bit
    is not set.
    If int14h doesn't do busy-wait for THRE
    before xmitting, we have a problem.
    While in dosemu the int14 code was altered,
    my opinion is that DOS should do better
    job here.

     
    • Charles Patton
      Charles Patton
      2013-11-26

      My apologies, I figured out a solution and some insight on this problem
      subsequent to my original post and I should have posted it. A quote
      from my pgm describing the problem and the solution. Immediately
      following is the commented out problem code followed by the fix information:

      '*** port 1
      ' OPEN "com1:4800,n,8,1,bin,ds0,cd0,cs0" FOR RANDOM AS #2
      ' OUT &H3FB, &H1F
      'next line must happen before the open statement -- something in QB
      ' creams the bios entry when it executes
      DEF SEG = &H40: port2LCR = 3 + PEEK(2) + &H100 * PEEK(3)'so now have
      port adr
      OPEN "com2:4800,n,8,1,bin,ds0,cd0,cs0" FOR RANDOM AS #2
      'The reason for the next statement is explained at:
      ' support.microsoft.com/kb/39342
      ' as the MC 14469's used in the switch plates require 4800,e,8,
      ' it is incompatible with QB's ability. The next statement
      ' places the required change into the Line Control Register and sets
      ' 8 bit data, even parity, and 2 stop bits
      ' a further complication was that during the update to the
      ' Intel D2400HN motherboards, there is a switch between COM1 & COM2
      ' using the BIOS mem loc of 40:0 and 40:2 for the SIO port base addrs
      ' careful reading of the Tech Spec for the INtel bd indicates a possible
      ' layout error and the hardware COM ports were interchanged.
      ' It must have been decided to flip them in the BIOS so following fix
      should work
      ' for any motherboard including the
      ' Intel bd, so this uses the BIOS link to point to correct out port
      adr of
      ' LCR (=base adr +3)
      ' next statement moved up above so is before OUT instruction
      'DEF SEG = &H40: port2LCR = 3 + PEEK(2) + &H100 * PEEK(3)
      PRINT "port2LCR is "; HEX$(port2LCR)
      OUT port2LCR, &H1F 'finally set 8,E,2

      Hope this explains what went wrong -- a combination of a couple of problems.
      Regards,
      Charles R. Patton

      On 11/26/2013 1:33 PM, Stas Sergeev wrote:

      We have investigated the same problem
      under dosemu recently:
      https://sourceforge.net/p/dosemu/support-requests/261/?limit=10&page=2#3ebc

      DOS reads an LSR but doesn't check its
      bits properly, and keeps sending chars
      with int14h even when the LSR.THRE bit
      is not set.
      If int14h doesn't do busy-wait for THRE
      before xmitting, we have a problem.
      While in dosemu the int14 code was altered,
      my opinion is that DOS should do better
      job here.


      [bugs:#101] http://sourceforge.net/p/freedos/bugs/101/ problems
      with serial i/o on Intel D2500HN motherboard

      Status: open
      Labels: FreeCOM
      Created: Thu Dec 13, 2012 04:12 AM UTC by Charles Patton
      Last Updated: Thu Dec 13, 2012 04:12 AM UTC
      Owner: nobody

      Problems with SIO show in at least two ways:
      1) type in: "copy file.txt con:" The file will be displayed on the
      screen, but then the following line is issued:
      Unable to write to file 'con'
      2) type in "copy file.txt com2:" FreeDOS returns three lines:
      file.txt => com2
      Error reading from device COM2: write fault
      (A)bort, (I)gnore, (R)etry, (F)ail?
      This test is basically done without a real modem on the port -- just a
      scope, so handshake lines aren't activated.

      Type command "MODE" and what is returned is:
      . SERIAL PORT 1 STATUS
      Port status: [ xmit-shift-empty xmit-hold-empty ]
      . SERIAL PORT 2 STATUS
      Port status: [ xmit-shift-empty xmit-hold-empty ]
      ...more report follows

      Using DEBUG 'D" shows that at 40:0 and 40:2 (BIOS addresses to show
      where SIO port addresses should be), shows the proper 0x3F8 and 0x2F8
      respectively, but
      DEBUG "D 0:3f8 3FF" shows all zeros
      DEBUG "D 0:2f8 2FF" shows all zeros
      None of the data of the SIO settings are being returned

      Another data point. The point of this project was to use new Intel
      D2500HN motherboards to replace 20-year old 386 motherboards used in a
      automation control setup before those old motherboards failed. The
      control program used is QuickBasic. Everything seemed to be going
      fine. I used Rufus to make bootable USB sticks, then added the old
      files for QB and pgms. Nothing seemed wrong. DOS booted and QB pgm
      started and SIO link was being transmitted to. But then the fun
      started. The SIO link wasn't responding Much troubleshooting later I
      realized that the link was transmitting 4800,N,8,1, not 4800,E,8, 2 as
      originally designed and cannot be changed as it is transmitting to
      Motorola MC14469's, where the format is built into the silicon. Here a
      bit of explanation is necessary. When you initialize the SIO port in
      QB you cannot use com2:4800,e,8,2 because of a flaw in QB of a 10 bit
      TX buffer. But I had the work around as follows:
      OPEN "com2:4800,n,8,1,bin,ds0,cd0,cs0" FOR RANDOM AS #2
      OUT &H2FB, &H1F 'this dings the SIO chip LCR (Line Control Register)
      to put it into even parity, 2 stop bits
      But this is not working on the Intel bd. I also tried:
      OPEN "com2:4800,n,8,1,bin,ds0,cd0,cs0" FOR RANDOM AS #2
      SHELL "MODE com2:4800,e,2"
      This also doesn't work -- nothing changes.

      So in summary, this probably isn't directly a FreeDOS problem, but
      MODE doesn't seem to be working properly here, either. I am fairly
      certain it's a BIOS problem on the Intel bd talking to the Winbond
      W836270HG-P legacy I/O chip using the LPC bus.

      One other point of interest -- a web search found
      "http://lists.freebsd.org/pipermail/freebsd-stable/2012-July/068802.html"
      where they did a load dump and look at time(?) 3.580072]
      [ 3.580072] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
      [ 3.600806] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
      [ 3.621608] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
      [ 3.672837] 00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
      [ 3.693711] 00:0b: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A

      So a Linux load seems to get the same answer -- but I don't understand
      the "00:0a:" in "[ 3.672837] 00:0a: ttyS0"

      This is beyond my level of competence -- I'm hoping maybe someone can
      shed some light on this problem.
      Thanks,
      Charles Patton


      Sent from sourceforge.net because you indicated interest in
      https://sourceforge.net/p/freedos/bugs/101/

      To unsubscribe from further messages, please visit
      https://sourceforge.net/auth/subscriptions/

       

      Related

      Bugs: #101