Board index » delphi » BP7 mit > 64 MB RAM

BP7 mit > 64 MB RAM

Hallo!

Warum rebootet BP7 meinen PC (hat 224 MB RAM) wenn ich es von Plain DOS
7.x aus starten will?

Gru?

Markus

 

Re:BP7 mit > 64 MB RAM


Markus Humm wrote in <3CAF1B0A.9010...@freenet.de>

Quote
> Warum rebootet BP7 meinen PC (hat 224 MB RAM) wenn ich es von Plain DOS
> 7.x aus starten will?

  Sorry but I don't understand German :(
  But I believe you asked: How to give access to all memory (more than
64M)?
*  In real mode:
1) use XMS 3.0 functions (see Ralf Brown's Interrupt List, for example)
2) use Flat Memory Model (as I remembered it's title:). For example I have
6K zip-archive with sources demonstrated this feature
<======== ========>
  This pretty short example shows how to access all memory installed on
computer. This works under pure DOS. Don't laugh! It's true. Tihs is
available since i386 processor has been launched! I don't know why
programmers didn't use this before. It's a sort of mestery. And people
didn't have to use Windows and those uneasy memory managers such as
himem.sys, emm.exe, qemm.exe, etc. The way used in this examle is
the easiest, if you know i386 processor architecture quite good. :)
I don't want to explain details but this really works. In fact, DOS
programmers can use all megabytes of their computer memory freely.
Look through the sources.

                             Requirements:

  - i386 or better processor
  - more than 1MB memory installed
  - pure DOS (not Windows, without memory managers listed above)
  - you should program in assemler language, if you want your program
    runs fast, because pascal routines are too slow

                                            Author: Alexei A. Frounze

E-mail: alex...@chat.ru
Homepage: http://www.chat.ru/~alexfru
<======== ========>
3) with XMS 2.0 functions you can work with a number of handlers by (up to)
64M for each

*  In protected mode (with RTM.EXE) I didn't work but I here about utility
RTMSWAP (or so) that able to add swaped-memory (from disk of course) to
64M-barrier

--
   Varjonov Konstantin       varkos^mail.ru      http://ghsrl.newmail.ru

Re:BP7 mit > 64 MB RAM


Try to set SET DPMIMEM=MAXMEM 32767

 Klaus Weires

Re:BP7 mit > 64 MB RAM


Opps! Sorry to write in german. What you thought about my question was a
little bit wring, but about that topic I'm searching for info tto. But
you solution is of no use for me because:

- I need DLLs, so I need DPMI (BP's DPMI provides DLLs and there is some
   "hack" for 321 bit as well but with that {*word*193} 64 MB limit)

- the program shall run under Extenders or Windows 9x to avoid
   complicated configuration or reboots for the user...

But: thanks anyway!!

Greetings

Markus

Re:BP7 mit > 64 MB RAM


Quote
Markus Humm wrote:
> Hallo!

> Warum rebootet BP7 meinen PC (hat 224 MB RAM) wenn ich es von Plain DOS
> 7.x aus starten will?

> Gru?

> Markus

setting DPMIMEM worked, but I wonder why it crashed anyway. As far as I
can remember this PC had 96 MB before upgrading and BP worked without
DPMIMEM var!

Greetings

Markus

Re:BP7 mit > 64 MB RAM


"Konstantin V. Varjonov" <var...@ktk.ru> wrote in message <news:01c1dd9f$d1146d80$LocalHost@varkos>...

Quote
> Markus Humm wrote in <3CAF1B0A.9010...@freenet.de>

> > Warum rebootet BP7 meinen PC (hat 224 MB RAM) wenn ich es von Plain DOS
> > 7.x aus starten will?

>   Sorry but I don't understand German :(
>   But I believe you asked: How to give access to all memory (more than
> 64M)?
> *  In real mode:
> 1) use XMS 3.0 functions (see Ralf Brown's Interrupt List, for example)
> 2) use Flat Memory Model (as I remembered it's title:). For example I have
> 6K zip-archive with sources demonstrated this feature
> <======== ========>
>   This pretty short example shows how to access all memory installed on
> computer. This works under pure DOS. Don't laugh! It's true. Tihs is
> available since i386 processor has been launched! I don't know why
> programmers didn't use this before. It's a sort of mestery. And people
> didn't have to use Windows and those uneasy memory managers such as
> himem.sys, emm.exe, qemm.exe, etc. The way used in this examle is
> the easiest, if you know i386 processor architecture quite good. :)
> I don't want to explain details but this really works. In fact, DOS
> programmers can use all megabytes of their computer memory freely.

Flat mode is the way to go for fast,simple, crashproof code. The only
problem is debugging, since you cannot place variables in a watch
window.

Here is the solution:

http://mr_monett.tripod.com/frm.htm

Best Regards, Mike

Re:BP7 mit > 64 MB RAM


Quote
Markus Humm <markus.h...@freenet.de> wrote in message

news:3CB16CE3.2020200@freenet.de...
Quote
> Markus Humm wrote:

> > Hallo!

> > Warum rebootet BP7 meinen PC (hat 224 MB RAM) wenn ich es von
> > Plain DOS  7.x aus starten will?

> > Gru?

> > Markus

> setting DPMIMEM worked, but I wonder why it crashed anyway. As far as I
> can remember this PC had 96 MB before upgrading and BP worked without >

DPMIMEM var!

Quote
Markus Humm <Markus.H...@freenet.de> wrote in message

news:3CB16EC0.7000405@freenet.de...

Quote
> Why has BP7 some problems when used on PCs with more than 64 MB
> RAM?
> Mine always rebootet the PC. Solution to set DPMIMEM works, but I want
> to know the technical reason! Loading 32RTM.EXE before works too.
> If I set DPMIMEM too high (higher than 49000) it rebbots again.
> Where is the problem? I tried under MS DOS 7.10 (without GUI) and under
> DR DOS 7.03. Both the same. If started from W95b it works, but W95b
> gives only a few MB to BP7 (not quite satisfactory).
> Since I want to use all memory in my DOS based apps, this is very annoying.

The problem lies with DPMI16BI.OVL (the DPMI server/DOS extender) and possibly
RTM.EXE supplied with BP 7.0x. Go to my website (downloads page) and get GV or
my GVFM demo. In them are new versions of the above that seem to have no
problems. It also supports DPMI function 0800h which is required for accessing
the Linear Frame Buffer of modern SVGA video cards. The only caveat is that
this version of DPMI16BI.OVL (which is really a virtual memory-disabled
version of DPMI32BI.VME) requires Himem.sys or some other XMS services
provider. The available memory limit is still 64MB, though it won't balk if
your machine has more memory than this.

BTW, the built-in DPMI server from DR DOS 7.03 is buggy - don't use it.

--
Jay

Jason Burgon - Author of "Graphic Vision"  GUI for DOS/DPMI
=== Free LFN capable Dos/WinDos replacement and ===
=== New Graphic Vision  version 2.21 available from:  ===
http://www.jayman.demon.co.uk

Re:BP7 mit > 64 MB RAM


Quote

> Flat mode is the way to go for fast,simple, crashproof code. The only
> problem is debugging, since you cannot place variables in a watch
> window.

> Here is the solution:

> http://mr_monett.tripod.com/frm.htm

> Best Regards, Mike

The problem is the missing DLL support in flatmemory mode and the
problems with some memory managers like EMM386, or am I wrong?

I need DLLs for dynamic drivers and I don't like to throw away that
widely supported concept for something selfmade which wouldn't have that
acceptance then. My program shall be multilanguage: C and BP DLLs shall
be possible...

Greetings

Markus

Re:BP7 mit > 64 MB RAM


OT: I read you use cute mouse as your favourite mousedriver for GV? There's a new 2.0 beta out which

supports the mouse wheel on PS/2 ones...I tried it already and it works! Included is the wheel API documentation!

Great stuff!
Wouldn't that be nice for GV too?

Markus

Re:BP7 mit > 64 MB RAM


Quote
> The problem lies with DPMI16BI.OVL (the DPMI server/DOS extender)

Already thought that...

Quote
> and possibly
> RTM.EXE supplied with BP 7.0x. Go to my website (downloads page) and get GV or
> my GVFM demo. In them are new versions of the above that seem to have no
> problems. It also supports DPMI function 0800h which is required for accessing
> the Linear Frame Buffer of modern SVGA video cards.

Ah good! Want that feature too one day...

Quote
> The only caveat is that
> this version of DPMI16BI.OVL (which is really a virtual memory-disabled
> version of DPMI32BI.VME) requires Himem.sys or some other XMS services
> provider.

That's no problem...

Quote
> The available memory limit is still 64MB, though it won't balk if
> your machine has more memory than this.

Hm, even if HIMEM.SYS provides more than 64 MB? That can't be changed
without the source of this OVL, am I right?

If yes, why not ask Borland to release it?

Quote

> BTW, the built-in DPMI server from DR DOS 7.03 is buggy - don't use it.

Didn't want to use that, but thanks for the hint! I only use DPMS for
some of their drivers...

Greetings

Markus

Re:BP7 mit > 64 MB RAM


Quote
Markus Humm <markus.h...@freenet.de> wrote in message <news:3CB2D015.5010901@freenet.de>...

> > Flat mode is the way to go for fast,simple, crashproof code. The only
> > problem is debugging, since you cannot place variables in a watch
> > window.

> > Here is the solution:

> > http://mr_monett.tripod.com/frm.htm

> > Best Regards, Mike

> The problem is the missing DLL support in flatmemory mode and the
> problems with some memory managers like EMM386, or am I wrong?

> I need DLLs for dynamic drivers and I don't like to throw away that
> widely supported concept for something selfmade which wouldn't have that
> acceptance then. My program shall be multilanguage: C and BP DLLs shall
> be possible...

> Greetings

> Markus

Hi Markus,

When you talk about DLL's I assume you mean the ones used with
Windows.

Yes, Flat Mode has no DLL support. The cpu is running in real mode,
and it cannot execute code above 1meg due to the 16-bit stack. Alexei
Frounze briefly mentioned a technique of remapping memory in clax to
make blocks of addresses above 1 meg appear to start at zero, but this
would be tricky to implement and would not work with DLL's larger than
1meg.

My problem with DLL's is the "DLL Hell" in distribution. You have to
include each DLL used with your code to ensure everyone has a copy of
the version needed by your software.

After a while, your distribution ages and becomes down-level. Users
end up with multiple copies of the same DLL scattered on their hard
disk, which can cause no end of headaches since they do not know which
one is correct.

If you do not distribute the DLL with your code, you have to check
every version of code that was ever released to ensure that someone
does not install a copy that contains a bug that kills your code. This
is an  impossible task.

Another problem with DLL's is you really have no idea what is in them,
unless you happen to have the source code. So you have no way to tell
what kind of problems might occur with different combinations of
hardware and software, and you have no way to correct any problems
that might occur. If your goal is to produce software that will be
widely distributed, it might be better to write your own drivers so
you know what is in them and can solve the myriad problems that users
will have with different hardware configurations.

I'm not sure including DLL's would give your code wider acceptance.
Many people are familiar with the problems they cause, and may be
reluctant to use your code when they see that you depend on them. I
know I get very suspicious of code that assumes I will have some
needed component on my hard disk. I prefer code that is completely
self-contained, because it tells me the author has taken the trouble
to ensure his code will work no matter what version of DLL I may have
on my disk.

If I am mistaken about your intended use of DLL's, please let me know.

The EMM386 problem is solved with the alternative versions discussed
in my article. I found it causes a 50% drop in hard disk performance
due to the multiple translations between EMM386 and Himem. I rarely
use it, but I'm sure many people depend on it since it also provides
more memory for DOS.

Best Regards, Mike

Re:BP7 mit > 64 MB RAM


Quote

> If I am mistaken about your intended use of DLL's, please let me know.

Yes you are, but it's not your fault!
I need the DLLs for implementing drivers and filters.
=> modular design with DLLs

My DLLs are no Windows DLLs but 16 bit DOS DLLs (which are indeed
possible with BP7 and some C compilers). My project shall be extensible
by other programmers not directly belonging to it. The necessary API
will be described and explained somewhere on the net and there will be
SDKs then (if my project ever comes so far). Each of the DLLs for my
project must have some defined functions to return the version number of
the DLL, the version of the main programm the DLL needs, the CPU it
needs, whether it needs a FPU or FPU emulation, the language of the
messages included in the DLL etc. so my main programm (and some little
utility supplied with it) can read this information and act acordingly.
The DLLs won't be spread over the whole HDD too, because they only
belong to my app. and not to Windooze. I hope you see clear now about my
intention to use DLLs. And since such DLLs are "relatively" cross
compiler among PASCAL and C I think this would help the support through
external programmers most.

Greetings

Markus

Re:BP7 mit > 64 MB RAM


Quote
Markus Humm <markus.h...@freenet.de> wrote in message <news:3CB3DDF5.9040901@freenet.de>...

> > If I am mistaken about your intended use of DLL's, please let me know.

> Yes you are, but it's not your fault!
> I need the DLLs for implementing drivers and filters.
> => modular design with DLLs

> My DLLs are no Windows DLLs but 16 bit DOS DLLs (which are indeed
> possible with BP7 and some C compilers). My project shall be extensible
> by other programmers not directly belonging to it. The necessary API
> will be described and explained somewhere on the net and there will be
> SDKs then (if my project ever comes so far). Each of the DLLs for my
> project must have some defined functions to return the version number of
> the DLL, the version of the main programm the DLL needs, the CPU it
> needs, whether it needs a FPU or FPU emulation, the language of the
> messages included in the DLL etc. so my main programm (and some little
> utility supplied with it) can read this information and act acordingly.
> The DLLs won't be spread over the whole HDD too, because they only
> belong to my app. and not to Windooze. I hope you see clear now about my
> intention to use DLLs. And since such DLLs are "relatively" cross
> compiler among PASCAL and C I think this would help the support through
> external programmers most.

> Greetings

> Markus

Sounds interesting! What kind of filters, and what do the drivers do?

I assume you intend to supply binaries, and each programmer will use C
or Pascal as desired. Can you debug a DLL by simply loading the source
in the de{*word*81} and setting a breakpoint at the desired location? My
guess is it should work fine in C if the OBJ file is compiled with
debug info.

Do you plan on making the source for the DLL's available? What happens
if there is a bug and the owner of the DLL has lost interest or moved
to a deserted island?

Best Regards, Mike

Re:BP7 mit > 64 MB RAM


Hi Markus,

Quote
Markus Humm <markus.h...@freenet.de> wrote in message

news:3CB2D0E3.20400@freenet.de...
Quote
> OT: I read you use cute mouse as your favourite mousedriver for GV? There's

a new 2.0 beta out which
Quote

> supports the mouse wheel on PS/2 ones...I tried it already and it works!

Included is the wheel API documentation!

Yes I know, I helped write it!  (look in the CuteMouse credits) :-)

Quote
> Great stuff!
> Wouldn't that be nice for GV too?

Way ahead of you. Download my latest GVFM demonstation distro, run gvfm.exe
under DOS with Cutemouse 2.xx loaded, and feel the wheel! ;-)

CuteMouse-style wheel support will be in the next official release of GV
(version 2.30), to be announced in the next 2-4 weeks.

--
Jay

Jason Burgon - Author of "Graphic Vision"  GUI for DOS/DPMI
=== Free LFN capable Dos/WinDos replacement and ===
=== New Graphic Vision  version 2.21 available from:  ===
http://www.jayman.demon.co.uk

Re:BP7 mit > 64 MB RAM


Hi Markus,

Quote
> Hm, even if HIMEM.SYS provides more than 64 MB? That can't be changed
> without the source of this OVL, am I right?

Correct. It obviously uses the old 2.x XMS services, which places a limit at
64MB (2^16 * 1k = 64MB).  See the XMS spec if you're interested in the
details).

Quote
> If yes, why not ask Borland to release it?

We asked Borland for a new BP for DOS - nothing
We asked Borland to release BP7 - nothing
We asked Borland to release the missing bits of the BP7 RTL source (Graph,
Overlay and the x87 emulator) - nothing.

You ask! :-)

There may be one more problem - The DPMI server/extenders were not written by
Borland, they simply bought or commissioned them from Ergo.

Quote
> > BTW, the built-in DPMI server from DR DOS 7.03 is buggy - don't use it.

> Didn't want to use that, but thanks for the hint! I only use DPMS for
> some of their drivers...

You should be ok there then - I've personally never encountered any problems
with their DPMS driver.

--
Jay

Jason Burgon - Author of "Graphic Vision"  GUI for DOS/DPMI
=== Free LFN capable Dos/WinDos replacement and ===
=== New Graphic Vision  version 2.21 available from:  ===
http://www.jayman.demon.co.uk

Go to page: [1] [2]

Other Threads