• Please review our updated Terms and Rules here

8-Bit IDE Controller

my #10 limited edition prototype is on the way, and then i'll help testing when i get it! :mrgreen::mrgreen::mrgreen:

thanks, hargle. i wonder what sort of speed i'd see using it as a web server with a new-ish 40 GB drive.
 
hargle said:
[snip]

Does that mean it actually does boot if you remove those devices?
Click to expand...

Hi! I seem to recall getting it to boot if I left the FDC board in but removed its BIOS ROM so the native motherboard BIOS could manipulate the bare FDC chip. The problem with that approach is then I don't have a boot floppy. I suppose I could switch to a 720K 3.5" rather than 1.4M but that limits connectivity with my main computers. It's kind of a catch 22.

Thanks and have a nice day!

Andrew Lynch
 
Per may have just figured out the lockup problem that you're seeing.

On the PC/XT, port 80 is a DMA page register. There are at least 2 port 80 writes in the ROM that I'd left in for debugging purposes. While it should have no effect on our usage, since we're not using DMA to transfer data, it very well may have some impact on say, a floppy controller.

Oddly enough, i was going to send you a version of the ROM with all kinds of port 80 writes to see if we could figure out where the fault was, and that in itself may be exactly what is causing it to fail!

This weekend I'll send you a version of our latest work that has no stray port 80 writes in it, and maybe that will help. If it doesn't, then maybe we will do the port 80 write version anyway.
 
ideprototype.jpg


:p
 
hehe.. no, it's just fine. that got here very fast, too. 2 days! anyway, i've tried a few drives. they all work, but the smallest was 10 GB. from what i read, smaller drives don't seem to work right? what types of sizes have problems? i'll give em a whirl on my card.

let me know some of the common issues you guys are having, and i'll see what happens when i try to recreate.
 
Mike Chambers said:
hehe.. no, it's just fine. that got here very fast, too. 2 days! anyway, i've tried a few drives. they all work, but the smallest was 10 GB. from what i read, smaller drives don't seem to work right? what types of sizes have problems? i'll give em a whirl on my card.

let me know some of the common issues you guys are having, and i'll see what happens when i try to recreate.
Click to expand...

As of I recall, all those issues should have been fixed by now.
 
is there any version of DOS that'll work on an 8088 that makes/sees partitions larger than 2 GB? DR-DOS uses FAT32 but it's still limited to making 2 GB partitions. i know DOS 7 will do it, but is it able to load on an 8088?



EDIT: there actually seem to be some issues. a couple times after executing a program the system has either started blinking strangely on the screen, or started spewing garbage data to the monitor. the only solution in either case is to reboot. also, i just tried installing arachne from ARCHN170.EXE (a known working copy a FTP'd over to the XT) and after a few minutes of extracting files okay, it came up with a CRC errors in archive dialog box and locked. i suppose i'll try on a larger drive and see if the problems continue.
 
Last edited:
per said:
Nope.

Maybe Free-DOS is able to do it? But I've never tested free-dos on an 8088, so I don't know if that'll work either.
Click to expand...

i've tried that before, freedos absolutely will not work on an 8088. also, i just edited my previous post right about as you responded... take a look at some issues i'm experiencing.
 
EDIT: there actually seem to be some issues. a couple times after executing a program the system has either started blinking strangely on the screen, or started spewing garbage data to the monitor. the only solution in either case is to reboot. also, i just tried installing arachne from ARCHN170.EXE (a known working copy a FTP'd over to the XT) and after a few minutes of extracting files okay, it came up with a CRC errors in archive dialog box and locked. i suppose i'll try on a larger drive and see if the problems continue.
Click to expand...


sounds like a data corruption issue.

this is something I haven't done yet:
1) on a modern machine, make a drive with 2 partitions. leave 1 partition blank, and copy 10-50MB of data over to the 2nd parition.

2) install that drive on the XTIDE and copy the data from 1 partition to the blank one. (I'd use xcopy over copy, since it should attempt to do larger transfers in each pass. Maybe try it with both copy and xcopy)

3) fc /b the files to see if they are copied properly. You may want to do this back on the modern machine for speed and possibly even better accuracy, maybe both on the xtide and on a modern machine.

An alternate would be do this from drive to drive (having 2 drives on the XTIDE) and then moving both back to the modern machine to do the compare.


The big issue I fixed in 008 BIOS was that when running on my 486, with an old hard drive, I was trying to read multi-sector transfers faster than the drive was able to provide the data, so it corrupted after the 3rd sector. I figured we'd never have this problem on an XT with a new hard drive, but Per witnessed essentially the same issue with his slow computer and fast drive. The issue should be fixed with both reads and writes now, but ya never know.


I'll be performing similar tests this weekend.

If there are file compare differences, please post the model # of the drive and a sample of the data that miscompared.
 
hargle said:
sounds like a data corruption issue.

this is something I haven't done yet:
1) on a modern machine, make a drive with 2 partitions. leave 1 partition blank, and copy 10-50MB of data over to the 2nd parition.

2) install that drive on the XTIDE and copy the data from 1 partition to the blank one. (I'd use xcopy over copy, since it should attempt to do larger transfers in each pass. Maybe try it with both copy and xcopy)

3) fc /b the files to see if they are copied properly. You may want to do this back on the modern machine for speed and possibly even better accuracy, maybe both on the xtide and on a modern machine.

An alternate would be do this from drive to drive (having 2 drives on the XTIDE) and then moving both back to the modern machine to do the compare.


The big issue I fixed in 008 BIOS was that when running on my 486, with an old hard drive, I was trying to read multi-sector transfers faster than the drive was able to provide the data, so it corrupted after the 3rd sector. I figured we'd never have this problem on an XT with a new hard drive, but Per witnessed essentially the same issue with his slow computer and fast drive. The issue should be fixed with both reads and writes now, but ya never know.


I'll be performing similar tests this weekend.

If there are file compare differences, please post the model # of the drive and a sample of the data that miscompared.
Click to expand...

Hey, wait a moment, I'm also having some of those issues with minor data-corruption. However, it can also be signal-noise so I'm not sure...
 
per said:
Hey, wait a moment, I'm also having some of those issues with minor data-corruption. However, it can also be signal-noise so I'm not sure...
Click to expand...

ok, let's get these issues hammered out. they are unacceptable.

1st, use an 80 pin cable. the extra ground wires should help with any outside noise being introduced. they shouldn't be required on something this slow, but we need to eliminate all the variables we can.

2nd, do the same test I outlined for mike. Copy some data on a known good controller and then compare it on the XT. Keep a log of some of the corrupt data, and maybe we can find there's a pattern to it (like bit 5 is always low when the data fails) and we can hopefully start to focus on where the problem is.

Here's some rules to follow:

* if there's a byte/bit or two that have failed out of a sector, it is not going to be a BIOS issue.

* if a bit is failing repeatedly, like bit 5 is always low in a data miscompare, then it is very likely to be a soldering issue.

* if entire sectors are corrupt, then it could very well be a BIOS issue.

* if it's totally random, like a byte is duplicated when it shouldn't be, or there's no pattern to failing bits, then it could be an IC timing issue between parts. This is especially true if you do the same compare test again, and it fails in a different location. Something like that will likely need a logic analyzer to figure out. (i can do this at my work)

We also need to figure out if the read is failing or the write. THat's why I'm suggesting you write the data on a modern machine and compare it on the XTIDE, and vice versa.

Please log your results, including the model # of the drive on the wiki debugging logs, unless mike b. has any other suggestions.
 
Hi! There are many possibilities for data corruption to sneak into the circuit. I recommend thorough inspection of the solder joints to ensure no cold joints are present. Use your soldering iron to melt/remelt all joints and wick away any excess solder.

Make sure the latches are 74F573's rather than 74ls574's because the F series TTL has better drive performance. Also use the 80 conductor cable that Hargle suggests.

Thanks and have a nice day!

Andrew Lynch
 
hargle said:
sounds like a data corruption issue.

this is something I haven't done yet:
1) on a modern machine, make a drive with 2 partitions. leave 1 partition blank, and copy 10-50MB of data over to the 2nd parition.

2) install that drive on the XTIDE and copy the data from 1 partition to the blank one. (I'd use xcopy over copy, since it should attempt to do larger transfers in each pass. Maybe try it with both copy and xcopy)

3) fc /b the files to see if they are copied properly. You may want to do this back on the modern machine for speed and possibly even better accuracy, maybe both on the xtide and on a modern machine.

An alternate would be do this from drive to drive (having 2 drives on the XTIDE) and then moving both back to the modern machine to do the compare.


The big issue I fixed in 008 BIOS was that when running on my 486, with an old hard drive, I was trying to read multi-sector transfers faster than the drive was able to provide the data, so it corrupted after the 3rd sector. I figured we'd never have this problem on an XT with a new hard drive, but Per witnessed essentially the same issue with his slow computer and fast drive. The issue should be fixed with both reads and writes now, but ya never know.


I'll be performing similar tests this weekend.

If there are file compare differences, please post the model # of the drive and a sample of the data that miscompared.
Click to expand...

i'll do this and let you know. i just put an 80-wire cable in there. first thing i'm doing is trying to install arachne again to see what happens. i was curious about the performance with a newer drive as compared to an ancient XT-style IDE i was using before. arachne uses disk swap for "memory" on machines with little RAM like these.
 
hey, arachne installed fine with the 80-wire cable! early success! :)

how to see how it runs. this also means that when i FTP'd the install EXE over it wrote it to the drive just fine. the error was during reading while installing yesterday.
 
Mike Chambers said:
hey, arachne installed fine with the 80-wire cable! early success! :)

how to see how it runs. this also means that when i FTP'd the install EXE over it wrote it to the drive just fine. the error was during reading while installing yesterday.
Click to expand...

May be a noise-problem on your side too.

Do you have your drive/cable close to the powersupply?
 
per said:
May be a noise-problem on your side too.

Do you have your drive/cable close to the powersupply?
Click to expand...

well the drive sits about 4 inches away from the PSU... the cable isn't much closer than that at any point.
 
You must log in or register to reply here.
Back
Top