8-Bit IDE Controller

[Lutiana]

My fear is the 62 pin connector though.

I am not sure I understand what it that you fear about the connector.

Hopefully nothing will happen but we don't want to find out we have a problem *after* taking delivery of 100 PCBs.

I completely agree. Best to take it slow, and do some small runs first, till you're 100% sure of end result. In fact I'd recommend running at least 3 - 5 small runs. Sell them to people to play with and give you feed back before a large run. Lots of small runs would allow for minor changes in the PCB as you go along, and the more people that get their hands on these early revision boards the better.

And then once the design is complete, you can sell them on Ebay and eventually amass enough money to rule the world... Well okay, not really, but hopefully enough to recoup your time and costs.

 

[hargle]

PS, BTW, I also checked the hdtest run on the XT test station. Its up to 0018xxxx of 00FBxxxx sectors. Does this need to go all the way to the end or can it be aborted part way through and still provide meaningful results? If it were encountering errors would it have printed them already or do I wait until its done? I hope the power stays up for the next two weeks!

yeah, go ahead and shut it down, it doesn't need to go through the entire drive to make sure it's working. If there were any errors, it would have displayed a dump of expected/found data and then quit. I'm confident that your card is working as expected.

 

[hargle]

now another question I have: would an XTIDE card work in more modern systems, i.e. Pentium - Pentium III class?

Don't bother. the card is slow, partly because it doesn't use IRQs or DMA, and partly because it is converting 8bit data to 16bit data and vice versa. On any machine with an actual 16bit data bus (that is, a 286 or better), a regular IDE controller with a boot sector INT13 overlay like Drive Manager would smoke the performance of our card and offer you every benefit that ours has, aside from the warm fuzzy of helping out our project.

 

[Lutiana]

I have updated and tweaked the Wiki a little bit. I intend to do more.

Can you guys post the settings for those 2 dip banks, so I can get that up there.

Thanks

-Jarrod

 

[NobodyIsHere]

yeah, go ahead and shut it down, it doesn't need to go through the entire drive to make sure it's working. If there were any errors, it would have displayed a dump of expected/found data and then quit. I'm confident that your card is working as expected.

Hi! OK, the XT test station has gotten up to 0018xxxx sectors with no errors. I think its working so lets move on to other testing.

Thanks and have a nice day!

Andrew Lynch

 

[NobodyIsHere]

I have updated and tweaked the Wiki a little bit. I intend to do more.

Can you guys post the settings for those 2 dip banks, so I can get that up there.

Thanks

-Jarrod

Hi! That information you can pull directly off the schematic. SW1 sets the IO address of for the IDE interface. The switches correspond to A4-A9 with the last two switches must be closed. Closed corresponds to 0 and open corresponds to 1 in the address so all closed would be 0x000, the first switch open would be 0x010, and so forth. The only IO address that matters right now is 0x300 which is all closed except switches 5 and 6 open. SW1 addresses bits are "flipped" compared to normally read binary numbers. That is fixed in the updated PCB.

SW2 follows similar logic for the ROM address but follows the normal binary order. The ROM can be placed at any memory addresses starting at the 8K boundary from $00000 through $FE000.

Thanks and have a nice day!

Andrew Lynch

 

[bobwatts]

Thanks !

Thanks !

Hi Gang !

Just dropping a public note of thanks to Druid and Jeff for the safe return of my Acculogic sIDE card. It was packaged in a magnificent manner, and looks like new. Thanks Jeff !

Although I haven't tried it out yet, I anticipate great results with the new BIOS ROM that Mr. Leyda has provided. Even if there are conflicts with the loaded devices in my particular machine, I'm confident they can be worked out. Besides, I have the original ROM to re-install should that be necessary.

I will of course have a fire extinguisher handy to keep the smoke and flames to a minimum during initial testing. Hopefully there WILL be some excitement, and not a mundane boring test involving nothing more than bits and bytes performing as they should. What would be the fun in that ?

Once again, my sincere respect to Jeff, Andrew, and others for their efforts in this endeavor.

bobwatts
EartH

 

[Druid6900]

Hi Gang !

Just dropping a public note of thanks to Druid and Jeff for the safe return of my Acculogic sIDE card. It was packaged in a magnificent manner, and looks like new. Thanks Jeff !

Although I haven't tried it out yet, I anticipate great results with the new BIOS ROM that Mr. Leyda has provided. Even if there are conflicts with the loaded devices in my particular machine, I'm confident they can be worked out. Besides, I have the original ROM to re-install should that be necessary.

I will of course have a fire extinguisher handy to keep the smoke and flames to a minimum during initial testing. Hopefully there WILL be some excitement, and not a mundane boring test involving nothing more than bits and bytes performing as they should. What would be the fun in that ?

Once again, my sincere respect to Jeff, Andrew, and others for their efforts in this endeavor.

bobwatts
EartH

Better watch what you wish for, you're liable to get it

 

[Lutiana]

SW1 sets the IO address of for the IDE interface. /snip

SW2 follows similar logic for the ROM address /snip

Hi guys,

Please check the attached XLS spread sheet to see if my tables are right.

Thanks

-Jarrod

 

[NobodyIsHere]

Hi! Well the good news is that the trace router optimizer is doing a wonderful job in the trial run. The PCB is down to 94 vias and less than 400" overall trace length. That is really good it was able to clear up the mess so quickly.

However, that was just a trial run to shake out the normal PCB layout issues. I've rolled in a couple of updates to the layout since starting the trial trace routing. Does anyone have any more comments and/or changes to the design, requirements, PCB layout, etc? Now is the time to get them in and start the discussion! Please take another look and let me know!

Thanks and have a nice day!

Andrew Lynch

 

[mbbrutman]

Andrew ..

Might want to wait a few days for comments. I'm going to be examining one of Hargle's board fairly shortly, but probably won't have anything to say about it until mid next week.


Mike

 

[NobodyIsHere]

Hi Mike! Yes, the PCB respin can wait. I suspect there will be more changes required once the initial test group gets their boards and really starts hammering on the design. I have a couple more ideas on how to improve the layout for better trace routing which may help some but will require a restart.

Please let me know if there is anything I can do to help push this along. Its exciting to see this project get closer to something real and I am "champing at the bit" to get this out. Still, another round of testing may be warranted as we already have many changes to the design and probably more are on the way.

What we need are changes to make the HIGH and LOW IO ports adjacent so DMA would work but everytime I look at the design I see that it is absolutely dependent on sequential byte wide reads to get the latching mechanism to work. Does anyone have any bright ideas on how to make this DMA compatible? I had a brief thought of swapping A3 with A0 but I fear it would have such a dire effect on the register compability it would break things. I think it would interleave the registers like this R0, R8, R2, RA, R4, RC, ... etc. I am sure after trying to write and debug a BIOS with a register set like that Hargle would be drinking out of the Windex bottle...

Since this is an Intel machine it may have to be LOW to HIGH adjacent like this R8, R0, RA, R2, RC, R4, etc for the DMA to work but that just adds even more to the confusion. That'd be a simple tweak of flipping A0 with a single transistor inverter. Register level backward compatibility would be gone completely but DMA might work.

Hey Hargle; do you still have your wire wrap prototype? If you've scrapped it and moved on maybe its time for some experimenting. It never worked all that great to begin with so it'd be the ideal candidate for tweaking. I surely hate to break mine as it "works" and I am truly reluctant to "break" working units exploring goofy ideas. We could do this "cutting and jumpering" a broken or unbuilt PCB as well but that's almost a criminal waste of a test asset.

Thanks and have a nice day!

Andrew Lynch

PS, I've been mulling this over a bit more and IIRC there is an unused inverter on U5. If that's still true then the second scenario (R8, R0, RA, R2, RC, R4, etc) could be implemented completely with cuts and jumpers on PCB or prototype board without any "dead bugs"

PPS, never mind... I am thinking 16 bit DMA and we only have 8 bit DMA on a PC/XT. What are the characteristics needed to get 8 bit DMA working? Would replacing A3 with a T flip flop attached to the IO port chip select work? That way you get alternating register set access; on the first IO access you get R0-R7 and on the next you get R8-RF and so on and so forth. That could be done with a new 74LS74 "dead bug" on the circuit board. It would still effect register level backward compatibility though. Also the IDE /DMACK, DMARQ, /CS0, and /CS1 lines are all effected and would have to be qualified for proper operation. Its either an OR or AND gate but its another chip (74LS32?) at least. Also, I assume just hooking the IDE /DMACK and DMARQ lines to the ISA bus would be sufficient but it may have other effects.

 

[hargle]

I think it would interleave the registers like this R0, R8, R2, RA, R4, RC, ... etc. I am sure after trying to write and debug a BIOS with a register set like that Hargle would be drinking out of the Windex bottle...

yeah, that would make things really difficult. We'd then be DMAing the data in, and then having to double back through the data to flip all the bits in the right order. It would probably be slower than PIO by the time we were finished.

transistor inverter. Register level backward compatibility would be gone completely but DMA might work.

Ah, here's another issue I think. We still need to do PIO for certain tasks, like the POST Identify Device data. Only sector read/writes use DMA, so we still need the ability to do PIO data in/out. The byte ordering of the PIO data doesn't matter-I'll flip stuff around any way it needs to be, but we must have the ability to do both.

Hey Hargle; do you still have your wire wrap prototype? If you've scrapped it and moved on maybe its time for some experimenting.

Yep. I've pulled a few parts off it, but now that I have a fresh stock of ICs, I can put it all back together, no sweat. I'd be happy to mail it to you if you want to play with it w/o breaking yours.

work? That way you get alternating register set access; on the first IO access you get R0-R7 and on the next you get R8-RF and so on and so forth.

I'm a little DMA dumb, especially on an 8bit machine, but I'd think for 8bit DMA, it's pretty much a requirement that all the data comes in through the same IO port. If you can stack the data up like you just described, I think that would work. That byte ordering would also be excellent for PIO too.
I think that's how that tilmann reh design worked. The schematics were back in the thread somewhere.

That could be done with a new 74LS74 "dead bug" on the circuit board. It would still effect register level backward compatibility though. Also the IDE /DMACK, DMARQ, /CS0, and /CS1 lines are all effected and would have to be qualified for proper operation.

I have no idea what other hardware would need to be used for actual DMA transfers to do the handshaking and actual transfers. Someone way back in the thread mentioned some stuff, but I don't remember who.
I also assume that the DMA lines were some that you didn't remove the gold teeth from?

I'm really happy to explore this some more. I think Mike coming on board will help a lot too. Cards are shipping today.

 

[hargle]

Hi! That information you can pull directly off the schematic. SW1 sets the IO address of for the IDE interface. The switches correspond to A4-A9 with the last two switches must be closed. Closed corresponds to 0 and open corresponds to 1 in the address so all closed would be 0x000, the first switch open would be 0x010, and so forth. The only IO address that matters right now is 0x300 which is all closed except switches 5 and 6 open. SW1 addresses bits are "flipped" compared to normally read binary numbers. That is fixed in the updated PCB.

SW2 follows similar logic for the ROM address but follows the normal binary order. The ROM can be placed at any memory addresses starting at the 8K boundary from $00000 through $FE000.

Would it be too bold of me to suggest that we merge the 2 dipswitches together and use 4 bits for each IO space and 4 bits for ROM address? That would give us 16 possible addresses per resource, which should still be more than enough. Most adapter cards only give us about 4 choices each, and no one seems to complain.

The reason I'm thinking this is several-fold:
1) there is no reason to decode IO below 100h. The motherboard resources pretty much keep this area as a no-go zone. My reference material says that ranges between 100 and 3ff are the primary spots for adapter card IO usage.

2) during POST, the option rom is going to need to scan IO to locate the card. With 256 possible current locations, this is going to be time consuming and error prone.

3) likewise with the option rom, we only have C800-EE00 segments to work in, that's only 20 possible locations for an 8k ROM to exist. cutting that down to 16 possible locations through 4 dipswitches is a good enough fix.

4) a little cost savings without another dipswitch.

I'm trying to work out how to wire this up, and can post back with more details, but I don't want to do that work if something like that is going to be more of a headache than it's worth.

Alternately, instead of ganging up the decodes to 2 sets of dips, we could tie a few of the unused address lines off, and route the jumpers over to the dipswitches instead to remove those from the design.

 

[per]

I'm a little DMA dumb, especially on an 8bit machine, but I'd think for 8bit DMA, it's pretty much a requirement that all the data comes in through the same IO port. If you can stack the data up like you just described, I think that would work. That byte ordering would also be excellent for PIO too.

DMA on an 8-bit machine just moves data between one 8-bit I/O port to memory. A total of 64 Kbytes can be moved at a time, and each transfer takes 3 clock cycles.

I don't think it can toggle between two ports, but I'll investigate the posibilities.

 

[Lutiana]

The reason I'm thinking this is several-fold:
/snip

5. A much smaller table on the two addresses (and easier to print on the back of the card).

Why not remove the dip switches all together and go with a classic set of jumper blocks? I am not sure if this would cut costs a bit or not, but it seems to be there must be a reason why most cards don't have DIP switch banks on them.

 

[NobodyIsHere]

5. A much smaller table on the two addresses (and easier to print on the back of the card).

Why not remove the dip switches all together and go with a classic set of jumper blocks? I am not sure if this would cut costs a bit or not, but it seems to be there must be a reason why most cards don't have DIP switch banks on them.

Hi! Yes, we could shrink the address ranges on both the IO port and the ROM address to fit on a single DIP switch but the idea of using jumpers is even better because they are cheaper and more reliable. Here is the deal though, with only 16 possibilities each we need to carefully specify the ranges.

For the IO port, there are only 10 bits to work with. The XT-IDE need 16 IO port registers so the lower four bits have to be free. If those below 0x100 are reserved then the upper two bits are basically fixed at A9=0 and A8=1. If we put the four jumpers for bits A7, A6, A5, and A4 the XT-IDE can start at
0x100-0x10F
0x110-0x11F
0x120-0x12F
.
.
.
0x1F0-0x1FF

Is that going two work?

Similiarly with the ROM if we assume address has 20 bits to work with. It needs a memory address window of 13 bits so the lower 13 bits have to be free. If the lowest useful address is $C0000 the upper two bits are fixed at A19=1 and A18=1. If we fix A13=0 then the ROM could appear at

0xC0000-0xC1FFF
0xC4000-0xC5FFF
0xC8000-0xC9FFF
.
.
.
0xFC000-0xFDFFF

If you're happy with these modifications I can roll them into the new design. I will simplify things somewhat and improve trace routing. We can replace two 8 position DIP switches and sockets with a single 2x8 dual row header. I don't think it will reduce the need for pull up resistors on the 74LS688 decoders though.

Thanks and have a nice day!

Andrew Lynch

PS;

IO address map http://www.pcguide.com/ref/mbsys/res/ioSummary-c.html
UMA address map http://www.pcguide.com/ref/ram/logic_UMA.htm

 

[NobodyIsHere]

Hi Hargle! I was looking at the IO address map and now am starting to wonder if accessing both drives on a dual drive IDE cable is even possible. Have you tried it? Now I am not sure if I've ever seen it work with two drives or not.

It seems on a modern system the primary IDE controller master drive is at 0x1F0-0x1FF and the slave drive is at 0x3F0-0x3FF. How is the slave drive accessed on the XT-IDE? I don't see any mechanism that ties an address line to CSEL. CSEL is connected to a pull up resistor so its always high.

What is your BIOS code doing to distinguish between master and slave drives?

Thanks and have a nice day!

Andrew Lynch

PS, nevermind... drive selection is done with one of the IDE registers

 

[per]

There is one way we could make DMA possible. That is if we add one I/O port that preforms either a xx0 I/O or a xx8h I/O each other or even time it's used. (that is, tie the active line of port xx0 to a counter/1-bit demultiplexer, and drive the once-xx0/xx8 port each other I/O. See the upcoming attachement.)

 

[per]

There is one way we could make DMA possible. That is if we add one I/O port that preforms either a xx0 I/O or a xx8h I/O each other or even time it's used. (that is, tie the active line of port xx0 to a counter/1-bit demultiplexer, and drive the once-xx0/xx8 port each other I/O. See the upcoming attachement.)

In other words, two writes/reads from one certain port will ressult in one R/W from/to port xx0 and one R/W from/to port xx8. This sequence repeats each 2 R/W's.