No announcement yet.

Computer hangs - completely unresponsive on compile

  • Filter
  • Time
  • Show
Clear All
new posts

  • Computer hangs - completely unresponsive on compile

    Hi All,

    I am on the way to writing my first PowerBasic DOS application. It is to gather data from some simple serial devices so I based it on the terminal.bas example.

    It took me a few goes to get terminal.bas to compile. I needed to put the full path into the linked file specifications. I got it to compile and run OK.

    I renamed the terminal.bas file, saved it into a work directory and took out the stuff relating to the dialing. The first test is very simple; open the port, get the device to return some standard data and close the port. However, when I hit Run the Compiling pop-up appeared and the computer went completely unresponsive. It did not respond to any keystrokes at all. The only thing to do was power it off and back on again.

    The information on the Compiling pop-up, below the file names, is:

    ......Pass 1 Pass 2

    Free memory: 4144k Time: 00:00

    The PC is a Pentium 120 Compaq notebook with 48 MB of RAM, loaded with DOS 6.22. It runs other apps, including Windows 3.11. It is vary fast and stable. I ran SpinRite on the hard drive to make sure it is OK.

    Other example files compile OK. I have attached the offending BAS file. I would be grateful for any help or suggestions.

    Thanks in advance,

    Attached Files
    Last edited by Robert Keith; 8 Sep 2009, 07:09 PM. Reason: Spelling error

  • #2

    I could not reproduce your situation. It seems to compile OK, clear the screen in blue for a while and then end. Off course I do not have connected a serial device. Maybe the problem has to do with writting to the disk, so try compiling to memory instead.



    • #3
      Simple thing to try...

      Compile to Exe, run exe from command-line, not thru IDE.
      Michael Mattias
      Tal Systems (retired)
      Port Washington WI USA
      [email protected]


      • #4

        I forgot to mention that the .EXE file (56.264 bytes) behaves identically. Run for a couple seconds and end without error. If you post some information of the connected device, maybe I can emulate it's output with a second PC.

        Another test you can perform, in the line suggested by Michael Mattias, is to change the name of the .BAS file so the EXE will have a different name too. This way the operative system will write it in a different place of the disk.



        • #5
          Thank you

          Thank you both for taking the time to help with this. I have no idea what happened. I cloned the disk image to a CF card and ran it in an entirely different (brand new mini embedded) PC with the same results. I would have thought the 13 year old laptop HDD was the prime suspect but it continues to work fine.

          After that I tried a fresh install on the little PC and it works fine. The file compiles with no problems. Now I can continue trying to build something that works.




          • #6
            Robert - shoot me an email if you are interested or do a search for BBSDown! and/or "INter-sceptre" - they are a couple of dos based apps written in PB 3.5 that I sold as shareware - back in teh day.

            There's a LOT of modem calls in there, just looking at your code and think maybe you will want to check out some of the calls I used, have some inline ASM stuff as well - these apps were FAST on responding to the serial devices...
            Scott Turchin
            MCSE, MCP+I
            True Karate-do is this: that in daily life, one's mind and body be trained and developed in a spirit of humility; and that in critical times, one be devoted utterly to the cause of justice. -Gichin Funakoshi


            • #7
              Something i just read and was passing on information if it helps.

              Written by Scott B. Suhy
              When running MS-DOS or Windows version 3.1, serial communications applications that directly access serial port hardware, you may enhance performance of these applications by using software handshaking (xon/xoff) instead of hardware handshaking (cts/rts). Because hardware must be virtualized under Windows NT, checking the cts/rts signals directly will incur an unavoidable performance degradation. Using xon/xoff handshaking avoids this problem since xon/xoff handshaking does not require accessing the serial port hardware directly.
              p purvis