Announcement

**Mel Bishop** · 11 Sep 2003, 06:11 AM

Don't think my original response was accurate.

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

**Aldo Cavini** · 11 Sep 2003, 06:36 AM

mel, i first replied too fast...

the reason i open the port, close and repoen is because it is not clear if the width statement works after the port has opened. from the printed manual:

if the device has already been opened, its width setting is not changed...

the trick to open, close and reopen is derived from the sample by matthias kuhn, at http://www.powerbasic.com/support/pb...read.php?t=789

aldo

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

[this message has been edited by aldo cavini (edited september 11, 2003).]

**Mel Bishop** · 11 Sep 2003, 06:39 AM

Okay. Sorry you saw my original post. It was knee jerk which
shouldn't have happened.

I haven't tried this but you may want to:

width "com1:",10
open "com1:.....

i.e., set the width then open the port.
------------------

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

**Aldo Cavini** · 11 Sep 2003, 06:50 AM

Mel,

I tried also what you suggested. Nothing changed - no CRs added. Is it possible it depends on the BIOS or the OS?

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

**Tom Hanlin** · 11 Sep 2003, 08:54 AM

WIDTH works on "a device opened for output". Your OPEN is for RANDOM access.

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

**Mel Bishop** · 11 Sep 2003, 09:44 AM

Aldo's post got me curious so I finally found an old x486 running
pure dos 6.2 with a modem in it. Wrote the following test code:

Code:

        $lib all off
        $lib com on
        color 14,1
        cls

        a$ = string$(80,"A")

	width "com2:",10
rem	open  "com2:1200,n,8,1,rs,cs,ds,cd" for output as #1
rem	open  "com2:1200,n,8,1,rs,cs,ds,cd" for append as #1
rem	open  "com2:1200,n,8,1,rs,cs,ds,cd" for random as #1
	open  "com2:1200,n,8,1" for output as #1
        width "com2:",10

        delay 1
        print #1,"atz"
        delay 5
'-----------
	for x = 1 to len(a$)
	print #1,mid$(a$,x,1);
rem	print #1,mid$(a$,x,1)
	next x

rem	print #1,a$;
rem	print #1,a$
'-----------
        do until inkey$ <> ""

        if not eof(1) then
        t$ = input$(1,#1)
        print;t$;using$("### ",asc(t$));
        end if

        loop
        close #1
        end

Tried every possible combination. The un-rem'd lines that didn't
error out did not produce the desired results. i.e., no Cr's
every 10th character.

What are we missing?

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

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

**Tom Hanlin** · 11 Sep 2003, 02:15 PM

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

**Mel Bishop** · 11 Sep 2003, 04:07 PM

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).]

**Aldo Cavini** · 11 Sep 2003, 10:14 PM

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).]

**Tom Hanlin** · 11 Sep 2003, 11:05 PM

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** · 12 Sep 2003, 01:57 AM

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:

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.

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

**Clay Clear** · 12 Sep 2003, 02:24 AM

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** · 12 Sep 2003, 03:37 AM

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** · 12 Sep 2003, 03:46 AM

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.

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

**Mel Bishop** · 12 Sep 2003, 06:37 AM

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.

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

**CC Tung** · 12 Sep 2003, 07:51 AM

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

**Davide Vecchi** · 12 Sep 2003, 07:55 AM

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]

**Mel Bishop** · 12 Sep 2003, 09:03 AM

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.

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

**Tom Hanlin** · 12 Sep 2003, 11:54 AM

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

Announcement

Comm and Width

Comm and Width

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment