Announcement

**Mel Bishop** · 13 Sep 2005, 10:54 AM

Without actual specifics, I'm taking a shot in the dark:

Have you played with the baud rate? Increased/Decreased it? May
have something to do with it.

You running xp may have something to do with it. Do you have a
pure DOS box you can test it on?

Have you tried giving your program a greater time slice?

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

**Aldo Cavini** · 14 Sep 2005, 01:00 AM

Mel, thanks for the reply. I started working on this program on 1992, with Turbo Basic, under plain DOS. Then passed to Windows 3.xx, then WinNT, PowerBasic for DOS, Win 98/me and now WinXP. It still runs perfectly under all those platforms... but WinXP.

About the baud rate, I checked it with the scope - it's perfect. In those rare occasions the stream is not broken into two sections by the "idle hole", the device replies correctly. I suspect it is a WinXP matter, but till now I didn't find the "trick" I need.

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

**Davide Vecchi** · 14 Sep 2005, 03:59 AM

Aldo, maybe this can help: http://forums.parallax.com/forums/de...=7&m=80628&p=2

From the 4th post (top to bottom):

My personal opinion is that somehow MS gave the serial port lower priority in WinXP, causing momentary data hiccups which cause timeouts. This line of reasoning is how I discovered that lowering the FIFO settings helped.

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

**Aldo Cavini** · 14 Sep 2005, 04:58 AM

thanks Davide - I tried to change the tx FIFO on the serial comm, and to change the priority of the DOS window in which my application is running - the "idle holes" are still there, no way to eliminate them.

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

**Aldo Cavini** · 16 Sep 2005, 12:45 AM

I just converted the communication engine to Pb/CC, and it works perfectly. I suspect the problem is in the XP "virtual BIOS"... I'll have a long-long working weekend to translate the whole program...

A question to the PowerBasic staff. Really there is not a way to make COMMs work properly in a DOS window under XP? I have a lot of PbDos test programs I run on my company production lines, and am worried about the following choice: to translate all those programs, or to never upgrade the computers to XP.

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

**Davide Vecchi** · 16 Sep 2005, 04:14 AM

Aldo, i'm curious if this is a general problem of DOS accessing RS-232 ports on WinXP, or something more specific that has to do with PB/DOS. Have you by chance tested this with say QBASIC or some other DOS compiler ?

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

**Aldo Cavini** · 16 Sep 2005, 05:13 AM

Davide,

I tried the following code

Code:

open "com1:4800,n,8,1,cs,rs,ds,cd" as #1
 
do while inkey$ = ""
  print #1, "aldoaldoaldoaldo"
  sleep 0.1
loop

with PbDos and TurboBasic (with Tb I translated the sleep statement into a timer-based loop). The results I got, both compilers, are the same: the tx streams show the "idle holes".

At the moment I don't have other compiler to try.

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

**Davide Vecchi** · 16 Sep 2005, 05:23 AM

Thanks Aldo, this answer my question about whether it's a generic problem of WinXP.

I'm quite interested in this problem; if i'll find some related info i'll post here.

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

**Paul Dixon** · 16 Sep 2005, 05:52 AM

Aldo,
Possible solutions might include:

Changing the priority of your DOS application.

Making sure other programs running on the computer are behaving themselves (well written).

Starting a multimedia timer with a 1ms period in a Windows program on the same machine. It doesn't need to do anything (it just calls an empty function and exits) but it will affect the granularity of the time slices that windows uses so, on a not-too-busy PC your DOS program will get shorter timeslices, but more often so there won't be as much chance of the program being suspended long enough for the COM port FIFO to empty.

<<..am worried about the following choice: to translate all those programs, or to never upgrade the computers to XP.>>

It's not an upgrade to break your working code. That's a downgrade.
If WinXP is not suitable then you don't use it and you tell your client that. If he wants to run the latest and greatest software then he can spend $500 for another PC for the purpose.

Too many people look at PCs as something that must be up to date with current developments or they'll be laughed at. Instead, you should look at a PC for what it is, a tool to do a job.
WinXP is not the appropriate tool for MANY jobs. It imposes HUGE overheads in CPU power, memory and disk requirements, running costs and it reduces performance of any I/O intensive program to below that of a PC with half the power.
After all, your client wouldn't upgrade his transport from a 5 seat family car to a 40 tonne truck just because the truck is newer, would he?

Paul.

PS
Aldo,
a comment on that code you posted.
You're sending out 16 characters every 0.1s at 4800, which gives 480 characters per second.
So, your 16 characters will take 33ms, leaving a 67ms gap before the next block of 16 is ready. Without trying it, I would expect that code to produce gaps on any PC, WinXP or not.

Paul.

[This message has been edited by Paul Dixon (edited September 16, 2005).]

**Aldo Cavini** · 16 Sep 2005, 06:48 AM

Davide,

since PbDos is "son" of TurboBasic, it is likely they behave the same way. I found a grandfather to them: GwBasic! Since it is an interpreted language, no way it has something similar to Tb/Pb. I tried the same code (with line numbers...) and the "idle holes" are still present.

Paul,

tried to change the application priority while no other application is running on my Pc. Also tried to setup the FIFOs. No improvements.

I modified the posted program as to send the frame (it is 18 chars: 16 + CR and LF) once per second. What I see is inside the frame there are "holes" which can last up to 120-150 ms.

About Pc "evolution" you are right: with an old PC XT 8088 I could do everithing I needed. I miss those times when 640K of ram was a dream... Nevertheless, I can't teach today people to live. If a customer wants to use a WinXp based Pc, I can't tell him to return back to Dos 3.0...

Aldo

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

**Paul Dixon** · 16 Sep 2005, 06:50 AM

Aldo,
I've now tested it. WinXP home, DOS3.5 and at all rates from 4800 to 115200 I get no gaps of any kind visible on a 'scope.

Paul.

edit:
Hmm, I've slowed it down to 4800 again and put your 0.1s sleep back in and it's not as good as it was, I'll look into it.

[This message has been edited by Paul Dixon (edited September 16, 2005).]

**Paul Dixon** · 16 Sep 2005, 07:45 AM

aldo,
i think one of your problems is that your dos code attempts to use 100% cpu. it takes no account of being run under windows.
sleep in dos doesn't release a time slice to windows, it just loops using 100% cpu time.
eventually, windows get fed up waiting and takes control from your dos program. unfortunately, this tends to occur while your transmitting because time slices are typically 16ms in winxp and your data takes 36ms to send.

try replacing your "sleep 0.1" with the following :

Code:

  iswindows% = istrue bit(pbvhost,8)
  if ucase$(environ$("os")) = "windows_nt" then iswindows% = -1
 
 t!=timer
 do
         if iswindows% then
         ! push ds
         ! mov ax, &h1680
         ! int &h2f
         ! pop ds
         end if
 
 loop until timer-t!>0.1

which is obtained from here: http://www.powerbasic.com/support/pb...read.php?t=604

paul.

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

**Aldo Cavini** · 16 Sep 2005, 09:31 AM

Paul,

nothing to do! Still having such 50 to 150 ms holes. Thanks anyway. Well, I think there must be a way Windows understands (?!#@#!!!) a DOS application is waiting for... something (I modified the code as you suggested; but, since I suspected was INKEY the statement that caused the problem, I avoided it just creating a FOR NEXT loop to transmit 100 frames). Does someone know how Windows understands it and how to tell Windows it must not be so intelligent?

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

**Paul Dixon** · 16 Sep 2005, 02:51 PM

Aldo,
I did find that increasing the time between frames (use 0.2s instead of 0.1s) OR increasing the bit rate (19200 or more instead of 4800) both did away with any signs of jitter on my system, but I don't get large gaps like you anyway.

Perhaps it's not the DOS program but some other program running and using the time? Presumably you are doing this under Windows because you want to run other programs at the same time. If not, then you'd stick with plain DOS.
Check the task manager to see which application is using all the CPU time.

If you have other badly behaved programs running (e.g.programs like your DOS program that don't give up their time slices!) then the other program(s) may be hogging the CPU when your DOS code needs it and your DOS code is then kept waiting until Windows steps in and forcibly transfers control back to DOS.

Paul.

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

**Paul Dixon** · 17 Sep 2005, 09:22 AM

Aldo,
<<Does someone know how Windows understands it and how to tell Windows it must not be so intelligent?>>

I wouldn't call Windows intelligent! .. but perhaps this registry setting may be worth experimenting with:
http://www.microsoft.com/resources/d...ntry/29623.asp

Paul.

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

**Donald Darden** · 19 Sep 2005, 12:31 AM

I would suggest that you try to run your program, then go into the
Task Manager and start killing off process not related to what you
are doing and see if any of these contribute to the delay. Most
people fail to realize just how many processes might be running
at any one time, and that each one is taking up some portion of
computer memory, cpu time, and other resources. Processes such as
anti-virus and other protection programs can interact with your
efforts to move information in and out of the PC as well.

Also, instead of trying to get by with your own comm routines, you
might want to evaluate some of the 3rd party products which are
often more tightly integrated into the system, and see if you have
the same problem with them. Some of them are capable of supporting
a large number of modems or serial connections at the same time,
at very high connect speeds.

------------------
Old Navy Chief, Systems Engineer, Systems Analyst, now semi-retired

**Aldo Cavini** · 20 Sep 2005, 01:35 AM

... sorry I couldn't reply till now ...

I did some tries looking at the task manager: with a sleep statement, with a timer based do-loop, with the BIOS call Paul suggested. These are the results:

Code:

           | ntvdm | idle
-----------+-------+------
sleep      |  50%  |  50%
timer loop |  50%  |  50%
BIOS call  |  95%  |   5%

I always see the Tx holes - may be I there is some NT-Virtual-Dos-Machine setting to setup. But at last I decided to translate the program to PbCc. Thanks

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

**Donald Darden** · 23 Sep 2005, 04:26 PM

You may have encountered a boundary problem in XP where it has to
emulate DOS Interrupt Calls on behalf of the PB/DOS-generated
program. This effort is not reqired on Windoes 9x/Me machines,
which are effectively a GUI overlay with DOS running underneath.

It might be interesting to find out if this is also a problem with
Windows NT/2K, which share much of the kernel/core processes with
the code in XP. What we call "true" 32-bit operating systems. But
it could also be a result of performance tweaking, I guess, because
a notable problem with Windows is that it's animations can get a
bit jerky if the cpu has a hard time keeping up with tasking
requirements. Faster machines are less prone to this, but the OS
is being continually expanded to provide more services and features.
You might be seeing an effort to de-emphasize (slow down) DOS-
based services so that others can be enhanced as much as possible.

------------------
Old Navy Chief, Systems Engineer, Systems Analyst, now semi-retired

**Aldo Cavini** · 26 Sep 2005, 01:31 AM

Donald,

the program I'm working on ran perfeclty on a 80286! Never had problems with DOS, Win 311, Win 95 and 98. Started having timing problems witn NT 4.0, but the situation becomed dramatic under WinXP pro on a P4 2.8GHz. May be it be worse on the next os... hence I'm translating this critic program to Pbcc. It is not as trivial as I hoped, because of a lot of graphics that can't be translated automatically; but at least I don't have those communication problems I have with PbDos. Thanks

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

Announcement

idle while transmitting on comm

idle while transmitting on comm

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment