Hi,
On Thu, Mar 15, 2012 at 8:09 PM, Jack wrote:
>
> But, there are a LOT of us who do not use DJGPP and yet COULD use a bit
> more UMB space, to load more/bigger drivers etc.
In fairness, DJGPP is quite widespread, at least in apps, not
necessarily developer tools, though I admit there are alte
Hi,
On Thu, Mar 15, 2012 at 8:23 PM, Eric Auer wrote:
>
>> Thus far, I have been absolutely UNABLE to "break into" a V86 system,
>
> VCPI is there to share protected mode, not to keep you outside.
http://en.wikipedia.org/wiki/VCPI
Yup, developed by PharLap and Quarterdeck, no surprise, as they
Hi,
On Thu, Mar 15, 2012 at 6:35 PM, Bernd Blaauw wrote:
> Op 16-3-2012 0:22, Marcos Favero Florence de Barros schreef:
>
>> I have been using JEMMEX NOEMS, but now I see it is not really necessary.
>> What would you recommend instead?
>
> If not needing UMBs that much to optimise conventional me
Eric,
>> Thus far, I have been absolutely UNABLE to "break into" a V86
>> system ...
>
> VCPI is there to share protected mode, not to keep you outside.
I was discussing "V86", not VCPI. But in my opinion, requiring
VCPI goes a bit too far, since I now have "XMS only" methods for
UIDE/UIDE2 th
Hi Jack,
> Thus far, I have been absolutely UNABLE to "break into" a V86 system,
VCPI is there to share protected mode, not to keep you outside.
But indeed while you are in V86, you have limitations. Running
your stuff in protected mode with HELP of VCPI would fix this,
but it is annoying to nee
>> JEMMEX/JEMM386 also allow VCPI/DPMI to be used,
>
> VCPI, yes, but not DPMI, you don't (necessarily) need EMM386 for that.
Same for VCPI, I suppose -- There are "subroutine packages" that set up
VCPI for a user application, if needed.
>> they allow "mapping" of
>> upper-memory addresses into U
2012/3/16, Rugxulo :
> It shouldn't pause at all if using a generic hard drive, but perhaps
> yours is flash-based, e.g. USB or SSD?? If not, then it's some other
> conflict.
No, STM3320418AS is just common internal HDD, got it attached to
on-board controller. That's why I was surprised by these
>> Intel "giveth" NOTHING, and followeth only "All we want is MONEY!",
>> same as Gates & Co.! In my opinion, absolutely NO excuse for AHCI
>> that a better-written Windows driver could NOT have solved, but for
>> Intel as-always wanting to sell-Sell-SELL new chips!
>
> In fairness, not every per
Hi,
On Thu, Mar 15, 2012 at 7:11 PM, Zbigniew wrote:
> 2012/3/15, Rugxulo :
>
>>> I noticed that pauses while using "edit" shipped with FreeDOS - can it
>>> really be that slow when saving edited file?
>>
>> How big is the file? (Last I checked, FD EDIT only supported 64 kb
>> files.)
>
> Like I
Hi,
On Thu, Mar 15, 2012 at 6:04 PM, Jack wrote:
>
>> Unless you need EMS, you don't truly need JEMMEX itself ...
>
> JEMMEX/JEMM386 also allow VCPI/DPMI to be used,
VCPI, yes, but not DPMI, you don't (necessarily) need EMM386 for that.
> they allow "mapping" of
> upper-memory addresses into UM
Op 16-3-2012 0:50, Jack schreef:
> To test this, I change the first few lines of my CONFIG.SYS file
> which are --
>
> DEVICE=C:\BIN\UMBPCI.SYS
> DEVICE=C:\BIN\XMGR.SYS /W
> DOS=HIGH,UMB
> REM DEVICE=C:\BIN\JEMM386.EXE I=B000-B7FF X=C800-EFFF NOEMS
>
> Normally, I "remark out" (REM
Op 16-3-2012 0:55, Rugxulo schreef:
> stuff, esp. not DJGPP/DPMI things, so I would only do "JEMM386 LOAD"
> and "UNLOAD" at runtime if needed (rarely).
The ability to dynamically load and unload JEMM386 is a nice benefit
indeed. Indeed an XMS/HMA-only environment already provides a pretty
dece
>> Rugxulo, I REALLY think you should check AGAIN running JEMM386
>> without "NOEMS" -- worked fine for me!
>
> In the past I always had EMM386 enabled, and it worked fine. In fact,
> some apps explicitly needed EMS and/or EMM386. But nowadays, FreeDOS
> is so good at keep low RAM free that I don't
2012/3/15, Rugxulo :
>> I noticed that pauses while using "edit" shipped with FreeDOS - can it
>> really be that slow when saving edited file?
>
> How big is the file? (Last I checked, FD EDIT only supported 64 kb
> files.)
Like I wrote: about 2 KB.
> It's a 16-bit real mode editor compiled by a
Hi,
On Thu, Mar 15, 2012 at 5:37 PM, Jack wrote:
>
> Intel "giveth" NOTHING, and followeth only "All we want is MONEY!",
> same as Gates & Co.! In my opinion, absolutely NO excuse for AHCI
> that a better-written Windows driver could NOT have solved, but for
> Intel as-always wanting to sell-Se
Hi,
On Thu, Mar 15, 2012 at 6:50 PM, Jack wrote:
>> Unless you need EMS, you don't truly need JEMMEX itself. Last
>> I checked, I don't think it would let you run XMS only unless
>> you did "NOEMS", and even that still left you in V86 mode.
>
> Did not try this on FreeDOS, but on my "old" V6.22
> Unless you need EMS, you don't truly need JEMMEX itself. Last
> I checked, I don't think it would let you run XMS only unless
> you did "NOEMS", and even that still left you in V86 mode.
To test this, I change the first few lines of my CONFIG.SYS file
which are --
DEVICE=C:\BIN\UMBPCI.SYS
> I noticed that pauses while using "edit" shipped with FreeDOS
> - can it really be that slow when saving edited file?
Try using "EDIT" shipped with V6.22 or V7.10 MS-DOS, which I
find is "not too bad"!
--
This SF email
Hi,
On Thu, Mar 15, 2012 at 6:28 PM, Zbigniew wrote:
> 2012/3/15, Jack :
>
>> Maybe not: I still use a 1986 "WordStar" editor, the only one I ever
>> had "time to learn" well. It is VERY slow at the end of an edit, my
>> guess being that only THEN does it "rename" my previous file with the
>>
Op 16-3-2012 0:22, Marcos Favero Florence de Barros schreef:
> I have been using JEMMEX NOEMS, but now I see it is not really necessary.
> What would you recommend instead?
If not needing UMBs that much to optimise conventional memory, an XMS
manager like XMGR might be sufficient. In addition, U
2012/3/15, Jack :
> Now, under $100 can
> get me about 250-GIGABYTES with at-least a 16-MB write cache! Most
> "IDE commands" used in 1994 can still be used, only a few were added
> since then to support 48-bit LBA addressing (not 28-bit, like then).
Right - and, of course, I set the controller
> Rugxulo:
> Unless you need EMS, you don't truly need JEMMEX itself. Last I
> checked, I don't think it would let you run XMS only unless you
> did "NOEMS", and even that still left you in V86 mode. Granted,
> it should be fine for "most" software, but it's not a perfect
> solution
I do need EMS
>> DOS doesn't use SATA anyways (AFAIK), only IDE compatibility mode.
>
> It's still much faster than the hardware, that I was using in
> 1991. The HDD itself has quite large hardware cache (16 MB -
> incredibly large space compared to 640 KB).
Hard-disks have come a long way. In 1994, I paid
>> I have saved XMGR for "real mode" users who run UMBBCI first, followed
>> by XMGR. In that case, XMGR is able to "read" UMBPCI's table of UMBs
>> and can load there directly, which also uses 0 low-memory like JEMMEX.
>> ...
>
> Unless you need EMS, you don't truly need JEMMEX itself ...
JEMME
>> Actually, it was a bit surprising to me that I still need a software
>> cache ... Well, perhaps the NVIDIA SATA isn't the best fit for DOS.
>
> DOS doesn't use SATA anyways (AFAIK), only IDE compatibility mode.
> It would be even slower without UDMA or a software cache. As to
> why you need it
2012/3/15, Rugxulo :
> DOS doesn't use SATA anyways (AFAIK), only IDE compatibility mode.
It's still much faster than the hardware, that I was using at - say -
1991. The HDD itself has quite large hardware cache (16 MB -
incredibly large space compared to 640 KB).
> But actually even DOS softwar
Hi,
On Thu, Mar 15, 2012 at 3:39 PM, Jack wrote:
>
> I have saved XMGR for "real mode" users who run UMBBCI first, followed
> by XMGR. In that case, XMGR is able to "read" UMBPCI's table of UMBs
> and can load there directly, which also uses 0 low-memory like JEMMEX.
> UMBPCI cannot "map" the B
Hi,
On Thu, Mar 15, 2012 at 2:48 PM, Zbigniew wrote:
>
> Actually, it was a bit surprising to me, that I still need a software
> cache, while using hardware, which - like for DOS requirements - is
> really very fast. Unfortunately, using no caching at all, I noticed
> pauses (3-4 seconds), that o
Zbigniew,
>> Now that JEMMEX is available, HIMEMX + JEMM386 and XMGR + JEMM386 are
>> "historical curios" only, and JEMMEX should be preferred.
>
> That was my guess: "maybe some of them can be even seen as 'obsolete'
> by now".
All still work O.K., however JEMMEX saves all possible 640K memory
2012/3/15, Jack :
> Now that JEMMEX is available, HIMEMX + JEMM386 and XMGR + JEMM386 are
> "historical curios" only, and JEMMEX should be preferred.
That was my guess: "maybe some of them can be even seen as 'obsolete' by now".
> As to the caching drivers, LBAcache may still be a hair faster th
Zbigniew,
> But personally I can't see a reason to dispose of such "low footprint"
> driver "on the fly"; that's why I wrote "this is the question".
Understood, and I do agree with you! XMS and HMA usage were both
suggested to me by Tom Ehlert in 2003, when I wrote my first UDMA.
> Yes, I'm g
But personally I can't see a reason to dispose of such "low footprint"
driver "on the fly"; that's why I wrote "this is the question".
Yes, I'm going to use UIDE2 rather than LBACACHE exactly because it
takes less memory. BTW: there are many (of course, it's very good to
have a choice :) drivers f
Zbigniew,
Forgot to mention in my last post that if you do run
UIDE2 in HMA space with /H, you must limit the cache
to about 325-MB, and with /HL to about 420-MB, since
FreeDOS does not have as much "free HMA" as my V6.22
MS-DOS does. Unlike V7.10+ MS-DOS, "old" V6.22 has
no FAT32 nor "long fil
Zbigniew,
>> Why, after using UltraDMA and caching,
>> would anyone ever WANT to "unload" such a driver??!!
>
> Well, yes, this is the question.
Do tell THAT to all the "unloadable driver" FREAKS, who
have "beset me" in past years about making UIDE unload!
I am glad that you are "on the air" (r
2012/3/15, Jack :
> Why, after using UltraDMA and caching,
> would anyone ever WANT to "unload" such a driver??!!
Well, yes, this is the question.
--
Z.
--
This SF email is sponsosred by:
Try Windows Azure free for 90 d
> Problem (seems to be) solved. Formerly I was using a line:
>
> INSTALLHIGH=C:\FDOS\BIN\UIDE2.SYS
>
> ...and this gave problems. When I replaced INSTALLHIGH with
> DEVICEHIGH -- there are no problems anymore.
>
> I thought, that INSTALL and DEVICE keywords are synonyms for
> fdconfig.sys file,
Problem (seems to be) solved.
Formerly I was using a line:
INSTALLHIGH=C:\FDOS\BIN\UIDE2.SYS
...and this made problems. When I replaced INSTALLHIGH with DEVICEHIGH
- there are no problems anymore.
I thought, that INSTALL and DEVICE keywords are synonyms for
fdconfig.sys file, since I was very l
Hi Zbigniew, Jack
> I must conclude that the problems you are seeing, using JEMMEX
> and UIDE2, are NOT caused by those drivers.
Not necessarily. They just NOT happen on BOTH hardwares,
Zbigniew's and Jack's. Could be A20 or UMB being weaker
on one system than on the other. Still a problem exist
Zbigniew,
For your info, I tested the latest 7-Mar-UIDE2 with the latest
V5.75 JEMMEX on "my own" V6.22 MS-DOS, on V7.10 MS-DOS, and on
FreeDOS. The latter 2 tests were done using the systems from
Lucho's 2008 "boot" diskette.Every system on that diskette
runs with an "old" 4DOS, and the Fr
39 matches
Mail list logo
