Thanks, after using all the excellent advice so far, I am **ALMOST** back
up and running, the environment variable problem has been worked around,
and I have taken onboard the memory saving advice (have about 470k of
conventional memory, which should be ample, how much did billyboy say we
wouln't need anything more than?).
Problem is, now the ghost process is crashing with a read error from the
DVD, which I know don't contain any errors. Could this be related to me
using UIDE.SYS rather than our previous driver (oakcdrom.sys)? Is there
anything I should be aware of? Or any way to help diagnose the error?
My config and autoexec now look like:
Config:
DEVICE=A:\JEMMEX.EXE
SHELL=A:\COMMAND.COM A:\ /E:512 /P
DOS=HIGH,UMB
DOSDATA=UMB
FILES=20
BUFFERS=4
LASTDRIVE=Z
Autoexec:
DEVLOAD /H A:\UIDE.SYS /S511 /D:CDROM1 /H
LH A:\RDISK.COM /S10 /:Y
A:\FREEDOS\SHSUCDX /QQ /D:CDROM1,Z
On 8 March 2012 15:46, Jack <gykazequ...@earthlink.net> wrote:
>
> Mark,
>
> > Yep, just tried Rdisk and it works as expected (when loaded from
> > Autoexec.bat), I can assign a known drive letter and then not have
> > to "faff around" trying to locate the ramdisk using findtdsk.exe.
> >
> > I don't think rdisk was around in 2003 when we set up our stuff
> > originally, which I why we went tdsk route.
>
> I am the author of RDISK, also UIDE and XMGR. Glad you like RDISK,
> which I wrote in 2009 in response to Johnson Lam (my "partner" in my
> DOS activities), who noted HE "did not like" any of the available
> RAM disk drivers, either. So I did a "simpler" driver for him, and
> that is how RDISK came to be!
>
> > Interestingly thou, Rdisk suffered the same problem, that tdsk had,
> > in that we stored the ramdrive disk letter in an environment variable
> > %RAMDRIVE% and our watcom app used a GetVar to retrieve it ...
>
> Not sure if this is a "driver" problem. If you wish, send me an
> E-Mail in private with more detail, and if RDISK can be improved,
> I shall do so.
>
> > One last question, all these memory managers and such, is there a
> > recommended set for a modern PC?
>
> I definitely recommend either JEMMEX (as you are using) or JEMM386
> with a good XMS manager, either HIMEMX or my own XMGR. The other
> "EMM" drivers are all NOT under current maintenance, and many have
> never-fixed bugs!! Japheth works hard to keep his "JEMM" drivers
> current and bug-free, so they are the ones to use.
>
> JEMMEX alone should work fine for most people. If you don't need
> any protected-mode features nor any "extra" upper-memory (B000h to
> B7FFh, i.e. the old "monochrome video" area) that must be "mapped"
> by an EMM driver, you can first run UMBPCI, then load my own XMGR.
> XMGR can "read" the UMBPCI memory blocks and load itself directly
> into upper-memory. XMGR also has "I-O Catcher" logic to "catch"
> and execute diskette I-O (also hard disk I-O until UIDE loads) in
> upper-memory, since UMBPCI's "Shadow RAM" upper memory will not do
> any DMA! "Serious" game fanatics prefer UMBPCI/XMGR, as they are
> slightly faster from not using protected-mode, and many DOS games
> are written for real-mode speed. Except for JEMMEX by itself, or
> UMBPCI + XMGR, other memory-manager drivers are usually unneeded.
>
> > At the moment, my fdconfig.sys looks like:
> >
> > DEVICE=A:\JEMMEX.EXE
> > SHELL=A:\COMMAND.COM A:\ /E:512 /P
> > DOS=HIGH,UMB
> > DOSDATA=UMB
> > FILES=20
> > BUFFERS=20
> > LASTDRIVE=Z
> > DEVICEHIGH=A:\UIDE.SYS /S40 /D:CDROM1
> >
> > and the start of my Autoexec.bat looks like:
> >
> > LH A:\RDISK.COM /S50 /:Y
> > A:\FREEDOS\SHSUCDX /QQ /D:CDROM1,Z
> >
> > Any pointers or help optimizing it further would be appreciated.
>
> Looks good to me! My only comment is that if you always use the
> FreeDOS system, you may want to delay loading UIDE until AUTOEXEC
> runs, in which case you will have to load UIDE with --
>
> DEVLOAD /H A:\UIDE.SYS /S40 /D:CDROM1 /H
>
> DEVLOAD, maintained by Eric Auer, can load .SYS drivers during the
> AUTOEXEC.BAT file (normally, they load during CONFIG.SYS). In my
> example line, the first /H tells DEVLOAD to load UIDE "high", i.e.
> in upper-memory, and the second /H tells UIDE to use free HMA space
> for most of its driver logic. That will save you about 4300 bytes
> of upper-memory. FreeDOS does not make HMA available for drivers
> until AUTOEXEC runs, thus the reason for "delaying" UIDE's loading.
>
> You may also want to give UIDE more than just 40-MB of XMS for its
> cache. The "rule" I recommend, where possible, is to allocate 3
> times the size of your largest cached file, i.e. if your system may
> have to handle up to 100-MB files, then a 300-MB cache works fine:
> 100-MB to cache the "input" file, 100-MB to cache its "output" copy
> during file copies, and 100-MB for directories or other files to be
> SAVED while a big file-copy is going on! If 300-MB is too much or
> if your largest file is used only "occasionally", make the cache 3
> times the size of your largest "most used" file. This scheme will
> avoid UIDE having to discard directories, to make space for a large
> "new" file in its cache, which slows it down a bit when those disk
> directories ultimately need to be re-read!
>
> Finally, unless your WATCOM application requires them, you may want
> to use BUFFERS=4, or at most BUFFERS=10, in your CONFIG.SYS file.
> WIth UIDE present, there is no further need for a large number of
> DOS buffers. UIDE does a much better caching job than the old DOS
> buffers, and by reducing your buffer count, you may save enough HMA
> space to put UIDE "up there" in the HMA, as well!
>
> Best wishes,
>
> Jack R. Ellis
>
>
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
