From: Ercan Ersoy
--===8993504009879490629==
Content-Language: tr-TR
Content-Type: multipart/alternative;
boundary="_000_AM2PR09MB05292BD4EC3FF31E9C3C2452D5F60AM2PR09MB0529eurp_"
--_000_AM2PR09MB05292BD4EC3FF31E9C3C2452D5F60AM2PR09MB0529eurp_
Content-Type: text/plain; charset
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/p
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
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 understa
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
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 suppo
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 loa
>> 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, aft
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? Wou
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
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
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
Hi Jack, Dos386,
as your driver already has built-in caching, UIDE does
not need to "make" int 13 device numbers for non-BIOS
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.
The block devic
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 drive
> 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 a
>>> 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 i
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
> 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 u
> 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
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.
>> 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 cou
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, U
"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 commandl
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 BIO
> 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 "com
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.
--
26 matches
Mail list logo
