Re: [Freedos-user] UIDE versus UHDD in freedos 1.2 - and 1.3

[Mercury Thirteen via Freedos-user]

On Saturday, March 28, 2020 6:34 AM, Eric Auer e.a...@jpberlin.de wrote:

> Hi Mercury, some short answers :-)
> I think dates as version numbers are fine when there is no explicit version 
> numbering. I would use the date of the most recent file, leave the decision 
> to you whether that means the version is this week since YOU yourself have 
> made per-driver excerpts of the readmes. Otherwise, use the newest timestamp 
> of the original files, even in situations where only documentation updates 
> took place.

Personally, I would like to assign a new version date to my packages since I've 
made some significant changes... however, I think that also would cause 
unnecessary confusion to existing users of these programs. E.g. "Sweet, a new 
version! Oh, wait... this is the same binary I already had. :(( " So I guess 
I'll leave the versions as-is.

> Regarding sources, please always use source\NAME\FILE.EXT naming. It is no 
> problem to have separate copies of CC in source\uide\cc.asm and 
> source\uhdd\cc.asm when installed. There is an official howto for the 
> directory tree etc. in ZIP files for install friendly packages, somewhere 
> online.

Yep, I think the place to which you're referring is 
[here](http://wiki.freedos.org/wiki/index.php/Package), a page I already knew 
about. Had I just read a little further, I would have seen the answer to this 
problem! lol

> Having two himemx variants to compare sounds like Japheth hopes to get MANY 
> TESTERS so a new update can consolidate into one version again? Or maybe a 
> command line option to pick one of the two styles now represented by two exes?

I think it's to give users a choice, depending on their needs. He mentions they 
both employ a different strategy of allocating blocks - perhaps one is 
First-Fit and another is Best-Fit - and each strategy would work better for 
different users. So he gave them a choice. But Idk, that's just my take on it. 
:)

> I suggest that you give Jerome a signal when you think the packages on your 
> website have been updated to fix all items mentioned by him and fully fdinst 
> / fdnpkg compatible :-)

Will do. Hopefully by the end of the day!

> Thank you for your help! Regards, Eric

No problem. Glad to help!___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE versus UHDD in freedos 1.2 - and 1.3

[Jerome Shidel]

Hi,

> On Mar 27, 2020, at 11:03 PM, Mercury Thirteen via Freedos-user 
>  wrote:
> 
> Hi Jerome, Eric!
> 
> 
> On Friday, March 27, 2020 1:16 PM, Jerome Shidel jer...@shidel.net 
>  wrote:
> 
> Hi Eric,
> I took a quick look.
> There is some minor confusion and package issues and they cannot be replace 
> the current packages “AS-IS”.
> At a glance…
> Are they all newer than the ones already in the repo?
> 
> Since the author did not assign explicit version numbers, I had been 
> generating version numbers based on the date of the most recent modification 
> in the change log section of the readme file. However, since some changes 
> were to the documentation only and did not affect the code, this resulted in 
> a newer version number than the existing package despite the included binary 
> being identical. I had listed the "makeshift" versions on my site, but not to 
> the individual LSM files in hopes I could dig up some "real" final version 
> numbers somewhere. These issues have all been fixed in the versions I 
> uploaded today - all versions listed are pulled directly from the binaries 
> themselves, the LSM files have been modified accordingly, and I also updated 
> the descriptions of the packages to further indicate the differences between 
> my packages and any existing ones on the ibiblio list.

That is understandable. 

As a side note…

The repository management utilities require a version (along with things like 
title and some other mandatory fields). The version information must be unique. 
No two packages with the same filename can have the same version. If a version 
3.34 is in the repo, you cannot add the same package as version 3.34. You would 
need to update its ism to something like 3.34b, 3.34-1, 3.34.1 or whatever. 
There is no specified format for version information. This like “5.13.19”, 
“2019-05-13”, “19-May-13 (pre-1, RP ed)” and etc are all fine.

In the ones I looked at, the Entered-date field in your packages looked fine. 
But, I figured I’d mention that it is strict format of -MM-DD. This is 
enforced by the repo management software to provide a uniform look across all 
packages.

Just some more notes on LSM metadata files.

The required Description field should be fairly short and preferably one good 
sentence to describe the package.

There are a couple addition fields the repo knows that are used for various 
things like html pages and RSS feeds. None of them are required.

Summary: A more detailed description of the package. 

Changes: Simple note on what has changed since the last version. 

Modified-date: Formatted as -MM-DD.nn and if not present will be 
automatically stamped with the current date by the repo. Eventually, this may 
be used by software instead of trying to parse version numbers. 
> For example…, RDISK shows no version in package, web page says 2011-04-25. 
> Repo version is 2015-03-05.
> 
> Can one of you point me to the existing RDisk package (and XMgr too, if one 
> exists)? I only found SRDisk on the ibiblio list.
> 

At present… 

There are two main FreeDOS software repos.

The Official FreeDOS software Repository — (html interface) 
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/pkg-html/index.html
 

My unofficial repository — 
http://fd.lod.bz/repos/current/pkg-html/comparison.html 


The Official repo is where all the packages for a FreeDOS release come from. 
Some packages do not exist on it for various reasons. 

My repo is far less strict. As long as it can be legally distributed, I’m 
willing to include it. It contains all the packages and versions that are in 
the Official repo plus more versions and packages that are not present. 
Sometimes, packages are pushed here prior to being approved for inclusion on 
the Official repo.

At present, neither RDISK or XMGR exist on the Official Repo. 

https://fd.lod.bz/repos/current/pkg-html/rdisk.html 

https://fd.lod.bz/repos/current/pkg-html/xmgr.html 


The others are on both repos.

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/pkg-html/himemx.html
 

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/pkg-html/udvd2.html
 

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/pkg-html/uide.html
 


Someday… Programs like FDIMPLES will be capable of fetching packages and 
updates from multiple online 

Re: [Freedos-user] UIDE versus UHDD in freedos 1.2 - and 1.3

[Eric Auer]

Hi Mercury, some short answers :-)

I think dates as version numbers are fine when there is
no explicit version numbering. I would use the date of
the most recent file, leave the decision to you whether
that means the version is this week since YOU yourself
have made per-driver excerpts of the readmes. Otherwise,
use the newest timestamp of the original files, even in
situations where only documentation updates took place.

Regarding sources, please always use source\NAME\FILE.EXT
naming. It is no problem to have separate copies of CC in
source\uide\cc.asm and source\uhdd\cc.asm when installed.

There is an official howto for the directory tree etc. in
ZIP files for install friendly packages, somewhere online.

Having two himemx variants to compare sounds like Japheth
hopes to get MANY TESTERS so a new update can consolidate
into one version again? Or maybe a command line option to
pick one of the two styles now represented by two exes?

I suggest that you give Jerome a signal when you think the
packages on your website have been updated to fix all items
mentioned by him and fully fdinst / fdnpkg compatible :-)

Thank you for your help! Regards, Eric




___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE versus UHDD in freedos 1.2 - and 1.3

[Mercury Thirteen via Freedos-user]

Hi Jerome, Eric!

On Friday, March 27, 2020 1:16 PM, Jerome Shidel jer...@shidel.net wrote:

> Hi Eric,
> I took a quick look.
> There is some minor confusion and package issues and they cannot be replace 
> the current packages “AS-IS”.
> At a glance…
> Are they all newer than the ones already in the repo?

Since the author did not assign explicit version numbers, I had been generating 
version numbers based on the date of the most recent modification in the change 
log section of the readme file. However, since some changes were to the 
documentation only and did not affect the code, this resulted in a newer 
version number than the existing package despite the included binary being 
identical. I had listed the "makeshift" versions on my site, but not to the 
individual LSM files in hopes I could dig up some "real" final version numbers 
somewhere. These issues have all been fixed in the versions I uploaded today - 
all versions listed are pulled directly from the binaries themselves, the LSM 
files have been modified accordingly, and I also updated the descriptions of 
the packages to further indicate the differences between my packages and any 
existing ones on the ibiblio list.

> For example…, RDISK shows no version in package, web page says 2011-04-25. 
> Repo version is 2015-03-05.

Can one of you point me to the existing RDisk package (and XMgr too, if one 
exists)? I only found SRDisk on the ibiblio list.

> HIMEMX contains two EXE versions? Why?

According to the readme: "Currently there are 2 versions of HimemX supplied, 
HimemX and HimemX2. HimemX2 uses a different strategy when it comes to extended 
memory block allocations."

> Where is the License file that was in previous versions?

Japheth no longer includes it, instead he added a License section to the readme 
file.

> All packages extract sources to the SOURCE path. This is a problem if the 
> user selects install sources. For example, both UHDD and UIDE contain a 
> SOURCE\CC.ASM file. This will collide and cause package installation to fail 
> with FDNPKG and FDINST.

I see that could be problematic, even if they are the same file. I could 
separate CC into its own package, perhaps. Any thoughts from you guys on 
whether or not that's an appropriate way to handle this issue?

> Some other docs seem to be missing. Like UIDE\UIDE.TXT. (may no longer be 
> needed, IDK)

This file was not included in the driver pack from which I split off the 
individual packages, but the existing readme has its own collection of 
technical notes. From that I conclude it no longer applies to the current 
version.

> Unfortunately, I don’t have the spare time to dedicate to carefully go over, 
> verify and adjust them at present.

No problem, I understand how time-consuming this can be!___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE versus UHDD in freedos 1.2 - and 1.3

[Jerome Shidel]

Hi Eric,


> On Mar 27, 2020, at 7:16 AM, Eric Auer  wrote:
> 
> 
> Hi Jerome,
> 
>> The package UIDE contains UHDD.
>> It was updated to the latest versions almost a year ago.
> 
> Mercury has recently created separate packages for
> all different drivers, with separate readme, source
> and so on. Please use those for 1.3, so people do
> not have to search for UHDD in the UIDE package.

I took a quick look.

There is some minor confusion and package issues and they cannot be replace the 
current packages “AS-IS”. 

At a glance… 

Are they all newer than the ones already in the repo? For example…, 
RDISK shows no version in package, 
web page says 2011-04-25. Repo version is 2015-03-05.

HIMEMX contains two EXE versions? Why? Where is the License file that 
was in previous versions?

All packages extract sources to the SOURCE path. This is a problem if 
the user selects install sources. For example, 
both UHDD and UIDE contain a SOURCE\CC.ASM file. This will collide and 
cause package installation to fail with 
FDNPKG and FDINST. 

Some other docs seem to be missing. Like UIDE\UIDE.TXT. (may no longer 
be needed, IDK)

Unfortunately, I don’t have the spare time to dedicate to carefully go over, 
verify and adjust them at present. 

Jerome

___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE versus UHDD in freedos 1.2 - and 1.3

[Eric Auer]

Hi Jerome,

> The package UIDE contains UHDD.
> It was updated to the latest versions almost a year ago.

Mercury has recently created separate packages for
all different drivers, with separate readme, source
and so on. Please use those for 1.3, so people do
not have to search for UHDD in the UIDE package.

Note that UIDE itself should only be used for tiny
boot floppy purposes as UHDD + UDVD2 together are
more modern than UIDE alone, and fix some bugs.

Thank you Jerome and thank you Mercury! :-)

http://mercurycoding.com/downloads.html#DOS
(UDVD2, UHDD, UIDE, RDISK, XMGR, see also my PS)

Regards, Eric

PS: Mercury also made a HIMEMX 3.35 package with
Japheth's updates. Please check how well it works
on both very new and very old computers. It should
be an improvement over Rob Pemberton's "3.34 RP":

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/himem/himemx/



___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE versus UHDD in freedos 1.2 - and 1.3

[Jerome Shidel]

The package UIDE contains UHDD. It was updated to the latest versions almost a 
year ago.

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/pkg-html/uide.html
 


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE versus UHDD in freedos 1.2 - and 1.3

[Eric Auer]

Hi Rugxulo,

Skipping over the FUD undertone, here are some answers :-)

Yes the UHDD updates in 2019 are useful and by the author.

Yes UHDD + UDVD2 works better than using only UIDE alone.

No this is not about RDISK or XMGR updates, although if you
can be more specific, I can check whether ibiblio needs them.

Yes UHDD and UIDE have different performance features
and UHDD is significantly better in various aspects.

Yes UDVD2 is fine in spite of having no recent updates.

Yes EMM386 can have troubles with new hardware. But:
Yes Japheth is updating his EMM386 JEMM right now.

You ask whether anybody should still use UIDE alone:
Probably no. It is a bit smaller. Maybe floppy users.

Yes the 2019 releases of the drivers are free and open.

Regards, Eric



___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE versus UHDD in freedos 1.2 - and 1.3

[Rugxulo]

Gruess Gott,

On Mon, Mar 9, 2020 at 5:59 AM Eric Auer  wrote:
>
> > As far as I'm concerned, UIDE [sic] died in 2015.
>
> Another reason to switch to UHDD and UDVD2.

I meant that I'm only personally aware of the 2015 "drivers" (long ago
abandoned). I was not directly informed of the later "ad hoc" early
2019 update of one, lonely file (UHDD.SYS). So I don't know the
difference because I only ever ran UIDE.SYS (which apparently is
defective or at least designed differently, according to you).

Who even takes credit for the 2019 update? Certainly it can't be the
original developer, can it? He still maintains his closed source
variant (last updated in November 2019), for zero practical advantage.
Why have so many competing variations (market segmentation??)?

> You do know that the 2019 version *does* include full sources
> of UDVD2, UHDD, UIDE and XMGR, I hope.

AFAIK, the developer is aware of and has elsewhere fixed known bugs in
RDISK and XMGR. But none of those fixes were propagated back to the
2015 version (UIDE, aka not XIDE) for FreeDOS on iBiblio. Why is that?

> Replying to my list, you ask for more exact descriptions of the
> improvements in the currently-on-ibiblio 2019 UHDD and UDVD2:
>
> Better performance: UHDD 10% faster with read-ahead than UIDE.

Were these two designed differently? Or is this only in hindsight,
i.e. some 2019-era bugfix of older 2015 code? Why have two separate
versions that behave differently? (There could be a good reason, I
just don't know why exactly.)

> Because UHDD (and UDVD2, in spite of being "old")

"Old" is fine when it works. I'm not complaining about age but moreso
bugs, regressions, restrictions, licensing, redistribution. Also,
having too many subvariants and releases is confusing. It shouldn't be
so fragmented.

> recognize more drives as DMA/UDMA compatible, without false
>  positives, they give much better performance in those cases
> compared to situations where UIDE fails to detect the DMA support.
> This can mean up to several *times* faster in EMM386 context, as
> a BIOS would rarely bother to call the VDMA API to support
> fast protected mode or VM86 disks on DMA and rather use PIO.

I was under the impression that most EMM386s were unreliable on newer
hardware. So I don't try to use them too much. (Then again, CSM is
basically dead, so who cares.)

Yes, Japheth has updated JEMM386 a few times in recent months. Is that
the one you're referring to, or do you refer to other (much older,
more limited, buggier) vendors? Which ones have been tested in recent
years with these drivers? But even with JEMM we have several versions
(5.78, 5.79, 5.80-pre1) and subvariants (e.g. jemmex or jemm386). I'm
not complaining, we're lucky to have it, it's just a lot for people to
test (but most people don't). So I haven't tried it lately.

> > How is that even possible? Too many versions, too many
> > (alleged) bug fixes! Ridiculous!
>
> Being too annoyed to look at the new version will not make
> the new version worse. That is just your personal opinion.

Is UIDE.SYS completely irrelevant in lieu of UHDD.SYS + UDVD2.SYS?
Seriously, do you know? Is there literally any reason anymore to use
UIDE.SYS? Were they just designed differently, or is this only a
result of UHDD.SYS being "fixed" in early 2019??

> PS: The drivers are deliberately freeware with sources without
> giving a specific license as the author is against fine print.

FreeDOS, by design, has always favored free/libre or "open source".

* http://wiki.freedos.org/wiki/index.php/Open_source_software
* https://sourceforge.net/p/forge/documentation/userfaq/#free
* https://www.gnu.org/philosophy/free-sw.en.html

Going closed source for unjust reasons for zero practical advantage is
user hostile and the exact kind of thing that the GPL was designed to
avoid. No amount of partial updates and pretend lip service can change
that. He made a choice, based upon nothing, despite correction and
proof, but instead still keeps punishing end users, for literally no
gain. What a waste of time.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE versus UHDD in freedos 1.2 - and 1.3

[Eric Auer]

Hi Jim,

> I think this is an oversight in FreeDOS 1.3. I did review UDVD2 and the
> others and said they were ok for FreeDOS 1.3. They are listed as such
> (green) on the Packages page.
> http://wiki.freedos.org/wiki/index.php/Releases/1.3/Packages
> 
> Unless I'm missing something?

I agree: It seems that while UDVD2 is included, there could
be a more explicit mention and inclusion of UHDD and the
fact that UDVD2 combined with UHDD is strongly recommended
over using the integrated but older UIDE driver instead.

So apparently we should simply add UHDD to FreeDOS 1.3 as
UDVD2 already is there :-)

Eric




___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE versus UHDD in freedos 1.2 - and 1.3

[Jim Hall]

I think this is an oversight in FreeDOS 1.3. I did review UDVD2 and the
others and said they were ok for FreeDOS 1.3. They are listed as such
(green) on the Packages page.
http://wiki.freedos.org/wiki/index.php/Releases/1.3/Packages


Unless I'm missing something?

Jim

On Mon, Mar 9, 2020, 5:59 AM Eric Auer  wrote:

>
> Hi Rugxulo, Jerome, Jim et al,
>
> > The full 1.2 release was from late 2016 / early 2017.
> > It hasn't changed.
>
> Good point, although 1.3 is still pending, so people
> might still want to update while they only have 1.2.
>
> > As far as I'm concerned, UIDE [sic] died in 2015.
>
> Another reason to switch to UHDD and UDVD2.
>
> > That makes no sense (to me). UHDD.SYS (from 2015) indeed had a
> > surprise update in early 2019 (dunno what changed, ask Jim), but
> > UDVD2.SYS is still dated 2015.
> >
> > *
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/cdrom/uide/
> >
> > "It would probably be better" ... if XIDE/XHDD/XDVD2 (or whatever he
> > calls it nowadays) wasn't unjustly "closed source" for five years!
>
> You do know that the 2019 version *does* include full sources
> of UDVD2, UHDD, UIDE and XMGR, I hope. And I do *not* remember
> attempts by other programmers to update them which would have
> failed during the period when sources were unpublished, simply
> because low level drivers rarely get updates from new people.
>
> Replying to my list, you ask for more exact descriptions of the
> improvements in the currently-on-ibiblio 2019 UHDD and UDVD2:
>
> Better performance: UHDD 10% faster with read-ahead than UIDE.
>
> 386 compatibility: UHDD can run on 386, while UIDE follows old
> Microsoft advice which causes XMS move errors on older 386 CPU.
>
> Improved drive detection and LBA: UHDD supports DMA on SSD (as
> well as CF) which claim to be "ATA / ATAPI" while UIDE would
> have ignored them as potentially optical, expecting *only* ATA
> to be supported. UIDE supports only old LBA for the first 128
> GB, while UHDD supports LBA48 and larger disks. Note that DOS
> itself has a 2 TB limit until somebody adds GPT partition code.
>
> Because UHDD (and UDVD2, in spite of being "old") recognize
> more drives as DMA/UDMA compatible, without false positives,
> they give much better performance in those cases compared to
> situations where UIDE fails to detect the DMA support. This
> can mean up to several *times* faster in EMM386 context, as
> a BIOS would rarely bother to call the VDMA API to support
> fast protected mode or VM86 disks on DMA and rather use PIO.
>
> > How is that even possible? Too many versions, too many
> > (alleged) bug fixes! Ridiculous!
>
> Being too annoyed to look at the new version will not make
> the new version worse. That is just your personal opinion.
>
> > These decisions (for FD 1.3) rely mostly on Jerome and Jim.
>
> Then I recommend UHDD and UDVD2 to Jerome and Jim, specifically.
>
> Regards, Eric
>
> PS: The drivers are deliberately freeware with sources without
> giving a specific license as the author is against fine print.
>
>
>
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE versus UHDD in freedos 1.2 - and 1.3

[Eric Auer]

Hi Rugxulo, Jerome, Jim et al,

> The full 1.2 release was from late 2016 / early 2017.
> It hasn't changed.

Good point, although 1.3 is still pending, so people
might still want to update while they only have 1.2.

> As far as I'm concerned, UIDE [sic] died in 2015.

Another reason to switch to UHDD and UDVD2.

> That makes no sense (to me). UHDD.SYS (from 2015) indeed had a
> surprise update in early 2019 (dunno what changed, ask Jim), but
> UDVD2.SYS is still dated 2015.
> 
> * https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/cdrom/uide/
> 
> "It would probably be better" ... if XIDE/XHDD/XDVD2 (or whatever he
> calls it nowadays) wasn't unjustly "closed source" for five years!

You do know that the 2019 version *does* include full sources
of UDVD2, UHDD, UIDE and XMGR, I hope. And I do *not* remember
attempts by other programmers to update them which would have
failed during the period when sources were unpublished, simply
because low level drivers rarely get updates from new people.

Replying to my list, you ask for more exact descriptions of the
improvements in the currently-on-ibiblio 2019 UHDD and UDVD2:

Better performance: UHDD 10% faster with read-ahead than UIDE.

386 compatibility: UHDD can run on 386, while UIDE follows old
Microsoft advice which causes XMS move errors on older 386 CPU.

Improved drive detection and LBA: UHDD supports DMA on SSD (as
well as CF) which claim to be "ATA / ATAPI" while UIDE would
have ignored them as potentially optical, expecting *only* ATA
to be supported. UIDE supports only old LBA for the first 128
GB, while UHDD supports LBA48 and larger disks. Note that DOS
itself has a 2 TB limit until somebody adds GPT partition code.

Because UHDD (and UDVD2, in spite of being "old") recognize
more drives as DMA/UDMA compatible, without false positives,
they give much better performance in those cases compared to
situations where UIDE fails to detect the DMA support. This
can mean up to several *times* faster in EMM386 context, as
a BIOS would rarely bother to call the VDMA API to support
fast protected mode or VM86 disks on DMA and rather use PIO.

> How is that even possible? Too many versions, too many
> (alleged) bug fixes! Ridiculous!

Being too annoyed to look at the new version will not make
the new version worse. That is just your personal opinion.

> These decisions (for FD 1.3) rely mostly on Jerome and Jim.

Then I recommend UHDD and UDVD2 to Jerome and Jim, specifically.

Regards, Eric

PS: The drivers are deliberately freeware with sources without
giving a specific license as the author is against fine print.



___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE versus UHDD in freedos 1.2

[Rugxulo]

Gruess Gott,

On Sun, Mar 8, 2020 at 10:12 AM Eric Auer  wrote:
>
> It seems that FreeDOS 1.2 currently includes UIDE.

"Currently"?? The full 1.2 release was from late 2016 / early 2017. It
hasn't changed.

As far as I'm concerned, UIDE [sic] died in 2015.

> It would probably be better to use UHDD and UDVD2 instead:

That makes no sense (to me). UHDD.SYS (from 2015) indeed had a
surprise update in early 2019 (dunno what changed, ask Jim), but
UDVD2.SYS is still dated 2015.

* https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/cdrom/uide/

"It would probably be better" ... if XIDE/XHDD/XDVD2 (or whatever he
calls it nowadays) wasn't unjustly "closed source" for five years!
That would've saved a lot of end users tons of frustration.

Then again, most of them "just use Linux", it works! (I'm on a
Chromebook now. Isn't "Free Software" great?? GPL FTW!)

> Those

Which exactly? Where are they? What versions?

> have better performance

Than who? Which versions exactly?

> and better 80386 style XMS compatibility

XMSv3? (You know that DR-DOS 7.03's XMS faked its version number and
really only supported XMSv2, i.e. 64 MB limit.)

> on old computers

Which? Actually 386 or 486 cpus? Pre-LBA BIOSes?

> , as well as improved drive detection, DMA choices, support for disks above 
> 128 GB size and more good news :-)

How is that even possible? Too many versions, too many (alleged) bug
fixes! Ridiculous!

> Thanks for considering!

These decisions (for FD 1.3) rely mostly on Jerome and Jim.

But discussing these drivers is always a huge waste of time. I'm tired
of hearing about it. It's unproductive, to put it politely.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] UIDE versus UHDD in freedos 1.2

[Eric Auer]

Hi!

It seems that FreeDOS 1.2 currently includes UIDE. It
would probably be better to use UHDD and UDVD2 instead:

Those have better performance and better 80386 style
XMS compatibility on old computers, as well as improved
drive detection, DMA choices, support for disks above
128 GB size and more good news :-)

Thanks for considering! Regards, Eric



___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE Updates: NOT Losing My Mind!

[Eric Auer]

Jack,

another week, another UIDE update is probably just a compliment, no
complaint... Regarding your most recent update: Until we support EFI
(UEFI?) GPT partitioning, FreeDOS only supports 2^32 sectors for FAT
partitions on int13 disks in the kernel. However, it is possible that
some driver (e.g. for USB media) supports GPT itself and/or supports a
filesystem (not FAT, probably also not ISO9660 nor UDF) for partitions
or unpartitioned media which extend beyond 2^32 sectors.

You could decide to not cache such drives. Or you could decide to
(carefully) cache only the first 2^32 sectors. Or you could support
LBA48 or even 64 bit sector numbers. In my personal opinion, your choice
to support 2^32 sectors is fine as long as no DOS kernel and no popular
driver for DOS supports larger disks. If you need a spare bit for flags,
even caching only the first 1 TB (2^31 * 512 byte) would be ok for me.

Of course you could pool updates - but people can decide themselves if
they personally need a specific update or if they want to wait until a
few other interesting changes become available before they update. In
that sense, release early, release often can work for everybody.

Regards, Eric

PS: I think it is nice to announce updates on multiple channels, e.g.
BTTR forum, freedos.org and this mailing list here.



--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] UIDE Updates: NOT Losing My Mind!

[Jack]

Re: Rugxulo's FreeDOS front-page comment about Another week, another
UIDE update, I want to assure people that, despite now being age 68,
I am NOT losing my mind!

The 20-Aug-13 update was to provide CD/DVD kiosk users in Hong Kong
(and elsewhere) a way to cache CD/DVD data without loading the entire
4.5K UIDE driver.   My partner Johnson Lam asked for this, so I did
it.   But, I was UNHAPPY with the size of UCACHE2, and so --

The 26-Aug-13 update makes UHDD able to run private caches, with NO
separate caching driver required.   UHDD still has its common cache
for old drivers, and it may now be called by the updated UDVD2 and by
other updated user drivers (if any!) that desire private caching.

The 2-Sep-13 update fixed a possible media-change problem in UDVD2.
I say possible because UDVD2 ran fine, but its logic did not appear
correct.   So I upgraded it, to stay safe.   Safety MATTERS, to me!

The 9-Sep-13 update fixed more possible but unlikely errors in UHDD
re: resetting its user parameter-table pointer.   The reset cannot be
done if UHDD rejects an I-O request because another is still running.
If the running request LOSES its cache parameters, a CRASH may occur!
Also, the reset should not be done for BIOS requests that UHDD is not
going to handle.   I am unsure all old DOS versions have media-change
logic for a HARD-disk flagged as removable, i.e. a USB disk.So,
UHDD/UIDE are written to stay safe and IGNORE any such disks!

I have never heard of any cases where multiple I-O requests have been
issued to UHDD/UIDE.   DOS uses a one at a time I-O scheme, as most
developers know.   Nor have I heard of many cases where an odd BIOS
disk gets ignored by my drivers.   But to remain safe, I fixed both
cases in UHDD, and I apologize for not having realized all this while
adding UHDD's private cache capability.   I get bugs, too.

Finally, though we are years away from a Super Blu-Ray CD/DVD drive
requiring 32 LBA bits (8 Terabytes), UDVD2/UIDE using only 30 bits in
caching was a problem waiting to happen!   The problem has now been
corrected in both drivers.

Those are my REASONS behind the 4 recent UHDD/UDVD2/UIDE updates, and
everyone can rest assured that I am NOT losing my mind!

--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] UIDE etc. (Apr. 30)

[Rugxulo]

On April 30, Jack Ellis once again updated his UIDE etc. drivers.
Changes: UHDD/UDVD2 can now be run without XMS (at lower speed) for
FreeDOS 'scripts' or for tests. UDVD2 can now do 'raw' (trackwriter)
input. Other drivers unchanged (re-dated only). You can grab binaries
and sources at iBiblio (/dos/cdrom/uide/). Thanks again, Jack!

http://www.freedos.org/software/?prog=uide

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/cdrom/uide/drivers-2013-04-30.zip

--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] uide versus virtualbox versus ls120 - was: DISGUSTED With Pundits!!

[Eric Auer]

Hi! (BCCing Jack and Mr. Lego)

If I understand you correctly, you deliberately make
incompatible for many VirtualBox users in order to fix
it for a few users with LS120 drives with broken BIOS
support?

Can you give more details about the way in which the
BIOS of Christian Pfaller fails to report the LS120?
By the way, is it supported as LS120 or just as 1.4M?

 Eric, if your VBOXFIX program is still available, you might
 want to re-issue it, with its specific logic to test the bits
 in the BIOS diskette flag byte for the presence of diskettes,
 when VirtualBox is used.   I intend to use that byte again,

Did anybody with connections to the VirtualBox community
or a bug reporting account report the lack of support
for this semi-undocumented BIOS flag byte to VirtualBox?

By the way, why do you publish that mr-lego.fd web.de
email address to the list? Did Christian ask for that?

 For example I load UIDE with the parameter /S25 (with 25MB-cache).
 If I check now a LS120 diskette with DOSFSCHK, it told me that the first
 and the second FAT are not be the same.
 
 Now I load UIDE with the parameter /B (basic, without cache).
 Then I check the LS120 diskette with DOSFSCHK, no errors were found.

I still wonder how THAT would by influenced by whether or not
UIDE caches the drive? Or does UIDE get the geometry wrong or
some completely different problem arises? Because I assume by
flag byte you mean the byte saying whether the drive exists?

 This problem only appears with the LS120 Diskette Drive.

Regards, Eric



--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] uide versus audio cd versus udvd

[Karen Lewellen]

The ability to rip audio cds has been built into the mpxplay dos audio 
player package for years.  Given  it now includes audio formats from .aif 
to .acc to m4a and mp4  and still allows for audio cd ripping, clearly 
many people care.
Karen

On Sun, 12 Aug 2012, Eric Auer wrote:


 Hi, short question about CD-DA: The UDVD driver saves a tiny
 amount of RAM by not supporting raw sector reads, so if you
 want to rip audio CD to audio files, you have to use UIDE,
 the more complete driver.  My question is: Who does audio CD
 ripping in DOS at all? Depending on that, it might be worth
 enabling raw read in UDVD, making it more known that raw is
 only available in UIDE, or maybe do nothing as nobody cares?

 Regards, Eric :-)

 PS: I myself prefer cdparanoia-related abcde to rip in Linux.


 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] uide versus audio cd versus udvd

[Eric Auer]

Hi, short question about CD-DA: The UDVD driver saves a tiny
amount of RAM by not supporting raw sector reads, so if you
want to rip audio CD to audio files, you have to use UIDE,
the more complete driver.  My question is: Who does audio CD
ripping in DOS at all? Depending on that, it might be worth
enabling raw read in UDVD, making it more known that raw is
only available in UIDE, or maybe do nothing as nobody cares?

Regards, Eric :-)

PS: I myself prefer cdparanoia-related abcde to rip in Linux.


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE Diskette Change Line Capability Tests.

[Bret Johnson]

Jack:

Are you more interested in actually getting your program to work, or in trying 
to prove that you're smarter than everybody else?

Let's take this from the perspective of someone trying to write a BIOS.  If I 
were trying to do that, I would do my due diligence and obtain as many 
references as I could.  This would include BIOS Central, RBIL, and as many 
hard books as I could reasonably get hold of.  Some people have been doing 
research on this in the background, and nobody yet has reported a hard book 
saying anything at all 40:8F.

BIOS Central says one thing, RBIL says another.  Which one is right?  Maybe 
both (different BIOS's on different computers), maybe neither.  I do know that 
both of these are secondary, not primary, sources.  At least some of their 
information is gathered by experimentation on specific computers, and can be 
pure conjecture.  Extrapolating information from specific computers and 
applying it to all computers is, at best, reckless.

Which one do I believe?  I can't believe either one.  I need another source of 
corroboration, one that I know didn't just copy their information from BIOS 
Central or RBIL.

So, I go to a primary, official source -- The IBM Technical Reference (it 
doesn't get any more official or primary than that).  The IBM PS/2 Technical 
Reference from 1991 simply says that 40:8F is Reserved.

So, what do I do with 40:8F in my BIOS?  The short answer is, I can do anything 
I want.  If somebody points the finger back at me and says, It should work 
like BIOS Central says, I can laugh and say, Says who?  BIOS Central does 
not have any more credibility than RBIL, and neither one of them can touch IBM.

UIDE is using an undocumented and unverifiable feature and needs to be fixed.  
VirtualBox is following the rules.


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE Diskette Change Line Capability Tests.

[Jack]

Bret,

A favorite tactic of propagandists, be they Fascist/Nazi/Communist
or others, is that they flatly IGNORE any information from opponents
and simply go on spouting their own ideas.

In responding to the above thread, you have totally IGNORED all info
I offered to begin with, and you cite, as your reference, a 1991 IBM
Technical Reference for the PS/2.

That reference is now 21 years old, and was written for a computer
that AFAIK has NOT been sold by IBM for YEARS!   I can also note how
IBM in fact LOST control of their own PC market beginning about 1985
to vendors in Japan and Asia, due largely to the same class of FIXED
thinking that you now exhibit!   IBM thought they were Gods and Asia
did not matter, and Asia just MASSACRED IBM in their own marketplace
same as Crazy Horse did to Custer in 1876!   I have NEVER given much
trust to IBM, surely not after 1985, and I never will!

So I will say it all again, for the cheap seats --

(A) The 1991 IBM Technical Reference for a PS/2 is 21 years old, was
 written for a system that is now obsolete, and MAY NOT have been
 kept current.

(B) Using byte 0:048Fh is not undocumented.   BIOS Central has noted
 this from at-least 2006, when I first read their BIOS data list.

(C) As of 11-Jan-2007, 16 years PAST your IBM reference, Phoenix and
 maybe other BIOS vendors do in fact support byte 0:048Fh exactly
 as BIOS Central describes that byte.   I have such a BIOS, and I
 expect others using a hardware PC can verify that 0:048Fh DOES
 work exactly as BIOS Central indicates, DESPITE some 21-year-old
 IBM reference calling that byte reserved.

(D) UIDE/UIDE2 have NEVER failed, to my knowledge, to cache diskette
 data and deal with diskette media-changes, if used on any actual
 hardware PC system.   If so, I want to KNOW about it and shall
 FIX any such problems, REAL QUICK!!

(E) VirtualBox handling of diskette change-lines IS IN DOUBT!   Eric
 did find (yesterday) a source file in which THEY DO set the byte
 at 0:048Fh, despite other parts of their emulator saying they do
 NOT support diskette change-lines.   Since Their RIGHT hand may
 not know what their LEFT is doing! (a usual result re: too many
 programmers on one task!), I believe it is WRONG to say they are
 following the rules.   WHOSE rules??   Even THEY seem not able
 to agree among THEMSELVES what those rules ARE!!

And now, Bret, DO NOT merely spout your own propaganda again!   If
you have more to say, speak to the points -- SPEAK TO THE POINTS! --
that I have listed above!!

And do so in private, as after this E-Mail, I will again unsubscribe
 from FD-User.Jack is right and everyone else is an idiot, Are
you trying to prove yourself smarter than everyone else, plus other
such INSULTS will be ENOUGH for me!

Use UIDE/UIDE2 if you think they work.   Otherwise, do not use them.
Your choice.   I think they work, I have evidence to say they should
and NO actual PROOF to the contrary.   So I will leave them as is.

Jack R. Ellis

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE Diskette Change Line Capability Tests.

[Eric Auer]

Jack, Bret, VirtualBox users,

 A favorite tactic of propagandists, be they Fascist/Nazi/Communist
 or others, is that they flatly IGNORE any information from opponents

At this point, you lost the discussion and many readers will
simply have skipped the rest of your mail, as explained here:

http://en.wikipedia.org/wiki/Godwin%27s_law#Corollaries_and_usage



 In responding to the above thread, you have totally IGNORED all info
 I offered to begin with, and you cite, as your reference, a 1991 IBM
 Technical Reference for the PS/2.

No. The point was that BIOS Central, RBIL, Tischer and other
reputable sources disagree* about 40:8f and therefore, even
though each individual source is reputable, 40:8f is not a
safe way to decide about floppy change lines. On the other
hand, all sources do agree about int 13 for that purpose.

* can mean ONE thing, ANOTHER thing, or be a RESERVED byte.

 (C) As of 11-Jan-2007, 16 years PAST your IBM reference, Phoenix and
  maybe other BIOS vendors do in fact support byte 0:048Fh exactly

The weak point is in maybe other here.

 (D) UIDE/UIDE2 have NEVER failed, to my knowledge... on any actual
  hardware PC system.   If so, I want to KNOW about it...

Virtual machines are widespread now, their users deserve support.



 (E) VirtualBox handling of diskette change-lines IS IN DOUBT!

The comment in orgs.asm indeed supports your claim that VirtualBox
is in conflict with itself IF 40:8f really means what UIDE thinks.
However, documentation about that very byte is contradictionary...

Also, DOSEMU treats the same byte as reserved (0) and is backed by
literature for this. As long as you can find support in literature
for multiple interpretations of the same byte, it is not safe to
demand from all BIOSes to interpret the byte in one specific way.

Note that I was not able to download rombios.c from BIOS so all
statements about me reading VirtualBox sources are limited to the
BIOS-new directory and I do not know which version is used when.



 Use UIDE/UIDE2 if you think they work. Otherwise, do not use them.

The third choice is giving my prosthetic helper a try ;-) Users
of VirtualBox and UIDE, but also of other systems including real
hardware, are invited to write me off-list, so I can send a copy
and receive feedback :-) My tool does the following: It installs
a PCI BIOS handler where scans are limited to existing bus numbers
(VirtualBox has 1 bus but VirtualBox BIOS scans 256) which should
speed up UIDE init a lot. This function is an experimental TSR and
takes circa 400 bytes of DOS RAM. Loading into UMB with LH should
be possible without problems. The other function does not take any
DOS RAM: It simply enforces the expected-by-UIDE semantics for the
BIOS Data Area byte 40:8f - This should protect you from data loss
in VirtualBox and should enable UIDE caching of floppies in DOSEMU.

Regards, Eric :-)


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE Diskette Change Line Capability Tests.

[Jim Hall]

 Use UIDE/UIDE2 if you think they work. Otherwise, do not use them.

 The third choice is giving my prosthetic helper a try ;-) Users
 of VirtualBox and UIDE, but also of other systems including real
 hardware, are invited to write me off-list, so I can send a copy
 and receive feedback :-) My tool does the following: It installs
 a PCI BIOS handler where scans are limited to existing bus numbers
 (VirtualBox has 1 bus but VirtualBox BIOS scans 256) which should
 speed up UIDE init a lot. This function is an experimental TSR and
 takes circa 400 bytes of DOS RAM. Loading into UMB with LH should
 be possible without problems. The other function does not take any
 DOS RAM: It simply enforces the expected-by-UIDE semantics for the
 BIOS Data Area byte 40:8f - This should protect you from data loss
 in VirtualBox and should enable UIDE caching of floppies in DOSEMU.


Out of curiosity, why not post the tool online, and share the URL on
this list so people can try it? A key part of free / open source
software is making our programs easily available to everyone so people
can use them.


-jh

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] UIDE Update Coming -- DISGUSTING Implications!!

[Jack]

A Heads Up (warning) message to all users of UIDE and UIDE2 --

Some time ago, I considered Read-Ahead for UIDE/UIDE2.   But effective
Read-Ahead requires knowing file sizes, to prevent reading too FAR ahead
and losing time!   File sizes demand DOS calls, and I want UIDE/UIDE2 to
remain generic (no DOS calls) and continue to use only Int 13h.

In any case, I did revise the drivers' UdmaIO/DoDMA routines, to put
more setup logic in DoDMA so it could be an internal driver for Read
Ahead.   This created a bug!   For disks, the SetAdr subroutine that
detects 64K UltraDMA boundary crossings is now being called BEFORE the
IOLen byte count is set for requests!   SetAdr must know that count!
CD/DVD requests, and the non-caching UIDEJR driver, were not affected.

Easy to fix, simply re-arrange UIDE/UIDE2's logic to what it was before.

However, what this bug IMPLIES has left me rather DISGUSTED!

I shall NOT believe that all DOS kernels/programs do disk I-O using only
perfectly-aligned buffers with no 64K UltraDMA boundaries!   Many such
kernels/programs were written BEFORE 1994, when UltraDMA was thought-up!
So, the only way recent UIDE/UIDE2 drivers could run O.K., without users
seeing a LOT of data errors, is that 64K UltraDMA boundaries NO-LONGER
EXIST!   Newer DMA controller chips likely increment all 32 address bits
after DMA byte/word transfers, not just the LOWER 16 bits as in the 1994
Intel Bus-Master Specs.   That was what created such 64K boundaries!

And NOBODY in Santa Clara, California nor in Redmond, Washington told ME
one word about all this, that UIDE need no-longer worry about UltraDMA
boundaries!   This despite comments about UIDE showing up all the time
on MSN and others of their forums!

So, pardon me, if I am really left DISMAYED and DISGUSTED by the current
computer industry, that PROVES all-the-time how they only want DOS and
efforts like ours to just go away!   Small wonder, that my computer is
unchanged past 2006, and my software is unchanged past 1994 V6.22 MS-DOS
and 1998 V4.0 Windows/NT.I too can play their little go away game,
or as my late Mother might have said, So SCREW them!!!

I have the bug fixed in my personal drivers, and I shall soon issue an
updated DRIVERS.ZIP file through Johnson Lam's website, when he recovers
 from another type of bug called the FLU!

--
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

[Freedos-user] UIDE Drivers Updated, UIDE-S Eliminated!

[Jack]

Johnson Lam has posted a new 16-Oct-2011 DRIVERS.ZIP file on
his website at http://johnson.tmfc.net/dos/driver.html.

In it, UIDE has again been reduced down to a 7.5K-byte file,
same as UIDE2, for boot diskettes and other systems having
limited space.So, UIDE-S is no longer needed, and it has
been eliminated!   UIDE2's performance is also improved, and
all other drivers have merely been re-dated to 16-Oct-2011.

To get UIDE below 7.5K, I had to delete its /M switch./M
saved only 256 bytes of HMA, not enough to matter, as UIDE
uses only 4336 bytes of HMA in all cases.   Even poor MS-DOS
V7.10 (short on HMA due to long-filename and Win95/98 logic)
still has 9100+ bytes of free HMA, and a BUFFERS=4 command
in CONFIG.SYS can reduce what the kernel needs!   Most other
DOS systems have MUCH more free HMA and should be no problem
if loading UIDE with a /H switch.   UIDE can be re-assembled
with SBUFSZ equ 256, if anyone absolutely requires its 256
byte binary-search buffer (runs maybe 1% slower)!

The UIDE2 driver now runs a hair faster for protected-mode
users, due to re-adding the old ScnD subroutine which uses
a scasw command (not a full binary-search) in deleting old
cache-table entries.   ScnD is used with UIDE2's /H or /HL
switches, as its HMA caches are small enough for such logic.
Large caches in upper/DOS memory still use the current UIDE2
SrchD routine, for better speed with bigger search tables.

The UIDE caching drivers now consist of only --

1) The UIDE.ASM source file (assembles both drivers).
2) The UIDE.SYS driver for up to 4-Gigabyte caches.
3) The UIDE2.SYS driver for fast caches in protected-mode.

I hope such a simplification is of benefit for UIDE users!


--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] UIDE Drivers Updated, New UIDE2.

[Jack]

Johnson Lam has posted an updated 9-Sep-2011 DRIVERS.ZIP file, on his
website at johnson.tmfc.net/dos/driver.html, which contains a new
UIDE2, also updates to the other UIDE drivers.

UIDE2 uses old-style protected mode caching, that was in UIDE until
August, 2010.   Try as I may, I simply cannot get the current all-XMS
UIDE to run any faster in protected-mode (JEMM386 etc.).   All of its
cache tables are in XMS memory.   This requires a slow Int 15h trap
thru JEMM386, to fetch any XMS data.Absolutely NOT any fault of
JEMM386, but due to Intel's too-complex 80386+ protected mode scheme!

UIDE2 sets its binary-search table in memory beyond the driver, which
avoids 50% of XMS accesses and saves time -- fewer Int 15h traps in
protected-mode.   As it uses more HMA or memory for its search table,
UIDE2 does have cache-size limits, noted in the UIDE2.ASM file.   But
it is still up to 5% faster for protected-mode, and so UIDE2 is Back
in service! for users who run JEMM386/EMM386 etc.

I was also unhappy about UIDE-S running only 4 CD/DVD drives, since
there may be a few CD copier PCs with up to 6 CDs.So, UIDE2 and
UIDE-S now handle up to 6 CD/DVD drives!   Any users who in fact have
7 or 8 CD/DVD drives can still use the full UIDE or the non-caching
UIDEJR, which will run up to 8 CDs/DVDs (UIDEJR with its /U8 switch).

UIDE2 and UIDE-S are still 7.5K-byte .SYS files, for boot diskettes
or other space-limited systems.   UIDE2 also handles the /N3 No XMS
switch and sets the UIDE$ default name if no CD/DVD drive is found.
So, UIDE2 can be run with FreeDOS automatic loader scripts on their
distribution CDs.   (Not possible for UIDE-S, which now barely fits
into 7.5K!).


--
Why Cloud-Based Security and Archiving Make Sense
Osterman Research conducted this study that outlines how and why cloud
computing security and archiving is rapidly being adopted across the IT 
space for its ease of implementation, lower cost, and increased 
reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE Performance -- Small Caches DO Work O.K.!

[Santiago Almenara]

Welcome back!

Sent from my iPhone

On 23/08/2011, at 23:50, Jack gykazequ...@earthlink.net wrote:


 For years, I have told people to use as much cache as
 possible with UIDE, to handle today's large files and
 still leave space in the cache for DOS directories.

 Today, Tuesday 23-Aug-2011, I ran experiments using
 a driver equal to UIDE-S, with a new 10-MB cache size
 of 1280 8K-byte data blocks.   I never liked the 5-MB
 cache that some users MUST have (only 640 blocks, not
 enough data!) so I chose to try a 10-MB tiny cache.

 I ran my usual test of copying a 635-MB video drivers
 CD to disk.   With my regular 500-MB UIDE cache, this
 test takes around 124 seconds, plus-or-minus about 2.

 With only the 10-MB cache, the test took 128 seconds,
 merely 4 seconds more!   I checked 25, 50, and 100-MB
 caches as well, and none suffered in speed from being
 small-sized!   Each performed as well, maybe a hair
 better in some cases, as the 10-MB cache!

 So, it seems I may have been All wet! (misinformed)
 re: UIDE's cache performance v.s. cache size.   Users
 may want to check this on their systems, maybe across
 a variety of applications.   And I expect there are a
 few large file systems which do need larger caches.

 But, it now seems that casual users of DOS and UIDE
 need NOT worry re: using only a 25/50/100-MB cache --
 They do seem to perform a LOT better than I expected!

 Jack R. Ellis


 --
 EMC VNX: the world's simplest storage, starting under $10K
 The only unified storage solution that offers unified management
 Up to 160% more powerful than alternatives and 25% more efficient.
 Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user

--
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE Performance -- Small Caches DO Work O.K.!

[JPT]

Hi,

I cannot resist... in the following read my comments on caching and
buffering.

Even Windows XP (did not try nore recent versions yet) suffers from bad
buffering when copying files from and to the same harddrive. It takes
10x to 100x time compared to copying from one drive to another one.
I installed SuperCopier 2.2 beta which catches Explorer copy actions and
does them itself. Well, now you are able to define huge buffers... but
it does not help much, because its a question of filling and flushing
the buffer, as XCOPY did.
!!! beware, supercopy has got a bug when using buffers larger than 64k,
causing it to abort the operation on files larger than 4 gig. !!!
Caching does not help much with operations like this. Ok, caching FAT
and directories...

When working with large files, you always have to code buffering on your
own. For example, I compiled mplex (mpeg muxer) myself using cygwin.
Works correctly but uses the wrong file mode. Result is my RAM gets
filled with cached data from the target file. Everything else gets paged
out. The system breaks down to almost unusable until the process is
finished. Then it takes decades to swap in the other programs again...
What I want to say is, you can have Terabytes of RAM, it won't help in a
case like this when the file operation is about as large as your RAM. If
there was an upper limit for the amount of cache used for a single file,
there would be no problem at all. So small caches sometimes perform even
better!

So guys go tell M$ how to write an operating system!


JPT


--
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] UIDE Performance -- Small Caches DO Work O.K.!

[Jack]

For years, I have told people to use as much cache as
possible with UIDE, to handle today's large files and
still leave space in the cache for DOS directories.

Today, Tuesday 23-Aug-2011, I ran experiments using
a driver equal to UIDE-S, with a new 10-MB cache size
of 1280 8K-byte data blocks.   I never liked the 5-MB
cache that some users MUST have (only 640 blocks, not
enough data!) so I chose to try a 10-MB tiny cache.

I ran my usual test of copying a 635-MB video drivers
CD to disk.   With my regular 500-MB UIDE cache, this
test takes around 124 seconds, plus-or-minus about 2.

With only the 10-MB cache, the test took 128 seconds,
merely 4 seconds more!   I checked 25, 50, and 100-MB
caches as well, and none suffered in speed from being
small-sized!   Each performed as well, maybe a hair
better in some cases, as the 10-MB cache!

So, it seems I may have been All wet! (misinformed)
re: UIDE's cache performance v.s. cache size.   Users
may want to check this on their systems, maybe across
a variety of applications.   And I expect there are a
few large file systems which do need larger caches.

But, it now seems that casual users of DOS and UIDE
need NOT worry re: using only a 25/50/100-MB cache --
They do seem to perform a LOT better than I expected!

Jack R. Ellis


--
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE /E For VirtualBox Now Officially Released.

[Santiago Almenara]

Jack,

Is there any specific order for UIDE options?

I am using the lastest UIDE (07-22-2011) wtih this options:

C:\DEVLOAD\DEVLOAD /H C:\UIDE\UIDE.SYS /E /H /S:15 /D:MYCDROM

Under VirtualBox, I am having the same problems when detecting the hard disk
than the previous UIDE version.

Thanks,

Santiago

On Sun, Jul 24, 2011 at 5:57 PM, Jim Hall jh...@freedos.org wrote:

 THANKS, Jack!

 I've mirrored this release on ibiblio, and updated the software list.
 A news item should appear on the www.freedos.org site in about an
 hour.



 On Sun, Jul 24, 2011 at 3:15 PM, Jack gykazequ...@earthlink.net wrote:
 
  As noted earlier by Rugxulo, Johnson Lam has now posted
  the 22-Jul-2011 DRIVERS.ZIP file on his website at:
 
  http://johnson.tmfc.net/dos/driver.html
 
  Thus, the new UIDE and UIDE-S, with their /E emulator
  switch for use by VirtualBox, are officially released
  and users need not E-Mail me directly for the files.
 
  Users who had been running UIDE /N1 (no hard-disks), to
  avoid VirtualBox problems, can now try UIDE /E instead.
  /N1 causes UIDE to totally ignore all hard-disks, while
  /E does permit hard-disk data to get cached, after UIDE
  calls the BIOS to do disk I-O.   This is much better!
 
  Jack R. Ellis
 
 
 
 --
  Magic Quadrant for Content-Aware Data Loss Prevention
  Research study explores the data loss prevention market. Includes
 in-depth
  analysis on the changes within the DLP market, and the criteria used to
  evaluate the strengths and weaknesses of these DLP solutions.
  http://www.accelacomm.com/jaw/sfnl/114/51385063/
  ___
  Freedos-user mailing list
  Freedos-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/freedos-user
 


 --
 Magic Quadrant for Content-Aware Data Loss Prevention
 Research study explores the data loss prevention market. Includes in-depth
 analysis on the changes within the DLP market, and the criteria used to
 evaluate the strengths and weaknesses of these DLP solutions.
 http://www.accelacomm.com/jaw/sfnl/114/51385063/
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user

--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE /E For VirtualBox Now Officially Released.

[Rugxulo]

Hi,

On Thu, Jul 28, 2011 at 12:01 PM, Santiago Almenara almen...@gmail.com wrote:

 Is there any specific order for UIDE options?

 I am using the lastest UIDE (07-22-2011) wtih this options:
 C:\DEVLOAD\DEVLOAD /H C:\UIDE\UIDE.SYS /E /H /S:15 /D:MYCDROM
 Under VirtualBox, I am having the same problems when detecting the hard disk
 than the previous UIDE version.

Blind guess, but /S15 shouldn't have a colon in it, I think.

--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE /E For VirtualBox Now Officially Released.

[Bernd Blaauw]

Op 28-7-2011 23:22, Rugxulo schreef:

 I am using the lastest UIDE (07-22-2011) wtih this options:
 C:\DEVLOAD\DEVLOAD /H C:\UIDE\UIDE.SYS /E /H /S:15 /D:MYCDROM
 Under VirtualBox, I am having the same problems when detecting the hard disk
 than the previous UIDE version.

 Blind guess, but /S15 shouldn't have a colon in it, I think.

And otherwise there's still the options to enable newer hardware 
(IO-APIC, ICH9 chipset instead of 430FX). Pity if the /E setting doesn't 
suffice, but Jack so far did what he can. It's nearly impossible to be 
compatible with everything related to PCI and BIOS. And just to add some 
fun from the EFI (bios replacement) corner:
http://mjg59.dreamwidth.org/



--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] UIDE /E For VirtualBox Now Officially Released.

[Jack]

As noted earlier by Rugxulo, Johnson Lam has now posted
the 22-Jul-2011 DRIVERS.ZIP file on his website at:

http://johnson.tmfc.net/dos/driver.html

Thus, the new UIDE and UIDE-S, with their /E emulator
switch for use by VirtualBox, are officially released
and users need not E-Mail me directly for the files.

Users who had been running UIDE /N1 (no hard-disks), to
avoid VirtualBox problems, can now try UIDE /E instead.
/N1 causes UIDE to totally ignore all hard-disks, while
/E does permit hard-disk data to get cached, after UIDE
calls the BIOS to do disk I-O.   This is much better!

Jack R. Ellis


--
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE /E For VirtualBox Now Officially Released.

[Jim Hall]

THANKS, Jack!

I've mirrored this release on ibiblio, and updated the software list.
A news item should appear on the www.freedos.org site in about an
hour.



On Sun, Jul 24, 2011 at 3:15 PM, Jack gykazequ...@earthlink.net wrote:

 As noted earlier by Rugxulo, Johnson Lam has now posted
 the 22-Jul-2011 DRIVERS.ZIP file on his website at:

 http://johnson.tmfc.net/dos/driver.html

 Thus, the new UIDE and UIDE-S, with their /E emulator
 switch for use by VirtualBox, are officially released
 and users need not E-Mail me directly for the files.

 Users who had been running UIDE /N1 (no hard-disks), to
 avoid VirtualBox problems, can now try UIDE /E instead.
 /N1 causes UIDE to totally ignore all hard-disks, while
 /E does permit hard-disk data to get cached, after UIDE
 calls the BIOS to do disk I-O.   This is much better!

 Jack R. Ellis


 --
 Magic Quadrant for Content-Aware Data Loss Prevention
 Research study explores the data loss prevention market. Includes in-depth
 analysis on the changes within the DLP market, and the criteria used to
 evaluate the strengths and weaknesses of these DLP solutions.
 http://www.accelacomm.com/jaw/sfnl/114/51385063/
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user


--
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] UIDE vs drive power management spin down timers

[Eric Auer]

Jack,

[others: this is a bit long/technical, the summary is that it
is both easy and safe to use shallow drive power management.]

 The problem is WHERE does UIDE or any other driver wait for
 a sleeping, i.e. stand-by hard disk to awaken again??   The
 ATA specs do not make this clear.   Can UIDE simply issue a
 drive-select command to the disk and await ready for it?
 Or, does UIDE actually have to issue a seek or read, and
 then retry that command when first it fails??

As far as I remember, DOS always considers retrying the read.

I seem to remember that MS DOS would crash by showing a non-
useful variant of the critical error dialog if it runs out of
retries, e.g. when using a TSR to make writes always fail, as
opposed to failures which go away when retrying.

 If you can determine a reliable way for ALL disks to come out
 of stand-by mode, i.e. at what point UIDE should have a long
 time-out value, I can program that.   But, it must be COMMON
 to all drives, NO exceptions, or it might cause just as much
 TROUBLE as it resolves!

You can use FDAPM to spin down disks at once: It sends the raw
command (e0, standby) for that to the first 4 disks when you
select spin down and sends immediate idle (e1, idle) to wake
up disks explicitly. However, the latter is not needed as the
disk will automatically spin up when accessed again. BIOS, DOS
(FreeDOS) and lbacache seem to have no problem with this but
of course it would be better to first check the disk self-id,
to only send those commands to drives which care for them.



The I/O sequence for the primary controller is:
out 0x1f6,0xa0 for master or b0 for slave (non-lba command here)
wait (just a tiny bit)
out 0x1f7,command (0xe0 standby/spin down - 0xe1 idle/spin up)
wait (again)
... repeat for port 0x176 / 0x177 for secondary controller.

Related commands:  e6 suspend/sleep (you want to avoid this,
as waking up would need a drive reset), e5 check power state
(does not cause a wake up), ec read self-id (read port 0x1f0
many times to get 512 bytes of data as soon as drive ready?)
and last but not least e3 set idle / spin-down timer :-)



My notes say Seagate Barracuda use 8-12 Watts between idle
and working-and-seeking while using 25 Watts for a few secs
while spinning up, 1 Watt in standby and even less in sleep.

The fact that I cannot grep standby-specific error handlers
in lbacache probably means two things: Lbacache does not have
to retry I/O itself, because DOS does that already and second
neither DOS nor BIOS try to reset harddisks when I/O fails,
nor does lbacache do that for them. I think if your disk is
in sleep / suspend or even bus tri-state mode, it would be as
if it is not really there at all and the BIOS would run in a
bad timeout or similar as it just does not expect that case.



In short: Please check whether fdapm spindown has adverse
effects on anything in UIDE context and implement sending a
0xe3 set idle timer to X minutes UIDE command line option
(where you convert X to a suitable byte of N*12 if N at most
20, otherwise X = 240 + round(N/30) with a maximum N = 330),
at your choice either for sending the 0xe3 to all drives or
only to certain drives based on a choice of the user or 3rd
only to drives for which setting the idle timer is useful,
based on checking the drive's self-id at UIDE driver start.



To already answer some possible questions: CD/DVD drives do
not seem to have problems with the immediate standby or
immediate idle, but hdparm -I does not list anything on
this topic for my DVD drive (only lists supported PIO / DMA
modes) while the report for my harddisk is far more verbose:

   Queue depth: 32
   Standby timer values: spec'd by Standard, no device specific minimum
...
   Recommended acoustic management value: 254, current value: 128
(this is about how fast and noisy seeks should be done etc)

Supported features for the harddisk:

SMART, Power Management, Write Cache, Look-Ahead, Automatic
Acoustic Management, 48-bit LBA, Cache Flush, SMART Logging
and SMART Self-Test, NCQ, 3Gb/s SATA, Host-initiated bus(?)
(says interface) Power Management, (optional) Persistent
Settings (preserve over reboot etc), various SMART SCT I/O
and a number of other features.



No power saving related features are reported for my CD/DVD
drive and running  smartctl -d ata -a  for it for example
just returns the model, support for ATA7, no SMART support.
Trying with -d sat (SCSI to ATA layer, 16 byte variant) is
even worse, the drive does not even give a model name then.

As I am evil, I just sent -y standby, --idle-immediately as
well as --idle-unload (also parks heads?) and -Y sleep to
my CD/DVD drive via hdparm anyway. Drive reactions/symptoms:

None that I noticed at all for --idle-*, a tiny delay for -y
and a bigger delay together with a kernel log message saying
that the SATA link got reset when I used the -Y command :-p

Setting the idle timeout (hdparm -S) for my CD/DVD drive,
which as mentioned claims to not support any 

Re: [Freedos-user] UIDE vs drive power management spin down timers

[Jack]

Eric,

I read through and understood all your comments about hard-disk
power management, etc.

My problem is:  I am not-interested in being the one who does
power management.   If DOS or the BIOS wants to save power thru
putting disks into stand-by mode, let them do it.   UIDE is a
disk I-O driver, not a power-management tool, and I desire to
keep such things OUT of UIDE's logic!

Re: handling disk drives which ARE in stand-by mode, if all I
need to do is allow some more time for them to spin-up, that is
relatively easy.   UIDE's CD/DVD logic currently allows 7 secs.
for spin-up and 3 seconds for track-to-track seeks, which I had
forgotten -- I had not looked at that logic for almost 5 years!

Assuming 7 seconds should be long enough! for a hard disk, as
well, I can simply use that value as a timeout during disk I-O,
not the current 400-msec timeout.   Shall experiment re: this
idea.   Might cause some confusion among UIDE users, who will
now see a 7-second delay in some error handling.   But, if UIDE
needs only a timeout change to handle sleeping hard disks, it
might be worth updating only 1 byte in its DoIO subroutine!

Jack R. Ellis


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE vs drive power management spin down timers

[Eric Auer]

Jack,

 I read through and understood all your comments about hard-disk
 power management, etc.
 
 My problem is:  I am not-interested in being the one who does
 power management.   If DOS or the BIOS wants to save power thru
 putting disks into stand-by mode, let them do it...

There is not much to do there, as you only tell the disk once
and then the disk itself does the rest. But it would be good to
know from you that UIDE is (as predicted) happy to wait a moment
for idle disks to spin back up as that in fact does not need any
explicit handling by UIDE anyway.

However, I would be happy if UIDE could do the sending of the
idle timer config command to the disk because: It already does
raw drive I/O anyway and it already has some command line parser
anyway so it would only take a few more (non-resident) bytes to
let UIDE send this command when the user puts the corresponding
command line option during UIDE start-up. That way, no separate
tool would be needed which would duplicate existing UIDE logics.



 UIDE is a disk I-O driver, not a power-management tool, and
 I desire to keep such things OUT of UIDE's logic!

Yet UIDE already probably does drive setup communication with
the disk for selection of the right communication speed so my
point is it would be only a small step to make it possible to
send other drive (e.g. idle timer) setup commands with it.

 relatively easy.   UIDE's CD/DVD logic currently allows 7 secs.
 for spin-up and 3 seconds for track-to-track seeks, which I had
 forgotten -- I had not looked at that logic for almost 5 years!

Interesting. So it can in fact report a time-out, but that should
simply make DOS try again. As FreeDOS tries 5 times, you get much
more than 3 or 7 seconds in the end, depending on which timeouts
are used for int 13 functions 0, 2, 3, 42 and 43. Long enough :-)

 Assuming 7 seconds should be long enough! for a hard disk, as
 well, I can simply use that value as a timeout during disk I-O,
 not the current 400-msec timeout.   Shall experiment re: this

Thanks - and see above.



 idea.   Might cause some confusion among UIDE users, who will
 now see a 7-second delay in some error handling.

Good question. This would only make delays longer for errors that
would never end without explicit error handling but I understand
that users could still notice. For example I remember that using
CompactFlash CF cards with a (purely mechanical) IDE adapter plug
can have such hangs for low quality cards - in particular when
you combine that plug with a SATA-IDE adapter with cheap chipset.

So I guess such hangs would get longer with longer timeouts, as
it might take the driver longer to give up the access attempt
and decide to give the drive a smack of reset to reactivate it
no matter whether it is the driver or just DOS which says reset.

 But, if UIDE
 needs only a timeout change to handle sleeping hard disks, it
 might be worth updating only 1 byte in its DoIO subroutine!

Nice, thanks :-)

Eric

PS: Of course a stall/crash of a CF/SD/... card affects any OS.



--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE vs drive power management spin down timers

[Jack]

Eric,

 ... My problem is:  I am not-interested in being the one who
 does power management.   If DOS or the BIOS wants to save power
 thru putting disks into stand-by mode, let them do it...

 There is not much to do there, as you only tell the disk once
 and then the disk itself does the rest.

Amen!, so let the user handle this thru the BIOS setup routines
and let the BIOS tell the disk what to do during system boot!
BIOS vendors have many more programmers than just me by myself!

 But it would be good to know from you that UIDE is (as predicted)
 happy to wait a moment for idle disks to spin back up, as that in
 fact does not need any explicit handling by UIDE anyway.

UIDE's CD/DVD logic is happy to wait for up to 7 seconds, and I
will look into changing its disk logic from 400-msec to 7 seconds
as well.

 However, I would be happy if UIDE could do the sending of the
 idle timer config command to the disk because:  It already does
 raw drive I/O anyway and it already has some command line parser
 anyway so it would only take a few more (non-resident) bytes to
 let UIDE send this command when the user puts the corresponding
 command line option during UIDE start-up. That way, no separate
 tool would be needed which would duplicate existing UIDE logic.

Actually, UIDE has NOT changed any disk-configuration settings by
the BIOS since late 2005, when I got into TROUBLE doing so with
some BIOS programs!   UIDE now only reads I-O and DMA addresses
for a disk from the BIOS, then runs a disk however the BIOS set
it up.   That, also, is something I want to LEAVE up to the BIOS,
as I don't want any MORE trouble by changing BIOS settings again!

 UIDE is a disk I-O driver, not a power-management tool, and
 I desire to keep such things OUT of UIDE's logic!

 Yet UIDE already probably does drive setup communication with
 the disk for selection of the right communication speed so my
 point is it would be only a small step to make it possible to
 send other drive (e.g. idle timer) setup commands with it.

No, sir!   UIDE does NOT change any communication-speeds nor ANY
other BIOS settings for disks, not since 2005, as I noted above!

 relatively easy.   UIDE's CD/DVD logic currently allows 7 secs.
 for spin-up and 3 seconds for track-to-track seeks, which I had
 forgotten -- I had not looked at that logic for almost 5 years!

 Interesting. So it can in fact report a time-out, but that should
 simply make DOS try again. As FreeDOS tries 5 times, you get much
 more than 3 or 7 seconds in the end, depending on which timeouts
 are used for int 13 functions 0, 2, 3, 42 and 43. Long enough :-)

Any hard-disk function but 2/3/42/43 (reads and writes) is passed
to the BIOS, so function 0 would not be so timed-out by UIDE.   Nor
would UIDE ever declare a timeout -- CD/DVD errors currently post
only general error in such cases, and hard-disk errors would post
only whatever hardware error applies to that part of DoIO which
noted the timeout, likely a DMA error for most cases.   Not a big
problem.   Disk/CD/DVD errors are few and far between, and people
already know that a lot of DOS programs will only display Error!,
leaving exactly WHAT error it was for diagnostic programs, etc.!

 ... Might cause some confusion among UIDE users, who will
 now see a 7-second delay in some error handling.

 Good question.   This would only make delays longer for errors that
 would never end without explicit error handling but I understand
 that users could still notice. For example I remember that using
 CompactFlash CF cards with a (purely mechanical) IDE adapter plug
 can have such hangs for low quality cards - in particular when
 you combine that plug with a SATA-IDE adapter with cheap chipset.

 So I guess such hangs would get longer with longer timeouts, as
 it might take the driver longer to give up the access attempt
 and decide to give the drive a smack of reset to reactivate it
 no matter whether it is the driver or just DOS which says reset.

If DOS does 5 retries, as you indicate, this would cost the user a
maximum of 35 seconds (my 7 seconds * 5 tries) and thus is NOT any
sort of an indefinite hang!I would indicate in UIDE's README
that an actual [rare!] disk error may now take that long, before
DOS gives-up on it and reports something to the user.

 But, if UIDE needs only a timeout change to handle sleeping
 hard disks, it might be worth updating only 1 byte in its DoIO
 subroutine!

 Nice, thanks :-)

That was only my Thought while eating breakfast! this morning,
but I shall test it out, later today!

Jack R. Ellis


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user 

Re: [Freedos-user] UIDE vs drive power management spin down timers

[Eric Auer]

Jack,

 There is not much to do there, as you only tell the disk once
 and then the disk itself does the rest.
 
 Amen!, so let the user handle this thru the BIOS setup routines
 and let the BIOS tell the disk what to do during system boot!
 BIOS vendors have many more programmers than just me by myself!

I have not yet seen a desktop BIOS which implements this, alas. I do
have an adware DOS tool for it, showing a splash screen for a BBS or
similar when you run it and of course bigger than needed, but free.

 Actually, UIDE has NOT changed any disk-configuration settings by
 the BIOS since late 2005, when I got into TROUBLE doing so with
 some BIOS programs!   UIDE now only reads I-O and DMA addresses

Interesting, but which trouble did which setting cause?

 Any hard-disk function but 2/3/42/43 (reads and writes) is passed
 to the BIOS, so function 0 would not be so timed-out by UIDE.   Nor
 would UIDE ever declare a timeout

Why not? There is an error code (0x80) defined for that in int 0x13.

 If DOS does 5 retries, as you indicate, this would cost the user a
 maximum of 35 seconds (my 7 seconds * 5 tries) and thus is NOT any
 sort of an indefinite hang!

What I meant is that when the disk is in a state where only a reset
can make it continue, the driver will wait 7 seconds. If it is in a
state where nothing will make it continue (e.g. un-hotplugged it?),
DOS will take 35 seconds until it displays an error message. In the
7 second case, the user will in the worst case see a delay of 7 sec
plus the time needed to spin up, but more likely only the always-
present delay caused by the time needed to spin up.

 That was only my Thought while eating breakfast! this morning,
 but I shall test it out, later today!

Have a nice afternoon then :-)

Eric


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE vs drive power management spin down timers

[Jack]

Eric,

 I have not yet seen a desktop BIOS which implements this, alas [disk
 spin-down timeouts, etc.].  I do have an adware DOS tool for it,
 showing a splash screen for a BBS or similar when you run it and of
 course bigger than needed, but free.

Desktop BIOS routines are usually not-interested in saving power thru
spin-down timeouts or other such tricks.   Laptop BIOS routines ARE
interested, since their power is limited when using batteries.   Thus
it is mainly laptops we address here, and their BIOS routines DO have
the needed hard-disk logic.

 Actually, UIDE has NOT changed any disk-configuration settings by
 the BIOS since late 2005, when I got into TROUBLE doing so with
 some BIOS programs!   UIDE now only reads I-O and DMA addresses

 Interesting, but which trouble did which setting cause?

With a few BIOS routines back in 2005 (maybe obsolete, now), setting
any UltraDMA mode OTHER than what the BIOS set did not work!   To be
safe, I got RID of such mode-set logic in my drivers, back then.

 Any hard-disk function but 2/3/42/43 (reads and writes) is passed
 to the BIOS, so function 0 would not be so timed-out by UIDE.   Nor
 would UIDE ever declare a timeout ...

 Why not? There is an error code (0x80) defined for that in int 0x13.

Note in my drivers' UltraDMA DoIO subroutine, it is always waiting
for either controller/drive ready or DMA end.   If those events do
not occur, hard to tell if the controller/disk has failed or if they
just took too long.I have assumed a disk will finish I-O in at
most 400 msec, and if not, it was a hardware failure, not a timeout.
So, I have never used BIOS code 080h.   Same situation even if the
DoIO timeout becomes 7 seconds, to handle disk spin-up.   No way I
can know if the hardware failed, so I doubt I can use code 080h.

 If DOS does 5 retries, as you indicate, this would cost the user a
 maximum of 35 seconds (my 7 seconds * 5 tries) and thus is NOT any
 sort of an indefinite hang!

 What I meant is that when the disk is in a state where only a reset
 can make it continue, the driver will wait 7 seconds. If it is in a
 state where nothing will make it continue (e.g. un-hotplugged it?),
 DOS will take 35 seconds until it displays an error message. In the
 7 second case, the user will in the worst case see a delay of 7 sec
 plus the time needed to spin up, but more likely only the always-
 present delay caused by the time needed to spin up.

Understood, if in fact DOS issues a drive-reset on any error.   Also,
note that my drivers do NOT allow removable or hot-pluggable HARD
disks, since I cannot be sure all DOS kernels can handle media-change
events in their HARD-disk logic!

Jack R. Ellis


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE

[Eric Auer]

Hi Marcos, Jack,

 Readme.Txt says Power-saving features such as a 'drive
 spin-down timeout' should be DISABLED.
...
 Is that what I should disable? If so, does this mean that
 the hard disk must keep running all the time if UIDE is used?

Of course DOS will freeze for a short moment when it has to
wait for a harddisk to spin up again, but as I never had a
bigger problem than that with power-saving in DOS without
UIDE, I would like to suggest the opposite of what the UIDE
readme.txt seems to say at the moment:



Could UIDE be used to configure the power saving timeout of
your harddisks? The involved IDE/ATA commands are relatively
simple. They could be sent to either all disks which, based
on their self-ID, support power saving, or to one selected
disk, using any suitable command line syntax for the latter.

Of course UIDE should in addition be able to wait in a safe
way when it encounters a sleeping disk which has to spin up
first. Should be possible with small error handling changes.



This is not to be confused with e.g. bus tri-state or with
power-up in standby or similar extreme power savings. It
is also possible to either standby or suspend disks. I think
the best combination of comfort and savings is STANDBY mode,
as SUSPEND (sleep, communication shut down) would require a
drive reset to wake up which would need extra error handling
and automatic reset / retry etc, in short would be annoying.



Standby simply means the drive spins down so the next attempt
to access it will take a while because the drive will have to
spin up again first. Harddisks have a built-in timer for this
and only need a setup command once to enable auto-sleep. The
setup uses one byte to specify the timeout in a slightly weird
way: 0 = none, 1..240 = N*5 seconds, 241..251 = (N-240)*30 min
which means 5 sec to 20 min or 0.5 to 5.5 hours timeout :-)

Setting the spin-down timeout at the moment when UIDE is loaded
would be a nice combination to would avoid needing other tools.

Regards, Eric



PS: Bus tri-state is at most useful for non-hot unplugging and
needs a heavy reset to re-start the drive, while powering up in
standby is for people who want to reduce boot-up power peaks
by keeping non-boot(!) disks in standby until they are actually
needed. Setting this for a boot disk would be very strange: It
would not save energy and a BIOS timeout might skip the disk.


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE

[Jack]

Eric,

 Of course DOS will freeze for a short moment when it has to
 wait for a harddisk to spin up again, but as I never had a
 bigger problem than that with power-saving in DOS without
 UIDE, I would like to suggest the opposite of what the UIDE
 readme.txt seems to say at the moment:

 Could UIDE be used to configure the power saving timeout of
 your harddisks? The involved IDE/ATA commands are relatively
 simple.   They could be sent to either all disks which, based
 on their self-ID, support power saving, or to one selected
 disk, using any suitable command line syntax for the latter.

 Of course UIDE should in addition be able to wait in a safe
 way when it encounters a sleeping disk which has to spin up
 first.   Should be possible with small error handling
 changes ...

The problem is WHERE does UIDE or any other driver wait for
a sleeping, i.e. stand-by hard disk to awaken again??   The
ATA specs do not make this clear.   Can UIDE simply issue a
drive-select command to the disk and await ready for it?
Or, does UIDE actually have to issue a seek or read, and
then retry that command when first it fails??

If you can determine a reliable way for ALL disks to come out
of stand-by mode, i.e. at what point UIDE should have a long
time-out value, I can program that.   But, it must be COMMON
to all drives, NO exceptions, or it might cause just as much
TROUBLE as it resolves!

Jack R. Ellis


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] UIDE

[Marcos Favero Florence de Barros]

I don't know whether the information below is of any value, but
I'm reporting it anyway, just in case.

I have been using UIDE for almost a year in one desktop and two
notebooks, blissfully unaware that hard disks are not supposed to
sleep.

All three computers were set to spin down their disks.  Even
though I work for about 6 hours every day on FreeDOS, perhaps a
couple of files were lost in that year.  So, at least with these
computers, it was not disastrous to have UIDE and sleeping disks.

By the way, the same applies to LBACache, which I used for 3
years prior to UIDE.

Regards,

Marcos


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] UIDE driver help

[James Collins]

Hello,

I am trying to set up support for a cd/dvd drive on my freedos. I am using vbox 
on a mac running freedos as my operating system.

I want to be able to use my cd/dvd drive on my MacBook pro laptop. I have the 
drivers for UIDE. I have read the readme file, but it is very technical. I 
could use some help loading the drivers.

Do I have to edit my config.sys file? Do I put the drivers, that I downloaded 
on my c drive?

I could use some help, my goal is to be able to access my cd/dvd drive on my 
mac while in freedos. Like I could put in a cd and then in freedos change to 
drive a or b or whatever letter is assigned the cd drive and access a cd in my 
MacBook pro cd drive.

Any help would be appreciated.

Sent from my iPhone
--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] UIDE

[Marcos Favero Florence de Barros]

Hi Jack Ellis and others,

I also have a couple of questions about UIDE.

Question 1.

Can we continue using the /PM switch with the new release of
UIDE?

The reason I'm asking is that new README.TXT file does not
mention it anymore (except in the Revision Summary).

Question 2.

Readme.Txt says Power-saving features such as a 'drive
spin-down timeout' should be DISABLED.

My setup (AMIBIOS Version 2.5, 1997) does not have a feature
with that specific name, but it does have:

Hard Disk Time Out

Is that what I should disable? If so, does this mean that
the hard disk must keep running all the time if UIDE is used?

The setup also has the following:

Hard Disk Power Down Mode
Standby Time Out
Suspend Time Out

Are these three also involved?



Currently my pertinent FDCONFIG.SYS lines are:

BUFFERS=4   ; (Recommended by Jack Ellis)
devicehigh=C:\FDOS\UIDE\uide.sys /S40


Thanks,

Marcos



--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE driver help

[Bernd Blaauw]

Op 12-5-2011 16:13, James Collins schreef:
 I want to be able to use my cd/dvd drive on my MacBook pro laptop. I have the 
 drivers for UIDE. I have read the readme file, but it is very technical. I 
 could use some help loading the drivers.

 Do I have to edit my config.sys file? Do I put the drivers, that I downloaded 
 on my c drive?

 I could use some help, my goal is to be able to access my cd/dvd drive on my 
 mac while in freedos. Like I could put in a cd and then in freedos change to 
 drive a or b or whatever letter is assigned the cd drive and access a cd in 
 my MacBook pro cd drive.

Loading support for optical disc drives (CD/DVD/BD) by itself is quite 
simple really:
* add a line in CONFIG.SYS (or FDCONFIG.SYS, whichever you're using) as 
follows: DEVICE=C:\FDOS\UIDE.SYS /D:FDCD0001
* add a line in AUTOEXEC.BAT as follows: C:\FDOS\SHSUCDX /D:FDCD0001

Where exactly you add each line to each file is your own decision, 
doesn't matter much. Make sure the FDCD0001 or whichever name you 
choose, is equal for both UIDE and SHSUCDX
However as UIDE is also able to cache/buffer drives, it expects some XMS 
memory provided by for example HIMEM.EXE. In effect:
DEVICE=C:\FDOS\HIMEM.EXE
DEVICE=C:\FDOS\UIDE.SYS /D:FDCD0001

However it might also be possible to disable the cache entirely, and 
thus let UIDE work as a basic (CD) driver without requiring XMS memory 
or XMS driver:
DEVICE=C:\FDOS\UIDE.SYS /D:FDCD0001 /N1 /N3 /B

Above things should work fine, if not let the mailing list know. Both 
UIDE and SHSUCDX have many options and a lot of documentation if you'd 
like to know more.
Ofcourse if your CD drive isn't presented in Virtualbox as being on an 
SATA/IDE controller/port, UIDE won't be much help.

--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] UIDE

[Jack]

Marcos,

 I also have a couple of questions about UIDE.

 Question 1.

 Can we continue using the /PM switch with the new release of UIDE?

You can, but it will be ignored!   I deleted the protected mode
logic from UIDE in 2010, as the standard UIDE using XMS caching
became 96% as fast as the /P and /PM caches, from better handling
of XMS memory.   No further need for the protected mode logic!

 Question 2.

 Readme.Txt says Power-saving features such as a 'drive spin-down
 timeout' should be DISABLED.   My setup (AMIBIOS Version 2.5,
 1997) does not have a feature with that specific name, but it
 does have:
  Hard Disk Time Out

 Is that what I should disable?

Yes.   Hard disk time-outs are not part of the ATA disk spec,
and many laptop vendors have unusual schemes for supporting
them.   So, there is no way I can program UIDE for all of that!

 If so, does this mean that the hard disk must keep running all
 the time if UIDE is used?

Correct, for the reason I note above.

 The setup also has the following:

   Hard Disk Power Down Mode
   Standby Time Out
   Suspend Time Out

 Are these three also involved?

Yes.   ANYTHING that would cause a hard-disk or CD/DVD drive to
appear not ready for extended time spans should be disabled!

 Currently my pertinent FDCONFIG.SYS lines are:

   BUFFERS=4   ; (Recommended by Jack Ellis)
   devicehigh=C:\FDOS\UIDE\uide.sys /S40

Looks good to me!   I recommend BUFFERS=4, since UIDE caches
all directory sectors it handles, as well as data files.This
performs MUCH better than the DOS BUFFERS= command, unless one
can set BUFFERS=32 or more, which gives a slight increase in
speed even with UIDE.   But few systems can spare the HMA memory
for BUFFERS=32, so using UIDE is the better bargain!

Also, do try /S50 or /S100, if you can afford 50-MB or 100-MB of
XMS memory assigned to UIDE.   /S40 sets only 1280 cache blocks,
while the 50/100-MB caches have 1600 cache blocks.   More blocks
gives better directory handling, as there are a LOT of directory
sectors handled by DOS, and extra cache blocks help with them.

Jack R. Ellis


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] UIDE

[Marcos Favero Florence de Barros]

Hi Jack,

Thanks :-)

Marcos



--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] UIDE driver help

[Jack]

James,

I am the author of the UIDE and UIDEJR drivers, and I will try
to answer your questions.

 I am trying to set up support for a cd/dvd drive on my freedos.
 I am using vbox on a mac running freedos as my operating system.

I assume your vbox responds the same as a true PC system.   If
it does not, UIDE/UIDEJR may not work, as they interrogate the
PCI BIOS to find what controllers and hard-disks are present.

 I want to be able to use my cd/dvd drive on my MacBook pro laptop.
 I have the drivers for UIDE.   I have read the readme file, but it
 is very technical.   I could use some help loading the drivers.

Do note Section 5 of the README file, which gives samples of the
commands needed in CONFIG.SYS, or FDCONFIG.SYS in your case, for
loading UIDE.

 Do I have to edit my config.sys file?

Yes, you do.   At least a command similar to the following must be
added to it, for loading UIDE --

   DEVICE=C:\DRIVERS\UIDE.SYS /S100 /D:MYCDROM

If you want only a basic non-caching driver, you can load UIDEJR
[i.e. junior UIDE] using the same type of CONFIG.SYS line --

   DEVICE=C:\DRIVERS\UIDEJR.SYS /D:MYCDROM

The /D: name must be the same as given to SHSUCDX or SHCDX33E (my
equivalent CD/DVD manager), so the two programs can communicate
correctly re: the CD/DVD drives they handle.   Also, since UIDEJR
is not a caching driver, it needs no /S cache-size switch.

 Do I put the drivers, that I downloaded on my c: drive?

They can be on any drive or in any directory you like, as long as
the DEVICE= in your command line tells FreeDOS exactly where they
are.

 I could use some help, my goal is to be able to access my cd/dvd
 drive on my mac while in freedos.   Like I could put in a cd and
 then in freedos change to drive a or b or whatever letter is
 assigned the cd drive and access a cd in my MacBook pro cd drive.

If you intend only occasional use of CD/DVD files, you may want
to download my latest 10-May-2011 DRIVERS.ZIP file from --

http://johnson.tmfc.net/dos/driver.html

Johnson Lam has been my partner since 2004 in testing and distri-
buting the drivers, and his above website still hosts the drivers
for me.

In the 10-May-2011 DRIVERS.ZIP, the latest UIDEJR.SYS driver takes
only 2032 bytes of memory in its CD/DVD only form, loaded as --

   DEVICE=C:\DRIVERS\UIDEJR.SYS /D:MYCDROM /N1

The /N1 switch tells it No hard-disks and saves about 1100 bytes
of memory, i.e. it omits disk logic and runs only CD/DVD drives.

The latest UIDEJR is not particular re: being loaded with an XMS
manager, e.g. HIMEM or my own XMGR.If an XMS manager is there,
UIDEJR using the above command-line requests 128K of XMS memory as
its I-O buffer.   The buffer is used only when UltraDMA may NOT be
used, as when a DOS program does input to an odd address buffer,
etc.   If XMS is unavailable, UIDEJR will handle such misaligned
CD/DVD input using old PIO mode [Programmed input-output, i.e.
SLOW!].

The above DEVICE= command always places the driver in low memory
i.e. in the original 640K of DOS memory.   If you use  DEVICEHIGH=
instead, the driver can be loaded into upper memory beyond 640K.
Doing so requires an XMS manager and either (A) the UMBPCI driver,
which can map system Shadow RAM into the 640K to 1-MB area, or
(B) one of the EMM drivers such as JEMMEX, or the combination of
HIMEMX + JEMM386 or my own XMGR + JEMM386, which can map regular
memory into the 640K to 1-MB range.UMBPCI is simpler, but more
limited in functionality (complex subject!), so if you want to use
upper-memory, a better choice is an XMS manager and an EMM driver,
or the combined JEMMEX.

Upper memory schemes are admittely a lot more complicated!If
you are new to FreeDOS, loading UIDEJR just as I show above will
handle your CD/DVD files O.K.

Do remember to load either SHSUCDX, my own SHCDX33E, or MSCDEX, in
your AUTOEXEC.BAT file.   UIDE/UIDEJR are only the drivers for a
CD/DVD drive -- Its file manager is one of the above 3 programs!
You need to add a line in AUTOEXEC similar to --

   C:\DRIVERS\SHSUCDX.COM /D:MYCDROM /C

The /C switch keeps the driver where it was loaded, i.e. if into
low-memory, it shall not try to move itself to upper-memory, and
vice-versa.And again, the name after /D: must match the name
given to UIDE or UIDEJR.   My drivers default to  UDVD1  thus if
you give SHSUCDX/SHCDX33E the switch  /D:UDVD1  you needn't have a
/D: switch on the CONFIG.SYS command-line which loads UIDE/UIDEJR.

Anything further, send me a private E-Mail, and I shall be happy
to respond!

Jack R. Ellis


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list

Re: [Freedos-user] UIDE Question.

[Robert Riebisch]

japhethx gmail wrote:

 In my previous UIDE comments the word P-R-E-S-E-N-T
 was truncated by whatever forum software is in use to
 the word S-E-N-T!!
 
 No problem here. There are 3 occurances of sent in your first post, and all 
 threee have a nice pre prefix.

Same here in Thunderbird 2.0.0.23 (Windows/20090812) and at
http://www.mail-archive.com/freedos-user@lists.sourceforge.net/msg09851.html.

BUT
https://sourceforge.net/mailarchive/forum.php?thread_name=op.u8y689w0sxzqeq%40dialup-4.246.135.135.dial1.sanjose1.level3.netforum_name=freedos-user
shows only sent three times! Japheth's reply at
https://sourceforge.net/mailarchive/forum.php?thread_name=4B8E1358.3090606%40googlemail.comforum_name=freedos-user
also misses P-R-E (w/o the hyphens).

Must be a SF.net display error.

Threaded view is also defunct.

Robert Riebisch
-- 
BTTR Software
http://www.bttr-software.de/

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] UIDE Question.

[Jack]

Maybeway36 and Geraldo --

I am the writer of UIDE.  To answer your confusion about
the UIDE driver, the following may be of help --

UIDE is meant to be a Universal IDE driver for hard-disk
and CD/DVD drives.   It enables UltraDMA logic for SATA or
IDE disks and CDs/DVDs, which some older BIOS programs may
not do.

When UIDE loads, it asks the PCI BIOS if any Legacy Mode
(address 3F0h, 370h, 3E8h, and 368h) and Native PCI Mode
(addresses set thru the PCI BIOS) SATA and IDE controllers
are present.   If so, UIDE then issues EDD BIOS calls to
match the posted I-0 addresses for each hard-disk to the
controller addresses.   Disks which match are run directly
by UIDE with normal UltraDMA I-O logic -- UltraDMA is part
of the design for both SATA and IDE controllers.

CD/DVD drives were not part of the original IBM BIOS spec,
so they cannot be detected by PCI/EDD BIOS calls.   UIDE
thus does its own examination of every SATA/IDE controller
detected above, and it then runs the first 8 CD/DVD drives
found.   Unlike hard-disks, which MUST be on a SATA or IDE
controller for UIDE to run them, UIDE will handle a CD/DVD
drive on non-PCI legacy controllers, needed by some very
old PC systems.   CD/DVD drives are enabled to do UltraDMA
I-O by UIDE.   If a (very old) CD drive cannot do UltraDMA
it is run by UIDE in PIO mode, slow but it does the job!

After it detects and enables SATA/IDE hard-disks or CD/DVD
drives, UIDE caches data for them and for A:/B: diskettes!
Both directories and data files are cached, which offers a
HUGE speed improvement to all DOS systems, especially when
using diskette or CD/DVD files.   Hard-disks declared to a
BIOS but which did not match a SATA/IDE controller (e.g.
SCSI, USB, etc.) are still cached by UIDE which calls the
BIOS to handle I-O for the different type of disk.   Upon
return from the BIOS, UIDE caches the odd disk's data as
well.   CD/DVD drives not detected by UIDE are not cached,
as the BIOS offers UIDE no info about odd CD/DVD drives.

XMS memory is used as the cache, and UIDE now allows up to
4-GB of memory for caching.   More reasonably, users would
likely give UIDE up to 3-GB, keeping 500-MB for a RAM-disk
(as in my RDISK driver) and the last 500-MB for user tasks
that also need some XMS memory.

UIDE does BOTH read- and write-caching.   UIDE uses Write
Through caching, which writes new output data immediately
to disk, unlike Write Back caching that delays writes to
see if the data may get updated again.   Write Backs are
more efficient for compilers or databases but are HORRIBLY
complex!   I want UIDE to work with all DOS versions, so I
will NOT include all the needed special hooks to allow a
Write Back cache.   UIDE with Write Through caching is
fast-enough anyway for most tasks!   [Writing diskettes is
slow, due to updating directories on track 0.But, when
reading diskettes, directory caching DOES improve speed!].

At present, UIDE does not directly handle SCSI or USB hard
disks, although if they are declared as BIOS units, UIDE
calls the BIOS for their I-O and then caches their data,
afterward.   Sadly, most USB hard-disks are NOT declared
as BIOS units, so UIDE may not be able to run them at all.
And at present UIDE handles only SATA or IDE CD/DVD drives
as it does not detect controllers other than SATA and IDE.
Finally, UIDE does not-yet have logic to handle new AHCI
controllers.   This should not be a problem, as most AHCIs
can be configured via the BIOS to legacy or compatible
mode (meaning IDE!), in which case UIDE will run them O.K.

Note that UIDE still DOES allow external drivers to call
it for caching, in ways similar to its own call the BIOS
logic.   Nobody has ever used this, though if anybody DOES
want to interface a SCSI/USB/etc. driver to UIDE's cache
I would be happy to work with them to achieve this.

On running UIDE with LBACache/CDRCache, this should NOT be
necessary.UIDE provides much-larger and usually faster
caches.   In cases when protected mode (JEMM386) is used
and absolute-maximum speed with smaller caches is desired,
LBAcache may be of benefit (protected mode does slow XMS
usage by UIDE a little).   Real mode (UMBPCI) users will
not have any speed problems due to XMS memory.   Also, for
systems with SCSI or other-type CD/DVD drives that are not
detected by UIDE, then CDRcache may be of benefit.But,
for most users who have only SATA/IDE hard-disks or CD/DVD
drives, UIDE should be used without LBACache or CDRcache.


--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE Question.

[Jack]

In my previous UIDE comments the word P-R-E-S-E-N-T
was truncated by whatever forum software is in use to
the word S-E-N-T!!   I have NEVER seen such a thing
occur in E-Mail or forums before!   Please understand
that what seems to be S-E-N-T should be read as the
words At p-r-e-s-e-n-t.   Someone please FIX this!!

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE Question.

[Geraldo Netto]

Hi!

eheheh :)
relax Jack, nice shot regarding uide :)
once english is my second language,
my english is definitely far worse than your :)

Kind Regards and Best Wishes,

Geraldo
Non dvcor, dvco = Sapere Aude
São Paulo, Brasil, -3gmt
site: http://exdev.sf.net/
github: http://github.com/geraldonetto
msn: geraldo_b...@hotmail.com
skype: geraldo-netto
icq: 145-061-456



On 3 March 2010 02:32, Jack mezukoyl...@sprynet.com wrote:
 In my previous UIDE comments the word P-R-E-S-E-N-T
 was truncated by whatever forum software is in use to
 the word S-E-N-T!!   I have NEVER seen such a thing
 occur in E-Mail or forums before!   Please understand
 that what seems to be S-E-N-T should be read as the
 words At p-r-e-s-e-n-t.   Someone please FIX this!!

 --
 Download Intel#174; Parallel Studio Eval
 Try the new software tools for yourself. Speed compiling, find bugs
 proactively, and fine-tune applications for parallel performance.
 See why Intel Parallel Studio got high marks during beta.
 http://p.sf.net/sfu/intel-sw-dev
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user


--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE Question.

[japhethx gmail]

 In my previous UIDE comments the word P-R-E-S-E-N-T
 was truncated by whatever forum software is in use to
 the word S-E-N-T!!

No problem here. There are 3 occurances of sent in your first post, and all 
threee have a nice pre prefix.

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE question

[Geraldo Netto]

Hi!

I didn't know that, oops
btw, what is up with FD 1.1?
i still busy(oops, my thesis got rejected here)
but of course, as soon as i can, i'll contribute

See Ya!

Geraldo
Non dvcor, dvco = Sapere Aude
São Paulo, Brasil, -3gmt
site: http://exdev.sf.net/
github: http://github.com/geraldonetto
msn: geraldo_b...@hotmail.com
skype: geraldo-netto
icq: 145-061-456

On 26 February 2010 18:53, Bernd Blaauw bbla...@home.nl wrote:
 Op 26-2-2010 22:17, Geraldo Netto schreef:
 Hi maybeway36,

 Uide is different from lbacache/cdrcache
 Uide enables ultra dma[1] modes for harddisks
 while lbacache/cdrcache do cache for harddisks/cdrom

 Geraldo, by default UIDE includes caching for diskettes, harddisks on
 controllers and IDE/SATA optical devices.
 What UIDE doesn't help with is when using different drivers like USB or
 SCSI CD drivers, or ELTORITO.SYS (for non-emulation booting).

 I think LBACACHE and CDRCACHE have better statistics you can query, though.

 Bernd

 --
 Download Intel#174; Parallel Studio Eval
 Try the new software tools for yourself. Speed compiling, find bugs
 proactively, and fine-tune applications for parallel performance.
 See why Intel Parallel Studio got high marks during beta.
 http://p.sf.net/sfu/intel-sw-dev
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user


--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] UIDE question

[maybeway36]

With UIDE (http://johnson.tmfc.net/dos/driver.html), do I need LBACACHE and
CDRCACHE anymore, or does UIDE server their functions as well?
-maybeway36
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE question

[Geraldo Netto]

Hi maybeway36,

Uide is different from lbacache/cdrcache
Uide enables ultra dma[1] modes for harddisks
while lbacache/cdrcache do cache for harddisks/cdrom

[1] http://en.wikipedia.org/wiki/Parallel_ATA

See Ya,

Geraldo
Non dvcor, dvco = Sapere Aude
São Paulo, Brasil, -3gmt
site: http://exdev.sf.net/
github: http://github.com/geraldonetto
msn: geraldo_b...@hotmail.com
skype: geraldo-netto
icq: 145-061-456

On 26 February 2010 17:41, maybeway36 maybewa...@gmail.com wrote:
 With UIDE (http://johnson.tmfc.net/dos/driver.html), do I need LBACACHE and
 CDRCACHE anymore, or does UIDE server their functions as well?
 -maybeway36

 --
 Download Intel#174; Parallel Studio Eval
 Try the new software tools for yourself. Speed compiling, find bugs
 proactively, and fine-tune applications for parallel performance.
 See why Intel Parallel Studio got high marks during beta.
 http://p.sf.net/sfu/intel-sw-dev
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user



--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE question

[Bernd Blaauw]

Op 26-2-2010 22:17, Geraldo Netto schreef:
 Hi maybeway36,

 Uide is different from lbacache/cdrcache
 Uide enables ultra dma[1] modes for harddisks
 while lbacache/cdrcache do cache for harddisks/cdrom

Geraldo, by default UIDE includes caching for diskettes, harddisks on 
controllers and IDE/SATA optical devices.
What UIDE doesn't help with is when using different drivers like USB or 
SCSI CD drivers, or ELTORITO.SYS (for non-emulation booting).

I think LBACACHE and CDRCACHE have better statistics you can query, though.

Bernd

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user