8-Bit IDE Controller

[hargle]

hi! back to work here, after taking a couple days off over the weekend.

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?

Last night, I checked my 100h-1ffh range on my zenith 8088, and it looked to me that the entire range was full of other things decoding in that address range. The entire 200h range appeared to be empty. The 300h range had some stuff in it too (video at a minimum), but certainly our favorite 300-30f is free.

I should (or Per will likely beat me to it) check to see how the 1xx range is being used on a true XT and PC, and also see what's being decoded in the 2xx range.

Right now, I'm leaning toward having you tie bit 9 high, 4:0 low, and let the switches be bits 8:5. That'll put us at either 2xx or 3xx and it'll increment in steps of 20h.
Like such:

98 7654 3210
10 0000 0000 = 200h
10 0010 0000 = 220h
10 0100 0000 = 240h
10 0110 0000 = 260h
10 1000 0000 = 280h
10 1010 0000 = 2A0h
10 1100 0000 = 2C0h
10 1110 0000 = 2E0h
11 0000 0000 = 300h
11 0010 0000 = 320h
11 0100 0000 = 340h
11 0110 0000 = 360h
11 1000 0000 = 380h
11 1010 0000 = 3A0h
11 1100 0000 = 3C0h
11 1110 0000 = 3E0h

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 think that's perfect. Plenty of room. Heck, even moving it around using only 3 bits and having the 4th be a ROM enable/disable would be fine.


I think we (per?) could write a little utility that scans IO space looking for unused IO in the above ranges, and then also scans for an 8k chunk of ROM space to use, and then prints out to the screen a good dip switch setting display. Users could run that software before putting the card in.

It 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.

This really is a win-win. costs go down, simplicity goes up. I personally prefer dipswitches to jumpers for something like this though.
So I'm visualizing an 8 dipswitch to control all the addresses, and then a jumper block to control the enable/disables and IRQ selections. Sound right?

 

[NobodyIsHere]

Hi! Its OK with me. I'll cut in the changes tonight and repost the schematic and PCB layout.

Thanks and have a nice day!

Andrew Lynch

 

[NobodyIsHere]

Hi! OK done. Please check out and review the schematic and PCB layout on the N8VEM wiki. Thanks and have a nice day!

Andrew Lynch

 

[mbbrutman]

I am running one of the Hargle cards now. It is, in a word, magnificent.

Right now it is running in an original XT with a 40GB Western Digital drive. The drive had DOS 7 installed. I nearly died when it booted to DOS 7 on the first attempt.

A simple I/O benchmark that I wrote shows 80KB/sec writing an 87KB/sec reading. No, it is not a speed demon. But this PIO based code has a quite a few things going for it:

• No IRQs required - nice for our target systems, which are short on IRQs anyway. Also simplifies setup.
• No DMA required, which is also night
• The code should be pretty portable to other machines (like the PCjr) that don't have DMA

I'm going to burn this drive in nice and hard .. and I have a few more to test against too.


Once again fellas, magnificent. I will buy beer when I see you in person. (For Jeff that is a very real threat.)


Mike

 

[Unknown_K]

How does the speed compare to an XT era MFM drive and controller?

 

[NobodyIsHere]

I am running one of the Hargle cards now. It is, in a word, magnificent.

Thanks Mike!

Right now it is running in an original XT with a 40GB Western Digital drive. The drive had DOS 7 installed. I nearly died when it booted to DOS 7 on the first attempt.

A simple I/O benchmark that I wrote shows 80KB/sec writing an 87KB/sec reading. No, it is not a speed demon. But this PIO based code has a quite a few things going for it:

• No IRQs required - nice for our target systems, which are short on IRQs anyway. Also simplifies setup.
• No DMA required, which is also night
• The code should be pretty portable to other machines (like the PCjr) that don't have DMA

Yes, the plain PIO approach has its benefits! The production board will support a range of IRQs (see the N8VEM wiki) so when the time comes for software support of IRQs the board can do it.

I've looked into DMA but so far no luck. That really raises the bar on complexity. Having a working example of a simple DMA device would help but I think it would drive pretty massive changes to the design.

Regarding performance, almost all the development so far has been on just basic functionality. I believe that once the design settles and everything works that the transfer speed will improve somewhat. There are things like loop unrolling, etc which can boost transfer rates. However its premature to deal with that now. Hargle's done a great job on the BIOS but there is a lot of complexity in supporting a variety of IDE devices and PC machines.

If you would, see if you can get the XT-IDE to share the PC with a MFM/RLL style ST-412/ST-506 controller preferrably with its own BIOS. In my testing there seems to be a problem someplace regarding the XT-IDE and my other XT disk controllers with BIOS (FDC and MFM HD).

I'm going to burn this drive in nice and hard .. and I have a few more to test against too.


Once again fellas, magnificent. I will buy beer when I see you in person. (For Jeff that is a very real threat.)


Mike

Great! Please experiment with the XT-IDE and drives. When you get a chance please check out the latest schematics and PCB layout for any considerations for the production unit.

Thanks and have a nice day!

Andrew Lynch

 

[per]

I've looked into DMA but so far no luck. That really raises the bar on complexity. Having a working example of a simple DMA device would help but I think it would drive pretty massive changes to the design.

DMA-capabilities migth be availible just by adding 3 ICs (2 if we can get a 2-in-1 counter). I've not checked if we need to add any NOT gates to make it work, but it should.

What the logic I've come up with does is that it toggles between triggering one of two output-lines each time one input line is triggered. Because of this, you don't need to do "In base+0" and "In base+8" to read a word, it is enough with two "in base+0".

If I'm right about DMA, this will actually work.

I'll post more of it tomorow (as I don't got time now).

 

[bobwatts]

Two drives ?

Two drives ?

Hi Gang !

As I mentioned previously, I got the Acculogic sIDE card back the other day, but unfortunately, haven't gotten a spare second to install it, and try out the new "hargle" BIOS.

I can't find the thread message now, but I was curious if the card will still support two IDE drives. I seem to recall that there was/is maybe an issue with this. I have two IDE drives installed, and the sIDE card worked fine with 'em previously.

My XT is really packed away, and just not easy to get to, but I will soon to test it out.

bobwatts
EartH

 

[NobodyIsHere]

DMA-capabilities migth be availible just by adding 3 ICs (2 if we can get a 2-in-1 counter). I've not checked if we need to add any NOT gates to make it work, but it should.

What the logic I've come up with does is that it toggles between triggering one of two output-lines each time one input line is triggered. Because of this, you don't need to do "In base+0" and "In base+8" to read a word, it is enough with two "in base+0".

If I'm right about DMA, this will actually work.

I'll post more of it tomorow (as I don't got time now).

Hi Per! I was thinking that to get the interleaved HIGH/LOW reading from a single IO port that was to use a 74LS74 flip flop on the latches chip select line for the latches. A reset signal would clear the flip flop, then the first read would give HIGH, the next LOW, the next HIGH again, and so forth. Eliminate the use of the A3 line and just use the flip flop output to toggle back and forth. (74LS74 configured as JK FF with direct clear)

What complicates matters is that the IDE chip select signals cannot be asserted during the DMA transactions. So they would have to be qualified (with 74LS32 and probably a 74LS04 inverter) with the DMA status lines. This gets complicated since there are two separate IDE chip selects.

Here is some information from the IDE "standard":

6.3.8 DMACK- (DMA acknowledge) (Optional)
This signal shall be used by the host in response to DMARQ to either
acknowledge that data has been accepted, or that data is available.

6.3.9 DMARQ (DMA request) (Optional)
This signal, used for DMA data transfers between host and drive, shall be
asserted by the drive when it is ready to transfer data to or from the host.
The direction of data transfer is controlled by DIOR- and DIOW-. This signal
is used in a handshake manner with DMACK- i.e., the drive shall wait until the
host asserts DMACK- before negating DMARQ, and re-asserting DMARQ if there is
more data to transfer.
When a DMA operation is enabled, IOCS16-, CS1FX-, and CS3FX- shall not be
asserted and transfers shall be 16-bits wide.
NOTE 2 - ATA products with DMA capability require a pull-down resistor on this
signal to prevent spurious data transfers. This resistor may affect driver
requirements for drives sharing this signal in systems with unbuffered ATA
signals.

http://www.ele.uri.edu/courses/ele408/s2001/projects/roland_ide/IDE.pdf

I am fuzzy on the whole DMA implementation to begin with so whatever design does finally surface would require some test with a prototype board to ensure it really works. I see this easily adding several chips to the design which is why I believe the GIDE developers ended up using GALs to keep part count reasonable. If adding DMA capability comes at the price of doubling part count I do not think its worth it as it would dramatically increase unit cost due to additional parts, larger PCB required, etc. There are benefits to keeping this simple and cheap!

Thanks and have a nice day!

Andrew Lynch

 

[geneb]

Have you guys thought about checking Rolf Brown's Interrupt List to see what can use the port and memory addresses you guys are using? It might help avoid conflicts...

Oh, and I WANT ONE! :D

g.

 

[gerrydoire]

Does the Acculogic IDE 8 Bit Card support DMA?

 

[hargle]

Have you guys thought about checking Rolf Brown's Interrupt List to see what can use the port and memory addresses you guys are using? It might help avoid conflicts...
g.

of course. ralf is bookmarked on every machine i have.
that doesn't help with other option roms from other hardware vendors though. like our card, they may be configured to decode over a wide range of locations in memory and IO, and there's no way of knowing what's free without first examining the system and looking. This is entirely why Plug-n-Play was introduced.

It'll be really easy to create a quick-n-dirty program to scan through IO and memory and find an appropriate location for our card to be, and then display on the screen in high-definition ASCII characters how to configure the dip switches on our card before you actually plug the card in.

Advanced users may skip this step, but then you're on your own. I'm not giving out my number for tech support, despite what mike brutman may believe.

 

[hargle]

Does the Acculogic IDE 8 Bit Card support DMA?

No. I can't actually even see where it's supporting an IRQ, even though it claims it does.

I don't know of any 8bit DMA capable cards other than a soundblaster.
Maybe a SCSI controller?

 

[hargle]

Regarding performance, almost all the development so far has been on just basic functionality. I believe that once the design settles and everything works that the transfer speed will improve somewhat. There are things like loop unrolling, etc which can boost transfer rates. However its premature to deal with that now.

indeed.
compatibility and stability over performance right now. I've documented a half dozen things in the BIOS source that we can do to improve performance all around, and I really look forward to putting some of these improvements to work once the main testing is done and the BIOS is stable. (which I think it pretty much is already)

Mike, please post your quick-n-dirty benchmark, and shortly we'll look into implementing some improvements and we'll see where we can get it.

I'd also love to see some comparisons between us and MFM and even SCSI.

 

[geneb]

Thanks for the clarification Hargle. I'm dying to get one of those cards. I've already got my 5170 running off of a 1GB CF card as well as my Amiga 2000. I'd love to be able to use the 5160 the same way. The original 10MB MFM drive ain't gonna last forever.

Awesome work guys!

g.

 

[hargle]

well, I just happen to be about to start the build process on 2 more of them in about 30 minutes time....

We had 10 cards, and only half as many tester volunteers who could help out with the debug work. The other cards could certainly go up on the auction block to help pay for the development costs of the whole project.

These early proto cards aren't going to be as sexy as the final product, but it could be your chance to own a signed and numbered, extremely limited edition, first edition piece of computer history.

operators are standing by...

(I'm serious, I think I will have 3 or 4 cards that could go up for sale. PM me)

 

[NobodyIsHere]

Hi! I agree. With the latest test results I think we are probably past the big hump on the PCB prototype. We need some testers who are going to beat on this design and drive out the bugs. I mean some ruthless beat down testing. If there are people willing to test lets have a go at it and get as much value out of these initial test units as possible.

Thanks and have a nice day!

Andrew Lynch

 

[Lutiana]

Andrew, I notice your latest circuit design your description for JP1 and JP2 is not as clear as before (looks like some text was removed).

I think that's perfect. Plenty of room. Heck, even moving it around using only 3 bits and having the 4th be a ROM enable/disable would be fine.

I think this is a great idea. You'd have a 8 switch dip, switch 1 to 4 are for IO address, switch 5 is BIOS on/off and switches 6 - 9 are for BIOS memory address. This simplifies the table of values quite a bit, and give plenty of options for the BIOS memory range (7). It also cuts out a jumper (JP1?), but leaves the IRQ selection and write enabled settings in jumper form.

I think we (per?) could write a little utility that scans IO space looking for unused IO in the above ranges, and then also scans for an 8k chunk of ROM space to use, and then prints out to the screen a good dip switch setting display. Users could run that software before putting the card in.

I think this is a great piece of software to have in general for non-plug and play systems.

Yes, the plain PIO approach has its benefits! The production board will support a range of IRQs (see the N8VEM wiki) so when the time comes for software support of IRQs the board can do it.

I've looked into DMA but so far no luck. That really raises the bar on complexity. Having a working example of a simple DMA device would help but I think it would drive pretty massive changes to the design.

Why do you need DMA support or IRQ support? Would these merely improve performance and throughput or are there are capabilities these bring to the table?

If you would, see if you can get the XT-IDE to share the PC with a MFM/RLL style ST-412/ST-506 controller preferrably with its own BIOS. In my testing there seems to be a problem someplace regarding the XT-IDE and my other XT disk controllers with BIOS (FDC and MFM HD).

What would be a great add to this card would be a FDC Bios, to allow for high density 5.25 and 3.5 disk drives. But lets save that for Revision 3 of the final card (if it is even possible) :D

This is coming along nicely, the design is definitely getting ironed out well, though it looks to be pretty stable for how early on in the project it is. Great job guys.

 

[geneb]

Unfortunately, I don't have the time to really do a debug process justice.

g.

 

[mbbrutman]

Hi! I agree. With the latest test results I think we are probably past the big hump on the PCB prototype. We need some testers who are going to beat on this design and drive out the bugs. I mean some ruthless beat down testing. If there are people willing to test lets have a go at it and get as much value out of these initial test units as possible.

Thanks and have a nice day!

Andrew Lynch

The burning has already begun. My smaller drives (2GB and 6GB) are problematic - Hargle and I are debugging.


Mike