Comm and Width

[Aldo Cavini]

Mel,

I think too there is no need to fix the bug (if it is a bug...). If you don't peek the Rx chars, your program doesn't care about the Rx activity. For instance, the ERROR 69 (communication buffer overflow) is only raised when you INPUT the Rx chars (as are raised all the other Rx errors, like parity error). Hence if you open the comm, there is a Rx activity and you don't poll it, you'll never have unexpected Rx errors - this is true if you open the comm either FOR OUTPUT or not.

--------------------

[This message has been edited by Aldo Cavini (edited September 16, 2003).]

[Tom Hanlin]

As far as I know the 8250 UART has no trouble parity and 8-bits, it's problem was the 9600 baud limit.

There was no such limit. The chip could support up to 115,200 bps. Odds are, the CPU
couldn't keep up with anything close to that for very long, but it wasn't due to a UART
limitation.

As for the serial port, it has the option for 8 bits and Even, Odd or No parity!

The software might not have complained, but the hardware did not offer that support, to the best
of my knowledge, and I used to write interrupt-driven serial comm drivers. Could be I'm mistaken,
as it's been a few years. The QB4 docs do have this to say: "If you set the data bits per byte
to eight, you must specify no parity (N)."


------------------
Tom Hanlin
PowerBASIC Staff

[Paul Dixon]

Mel,
without timing it first I'd bet you a pint it boots to a DOS prompt quicker than yours boots to WinXP!

Paul.

--The edit--
Well, I suppose all bets are off. I've dug the computer out.
The hard disk doesn't work so I'm at a disadvantage booting from floppy.

On the other hand, it turns out it's a 8086 8MHz so I'm at a huge advantage over an 8088!

But it only takes 34 seconds from power on to DOS3.2 prompt, beat that with XP! (or98 even)

As for the serial port, it has the option for 8 bits and Even, Odd or No parity!

Paul.


[This message has been edited by Paul Dixon (edited September 15, 2003).]

[Mel Bishop]

Originally posted by Paul Dixon:
...I'll dig my 8088 PC...

Make sure you have a copy of "War & Peace" handy while it's booting


------------------

[Paul Dixon]

Tom,
perhaps there was some software reason for that in early PC's, but I'm not aware of any (at the time I wasn't into PC stuff).

As far as I know the 8250 UART has no trouble parity and 8-bits, it's problem was the 9600 baud limit. If I get around to it I'll dig my 8088 PC out of the loft and confirm it!

Paul.

[Tom Hanlin]

With the original PC UARTs, the only option supported for "8 bits"
was "no parity". It may be that this is no longer a typical hardware
limitation, I don't know.

------------------
Tom Hanlin
PowerBASIC Staff

[Paul Dixon]

Tom and CC,
<<With 8 bits, you can only have "N" parity.>>

The following works fine in PB3.5.
I can confirm it sends out 11 bits, 1 start bit, 8 data bits, 1 Even parity and 1 stop. Change the "E" to "O" in the OPEN COM and it works with Odd parity too.

open "com2:9600,E,8,1,cs0,cd0,ds0" as #1

There is no reason for any restriction in the data format, the number of bits and the type of parity are not linked, they have independent control bits in the UART Line Control Register.

Paul.

[Tom Hanlin]

Is it possiable to config serial port to 9600,E,8,1 in PC?

With 8 bits, you can only have "N" parity.

Aldo, the way you're opening the comm port (open "com1:4800,n,8,1,cs,rs,ds,cd" ...)
will always be handled through PB's own comm support. You don't have to worry about
machine dependencies.

------------------
Tom Hanlin
PowerBASIC Staff

[Mel Bishop]

Originally posted by CC Tung:
Is it possiable to config serial port to 9600,E,8,1 in PC?

I haven't tried it but I doubt it. That configuration would send
8 data bits with an extra parity giving a total of 9 bits.
But go ahead, try it and see what shakes loose.


------------------

[Davide Vecchi]

Originally posted by Mel Bishop:
Well, if it is a bug, please DON'T fix it.

IMO it's correct saying that it's an undocumented and unexpected result,
and personally i would prefer to get an error message when i try to read
from a port i opened FOR OUTPUT.
If one wants to read chars back from the modem he shouldn't open the port
FOR OUTPUT.
If the flow control is software, it has to be done by the app by reading
control chars, so again the port shouldn't be opened FOR OUTPUT.
In my understanding one opens the port FOR OUTPUT only when he doesn't expect
to receive anything.

------------------
Davide Vecchi
[email protected]

[CC Tung]

Is it possiable to config serial port to 9600,E,8,1 in PC?

[Mel Bishop]

Originally posted by Tom Hanlin:
Mel, a file or device opened FOR OUTPUT is not intended to
be used FOR INPUT....it's an undocumented and unexpected result...

Well, if it is a bug, please DON'T fix it. Like I said, I've been
using this technique quite successfully for years (since pb 2.0).

Thinking about it, it does make sense. When one opens a comm port,
one has, by default, both output and input buffers. If the modem
echos the data back to the input buffer, why wouldn't you be able
to fetch data back to the program?

Besides, if the program/hardware is set to software flow control,
the modem (or device) has to be able to tell the software when
to stop transmitting and let it catch up to itself.


------------------

[Clay Clear]

Aldo,

Yes. Back when I was still writing DOS BBS doors software for the
TriBBS BBS, I would open the comm port with the PB "COM" OPEN
command. Then, I would actually output the characters through the
ASM serial port output function I had written. This was only to
"play,", and I was still learning DOS INT's, which is why I did it.
It never served realworld purposes, so my final production apps did not
use it. But, yes, it can be done. And, you should note that the DOS
INT for the serial port only puts out what you tell it to - it does
not add any extra characters. However, I have NO idea if those DOS
services are available on the NT OS's.


------------------

[Aldo Cavini]

Clay,

thanks for the reply, but I don't need such routine. I initiated this forum because I have some communication problems, and started investigating the WIDTH statement to see if there was the possibility of some extra-char automatically inserted by the program. The question if something could change depending on BIOS / OS is still valid. On my dev Pc I'm sure those extra-chars are not added; but what happens on other platforms? Is it possible to switch between Pb driven and DOS driven communication?

Aldo

------------------

[Clay Clear]

Aldo,

I am not sure what the WIDTH command does, as I have never used it,
but if I understand correctly, you need a $CR at the end of, say,
every 10 characters of output? I could write a pure ASM routine to do that
for you in about 10 minutes, if you would like me to?

P.S. I cannot debug the code myself, as I do not have the hardware
for it.


------------------

[Aldo Cavini]

Tom,

what does it mean "COMx" instead of "COMx:"? I tried to use COM1 without the colon, and got ERROR 53 file not found. This applies both to the OPEN and the WIDTH statements.

I cross connected RX and TX between COM1 and COM2, and tried the following code:

$error all on
$dim none
 
open "com1:4800,n,8,1,cs,rs,ds,cd" for output as #1
open "com2:4800,n,8,1,cs,rs,ds,cd" for output as #2
 
cls
do
  do
    if loc( 1 ) then
      color 12, 0
      print input$( 1, #1 );
    end if
    if loc( 2 ) then
      color 14, 0
      print input$( 1, #2 );
    end if
 
    k$ = inkey$
  loop until k$ > ""
  if k$ = "1" then
    print #1, "Aldo____";
  elseif k$ = "2" then
    print #2, "Cavini__";
  end if
 
loop until k$ = chr$( 27 )

The result is I see the Rx chars on both the COMs, even being the ports opened FOR OUTPUT.

------------------

[Tom Hanlin]

A comm port is opened FOR OUTPUT in the event that you have a printer
tied to a serial port, rather than a parallel port... and that's about
it. Used to be, rarely, you'd see that happen. These days, it would be
bizarre, but I suppose there are still a few.

I'm thinking that it's possible that the WIDTH handling only applies to
"COMx" output, not "COMx:" output (DOS-level, rather than PB-level), and
no one has ever noticed because... people hardly ever open a COM port for
OUTPUT, and wouldn't tend to assume that there's a built-in line-wrap
length by default in such cases, anyway.

Mel, a file or device opened FOR OUTPUT is not intended to be used FOR INPUT.
If your INPUT$ method is succeeding here, it's fascinating, but doesn't actually
tell us much about what's going out-- it's an undocumented and unexpected result
of an oversight or bug, and can't be relied on in any particular. A more useful
test would be printing to a serial printer, or to a terminal hooked to the COM2
serial cable.


------------------
Tom Hanlin
PowerBASIC Staff

[Aldo Cavini]

Tom,

I never suspected a serial com could be opened for output... this is a keyword isn't mentioned at all on the reference guide (may be I didn't find it). Nevertheless, as Mel also tried, opening the serial com for output makes it possible to receive chars, and I can confirm che CRs are never added to the stream.

Aldo

[added later]

Well, since I don't need such feature, and since by design a device NOT opened for output doesn't care about WIDTH, I'm confident I shouldn't have problems because of an odd OPEN / WIDTH combination.

------------------


[This message has been edited by Aldo Cavini (edited September 11, 2003).]

[Mel Bishop]

Originally posted by Tom Hanlin:
...It would be a good idea to turn on error checking...

Did that. Program still works with no 10-character delimiter

Is your program successful at opening COM2: for OUTPUT?

Yes. Since the modem echos received (from the computer) characters
back to the input buffer, I can get the characters from the comm
port buffer okay using the "Input..." function. I've used this
technique for years.

How do you see the results of printing to the port?

To the port? I can't. All I can see are the characters being
echo'd back from the modem. Except for the "ATZ"+Cr, they are
all "A 65"'s.

Now if the program inserted Cr's in the string after each 10th
character, the Cr should be received in the echo'd incoming
data stream.




[This message has been edited by Mel Bishop (edited September 11, 2003).]

[Tom Hanlin]

I am thinking that "input$(1,#1)" is not going to do anything useful
with a file that is opened FOR OUTPUT. It would be a good idea to turn
on error checking!

Is your program successful at opening COM2: for OUTPUT? How do you
see the results of printing to the port?


------------------
Tom Hanlin
PowerBASIC Staff