Hi,
On Mon, Jun 30, 2014 at 12:30 PM, Zbigniew wrote:
> 2014-06-30 19:19 GMT+02:00, Rugxulo :
>
>> IIRC, 4DOS can swap out (since it's quite large) to conserve
>> conventional memory. You may have to change that setting (SWAPPING ??
>> I forget ...). I don't think it's something inherently wrong
On Mon, Jun 30, 2014 at 1:30 PM, Zbigniew wrote:
> 2014-06-30 19:19 GMT+02:00, Rugxulo :
>
>> IIRC, 4DOS can swap out (since it's quite large) to conserve
>> conventional memory. You may have to change that setting (SWAPPING ??
>> I forget ...). I don't think it's something inherently wrong with
>
2014-06-30 19:19 GMT+02:00, Rugxulo :
> Hi,
>
> On Sun, Jun 29, 2014 at 7:05 PM, Zbigniew wrote:
>>
>> No, no such exotic options,
>
> Well, I would maybe recommend "I=TEST X=TEST".
I used - and still use - exactly the two above.
> IIRC, 4DOS can swap out (since it's quite large) to conserve
> c
Hi,
On Sun, Jun 29, 2014 at 7:05 PM, Zbigniew wrote:
>
> No, no such exotic options,
Well, I would maybe recommend "I=TEST X=TEST".
> and using JEMM386 didn't help
Again, I think it's better to LOAD and UNLOAD from cmdline (JEMM386)
when needed to avoid such problems.
> - but I located the p
2014-06-29 21:16 GMT+02:00, Rugxulo :
> I don't know which versions exactly, but AFAIK, Turbo C tries to use
> EMS by default (if found) but not XMS (without some cmdline switches).
> So who knows if it's getting confused here. Remember that 32 MB of EMS
> is a lot (to it)!
>
> Are you using any s
Hi,
On Sun, Jun 29, 2014 at 8:45 AM, Zbigniew wrote:
> 2014-06-29 15:25 GMT+02:00, Mateusz Viste :
>
>> I am not sure it's related to the XMS manager you use.
>
> Unfortunately, it seems to be related.
>
>> It's rather a matter of the amount of conventional memory you have.
>
> No, it was what I
Strange then. Maybe Jemmex provides more memory overall, but it's
fragmented for some reasons? MEM should tell you the size of the longest
contiguous block in memory ("largest executable block size" IIRC).
Mateusz
On 06/29/2014 03:45 PM, Zbigniew wrote:
> 2014-06-29 15:25 GMT+02:00, Mateusz V
2014-06-29 15:25 GMT+02:00, Mateusz Viste :
> I am not sure it's related to the XMS manager you use.
Unfortunately, it seems to be related.
> It's rather a matter of the amount of conventional memory you have.
No, it was what I checked first before posting.
> Maybe when using
> XMGR you end up
I am not sure it's related to the XMS manager you use. It's rather a
matter of the amount of conventional memory you have. Maybe when using
XMGR you end up with more free memory < 640K than when using Jemmex?
Mateusz
On 06/29/2014 03:20 PM, Zbigniew wrote:
> What I also noticed, Turbo C 2.01
What I also noticed, Turbo C 2.01 doesn't like JEMMEX - while having
around 32 MB of EMS and 1 GB of XMS, I cannot switch to shell from its
IDE; it complained: "not enough memory, press Esc".
No such problem when using XMGR instead of JEMMEX.
--
Z.
---
2014-06-19 1:05 GMT+02:00, Louis Santillan :
> The uide drivers gets updated rather frequently. Find the latest here <
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/ellis>
Well I used the latest one - and it turned out, that older uide2.sys
is more "Turbo C compatible" than newest
The uide drivers gets updated rather frequently. Find the latest here <
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/ellis>
On Wed, Jun 18, 2014 at 3:39 PM, Zbigniew wrote:
> I noticed another issue while using Turbo C 2.01:
>
> If in the fdconfig.sys there is uide.sys used (or
I noticed another issue while using Turbo C 2.01:
If in the fdconfig.sys there is uide.sys used (or uide2.sys used for
HDD) - the compilation is incredibly slow (100x or 200x times slower).
But it is enough to _not_ use this driver, or to use uide2.sys with
parameter like "/D:CDROM", to have Turbo
On Fri, May 23, 2014 at 4:49 PM, Eric Auer wrote:
>
> Hi!
>
>> After a fresh install of FreeDos, I found turbo c 2.01 is terribly slow to
>> run.
>
> That depends on what you mean by Turbo C. The IDE (editor) of it?
> Compiler? Some program written in Turbo C? What kind of program?
I meant the T
Hi!
> After a fresh install of FreeDos, I found turbo c 2.01 is terribly slow to
> run.
That depends on what you mean by Turbo C. The IDE (editor) of it?
Compiler? Some program written in Turbo C? What kind of program?
> even the speed of scrolling the screen is unacceptable. However,
> when I
After a fresh install of FreeDos, I found turbo c 2.01 is terribly slow to run.
even the speed of scrolling the screen is unacceptable. However, when I
unloaded FDAPM, turbo c became normal.
Is there any work around? Is it a bug in Turbo C or in FDAPM?
---
Pluto
-
16 matches
Mail list logo
