• Please review our updated Terms and Rules here

8-Bit IDE Controller

Hi! Good news! I finished assembly of the XT-IDE prototype. Installed the ICs, found a cable and a couple of IDE hard drives for testing. Thursday I start the point to point wring out to verify all the connections and then onto live testing. The prototype is too wide to fit in a single slot so it either uses a couple of slots or has to be on an ISA bus extender. Hopefully my 8 bit ISA bus extender will be here soon.

The point to point wring out usually takes a lot less time than the assembly. Building the prototype turned out to be more complex and time consuming than I originally estimated. It is more complex than it looks, that is for sure.

One thing we are finding on the N8VEM project with the Disk IO board is that the IDE "standard" is not very standardized. There are many variations of drives and controllers and not all IDE devices are interchangeable. Some work, some don't, and its not clear why.

One thing is for sure though, I suspect this project is in for the same rude surprise when we finally move to integration and software testing. Be prepared for some ugly IDE compatibility issues to surface. I'll bet that only a subset of IDE devices are going to work with the device, at least at first. So we'll see how this turns out. I am very glad we are prototyping this before investing in a manufactured PCB.

Thanks and have a nice day!

Andrew Lynch

Wouldn't the best option of compatibility for 8bit IDE be the ability to use CF cards?
 
Are you kidding? IDE/CF compatibility is even shakier than with plain-Jane IDE devices. Now you're adding another layer of complexity with having to insert an IDE<==>CF adapter into the equation.

--T

The only problem I've run into with IDE<>CF with the acculogic 1/16
was:

It wouldn't boot from the thing, it will work if I boot from a floppy
then go to c:/ and see my 512megs, but won't boot directly.

:)
 
>The only problem I've run into with IDE<>CF with the acculogic 1/16 was:

>:It wouldn't boot from the thing, it will work if I boot from a floppy
>then go to c:/ and see my 512megs, but won't boot directly.

Is that a common problem with all sIDE 8bit controllers? I just ordered one and was hoping to be able to boot from it.
 
Hi! Yesterday was good in that my 8 bit ISA bus extender arrived so that is taken care of for more testing. Tonight I plan on finishing or doing a big chunk of the point to point testing. Once it is done, I can put the new prototype in the test machine for live testing.

BTW, Hargle, what IO port and ROM addresses did you want? I can verify whether the IO ports and/or ROM work without any special software but we are going to be ready for software testing soon.

The good news on the related but different N8VEM DiskIO testing is that several builders have their Disk IO boards done and are testing the IDE section. So far there are about a dozen IDE devices known to work with it which are a mix of IDE hard drives and CF devices. That is pretty good for a completely stock system using the first revision of the CBIOS. The only problems really so far are that I included some resistors in the design which should be optional and that WD & later Quantum hard drives are not showing up on the interface for some reason.

The resistors are an easy fix by just not installing them and I suspect the problem with the WD & Quantum drives is probably a missing pull up/pull down resistor some place or maybe an initialization sequence problem. This is relevant to this project because I suspect we'll be going through a similar process here as well.

How can you help? Gather as many old and new IDE hard drives and/or IDE CF devices as you can and once the PCBs are available participate in the testing and fixing cycle. We are keeping a page on the Disk IO working devices here

Thanks and have a nice day!

Andrew Lynch
 
How can you help? Gather as many old and new IDE hard drives and/or IDE CF devices as you can and once the PCBs are available participate in the testing and fixing cycle. We are keeping a page on the Disk IO working devices here

Thanks and have a nice day!

Andrew Lynch

I got about 10 of them... Mostly in the 2GB range, but some up to 40GB.

Maybe if you use a socket for the resistors, and include both a jumper pack and a resistor pack. Then the user can choose to have resistors installed or not.
 
I got about 10 of them... Mostly in the 2GB range, but some up to 40GB.

Maybe if you use a socket for the resistors, and include both a jumper pack and a resistor pack. Then the user can choose to have resistors installed or not.

Hi! Thanks! Yes, I think we can apply the lessons learned on the N8VEM Disk IO project here and vice versa. Regarding the pull up/pull down resistors on the Disk IO, its not the pull up resistors in the packs for the 74LS688's that are the problem. Those should be just fine. The issue is the funky non-standard IDE pull up/pull down resistors. There are several variations of hobbyist IDE interfaces and all sorts of combinations of what pins are connected and how. Tilmann Reh has one scheme in GIDE, Phil Ruston at Retroleum another, Hans Summers yet a different one, etc. Some leave pins unconnected, others are grounded, yet others pulled high. The variations are also too numerous to count.

The Disk IO board is based on the Hans Summers IDE interface which included pull down resistors on the /DMACK and DMARQ pins. It also has a pull up resistor on CSEL. Apparently during my build of the original Disk IO prototype, I managed to get my IDE hard drive working but had to remove those resistors (R1, R2, and R3) in the process. When I went to the PCB layout and design it was months later and I forgot to remove those resistors so they carried over. The PCB fix is easy enough, just don't install them. However the issue remains as to *what* the IDE interface is *supposed* to be. It seems completely arbitrary as to what the configuration actually is!

The nice thing about the IDE "standard" is there are so many to choose from! They are all different! Yet most if not all work at least with some IDE hard drives! How do you capture a reliable design for something like that? Adding dozens of jumpers and pull up/pull down resistors for every conceivable combination makes no sense. It complicates the PCB and makes installation and test a nightmare.

Thanks and have a nice day!

Andrew Lynch
 
Hi! Thanks! Yes, I think we can apply the lessons learned on the N8VEM Disk IO project here and vice versa. Regarding the pull up/pull down resistors on the Disk IO, its not the pull up resistors in the packs for the 74LS688's that are the problem. Those should be just fine. The issue is the funky non-standard IDE pull up/pull down resistors. There are several variations of hobbyist IDE interfaces and all sorts of combinations of what pins are connected and how. Tilmann Reh has one scheme in GIDE, Phil Ruston at Retroleum another, Hans Summers yet a different one, etc. Some leave pins unconnected, others are grounded, yet others pulled high. The variations are also too numerous to count.

The Disk IO board is based on the Hans Summers IDE interface which included pull down resistors on the /DMACK and DMARQ pins. It also has a pull up resistor on CSEL. Apparently during my build of the original Disk IO prototype, I managed to get my IDE hard drive working but had to remove those resistors (R1, R2, and R3) in the process. When I went to the PCB layout and design it was months later and I forgot to remove those resistors so they carried over. The PCB fix is easy enough, just don't install them. However the issue remains as to *what* the IDE interface is *supposed* to be. It seems completely arbitrary as to what the configuration actually is!

The nice thing about the IDE "standard" is there are so many to choose from! They are all different! Yet most if not all work at least with some IDE hard drives! How do you capture a reliable design for something like that? Adding dozens of jumpers and pull up/pull down resistors for every conceivable combination makes no sense. It complicates the PCB and makes installation and test a nightmare.

Thanks and have a nice day!

Andrew Lynch

Who invented IDE anyways? It would be interesting to see how it should be in the first place.

How is the testing going to take place, will you relay on the N8VEM results, or will you make PCB's of the card and send around to testers?

One last question, will the card support 2 drives on the cable (jumpered to Master and Slave, not CableSelect)?
 
Who invented IDE anyways? It would be interesting to see how it should be in the first place.

How is the testing going to take place, will you relay on the N8VEM results, or will you make PCB's of the card and send around to testers?

One last question, will the card support 2 drives on the cable (jumpered to Master and Slave, not CableSelect)?

Hi! I believe Compaq "invented" the first IDE like drives as a cost savings measure in the mid to late 1980's. They combined a WD1002 MFM controller onto someone's HD assembly to save a bus slot and PCB in their units. Of course the first several generations of proto-IDE drives were highly proprietary and there are lots of variations. The ATA-1 standard didn't come about until the early to mid 1990's. Its more of an evolution of a device rather than an explicit design.

Since I am on both projects I am cross feeding relevant information on both projects back and forth. The N8VEM project is my primary concern, of course, but it can and has helped Hargle's 8 bit ISA IDE controller too. There are definitely a lot of similarity.

Regarding CSEL, most likely the board is going down the Master/Slave drive approach. Common IDE cables and drives support the Master/Slave jumpers and there is not much point in requiring special cable configurations for CSEL. However, there is nothing in the design which would prevent it. As long as the pull up resistor is available on CSEL the drives and/or cables can do whatever they like with it.

There is one thing the members here could do to help to me on both of these projects... If anyone knows or has any WD and/or recent Quantum IDE drives on a home made IDE controller please post the IDE pin out. If the WD/Quantum drives have special initialization codes or sequences I'd like that too. We are doing the experimenting to determine why the WD drives are misbehaving on the Disk IO board and I suspect it is related to either the IDE pull up/pull down resistors or there is something software related like the latches are in the wrong state (HIGH, LOW, or tristate) and its confusing them.

Thanks and have a nice day!

Andrew Lynch
 
Ide to cf

Ide to cf

>The only problem I've run into with IDE<>CF with the acculogic 1/16 was:

>:It wouldn't boot from the thing, it will work if I boot from a floppy
>then go to c:/ and see my 512megs, but won't boot directly.

Is that a common problem with all sIDE 8bit controllers? I just ordered one and was hoping to be able to boot from it.

One thing to keep in mind, the CF CARD I tried maybe the problem, not the controller card itself, its a 2 gig high speed version, I haven't tried an older version of a CF Card.

If you can try a 128 meg CF and even better a 512 meg CF, they might work, they are harder to come by these days, which is why I haven't tried one of them out yet..

This is the only CF Card tried with my sIDE:

http://store.lexar.com/?category=21&subcategory=1&productid=CF2GB-80-708

Any luck its the CF card not the sIDE...
 
My guess here about the CF card is the geometry it is reporting to the sIDE. It is probably causing an overflow somewhere and not allowing for boot. I have several 8 bit IDE cards and most do something odd with any drive 2GB or over. Some have problems with drives over 540MB.

That being said, I have a large stock of smaller drives.
 
Last edited:
Hi! I finished the point to point wring out and configuration check on the XT-IDE prototype. It seems to be in good shape so I put it in the test station PC. It seems to check out. The ROM appears at D000:0 as expected. When I place an IDE hard drive on the connector, the IO ports appear at 300 as expected. They are returning seemingly normal values.

The next step is some test software. Please let me know when you are ready to proceed. The prototype is sitting ready with an IDE drive in the test station. I suggest a plain MSDOS application to exercise the ROM and IO ports first. Then make a program to command the disk to IDENTIFY. If we can get those working we should be in good shape.

Thanks and have a nice day!

Andrew Lynch

PS, updated files on the wiki. This is the reference software and would be a good place to start. Preferrably with a tiny C environment for building tools. The smaller the better since then I can use the test station for local modification and debugging.

http://mylinuxisp.com/~jdbaker/oldsite/sourcecode/xtide.c

Tiny C Compiler (TCC) looks like it'd be just about perfect. Would someone please give this a try and let me know if this works in a plain MS-DOS environment? What would be ideal, I think, is the whole thing fitting on a single 1.44MB floppy disk for easy backup.
 
Last edited:
amazing!

here's a piece of software to play with:
http://www.waste.org/~winkles/ATA.ZIP

However, this software:
1) will not work on an 8088 machine
2) will need to be modified to read the 2nd half of the data from IOBASE+8.
3) requires a mouse

I can hopefully fix #2 over the weekend, #1 might take a bit longer. Not sure if #3 can be fixed without totally gutting the interface.

To use it, you'll need to boot up to a DOS disk, load a mouse driver and simply run ATA.
Since our device is dipswitched to IO address 300 for the base, click on the "controller base address" field and change it to 300 there, or better yet, launch the program with "ata -p300".

You should then be able to click on the "command" field, type in EC (Identify device ATA command) and click the read button. If the drive is responding correctly, the program should fill the screen with 256 words of data.

I'd assume since only 1/2 of the data is showing up at the data port at 300h, that you'll see 1/2 of the data and FFs mixed in, or maybe 00's? I've no idea what will happen!

Anyway, the list of registers (data, features, sector count...) is a 1:1 display of the IO ports starting at BASE, BASE+1, BASE+2 etc. So that could help you see if all 8 ports are being decoded.


You might want to get used to the program on a real HDD controller first, just so you know what to expect. It'll default to a base address of 1f0, which is where a normal hdd controller should be sitting. You should also use a fairly modern drive (1995 or later) just to make sure we're all LBA compatible.

You can do PIO reads and writes to a drive as well by issuing command 20h, set the LBA to whatever you want to read, and make sure at least BIT6 in the device register is set (for LBA access). PIO write is command 30h, and will write whatever data is currently in the buffer (ie, whatever you just read off the drive, or random data if you just started the program)

apologies that real life has demanded my attention lately, or I'd be a lot more prepared for this.
 
Hi Hargle! Thanks! Is the source code available for the ATA program? I think it might work with the XT-IDE controller as is but would give 256 double values for the sector rather than 512 unique values due to the high low split.

I have no doubt you are busy as it is something I have issues with as well. There is only so much time to work on these things and I can well understand that. However, this is an open project so it can be more than just you and me working on it. For example, if someone else could help with the compilation of the XTIDE.C program using TCC and write down the steps, I can better use the time I do have to actually test the hardware rather than wrestle with the development environment. I can do both but it just takes time.

When I was writing Catweasel software I used DJGPP which was fine but it is rather bulky and my only real interface to the PIII test station is via the floppy drive. To be useful as a test machine it does not load drivers and only a bare minimum MSDOS so getting things in and out of it can be a real PITA especially for large files.

Thanks and have a nice day!

Andrew Lynch
 
that program is written in x86 assembly, and I'm not sure how releasable the source would be. It was written at and for work, so it's not really as open as I'd like it to be. I consider that program to be pretty throwaway, since it's not really designed for what we're trying to do, but I can ply it to be useful for us for the time being.

I suspect that I can fix the 2nd data port before anyone else would be able to muddle through the source and figure out where all the things would need to be changed anyway. ;) I should be able to hit that this sunday.

It's my birthday tomorrow, so despite my own wishes, I have people who want to steal my time. :( heh.

At least you'll be able to see that data is coming back, and it should be easy to look at every other byte and know that we can at least communicate.

What I really want to do is develop a full card exerciser, which I'd then use for debugging and testing the built PCBs. since I have't written anything like that yet, we've gotta use what we have at hand. It won't be written in C though, as x86 is my native language.
 
Hi Hargle! Thanks! Happy Birthday BTW! Have a beer and think of all your friends here!

Tonight I will give the TCC a try and see if I can get the xtide.c program to compile. TCC needs MinGW which I hope means it can still work in plain MS-DOS. I prefer C as well although if that's not an option assembler is OK.

What I'd really like is the ability to modify the test software on my test station PC so its a nice short loop not involving multiple machines. We'll see if that is possible or not.

So things are going OK. I am fairly confident that the board is working since I checked all the IDE registers and got reasonable values. It is most likely working fine but we need to verify its right before making any assumptions that are going to screw up the software development.

If you really need some time, we can put this on the back burner for a while as I need to do some Disk IO testing. There is some issue with the IDE not recognizing the WD/Quantum drives. The XT-IDE design recognizes them just fine so I am suspecting the difference is in the pull up/pull down resistors.

Thanks and have a nice day!

Andrew Lynch
 
Hi! I tried the TCC to compile the xtide.c and it almost worked but is missing the BIOS.H header. I tried replacing it with the one from DJGPP and that did not work either. Compiling with DJGPP on a different machine produces a whole page of errors and I really did not want to delve into that tonight.

I also tried the ATA program and the machine has a mouse on it but must be missing the device driver or something since I could not access anything the mouse was unresponsive. Are there keyboard commands? It did not seem to respond to anything I could think of.

There is much going on right now so I am going to just put this on hold pending some test software.

Thanks and have a nice day!

Andrew Lynch
 
amazing!

here's a piece of software to play with:
http://www.waste.org/~winkles/ATA.ZIP

However, this software:
1) will not work on an 8088 machine
2) will need to be modified to read the 2nd half of the data from IOBASE+8.
3) requires a mouse

I can hopefully fix #2 over the weekend, #1 might take a bit longer. Not sure if #3 can be fixed without totally gutting the interface.

To use it, you'll need to boot up to a DOS disk, load a mouse driver and simply run ATA.
Since our device is dipswitched to IO address 300 for the base, click on the "controller base address" field and change it to 300 there, or better yet, launch the program with "ata -p300".

You should then be able to click on the "command" field, type in EC (Identify device ATA command) and click the read button. If the drive is responding correctly, the program should fill the screen with 256 words of data.

I'd assume since only 1/2 of the data is showing up at the data port at 300h, that you'll see 1/2 of the data and FFs mixed in, or maybe 00's? I've no idea what will happen!

Anyway, the list of registers (data, features, sector count...) is a 1:1 display of the IO ports starting at BASE, BASE+1, BASE+2 etc. So that could help you see if all 8 ports are being decoded.


You might want to get used to the program on a real HDD controller first, just so you know what to expect. It'll default to a base address of 1f0, which is where a normal hdd controller should be sitting. You should also use a fairly modern drive (1995 or later) just to make sure we're all LBA compatible.

You can do PIO reads and writes to a drive as well by issuing command 20h, set the LBA to whatever you want to read, and make sure at least BIT6 in the device register is set (for LBA access). PIO write is command 30h, and will write whatever data is currently in the buffer (ie, whatever you just read off the drive, or random data if you just started the program)

apologies that real life has demanded my attention lately, or I'd be a lot more prepared for this.

Hi Hargle! Good news! I finally got past the mouse issue and got the ATA program running on my test station. When I tell it to do the IDENTIFY command and then READ it does appear to be replying correctly.

I get a sector back but only the lower byte of the words have data. The high byte in the word is $00 so I am getting every other byte as you'd expect. Probably the modifications to ATA to fix that would be pretty easy since instead of reading a word now you read a low byte port and then a high byte port.

Its good news and thought I'd share it.

Thanks and have a nice day!

Andrew Lynch

PS that's with a WD hard drive which are giving us grief over on N8VEM for the Disk IO board. For some reason yet unknown the WD and recent Quantum hard drives are not responding correctly. Probably there is some issue like timing or something in the Disk IO. However, Disk IO does work with enough IDE drives that at least its useful. I believe we'll eventually find out the root cause for the incompatibility with the WD and Quantum drives. Depending on the fix it may be worth it to support them but I guess we'll see.
 
Hi Hargle! Good news! I finally got past the mouse issue and got the ATA program running on my test station. When I tell it to do the IDENTIFY command and then READ it does appear to be replying correctly.

I get a sector back but only the lower byte of the words have data. The high byte in the word is $00 so I am getting every other byte as you'd expect. Probably the modifications to ATA to fix that would be pretty easy since instead of reading a word now you read a low byte port and then a high byte port.

Its good news and thought I'd share it.

Thanks and have a nice day!

Andrew Lynch

PS that's with a WD hard drive which are giving us grief over on N8VEM for the Disk IO board. For some reason yet unknown the WD and recent Quantum hard drives are not responding correctly. Probably there is some issue like timing or something in the Disk IO. However, Disk IO does work with enough IDE drives that at least its useful. I believe we'll eventually find out the root cause for the incompatibility with the WD and Quantum drives. Depending on the fix it may be worth it to support them but I guess we'll see.

That's fantastic!

Do you got an price estimation? as of I know, most of the reqired parts are in place, so I guess the part list is somewhat the same on the final product.


I got an 16-bit ISA IDE controller. It got some resistors to GND and VCC. Although I haven't tested it with a WD or Quantum drive, do you want me to list them?
 
That's fantastic!

Do you got an price estimation? as of I know, most of the reqired parts are in place, so I guess the part list is somewhat the same on the final product.


I got an 16-bit ISA IDE controller. It got some resistors to GND and VCC. Although I haven't tested it with a WD or Quantum drive, do you want me to list them?

Hi! Thanks and I appreciate your enthusiaism but we are a L O N G way from selling these boards. Hargle and I are working on it as best we can but as relatively normal people our availability and capacity for hobbies varies with all sorts of things.

If you'd like to speed the project along, there are plenty of things that still need to be done. A good starting place is some test software. All we really need is the XTIDE.C program compiled and send me a binary to test with.

Since the problems with the XTIDE.C program appear to be related to the interrupt service routines, those could even be stripped out for a reduced but still useful test program.

Alternatively, you could use the design information in XTIDE.C to write a completely new program. The primary things it needs to do is read and write the IDE registers ($300-$30F) and allow a tester to inspect and change those values. It also needs to be able to read and write a sector and display the results, preferrably with some ASCII display.

Try the ATA program Hargle posted earlier with a normal PC IDE controller and you'll see the basic functionality we need. If you are going to write from scratch though please pick a lightweight and MSDOS friendly environment like TCC or even BASIC so it can be modified on the test station without a lot of development environment overhead. For example anything requiring Windows or a Linux GUI is a bad choice. Something that runs on MSDOS and fits on a floppy disk would be great with the program and the compiler/assembler/interpreter, etc.

Thanks and have a nice day!

Andrew Lynch
 
Back
Top