• Please review our updated Terms and Rules here

8-Bit IDE Controller

Yeah, I know you can make an adapter. I was thinking it'd be cool to have a PCB that was directly Plus connector compatible though.

I'd be happy to post pictures of the adapter that I made, using the parts I got from kb2syd. THis is maybe something that should be added to the wiki anyway, since it's a perfect mod for the home user.

I was also thinking about pulling the pin connector off my HX module and actually installing a proper ISA slot connector, maybe use an old riser card I have lying around.
 
I'd be happy to post pictures of the adapter that I made, using the parts I got from kb2syd. THis is maybe something that should be added to the wiki anyway, since it's a perfect mod for the home user.

I was also thinking about pulling the pin connector off my HX module and actually installing a proper ISA slot connector, maybe use an old riser card I have lying around.

I've seen some pictures of one... looks very simple. Your idea isn't a bad one... just adapt the connector to a riser card. I think I've got a spare one of those as well. :)
 
so, how much will the new XT-IDE 2 cards run me? was thinking of getting one for my PS/2 so i could use a better hard drive than the ST-506.
 
CompactFlash connector?

CompactFlash connector?

How much interest is there in a version of this card with a CF connector on it?
Either fixed internal or accessible through a rear bracket?

Since these are aimed at older machines that really can't access more than 8GB, and have little use for more space if they could access it, combined with the (relative) scarcity of older/smaller IDE drives relative to the availability of 1-8GB CF cards, it seems like a perfect fit for me.

Anyway, I was just trying to test the waters and get a feel for the interest.

(Yes, this is my first post on the VCF, and I just ordered a card from hargle... can't wait! :p)
 
How does XTIDE differ from AT-IDE in programmers perspective? I assume that registers are the same since the actual controller is on the drive itself. What about 16-bit data port? Do you just read/write 512 bytes instead of 256 words to transfer single sector?

XTIDE doesn't use interrupts yet. Why? Can they be enabled just by placing jumper and clearing bit 1 from IDE Adapter Control Register (and doing other bios modifications as well)?

What about DMA? There are no DMA jumpers so is new hardware revision required for DMA support?
 
How much interest is there in a version of this card with a CF connector on it?
Either fixed internal or accessible through a rear bracket?
somewhere, WAAYY in the back of this thread, user gerrydoire posted a picture of a CF adapter that was attached to a standard blank slot cover, which had been dremmeled out a bit for card access. Then you just attach the cable from the XTIDE to your hard drive, then to this device. It looked great, and I'm thinking that I will probably go this route on at least one of my machines. Yeah, XTIDE then takes up 2 ISA slots more or less, but I think that's pretty minor on large machines or machines where there are more slots in the back than ISA slots on the mobo. I think another option could be to use a 25pin serial port slot.

We bantered about the idea of CFing the card directly, but not much traction came of it. Finding something in a CF adapter that would be solderable at home seems like a challenge. (assuming we'd be attaching it directly to the card, and building a small "cable" with PCB traces.)


Since these are aimed at older machines that really can't access more than 8GB, and have little use for more space if they could access it, combined with the (relative) scarcity of older/smaller IDE drives relative to the availability of 1-8GB CF cards, it seems like a perfect fit for me.

CFs are great for sure. I don't expect the 8-10 gig hard drive market to dry up anytime soon. craigslist is an easy source. I have about a dozen drives from old xbox 1's that I've modded.

My fear with CF's is that there is no wear leveling, and with DOS FAT table being updated every time a file is changed, I think you could blast through one pretty quickly, and the place it's going to die (the flash holding the FAT) is the last place you want it to die.

The other potential twist on this is I'm trying to get CD-ROM support going. At least a proof of concept that we can read from CDs before I create a full blown driver. Now we've got 3 things that I want to attach to my XTIDE, but only cable for 2...
 
How does XTIDE differ from AT-IDE in programmers perspective?
I assume that registers are the same since the actual controller is on the drive itself. What about 16-bit data port? Do you just read/write 512 bytes instead of 256 words to transfer single sector?
Didn't I send you the BIOS source? :p Your answers are in there!

Really the only difference is the 16bit data port. What we (and acculogic) have done is to latch that 2nd 8bit byte and tuck it into another IO port, in this case it is at BASE_IO+8. Any time we transfer data to or from the drive, we simply split up the data across those 2 ports. The read/writer routines in the source code do the work of splitting or merging that data.

That's why it's so nice and easy to modify this source for actual 16bit controllers; you only have to change 2 routines and set the default IO space to 1f0.

XTIDE doesn't use interrupts yet. Why?
Getting the card functional seemed like a better goal than improving performance. I only have so many hours to dedicate to this project, and no one so far as stepped up to add IRQ support. It, like many other things, are on my to-do list.

Can they be enabled just by placing jumper and clearing bit 1 from IDE Adapter Control Register (and doing other bios modifications as well)?
go for it! send me the changes to the source and I will roll them in. that will be very helpful. Then I can continue investigating CD-ROM.

What about DMA? There are no DMA jumpers so is new hardware revision required for DMA support?

Additional hardware (not just jumpers) is required to do that. No one here has done DMA work in hardware before, so a lot of prototyping and debugging will be required. Remember, we're still developing XTIDE, but the card is also perfectly functional as it is, so we are at a decision point: Do we spend another year developing DMA support, or do we go into a production with a working card now. Is DMA worth delaying production that long? Some machines can't use DMA anyway, so is it really worth it?
 
Didn't I send you the BIOS source? :p Your answers are in there!
I see it now. I didn't first notice those if XTIDE eq 0 so i thought that you send me the Promise version since rep insw and rep stosw were used.
By the way, wouldn't this be a little bit faster:
Code:
readLoop:
	in	al, dx
	stosb
	or	dx, 8
	in	al, dx
	stosb
	and	dx, NOT 8
	loop	readLoop
It now has two byte writes but less instruction fetching. Similar thing can be done for PIO write also.

Getting the card functional seemed like a better goal than improving performance.
There wouldn't be performance improvements anyway. Polling status register and waiting interrupt will both waste just as much time. There are Int 15h/AH=90h and 91h but i don't think they will do much good on DOS anyway. Even if they did, DMA transfers would help them much more.


go for it! send me the changes to the source and I will roll them in. that will be very helpful.
I'll try something else instead. I wrote almost complete 286 BIOS two years ago. It only has what is necessary for DOS but that includes IDE BIOS functions with L-CHS (NORMAL), P-CHS (LARGE) and LBA (28-bit) addressing. It also supports (actually requires) interrupts. If i remember correctly, i also implemented block mode transfers. There are no EBIOS functions.

I will try to get it to work with XTIDE (no promises). However, currently it uses 286 instructions and reserves 1kB from top of base memory.

The whole BIOS was written for emulator so it has never been tested with real hardware. If i get it to work, i should be able to get floppy BIOS functions to work also (HD support for XT).

Is DMA worth delaying production that long?
No it is not. 8088 and 8086 would benefit from it but later CPUs are faster with PIO transfers thanks to INS and OUTS instructions. DMA would also complicate BIOS functions. For example on floppy functions it is needed to check for 64K physical page changes and switch to PIO if sector is partially in two different pages.
 
I see it now. I didn't first notice those if XTIDE eq 0 so i thought that you send me the Promise version since rep insw and rep stosw were used.
By the way, wouldn't this be a little bit faster:
Code:
readLoop:
	in	al, dx
	stosb
	or	dx, 8
	in	al, dx
	stosb
	and	dx, NOT 8
	loop	readLoop
It now has two byte writes but less instruction fetching. Similar thing can be done for PIO write also.

I don't know if it's faster. Right below that code, you will see the following code, which is even smaller than your code, but it's commented out:
Code:
readLoop:
		in	al, dx			; low port, get data
		stosb				; store it
		xor	dl, 8			; toggle to high port
		loop	readLoop
I commented it out because it appeared (by eyes only) to be even slower than the code I am currently using! Again, performance improvements have not been my priority, and I will revisit all these things eventually.

I'll try something else instead. I wrote almost complete 286 BIOS two years ago. It only has what is necessary for DOS but that includes IDE BIOS functions with L-CHS (NORMAL), P-CHS (LARGE) and LBA (28-bit) addressing. It also supports (actually requires) interrupts. If i remember correctly, i also implemented block mode transfers. There are no EBIOS functions.

Super cool! It's too bad that you came onto this project a little late; we could have started with your code from the beginning. Either way, it's great to have another set of eyes and hours available on the code.

The whole BIOS was written for emulator so it has never been tested with real hardware. If i get it to work, i should be able to get floppy BIOS functions to work also (HD support for XT).
yay! that's one of the things I am really interested in exploring too.
 
I'd love to help out with the technical details on this project. I'll have to defer until I actually get real hardware though. I've asked the missus for an XTIDE card for Christmas. ;)

I'm not real familiar with x86 assembly yet. I do have a lot of embedded programming experience though due to work. Mainly 8031 and ppc, but I'm also familiar with 6801, 6502, and z80.

I'm disassembling the 1000HX bios right now trying to understand it currently.
 
Well, this is a start at least. That "Searching boot sector from Floppy Drive A ... Found!" string is displayed by my BIOS. For some reason the Hard Disk detection didn't start at all so there is lot to do.

What if i make an error so bad that boot just isn't possible anymore? That would mean that i couldn't flash the EEPROM anymore. It is safe to boot without XTIDE and just install it while the power is on? That doesn't sound very safe.
 

Attachments

  • IMG_0077.jpg
    IMG_0077.jpg
    91.7 KB · Views: 1
What if i make an error so bad that boot just isn't possible anymore? That would mean that i couldn't flash the EEPROM anymore. It is safe to boot without XTIDE and just install it while the power is on? That doesn't sound very safe.

Are you flashing your own BIOS into the eeprom on the XTIDE?
If you break it so bad that you can't boot anymore there, just disable the eeprom on the card (j2 I think?) and your mainboard bios should allow you to boot to floppy again, then with power on, just re-enable that jumper and flash it.
 
Good thing that the ROM can be disabled if i do something bad.

I was able to detect master drive with my BIOS. It worked only after i polled busy flag from normal status register instead of alternate status register. My BIOS uses normal status register only when interrupts need to be acknowledged. Alternate status register is read for everything else, like making sure that controller is ready to accept commands.

Why didn't the alternate status register work? It is found at base port + 206h on XTIDE as well?
 
What about Adapter Control Register? It should use the same port as Alternate Status Register (ACR is write-only, ASR is read-only). Control Register is used for resetting controller and disabling/enabling interrupts.

Anyway, i now use normal Status Register only and look at this:
XtideAlternateBios.jpg


Interrupts are not used at the moment and there are some bugs, like 256MB CF card was identified as CD-ROM (now i know that non-magnetic device flag doesn't automatically mean CD-ROM). The 512MB card was identified as hard disk but as an L-CHS device and not as an LBA device.
 
What about Adapter Control Register? It should use the same port as Alternate Status Register (ACR is write-only, ASR is read-only). Control Register is used for resetting controller and disabling/enabling interrupts.
AFAIK, there are no other registers available beyond the 8 standard IDE registers, plus the 1 additional data register.

So it seems your BIOS is now as functional as the one I created.
It seems you have more time to dedicate to this project than I do; do you want to take over all the BIOS work? I won't mind at all; I have a *lot* of other projects to work on.
All you'd need to do is take my eINT13 support and add it into your code, and I think yours would be superior, since you support CHS addressing as well as LBA.
 
something totally new here - Some computers (like the IBM PS/2 model 25) had no power connector for the hard drive. In my case, the power is supplied though a connector on the controller card. Would it be possible to add a power header to the XT-IDE card for people who might have a similar computer setup?
 
Back
Top