8-Bit IDE Controller

[Lutiana]

Have you tried to flash it more than one time with BIOS ver 0.06?

Yep, flashed it at least 4 times. The first time I got the error I flashed it again just in case, then last night in order to get the error message for posting I flashed it again. My cat decided that after the first flash it was a great time to walk across the keyboard, so I missed the message and had to flash it a 4th time in order to get the message.

It looks like it works just fine.

With regards to DOS 7 on the XT, I am not too worried about it not working, plus this does not surprise me. So I will stick with DOS 5 or 6 to fdisk and format the test drives.

The one question I have in my mind is if DOS 6 only sees the drive as a 8gb drive (instead of 20) and I create a 2gb partition, would this partition be readable in other systems? I am thinking yes, but this was my hesitation on FDISKin the drive on the XT.

The thing that I have realized is I think that most people will likely prep their hard drives on newer (and faster) machines, and move the drive to the XT once it is setup. The FDISK and format procedure take a very long time on the XT, but they do seem to work just fine otherwise.

I eagerly wait for 0.07.

 

[hargle]

The one question I have in my mind is if DOS 6 only sees the drive as a 8gb drive (instead of 20) and I create a 2gb partition, would this partition be readable in other systems? I am thinking yes, but this was my hesitation on FDISKin the drive on the XT.

DOS 6 will top out at 8.4G. 8033MB IIRC is what FDISK says. You can create a series of 2g partitions, and your XT will see all 4 of them (or 5 if there's a little leftover there).

The thing that I have realized is I think that most people will likely prep their hard drives on newer (and faster) machines, and move the drive to the XT once it is setup.

yep, that's exactly the way it's supposed to work. The drive, whether prepped on the XT or a Xeon, should be interoperable between the two, as long as you're using the same DOS version on both machines.

I for one have been using my modern VIA board to fdisk and format the drive, then I copy a bunch of stuff over to it, then move the drive to the XT and make sure everything is readable as one of my tests.

 

[Lutiana]

DOS 6 will top out at 8.4G. 8033MB IIRC is what FDISK says. You can create a series of 2g partitions, and your XT will see all 4 of them (or 5 if there's a little leftover there).

So the obvious question on this one is, if I use DOS7 and make, say, 10 2gb partitions, would DOS 6 see partitions 5 - 10 (ie the ones above 8gb)?

I for one have been using my modern VIA board to fdisk and format the drive, then I copy a bunch of stuff over to it, then move the drive to the XT and make sure everything is readable as one of my tests.

I will adjust my test procedure to closer model this. I am using an Intel based board for this. I am glad to see my findings and reasonings are the same as the creators of this card.

Other than the weird glitch with my Toshiba 6gb hard drive (no matter how it is jumpered it ALWAYS comes up as slave, more testing is needed on my side with this drive though) the card seems to work fine.

Thanks

-Jarrod

 

[hargle]

So the obvious question on this one is, if I use DOS7 and make, say, 10 2gb partitions, would DOS 6 see partitions 5 - 10 (ie the ones above 8gb)?

now that's an interesting question. and certainly one I don't have an answer to at all. let us know ok?

DOS7 fdisk asks you if this large hard drive should be treated as large when start it. it may be at that point when it would switch between being able to see the entire drive or 8.4G of it just like DOS6. interesting though.

 

[per]

now that's an interesting question. and certainly one I don't have an answer to at all. let us know ok?

DOS7 fdisk asks you if this large hard drive should be treated as large when start it. it may be at that point when it would switch between being able to see the entire drive or 8.4G of it just like DOS6. interesting though.

It saw mine partioned 40Gb drive as an appromaxly -357Mb drive.

 

[Lutiana]

DOS7 fdisk asks you if this large hard drive should be treated as large when start it.

Yes, by large it is basically asking you if you want to create a FAT32 partition, it is badly worded. Even if you select no, it sees the entire drive, it just won't let you create a partition greater than 2gb (the FAT16 limit).

I will have to try this out and report back.

 

[hargle]

0.07 bios posted to the wiki.

i was hoping that this one would have all my drive parameter issues fixed, but I have still have a couple troublesome 1g drives that I can't boot to after formatting, and give me bad sectors, even though no verify commands are failing. it's weird.

i wrote a program today to write via CHS to the drive and read back via LBA.
the idea was that i'd write a bunch of data on another machine, move the drive over and read it back, just to verify the data landed where the other machine put it. Looks like it's working as expected, but I should prolly do an extensive test to make sure things don't break down at the higher parts of the drive.

hopefully i'll be back on this in a day or two, gotta take a break for a bit.

 

[Lutiana]

So the obvious question on this one is, if I use DOS7 and make, say, 10 2gb partitions, would DOS 6 see partitions 5 - 10 (ie the ones above 8gb)?

Well after some extensive trial and error followed by some research I have realized that the 8gb limit imposed by DOS 6.22 is a very hard limit, here are my 2 major findings:

• You can have a maximum of 4 primary partitions (actually its 4 partitions of any kind) on any given hard drive, and with FAT16 maxing out at 2Gb ea. that totals 8gb
  
• When you create an extended partition that takes you over the 8gb barrier DOS 6.22 see it as a non-dos partition, and the data is inaccessible.

So the bottom line is putting anything into you XT with this card bigger than 8gb will most likely result in a ton of unused space, unless you use a file system other than FAT16.

 

[hargle]

thanks for the information.

Certainly, I think an 8gig (or 10 with a little waste) drive is a perfect amount for an XT. It's obviously more than you'll ever really need, even if you install every game that runs on an 8088 on it, which is exactly what I plan on doing.
4 partitions will force me to keep things mildly organized too.

I'm using old xbox 1 hard drives for my machines, because they are either 8 or 10 gig, depending on which brand you pull out of the box, and I have a lot of them. They're relatively new, stable, quiet, and run cool.

For what it's worth, I think giving freedos a shot would be interesting on an XT. I know there are a few users here who swear by it, and it has eINT13 support, so now we're talking 1TB+ drives. The BIOS actually tops out at 137G at the moment, but adding 48bit LBA support is possible if someone really needed it.

 

[per]

thanks for the information.

Certainly, I think an 8gig (or 10 with a little waste) drive is a perfect amount for an XT. It's obviously more than you'll ever really need, even if you install every game that runs on an 8088 on it, which is exactly what I plan on doing.
4 partitions will force me to keep things mildly organized too.

I'm using old xbox 1 hard drives for my machines, because they are either 8 or 10 gig, depending on which brand you pull out of the box, and I have a lot of them. They're relatively new, stable, quiet, and run cool.

For what it's worth, I think giving freedos a shot would be interesting on an XT. I know there are a few users here who swear by it, and it has eINT13 support, so now we're talking 1TB+ drives. The BIOS actually tops out at 137G at the moment, but adding 48bit LBA support is possible if someone really needed it.

It's like; if you are used to dive in a smaller swimming pool, you don't have to swim over the ocean if you get the oppurtinity to dive there.

I'm estimating the current transfer rate is about 60Kb/sec. I tested 8088 corruption, and at 30fps, it seems to play 16 seconds, then stop 8 seconds to buffer. If the speed could pass 90Kb/sec, 8088 corruption would have run without buffering at 30fps.

 

[Lutiana]

I'm estimating the current transfer rate is about 60Kb/sec. I tested 8088 corruption, and at 30fps, it seems to play 16 seconds, then stop 8 seconds to buffer. If the speed could pass 90Kb/sec, 8088 corruption would have run without buffering at 30fps.

I have noticed that initially access to the drive on the card is very slow, but then it its fine. If I copy say 20 files to the drive, it takes 10 or so seconds to copy the first file, but the other copy immediately after. This is more obvious on a newer machine, but I doubt it will be an issue on the XT itself.

 

[hargle]

I haven't done any real benchmarking-more concerned with functionality at the moment. there's several places where I can see some speed improvements.

One of them is that every single time you do any transfer to the device, I call the routine that selects the master/slave device. It really should remember what the last drive accessed was and skip that routine if it's still accessing the same device. (or skip it altogether if only 1 device exists) There's lots of little niggly things like that which should help transfer speeds. Getting another 1/3 performance might be a bit tough though. I think we're going to need DMA for that.

 

[geneb]

Is performance comparable to a PC/XT using a MFM drive with an optimized interleave? If so, there really isn't much reason to make it better than that.

g.

 

[per]

I will just make a small note on something.

Right now, the BIOS correctly detects if there is no drive attached (didn't do that before). However, if no drives are connected, the boot menu won't come up.

The reason is problably because the code taking over Int 19h is older than the boot menu. But since there is a boot menu now, I would suggest that Int 19h sould be taken over anyways if there is drives attached or not. The boot menu is flexible and will work with MFM/SCSI hard drives too, so I see no reasons why this should be a problem.

 

[per]

Yep, flashed it at least 4 times. The first time I got the error I flashed it again just in case, then last night in order to get the error message for posting I flashed it again. My cat decided that after the first flash it was a great time to walk across the keyboard, so I missed the message and had to flash it a 4th time in order to get the message.

It looks like it works just fine.

With regards to DOS 7 on the XT, I am not too worried about it not working, plus this does not surprise me. So I will stick with DOS 5 or 6 to fdisk and format the test drives.

The one question I have in my mind is if DOS 6 only sees the drive as a 8gb drive (instead of 20) and I create a 2gb partition, would this partition be readable in other systems? I am thinking yes, but this was my hesitation on FDISKin the drive on the XT.

The thing that I have realized is I think that most people will likely prep their hard drives on newer (and faster) machines, and move the drive to the XT once it is setup. The FDISK and format procedure take a very long time on the XT, but they do seem to work just fine otherwise.

I eagerly wait for 0.07.

I was not able to reproduce the errors you got. It must either be a minor failure in your EEPROM, or a bad soldering joint. Since you can read it fine after a reset, it's problably not a bad joint.

As Hargle already said, those SEEQ parts are Cr*p.

 

[hargle]

I will just make a small note on something.

Right now, the BIOS correctly detects if there is no drive attached (didn't do that before). However, if no drives are connected, the boot menu won't come up.

The reason is problably because the code taking over Int 19h is older than the boot menu. But since there is a boot menu now, I would suggest that Int 19h sould be taken over anyways if there is drives attached or not. The boot menu is flexible and will work with MFM/SCSI hard drives too, so I see no reasons why this should be a problem.

you're correct-if there are no devices attached, the BIOS doesn't install/hook any interrupts, and thus no INT 19 boot menu. I can certainly change that to hook always, especially since our boot menu is pretty cool and offers some nice features. We will need to carefully test this to make sure there are no conflicts, and it's quite possible that some other controllers will hook int 19 and not ever give control to us.

I can make the "always int 19" change in the next release.

 

[hargle]

I was not able to reproduce the errors you got. It must either be a minor failure in your EEPROM, or a bad soldering joint. Since you can read it fine after a reset, it's problably not a bad joint.

As Hargle already said, those SEEQ parts are Cr*p.

I've seen flash verify errors too, but after a reset, it all works. I didn't really pay much attention to it, because, well, it worked and I don't need to be distracted chasing down other issues right now. I have enough to do!

Obviously, the correct data was written into the part, since it worked after a reset. The flaw is likely then, that the part was still in its funky write mode when the verify phase began. Maybe just a big delay between the last write and the verify phase, so that the part is sure to fall back into its read mode?

We may not be seeing this happen often because the values in a lot of the bytes aren't changing between writes. A good test would be to make an oprom.bin file that has nothing but 00's or FF's in it and flash that in, then flash in the real rom code and see if it can be duplicated.

When I saw this error, it was on my XT, and very likely with the seeq part.

I've not had any problems flashing the atmel parts on my 486, using the /f parameter. It works really well.
I'm absolutely going to be sourcing atmel parts for the real production run, so this is one of those issues that isn't really an issue, so I'm not concerned with it personally.

 

[per]

you're correct-if there are no devices attached, the BIOS doesn't install/hook any interrupts, and thus no INT 19 boot menu. I can certainly change that to hook always, especially since our boot menu is pretty cool and offers some nice features. We will need to carefully test this to make sure there are no conflicts, and it's quite possible that some other controllers will hook int 19 and not ever give control to us.

I can make the "always int 19" change in the next release.

There will not be any conficts, I can guarantee that. That's because the Int 19h doesn't do any low-level stuff. It's only using the BIOS, and the only problem migth be that another card got buggy Int 13h routines.

To make sure Int 19h is the one suppied by our card, the user can just place it as hight as possible in the memory map. Most disk controllers use C8000, and that's the lowest possible address for BIOS extensions.

 

[per]

I've seen flash verify errors too, but after a reset, it all works. I didn't really pay much attention to it, because, well, it worked and I don't need to be distracted chasing down other issues right now. I have enough to do!

Obviously, the correct data was written into the part, since it worked after a reset. The flaw is likely then, that the part was still in its funky write mode when the verify phase began. Maybe just a big delay between the last write and the verify phase, so that the part is sure to fall back into its read mode?

We may not be seeing this happen often because the values in a lot of the bytes aren't changing between writes. A good test would be to make an oprom.bin file that has nothing but 00's or FF's in it and flash that in, then flash in the real rom code and see if it can be duplicated.

When I saw this error, it was on my XT, and very likely with the seeq part.

I've not had any problems flashing the atmel parts on my 486, using the /f parameter. It works really well.
I'm absolutely going to be sourcing atmel parts for the real production run, so this is one of those issues that isn't really an issue, so I'm not concerned with it personally.

There is already a big delay. More than 10mS!

What I think therse SEEQ parts need to get all-right reads are a power reset after a write. I absolutely recomend Atmel (they're a lot more stable).

---

On a side-note, the flasher automaticly calculates the checksum byte now, so you really don't need to include it in the ROM file in later versions.

 

[hargle]

There will not be any conficts, I can guarantee that. That's because the Int 19h doesn't do any low-level stuff. It's only using the BIOS, and the only problem migth be that another card got buggy Int 13h routines.

i wouldn't be so sure just yet. andrew has issues booting with his floppy controller card installed with our card already, changing the address to make us last didn't help.

i can easily see some device requiring some additional work to be performed at INT 19 to do a proper boot to that device. Probably not too many oddball cards on the XT, but stuff like PXE booting most certainly requires some INT 19 work to be done to boot.

I have an MFM card and my future domain SCSI controller that I will be testing boot features and multiple card compatibility with, so I can give this a good testing. I should probably get my format issue worked out first though!

worst case, I will be saving the prior vector for INT 19 before I hook it, so we could also add a menu option to call the old INT 19 as a fallback choice.