Announcement

**Gary Stout** · 10 Feb 2007, 05:04 PM

Michael,

It has been a long time since I have done anything with PB for DOS,
but you might take a look at the $SEGMENT command if you are not already
using it. If I remember correctly, each segment could use 64k of memory
and "I believe" you could have up to 10 segments. If it is not compiling
due to lack of memory, this should solve the problem. If it is not running
due to lack of memory, I am not sure what the answer is there.

HTH,

------------------
Gary Stout
[email protected]

**Arthur Gomide** · 10 Feb 2007, 05:18 PM

Originally posted by Michael Rosner:
What should i write in the "autoexec.bat/ config.sys" to get max. memory for PB.?

Code:

My config.sys file:
-------------------
;install=c:\pb35\corrdata.exe /set
device=f:\WINDOWS\himem.sys        <<<< mandatory lines for ems
device=f:\WINDOWS\emm386.exe ram   <<<< mandatory lines for ems 
dos=high,umb
buffers=50
files=100
device=f:\WINDOWS\COMMAND\display.sys con=(ega,,1)
Country=055,850,f:\WINDOWS\COMMAND\country.sys

My autoexec.bat file:
---------------------
@F:\ARQUIV~1\GRISOFT\AVG7\BOOTUP.EXE
@if exist c:\checkmbr.exe c:\checkmbr quiet (Validate MBR, not a TSR)
@echo off
verify on
set TEMP=f:\temp
set TMP=f:\temp
path=f:\WINDOWS;f:\WINDOWS\COMMAND;f:\WINDOWS\SYSTEM;c:\;c:\util;c:\uc2;c:\nc5;c:\nu10e;c:\nu8;"F:\Arquivos de programas\Executive Software\Diskeeper\";F:\PBCC30\BIN;F:\PBWIN70\BIN;f:\PBDLL20\BIN
f:\WINDOWS\COMMAND\deltree /y f:\temp\ > nul
mode con codepage prepare=((850) f:\WINDOWS\COMMAND\ega.cpi)
mode con codepage select=850
:: rem keyb br,,f:\WINDOWS\COMMAND\keyboard.sys
lh keyb br,850,f:\windows\command\keybrd2.sys /id:275
doskey
ECHO OFF

------------------
Arthur Gomide
"If you think good architecture is expensive, try bad architecture." -- Brian Foote and Joseph Yoder

[This message has been edited by Arthur Gomide (edited February 10, 2007).]

**Michael Mattias** · 11 Feb 2007, 09:07 AM

Different solutions depending if "out of memory" occurs at compile time or run time.

If at run time, you will have to tweak with the program attributes after it's compiled.

If at compile time, you will have to tweak with the program attributes for PB.EXE (the IDE/compiler)

If this is occurring with "Execute from the IDE" then the first thing you want to try is to compile to Exe then run from command line or shortcut.

[This message has been edited by Michael Mattias (edited February 11, 2007).]

**Jerry Mason** · 12 Feb 2007, 03:11 PM

You can also try:

$ERROR ALL OFF
%StringLimit = 4
$STRING %StringLimit 'Small $STRING argument saves base memory
$STACK 1024 'Small STACK argument saves base memory
$COM 256 'small com buffer size saves base memory

Check all the compile options (the $ commands) to see what
else is available to you.

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

**Michael Mattias** · 13 Feb 2007, 06:44 AM

>Will PBDos 3.5 work better (using EMS or XMS better)

I am reaching way back in Ye Olde Memorie here, but unless I'm mistaken, VIRTUAL arrays (which use EMS/XMS) were new in 3.5, and require you code the VIRTUAL keyword; i.e., 3.2 code will not use EMS or XMS via some magic 'configuration option' and code change(s) are required.

Of course, we still don't know the real problem here.

**Paul Dixon** · 13 Feb 2007, 07:42 AM

Michael,
there are lots of ways to free up more memory.
Check that the arrays you have really need to be the size you've declared them. e.g. if your values are small you might get away with a BYTE array instead of INTEGER in some cases.
Check that the arrays are no bigger than they need to be.
Use local data if possible so it's only using memory when it's really needed.
When you're finished with data, ERASE it so it doesn't keep hogging memory.

If you don't need really fast access to your arrays (e.g. if they're only used occassionally) then change them to random access files on disc. Windows will actually cache them in the huge amounts of memory it has access to so you might not lose much performance.

You might be able to split your program up and CHAIN or EXECUTE one part from the other so only part of the code is in memory at any one time.

Use the right compiler directives in your program

Code:

$CPU 80386                ' run on 80386+ cpu's
$OPTIMIZE SIZE            ' make as small as possible
 
$DEBUG PBDEBUG OFF        ' don't include pbdebug support in our executable
 
$LIB COM        OFF       ' turn off PowerBASIC's communications library.
$LIB CGA        OFF       ' turn off PowerBASIC's CGA graphics library.
$LIB EGA        OFF       ' turn off PowerBASIC's EGA graphics library.
$LIB VGA        OFF       ' turn off PowerBASIC's VGA graphics library.
$LIB LPT        OFF       ' turn off PowerBASIC's printer support library.
$LIB IPRINT     OFF       ' turn off PowerBASIC's interpreted print library.
$LIB FULLFLOAT  OFF       ' turn off PowerBASIC's floating point support.
 
$ERROR BOUNDS   OFF       ' turn off bounds checking
$ERROR NUMERIC  OFF       ' turn off numeric checking
$ERROR OVERFLOW OFF       ' turn off overflow checking
$ERROR STACK    OFF       ' turn off stack checking
 
$FLOAT NPX                ' use floating point hardware only
 
$COM    0                 ' set communications buffer size to minimum
$STRING 1                 ' set largest string size at smallest
$STACK  2048              ' use a small 2k stack
$SOUND  1                 ' smallest music buffer possible

Of course, you only turn off the bits you don't need!

For config.sys try something like this:

Code:

DEVICE=C:\DOS\HIMEM.SYS /testmem :off
DEVICE=C:\DOS\EMM386.EXE noems
BUFFERS=4
DOS=UMB,HIGH
LASTDRIVE=J
FCBS=4,0
COUNTRY=044,,C:\DOS\COUNTRY.SYS
DEVICEHIGH =C:\DOS\DISPLAY.SYS CON=(EGA,,1)
DEVICEHIGH =C:\WINDOWS\IFSHLP.SYS
STACKS=0,0
DEVICEHIGH=c:\dos\ANSI.SYS
FILES=8

If you aren't using VIRTUAL arrays then you don't need EMS support so the noems option frees up extra memory that would otherwise be used for the EMS page frames.
BUFFERS should be set as low as you can get away with. DOS reserves space for these so setting the limit low saves RAM.
DOS=UMB,HIGH make sure DOS loads in otherwise inaccessible ram if it can, freeing up lower memory for your program.
FCBS=4,0 DOS reserves RAM for file control blocks. If you don't need them then set this value low.
LASTDRIVE=J DOS reserves space for each potential drive in the machine. Set this nearer to C to save RAM.
DEVICEHIGH =xxx By default DOS loads device drivers in low memory. Specifying DEVICEHIGH will load it in high memory if it's avcailable, freeing low memory for your program.

STACKS=0,0 Saves on RAM otherwise reserved for unused hardware interrupts
FILES=8 set to the minimum.

For Autoxec.bat

Code:

LH DOSKEY
LH C:\Mouse\mouse.exe /S60 /Z
LH KEYB UK,,C:\DOS\KEYBOARD.SYS

Use LH to load high and programs that you can to free up lower memory for your program.

There's also that useful program called MEMMAKER which came with DOS6.x which will try to set your files for you to make you as much memory as possible.

I'm sure there are more ways..

Paul.

[This message has been edited by Paul Dixon (edited February 13, 2007).]

**Donald Darden** · 18 Feb 2007, 07:19 PM

If you have PowerBasic Console Compiler, it is possible to make
some code changes that will allow you to recompile a PB/DOS
program and run it under Windows. There are, of course, some
significant differences between PB/DOS and PB/CC, and one of the
most significant is that PB/CC requires your main program to be
in its own function, which can be called PBMAIN. You might be
surprised how few changes are needed in order to get the program
to compile and run though. I have a huge, old shareware program
that was originally written under PB/DOS 2.1, and I stuck a
FUNCTION PBMAIN at the top, and END FUNCTION statement at the
bottom, and had about 20 changes to make before it would compile.
This included commenting out a KEY OFF statement, commenting out
five $SEGMENT statements, and converting some alternate I/O
command formats from something like OPEN "I", 1, a$ to OPEN a$
FOR INPUT AS #1. After that, it compiled and ran just fine.

It was a whole lot easier than trying to figure out how to get
Windows or DOS to give me enough menory of the right type so
that I could lick the OUT OF MEMORY problem when I tried to
compile and run the program under either PB/DOS 2.1 or PB/DOS 3.5
Just another thought on the subject. Another real gain with
moving to PB/CC is that the editor and debugger both give you a
whole lot of reason to be glad that you made the move, and the
freedom from memory constraints that you had under DOS is a real
big bonus.

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

[This message has been edited by Donald Darden (edited February 18, 2007).]

Announcement

Out of memory

Out of memory

Comment

Comment

Comment

Comment

Comment

Comment

Comment