I have never seen a RAMdisk that was not file-based
Maybe we have a misunderstanding here.. The driver itself
is of course a file, but the disk is a DOS block device,
so for DOS it is just a bunch of sectors. The DOS kernel
will then use those sectors as a FAT filesystem which can
contain
On Thu, 20-Aug-2009 11:27:47, Christian Masloch c...@bttr-software.de
wrote:
I have never seen a RAMdisk that was not file-based
Maybe we have a misunderstanding here ... The driver itself
is of course a file, but the disk is a DOS block device ...
NO misunderstanding, and that is exactly
Hi!
the moment, JEMMEX already is too fancy for many ancient DOS
games which use pre-VCPI DOS extenders, so it is good that
HIMEMX and JEMM386 are still separately available.
Also, isn't JEMM actually FreeDOS's memory manager of choice? I suppose
there was such a thing as FreeDOS EMM
Hi Jack,
Ah okay... So there would be a separate API, and separate
memory areas for XMS 2/3 and the new API then?
Absolutely! Forgetting XMS V2.0 (only 64-MB), I am suggesting that
all XMS V3.0 requests for 4-GB remain as-is, using the first 4-GB of
memory. XMS V4.0 commands, if we
On Wed 19-Aug-2009 13:06:42, Eric Auer e.a...@jpberlin.de wrote:
Ah okay... So there would be a separate API, and separate
memory areas for XMS 2/3 and the new API then?
Absolutely!
Hmmm then on one hand only new apps could use XMS 4, but on the
other hand, old apps would not have any
Hi Jack,
Note that the new apps will also have to use XMS 3 to get the
3-GB or similar that will be free in the first 4 GB because no
sane XMS 3 app will use much of those 4 GB... ;-)
I mean if you have some XMS 4 ramdisk then it should also
allow combined usage of XMS 3 and 4, otherwise it
On Wed 19-Aug-2009 14:21:04, Eric Auer e.a...@jpberlin.de wrote:
I mean if you have some XMS 4 ramdisk then it should also
allow combined usage of XMS 3 and 4, otherwise it would
leave the first 4 GB unused ... Would be somewhat wasteful.
I agree, and that is why local data such as UIDE's
JEMMEX could use big pages or
PAE or both to access more RAM for various things, but this
always leads to the question: How compatible will it be? At
the moment, JEMMEX already is too fancy for many ancient DOS
games which use pre-VCPI DOS extenders,
I think any protected-mode memory manager
On Tuesday 18 August 2009 15:18 (CEST), Christian Masloch wrote:
so it is good that
HIMEMX and JEMM386 are still separately available.
Separately from what?
Separately from each other...
Jemmex is a two-in-one driver, but you can use HIMEMX and JEMM386 as two
separate drivers, too.
Best
On Tue, 18-Aug-2009, Christian Masloch c...@bttr-software.de wrote:
so it is good that HIMEMX and JEMM386 are still separately available.
Separately from what?
Regards,
Christian
Separately from MS-DOS, FreeDOS, or other DOS variants, since few if-any
of their EMM drivers are still under
so it is good that HIMEMX and JEMM386 are still separately available.
Separately from what?
Separately from MS-DOS, FreeDOS, or other DOS variants, since few if-any
of their EMM drivers are still under maintenance, and as some have never
corrected BUGS!
I support your intention (i.e. JEMM
Hi Bernd,
Jack is right, pipeline based DVD burning saves a lot of space
for temp files. Of course you are also right - you cannot easily
put temp files on harddisk if the harddisk only has NTFS etc and
it would be asking a bit much to add another harddisk. Well, of
course DOS USB (storage)
Hi Jack,
No one is suggesting an API only for MEM! Also, my ideas about new
XMS commands are only for 64-GB memory, NOT for current XMS commands
Ah okay... So there would be a separate API, and separate
memory areas for XMS 2/3 and the new API then?
It is only necessary if you have tools
Eric,
My Thanks for your support of what you all call pipelining
(I call it simultaneous I-O) in our discussions with Bernd, in
your earlier post today.
No one is suggesting an API only for MEM! Also, my ideas about new
XMS commands are only for 64-GB memory, NOT for current XMS commands
Hello,
2) Do not support a super allocate, just let XMS clients alloc
memory as long as it is available - but start in the first 4 GB
and/or use memory after that easy area only for big allocs...
3) You need no outside-visible super extended move as long as
only XMS access to the extra
Op 14-8-2009 23:37, Jack schreef:
Oh, REALLY?? I have been running the DeepBurner program to shoot my
CD/RW masters for over two years now. It DOES simultaneous input/output
with the disk staying-ahead of the CD/RW and always having the next block
of data ready to be written out. It is a
On Fri, 14 Aug 2009 15:57:55 -0700, Eric Auer e.a...@jpberlin.de wrote:
Hi Jack,
Re: using memory over 4-GB in DOS, the best way to AVOID many new
custom programs is to raise the capacity of XMS drivers...
1) A change to the XMS request which determines available memory,
with a change
Hi Jack,
1) Do not tell MEM about the extra memory, just tell it that you
have 3 GB as long as at least 3 GB are still available ...
This might materially confuse users, who expect MEM to report actual
available XMS memory. Since MEM is only reporting numbers to users
I see no reason
Eric,
... Since MEM is only reporting numbers to users I see no reason
why MEM cannot remain honest about what is does.
MEM could - but all XMS 2 and XMS 3 apps will be more
confused about a too honest XMS 4 driver... And to
add a whole new API only for MEM...?
No one is suggesting an API
Eric,
Sorry, in my last post I meant to say Int 15h AH=87h move-
memory requests, not AH=80h.
Jack R. Ellis
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report
On 14-Aug-2009 13:13, MegaBrutal wrote:
Who ever needs a 64-bit version of DOS, especially if you need
to emulate an entire processor while achieving it? 32-bit is
just fine. I don't know why would anyone switch to 64-bit for
DOS since people don't even use the advantages out. Of course
Op 14-8-2009 20:17, Jack schreef:
Re: using memory over 4-GB in DOS, the best way to AVOID many new
I am assuming here that, to keep things simple and still-useful
for programs that cannot or will-not be upgraded, the XMS drivers
will all behave same-as-before for current XMS commands. User
I pretty much agree. I actually don't really need or even want access to even
the full 4GB that a 32-bit CPU allows, but would like what's there to work
correctly no matter how much memory there actually is. My newest computer came
with 6GB (64-bit Vista), which I multi-boot to DOS. I had to
On Fri, 14 Aug 2009 11:43:17 -0700, Bernd Blaauw bbla...@home.nl wrote:
I don't know if it's easier or harder to do, but maybe best approach is
twofold :
1) First 4GB handled traditionally for programs, ramdisks, diskcaches
etc.
2) Ramdisk driver that can handle all memory beyond 4GB
Op 14-8-2009 21:18, Jack schreef:
This would work. But, if we are to cook up a new scheme to handle
memory beyond 4-GB, why limit it only for RAMdisk usage? If the XMS
drivers/handlers support such large memory, EVERYBODY could use it!
yes, as long as older programs don't use it by
On 14-Aug-2009 21:18, Jack wrote:
... But, if we are to cook up a new scheme to handle memory beyond
4-GB, why limit it only for RAMdisk usage? If the XMS drivers/
handlers support such large memory, EVERYBODY could use it!
yes, as long as older programs don't use it by accident. Guess
Hi Jack,
Re: using memory over 4-GB in DOS, the best way to AVOID many new
custom programs is to raise the capacity of XMS drivers...
1) A change to the XMS request which determines available memory,
with a change to the FreeDOS MEM program to display all such
memory. I believe
27 matches
Mail list logo
