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