• Please review our updated Terms and Rules here

8-Bit IDE Controller

hargle said:
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.
Click to expand...

The only difference in the boot procedure of IBM's BIOS and this BIOS is that the ones in the IBM bios resets the parameters. I don't know if that is needed...

I really don't think the problems Andrew had with booting was because of Int 19h. I think it is rather a memory conflict or something. There is one way to find out; make Andrew try to use our Int 19h to boot from a floppy.
 
per said:
The only difference in the boot procedure of IBM's BIOS and this BIOS is that the ones in the IBM bios resets the parameters. I don't know if that is needed...
Click to expand...

Sure, that's all good. what I'm saying is that some oddball card may have a bunch of code in INT 19 that it needs run before it's able to boot.
(say perhaps a SCSI controller needs to initialize something before it can read any sector off the hard drive for example)

If our card comes along and replaces the INT 19 vector with our menu, then even if you select boot to C: (the scsi drive) without that scsi INT 19 code that the oddball card was expected to execute, the system wouldn't be bootable to that device.

It's just an example. I'm not saying that there are any cards like that (especially on the XT) that put their own boot code into INT 19, but our card would be removing that code altogether if we steal INT 19 away from another device which has already hooked it. That's the part we need to be careful about. That's why I'm thinking we can always add a "boot int 19" option to the menu to allow us to call their code, which then lets the system boot to that oddball drive.

This is exactly why modern BIOSes have a boot menu. You pick in setup which device order you want to boot to, and the mainboard bios calls that device's boot code. Modern machines don't actually hook INT 19 anymore.
It's a pretty good thing that there are significantly less bootable items available on an XT class machine.
 
hargle said:
It's a pretty good thing that there are significantly less bootable items available on an XT class machine.
Click to expand...

You mean to say I cannot boot from my high end adaptec raid 5 controller in my XT, or my USB thumb drive.... *gasp* I want my money back....
 
hargle said:
Sure, that's all good. what I'm saying is that some oddball card may have a bunch of code in INT 19 that it needs run before it's able to boot.
(say perhaps a SCSI controller needs to initialize something before it can read any sector off the hard drive for example)

If our card comes along and replaces the INT 19 vector with our menu, then even if you select boot to C: (the scsi drive) without that scsi INT 19 code that the oddball card was expected to execute, the system wouldn't be bootable to that device.

It's just an example. I'm not saying that there are any cards like that (especially on the XT) that put their own boot code into INT 19, but our card would be removing that code altogether if we steal INT 19 away from another device which has already hooked it. That's the part we need to be careful about. That's why I'm thinking we can always add a "boot int 19" option to the menu to allow us to call their code, which then lets the system boot to that oddball drive.

This is exactly why modern BIOSes have a boot menu. You pick in setup which device order you want to boot to, and the mainboard bios calls that device's boot code. Modern machines don't actually hook INT 19 anymore.
It's a pretty good thing that there are significantly less bootable items available on an XT class machine.
Click to expand...

That's a good idea, but I can't add that function to the BIOS since I don't got that part of the code. If you add that variable, make sure to tell me how it works so I can add it to the setup program.
 
I thought I would post this just before I went to bed. I managed to boot into Windows 98 SE (safe mode) with the hard drive running on Hargle and Andrew's card in my test machine (PIII-550 w/ 512Mb or RAM). It took a VERY long time (about 2 hours) but it came up.

I had to go into safe mode because this install was from another machine.

Very impressive guys, you'r on the way to a nice functional product.
 
lutiana said:
I thought I would post this just before I went to bed. I managed to boot into Windows 98 SE (safe mode) with the hard drive running on Hargle and Andrew's card in my test machine (PIII-550 w/ 512Mb or RAM). It took a VERY long time (about 2 hours) but it came up.
Click to expand...

wtf?!? heheheh.
that is absolutely hilarious.

however, that is an interesting situation. If you installed this O/S off another machine, meaning another IDE controller, that means that our controller is properly reading sectors off the drive where another controller put them down, meaning that our LBA translation layer is working as expected. That's really good news, although I was slightly hoping for a bug there to explain why I can't format a couple drives that I have without the entire drive being labeled as bad sectors.

Either way, that's an accomplishment. And certainly an experiment that I never would have considered attempting. You've made my day.
 
hargle said:
If you installed this O/S off another machine, meaning another IDE controller, that means that our controller is properly reading sectors off the drive where another controller put them down, meaning that our LBA translation layer is working as expected.
Click to expand...

It was actually a 40gb laptop drive from an old Sony laptop. Partitioned into one 40gb partition and had Windows 98 installed on it. So yeah the translation seems to be working just fine.
 
come get it!
http://wiki.vintage-computer.com/index.php/XTIDE_project

v0.08 BIOS

fixed the format issue finally. wow, that took up almost a week of my time. the deal is that on older drives (1995ish) on newer machines (486ish), doing multi-sector reads/writes could cause the data to not be available fast enough from the drive for the host. So data would get lost/corrupt after reading a couple sectors in a row. The fix was to insert a "check for data ready" between each read of a sector.

It was really tough to find, since single sector reads always worked fine, so I couldn't see any issues with the data when using single sector tools like norton disk edit, or even my own CHS->LBA test which i wrote just to find this bug.

Oddly enough, this likely would have never been an issue, had I not been playing around on the 486 lately.

I don't have a single drive in my collection (or CF card) that I am unable to format and boot to.


Fixed a boot menu bug too. It was losing track of where to find the next boot device to try when booting to the A: drive failed.


Do not use anything less than 0.08 BIOS please.
 
hargle said:
come get it!
http://wiki.vintage-computer.com/index.php/XTIDE_project

v0.08 BIOS

fixed the format issue finally. wow, that took up almost a week of my time. the deal is that on older drives (1995ish) on newer machines (486ish), doing multi-sector reads/writes could cause the data to not be available fast enough from the drive for the host. So data would get lost/corrupt after reading a couple sectors in a row. The fix was to insert a "check for data ready" between each read of a sector.

It was really tough to find, since single sector reads always worked fine, so I couldn't see any issues with the data when using single sector tools like norton disk edit, or even my own CHS->LBA test which i wrote just to find this bug.

Oddly enough, this likely would have never been an issue, had I not been playing around on the 486 lately.

I don't have a single drive in my collection (or CF card) that I am unable to format and boot to.


Fixed a boot menu bug too. It was losing track of where to find the next boot device to try when booting to the A: drive failed.


Do not use anything less than 0.08 BIOS please.
Click to expand...

That's fantastic. Does that mean that my Segate drive will work now, and that the DOS 5.0 installation will be able to complete?

Maybe I should use segment-overrides (CS:[variable]) on all variable-reads in the future... I don't like to shuffle a register between something and some other thing as it may become pretty confusing after a while.

By the way, you forgot to add the code from the new menu on my site; the error message in the boot menu are still missing that 'space'.
 
Last edited:
hargle said:
come get it!
http://wiki.vintage-computer.com/index.php/XTIDE_project

v0.08 BIOS

[snip]

Do not use anything less than 0.08 BIOS please.
Click to expand...

Hi Hargle! I burned a 2764 EPROM with the new OPROM-008 BIOS. Unfortunately I seem to be missing the "ANY" key... ;-)

I can see the BIOS ROM is executing since it detects my hard drive and prints the boot message. Then it says "press any key to for boot menu..." and hangs the XT clone up hard.

I reverted back to the OPROM-005 version and it works. Apparently something introduced in the 006, 007, or 008 version doesn't like my XT clone. Am I doing something wrong?

I'll get the 006 and 007 versions and burn EPROMs of those and let you know if they work. While I am testing is there any of the test utilities you'd like run on my system?

Thanks and have a nice day!

Andrew Lynch
 
Hi! I downloaded versions 006 and 007 and burned EPROMs for them. Apparently the menu hang glitch was introduced with 006 and the "press any key for boot menu..." prompt. Bummer!

So I am sticking with 005 for now. It seems to me we ran into this problem before when I was testing the first wire wrap prototype on my PIII test station? There must be something about the XT keyboard that is causing fits.

Thanks and have a nice day!

Andrew Lynch
 
lynchaj said:
Hi! I downloaded versions 006 and 007 and burned EPROMs for them. Apparently the menu hang glitch was introduced with 006 and the "press any key for boot menu..." prompt. Bummer!

So I am sticking with 005 for now. It seems to me we ran into this problem before when I was testing the first wire wrap prototype on my PIII test station? There must be something about the XT keyboard that is causing fits.

Thanks and have a nice day!

Andrew Lynch
Click to expand...

It should pause for about 5 seconds before booting by defaut... If any key is pressed durning this delay, the menu should appear.

Of course I can make the menu disabled by default (so you need to "activate" it with the setup program).
 
Last edited:
Hi! No luck with any BIOS version later than OPROM-005. When the BIOS boots and prints "Press any key for boot menu..." the XT clone locks up hard and it does not respond after waiting. Even the NUMLOCK LED no longer responds and neither does CTRL-ALT-DEL. Only a power cycle restores the machine since I don't have a reset button on this poor old thing. I haven't tried it on the PIII yet but since the XT clone is closer to target hardware that's where I do most of my testing.

I've been off doing other things lately while the XT-IDE BIOS development settles down. Are there any changes identified for the hardware? I haven't started the respin yet since we never settled on a final configuration.

Thanks and have a nice day!

Andrew Lynch
 
lynchaj said:
Hi! No luck with any BIOS version later than OPROM-005. When the BIOS boots and prints "Press any key for boot menu..." the XT clone locks up hard and it does not respond after waiting. Even the NUMLOCK LED no longer responds and neither does CTRL-ALT-DEL. Only a power cycle restores the machine since I don't have a reset button on this poor old thing. I haven't tried it on the PIII yet but since the XT clone is closer to target hardware that's where I do most of my testing.

I've been off doing other things lately while the XT-IDE BIOS development settles down. Are there any changes identified for the hardware? I haven't started the respin yet since we never settled on a final configuration.

Thanks and have a nice day!

Andrew Lynch
Click to expand...


You may try to press a key when the message apprars. If the boot menu doesn't appear, try the following:

Burn an EPROM of version 0.08 where you change the byte at offset 001Ch to 00h. Make sure to change the checksum byte at 0FFF or 1FFF accordingly (doesn't matter which of them, any unused byte within the 8k range will work). If it still doesn't boot... Then there must be some problems with either Int 13h function 00h or function 02h.
 
Last edited:
Jeff and I have been having a running conversation on these cards. One of the key observations is that testing is a very important part of what we are doing:

  • We need to understand what has been tested and what has not
  • We need to ensure the testing is somewhat well defined and methodical
  • We need to chase down any weirdness, from drives not reporting in, systems not getting through POST, data corruption, performance variations
  • We need to chase down perceived problems with component quality


I would like to start gathering this data to get a broader picture of what works and what doesn't so that we know where to apply focus. But this thread is probably not a good place to do that - it's too unwieldy.

I'd like to start gathering individual experiences with the card to get an idea of what you have tried it with, what tests you have run against it, etc. I'll try to get the data points organized and most results the Wiki periodically so that people can see what we are doing. Please drop me a private message here so that we can exchange email addresses. Hopefully we can get a little bit more organized - the card has great promise, but we're not coordinated enough.


Regards,
Mike
 
All of my debugging is being logged here:
http://wiki.vintage-computer.com/index.php/XTIDE_project_debug_log

I've exhausted my collection of hard drives, and have verified that all of them available to me match drive parameters the same as a modern motherboard with phoenix BIOS, and that all of them that I was willing to format (some had data that I didn't want to lose) were fdisk+format+bootable. From my card and drive collection's point of view, there are no outstanding issues for drive compatibility/usability.

It seems that almost everyone else has a straggling drive that just doesn't quite work right though. These are the ones that we need to bring to the forefront and decide where the faults lie.

Andrew's system is just weird, so let's ignore him. :p

Andrew, do you have a POST card available? I can build you a 008 version with a bunch of post codes in various spots and you can tell me where it's locking up at.
 
Notifications stopped

Notifications stopped

Hi GAng !

Looks like things are progressing. Anyone know why my notifications stopped? I thought that everyone was asleep for the past couple of weeks.

By the way, just noticed that the Legendary Mr. Lynch is just down the road from me. ( Dayton Ohio. )

bobwatts
EartH
 
hargle said:
All of my debugging is being logged here:
http://wiki.vintage-computer.com/index.php/XTIDE_project_debug_log

I've exhausted my collection of hard drives, and have verified that all of them available to me match drive parameters the same as a modern motherboard with phoenix BIOS, and that all of them that I was willing to format (some had data that I didn't want to lose) were fdisk+format+bootable. From my card and drive collection's point of view, there are no outstanding issues for drive compatibility/usability.

It seems that almost everyone else has a straggling drive that just doesn't quite work right though. These are the ones that we need to bring to the forefront and decide where the faults lie.

Andrew's system is just weird, so let's ignore him. :p

Andrew, do you have a POST card available? I can build you a 008 version with a bunch of post codes in various spots and you can tell me where it's locking up at.
Click to expand...


Hi! Yes, I've a POST card in the basement someplace. There are different ones for different machines. I believe the XT's used port 60 and the AT's and later used port 80. The ISA post card which is most readily accessible is one of the port 80 units for ATs if that'll help. It works fine on the PIII machine but I've not tested it on the XT clone. I have an XT POST card but its buried someplace. It doesn't matter though since you can write diagnostic codes to any IO port you choose.

My system XT IDE card won't boot if either the FDC with BIOS has its ROM chip installed or the Seagate MFM with BIOS is installed. I suspect there is something flakey going on with the boot code determining boot order or something. Int19 hook maybe? Who knows?

I am working on a couple of N8VEM projects right now so my time on this is pretty limited. I am about half way through the construction of the N8VEM video display unit board and some S-100 related stuff. So if there is something specific I can help with please let me know.

Thanks and have a nice day!

Andrew Lynch
 
lynchaj said:
Hi! Yes, I've a POST card in the basement someplace. There are different ones for different machines. I believe the XT's used port 60 and the AT's and later used port 80. The ISA post card which is most readily accessible is one of the port 80 units for ATs if that'll help.
Click to expand...
that's perfect. I'll draw up a BIOS for you tonight with a ton of port 80 codes, and you can let me know where it's hanging.

My system XT IDE card won't boot if either the FDC with BIOS has its ROM chip installed or the Seagate MFM with BIOS is installed. I suspect there is something flakey going on with the boot code determining boot order or something. Int19 hook maybe? Who knows?
Click to expand...
yep, that's 100% untested at the moment. I need to dig out my MFM card and see if I can duplicate any of these issues so they can be clobbered.

Does that mean it actually does boot if you remove those devices?
 
You must log in or register to reply here.
Back
Top