• Please review our updated Terms and Rules here

8-Bit IDE Controller

hargle said:
whoa. that really looks interesting. I haven't read through everything just yet, but I did see that the article talks about 2 ways of dealing with the 16/8bit data issue, and that one way (the way the acculogic card works) is to map the other 8bits to a different I/O port. This breaks DMA access, which has been one of my fears about this project.

The other way is to map the 16bit data onto 2 consecutive reads of the same I/O address, which is what this article is all about it seems. AND it includes source code for the GAL/PAL that gets used! Top notch.

So, if we could take this project, and somehow get an option rom decoded in there, we would be set.

Before I get too excited about this new information, I'll let druid weigh in.
95% of the source code I've got right now would still be usable with this new design, so I'm happy. ;)
Click to expand...

I took a quick look at it, but didn't get too into it just yet, but, I will.
 
Keep forgetting to mention the card arrived Friday, but, I was out walking the dog, so, I picked it up Saturday.

No wonder it cost over 24 bucks, you could have shipped a truck battery in the box and there was enough packing to ship an egg to Jupiter and have it made a soft landing on the (hypothetical) surface :)

I'll start my work in a couple of days and report back.
 
OK, I'm going to start working on the board design soon, so, I want to know if we are going to clone the Acculogic card or modify the one from here http://bitchin100.com/files/hardware/

Cloning the card will, as mentioned before, require reading and duplicating two PLA chips, but the ROM is already worked into the design.

Building from the article gives us the code for the GLA, but, someone is going to have to figure out how to interface the ROM and jumpers on to the board. Converting this from an ECB to a standard 8-bit bus shouldn't be too difficult, while getting rid of the LEDs, parallel port and switches.

However, on page 29 of the PDF, right side column, second paragraph from the bottom, last sentence in the paragraph has me a bit confused.

So, what are we going to do?
 
Last edited:
I think i'm leaning toward the tilmann reh design, for these reasons:

1) it maps the additional 8bits of data to a second read of the same data port, so we could use DMA for the transfers. (I think-the example code he provides still use PIO, so that's a little fuzzy)

2) it's newer, and the author (tilmann) of that article is still out there, and could provide us with assistance if we asked. I'd be happy to get ahold of him, perhaps I should just to thank him for his article.

3) code for the GAL is provided.
--------
As for adding an eeprom, I think (ok, i hope!) that stealing that portion of the design from the acculogic card might not be that bad, and the jumpers are a part of that subsystem. I'd think that I could pin out that section for you using any other ISA board with an option ROM, like my 8bit SCSI card, since it would use the same size eeprom, and has all the same address selection jumpers. Is one of the PALs on that acculogic card is for the eeprom address decoding? that could get ugly, but again, I do have similar hardware here that I could start playing with immediately, like seeing if I can read it using my burner.
---------

page 29, 2nd paragraph from the bottom, last line says:

"The connector is a 40pin header, not to be confused with the XT-type IDE interface connector, which is also a 40pin header, but needs somewhat different hardware and totally different software!"

My interpretation of that is that is comparing 16bit IDE drives to really old 8bit XT drives and cabling, perhaps in reference to the /IO16 line (pin32), which obviously would not exist on an XT based drive/cable/interface.

All the more reason I should contact tilmann and get some direct answers.

Edit later: Tilmann Reh has been contacted and made aware of our project. Hopefully he's interested in lending a hand!
 
Last edited:
hargle said:
1) it maps the additional 8bits of data to a second read of the same data port, so we could use DMA for the transfers. (I think-the example code he provides still use PIO, so that's a little fuzzy)
Click to expand...

This is KEY to achieving speed. If DMA can do all of the port-to-mem transfers in a single burst then you'll be able to exceed 300KB/s on an XT.
 
hargle said:
I think i'm leaning toward the tilmann reh design, for these reasons:

1) it maps the additional 8bits of data to a second read of the same data port, so we could use DMA for the transfers. (I think-the example code he provides still use PIO, so that's a little fuzzy)

2) it's newer, and the author (tilmann) of that article is still out there, and could provide us with assistance if we asked. I'd be happy to get ahold of him, perhaps I should just to thank him for his article.

3) code for the GAL is provided.
Click to expand...

I agree that, provided that we can get rid of the extraneous crap and mount the PROM and jumpers, this would be the way to go.

--------
As for adding an eeprom, I think (ok, i hope!) that stealing that portion of the design from the acculogic card might not be that bad, and the jumpers are a part of that subsystem. I'd think that I could pin out that section for you using any other ISA board with an option ROM, like my 8bit SCSI card, since it would use the same size eeprom, and has all the same address selection jumpers. Is one of the PALs on that acculogic card is for the eeprom address decoding? that could get ugly, but again, I do have similar hardware here that I could start playing with immediately, like seeing if I can read it using my burner.
Click to expand...
---------
Ok, that works for me and, seeing as we have a schematic, adding the new circuitry would be pretty easy.

As for the Acculogic, I can't say for sure, but, I'm willing to bet it is. I haven't actually done anything with the card until we decide on this.

page 29, 2nd paragraph from the bottom, last line says:

"The connector is a 40pin header, not to be confused with the XT-type IDE interface connector, which is also a 40pin header, but needs somewhat different hardware and totally different software!"

My interpretation of that is that is comparing 16bit IDE drives to really old 8bit XT drives and cabling, perhaps in reference to the /IO16 line (pin32), which obviously would not exist on an XT based drive/cable/interface.
Click to expand...

Yes, I was working on that assumption as well, but wanted to see if others were reading it the same way I was, so, it's a non-issue
 
ok, this weekend I'll pinout my future domain SCSI controller and see if I can figure out where all the pins from the ROM are heading through the jumpers. Having never created a schematic before, expect it to be fairly ugly, but well documented. ;) If the lines end up going to a PAL, I'll pull it off and see if I can read it. I doubt I have any spare PALs here to try and program though, but if my burner can read it, there's no reason it can't write it.

Is there any software I should use to do schematic layouts that you can import into your project, or should I just ascii it up or scan it off paper?

Once that's done, i do want to upgrade the ROM to an EEPROM, so the card can upgrade it's BIOS through a software update. I'll assume (perhaps incorrectly) that the differences should be minor, aside from pulling in additional power to be used during the erase cycle. (we can jumper that) I've written flash upgrade programs before, so the software side of an update tool isn't too complex for me, and I do have schematics available from PC motherboards my group has designed that I can work from too, so i'll keep my spirits up that we can make that work.
 
hargle said:
I'll assume (perhaps incorrectly) that the differences should be minor, aside from pulling in additional power to be used during the erase cycle.
Click to expand...

You're partly right there. The only difference from a EPROM to a EEPROM is that A14 is moved to pin 1 and pin 27 replaced with the "write enable" (active low) line.

The IBM PC/XT BIOS ROM socets has support for both EPROMs and write-protected EEPROMs because A14 was connected to both pin 1 and pin 27.
 
I have a couple of questions, strictly out of curiosity.

Why are the PC-AT port addresses being used on a PC-XT? Given that the operation of the controller isn't compatible with PC-AT driver software, what's the point? Why not use the PC-XT addresses?

One of the problems in trying to use 286 code on an 8088-based machine is the use of the 286 INS and OUTS block transfer instructions. You could replace the 8088 with a V20, but that just adds an extra layer of confusion. And you don't have IRQ 14 and 15 anyway on an XT.

If you want to use DMA, you need circuitry on the adapter to handle it. I don't see that on the Reh design.

If running in PIO mode and using the PC AT port addresses is desirable, why not a simple state machine that would allow an access to the (data port +1) address after an access to (data port) using the 8088 IN/OUT word instructions? It seems to me that you'd get the best programmed-I/O transfer speed.

Just tossing a couple of thoughts out there to be shot down...
 
Chuck(G) said:
I have a couple of questions, strictly out of curiosity.
Why are the PC-AT port addresses being used on a PC-XT? Given that the operation of the controller isn't compatible with PC-AT driver software, what's the point? Why not use the PC-XT addresses?
Click to expand...

I guess I don't see why it matters what I/O range we're using? I wasn't aware that we had made that decision yet?

As long as it's dropped into a range that doesn't conflict with other devices that are commonly used in a PC/XT, we should be fine. If 1F0-1F7 and/or 170-17f used by other stuff, then by all means it should be moved.

Having it jumper selectable from 4 or more address ranges is of course the ideal solution.

I think there are plenty of ranges of I/O that should be available.
Not having it on top of the existing XT HDD port addresses would allow for MFM drives to be used at the same time as our card, for the truly insane.


One of the problems in trying to use 286 code on an 8088-based machine is the use of the 286 INS and OUTS block transfer instructions. You could replace the 8088 with a V20, but that just adds an extra layer of confusion. And you don't have IRQ 14 and 15 anyway on an XT.
Click to expand...
we're not using any 286+ instructions. The original dump of the BIOS used only 8088 code, and I've only augmented that to support larger hard drives. (and fixed a lot of stupid stuff) The end result BIOS will likely be 95% written by me from scratch, and i've so far only done PIO based transfers using single byte reads, because the code came from the acculogic card and they did weird stuff to get the 2nd half of the data. If we change the design, I have to change the core reader/writers, but that's fairly minor.

Since it's all PIO at the moment, there's no IRQ usage.
If the design changes to support DMA, then that'll change, but there's no reason we need IRQ 14 or 15 to work.

If you want to use DMA, you need circuitry on the adapter to handle it. I don't see that on the Reh design.
Click to expand...
I'll defer that one to a hardware guy, as I have no idea what hardware would be required there. The reh article does mention that the way his design works (512, 8bit reads from the same data port) is ideal for DMA transfers, so I assumed all the stuff required was in the design already. If you can help with that hardware design, please do.

If running in PIO mode and using the PC AT port addresses is desirable, why not a simple state machine that would allow an access to the (data port +1) address after an access to (data port) using the 8088 IN/OUT word instructions? It seems to me that you'd get the best programmed-I/O transfer speed.
Click to expand...
Agreed, that would be better, if we're still forced to do PIO, and nobody accidentally touches the data port register and gets us into a weird state!
I wonder how much of a boost that would be?
 
hargle said:
I guess I don't see why it matters what I/O range we're using? I wasn't aware that we had made that decision yet?

As long as it's dropped into a range that doesn't conflict with other devices that are commonly used in a PC/XT, we should be fine. If 1F0-1F7 and/or 170-17f used by other stuff, then by all means it should be moved.

Having it jumper selectable from 4 or more address ranges is of course the ideal solution.

I think there are plenty of ranges of I/O that should be available.
Not having it on top of the existing XT HDD port addresses would allow for MFM drives to be used at the same time as our card, for the truly insane.
Click to expand...

Yeah, I guess I could see that. But might it be better to use some non-AT-HD I/O port range to avoid getting a false positive ID from a piece of software that probes for a HDC?

The reh article does mention that the way his design works (512, 8bit reads from the same data port) is ideal for DMA transfers, so I assumed all the stuff required was in the design already. If you can help with that hardware design, please do.
Click to expand...

You need handshaking with the appropriate DRQ/DACK signal pair. A look at the PC XT HDC schematics would be instructive.

Agreed, that would be better, if we're still forced to do PIO, and nobody accidentally touches the data port register and gets us into a weird state!
I wonder how much of a boost that would be?
Click to expand...

Well figure this:

Code: 
     in  al,dx
     mov  ah,al
     in  al,dx
     stosw

versus:

Code: 
     in ax,dx
     stosw

So there are a few cycles saved there. And, on a V20, it's simply:

Code: 
     insw
 
Hi Richard!

I have been lurking on this thread for some time but a bit hesitant to add anything because I am currently swamped with the N8VEM project. Ironically, my current task is making an ECB Disk IO board which contains IDE and FDC interfaces. I can "feel your pain" as adding an interface seems so simple at the outset but quickly gets very complicated.

May I make a suggestion though? I have found to make a project "real" it has to be very simple so that the circuit is "buildable." With that in mind, maybe the approach this project should refocus to simplify the objective. Early in this thread, Hargle suggested this approach:

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

Given this circuit has already been designed and software exists for it, I think this may be your best approach. I understand it does NOT contain the boot ROM and probably doesn't have all the bells and whistles some of the other designs have. However, if you look at the circuit schematic closely you'll notice the entire design is implemented in bog standard 74LSxxx TTL chips and a prototype could be relatively easily implemented on an 8 bit ISA prototype board.

http://www.jameco.com/webapp/wcs/st...toreId=10001&catalogId=10001&productId=21532&

Once that existed and the circuit and software verified to work properly, I believe the design could be extended to include a boot EPROM socket.

The bottom line is I recommend building a working prototype and extending it before you commit anything to a PCB manufacturing run. Frankly, I would love to do it myself but I do not see any opportunity to do so due to previous commitments on the N8VEM project.

Thanks and have a nice day!

Andrew Lynch
 
Andrew,

We all appreciate your input since you've "built from scratch" for your project.

I'm just, basically, waiting to see what happens.

Of course, whatever design we choose is going to have bread-boarded, at some point and that protoboard seems like it would make it very easy.

However, if we go with the latest design, and someone works in the ROM and jumpers, then Hargle's people could do the schematic to board work as they have nothing to do.

As I mentioned before, I have LOTS to do and just offered because no one else was.
 
i too agree with andrew that building up one or two protoboards is the way to go before we mass produce anything. it just makes sense. I had no idea that ISA slot edge prototype boards still existed in the market...

Software wise, all of the designs we're playing with are all pretty similar, so only the really low-level reader/writers need to change if we switch to DMA in the future, and it's pretty minor to jump to option ROM in the future too, so I suggest stages of design are ideal.

I'd love to have either the reh or linux design in a protoboard right now-I could probably finish off and debug the software in a solid weekend.

anyone want to build me one? :) I'd even buy all the parts if you put it together.
 
here's some preliminary work on the option rom hookup, as pinned out from my TMC-850 card, hopefully this is somewhat useful.

This rom is an intel d27128-4
Code: 
                             +--\/--+
          ISA B29 (+5v)<-vpp-|      |-vcc->ISA B29 (+5v)
ISA a19 (address bit12)<-a12-|      |-pgm->ISA B29 (+5v)
ISA a24 (address bit 7)<--a7-|      |-a13->? no connect?
ISA a25 (address bit 6)<--a6-|      |-a8-->ISA a23 (address bit 8)
ISA a26 (address bit 5)<--a5-|      |-a9-->ISA a24 (address bit 7)
ISA a27 (address bit 4)<--a4-|      |-a11->ISA a27 (address bit 4)
ISA a28 (address bit 3)<--a3-|      |-oe-->jumper W1, pin 2
ISA a29 (address bit 2)<--a2-|      |-a10->ISA a21 (address bit 10)
ISA a30 (address bit 1)<--a1-|      |-ce-->jumper W1, pin 2
            LS244 pin 3<--a0-|      |-o7-->LS244 pin 8
            LS244 pin 5<--o0-|      |-o6-->LS244 pin 12
            LS244 pin 7<--o1-|      |-o5-->LS244 pin 16
            LS244 pin11<--o2-|      |-o4-->LS244 pin 20
                         gnd-|      |-o3-->LS244 pin 15
                             +------+


So the outputs go to some kinda buffer-I should ohm that out to see where they go. I didn't have any specs with me when I multimetered this out.

I don't quite understand why bit 7 and 4 are duplicated and go to the same connector. I may have to 2x check that with the data sheets handy next time, likewise with the a0 output-i guess I would have suspected that to go the ISA a31. This is why you should never send a software guy in to do hardware work.

the jumpers themselves all end up at the asic on the card, so there's little hope in figuring out how the address selection is changed.
 
Hello guys what happened to idea it did seem great but suddenly not a word, did it just roll over an die?

Will you implement DDO code for the bios?
Will it will be 8086 code.

Couldn't you at least program and implement the DDO driver before you give up the great idea, i need it for my ADP50L controller :D

Well if you still working on it good luck, it seems like a reall good idea to me.

JT
 
JT64 said:
Hello guys what happened to idea it did seem great but suddenly not a word, did it just roll over an die?

Will you implement DDO code for the bios?
Will it will be 8086 code.

Couldn't you at least program and implement the DDO driver before you give up the great idea, i need it for my ADP50L controller :D

Well if you still working on it good luck, it seems like a reall good idea to me.

JT
Click to expand...

Looks like we are just waiting for someone to prototype the (whatever) design after the schematic is augmented to include the desired options and exclude the ones that aren't necessary.

Judging from the number of people fighting over the honour of doing it, I'm getting the sinking feeling that'll be me.....
 
You must log in or register to reply here.
Back
Top