DOS ain't dead

hi all,

I've got some AHCI based code in my pocket that I'd be happy to contribute somewhere or at least be a technical consultant for working with AHCI projects in the future.

I've got a DOS program (in x86 assembly) which does reads and writes to both Intel and JMicron controllers (others can be added easily) and can detect and display SATA drives attached on any AHCI port.

It uses flat real mode to get access to the AHCI controller, and uses multiple 4mb buffers for the actual transfer buffers. It opens up 32 command slots so you can actually get some pretty impressive transfer speeds with it. (I was just reading a drive at ~80MB/sec)

I was thinking that it would be kind of neat to make a sort of drive clone/ghost software with it, but the guts of it could be used in a lot of places.

I would have to poke around in the code a little bit to clean it up in places, but if anyone seriously wants to play, let me know.

(quoting lexapass, 03 Nov. 2009):

> Hello, Rugxulo.
>
> I think not many people knows about it.
> And I think it will be interesting for you.
> Please follow the link below to find "AHCI Sata Driver for DOS, Release
> 1.1 (c) 2008, Intel Corporation".
> Sounds like a miracle, isn' it?
>
> I found it recently, but unable to test (no hardware). May be you can offer it to some > communities/forums.
http://h20000.www2.hp.com/bizsupport/TechSupport/S...p;swLang=13&taskId=135&mode=4&idx=0

P.S. It's not open source, but it does use FreeDOS!

==================================
Files included in this folder are:

Readme.txt (this file)
files\ahci.sys
files\autoexec.bat
files\config.sys
files\SataDosBoot_MWP.pdf
files\shcdx86.com
freedos\kernel.sys
freedos\freedos_source.zip
freedos\command.com
autoexec.bat
choice.com
copydisk.exe
diskimag.img
hpusbf.exe
mkflpy.cmd
mkusb.cmd

Copyright (c) 2008-2009 Hewlett-Packard Development Company, L.P.

Is this something that Jack R. Ellis could use in his UIDE driver???
Stephen William Foyle

What this HP driver should exactly do? When I enable AHCI mode on my controller for my SATA drive I still can access it under DOS via INT13h extension (it's not emulated on low level as in IDE compatability mode so some low level tools cannot acces it). I think that any driver can't help when application will touch directly IDE IO ports. Or does it intended for PC without INT13h support in AHCI mode? And about performance... I tried to enable AHCI mode under WinXP-SP3 with latest intel drivers but I didn't get any significant speed gain. So I have AHCI disabled for compatability with Win98SE...

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

Hm, according to SataDosBoot_MWP.pdf it seems this is SATA CDROM driver not for HDD. So nothing new. GCDROM.SYS can do the same for years...

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

> I've got some AHCI based code in my pocket that I'd be happy to contribute
> somewhere or at least be a technical consultant for working with AHCI
> projects in the future.

Do you intend to publicly provide that code?

---
Glory to God for all things

> Do you intend to publicly provide that code?

yes, I would intend on open sourcing it, although probably through a "ask and ye shall receive" rather than posting it somewhere for anyone to download, at least for starters. It was one of those things that I wrote for a project at my work, but it is no longer useful there, and it has been sitting idle for almost a year. Somewhat gray area as to true ownership rights, but it's 100% written by me, and I would like to see the work live on.

This code talks directly to the hardware. Since most AHCI controllers do also provide INT13 support through an option ROM, there probably isn't a need to do the same with this code. As I was saying, a tool/utility for doing high speed transfers (HDD cloning) is the first thing that comes to mind for this. I suppose it could be tossed into a driver as well, although I would have to research that to see how it would fit in.

--

AHCI performance in XP isn't good. Vista, server 2008, and 7 are the only O/Ses in the windows families to actually make use of AHCI's abilities. It's a driver stack issue which is outside of my realm of knowledge.

Thanks for explanation. BTW is the driver specific for each controller model (e.g. ICH7, ICH8,...) or it works samo on whole ICHx family? Yes it would be nice for ghost or pqmagic clone. But this sw are not opensource. I think Ghost is very rich of features and also has nice GUI and it will be hard to make such well opensrc program. If ghost would allow to use some external disk driver with documented api it will be much easier...

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

> Thanks for explanation. BTW is the driver specific for each controller
> model (e.g. ICH7, ICH8,...) or it works samo on whole ICHx family?

AHCI is its own standard, so any software written to work on say, the ICH9 AHCI controller should also work on a JMicron AHCI controler, or an ICH10 controller too. Vendors may add their own features to their controllers, and thus want their own driver to take advantage of those features though, and that would be outside of our DOS world without the chipset specifications. The AHCI spec is however available to the public, and that's what I wrote my software against.

Key word there is *should* ;)

> Thanks for explanation. BTW is the driver specific for each controller
> model (e.g. ICH7, ICH8,...) or it works samo on whole ICHx family? Yes it
> would be nice for ghost or pqmagic clone. But this sw are not opensource.
> I think Ghost is very rich of features and also has nice GUI and it will
> be hard to make such well opensrc program. If ghost would allow to use
> some external disk driver with documented api it will be much easier...

Older ICH's like ICH8 don't support AHCI. ICH8R should though, and there have been rumours that the ICH8R drivers can be tweaked to support ICH8, but I haven't seen real confirmation. (the JMicron on the same board did support AHCI and NCQ though (MSI p965 neo-F), would have to look up the exact chipnr)

While messing with an external ESATA bracket, I blew up my ICH8 though, so I'm now at ICH10R

> still can access it under DOS via INT13h extension (it's not emulated
> on low level as in IDE compatability mode

Good

> so some low level tools cannot acces it). I think that any driver can't help
> when application will touch directly IDE IO ports.

Not really surprising nor a problem

> Or does it intended for PC without INT13h support in AHCI mode?

Or for PC's with bad/buggy AHCI support in the BIOS

> So I have AHCI disabled for compatability with Win98SE...

So with AHCI enabled you have INT $13 and AHCI available, but no IDE PIO and no IDE UDMA ? And this 98SSE can'u use INT $13 ?

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> So with AHCI enabled you have INT $13 and AHCI available, but no IDE PIO
> and no IDE UDMA ? And this 98SSE can'u use INT $13 ?

I'm sure the specifics are different for each vendor's implementation of their INT 13 wrapper, but essentially in AHCI mode:

1) there are no longer IO ports to access the drive. (1f0-1f7, 170-177, etc) so the drive does not appear as a standard hard drive anymore.

2) all of the access to the drive is done through DMA through the AHCI controller itself. essentially the "driver" or int 13 interface takes a command, even identify device, which is PIO, and you build a bunch of tables in memory that tell the controller what the command is, where to get/put the data, etc, then you hit the "go" bit, and the controller takes care of the actual drive communication through DMA.

The performance of AHCI comes through a parallel interface in these tables you can build. You can have 32 outstanding requests at the same time, each with their own scatter/gather tables and buffers in memory.
You build the tables of the commands you want to issue, hit that go bit and sit back and wait for your data to be read or written to/from the drive. (I think you can do up to 32mb sized transfers, and have 32 of them at a time.)

3) my assumption would be that when using the INT13 interface, they probably don't open up 32 channels, as that becomes a big memory hog and could require memory access >1mb. My guess is that it's only 1 channel ever being used, and thus with 1 channel going, you'd end up with the exact same performance as issuing commands to a standard SATA port.

Thanks.

> 1) there are no longer IO ports to access the drive. (1f0-1f7, 170-177, etc)

Above are legacy ports, but there are also "native" IDE/SATA ports ...

> so the drive does not appear as a standard hard drive anymore.

So PIO / UDMA code won't find anyting ...

> 2) all of the access to the drive is done through DMA through the AHCI
> controller itself. essentially the "driver" or int 13 interface takes a
> command, even identify device, which is PIO, and you build a bunch of
> tables in memory that tell the controller what the command is, where
> to get/put the data, etc, then you hit the "go" bit, and the controller
> takes care of the actual drive communication through DMA.

> The performance of AHCI comes through a parallel interface in these
> tables you can build. You can have 32 outstanding requests at the
> same time, each with their own scatter/gather tables and buffers in
> memory. You build the tables of the commands you want to issue,
> hit that go bit and sit back and wait for your data to be read or
> written to/from the drive. (I think you can do up to 32mb sized
> transfers, and have 32 of them at a time.)

COOL

> 3) my assumption would be that when using the INT13 interface, they
> probably don't open up 32 channels, as that becomes a big memory
> hog and could require memory access >1mb. My guess is that it's only
> 1 channel ever being used, and thus with 1 channel going, you'd end
> up with the exact same performance as issuing commands to a
> standard SATA port.

What performance do you get using INT $13 (IDECHECK) ?

So since it works well (just not very fastest) in DOS, the need for a
driver is not "that bad" (not as bad as for sound) for now

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> So with AHCI enabled you have INT $13 and AHCI available, but no IDE PIO
> and no IDE UDMA ? And this 98SSE can'u use INT $13 ?

Yes, Win98 booted in INT13h compatability mode but disk operations was extremely slow about 1MB/s. And windows gives you warnig that disk subsys run in 16bit mode. Normally in IDE compatability mode I can reach ~30MB/s copying speed.

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

> While messing with an external ESATA bracket, I blew up my ICH8 though, so
> I'm now at ICH10R

And how fast is your ICH10R compared to ICH8 under DOS? I tested one gigabyte mobo with ICH10 and is was significantly slower than my ICH7. But after loading of udma.sys the performance was near to ICH7 with udma.sys

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

> Yes, Win98 booted in INT13h compatability mode but disk operations was
> extremely slow about 1MB/s. And windows gives you warnig that disk subsys
> run in 16bit mode.

COOL

And INT $13 in AHCI mode with IDECHECK in DOS ?

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> Thanks.
>
> > 1) there are no longer IO ports to access the drive. (1f0-1f7,
> 170-177, etc)
>
> Above are legacy ports, but there are also "native" IDE/SATA ports ...

sure, but all that means is that the decoding done at the old 1f0-1f7 are now relocatable anywhere in IO space and the BIOS/OS is in control of where they go. It's the same stuff, just in a different place. In AHCI that stuff is gone. It's all done via memory mapped access now.


>
> > so the drive does not appear as a standard hard drive anymore.
>
> So PIO / UDMA code won't find anyting ...

correct. You will not find a drive by poking any ATA type command via the typical "shadow register" block (LBA/command/device/features, etc registers) as you would with previous controllers. The registers still exist, but now reside inside a "FIS" which is a chunk of data in a table that the controller DMAs over to the drive. The nicest part is that it's all LBA mode, and it's all 48bit (actually 64 bit!) so finally, we have no size barriers, or at least not any realistic ones. 64bit is what, like 16,000TB or something insane!

>
> What performance do you get using INT $13 (IDECHECK) ?

10182 kB/S which is pretty respectable.

In AHCI mode, using my code, I did a similar test; 128k transfers (which should equate to IDECHECK's 256 sectors per transfer) and I topped out at 73MB/sec. [same drive, same motherboard, same controller]

If I bump it up to a 4MB transfer size, I could get 76MB/sec. As I think I mentioned before, I believe you can do 32MB transfers (* 32 channels) and I can likely get a little bit more performance out of it, probably topping out at about 80MB/S. It's not quite an apples:apples comparison, but it's pretty easy to see the performance gain when AHCI is actually being used.


>
> So since it works well (just not very fastest) in DOS, the need for a
> driver is not "that bad" (not as bad as for sound) for now

I agree completely. It's plenty fast for normal usage, which is why I was thinking that making a clone type program, something that bypasses INT13, would be cool and useful.

> The nicest part is that it's all LBA mode, and it's all
> 48bit (actually 64 bit!) so finally, we have no
> size barriers, or at least not any realistic ones. 64bit is what, like
> 16,000TB or something insane!

LBA64 with 512 Byte's per sector : 8'192 EiB

> > What performance do you get using INT $13 (IDECHECK) ?
> 10182 kB/S which is pretty respectable.

10 MiB (Byte's) per second ? Usable, but not fast at all, some BIOS'es get only 5 MiB/s while DOS DMA driver gets 60 MiB/s with very same hardware

> In AHCI mode, using my code, I did a similar test; 128k transfers (which
> should equate to IDECHECK's 256 sectors per transfer) and I topped out at
> 73MB/sec. [same drive, same motherboard, same controller]

Good, but since I get 60 MiB/s with just IDE (not even SATA) ...

> thinking that making a clone type program, something that bypasses INT13,
> would be cool and useful.

Don't forget to add optional INT $13 support besides native AHCI

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > While messing with an external ESATA bracket, I blew up my ICH8 though,
> so
> > I'm now at ICH10R
>
> And how fast is your ICH10R compared to ICH8 under DOS? I tested one
> gigabyte mobo with ICH10 and is was significantly slower than my ICH7. But
> after loading of udma.sys the performance was near to ICH7 with udma.sys

I don't run dos on that machine. I just replied because I knew a bit more about the ich8 state.

This weekend I tried the AHCI.SYS driver from Hewlett packard with my new notebook HP Pavilon dv6 and it didn't worked
In BIOS I can't set almost nothing so it is very bad.
Now I want to try to modify the BIOS with Phoenix Bios Editor

---
DOS-u-akbar!

> This weekend I tried the AHCI.SYS driver from Hewlett packard with my new
> notebook HP Pavilon dv6 and it didn't worked
> In BIOS I can't set almost nothing so it is very bad.
> Now I want to try to modify the BIOS with Phoenix Bios Editor

Do you know if you have an AHCI compatible controller in your notebook? There may be a very good reason that it didn't work. ;)

Do a PCI device scan, AHCI controllers have PCI registers 9,a,b = 01,06,01

DOSferatu wrote:

...

Welcome back Any progress with the sound and the attachment you tried to send me centuries ago ?

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> Welcome back Any progress with the sound and the attachment you tried
> to send me centuries ago ?

I should ask you the same thing. I sent out a fixed file, but never heard from you, twice. We figured the 1st one got spam filtered, but the 2nd should have made it, but I never knew if it made it, or if the bug was fixed. pop me some email and we'll try again.

> I sent out a fixed file, but never heard from you, twice.

I got only 1 (ONE) mail so far, 2009-12-26:

> I think you have you not been getting any of my emails?
> I believe I fixed this, sent you an updated one, then sent it again
> because I figured the spam filter got it (sent as a link, not an
> attachment) and now here we are again... :)
> this time, just words, to make sure.

and answered less than 12 hours later.

If anyone wants to send me a ZIP, please missname it as ARC, it works, got such an ARC just yesterday

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Hello
I'm interested about your ahci code.
I'm not a programmer and I have trying to enable ahci on some notebook but vendor doesn't provide this option in bios.
I have managed through a pci option rom to rewrite ICH7-M registers to switch controller in ahci mode but then bios can't boot from fixed disk.
But if I boot from usb some linux distro I can see is in ahci mode and can get access to disk.
That explain why I'm intersted about your ahci code.
I hope this will help somehow in my tries to regain access to boot from disk.
Thanks.
I forget to say,I have tested also with AHCCMDT from ata-atapi.com and their software can find and gain access to disk when I use this trick to switch controller to ahci but is only for testing.

> Hello
> I'm interested about your ahci code.
> I'm not a programmer and I have trying to enable ahci on some notebook but
> vendor doesn't provide this option in bios.
> I have managed through a pci option rom to rewrite ICH7-M registers to
> switch controller in ahci mode but then bios can't boot from fixed disk.
> But if I boot from usb some linux distro I can see is in ahci mode and can
> get access to disk.
> That explain why I'm intersted about your ahci code.
> I hope this will help somehow in my tries to regain access to boot from
> disk.
> Thanks.
> I forget to say,I have tested also with AHCCMDT from ata-atapi.com and
> their software can find and gain access to disk when I use this trick to
> switch controller to ahci but is only for testing.

Hmmm.
So my code would have to be converted into a BIOS int-13 extension loaded through your PCI option rom. that would allow you to boot the device, then your OS would load an ahci driver. If you are only using DOS for your OS, no driver would be required. Doable I think, but I doubt performance would be any better. Performance is only better when you can utilize a lot of system memory and have many outstanding IO requests at a time.

I don't have the time to work on it though, and whoever did do this would need the hardware to test it with-this is not something I could write at home and just send to you without many hours of debugging.

I guess I have to ask what/why are you trying to achieve with this setup?

Hello
Yes that's the plan,to boot device then OS will use an ahci driver.
I'm planning to upgrade to ssd disk and in that case working in legacy emulated mode is not a best choice.
I don't request you to work on it,I know is need of hardware to test and time for this.
But early you say "I would intend on open sourcing it" , source code maybe will help me or others to make this pci option rom.
I'm interested mostly about detection part.
Thanks.

> > Do you intend to publicly provide that code?
>
> yes, I would intend on open sourcing it, although probably through a "ask
> and ye shall receive" rather than posting it somewhere for anyone to
> download, at least for starters.

I need this code,maybe will help me somehow to detect and boot from disk.
At this moment soft like ahccmdt,mhdd,victoria,can detect and access internal disk but bios is unable to boot from.
Thanks.

> > Do you intend to publicly provide that code?
>
> yes, I would intend on open sourcing it, although probably through a "ask
> and ye shall receive" rather than posting it somewhere for anyone to
> download, at least for starters.

Could you, please, send me this AHCI code?

Thank you very much.

Hi everyone, sorry for lateness, but I was unaware of this matter at the time.
Not to be too verbose, here lies a complete description of my problem ( https://superuser.com/questions/1726494/force-ich7-m-ahci-mode-works-in-linux-with-grub2-and-setpci-not-in-windows ) and a solution tested in Linux.
Where the above trick works also past an IDE installation because, by embedding the AHCI driver into the initramfs, it is loaded after grub2 after a setpci -s 0:1f.2 90.B=40 and then the SSD boots.
Since I have no option to switch from IDE to AHCI into BIOS, I tried the same trick before starting Windows, but as expected the SSD is not detected at all, because there is no "driver" or anything similar in the process that initializes the system enough.
So I moved my testing under FreeDOS, CWSDPMI, a DJGPP compiled setpci and a self-compiled grub4dos (with AHCI patch), I wrote a batch with a more complex setpci sequence with partial success - at the moment, I'm stuck at "implementing" a port.
I'm sure that into DOSferatu's code lies the "magic" able to mimic a "driver" and fully configure "by hand" the PCI space.

Please, is this code still available?

I'm not aware of a real DOS "driver" out of the box that would works for me, but I know that the code is part of a diagnostic software that at least "sees" my SSD in AHCI ( https://www.hdsentinel.com/hard_disk_sentinel_dos.php ).
I am open to advice and suggestions, my best and thanks for attention

> Hi everyone, sorry for lateness, but I was unaware of this matter at the
> time.

Not very late... only been 13yrs since the previous post to this thread

---
--
http://glennmcc.org/

> Not very late... only been 13yrs since the previous post to this thread

Hi @glennmcc, you're right, but it's been a relatively short time since I've owned this (beautiful pink) netbook, bought NOS, and it's since I equipped it with a spare small SSD that I've understood how much damage Sony has (deliberately?) done to the BIOS.
In comparison, the other netbook I own and use, an ASUS Eee PC 701 4G, ironically has some sort of SSD soldered to mobo, but it has far fewer limitations (LOL)

Hi everyone, meanwhile I'm carrying on my simple experiments.
With a slight improvement, although I still fail.
I remembered, that since Vista, bootmgr can boot from a basic floppy, as long as the PBR comes from Vista or Win7 etc ( http://www.multibooters.co.uk/floppy.html ) so I tried.
If I don't use the setpci trick, bootmgr + BCD copied from my Seven partition to the floppy works as expected (obviously only in IDE to which I am doomed thanks to my damn BIOS).
To also test the Vista boot floppy jointly with the AHCI setpci trick, first I created a Vista half floppy image (720 kb) with only bootmgr + BCD on board and booted the half image, which I copied onto a real full FreeDOS floppy, with the known sequence - CWSDPMI + setpci + grub + menu.lst
The bootmgr in the image starts the boot process, but as expected it doesn't find winload.exe and the rest of the Windows drivers on the SSD, because the SSD has already vanished in the meantime.
I'm running out of ideas, and I have the umpteenth confirmation that I need an "AHCI driver" of some sort.
Finally, I guess I need it before bootmgr, rather than after bootmgr has started.
I am always open to kind advice and suggestions, my best