Announcement

**Lance Edmonds** · 8 Jan 2001, 05:03 AM

I've seen similar reports with PC104 embedded PC's... the most common successful solution is to install appropriate memory managers (HIMEM.SYS & EMM386.EXE).

Please let us know if this helps!

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**Wyman A Belts** · 8 Jan 2001, 07:22 PM

Hi Samir,
I program for the DAP PC9500 in PB DOS 3.5. You might try disabling
timeouts in the open statement like so:

OPEN "COM1:19200,N,8,1,RS,CS,DS,CD" As #1 Len = 4096.

Maybe there's some differences since the PC9800's a Windows
machine, but it works on the 9500. I just completed an
upload/download program for it yesterday. Anyway, good luck, and
let me know how this turns out, please.

------------------
[email protected]

**Samir Alamari** · 8 Jan 2001, 10:19 PM

Dear Lance,
Please note that these devices do not have extended memory as such, and as a result any memory managers would not load in the first place.

Dear Wyman,
There are several models of the PC9800. This problem cannot be reproduced on a PC9500 because of the different design. The PC9800 one we are actually using is DOS-based.
As for the communication, we actually rely on the Communication pgm supplied with the unit COM.EXE and it is powerful enough for all our requirements.
Our problem is that it will not recognize the optical interface after running a PB35 EXE program, even if that pgm is a simple PRINT "HELLO"

All,
What I need is overhead code generated by PB35 with EXE file for a simple PRINT "HELLO" pgm.
One of the interrupts is causing this malfunction.
Again for QB45 this is not the case.

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

**Lance Edmonds** · 8 Jan 2001, 10:45 PM

You have noted that you experimented with all compiler & linker settings, but it does not solve the problem. PowerBASIC/DOS does not cause any problems of this kind with "proper" PC's, so it suggests that you could be facing a simple (in)compatibility problem.

One thought does come to mind... have you tried switching off all unnecessary libraries from the runtime library ($LIB ALL OFF)?

Note that if your real code will use the CHAIN statement, then the primary EXE will automatically include all library modules (regardless of the $LIB setting) since there is no way for the linker to predict which RTL functions may be required by the called PBC/EXE module, so the complete RTL is included in the EXE.

IOW, if you solve the problem for a PRINT "HELLO" app, you may face the same problem with "real" code, depending on what it does.

What interests me is what you plan to do to solve the problem, assuming you can establish which hooked Interrupt is the cause? I simply don't see a solution, since altering the RTL itself would be required. Either that, or you'll have to change the way the hardware works...

FYI, the Interrupts that the PowerBASIC runtime library uses are described in the Users Guide (in the chapter on TSR's, IIRC. I'm sorry, bit I don't have my copy handy to give you a page reference).

One more idea: does code compiled with FirstBASIC cause this problem too? You can download the shareware version from our FILES section if you wish to experiment.

Do you or anyone else have any comments or ideas?

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**Samir Alamari** · 9 Jan 2001, 01:03 AM

I will take your points one by one.

$LIB ALL OFF - Just tried this and received exactly same result

To solve the problem - The device itself has a built-in set of device specific BIOS function calls, which are probably being disabled unintentionally by PB pgm. As such I would issue the appropriate BIOS function call to restore the settings.
As a followup please note that I have issued the device-specific BIOS function calls for Restore to Factory Settings, and for enabling the Optical Port, and setting the appropriate communication channels, but none of these is restoring the functionality of the optical port to the status prior to running the PB pgm, and as such they are not 're-enabling' the optical port.

As for the chapter on TSR's I am not able to locate it in the 2 manuals but will continue to look.

As for FirstBasic, I have downloaded the compiler and made two PRINT "HELLO" programs.
Unfortunately both gave identical behaviour to PB, disabling the Optical Port upon exit.

I'm open to other suggestions or comments on the above

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

**Samir Alamari** · 9 Jan 2001, 01:07 AM

Addendum

FirstBasic-The two pgms were one with $LIB ALL OFF and the other without.

Nothing restores the functionality of the Optical Port except a RESTART of the device.

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

**Lance Edmonds** · 9 Jan 2001, 01:13 AM

I'm sorry, but I'm fresh out of ideas.

I'll ask R&D about this, but I suspect we are not going to be able to help you with this problem since PB/DOS works with all "normal" hardware without any problems whatsoever.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**Gary Akins** · 9 Jan 2001, 05:41 AM

Actually, I've been having a similar problem with straightforward laptop PC's (standard serial-port connections, no infrared stuff). A PB/DOS 3.5 program containing the following code:

Code:

$COM 8192
ComHandle% = FREEFILE
OPEN "COM1: 57600,N,8,1,DT" AS ComHandle% LEN=2048
PRINT "COM port opened"

will "jam" at the OPEN statement - no error messages, no device timeouts. (I once left it sitting overnight to see if it would ever come back, and when I returned the next morning it was still "stuck"; it will apparantly wait forever for whatever condition it wants that it isn't seeing.) [CTRL][BREAK] will get me out of the program and back into the IDE, so I don't think the program has shot off into nowhere...

Further, once this occurs, the COM port is completely lost to me - exiting to DOS and then restarting PowerBASIC has no effect, and no other serial-port-using programs (like Telix or Procomm) can open the COM port either - they, too, get "stuck". This has happened on two different laptops - my Gateway Colorbook, and one of our company Dell laptops - and on an Ampro 4DXi PC-104 board. (But, interestingly, it never occurs on my own Dell Latitude XPi laptop.) For the Dell and the Ampro, a reboot is sufficient; the Gateway actually has to be power-cycled off and on again to get the port back.

A little experimentation has yielded the following information:

----- The problem seems to be caused by the system at the other end of the null-modem cable sending bytes before PowerBASIC has executed the OPEN COM statement.

----- The type of null-modem cable has no effect; I've tried both full crossover cables, and simple Tx/Rx/GND-only cables.

----- The various OPEN COM handshake-control options such as DS0, CD0, etc. have no effect on the problem one way or the other.

----- When the "jam" occurs, using the CALL INTERRUPT statements to query the BIOS services directly, as follows:

Code:

REG %AX, &H0300        '--invoke INT 14h, service 3
REG %DX, &H0000        '--  ("Get Comm Port Status")
CALL INTERRUPT &H14 '--   against COM1
PRINT HEX$(REG(%AX))

returns 61h in the AH register, and 00h in the AL register. According to my copy of "Using Assembly Language, 3rd Edition" (Allen L. Wyatt, QUE Corp., 1992, p.532) this corresponds to an "Overrun Error' in the line status register.

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

**Lance Edmonds** · 9 Jan 2001, 03:13 PM

Ok folks, I've heard back from PowerBASIC R&D...

Firstly, R&D suggest that it is possible that the design of the hand-held could such that it is doing something non-standard with one or more interrupts, such as the &H2F multiplex interrupt that PowerBASIC uses to query the environment.

Unfortunately, R&D are unable to offer any suggestions as to a workaround or cure. They did note to me that there is a curious lack of technical data on DAP's web site, which does not help much!

Gary, your observation is correct - PowerBASIC may not open a port that already has data in the input buffer - R&D have noted this for investigation. However, it is not related to Samir's problem...

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**Alan Earnshaw** · 9 Jan 2001, 05:19 PM

Samir,

What brand and version of DOS is running on the handheld computer?

Alan

------------------
Alan C. Earnshaw
Information Management Systems, Inc.
http://www.infoms.com

**Samir Alamari** · 10 Jan 2001, 02:33 AM

Gary,
It seems that our problems are similar in as far as the communications port is disabled following a PB pgm is terminated.
However, Lance is correct as my problem occurs even following a normal termination of a simple EXE pgm, that does not involve any communications routines. This does not happen on a normal PC.

Lance,
I have a PDF file containing detailed descriptions of the interrupts supported and used by the DAP unit.
Basically there are special handling of Standard BIOS interrupts
Int5H Print Screen Routine
Int10H Display Services
Int11H Equipment List
Int12H Memory Available
Int13H Disk Services
Int14H Serial Communications Services
Int16H Keyboard Services
Int17H Printer Services
Int1AH Real Time Clock Support

Extended BIOS interrupts, have been grouped into Int15H, and include functions for controlling and modifying the devices.

I can forward these PDF files if needed by anyone.
re AP web site---I agree

Alan,
the DOS brand and version is a standard MS-DOS v 6.22

All,
Thanks for the replies and inputs

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

**Lance Edmonds** · 10 Jan 2001, 02:39 AM

Please email the file to Tech Support and I'll pass it to R&D, but please do not hold your breath for a solution.

Out of curiousity, have you asked DAP for help with this problem on their equipment? Surely they must have a Tech Support department?

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**Samir Alamari** · 10 Jan 2001, 04:18 AM

Lance,
I will email the file, as for DAP tech support, I have actually not contacted them as the problem is isolated to PowerBasic only, and is not evident in other compilers/linkers.

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

**Gary Akins** · 10 Jan 2001, 06:53 AM

Lance Edmonds wrote:
Gary, your observation is correct - PowerBASIC may not open a port that already has data in the input buffer - R&D have noted this for investigation. However, it is not related to Samir's problem...

OK, I just thought it might have some bearing because of the seemingly similar end result, of no other program being able to open the port afterwards...

While we're on the subject, though, is there any known workaround for this? A BIOS call, or bytes INP/OUT'ed directly to the COM-port hardware itself, that can force it back into a condition that PB/DOS can open? We're getting ready to ship an embedded-systems product driven by a PowerBASIC program, running on the above-mentioned Ampro 4DXi, and one of the things that it needs to be able to do is to have a GPS receiver plugged in to one of the COM ports... and many these off-the-shelf GPS systems (we don't have any control over what GPS device they use) transmit data continuously.

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

**Lance Edmonds** · 11 Jan 2001, 01:53 AM

R&D have perused the PDF's... here is what they came back to me with:

In a PRINT "Hello" program, PB/DOS does make a number of interrupt calls
that are not supported by the PC9800. It is not clear what the results would
be. These are INT 10h video calls for retrieving EGA/VGA information:
functions 1009h, 1200h, and 1A00h. The PC9800 emulates CGA graphics.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**Ian Cairns** · 11 Jan 2001, 07:35 AM

Lance,
Does R&D say that these interrupts are included in the executable
even if the Options/Compiler/Linker/Graphics is set at off,
or if the ../Linker/Video Cards/VGA is set to off?
Curious in Canada,

------------------
[email protected]

**Mike Luther** · 11 Jan 2001, 08:16 AM

And for note Lance .. and others..

Gary, your observation is correct - PowerBASIC may not open a port that already has data in the
input buffer - R&D have noted this for investigation. However, it is not related to Samir's
problem...

------------------
Lance
PowerBASIC Support

Observed in remote site telecommunications applications where PB 3.5 programs are asked
to open a port in OS/2 sessions that have been contaminated by any previous comm port
failure!

This also happens to be one way to totally dishevel an OS/2 system, still! If a previous
port applicatopn has terminated improperly, leaving an "ownerless" thread, with data still
in the object space that was assigned to the 'bufffer', there seems no possible way I have
ever found yet in OS/2, to ever recover the use of it until you re-boot!

Further, under certain circumstances, if it does, somehow, it may, at times, produce a
SYS3175 or other trap error, and you need to realize that the resultant trap error will then
float up to the top of the Desktop in OS/2. At that point, there is absolutely no way
that I've ever found that any keyboard I/O can ever clear anything without being on-site
to do it. Only the *LOCAL* keyboard will clear that ring level screen message! So, if
you obtain this type error in OS/2, and the system is a remote system, even one with full
remote Desktop access, such as HyperAccess and HuperHost, even in an IP instance of it as
a VPN, you will still have to either go to the site, or, in some fashion, hardware reboot
the site remotely to recover it!

Now, just because I can't break this, and 'MOLE" and other task killers can't break it
that I have tried, does not mean that it can't be done. It just means I'm not educated
enough to know how to do it! Chuckle.

Obviously, a 'one track mind' pure 'DOS' operation, isn't quite the same thing as the
pre-emptive multi-tasking game, but the issue is there, and far more distructive, to my
experience in OS?2, than it may be otherwise.

It is *NOT* a fault of PowerBasic and PB 3.5, as far as I can tell. But trying to
open it can lead to the long trip on the road out to reset things! It would be a
kindness to those who face it in OS/2, if PB's R&D could somehow, also know that a
port shouldn't be, what do we say, 'accessed', if it isn't empty to start with?

Strange wish! Kind of like, "How do I get to love you if I've never met you?"
Secret soy sauce? But I've been told I'm not very 'objective' about these things!
Can anyone be? Grin!

------------------
Mike Luther
[email protected]

**Tom Hanlin** · 11 Jan 2001, 08:33 AM

The test program was built with $LIB ALL OFF.

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

**Wyman A Belts** · 11 Jan 2001, 03:08 PM

I write stuff for the 9500 (an earlier version of Samir's
Handheld with DOS 5.0) which is CGA also and it works fine. One
thing Samir, do you have the UART set for Auto in the setup program?
Just a wild guess, but I keep all our "bricks", as we call them,
in auto mode.

------------------
[email protected]

Announcement

Serial Interface Problems

Serial Interface Problems

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment