Re: [Freedos-user] UIDE.SYS

[Rugxulo]

Hi,

On Wed, Sep 21, 2016 at 5:53 AM, Eric Auer  wrote:
>
> Note that for live CD, you can also often use the tiny
> ELTORITO driver because after booting from CD, you get
> temporary BIOS support for easy CD access.
>
> I could not find a nice link for ELTORITO.SYS, but check
>
> www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/boot/syslinux/
>
> as that may have useful information...? Original site for
> the driver was http://www.nu2.nu/eltorito/ which is gone.
>
> PS: Rugxulo, Jim, please make eltorito.sys easier to find!

syslinux-6.03.zip (from iBiblio above) does have eltorito.sys (and
*.asm for NASM), 1554 bytes, calling itself version "1.5".

Is that what you meant? So you want someone to put a README telling
people that it contains "eltorito.sys"? By itself that's not much
help, is it?

Quoting the SysLinux wiki:

http://www.syslinux.org/wiki/index.php?title=MEMDISK

"
MEMDISK and generic El Torito CD-ROM driver for DOS
-
If you're using MEMDISK to boot DOS from a CD-ROM (using ISOLINUX),
you might find the generic El Torito CD-ROM driver (eltorito.sys) by
Gary Tong and Bart Lagerweij useful. It is now included with the
Syslinux distribution, in the dosutil directory. See the file
dosutil/eltorito.txt for more information.

Example usage of eltorito.sys in CONFIG.SYS:

device=eltorito.sys /X:MSCD0001

Corresponding MSCDEX command which can be placed in AUTOEXEC.BAT:

MSCDEX /X:MSCD0001 /L:X

Where X is the drive letter.
"

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

Re: [Freedos-user] UIDE.SYS

[dmccunney]

On Wed, Sep 21, 2016 at 6:53 AM, Eric Auer  wrote:
> I could not find a nice link for ELTORITO.SYS, but check
>
> www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/boot/syslinux/
>
> as that may have useful information...? Original site for
> the driver was http://www.nu2.nu/eltorito/ which is gone.

The eltorito site is still available through archive.org.  See
https://web.archive.org/web/20150922034605/http://www.nu2.nu/download.php?sFile=eltorito14.zip
for download links.

> Regards, Eric
__
Dennis
https://plus.google.com/u/0/105128793974319004519

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

Re: [Freedos-user] UIDE.SYS

[Don Flowers]

If you are inquiring about the AHCI SATA driver, I have an Acer Aspire and
this is the only driver that gives me Drive Letter Access (DLA) :
http://h20564.www2.hp.com/hpsc/swd/public/detail?swItemId=wk_61401_1#tab2

On Wed, Sep 21, 2016 at 6:53 AM, Eric Auer  wrote:

>
> Hi Ercan,
>
> if I understand you correctly, then the problem is not
> with the harddisk but with CD / DVD / BluRay? Then you
> may want to use the more specific UDVD2 driver instead.
>
> Note that for live CD, you can also often use the tiny
> ELTORITO driver because after booting from CD, you get
> temporary BIOS support for easy CD access.
>
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/ellis/
>
> Newer improved, closed source drivers, on mail request:
>
> http://optimizr.dyndns.org/
>
> I could not find a nice link for ELTORITO.SYS, but check
>
> www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/boot/syslinux/
>
> as that may have useful information...? Original site for
> the driver was http://www.nu2.nu/eltorito/ which is gone.
>
> Regards, Eric
>
> PS: Rugxulo, Jim, please make eltorito.sys easier to find!
>
> > DEVICE=XMGR.SYS
> > DEVICE=UIDE.SYS /D:OP1
> > DEVICE=UIDE.SYS /D:OP2
> >
> > SHSUCDX /~ /D:OP1
>
>
>
>
> 
> --
> ___
> 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.SYS

[Eric Auer]

Hi Ercan,

if I understand you correctly, then the problem is not
with the harddisk but with CD / DVD / BluRay? Then you
may want to use the more specific UDVD2 driver instead.

Note that for live CD, you can also often use the tiny
ELTORITO driver because after booting from CD, you get
temporary BIOS support for easy CD access.

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/ellis/

Newer improved, closed source drivers, on mail request:

http://optimizr.dyndns.org/

I could not find a nice link for ELTORITO.SYS, but check

www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/boot/syslinux/

as that may have useful information...? Original site for
the driver was http://www.nu2.nu/eltorito/ which is gone.

Regards, Eric

PS: Rugxulo, Jim, please make eltorito.sys easier to find!

> DEVICE=XMGR.SYS
> DEVICE=UIDE.SYS /D:OP1
> DEVICE=UIDE.SYS /D:OP2
> 
> SHSUCDX /~ /D:OP1




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

[Freedos-user] UIDE.SYS

[Ercan Ersoy]

Hi. I'm a developed FreeDOS live cd. I want to my live cd has native SATA 
support. But my live CD doesn't support. I laboured UIDE.SYS native SATA 
support on my live cd. I can't my live cd supported native SATA. Tested on 
Oracle VirtualBox and real hardware. But UIDE.SYS driver legacy PATA supports 
very well.


I would like help for this. How I can configure CONFIG.SYS and AUTOEXEC.BAT?


A part of CONFIG.SYS of my live CD's boot floppy image:


DEVICE=XMGR.SYS
DEVICE=UIDE.SYS /D:OP1
DEVICE=UIDE.SYS /D:OP2


A part of AUTOEXEC.BAT of my live CD's boot floppy image:


SHSUCDX /~ /D:OP1


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

[Freedos-user] UIDE.SYS delays boot process in VirtualBox

[Ulrich Hansen]

I have written a description of the boot delay caused by the loading of 
UIDE.SYS in VirtualBox.

https://sourceforge.net/apps/mediawiki/freedos/index.php?title=VirtualBox_-_Chapter_8

Anybody has an idea how to solve this with free software? Would the 
eltorito.sys driver help? I never worked much with CD drives in FreeDOS, so I 
am a bit stuck.

Thanks,
Ulrich
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE.SYS delays boot process in VirtualBox

[Bernd Blaauw]

Op 12-1-2012 19:03, Ulrich Hansen schreef:
 I have written a description of the boot delay caused by the loading of 
 UIDE.SYS in VirtualBox.

 https://sourceforge.net/apps/mediawiki/freedos/index.php?title=VirtualBox_-_Chapter_8

 Anybody has an idea how to solve this with free software? Would the 
 eltorito.sys driver help? I never worked much with CD drives in FreeDOS, so I 
 am a bit stuck.

Wasn't the solution to enable IO APIC or something like that? So a 
different enabled chipset.

ELTORITO.SYS can help, but only if you configure the VM to start with 
booting from CD, after which you boot from harddisk.

Loading UIDE at runtime instead of boottime is also possible, in some 
theoretical CDROM.BAT for example

@echo off
rem load CDEX, without any ISO9660 drivers attached
SHSUCDX /D9 /QQ
DEVLOAD ELTORITO.SYS /D:FDCD
DEVLOAD UIDE.SYS /D:FDCD0001 /N3 /B
SHSUCDHD /F:C:\FDBOOTCD.ISO
rem add drivers only by one
rem change loading order as you like
if exist FDCD SHSUCDX /D:FDCD,D
if exist FDCD0001 SHSUCDX /D:FDCD0001,D
if exist SHSU-CDH SHSUCDX /D:SHSU-CDH,D
if exist SHSU-CDR SHSUCDX /D:SHSU-CDR,D


Alternatives are creating and using an ISO file:
OMI.EXE D: C:\FDBOOTCD.ISO

Or replacing the CD-driver by the closed-source generic OAKCDROM.SYS or 
VIDE-CDD.SYS drivers [ http://www.opus.co.tt/dave/indexall.htm ].

Jack's UIDE.SYS driver performs chipset initialisation which is 
apparently still implemented in a buggy way in the VirtualBox software.

--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE.SYS delays boot process in VirtualBox

[Jack]

 Anybody has an idea how to solve this with free software? Would the  
 eltorito.sys driver help?

 Wasn't the solution to enable IO APIC or something like that? So a
 different enabled chipset.

 ELTORITO.SYS can help, but only if you configure the VM to start with
 booting from CD, after which you boot from harddisk.

I have never used El Torito as I have no CD boot disks (only diskettes)
on my system, so I have no idea if El Torito helps or not.

 Loading UIDE at runtime instead of boottime is also possible, in some
 theoretical CDROM.BAT for example ...

Doubtful this would help at all, since UIDE is going to do exactly the
same checks of the PCI bus for CD/DVD drives, whenever it gets loaded.

 Alternatives are creating and using an ISO file:
 OMI.EXE D: C:\FDBOOTCD.ISO

 Or replacing the CD-driver by the closed-source generic OAKCDROM.SYS or
 VIDE-CDD.SYS drivers [http://www.opus.co.tt/dave/indexall.htm].

I do NOT recommend any of the older generic drivers, since none of them
have UltraDMA logic, and none use file/directory caching.   Omitting both
of these items will cause CD/DVD transfers to run 3 or 4 times slower!

Also, a generic driver normally uses only Legacy IDE device addresses
and cannot see a controller whose addresses might be assigned by PCI to
other values.   This is true for VIDE-CDD, OAKCDROM, my old XCDROM, and
about all other generic CD/DVD drivers.

Note also that GCDROM/XGCDROM (BAD hacks of XCDROM!) claim to support
other addresses, but in fact they have PROBLEMS!

 Jack's UIDE.SYS driver performs chipset initialisation which is
 apparently still implemented in a buggy way in the VirtualBox software.

No other way possible for UIDE!   CD/DVD drives are not part of the BIOS,
so UIDE must detect them by (A) finding all SATA/IDE controllers on the
PCI bus, then (B) examining each controller's device slots for ATAPI CD
drives.

If some of the VirtualBox chipset options exhibit LONG delays when UIDE
issues an Identify ATAPI Device command, VirtualBox needs to get FIXED!


--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE.SYS delays boot process in VirtualBox

[Ulrich Hansen]

Am 12.01.2012 um 20:20 schrieb Jack:
 
 Loading UIDE at runtime instead of boottime is also possible, in some
 theoretical CDROM.BAT for example ...
 
 Doubtful this would help at all, since UIDE is going to do exactly the
 same checks of the PCI bus for CD/DVD drives, whenever it gets loaded.

Correct. It takes the same amount of time. Fortunately the batchfile is run 
whenever the user wants, which is more acceptable than such a long delay at 
boot.

And the boot delay is not really acceptable. Stopwatch says 2min and 49sec. 
This is much more than the 60sec I thought it would be.


 Alternatives are creating and using an ISO file:
 OMI.EXE D: C:\FDBOOTCD.ISO
 
 Or replacing the CD-driver by the closed-source generic OAKCDROM.SYS or
 VIDE-CDD.SYS drivers [http://www.opus.co.tt/dave/indexall.htm].
 
 I do NOT recommend any of the older generic drivers, since none of them
 have UltraDMA logic, and none use file/directory caching.   Omitting both
 of these items will cause CD/DVD transfers to run 3 or 4 times slower!
 
 Also, a generic driver normally uses only Legacy IDE device addresses
 and cannot see a controller whose addresses might be assigned by PCI to
 other values.   This is true for VIDE-CDD, OAKCDROM, my old XCDROM, and
 about all other generic CD/DVD drivers.
 
 Note also that GCDROM/XGCDROM (BAD hacks of XCDROM!) claim to support
 other addresses, but in fact they have PROBLEMS!

And we also should not suggest in our WIki that our users should use unfree 
software illegally to use FreeDOS. So this is not really an option anyway.

 Jack's UIDE.SYS driver performs chipset initialisation which is
 apparently still implemented in a buggy way in the VirtualBox software.
 
 No other way possible for UIDE!   CD/DVD drives are not part of the BIOS,
 so UIDE must detect them by (A) finding all SATA/IDE controllers on the
 PCI bus, then (B) examining each controller's device slots for ATAPI CD
 drives.
 
 If some of the VirtualBox chipset options exhibit LONG delays when UIDE
 issues an Identify ATAPI Device command, VirtualBox needs to get FIXED!

As DOS seems not really to be Oracles priority, we may have to wait. In the 
meantime it is IMHO a good idea that VirtualBox users use Bernds batchfile to 
mount the VirtualBox virtual CD drive whenever they can afford the time.

Thanks!


 --
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE.SYS

[Johnson Lam]

On Mon, 8 Jun 2009 09:59:27 -0700 (PDT), you wrote:

Hi,

Dumb question:  Is UIDE.SYS  _only_  for native  [[motherboard]]  
controllers?  I tried it with two PCI adapter card controllers -- one IDE 
controller and one SATA controller and UIDE.SYS did not find drives connected 
to either of the cards.

More precisely: UIDE.SYS is only for standard INT13 access.

Good news for you, Jack found another potential bug and working on
it, it may or may not affect this, but it's good since it means
UIDE.SYS become more bullet-proof to the bad BIOS.


Rgds,
Johnson.

--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE.SYS

[dos386]

 would be useful as fallback to have at least SOME access to your non-BIOS 
 disks

Why not the fastest SATA AHCI DMA ? Apparently the problem is not
inside UIDE ;-)

 Adding block-device support would take a LOT more code and isn't
 really necessary.   There are two other schemes that can be used
 without changing UIDE --

I haven't asked for adding block-device to UIDE, just non-BIOS disks support,
and I don't need it too __badly__ since I have none by now.




-- 
~~~ wow ~~~

--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE.SYS

[Eric Auer]

Hi!
 would be useful as fallback to have at least SOME access to your non-BIOS 
 disks
 
 Why not the fastest SATA AHCI DMA ? Apparently the problem is not
 inside UIDE ;-)

If your motorbike fails, the fallback is not a plane. It is a bicycle.
In other words, if for example a CF card only supports PIO, neither
UDMA nor AHCI DMA will help you ;-).

 Adding block-device support would take a LOT more code

A ramdisk is often a tiny driver. To give block device access
to UIDE disks, you only need a partition table parser and a
driver similar in size to a ramdisk. I would suggest that both
is put in a driver for UIDE block devices which can be loaded
separately from UIDE. Alternatively, UIDE could provide ASPI
access to the found disks, then already existing drivers as
ASPIDISK can be used for block device access :-).

 I haven't asked for adding block-device to UIDE, just non-BIOS
 disks support...

Support means you access them somehow - just adding them to
int 13 will not give them drive letters, only lowlevel access.

Eric



--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE.SYS

[Christian Masloch]

 Adding block-device support would take a LOT more code

 A ramdisk is often a tiny driver. To give block device access
 to UIDE disks,

Okay..

 you only need a partition table parser

Yes, which would reside in the temporary (discarded) part of the driver.  
Of course that won't decrease it's size on disk.

 and a driver similar in size to a ramdisk.

No.

 I haven't asked for adding block-device to UIDE, just non-BIOS
 disks support...

 Support means you access them somehow - just adding them to
 int 13 will not give them drive letters, only lowlevel access.

Although it is *obvious* at this time, why not use Int2F.0801 (Add new  
block device [to the default DOS block device driver]) to add the drives  
after enabling the Int13 access? The only notice here is that some DOS  
versions use varying layouts (i.e. MS-DOS 7.10+ with FAT32 EBPBs, and I  
hope FreeDOS with FAT32 uses the same layout) so such a feature would have  
to be configured carefully for different versions and code is required to  
tell them apart.

After all, that installation code (which leaves only the actual UPB (DDT)  
in memory) could easily be moved into another program. It could use a  
specific UIDE backdoor (or access UIDE's data, or do something else) to  
get to know which Int13 units are provided by UIDE exclusively; or a  
generic API could be written which could also process added Int13 drives  
provided by different drivers. Then the installation program would read  
 from the provided unit to decide whether the first sector is the MBR, or a  
partition boot sector. It would parse the MBR (if any) and then add block  
devices for each DOS partition.

Regards,
Christian

--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE.SYS

[dos386]

 If your motorbike fails, the fallback is not a plane. It is a bicycle.

Or just your feet ...

 In other words, if for example a CF card only supports PIO,
 neither UDMA nor AHCI DMA will help you

OK ... do the SATA PCI addon cards suport PIO also ?

I see no arguments against supporting PIO also for non-BIOS disks,
if the hardware supports it. The point was that the UDMA/ADMA support
apparently could be added at very little cost ;-)

 Support means you access them somehow - just adding them to
 int 13 will not give them drive letters, only lowlevel access.

I know ... maybe this problem could be somehow solved later
outside of UIDE ;-)






-- 
~~~ wow ~~~

--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE.SYS

[Jack]

DOS386 wrote:

 I haven't asked for adding block-device to UIDE, just
 non-BIOS disks support, and I don't need it too _badly_
 since I have none by now.

Non-BIOS disk support for caching already exists in UIDE,
in its external entry logic which can be conditionally-
assembled into the driver.   UIDE uses its first 48 cache
unit numbers for diskettes and hard-disks, and the next
8 cache unit numbers for its CD/DVD drives, leaving 200
free cache unit numbers for other devices.Each such
device can call UIDE for read/write access using a 48-bit
logical block number (LBA), same as a system hard-disk.
Each device also provides UIDE with a call-back routine
pointer, which UIDE calls for actual I-O if the requested
data is not in its cache.   As noted before, CD/DVD units
within UIDE actually use this external entry scheme, so
I know it works fine and could serve other devices, too.

Note that UIDE does not do actual I-O, the device's call
back routine does.   At present, UIDE has I-O logic only
for SATA/IDE hard-disks, also SATA/IDE/PIO CD/DVD drives.
Users of a non-BIOS device will have to provide their own
call-back I-O logic for UIDE.   I would consider adding
other internal drivers to UIDE only for major classes
of I-O devices, e.g. USB/Firewire, and only if somebody
can provide me a firm and universally accepted spec for
the devices.   Otherwise, I prefer that an odd non-BIOS
unit provides its own I-O logic and uses UIDE's external
entry scheme, if caching by UIDE is desired.

Also, Eric Auer wrote:

 ... To give block device access to UIDE disks, you only
 need a partition table parser and a driver similar in
 size to a ramdisk.   I would suggest that both is put in
 a driver for UIDE block devices which can be loaded
 separately from UIDE.   Alternatively, UIDE could
 provide ASPI access to the found disks, then already
 existing drivers as ASPIDISK can be used for block
 device access :-).

Unless there is some intent by BIOS vendors to drop the
Int 13h I-O method for disks/diskettes, accessing Int 13h
devices using block I-O methods ought not be necessary.
The Int 13h scheme, especially with its extended 48-bit
block numbers, works perfectly well, and a driver such as
Eric suggests would be surperfluous.

Re: UIDE having ASPI support, I am not-interested.   ASPI
is a SCSI-like interface scheme, HUGE and overblown and
has no business being in drivers intended to be SMALL, as
UIDE is.   SCSI has in effect been run out-of-business in
the PC market by less-expensive IDE devices, so it is not
the best use of my time to add ASPI handling in UIDE now.
USB/Firewire perhaps, SCSI no.


--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE.SYS

[Jack]

Eric Auer wrote:

 as your driver already has built-in caching, UIDE does
 not need to make int 13 device numbers for non-BIOS
 devices ...

I assume you mean its ability to cache devices other than
its own SATA/IDE devices, by using UIDE's external call
routines, and I agree with you.   A non-BIOS device needs
its own I-O logic, which except for USB/Firewire I am not
interested in adding into UIDE, and so I will dismiss the
idea of UIDE making Int 13h device numbers.UIDE was
meant to handle caching for already-existing devices, and
not add its own devices.

 I still think that allowing PIO for harddisk in case
 UDMA fails would be nice, and maybe it could share
 most of the logic with CD/DVD PIO mode.

I have heard of cases where my older drivers through 2006
caused FAILURES, if they tried setting UltraDMA to values
other than what the BIOS set.   That logic was deleted by
me around 2006, and UIDE now takes whatever UltraDMA mode
the BIOS sets for disk/CD/DVD units.

I have NEVER heard proven cases where UDMA fails either
due to a BIOS-made UltraDMA setting, or at run-time which
would give MANY disk I-O errors!   If this occurs, a disk
or mainboard controller likely has died, likely a 3 year
warranty disk, and a user needs to run diagnostics, then
go buy NEW hardware!   Cases where UDMA fails by itself
as you describe are very rare!

During init, note in UIDE.ASM after label I_MSNm: where
it calls I_ValD and validates a disk as being UltraDMA.
If NOT valid, an error message is displayed and the Non-
UDMA disk count is incremented, meaning UIDE then calls
the BIOS to handle I-O for that disk at run-time.   Thus
UIDE is already doing what you ask, since the BIOS likely
will handle such a non-UDMA disk using PIO mode.

 The block device thing is a separate issue -

I also agree.   This is an item that should not be a part
of UIDE, which is an I-O driver for already-existing hard
disks of the Int 13h variety.   Block devices require
different drivers which really should be kept separate.

--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE.SYS

[dos386]

Hi

Thanks

 Such disks would have to be installed into DOS.   The BIOS
 never did handle CD/DVD units directly, thus SHCDX33D always
 installs its units into DOS.   However, the BIOS does handle
 hard-disks, and DOS discovers how many hard-disks the BIOS
 found during system boot.   So, UIDE does not have, nor does
 it usually need, drive-installation code for hard disks.

OK, so it's trivial to add them into INT $13 and make available for
WDE disk editor, IDEcheck, NTSC4DOS and other DOS-independent
tools based on INT $13, but DOS won't see them for a known design
fault of itself ... what IMHO could and should get fixed. Allowing UIDE to add
them into INT $13 (while now no DOS will see them) still would be a good
idea IMHO. BTW, do you support MW-DMA ? I've been pretty happy with
XDMA 3.1 up to now (no SATA, no AHCI), but it doesn't support MW-DMA.












-- 
~~~ wow ~~~

--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE.SYS

[Jack]

 Such disks would have to be installed into DOS ...

 OK, so it's trivial to add them into INT $13 and make
 available for WDE disk editor, IDEcheck, NTSC4DOS and
 other DOS-independent tools based on INT $13, but DOS
 won't see them for a known design fault of itself ...
 what IMHO could and should get fixed.   Allowing UIDE
 to add them into INT $13 (while now no DOS will see them)
 still would be a good idea IMHO.

I doubt other applications would be able to use devices that
the main DOS system does not know about.   IMHO, better to
leave the BIOS design as-is, as too many people mess it up
already, and I do not want to be part of that sad list!

 BTW, do you support MW-DMA?

No, UIDE does not support it.   I never saw hard specs for
multi-word DMA, similar to the 1994 Intel specs for UltraDMA
that ARE relatively hard and followed by most chip makers.
Multi-word DMA never achieved the speed of UltraDMA, anyway.
The standard of the industry for disk/CD/DVD drives, since
about 1997, has been UltraDMA.   UIDE permits PIO mode for
CD/DVD drives, as audio and other CD/DVD commands MUST use
PIO mode.   No such requirement for hard-disks, and as few
old PIO/MWDMA disks remain in service, not the best use of
my time to add such code in UIDE.   Japheth's XDMA32 has it,
if you really need it.

--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE.SYS

[Eric Auer]

Hi Dos386,

 Such disks would have to be installed into DOS.   The BIOS
 never did handle CD/DVD units directly, thus SHCDX33D always
 installs its units into DOS.   However, the BIOS does handle
 hard-disks, and DOS discovers how many hard-disks the BIOS
 found during system boot.   So, UIDE does not have, nor does
 it usually need, drive-installation code for hard disks.

 OK, so it's trivial to add them into INT $13 and make available for
 WDE disk editor, IDEcheck, NTSC4DOS and other DOS-independent
 tools based on INT $13, but DOS won't see them for a known design
 fault of itself ... what IMHO could and should get fixed.

You can easily register drives AFTER boot, without giving them
int 13 interfaces, using the well-documented and well-working
DOS block device interface. Disk editors are not very widespread
but NTFS4DOS (NTSC is a television thing) and disk caching might
be a reason why providing int 13 access for extra disks can be
useful in DOS. I agree that having support for slower-than-UDMA
modes, maybe even for PIO, would be useful as fallback to have
at least SOME access to your non-BIOS disks :-).

Eric



--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE.SYS

[Jack]

 You can easily register drives AFTER boot, without giving them
 int 13 interfaces, using the well-documented and well-working
 DOS block device interface.  Disk editors are not very widespread
 but NTFS4DOS (NTSC is a television thing) and disk caching might
 be a reason why providing int 13 access for extra disks can be
 useful in DOS.   I agree that having support for slower-than-UDMA
 modes, maybe even for PIO, would be useful as fallback to have
 at least SOME access to your non-BIOS disks :-).

Adding block-device support would take a LOT more code and isn't
really necessary.   There are two other schemes that can be used
without changing UIDE --

A) Register whatever Int 13h devices are desired into the BIOS
and then load UIDE afterward, maybe using DEVLOAD through the
AUTOEXEC.BAT file.As long as the BIOS knows about disks
when UIDE is loaded, UIDE will get a count of BIOS disks that
includes the added devices and can at-least use its call the
BIOS logic to cache those devices.   UIDE can handle SCSI or
other devices this way -- I have tested it with UIDEJR loaded
previously, then UIDE loaded with its /N1 switch, and it DOES
call the BIOS and uses UIDEJR for hard-disks.   Works fine.

B) Re-assemble UIDE with its external call logic, which I took
out because no one used it.   Still present, in UIDE.ASM, and
any external block devices present on a system CAN call the
driver for caching.   As can be noted, if the external call
logic is present in UIDE, its CD/DVD drives USE that logic to
do data input as it saves some code v.s. a totally internal
call.   Works fine, as well.

My intent is still to keep UIDE and UIDEJR small.UIDEJR is
now within 30 bytes of exceeding 4608 bytes packed by UPX, and
I want to avoid unneeded extras.Lucho's next boot diskette
update may be difficult as he noted to me, since many programs
on that diskette keep growing, and he may need UIDEJR.   AHCI,
when needed, I will add -- other items like block devices, since
UIDE already has ways to handle them, are not absolutely needed.

--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE.SYS

[Jack]

DOS386 wrote:

 Thanks for the explanation ... UIDE won't see the PCI addon
 card since it uses BIOS INT $13 to search for disks ... but
 does anything prevent UIDE from searching for IDE/ATA/SATA
 stuff using PCI BIOS, and assigning it to a free INT $13
 disk number specified in commandline if some special switch
 is used ?

Such disks would have to be installed into DOS.   The BIOS
never did handle CD/DVD units directly, thus SHCDX33D always
installs its units into DOS.   However, the BIOS does handle
hard-disks, and DOS discovers how many hard-disks the BIOS
found during system boot.   So, UIDE does not have, nor does
it usually need, drive-installation code for hard disks.

UIDE could have logic permitting a user-specified controller
(i.e. an add on card) and could install disks/CDs/DVDs for
that controller.   But few people have add on cards, it is
not the best use of my time.   It also increases the size of
UIDE/UIDEJR.   UIDEJR is about 30 bytes from going over 4608
bytes packed via UPX (9 sectors on a boot diskette).   I
will add AHCI logic when needed, but I must be guarded re:
other driver additions!

--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE.SYS

[dos386]

Jack wrote:

 Regrettably, add on cards are also NOT not a part of the main-
 board BIOS, and so their I-O addresses are unknown to PCI BIOS
 or EDD BIOS calls.   Thus, UIDE's initialization displays will
 show no data for your add on disks as it cannot see them via
 the standard BIOS calls it makes.

Thanks for the explanation ... UIDE won't see the PCI addon card since it
uses BIOS INT $13 to search for disks ... but anything prevents UIDE
from searching for IDE/ATA/SATA stuff using PCI BIOS and assigning it
to a free
INT $13 disk number specified in commandline if some special switch is used ?

I don't need it badly (I have no such card now) ... just asking
since someone opened this topic ;-)






-- 
~~~ wow ~~~

--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] UIDE.SYS

[J C]

Dumb question:  Is UIDE.SYS  _only_  for native  [[motherboard]]  controllers?  
I tried it with two PCI adapter card controllers -- one IDE controller and one 
SATA controller and UIDE.SYS did not find drives connected to either of the 
cards.





  --
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] UIDE.SYS

[Jack]

 Dumb question:  Is UIDE.SYS  _only_  for native  [motherboard]
 controllers?  I tried it with two PCI adapter card controllers
 -- one IDE controller and one SATA controller and UIDE.SYS did
 not find drives connected to either of the cards.

NOT a dumb question, but one whose answer is complex!

UIDE detects SATA and IDE drives by using PCI BIOS calls to find
controller I-O addresses, and by using EDD BIOS calls later to
match I-O addresses assigned to a disk with the controller I-O
addresses.   Only the BIOS can make such I-O address assignments
and so UIDE must use them.

For CD/DVD units, UIDE does its own check of primary/secondary
and master/slave drives on each controller found earlier.CD/
DVD units are not assigned I-O addresses -- they are not handled
by the BIOS but by SHCDX33D or a similar CD Redirector driver.
So, UIDE must look for CD/DVD drives by itself.

Regrettably, add on cards are also NOT not a part of the main-
board BIOS, and so their I-O addresses are unknown to PCI BIOS
or EDD BIOS calls.   Thus, UIDE's initialization displays will
show no data for your add on disks as it cannot see them via
the standard BIOS calls it makes.

But, many add on cards WILL install hard-disks as extra BIOS
I-O units.   If so, UIDE displays Disks run by the BIOS: n and
will call the BIOS when a read/write for such disks is issued.
On return from the BIOS call, which is trapped and executed by
run-time logic on your add on card, UIDE will then cache data
for such calls.   Assuming the add on card has good read/write
code in its BIOS chip, this scheme uses little time and achieves
almost the same caching performance as a mainboard controller.

On your system with add on cards, do note if UIDE declares any
Disks run by the BIOS.   If so, these are likely the disks for
your add on cards, and UIDE should handle them well.   If not,
write me at mezukoylian at sprynet dot com, and I will cook-up
some other scheme.

Jack R. Ellis


--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user