Mail Archives: opendos/1997/09/11/07:15:10
X-Comment-To: Steven D. Sybesma
Hi!
10-σΕΞ-97 11:44 sybesma AT dimensional DOT com (Steven D. Sybesma) wrote to caldera-opendos AT rim DOT caldera DOT com:
> On Wed, 10 Sep 1997, Arkady V.Belousov wrote:
> > What about universal ATAPI CDD driver? Have Caldera plans for it? Most
> > "partial solutions" are (1) problematic (incompatability) and (2) memory
> > greedy (5K for ACER CDD driver, 30K for Sony CDD driver).
> Wouldn't a universal CD-ROM driver be memory greedy by nature?
Not neccessarily. You think, 5K for Acer CDD driver too many? Not
forget - they work not only for Acer CDD...
> The ideal situation would be to use the driver provided by the manufacturer.
Of course, but - (1) they can be too big, (2) they can be buggy or
incompatible with some soft, or (3) they can be missed.
> You don't want code for a bunch of different CD-ROMs loading into memory
> along with the code for just your CD-ROM drive. The smaller the better.
I ask only about ATAPI CDD, but _good_ programmer can write code, which
keep in memory only required code from "a bunch" (if they don't want to
combine they to one code).
> Case in point: I have a Toshiba XM-5302 4x ATAPI drive.
> The driver from Toshiba has the smallest memory footprint of any I've found.
How many?
> The Oak Technology driver that came with my drive is the worst memory hog of
> all three I've tried. There is no more functionality that I've found in it
[...]
> Now, if you could get the complete specs on a particular drive and write the
> driver specifically for it, that would be the ideal situation.
On one of my machine with Intel's Triton chipset (licensed from
Triones) I use Triones' _universal_ CDD driver with 7.5K in size. What about
this? Who wrong - Oak or Triones?
> The only thing that Caldera can do is improve the NWCDEX.EXE program, which
> is not really a driver but is a type of DOS extension to allow the drive to
> communicate with DOS.
This not only "extension", this is _very_ big and _buggy_ extension. :(
NWCDEX eat 2-3 times more memory, than MSCDEX, but with NWCDEX don't work,
for example, Acer Sertek's CD Pro 2.7 CD player. :(
I think, integrating to NWCDEX _additional_ (but optional) universal
CDD driver be great. Also as integrating HIMEM.SYS to EMM386.EXE.
10-σΕΞ-97 14:37 pbranna AT clemson DOT edu (Paul W Brannan) wrote to caldera-opendos AT rim DOT caldera DOT com:
> > Wouldn't a universal CD-ROM driver be memory greedy by nature?
> > The ideal situation would be to use the driver provided by the manufacturer.
> > You don't want code for a bunch of different CD-ROMs loading into memory
> > along with the code for just your CD-ROM drive. The smaller the better.
> With TSR's, it is not a requirement that the entire TSR remain resident,
> only that there is enough memory to load the TSR all at once. The problem
> I see is that the universal CD driver is going to be large at first, but
> will shrink, and so getting it to fit into an upper memory block on
> machines where UMB's are scarce or scattered might be a challenge.
You both forget "selfloading" techniques, used, for example, in
smartdrv. Hower, smartdrv also have bug :( - they load high two module (10K
and 13K), and second module placed high only when there are more than 20K!
Sucks...
- Raw text -