DOS ain't dead

Jack,
what is the possibility for, or status on adding AHCI support to the UIDE driver? Is it technically feasible?

I enable AHCI on all machines i reimage, and often run DOS diagnostics on the same machines. AHCI support would of course mean that i don't need to switch controller modes for DOS/UIDE and then remember to switch back again for Windows.

Maybe for you would be enough some code which switchs the controler from AHCI into IDE mode. Such code even in not necessery to be as a part of UIDE.

AHCI support would be however good as for example my HP Pavilon notebook does not have the AHCI/IDE setting in BIOS so I can't change it.
(so my advice is: don't buy notebooks from HP, it is a piece of shit, which doesn't let you to change operating system - even the instalation of Windows XP is virtualy impossible.)

---
DOS-u-akbar!

> Maybe for you would be enough some code which switchs the controler from
> AHCI into IDE mode. Such code even in not necessery to be as a part of
> UIDE.
>
> AHCI support would be however good as for example my HP Pavilon notebook
> does not have the AHCI/IDE setting in BIOS so I can't change it.
> (so my advice is: don't buy notebooks from HP, it is a piece of shit,
> which doesn't let you to change operating system - even the instalation of
> Windows XP is virtualy impossible.)

With suitable drivers, you can integrate driver to your Windows 2000/XP disk and install without changing AHCI/IDE settings.

BTW even in AHCI mode there still should be BIOS INT13h support (on my gigabyte it is) so DOS will run OK except low-level HDD utils acessing directly IDE I/O ports.

---
DOS gives me freedom to unlimited HW access.

> Jack,
> what is the possibility for, or status on adding AHCI support to the UIDE
> driver? Is it technically feasible? I enable AHCI on all machines I
> reimage, and often run DOS diagnostics on the same machines. AHCI
> support would of course mean that I don't need to switch controller modes
> for DOS/UIDE and then remember to switch back again for Windows.

Of course I could add AHCI to UIDE -- if I wanted to buy a new system, with
an AHCI mainboard. But in fact I do NOT! NOBODY yet has noted that AHCI
gains ANYTHING in speed/performance and likely IT NEVER WILL, as that would
require something called a "driver" to be written by "Gates & Co."!! Does
the expression "Good LUCK, Sucker!!" mean anything to you??!!

AHCI's "selling point" is being able to "chain" disk commands and demand no
software handling in-between disk transfers. That is for an "asynchronous
I-O" system like Windows/Unix, NOT for DOS which does one at a time I-O and
CANNOT indicate which of MULTIPLE transfers are COMPLETED, on an interrupt!
So, DOS cannot use "actual" AHCI, and I see NO reason to write 500 bytes of
AHCI run-time logic, plus up to 1000 more of AHCI initialization, into UIDE
only to avoid "switching modes" on DOS/Windows systems. A rather POOR use
of my time!

I suggest you simply keep your DOS/Windows systems in "compatibility" or in
"legacy IDE" mode, whatever the BIOS guys call it "today"! And I will bet
you lose LITTLE speed/performance, not before "Gates & Co." at-LAST "figger
out" a disk driver WORTH enabling AHCI!! To my knowledge, they still have
NO decent disk driver for SATA/IDE -- Lucho noted to me in 2008, re: UIDE's
performance v.s. Windows "You beat THEM, three MONTHS ago!!" -- and I would
NOT "hold your breath!!" for a decent Windows AHCI driver, either!!

---
(Account disabled on user's request.)

> I suggest you simply keep your DOS/Windows systems in "compatibility" or
> in
> "legacy IDE" mode, whatever the BIOS guys call it "today"!

Of course but on some new HW you simply have no choice (e.g. many notebooks or my Dell Optiplex 320 workstation at work).

---
DOS gives me freedom to unlimited HW access.

> > Jack,
> > what is the possibility for, or status on adding AHCI support to the
> UIDE
> > driver? Is it technically feasible? I enable AHCI on all machines I
> > reimage, and often run DOS diagnostics on the same machines. AHCI
> > support would of course mean that I don't need to switch controller
> modes
> > for DOS/UIDE and then remember to switch back again for Windows.
>
> Of course I could add AHCI to UIDE -- if I wanted to buy a new system,
> with
> an AHCI mainboard. But in fact I do NOT! NOBODY yet has noted that
> AHCI
> gains ANYTHING in speed/performance and likely IT NEVER WILL, as that
> would
> require something called a "driver" to be written by "Gates & Co."!!
> Does
> the expression "Good LUCK, Sucker!!" mean anything to you??!!
>
> AHCI's "selling point" is being able to "chain" disk commands and demand
> no
> software handling in-between disk transfers. That is for an
> "asynchronous
> I-O" system like Windows/Unix, NOT for DOS which does one at a time I-O
> and
> CANNOT indicate which of MULTIPLE transfers are COMPLETED, on an
> interrupt!
> So, DOS cannot use "actual" AHCI, and I see NO reason to write 500 bytes
> of
> AHCI run-time logic, plus up to 1000 more of AHCI initialization, into
> UIDE
> only to avoid "switching modes" on DOS/Windows systems. A rather POOR
> use
> of my time!
>
> I suggest you simply keep your DOS/Windows systems in "compatibility" or
> in
> "legacy IDE" mode, whatever the BIOS guys call it "today"! And I will
> bet
> you lose LITTLE speed/performance, not before "Gates & Co." at-LAST
> "figger
> out" a disk driver WORTH enabling AHCI!! To my knowledge, they still
> have
> NO decent disk driver for SATA/IDE -- Lucho noted to me in 2008, re:
> UIDE's
> performance v.s. Windows "You beat THEM, three MONTHS ago!!" -- and I
> would
> NOT "hold your breath!!" for a decent Windows AHCI driver, either!!

Jack,
there are web pages that have data that is favourable to AHCI in comparison to IDE mode. See for example:

http://expertester.wordpress.com/2008/07/24/ahci-vs-ide-%E2%80%93-benchmark-advantage/

http://benchmarkreviews.com/index.php?option=com_c...505&Itemid=38&limit=1&limitstart=12

However, regardless of arguments for or against any performance improvements for AHCI over IDE, what interests me more than this is getting DOS/UIDE to run on existing systems where Windows is preinstalled and AHCI mode is active, without first having to disable AHCI mode manually and having to renable it before rebooting into Windows.

In this sense i like the idea of Laaca, who mentioned that for my purposes it would be adequate to be able to disable AHCI when booting DOS within DOS, and then reenable within DOS before reboot. Given that you've said that DOS does not do asynchronous I-O, and therefore that any theoretical benefits of AHCI are lost in DOS anyway, this idea of quietly disabling/renabling AHCI mode sounds like a good compromise.

So simply put i would appreciate if via UIDE or some other mechanism the following functionality be available for DOS systems.

* Boot DOS
* Save AHCI mode status to environment
* Load UIDE and other drivers
During reboot...
* If AHCI==On AHCI /enable
* Reboot

I hope something like this is feasible without much time or effort.

> BTW even in AHCI mode there still should be BIOS INT13h support (on my
> gigabyte it is) so DOS will run OK except low-level HDD utils acessing
> directly IDE I/O ports.

Well i do use HDAT2. Presumably AHCI mode would interfere with this program?

> Jack,
> there are web pages that have data that is favourable to AHCI in
> comparison to IDE mode ...

I looked at those webpages, and they confirm to me that AHCI "wins" only
when it can "chain" (or "queue") a string of AHCI I-O requests. Like I
have noted, such schemes CANNOT work with DOS, which does not permit any
I-O scheme except "ONE at a time"!

> However, regardless of arguments for or against any performance
> improvements for AHCI over IDE, what interests me more than this is
> getting DOS/UIDE to run on existing systems where Windows is preinstalled
> and AHCI mode is active, without first having to disable AHCI mode
> manually and having to renable it before rebooting into Windows ...
> So simply put i would appreciate if via UIDE or some other mechanism the
> following functionality be available for DOS systems.
>
> * Boot DOS
> * Save AHCI mode status to environment
> * Load UIDE and other drivers
> During reboot...
> * If AHCI==On AHCI /enable
> * Reboot

I would rather NOT "play games" with BIOS settings. If a power-failure
occurs, or if the user presses the system-RESET button (on those systems
that still HAVE one!), the system may or may-NOT revert back to enabling
AHCI. BIOS code is not "C" and thus is regarded by Taiwanese mainboard
vendors as work fit only for "trainees", which is why many BIOS programs
"SUCK, BIG-Time!", as we say.

What you ask for ALSO entails "trapping" a system reboot, which is NOT a
universally-supported nor "guaranteed" function. If the DOS system has
suffered an actual POWER-failure and has TOO MUCH such work to do during
a reboot, it may or may-NOT end up DEADDD (no power LEFT!) before it can
GET to such AHCI re-enabling logic. I don't recommend "Uninterruptable
Power Supplies" (UPS boxes) either, as I've owned several in prior years
and know most ARE NOT "uninterruptible" beyond one good "lightning bolt"
or one good housewife turning on a washing-machine (can cause up to 600-
volt "spikes" on home wiring!).

Whether due to power-failure or a reset, users could be ANGRY with me or
UIDE for having played such "games", and as I do not like angry E-Mails,
UIDE shall NEVER "mess with" AHCI nor any other BIOS settings!!

---
(Account disabled on user's request.)

I see your point of view.

Ok then, so what about a seperate executible that the user can call from command line or scripts and "use at own risk"?

Something like this;

AHCI

/status (Displays AHCI mode)
/envar (Saves AHCI status to environment variable)
/enable (AHCI on)
/disable (AHCI off)

> Well i do use HDAT2. Presumably AHCI mode would interfere with this
> program?

Just try it or you can take a look in disassembler if it calls INT13 or access IDE IO ports directly...

---
DOS gives me freedom to unlimited HW access.

> I see your point of view. Ok then, so what about a separate executable
> that the user can call from command line or scripts and "use at his own
> risk"? ...

I have no-problem with this approach, and in fact, I believe it to be the
BEST approach for DOS. It avoids any need to update existing programs!

Such an executable must also be capable of being used while CONFIG.SYS is
being run. This is required so UIDE or other .SYS drivers will find the
desired AHCI settings present, when they load. My "RDISK.COM" driver is
one example of how to do this.

---
(Account disabled on user's request.)

Understood. Thanks for that Jack.

I'm no programmer, so i'm hoping someone will volunteer to do this.

You could probably do something like this with a CMOS settings poker program. I suspect such a program exists already to do similar tasks.

1) go into setup, enable AHCI, boot to DOS, save the contents of CMOS
2) " " disable AHCI " " "
3) compare the results and attempt to isolate the single bit in CMOS that tells the system BIOS if AHCI is enabled or disabled.

Then your enable/disable program would just set or clear that bit in CMOS, update the checksum, and then reboot the machine.

The reason to go this route is that it would be cleaner, without the need to hit any hardware directly, and I'd think that any time you reboot the machine, the BIOS is likely to just use whatever setting is in CMOS anyway, unless you're doing a soft INT 19 type boot.

-----------

That said, I've done a lot of AHCI work and have written DOS based tools to do stuff in AHCI. I would certainly be willing to consult with anyone who wanted to tackle this, but as been mentioned, the fact that you're behind INT 13 means that you're not going to see any speed improvements. It would be purely academic and only for the cool factor.

> the fact that you're
> behind INT 13 means that you're not going to see any speed improvements.
> It would be purely academic and only for the cool factor.
you are mostly right: I wouldn't expect any speed improvements for *disks* either.
unfortunately CD/DVD's are not handled by INT 13, but need it's own driver,
and the current CD/DVD driver(s) don't operate with AHCI

> you are mostly right: I wouldn't expect any speed improvements for *disks*
> either.
> unfortunately CD/DVD's are not handled by INT 13, but need it's own
> driver,
> and the current CD/DVD driver(s) don't operate with AHCI

ooh, ugh, yeah. ok, that's a whole new layer of ugly.
I suppose even with most mainboard's AHCI feature enabled which patches INT 13 to give you HDD support, you're still SOL with CD drives...

So you'd have to have a CDROM driver that can issue ATAPI packet commands down AHCI. I've never done much with packet commands, other than eject and load disc commands, but I think that a lot of the basic stuff I have, like sending FIS packets down to the device would still be applicable. I'm sure it's doable. Had I a 2nd or 3rd lifetime of freetime, I would be all over attempting to do something with that.

> You could probably do something like this with a CMOS settings poker
> program. I suspect such a program exists already to do similar tasks.
>
> 1) go into setup, enable AHCI, boot to DOS, save the contents of CMOS
> 2) " " disable AHCI " " "
> 3) compare the results and attempt to isolate the single bit in CMOS that
> tells the system BIOS if AHCI is enabled or disabled.
>
> Then your enable/disable program would just set or clear that bit in CMOS,
> update the checksum, and then reboot the machine.

I'm looking for a solution that works for any machine. That is, i want to be able to boot my DOS diagnostics disks on any machine, disable AHCI during config.sys processing (as described by Jack in this thread), and reenable just before reboot. What your suggesting would only work for me if i could get the CMOS settings for every model i come across, which is many.

Perhaps the author of HDAT2 will be able to help. I'll contact him and see...

> > the fact that you're
> > behind INT 13 means that you're not going to see any speed improvements.
>
> > It would be purely academic and only for the cool factor.
> you are mostly right: I wouldn't expect any speed improvements for *disks*
> either.
> unfortunately CD/DVD's are not handled by INT 13, but need it's own
> driver,
> and the current CD/DVD driver(s) don't operate with AHCI

As discussed earlier in this thread, speed improvements are of secondary importance. It's a question of convenience - keeping DOS systems compatible with the hardware configuration of existing Windows systems, without requiring manual intervention.

> I'm looking for a solution that works for any machine. That is, i want to
> be able to boot my DOS diagnostics disks on any machine, disable AHCI
> during config.sys processing (as described by Jack in this thread), and
> reenable just before reboot. What your suggesting would only work for me
> if i could get the CMOS settings for every model i come across, which is
> many.

understood.
I'm not so sure that it'll work as easily as you want it to though.

All of the machines I've played with that have AHCI, also have option ROMs in the mainboard BIOS which install INT 13 support so you can use HDDs in DOS, even through AHCI mode. Maybe I'm just getting lucky with the motherboards I play with.

Anyway, if you were to boot to DOS on such a machine with INT 13 supporting AHCI, and then turn AHCI off in config.sys, you're essentially going to break that INT 13 layer, and your HDD won't function anymore. The system may hang waiting for an AHCI command to complete, which never does.

If you can go without using INT 13, you may be ok, however booting to DOS does go out and query the HDD partition tables, even though you may not use the HDDs in your DOS session, so you may have difficult even booting to a floppy disk.



The good news is that I think that if AHCI were enabled in the BIOS, you wouldn't even need to re-enable it before rebooting after your DOS session. That should happen automatically when the system goes through POST again.

> Anyway, if you were to boot to DOS on such a machine with INT 13
> supporting AHCI, and then turn AHCI off in config.sys, you're essentially
> going to break that INT 13 layer, and your HDD won't function anymore.
> The system may hang waiting for an AHCI command to complete, which never
> does.

I think so it can cause problem. INT13h services for AHCI is in different BIOS module than for IDE compatability mode.

---
DOS gives me freedom to unlimited HW access.

> I think so it can cause problem. INT13h services for AHCI is in different
> BIOS module than for IDE compatability mode.

I can verify this on one of my test machines; I'll boot to DOS with AHCI enabled and go into the hardware and turn off the controller. If I'm lucky, the next INT13 will just timeout, if I'm unlucky, it will hang the machine.

> I can verify this on one of my test machines; I'll boot to DOS with AHCI
> enabled and go into the hardware and turn off the controller. If I'm
> lucky, the next INT13 will just timeout, if I'm unlucky, it will hang the
> machine.

sorry about the suspense/delays.

I booted up an intel desktop board with a believe an ICH10 on it. E210882 might be the model number?

Anyway, AHCI mode is on in BIOS, booted to DOS, went to the AHCI memory mapped registers and disabled AHCI by turning bit 31 to 0 in BAR+4.
I then did an INT 13 read from the drive and after 30 seconds or so, it timed out with CY set an a 0x8001 in AX.
This is a good sign, in that it looks like the BIOS is well behaved.
This of course cripples all INT 13 functions that touch the drive.

> I booted up an intel desktop board with a believe an ICH10 on it. E210882
> might be the model number?
>
> Anyway, AHCI mode is on in BIOS, booted to DOS, went to the AHCI memory
> mapped registers and disabled AHCI by turning bit 31 to 0 in BAR+4.
> I then did an INT 13 read from the drive and after 30 seconds or so, it
> timed out with CY set an a 0x8001 in AX.
> This is a good sign, in that it looks like the BIOS is well behaved.
> This of course cripples all INT 13 functions that touch the drive.

Thanks for testing, this is what we expected. I think it would be needed to unload current AHCI BIOS Int13h services and reload standard BIOS for IDE mode - if BIOS still contains it at all...
But if you try to run some low level disk utility from a floppy it should now see the HDD via standard IDE port.

---
DOS gives me freedom to unlimited HW access.

> I would rather NOT "play games" with BIOS settings. If a power-failure
> occurs, or if the user presses the system-RESET button (on those systems
> that still HAVE one!), the system may or may-NOT revert back to enabling
> AHCI. BIOS code is not "C" and thus is regarded by Taiwanese mainboard
> vendors as work fit only for "trainees", which is why many BIOS programs
> "SUCK, BIG-Time!", as we say.
>
> What you ask for ALSO entails "trapping" a system reboot, which is NOT a
> universally-supported nor "guaranteed" function. If the DOS system has
> suffered an actual POWER-failure and has TOO MUCH such work to do during
> a reboot, it may or may-NOT end up DEADDD (no power LEFT!) before it can
> GET to such AHCI re-enabling logic. I don't recommend "Uninterruptable
> Power Supplies" (UPS boxes) either, as I've owned several in prior years
> and know most ARE NOT "uninterruptible" beyond one good "lightning bolt"
> or one good housewife turning on a washing-machine (can cause up to 600-
> volt "spikes" on home wiring!).
>
> Whether due to power-failure or a reset, users could be ANGRY with me or
> UIDE for having played such "games", and as I do not like angry E-Mails,
> UIDE shall NEVER "mess with" AHCI nor any other BIOS settings!!

I agree that playing such games is EXTREMELY silly. IMO best to do the right thing and actually add proper AHCI support!