PDA

View Full Version : 8-Bit IDE Controller



Pages : 1 2 3 [4] 5 6

per
June 4th, 2009, 03:07 PM
i know DOS 7 will do it, but is it able to load on an 8088?

Nope.

Maybe Free-DOS is able to do it? But I've never tested free-dos on an 8088, so I don't know if that'll work either.

Mike Chambers
June 4th, 2009, 03:19 PM
Nope.

Maybe Free-DOS is able to do it? But I've never tested free-dos on an 8088, so I don't know if that'll work either.

i've tried that before, freedos absolutely will not work on an 8088. also, i just edited my previous post right about as you responded... take a look at some issues i'm experiencing.

hargle
June 5th, 2009, 05:56 AM
EDIT: there actually seem to be some issues. a couple times after executing a program the system has either started blinking strangely on the screen, or started spewing garbage data to the monitor. the only solution in either case is to reboot. also, i just tried installing arachne from ARCHN170.EXE (a known working copy a FTP'd over to the XT) and after a few minutes of extracting files okay, it came up with a CRC errors in archive dialog box and locked. i suppose i'll try on a larger drive and see if the problems continue.


sounds like a data corruption issue.

this is something I haven't done yet:
1) on a modern machine, make a drive with 2 partitions. leave 1 partition blank, and copy 10-50MB of data over to the 2nd parition.

2) install that drive on the XTIDE and copy the data from 1 partition to the blank one. (I'd use xcopy over copy, since it should attempt to do larger transfers in each pass. Maybe try it with both copy and xcopy)

3) fc /b the files to see if they are copied properly. You may want to do this back on the modern machine for speed and possibly even better accuracy, maybe both on the xtide and on a modern machine.

An alternate would be do this from drive to drive (having 2 drives on the XTIDE) and then moving both back to the modern machine to do the compare.


The big issue I fixed in 008 BIOS was that when running on my 486, with an old hard drive, I was trying to read multi-sector transfers faster than the drive was able to provide the data, so it corrupted after the 3rd sector. I figured we'd never have this problem on an XT with a new hard drive, but Per witnessed essentially the same issue with his slow computer and fast drive. The issue should be fixed with both reads and writes now, but ya never know.


I'll be performing similar tests this weekend.

If there are file compare differences, please post the model # of the drive and a sample of the data that miscompared.

per
June 5th, 2009, 06:41 AM
sounds like a data corruption issue.

this is something I haven't done yet:
1) on a modern machine, make a drive with 2 partitions. leave 1 partition blank, and copy 10-50MB of data over to the 2nd parition.

2) install that drive on the XTIDE and copy the data from 1 partition to the blank one. (I'd use xcopy over copy, since it should attempt to do larger transfers in each pass. Maybe try it with both copy and xcopy)

3) fc /b the files to see if they are copied properly. You may want to do this back on the modern machine for speed and possibly even better accuracy, maybe both on the xtide and on a modern machine.

An alternate would be do this from drive to drive (having 2 drives on the XTIDE) and then moving both back to the modern machine to do the compare.


The big issue I fixed in 008 BIOS was that when running on my 486, with an old hard drive, I was trying to read multi-sector transfers faster than the drive was able to provide the data, so it corrupted after the 3rd sector. I figured we'd never have this problem on an XT with a new hard drive, but Per witnessed essentially the same issue with his slow computer and fast drive. The issue should be fixed with both reads and writes now, but ya never know.


I'll be performing similar tests this weekend.

If there are file compare differences, please post the model # of the drive and a sample of the data that miscompared.

Hey, wait a moment, I'm also having some of those issues with minor data-corruption. However, it can also be signal-noise so I'm not sure...

hargle
June 5th, 2009, 07:23 AM
Hey, wait a moment, I'm also having some of those issues with minor data-corruption. However, it can also be signal-noise so I'm not sure...

ok, let's get these issues hammered out. they are unacceptable.

1st, use an 80 pin cable. the extra ground wires should help with any outside noise being introduced. they shouldn't be required on something this slow, but we need to eliminate all the variables we can.

2nd, do the same test I outlined for mike. Copy some data on a known good controller and then compare it on the XT. Keep a log of some of the corrupt data, and maybe we can find there's a pattern to it (like bit 5 is always low when the data fails) and we can hopefully start to focus on where the problem is.

Here's some rules to follow:

* if there's a byte/bit or two that have failed out of a sector, it is not going to be a BIOS issue.

* if a bit is failing repeatedly, like bit 5 is always low in a data miscompare, then it is very likely to be a soldering issue.

* if entire sectors are corrupt, then it could very well be a BIOS issue.

* if it's totally random, like a byte is duplicated when it shouldn't be, or there's no pattern to failing bits, then it could be an IC timing issue between parts. This is especially true if you do the same compare test again, and it fails in a different location. Something like that will likely need a logic analyzer to figure out. (i can do this at my work)

We also need to figure out if the read is failing or the write. THat's why I'm suggesting you write the data on a modern machine and compare it on the XTIDE, and vice versa.

Please log your results, including the model # of the drive on the wiki debugging logs, unless mike b. has any other suggestions.

NobodyIsHere
June 5th, 2009, 08:52 AM
Hi! There are many possibilities for data corruption to sneak into the circuit. I recommend thorough inspection of the solder joints to ensure no cold joints are present. Use your soldering iron to melt/remelt all joints and wick away any excess solder.

Make sure the latches are 74F573's rather than 74ls574's because the F series TTL has better drive performance. Also use the 80 conductor cable that Hargle suggests.

Thanks and have a nice day!

Andrew Lynch

Mike Chambers
June 5th, 2009, 01:47 PM
sounds like a data corruption issue.

this is something I haven't done yet:
1) on a modern machine, make a drive with 2 partitions. leave 1 partition blank, and copy 10-50MB of data over to the 2nd parition.

2) install that drive on the XTIDE and copy the data from 1 partition to the blank one. (I'd use xcopy over copy, since it should attempt to do larger transfers in each pass. Maybe try it with both copy and xcopy)

3) fc /b the files to see if they are copied properly. You may want to do this back on the modern machine for speed and possibly even better accuracy, maybe both on the xtide and on a modern machine.

An alternate would be do this from drive to drive (having 2 drives on the XTIDE) and then moving both back to the modern machine to do the compare.


The big issue I fixed in 008 BIOS was that when running on my 486, with an old hard drive, I was trying to read multi-sector transfers faster than the drive was able to provide the data, so it corrupted after the 3rd sector. I figured we'd never have this problem on an XT with a new hard drive, but Per witnessed essentially the same issue with his slow computer and fast drive. The issue should be fixed with both reads and writes now, but ya never know.


I'll be performing similar tests this weekend.

If there are file compare differences, please post the model # of the drive and a sample of the data that miscompared.

i'll do this and let you know. i just put an 80-wire cable in there. first thing i'm doing is trying to install arachne again to see what happens. i was curious about the performance with a newer drive as compared to an ancient XT-style IDE i was using before. arachne uses disk swap for "memory" on machines with little RAM like these.

Mike Chambers
June 5th, 2009, 02:02 PM
hey, arachne installed fine with the 80-wire cable! early success! :)

how to see how it runs. this also means that when i FTP'd the install EXE over it wrote it to the drive just fine. the error was during reading while installing yesterday.

per
June 5th, 2009, 02:05 PM
hey, arachne installed fine with the 80-wire cable! early success! :)

how to see how it runs. this also means that when i FTP'd the install EXE over it wrote it to the drive just fine. the error was during reading while installing yesterday.

May be a noise-problem on your side too.

Do you have your drive/cable close to the powersupply?

Mike Chambers
June 5th, 2009, 07:12 PM
May be a noise-problem on your side too.

Do you have your drive/cable close to the powersupply?

well the drive sits about 4 inches away from the PSU... the cable isn't much closer than that at any point.

Druid6900
June 6th, 2009, 08:24 PM
Guess the cards ran out before my offer to test one in a real world XT test bed.

mbbrutman
June 6th, 2009, 08:50 PM
The XT part is covered - I'm running in a genuine original machine. But we do need a lot of testing and some focus on it.

Hargle and I are coordinating at least ...

Druid6900
June 7th, 2009, 07:18 PM
I only offered because I have about 100 8-bit cards that I will be testing in the unit over the next little while and it would be a good way to see if the IDE controller chokes with any of them.

Normally, I wouldn't have time to test something like that, but, with, as I said, all the boards I'll be running through it (not to mention that it'll have to co-exist with various MFM/RLL controllers) I thought it might be a unique opportunity.

hargle
June 8th, 2009, 05:33 AM
I only offered because I have about 100 8-bit cards that I will be testing in the unit over the next little while and it would be a good way to see if the IDE controller chokes with any of them.

Normally, I wouldn't have time to test something like that, but, with, as I said, all the boards I'll be running through it (not to mention that it'll have to co-exist with various MFM/RLL controllers) I thought it might be a unique opportunity.

I have 1 card left. It's yours if you want it, and I'll send you a PM in a bit.

Testing the card with other cards is one of the last things we need to try out, so I am interested in the outcome here, but this may introduce a lot more work on your end, because if something goes wrong, I am going to need a lot of debugging information to get to the bottom of it. I know you're super busy, so don't sign up for something you can't throw a few dozen hours into... (or be willing to send all the cards that don't work with it to me)

hargle
June 8th, 2009, 05:56 AM
Big weekend in XTIDE land here.

1) got into the lab at work and took my two cards that had flaky IO (bits dropped, missing characters during POST ID, etc) and reflowed all the solder joints on them. Both came out successful! That took nearly 5 minutes of work to fix both cards. whew.

2) on one of the cards, I cut out the resistor at R6 and attached a single jumper header between CSEL (pin 28 ) and the ground next to it (Pin 30) on the back side of the IDE header. Low and behold, with a single drive jumpered as CS and attached at the end of the cable, it showed up in POST at the correct position. Attaching 2 CS jumpered drives, both showed up properly. I really think the next spin of the board, CS should be grounded and left that way. I don't think we need a 3 position jumper at all. I couldn't find a drive that didn't work properly with CSEL grounded.

3) did a pretty major overhaul of the BIOS, and came out with a ROM that supports multiple XTIDE cards now. (up to 4 of them!) This may seem superfluous, but it was actually a side effect of trying to get the card to play well with other controllers in the system. I hooked up 2 cards with 3 drives total on my test machine. fdisk saw all 3 drives, and I could copy files between them. Pretty cool.

4) did a little optimizing to the code. Didn't really see any speed improvements, but I don't have a good benchmark program anyway.

5) fixed a bug with sector reads: it was trashing SI on reads, and that's what was causing coretest to fail. coretest still doesn't operate properly, but at least it runs.

6) fixed the same multi-sector bug for enhanced INT 13 reads/writes as I had with normal reads/writes. no idea why I didn't think about fixing them both at the same time.

I'm hoping to have this new BIOS released tomorrow officially. I ran out of time trying to get everything in place and tested, so I need another day or two before letting it into the wild. I would not be surprised if other bugs crept in while making this big series of changes.

mbbrutman
June 8th, 2009, 06:23 AM
I only offered because I have about 100 8-bit cards that I will be testing in the unit over the next little while and it would be a good way to see if the IDE controller chokes with any of them.

Normally, I wouldn't have time to test something like that, but, with, as I said, all the boards I'll be running through it (not to mention that it'll have to co-exist with various MFM/RLL controllers) I thought it might be a unique opportunity.

I can see where co-existence might be interesting, but really the only other way another card can screw this up is if it is using the I/O ports used by the XTIDE card. There are no IRQs or DMA involved, so they can't cause conflicts.

If you really stretch far and the XTIDE card is not handling the bus cycle correctly, then you could see problems with other cards. But I think that will be fleshed out pretty quickly with just the video card, serial or parallel card.

It's not something I would put a high priority on. I would lean more toward testing a variety of drives and ensuring that we are not seeing data corruption. The drive tests should be comprehensive - if the drive has x number of sectors, the XTIDE card had better be able to see that and be able to touch them all.


Mike

hargle
June 8th, 2009, 07:43 AM
I can see where co-existence might be interesting, but really the only other way another card can screw this up is if it is using the I/O ports used by the XTIDE card. There are no IRQs or DMA involved, so they can't cause conflicts.


we (at least I) meant more along the lines of incompatibility with other devices which hook INT 19.

per
June 8th, 2009, 08:15 AM
we (at least I) meant more along the lines of incompatibility with other devices which hook INT 19.
We're at least talking about non-standard adapters that doesn't provide standard Int 13h routines.

I don't think there will be much problems, except if there is two drives with the same ID. That would be easy to fix, since all we have to do is to figure how many drives installed on initialazion, we also need our BIOS to be run last, because we can't be sure the other card's BIOS does that.

Mike Chambers
June 8th, 2009, 12:05 PM
Big weekend in XTIDE land here.

1) got into the lab at work and took my two cards that had flaky IO (bits dropped, missing characters during POST ID, etc) and reflowed all the solder joints on them. Both came out successful! That took nearly 5 minutes of work to fix both cards. whew.

2) on one of the cards, I cut out the resistor at R6 and attached a single jumper header between CSEL (pin 28 ) and the ground next to it (Pin 30) on the back side of the IDE header. Low and behold, with a single drive jumpered as CS and attached at the end of the cable, it showed up in POST at the correct position. Attaching 2 CS jumpered drives, both showed up properly. I really think the next spin of the board, CS should be grounded and left that way. I don't think we need a 3 position jumper at all. I couldn't find a drive that didn't work properly with CSEL grounded.

3) did a pretty major overhaul of the BIOS, and came out with a ROM that supports multiple XTIDE cards now. (up to 4 of them!) This may seem superfluous, but it was actually a side effect of trying to get the card to play well with other controllers in the system. I hooked up 2 cards with 3 drives total on my test machine. fdisk saw all 3 drives, and I could copy files between them. Pretty cool.

4) did a little optimizing to the code. Didn't really see any speed improvements, but I don't have a good benchmark program anyway.

5) fixed a bug with sector reads: it was trashing SI on reads, and that's what was causing coretest to fail. coretest still doesn't operate properly, but at least it runs.

6) fixed the same multi-sector bug for enhanced INT 13 reads/writes as I had with normal reads/writes. no idea why I didn't think about fixing them both at the same time.

I'm hoping to have this new BIOS released tomorrow officially. I ran out of time trying to get everything in place and tested, so I need another day or two before letting it into the wild. I would not be surprised if other bugs crept in while making this big series of changes.

excellent. looking forward to the new BIOS. just to keep you in the loop, i still haven't had one single issue with the card after switching to an 80-conductor IDE cable. i've been using it constantly too.

i've been running EZNOS 2 HTTP/FTP server on it, and i've been exercising it quite a bit via that.

hargle
June 8th, 2009, 12:17 PM
excellent. looking forward to the new BIOS. just to keep you in the loop, i still haven't had one single issue with the card after switching to an 80-conductor IDE cable. i've been using it constantly too.


i find it interesting that we need 80pin cables to be reliable. the transfer speeds are so slow, it shouldn't be required. 80pin cables were introduced for ultra DMA mode 3 speeds, and with our PIO mode 0 transfers, we're about as far away from that as you can get. Is the XT really that noisy? Why doesn't floppy or RLL/MFM controllers need special cables? Why doesn't the acculogic card need 80pin cables?

This is likely more of a non issue than anything. everyone should have at least one 80pin cable lying around since they are so common, but it seems fishy to me. Perhaps it's the "F" series parts that are so fast (even though the data transfer itself is slow)?

per
June 8th, 2009, 12:32 PM
i find it interesting that we need 80pin cables to be reliable. the transfer speeds are so slow, it shouldn't be required. 80pin cables were introduced for ultra DMA mode 3 speeds, and with our PIO mode 0 transfers, we're about as far away from that as you can get. Is the XT really that noisy? Why doesn't floppy or RLL/MFM controllers need special cables? Why doesn't the acculogic card need 80pin cables?

This is likely more of a non issue than anything. everyone should have at least one 80pin cable lying around since they are so common, but it seems fishy to me. Perhaps it's the "F" series parts that are so fast (even though the data transfer itself is slow)?

Does it say anything that the XT has an awfull lot of signals changing about everywhere on the system-board at any time? Modern computer got all that inside chipsets, and operates at 3.3v instead of 5v. I don't remember how many ameres the XT's system board actually uses, but it's quite a lot for it's time.

Maybe MFM drives use more current than IDE drives?

mbbrutman
June 8th, 2009, 12:35 PM
i find it interesting that we need 80pin cables to be reliable. the transfer speeds are so slow, it shouldn't be required. 80pin cables were introduced for ultra DMA mode 3 speeds, and with our PIO mode 0 transfers, we're about as far away from that as you can get. Is the XT really that noisy? Why doesn't floppy or RLL/MFM controllers need special cables? Why doesn't the acculogic card need 80pin cables?

This is likely more of a non issue than anything. everyone should have at least one 80pin cable lying around since they are so common, but it seems fishy to me. Perhaps it's the "F" series parts that are so fast (even though the data transfer itself is slow)?

We should not need the 80 pin cables. But they are a good diagnostic tool. If something clears up with the 80 pin cable and goes bad with a standard 40 pin cable, it's an electrical issue not a BIOS bug.

Remember, people built homebrew system bus extensions using ribbon cables back in the XT era. We should not be having noise problems with normal cables. Something else is dodgy here. I just wish I had a good local source for parts.

Mike Chambers
June 8th, 2009, 12:39 PM
i find it interesting that we need 80pin cables to be reliable. the transfer speeds are so slow, it shouldn't be required. 80pin cables were introduced for ultra DMA mode 3 speeds, and with our PIO mode 0 transfers, we're about as far away from that as you can get. Is the XT really that noisy? Why doesn't floppy or RLL/MFM controllers need special cables? Why doesn't the acculogic card need 80pin cables?

This is likely more of a non issue than anything. everyone should have at least one 80pin cable lying around since they are so common, but it seems fishy to me. Perhaps it's the "F" series parts that are so fast (even though the data transfer itself is slow)?

i was thinking the same thing. just because the computer as a whole reads and writes data very slowly, it doesn't mean that the chips on the board itself are doing it slowly. the bottleneck is the ISA bus and CPU/RAM speed.

isn't there some way to get that atmel chip running at say, half it's normal speed? another thing i was thinking, was that perhaps the signal coming from the drive should be dampened slightly by a resistor or something? if the signals coming in are too strong, it'd be easier for the louder line noise to be interfering with the actual data that's supposed to be coming through.

i'm no electrical engineer so i may be way off base, but putting some weak resistors on all 16 data lines may just fix it.

lutiana
June 8th, 2009, 01:43 PM
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 agree with this, but I would add that we need a standerdized testing format for data aquisition. To that end I threw together the attached spreadsheet, its a start, but with it we can compile a very nice table of drives that do and don't work with the card for the wiki and can use it to narrow down any issues.

Let me know what you think of the sheet. I will gladly convert any completed sheets to a wiki table and post them on the wiki.

Druid6900
June 8th, 2009, 08:43 PM
I can see where co-existence might be interesting, but really the only other way another card can screw this up is if it is using the I/O ports used by the XTIDE card. There are no IRQs or DMA involved, so they can't cause conflicts.

If you really stretch far and the XTIDE card is not handling the bus cycle correctly, then you could see problems with other cards. But I think that will be fleshed out pretty quickly with just the video card, serial or parallel card.

It's not something I would put a high priority on. I would lean more toward testing a variety of drives and ensuring that we are not seeing data corruption. The drive tests should be comprehensive - if the drive has x number of sectors, the XTIDE card had better be able to see that and be able to touch them all.


Mike

Ok, well, I can see what you mean and therefore, it wouldn't really advance the research on the card's operation much at all, so, the last card might as well go to someone who is willing to duplicate the efforts of everyone else with the card.

I usually test all the IDE hard drives I have in stock (80MB to 250GB) on something more modern where I can test them 4 at a time.

mbbrutman
June 9th, 2009, 02:21 PM
Ok, well, I can see what you mean and therefore, it wouldn't really advance the research on the card's operation much at all, so, the last card might as well go to someone who is willing to duplicate the efforts of everyone else with the card.

I usually test all the IDE hard drives I have in stock (80MB to 250GB) on something more modern where I can test them 4 at a time.

That's your call, not mine. I merely pointed out the technical fallacy of testing with other unrelated cards.

Druid6900
June 9th, 2009, 07:45 PM
That's your call, not mine. I merely pointed out the technical fallacy of testing with other unrelated cards.

Not a problem.

If I can't provide a unique environment to test the card out in, then it doesn't matter who has the last card, does it?

I'm sure that the other people with the card will provide feedback that would be just as good as mine.

mbbrutman
June 9th, 2009, 08:16 PM
I think Hargle brings up a good point - testing with other cards that provide INT19 hooks is important. I'm not sure how many of your cards do this, but those would clearly be a case where you have a unique environment.

(SCSI cards with boot PROMs come to mind. Network cards that can network boot are also good targets, although these older machines rarely ever network booted.)

NobodyIsHere
June 10th, 2009, 03:21 AM
Hi! Hargle sent me a revised BIOS I'll be testing here soon -- hopefully tonight. I think that will shed light on the int19 hooking issue which I believe is the root issue of booting with different cards with bootable ROMs. My system has two bootable cards, one MFM (Seagate, I think) and another of those funky FDC cards for HD floppy drives (JDR used to sell these).

I'll burn an EPROM of the new BIOS and give it a try. The last few days I've been busy on the N8VEM project with the VDU board. The good news is I've got the VDU board working and some decent video coming out now. It works pretty well and the software is coming along. Check out the photos. They are in the N8VEM wiki in the VDU folder. I still have a lot to do on it but now I can break off and do a bit of XT-IDE testing too.

Thanks and have a nice day!

Andrew Lynch

NobodyIsHere
June 10th, 2009, 04:00 AM
Oh yeah, I forgot to mention. Those testing the board might like to do some "up close and personal" inspection of the board using an oscilloscope/spectrum analyzer. There may be noise sources causing issues. Certainly, there are many bypass capacitors, an isolation capacitor, ground planes and the like but its still possible there is something flakey in the design. However, the problems so far seem to be rather specific to individual systems.

I have some Vector ISA bus extender boards to raise the boards above the bus for easy inspection. If anyone needs one (unlikely but I'm offering) you can use one of these units to help inspect the board. I haven't seen anything in particular on my boards. The manufactured PCB seems as solid as rock and the wire wrap board somewhat less so. Of course, I don't have very exotic equipment so its possible there are other factors at play I am not seeing.

Thanks and have a nice day!

Andrew Lynch

hargle
June 10th, 2009, 06:19 AM
Hi! Hargle sent me a revised BIOS I'll be testing here soon -- hopefully tonight. I think that will shed light on the int19 hooking issue which I believe is the root issue of booting with different cards with bootable ROMs. My system has two bootable cards, one MFM (Seagate, I think) and another of those funky FDC cards for HD floppy drives (JDR used to sell these).


i'm still immersed in working that aspect of the BIOS. I haven't tried the card out yet with my own MFM controller in the machine, so don't expect a lot of miracles just yet. I do plan on spending some more time with the BIOS this weekend, so hang in there! (sorry I keep delaying my release of 009, but I think it'll be worth it)

As Per has suggested, the best way to get the system to boot is to make sure the xtide loads its BIOS in last. You can freely move the ROM address around to make sure it gets the highest address above the other cards. If you move the IO address, you will need to use the flash setup program.



Oh yeah, I forgot to mention. Those testing the board might like to do some "up close and personal" inspection of the board using an oscilloscope/spectrum analyzer. There may be noise sources causing issues. Certainly, there are many bypass capacitors, an isolation capacitor, ground planes and the like but its still possible there is something flakey in the design. However, the problems so far seem to be rather specific to individual systems.


I think this is something that mike and I can do at my workplace some weekend. If he can spare the time to come up to minneapolis, we can pop into my work and hook up the logic analyzer we have here and start getting some captures of some signals. I first want to find a drive or two that absolutely won't work properly with our card (lutiana seems to have one) and then we can start to investigate. The new BIOS might change the outcome of the list of drives that are failing, although I kinda doubt it.

Those failing drives will have to be shipped here for us to test with.
I'll see if I can get one of my hardware co-workers to help out as well. Otherwise we might have to fly andrew in to help out. :)

per
June 10th, 2009, 07:45 AM
I think this is something that mike and I can do at my workplace some weekend. If he can spare the time to come up to minneapolis, we can pop into my work and hook up the logic analyzer we have here and start getting some captures of some signals. I first want to find a drive or two that absolutely won't work properly with our card (lutiana seems to have one) and then we can start to investigate. The new BIOS might change the outcome of the list of drives that are failing, although I kinda doubt it.

Those failing drives will have to be shipped here for us to test with.
I'll see if I can get one of my hardware co-workers to help out as well. Otherwise we might have to fly andrew in to help out. :)

I'll see if I can borrow my uncle's scope this weekend so I can test for signal noise. It seems like it only appears when I have the drive above the 3.5" floppy drive where the cable passes inbetween the 5.25" FDD and the PSU, then over the "system" part of the motherboard.

I've not had any corrupted reads when placing the drive outside to the left of my XT, where the cable goes in a bow-shape over the other expansion cards I have installed.

Maybe most IDE drives are using (weak) 74HCTxx logics to send data to the card?

lutiana
June 10th, 2009, 10:07 AM
I first want to find a drive or two that absolutely won't work properly with our card (lutiana seems to have one) and then we can start to investigate. The new BIOS might change the outcome of the list of drives that are failing, although I kinda doubt it.


I can ship it to you, though I have not had chance to test it with any of the newer bioses. Last one was 006, and it was still coming up as a slave drive.

I will try and test it again this evening with 008 and see if it still comes up as slave, and even so, if I can fdisk and format it.

NobodyIsHere
June 10th, 2009, 11:08 AM
Just a thought... If Hargle was able to resolve intermittent problems with two of his boards by doing a solder reflow (I presume with an soldering oven or wave solder machine), it may indicate the presence of hidden cold joints in the soldering of your PCB as well. Sometimes cold joints can act like diodes when they oxidize, etc. Flexing the board, moving cables can affect its operation.

Who made your board? Did you solder it yourself? If so, I would take the board, remove all the ICs, and use your soldering iron and wick to reflow all the joints. Remove all excess solder with your wick and remelt all joints. The key is to get as much unnecessary solder as possible off the joint and remove anything that would impede a thoroughly heated PTH and pin. That's why I'd remove the ICs to prevent damage.

Its possible that dodgy solder joints can contribute to noisy connections that would not appear with other boards. Itermittant problems like you are experiencing (I think) sound awfully suspicious.

Thanks and have a nice day!

Andrew Lynch

per
June 10th, 2009, 11:15 AM
Just a thought... If Hargle was able to resolve intermittent problems with two of his boards by doing a solder reflow (I presume with an soldering oven or wave solder machine), it may indicate the presence of hidden cold joints in the soldering of your PCB as well. Sometimes cold joints can act like diodes when they oxidize, etc. Flexing the board, moving cables can affect its operation.

Who made your board? Did you solder it yourself? If so, I would take the board, remove all the ICs, and use your soldering iron and wick to reflow all the joints. Remove all excess solder with your wick and remelt all joints. The key is to get as much unnecessary solder as possible off the joint and remove anything that would impede a thoroughly heated PTH and pin. That's why I'd remove the ICs to prevent damage.

Its possible that dodgy solder joints can contribute to noisy connections that would not appear with other boards. Itermittant problems like you are experiencing (I think) sound awfully suspicious.

Thanks and have a nice day!

Andrew Lynch
The card I have was soldered by Hargle.

There isn't really much unnessecary solder on the joints on my card, more the opposite. I would say it is to little solder, at leas if I compare it to all other cards I got.

hargle
June 10th, 2009, 11:27 AM
I can ship it to you, though I have not had chance to test it with any of the newer bioses. Last one was 006, and it was still coming up as a slave drive.

I will try and test it again this evening with 008 and see if it still comes up as slave, and even so, if I can fdisk and format it.

That seems like the CSEL issue that I was playing with over the weekend.
If you've got a soldering iron handy, I can step you through the process of pulling CSEL low. It was pretty easy to do.

that fixed my drives showing up as slaves issue 100%.

hargle
June 10th, 2009, 11:34 AM
The card I have was soldered by Hargle.

There isn't really much unnessecary solder on the joints on my card, more the opposite. I would say it is to little solder, at leas if I compare it to all other cards I got.

resoldering is quick and easy and couldn't hurt to try.

All I did was reflow the solder under all the pins of the sockets, minus the one for the eeprom, since that was working fine. I didn't touch the resistors, caps or the dipswitches, and my two cards have been rock solid since. For me, all I did was use the tip of the iron and pressed it against each leg of the socket until the leg moved. Took about 1 second per leg. That forced the solder to re-seat itself inside the hole.

All in all, I soldered 8 of the 10 cards, and only had 2 flaky ones. not too bad for a software guy, although if Per's card gets fixed with this method, my stats will drop again. ;)

per
June 10th, 2009, 11:56 AM
resoldering is quick and easy and couldn't hurt to try.

All I did was reflow the solder under all the pins of the sockets, minus the one for the eeprom, since that was working fine. I didn't touch the resistors, caps or the dipswitches, and my two cards have been rock solid since. For me, all I did was use the tip of the iron and pressed it against each leg of the socket until the leg moved. Took about 1 second per leg. That forced the solder to re-seat itself inside the hole.

All in all, I soldered 8 of the 10 cards, and only had 2 flaky ones. not too bad for a software guy, although if Per's card gets fixed with this method, my stats will drop again. ;)

My soldering iron is one of those big and clumsy old-style ones with a temperature regulator I can't trust (sometimes it just won't melt the sloder).

Maybe my uncle got one I can borrow. I got an old ISA card I sould reflow too, it has started to corrode (small white hairs on the solder) on some of the pins.

NobodyIsHere
June 10th, 2009, 12:03 PM
That seems like the CSEL issue that I was playing with over the weekend.
If you've got a soldering iron handy, I can step you through the process of pulling CSEL low. It was pretty easy to do.

that fixed my drives showing up as slaves issue 100%.

There is a pull up resistor on CSEL so if you want just solder a jumper between CSEL and ground. The pull up resistor will limit current to very small amount. Alternatively, remove the resistor and just ground CSEL directly.

Thanks and have a nice day!

Andrew Lynch

NobodyIsHere
June 10th, 2009, 12:07 PM
resoldering is quick and easy and couldn't hurt to try.

All I did was reflow the solder under all the pins of the sockets, minus the one for the eeprom, since that was working fine. I didn't touch the resistors, caps or the dipswitches, and my two cards have been rock solid since. For me, all I did was use the tip of the iron and pressed it against each leg of the socket until the leg moved. Took about 1 second per leg. That forced the solder to re-seat itself inside the hole.

All in all, I soldered 8 of the 10 cards, and only had 2 flaky ones. not too bad for a software guy, although if Per's card gets fixed with this method, my stats will drop again. ;)

Yes, that's exactly what I am suggesting. That heating and wiggling of the pins forces the solder to reflow and remelt. You'll virtually eliminate cold joints that way. Some solder joints that look OK can actually be bad underneath. Sometimes you can tell and sometimes not. That's why I always remelt/reflow solder joints to verify that they are thoroughly connected. Sometimes a touch of flux to questionable areas or if you suspect contamination.

I am not trying to be critical, just connecting the dots and trying to fix the problems as locally as possible. Getting reliable hardware is a big part of getting the software solution right.

Thanks and have a nice day!

Andrew Lynch

lutiana
June 10th, 2009, 12:29 PM
There is a pull up resistor on CSEL so if you want just solder a jumper between CSEL and ground. The pull up resistor will limit current to very small amount. Alternatively, remove the resistor and just ground CSEL directly.

Thanks and have a nice day!

Andrew Lynch

My biggest hesitation is that I am simply not that proficient with a soldering iron yet. The solder joints that Hargle has done are well beyond my ability at the moment.

If I am understaning you correctly I could simply bypass the resistor by using a small piece of wire to test it temporarily. Is that correct?

hargle
June 10th, 2009, 12:41 PM
My biggest hesitation is that I am simply not that proficient with a soldering iron yet. The solder joints that Hargle has done are well beyond my ability at the moment.

wow! and I don't think i'm that good at all! that's very kind of you. :)
I think I've found my method since I did Per's card though. (sorry per!)


If I am understaning you correctly I could simply bypass the resistor by using a small piece of wire to test it temporarily. Is that correct?

just about. R6 has to be cut to break the connection to the pull-up. THen you just jumper a tiny wire between 2 pins on the IDE connector on the back side of the card.

I can send you detailed pics of exactly what the process is. Actually, I should post the pictures so that anyone else can try it too. Will try to do that tonight.

NobodyIsHere
June 10th, 2009, 03:24 PM
My biggest hesitation is that I am simply not that proficient with a soldering iron yet. The solder joints that Hargle has done are well beyond my ability at the moment.

If I am understaning you correctly I could simply bypass the resistor by using a small piece of wire to test it temporarily. Is that correct?

Hi! If you want you can send me the board and I'll reflow it for you.

It is important to not just replace or bypass the pull up resistor with a jumper. The resistor is there to limit current flow and wire will not do that. A plain wire would short VCC to GND and the power supply will not come up.

Actually, you can just leave the resistor in place. Just connect the CSEL pin to ground and the pull up resistor will be OK as is.

Thanks and have a nice day!

Andrew Lynch

hargle
June 10th, 2009, 04:22 PM
here's a picture of what I did to the csel line:

http://www.waste.org/~winkles/csel.jpg

I used a jumper header so I could enable/disable it at will. You could use anything to do the trick. It's an easy mod.

NobodyIsHere
June 10th, 2009, 04:59 PM
Hi Hargle! That's great! Pin 30 is GND so that's convenient!

Nice mod! Cool points for Hargle!

Thanks and have a nice day!

Andrew Lynch

Mike Chambers
June 10th, 2009, 05:52 PM
has anybody tried a CF card with an IDE adapter on these yet? i have a 256 MB kingston i am thinking of trying.

lutiana
June 10th, 2009, 08:10 PM
has anybody tried a CF card with an IDE adapter on these yet? i have a 256 MB kingston i am thinking of trying.

Yes, a 1gb card. Detected fine, but had to format it with a third party (DOS Format kept finding a ton of bad sectors). It booted fine. That was with version 005 of the BIOS, haven't tried it since.

mbbrutman
June 10th, 2009, 08:47 PM
I've had a rockin' night of debug.

First, I redid every solder joint on the card. That was tedious and I can't say it looks much better, but there were some spots that definitely needed help.

No joy though. I have two drives which consistently give me problems and they both were still goofy.

Next I went to an 80 pin IDE cable. This really should not be necessary, but it definitely helps. Both of my problem drives are not usable. I'm not sure about long term stability - I'll need a few hours to ascertain that.

One of the drives would fdisk, format and I could copy data to it, but I could not boot from it. I thought that I had been wiping the master boot record using debug, but I must not have been doing it right. FDISK /MBR from DOS 5 fixed the problem and I can now boot straight from the drive.

So long story short - the two drives that were giving me grief are working now, and it looks like the older 40 pin cable was the cause of the grief. This will be a good thing to look at under a scope because those 40 pin cables should be fine for this application. There has to be something on the card that is marginal that the cable is helping out with.


Mike

per
June 10th, 2009, 10:05 PM
Yes, a 1gb card. Detected fine, but had to format it with a third party (DOS Format kept finding a ton of bad sectors). It booted fine. That was with version 005 of the BIOS, haven't tried it since.

Those problems was fixed in BIOS version 0.08. I suggest you update since there has been a lot of bugfixes and additions since then.

However, remember to use the /s switch when flashing in the new version, else, you'll get some insane settings. After you have updated to 0.08, you don't need to use the /s switch when updating to versions after 0.08.

NobodyIsHere
June 11th, 2009, 03:18 AM
I've had a rockin' night of debug.

First, I redid every solder joint on the card. That was tedious and I can't say it looks much better, but there were some spots that definitely needed help.

No joy though. I have two drives which consistently give me problems and they both were still goofy.

Next I went to an 80 pin IDE cable. This really should not be necessary, but it definitely helps. Both of my problem drives are not usable. I'm not sure about long term stability - I'll need a few hours to ascertain that.

One of the drives would fdisk, format and I could copy data to it, but I could not boot from it. I thought that I had been wiping the master boot record using debug, but I must not have been doing it right. FDISK /MBR from DOS 5 fixed the problem and I can now boot straight from the drive.

So long story short - the two drives that were giving me grief are working now, and it looks like the older 40 pin cable was the cause of the grief. This will be a good thing to look at under a scope because those 40 pin cables should be fine for this application. There has to be something on the card that is marginal that the cable is helping out with.


Mike

Hi Mike! Thanks! If the 80 conductor IDE cable helps it almost certainly means a noise (aka grounding) issue. As I am sure you already know but for the benefit of everyone, the difference between the two styles of cables is that the 80 conductor version has separate grounds for each pin versus common grounds on the 40 conductor cable. Probably the best solution would be a spectrum analyser, logic analyser, or really good storage oscilloscope to capture the offending events.

Bearing the above in mind, few modern IDE devices (in the last 10 years or so) probably few if any have much testing in XT ISA style bus. Most recent IDE devices are intended for PCI bus like environments which have significantly different noise, grounding characteristics, etc.

That being said, there are likely drives that will not be compatible with the interface. That is true for *all* IDE interfaces AFAIK. There is a huge variety of IDE devices available and if you include the early models (late 1980's) all the way to present times you will see an enormous amount of variations. No matter how you implement the IDE interface, you are making decisions which affect timing and any way you go, you are deciding some will be compatible and some will not.

My suggestion is to proceed with the investigation and see if you can determine a root cause. If its fixable I'll roll it in the design and put it in the respin. This is the investigation that we've needed since the beginning and I am very happy its underway at last!

Realistically, even after thorough investigation and repairs there will likely be some devices that just won't work. My suggestion is to use the wiki to capture what devices DO work and possible those devices that DO NOT work. The data might reveal clues and your improved testing data collection is an excellent idea.

I know it did on the N8VEM Disk IO board and we ended up with a "smart cable" to fix some timing issues with drives from certain manufacturers like WD etc.

Thanks and have a nice day!

Andrew Lynch

per
June 11th, 2009, 04:31 AM
Hi Mike! Thanks! If the 80 conductor IDE cable helps it almost certainly means a noise (aka grounding) issue. As I am sure you already know but for the benefit of everyone, the difference between the two styles of cables is that the 80 conductor version has separate grounds for each pin versus common grounds on the 40 conductor cable. Probably the best solution would be a spectrum analyser, logic analyser, or really good storage oscilloscope to capture the offending events.

Bearing the above in mind, few modern IDE devices (in the last 10 years or so) probably few if any have much testing in XT ISA style bus. Most recent IDE devices are intended for PCI bus like environments which have significantly different noise, grounding characteristics, etc.

That being said, there are likely drives that will not be compatible with the interface. That is true for *all* IDE interfaces AFAIK. There is a huge variety of IDE devices available and if you include the early models (late 1980's) all the way to present times you will see an enormous amount of variations. No matter how you implement the IDE interface, you are making decisions which affect timing and any way you go, you are deciding some will be compatible and some will not.

My suggestion is to proceed with the investigation and see if you can determine a root cause. If its fixable I'll roll it in the design and put it in the respin. This is the investigation that we've needed since the beginning and I am very happy its underway at last!

Realistically, even after thorough investigation and repairs there will likely be some devices that just won't work. My suggestion is to use the wiki to capture what devices DO work and possible those devices that DO NOT work. The data might reveal clues and your improved testing data collection is an excellent idea.

I know it did on the N8VEM Disk IO board and we ended up with a "smart cable" to fix some timing issues with drives from certain manufacturers like WD etc.

Thanks and have a nice day!

Andrew Lynch
I've now reflowed some of the worst-looking pins of my card (had to borrow my grand-dad's bulky soldering gun, something I'll never do again! It keeps the temperature high enough, but it's 10 times more difficult to handle because of it's tip-size). Especially pin 30 of the IDE connector was bad, it looked like the solder didn't even touch the PCB!

When I touched some of the pins, the solder just "dissapeard". I had to add new solder to all of those.

I'm now in the process of testing if there is improvements, and currently, it looks promising.

mbbrutman
June 11th, 2009, 05:33 AM
Hi Mike! Thanks! If the 80 conductor IDE cable helps it almost certainly means a noise (aka grounding) issue. As I am sure you already know but for the benefit of everyone, the difference between the two styles of cables is that the 80 conductor version has separate grounds for each pin versus common grounds on the 40 conductor cable. Probably the best solution would be a spectrum analyser, logic analyser, or really good storage oscilloscope to capture the offending events.

I have not studied the schematic, but I was thinking of the grounding issue when I mentioned using a scope to debug it. I'm confused though because I would have thought that having the pins with common grounds would have reduced/eliminated differing voltage potentials for those signals. The move to separate grounds was to support the higher transfer rates drives doing ATA-100. There is no way that we 'broke' the older style cable with our transfer rates, so there is probably something to be cleaned up on the card.

(The separate grounds on the 80 pin cables are a good thing for eliminating inductive capacitance between unrelated signals, but it's overkill for us.)



Bearing the above in mind, few modern IDE devices (in the last 10 years or so) probably few if any have much testing in XT ISA style bus. Most recent IDE devices are intended for PCI bus like environments which have significantly different noise, grounding characteristics, etc.

That being said, there are likely drives that will not be compatible with the interface. That is true for *all* IDE interfaces AFAIK. There is a huge variety of IDE devices available and if you include the early models (late 1980's) all the way to present times you will see an enormous amount of variations. No matter how you implement the IDE interface, you are making decisions which affect timing and any way you go, you are deciding some will be compatible and some will not.

I don't expect anything from before 1995 to be perfectly in spec. IDE drives had all sorts of problems with master/slave combinations due to sloppy implementation of the spec. It would not surprise me if other things were buggered and closely tied to the chipset they were connected to.


My suggestion is to proceed with the investigation and see if you can determine a root cause. If its fixable I'll roll it in the design and put it in the respin. This is the investigation that we've needed since the beginning and I am very happy its underway at last!

Realistically, even after thorough investigation and repairs there will likely be some devices that just won't work. My suggestion is to use the wiki to capture what devices DO work and possible those devices that DO NOT work. The data might reveal clues and your improved testing data collection is an excellent idea.

Happy to oblige. I wanted to get a first 'victory' post out last night because my experiences have been so trying up until about then. I will post a synopsis of my problems and suspected fixes in the Wiki and the specific drives that I used. (They did not all behave the same way.)


I know it did on the N8VEM Disk IO board and we ended up with a "smart cable" to fix some timing issues with drives from certain manufacturers like WD etc.

Thanks and have a nice day!

Andrew Lynch

per
June 11th, 2009, 06:08 AM
After some testing with my card recently (see earlier post), I have been able to copy the zipped installation files of Norton Utilities version 4.5 Adv. to the XT using our card and a IDE drive, unzip it without errors, moved the files to another place on the hard drive, moved the files back onto floppy disks, and install them without any errors.

I recomend everyone with noise-problems to inspect the joints of their card. I think that might have quite a lot to say about the cause.

I'll do some more writes/reads to make sure cold joints was the cause why my card was haunted by noise.

hargle
June 11th, 2009, 06:18 AM
Just to be realistic, we should also consider how much time we're going to spend on the debugging end of this project.

Consider:
a) we've all got 80 pin cables
b) we've all got at least a couple drives that work
c) we've all got real lives to live.

Out of the 12 or so drives I've tested in my machines, from 6 different manufacturers, I have zero drives that don't work. If, as suggested earlier, we start keeping a list of known working drives, I see no reason not to be totally happy delivering a product that works with a majority of the drives in the field.

I mean, if you can't find a drive that works on our card, you aren't trying very hard.

By all means, I would like to dig in and figure out why some of the flaky stuff is happening, but we also need to be realistic about how many hours we're going to burn fixing the last 5% of the drives out there that don't work.

As an engineer, I am of the personality type who will keep hammering on something until it's perfect, so it's unusual for me to have this viewpoint. Not sure what got into me today. ;)

Just keep that in the back of our minds...

hargle
June 11th, 2009, 06:21 AM
I recomend everyone with noise-problems to inspect the joints of their card. I think that might have quite a lot to say about the cause.


This is bittersweet news for me. Glad to hear that your card is working better, not so glad to hear that my soldering skills aren't up to snuff.

When we go into full production, I will strongly encourage people to buy the kit version of the card, so as to not place any of the soldering blame on me.

per
June 11th, 2009, 06:44 AM
This is bittersweet news for me. Glad to hear that your card is working better, not so glad to hear that my soldering skills aren't up to snuff.

When we go into full production, I will strongly encourage people to buy the kit version of the card, so as to not place any of the soldering blame on me.

Yea. I've now copied several megabytes over a 40-pin cable with the drive in "troubeling" position without a single error.

There is one thing I'm wondering about, how do you get the brownish gunk off the solder-mask after soldering a joint? I used a flat-bladed screwdrive to "peal" it off, but there was some left that wouldn't deattach. (Ok, now most people got a slodering iron/gun smaller than the one I used, so that will problably not be an issue.)

Just one last question. Can anybody compare R/W speeds when the card is in an XT and a more recent PC (486-ish)? If the speeds are more or less the same, we will problably gain higher data rates by using IRQ's.

per
June 11th, 2009, 07:01 AM
One last thing before a release; I should write a proper how-to-use document for the flasher and setup program. I also need to make it search for several signatures instead of just the first one it finds. I'll problably do all of that this weekend.

gerrydoire
June 11th, 2009, 07:03 AM
As an engineer, I am of the personality type who will keep hammering on something until it's perfect, so it's unusual for me to have this viewpoint. Not sure what got into me today. ;)

Just keep that in the back of our minds...


Best way to be!

Agent Orange
June 11th, 2009, 09:25 AM
I would use an "acid brush" or a Q-Tip with alcohol (drugstore variety - not the Jim Beam type) Although the way you guys have been going on this project, you could probably use some.

mbbrutman
June 11th, 2009, 10:53 AM
This is bittersweet news for me. Glad to hear that your card is working better, not so glad to hear that my soldering skills aren't up to snuff.

When we go into full production, I will strongly encourage people to buy the kit version of the card, so as to not place any of the soldering blame on me.

My experience says that your soldering, although it wasn't 100% pretty, is not the culprit. My data corruption issues went away when I changed to the better cable.

So don't be terribly hard on yourself. I had some solder joints that I had to redo two or three times too.

I understand your sentiment about 'perfect' vs. 'good enough'. I don't want to test every drive in existence - that's not feasible or necessary. However, I do want to find problem drives and figure out what the problem is. That just improves the robustness for the other marginal conditions these cards are going to encounter. I'm also really paranoid about data corruption .. if I can't depend on it, I don't want to use it.


Mike

NobodyIsHere
June 11th, 2009, 06:42 PM
This is bittersweet news for me. Glad to hear that your card is working better, not so glad to hear that my soldering skills aren't up to snuff.

When we go into full production, I will strongly encourage people to buy the kit version of the card, so as to not place any of the soldering blame on me.

No one is blaming you. You are doing great stuff and *I* much appreciate it and think most everyone else does too. Sometimes stuff happens and its OK. No criticism intended or implied.

Soldering can be difficult to get right especially the ground pins since I used massive copper pour fill zones to improve signal grounding and reduce ground bounce. Those ground pins practically require a blow torch to get right so maybe per is on to something using his "ol' GrandDaddy" soldering gun.

Uh, per, those soldering guns are meant for like soldering 10 AWG wires and stuff. Please be careful. It will burn a hole right through the PCB in just a few seconds.

Thanks and have a nice day!

:-)

Andrew Lynch

NobodyIsHere
June 11th, 2009, 07:11 PM
[snip]

So long story short - the two drives that were giving me grief are working now, and it looks like the older 40 pin cable was the cause of the grief. This will be a good thing to look at under a scope because those 40 pin cables should be fine for this application. There has to be something on the card that is marginal that the cable is helping out with.


Mike

Crap! I just went to bed and it occurred to me why we are probably seeing the drive "funkiness". Hargle is probably going to kill me but here goes...

Are you using 74F573s for your drive latches? As much as I am a fan of the Fairchild 74F TTL series, it may be too much for this application. 74F is super fast, very powerful, and has extremely sharp edges on its switching. In other words, its loaded with HF trash and has been known to make certain busses ring "like a bell" and may explain why certain cables work better than others. Of course, nothing can cut through noisy crappy lines like 74F but if its on a short unterminated bus it may be causing "bounce" due to reflections, etc.

Try switching back to 74LS573s or 74ALS573s as they have more "gentle" switching rather than the sometimes overly harsh 74F parts. I personally don't recommend 74HCT as they aren't known for their drive strength but you might try some of those too. Now, please I don't want to turn this into another TTL family religious crusade but some families are better than others at certain applications.

I generally stick with 74LS since they are a good balance and are generally the most (IMO) compatible with vintage electronics. Those were in the original circuit specifications as well.

Thanks and have a nice day!

Andrew Lynch

lutiana
June 11th, 2009, 07:32 PM
Just to be realistic, we should also consider how much time we're going to spend on the debugging end of this project.

Consider:
a) we've all got 80 pin cables
b) we've all got at least a couple drives that work
c) we've all got real lives to live.



That last one is hitting me really hard the last few weeks, but one more week and I'll be able to work with this more.

I also just realized I actually do not have a 40 pin IDE cable anywhere, and have been using 80 pin cables to test this. In fact I found a cable that worked, installed it on the card and have left it there.

At least a couple? I'd say quite a few have worked very well from what I am reading. Please try and fill out the spread sheet I posted, and I will get update the wiki and co-late the date so we can get an idea of exactly what works and what does not. This will definitely help us sort out some specific bugs and/or patterns that emerge. And as someone said, we aren't looking for 100% compatibility here (in fact we'd be lucky to hit 80%).

I would also say that at this point (with what, 9 different people?) testing this card it is vital that we have some someone bring all the test results together and compile it into a single report. This will help us get an overall picture of where we are at, I am willing to do this, just email me (or PM) the data you collect.

This data will also help us determine when we are ready for the second PCB to be done in a small quantity (I will personally buy one at $30 to help with the cost btw).

Lastly, I would really like to emphasize that Andrew, Hargle and Per have done an incredible job here, and I think this card will be very solid when its done.

lutiana
June 11th, 2009, 07:48 PM
So I learned 2 things tonight:

1. Do not plug the card in backwards, it will kill it

2. Once it is dead and you plug it in right, the machine will not post and the SEEQ chip will get hot, VERY F**** HOT. I know have a very painfull burn on the top of my left thumb.

*sigh* Hargle, can I get buy a replacement chip and send it you for flashing? Hopefully its just the SEEQ thats dead.

mbbrutman
June 11th, 2009, 07:52 PM
I would also say that at this point (with what, 9 different people?) testing this card it is vital that we have some someone bring all the test results together and compile it into a single report. This will help us get an overall picture of where we are at, I am willing to do this, just email me (or PM) the data you collect.


I offered to do this last week before your offer. Not a single email or private message came.

I don't think the cats want to be herded ...


Mike

lutiana
June 11th, 2009, 07:55 PM
I don't think the cats want to be herded ...


Engineers can be a difficult bunch too get documentation out of in my experience :D

per
June 11th, 2009, 10:44 PM
So I learned 2 things tonight:

1. Do not plug the card in backwards, it will kill it

2. Once it is dead and you plug it in right, the machine will not post and the SEEQ chip will get hot, VERY F**** HOT. I know have a very painfull burn on the top of my left thumb.

*sigh* Hargle, can I get buy a replacement chip and send it you for flashing? Hopefully its just the SEEQ thats dead.

You won't really need to send it to Hargle for reflashing. If you got a bootable floppy with the flasher and the most recent BIOS, that's enough. Just make sure to use the /S parameter when running the flasher the first time you flash the EEPROM.

per
June 11th, 2009, 10:49 PM
Crap! I just went to bed and it occurred to me why we are probably seeing the drive "funkiness". Hargle is probably going to kill me but here goes...

Are you using 74F573s for your drive latches? As much as I am a fan of the Fairchild 74F TTL series, it may be too much for this application. 74F is super fast, very powerful, and has extremely sharp edges on its switching. In other words, its loaded with HF trash and has been known to make certain busses ring "like a bell" and may explain why certain cables work better than others. Of course, nothing can cut through noisy crappy lines like 74F but if its on a short unterminated bus it may be causing "bounce" due to reflections, etc.

Try switching back to 74LS573s or 74ALS573s as they have more "gentle" switching rather than the sometimes overly harsh 74F parts. I personally don't recommend 74HCT as they aren't known for their drive strength but you might try some of those too. Now, please I don't want to turn this into another TTL family religious crusade but some families are better than others at certain applications.

I generally stick with 74LS since they are a good balance and are generally the most (IMO) compatible with vintage electronics. Those were in the original circuit specifications as well.

Thanks and have a nice day!

Andrew Lynch

Yes, my card got two of the 74F573 ICs.

I wonder why the soldering gun didn't go through my PCB... I had to push it down to that pin for quite a bit before the solder was sticking to it.

NobodyIsHere
June 12th, 2009, 03:21 AM
So I learned 2 things tonight:

1. Do not plug the card in backwards, it will kill it

2. Once it is dead and you plug it in right, the machine will not post and the SEEQ chip will get hot, VERY F**** HOT. I know have a very painfull burn on the top of my left thumb.

*sigh* Hargle, can I get buy a replacement chip and send it you for flashing? Hopefully its just the SEEQ thats dead.

Hi! IMO, almost certainly most if not all the chips are toast and I would not trust any survivors. Take a look at the ISA bus pin out and flip it and the other voltage rails appear on the address lines (-5V, -12V, and 12V) which means anything connected to them are likely smoked. Certainly the 74LS688's and EEPROM are goners. There may be others affected depending on how those ICs went bad. The 74LS245 would be highly suspect too depending if its connection allowed reverse biasing. Possibly flipping the VCC and GND rails would affect all the ICs depending on how it went.

My suggestion for cost effective repair is to "shotgun" the board and replace all the ICs. Just order the components and install them yourself or send it to me and I'll do it. It might be overkill but you'll save time and pain in the long run. There aren't that many and fortunately they are relatively inexpensive. Are there any burned traces?

I hope this helps. Don't fret, we've probably all done something like this at one point or another. Accidents happen.

Thanks and have a nice day!

Andrew Lynch

hargle
June 12th, 2009, 05:41 AM
Yes, my card got two of the 74F573 ICs.

We should probably do a roll call here and list what parts we have on our boards-it's possible we're on to something here.

There is likely a mixture of 74f573's and hct's, and possibly a 74ls573 or two in the mix as well.

IIRC, from my experiments, nothing mattered between the parts when I switched them, and I placed at least 2 orders from jameco, picking up both 74hct and 74f variants, using whichever one was cheaper. I don't think I mixed any parts on the same card, but you never know.

We could maybe add that data into the xls spreadsheet we're bouncing around.
Speaking of that, how to we go about all updating and sharing the spreadsheet? since we have to download it to make changes, is there a common site we can send it back to when we're finished making updates, or does 1 person want to take charge of making sure it's updated via email requests?

hargle
June 12th, 2009, 05:47 AM
I would also say that at this point (with what, 9 different people?) testing this card it is vital that we have some someone bring all the test results together and compile it into a single report. This will help us get an overall picture of where we are at, I am willing to do this, just email me (or PM) the data you collect.

ok, I guess this just answered my question above. I will send you my data today.


As for testers, everyone who is currently chiming in is pretty much it. Both mike chambers and terry yager have cards too, but they've been a bit quiet, terry especially. I have 3 cards, and after a little bit more playing with multi-card support this weekend, I would like to unload at least 1 more of them.

per
June 12th, 2009, 05:48 AM
Spreadsheet

Maybe we can use the Wiki?

lutiana
June 12th, 2009, 07:52 AM
Speaking of that, how to we go about all updating and sharing the spreadsheet? since we have to download it to make changes, is there a common site we can send it back to when we're finished making updates, or does 1 person want to take charge of making sure it's updated via email requests?

Modify it, fill it out completely, go nuts. Just get the data down and I will convert it and merge it all into a nice readable wiki article.


Maybe we can use the Wiki?

Well, the spread sheet is something quick and easy to fill out, and what I intend to do is merge the data and post it on the wiki for everyone to see. This way there will be some consistency in the end result.

I will look at purchasing all new ICs and ROM for my card and send 'em to Andrew for re-soldering. I don't think there are any burnt traces, just a very sore burnt thumb.

Thanks

Trixter
June 12th, 2009, 08:31 AM
Speaking of that, how to we go about all updating and sharing the spreadsheet? since we have to download it to make changes, is there a common site we can send it back to when we're finished making updates, or does 1 person want to take charge of making sure it's updated via email requests?

Google Docs is the best way to do this. Several people can edit the same spreadsheet simultaneously (and you can see the changes happening realtime).

NobodyIsHere
June 12th, 2009, 08:35 AM
[snip]
I will look at purchasing all new ICs and ROM for my card and send 'em to Andrew for re-soldering. I don't think there are any burnt traces, just a very sore burnt thumb.

Thanks

I hope your thumb is feeling better. That the part got so hot is definitely not a good sign.

You board does have sockets, right? I can swap them for you easily enough as it should be a simple matter of pulling one chip and replacing it a new one. There shouldn't be any desoldering/soldering involved.

I strongly recommend the use of sockets whenever possible especially during testing.

If there are not sockets, to desolder common parts like those, I'd just use a flush cutter and cut the legs off. Then desolder the individual legs, install sockets, and then install the parts. Even with a proper desoldering vacuum station (which I don't have) it'd be tough to remove all those parts without trashing at least one or two pads.

Thanks and have a nice day!

Andrew Lynch

mbbrutman
June 12th, 2009, 09:03 AM
I would be concerned that the host machine didn't like the way the board was inserted. I'd be looking to test the motherboard (and that particular) slot to make sure there is no other damage.

hargle
June 12th, 2009, 09:17 AM
You board does have sockets, right? I can swap them for you easily enough as it should be a simple matter of pulling one chip and replacing it a new one. There shouldn't be any desoldering/soldering involved.


it's all sockets. I suspect the dipswitches, caps and resistors probably survived, so as you say, it should be just a matter of getting a new set of ICs from jameco. Lutiana, I'll send you a bill of materials from jameco and you can just order a new set. Probably cost you about $12-15 plus shipping.

It'll be easy to swap the parts out and you'll be back up and running in no time, provided nothing on the PCB itself smoked.

-----------------------

here's my data, as taken from the wiki debug log:
http://www.waste.org/~winkles/XT_IDE-Testing.xls

I like the idea of moving to google docs...

lutiana
June 12th, 2009, 12:52 PM
I hope your thumb is feeling better. That the part got so hot is definitely not a good sign.


Its much better today, hurt like hell yesterday, but its a minor (first degree) burn, and now is a small blister. I'll live! :D


I would be concerned that the host machine didn't like the way the board was inserted. I'd be looking to test the motherboard (and that particular) slot to make sure there is no other damage.

As near as I can tell there is zero damage to the motherboard. It posts and boots fine without the card in it.


it's all sockets. I suspect the dipswitches, caps and resistors probably survived, so as you say, it should be just a matter of getting a new set of ICs from jameco. Lutiana, I'll send you a bill of materials from jameco and you can just order a new set. Probably cost you about $12-15 plus shipping.

It'll be easy to swap the parts out and you'll be back up and running in no time, provided nothing on the PCB itself smoked.


Much appreciated.



I like the idea of moving to google docs...

Yeah, thats a very good idea. I will set something up and post the URL.

lutiana
June 12th, 2009, 01:07 PM
Yeah, thats a very good idea. I will set something up and post the URL.

Ok, so google docs will only allow me to share the spreadsheet with specific people via email. I can't open it up to everyone and simply post a link (or at least I can't work out how to do this if it can be done).

So, anyone that is testing this card please send me a PM with your email and I will send you an invite to edit and add to the spread sheet.

I think I will also create a spread sheet with a list of you has what cards and contact details, so send me which card (and how many) you have, and whatever contact details you wish to share (if any).

*Edit* So I have edited the google spread sheet a bit, there is now a column for the BIOS revision and over-all functionality. Also, please read the comments in the heading (hover over the cell with you mouse) for what to put in the column (this will help keep the table consistent). I also added some conditional coloring (an entry of Y automatically changes to green, and N changes to red).

per
June 12th, 2009, 02:17 PM
Some updates on my side:

I've currently done some progress on the software pack for this card. Most of it is done, so it's actually just the polishing I'm working on now.

I tried to figure a way to make the setup program search for multipile cards, then asking the user what card to use. The main problem there was that it required a software-generated menu with variable number and content of options. Because writing such a menu requires quite a lot of code, and I really don't got that much time, I went for a more simple solution.

First of all, I added the "/O:Baseaddress" parameter to the setup program. I didn't add the "/S" switch for various reasons, so you have to use the parameter if you got multipile cards. Then, I made a small tool that simply scanns for siguatures, and tells the user the settings of all curently installed cards, including boot settings for the last card found.

So, a user with multipile cards should first run the small utility, then use the output to decide the input to the Setup program.

I'll also alter the Setup program to only ask for boot settings for the last found card.

k2x4b524[
June 12th, 2009, 05:25 PM
:onfire: Wow :onfire: i've been checking the thread for a while now, and i like how this card is turning out, i'm waiting for the end product, as i would be interested in one, maybe 2 of the suckers :)

per
June 13th, 2009, 01:38 AM
I just got a crazy idea:

Do you think This (http://www.satagear.com/SATA-MM-A1_SATA_Converter.html) wil work with our card?

NobodyIsHere
June 13th, 2009, 05:02 AM
Per, I think this (http://www.satagear.com/st-106_SATA_to_IDE.html) is what you want

Thanks and have a nice day!

Andrew Lynch

per
June 13th, 2009, 12:56 PM
Per, I think this (http://www.satagear.com/st-106_SATA_to_IDE.html) is what you want

Thanks and have a nice day!

Andrew Lynch

Ok, It was just a thought, in cause PATA drives are getting obsolete in the future.

linuxlove
June 13th, 2009, 01:01 PM
lol. Were you thinking about hooking up a SATA drive using that adapter to an XT-IDE card?

This looks like it's gone real well so far; i may buy one when the next batch comes...

Mike Chambers
June 13th, 2009, 02:14 PM
ok, I guess this just answered my question above. I will send you my data today.


As for testers, everyone who is currently chiming in is pretty much it. Both mike chambers and terry yager have cards too, but they've been a bit quiet, terry especially. I have 3 cards, and after a little bit more playing with multi-card support this weekend, I would like to unload at least 1 more of them.

i have tried 5 or 6 different drives and they all work like a charm as long as i stick with the 80-wire cable. speaking of which, was my resistor suggestion a stupid one?

i currently use a WD23200 Caviar driver on it with DR-DOS 7.03.

NobodyIsHere
June 13th, 2009, 06:07 PM
Ok, It was just a thought, in cause PATA drives are getting obsolete in the future.

Per, I think its a great idea. All we need is a brave volunteer to get one and try it out. Personally, I think it would work right out of the box. I could be wrong of course. The board seems to work with CF IDE adapters and they can't be any more bizarre than the SATA IDE adapters. The only way to settle it is to put down $20 and find out the old fashioned way... TRY IT!

Thanks and have a nice day!

Andrew Lynch

NobodyIsHere
June 13th, 2009, 06:15 PM
i have tried 5 or 6 different drives and they all work like a charm as long as i stick with the 80-wire cable. speaking of which, was my resistor suggestion a stupid one?

i currently use a WD23200 Caviar driver on it with DR-DOS 7.03.

Mike, well in general pull up/pull down resistors are a good idea. They are already applied in the existing design. When you take a circuit design and apply it to many unknown configurations, you'll find lots of strange combinations and things and work and some that don't. My personal opinion is we are chasing our shadows due to the cold joint issue. Once that's flushed out I think we are going to see much better results. Also, going back to 74LS parts will help, I think.

We're testing to expand the envelope on the design and find its limits. Honestly, I think its holding up fairly well. I mean, we haven't experienced any collapses of the space time continuum yet and that's always a good sign, right? :-)

Thanks and have a nice day!

Andrew Lynch

Mike Chambers
June 14th, 2009, 02:15 PM
Mike, well in general pull up/pull down resistors are a good idea. They are already applied in the existing design. When you take a circuit design and apply it to many unknown configurations, you'll find lots of strange combinations and things and work and some that don't. My personal opinion is we are chasing our shadows due to the cold joint issue. Once that's flushed out I think we are going to see much better results. Also, going back to 74LS parts will help, I think.

We're testing to expand the envelope on the design and find its limits. Honestly, I think its holding up fairly well. I mean, we haven't experienced any collapses of the space time continuum yet and that's always a good sign, right? :-)

Thanks and have a nice day!

Andrew Lynch

i don't know, i'm pretty sure i exprienced a small spacetime continuum disturbance the other day. it felt like about 8 hours passed, but i found out in reality it was only 8 minutes. i was talking to my step mother, may have had something to do with it but i'm open to the possibility of a temporal shift caused by my XT clone as well.

per
June 14th, 2009, 02:22 PM
I need everybody with an XT or XT compatible to run DEBUG and enter the command "d e000:0000" (you may replace e000 with the address to any black holes in your memory map if there are something at e000).

Does it returns 00s or FFs?

I need this information for one of the utilities that scans the memory map to search for suitable settings for our card.

Raven
June 14th, 2009, 05:24 PM
Excuse me for not wanting to read 84 pages of posts, but my understanding of this project is that there are prototypes being tested at the moment. Can someone PM me with how far along it is? Can I buy one? etc...

hargle
June 14th, 2009, 07:02 PM
I need everybody with an XT or XT compatible to run DEBUG and enter the command "d e000:0000" (you may replace e000 with the address to any black holes in your memory map if there are something at e000).

Does it returns 00s or FFs?

I need this information for one of the utilities that scans the memory map to search for suitable settings for our card.

FF's. unsed I/O is the same way. Should be the same on all platforms.

hargle
June 14th, 2009, 07:09 PM
New BIOS: 009

http://wiki.vintage-computer.com/index.php/XTIDE_project

frustrated.

didn't get as far today as I'd hoped. I really wanted to get mult-card support working, but there's a lot of recursive weirdness when trying to support multiple cards and being able to drive swap from the boot menu. It's close, but not there yet. It may take another overhaul to get it there.

This version seems to work on my z8088 with 2 devices, as well as adding a future domain SCSI controller in the system too. the SCSI card loaded first.
The boot menu works pretty well: I can boot from either floppy drive, and either the SCSI or the XTIDE drives, but cycling through the drives in DOS causes one of the drives to disappear or repeat itself.

So, please ignore any bugs found in the boot menu or operating with other HDD controller cards in the system. there's stuff there I know I need to work on. The other bug fixes (see the history file in the zip) are important enough to need to get this out there.

have fun!

Mike Chambers
June 14th, 2009, 09:42 PM
I need everybody with an XT or XT compatible to run DEBUG and enter the command "d e000:0000" (you may replace e000 with the address to any black holes in your memory map if there are something at e000).

Does it returns 00s or FFs?

I need this information for one of the utilities that scans the memory map to search for suitable settings for our card.

my BMI XT clone gives all FF's

per
June 15th, 2009, 03:18 AM
There.

Now, the utility package includes a new utility to search for a suitable swich setting for our card. Just note that this utility is called Setup.com, while the old Setup.com is now renamed Setcard.com.

Also note that the switch settings are for the final product, not the prototype.

In other news, I've added one parameter to the flasher; the ability to enter a custom I/O base port (it's patched into the ROM image before flashing), and one parameter to the Setcard utility; the ability to only change the boot settings. Run "<programname> /?" for more info.

Check it out!

lutiana
June 15th, 2009, 07:34 AM
I'm on my way to Florida for infoComm and I had some free time and internet in the airport so I was checking into the post and it occurred to me to ask these questions:

If you can set the address of the card in the bios of the card why do we need the jumpers? Also what happens when the jumper setting does not match the bios setting?

I can see the benefit of using a hardware setting, and a software bios setting, but using both seems a bit dangerous to me, or am I missing something?

hargle
June 15th, 2009, 07:54 AM
If you can set the address of the card in the bios of the card why do we need the jumpers? Also what happens when the jumper setting does not match the bios setting?

The hardware AND the software need to be set so that everyone is on the same page. The hardware is set via the dipswitches, the software is set via the value plugged into the BIOS image. The alternate would be to have the software auto-detect where the hardware is, but that didn't work out because if you didn't have any devices attached to the card, the card disappears altogether from the system.

If the hardware is sitting somewhere and the BIOS settings are somewhere else, it'll just think that there are no devices attached during POST.
Should be pretty harmless.

Note: This is only for the IO space. The ROM can be set anywhere there is room in the system. Since the software is the ROM, it doesn't matter where it's run from.

hargle
June 17th, 2009, 11:54 AM
Hi all.

I'm going to be MIA on vacation next week, so I won't be available for my usual witty banter or debugging sessions.

Your homework is as follows:

a) test out 009 BIOS and see if you can break it. There are known issues with boot swapping (ie, booting to something other than the C: drive from the boot menu) but feel free to log those issues so I know to check them all out.

b) test more drives and update that spreadsheet + wiki

c) decide if we want to try another small prototype run, or are we confident enough to do the big order. the only hardware change I'd make would be to pull out the CSEL 3-pin jumper and just pull it low. I think andrew might want to test that on his side to see if it breaks anything. I had good luck with it, and it fixed my issues with CS settings on drives.

d) If you've got flaky data reads, list your ICs and we'll see if we can narrow it down to LS or F parts.

bobwatts
June 21st, 2009, 12:33 PM
Hi Gang,

Don't know if there is any interest, but I re-installed the Acculogic card today, and took a lot of pictures of the installed software, mostly of old diags and benchmark programs {results} ( some of stuff not related, but really COOL stuff for XT afficionados Norton, InfoPlus, GEOWORKS, Windows 3.0, Checkit, Graphics Menu for Dos, etc. ), and I have the results of the "new" BIOS chip that was installed into my Acculogic sIDE card with pictures also.(not good )

Let me know, and I'll make a webpage with a LOT of pictures.

If not, that's fine, saves me a lot of work. :geek:

bobwatts
EartH

Mike Chambers
June 21st, 2009, 07:36 PM
i must have missed something, but where can i download BIOS 0.09?

per
June 22nd, 2009, 02:31 AM
i must have missed something, but where can i download BIOS 0.09?

It's availible from our Wiki:
http://wiki.vintage-computer.com/index.php?title=XTIDE_project

kb2syd
June 22nd, 2009, 04:48 AM
So I received one of the prototype boards for testing in my assorted Tandy 1000 computers. I installed it in a stock 1000sx with nothing else installed. Got a boot menu. Nice so far. So then I powered off and hooked up a drive. Now I get no boot menu, do detection, nothing.

I plugged it into my PIII DOS machine and get the same results. I'm going to try flashing the bios and checking again. More when I know more. Meetings tonight and tomorrow though and then it's going to be time to get ready for field day.

per
June 22nd, 2009, 05:07 AM
So I received one of the prototype boards for testing in my assorted Tandy 1000 computers. I installed it in a stock 1000sx with nothing else installed. Got a boot menu. Nice so far. So then I powered off and hooked up a drive. Now I get no boot menu, do detection, nothing.

I plugged it into my PIII DOS machine and get the same results. I'm going to try flashing the bios and checking again. More when I know more. Meetings tonight and tomorrow though and then it's going to be time to get ready for field day.

are you sure you plug the cable in the rigth way? some cables doesn't got the "key" hole filled, so make sure the pin-1 indicator is at the same side as the squared solder-pad of the connector.

kb2syd
June 22nd, 2009, 05:23 AM
Yes, I'm sure I plugged the cable in correctly. Even without the cable connected I no longer get a message about detection. I also reflowed all the solder connections so that's not it.

per
June 22nd, 2009, 12:21 PM
Yes, I'm sure I plugged the cable in correctly. Even without the cable connected I no longer get a message about detection. I also reflowed all the solder connections so that's not it.

Did you insert the card the rigth way after you plugged in the drive? One tested has already fried his card by inserting it the wrong way. It might also be that the EEPROM (somehow) went bad, but then you should have gotten a normal boot as if you didn't have the card installed.

Do you get the menu if the drive is not connected to the card?

kb2syd
June 22nd, 2009, 12:35 PM
Did you insert the card the rigth way after you plugged in the drive? One tested has already fried his card by inserting it the wrong way.
Yes, it was inserted correctly. I also checked and no chips were even warm to the touch. I did notice that the LED just blinks once on power on, although I don't know what it should do. I reseated all the chips and re-flowed all the solder. Still no joy.


It might also be that the EEPROM (somehow) went bad, but then you should have gotten a normal boot as if you didn't have the card installed.

It boots as if the card is not in there (to floppy).

Do you get the menu if the drive is not connected to the card? I did at first, but not now. I'm going to try to re-flash some time this week, but it's going to be tight. I have 3 meetings in the evenings this week, plus I need to get the computers ready for field day yet, plus there is ARRL field day Friday, Saturday and Sunday.

per
June 22nd, 2009, 01:39 PM
It boots as if the card is not in there (to floppy).
I did at first, but not now. I'm going to try to re-flash some time this week, but it's going to be tight. I have 3 meetings in the evenings this week, plus I need to get the computers ready for field day yet, plus there is ARRL field day Friday, Saturday and Sunday.

Sounds like the EEPROM is dead. Try to dump it using Debug.

Is the EEPROM one of the SEEQ ones, or is it from Atmel? Those parts are CMOS so they can be fried by static-electricity, however, Hargle has experienced that the SEEQ ones just drops-dead.

per
June 24th, 2009, 02:09 PM
Just like Hargle, I'm going for vacation right now, so I can't help out for a while. I'll be back in about a month.

TandyMan100
June 25th, 2009, 04:20 AM
I believe there is an IDE controller for the TRS-80 Model 100. It is controlled through software through Model T CP/M, and you can find schematics here. (http://bitchin100.com/wiki/index.php?title=MTHD)

kb2syd
June 25th, 2009, 04:49 AM
An update on the 8-bit controller I have:
I'm no longer getting a boot menu. I did the first 2 times in my Tandy 1000sx, but the computer locked hard at the "press <esc>" prompt.

I installed it in one of my MS-DOS test machines last night. This is a PIII with built in USB, Ethernet, SCSI, IDE, Parallel, 2 Serial, 2 PS/2 and Video. I also have and PCMIG backplane with a few other boards plugged in.

I did not see a boot menu on this machine either. I started debug and dumped D000:0 and saw the code from the bios 0.9 that I downloaded. I then tried to re-flash the ROM. NOTHING. I got 30 minutes of D000 scrolling down the screen and nothing else. I tried server different options on the flash routine. Next step is to try this in a simpler machine. I have plenty to choose from.

lutiana
June 25th, 2009, 12:39 PM
Hi all.
b) test more drives and update that spreadsheet + wiki


I got this one up on google apps, but no one has sent me their details to invite them to add their 2 cents into it.



c) decide if we want to try another small prototype run, or are we confident enough to do the big order. the only hardware change I'd make would be to pull out the CSEL 3-pin jumper and just pull it low. I think andrew might want to test that on his side to see if it breaks anything. I had good luck with it, and it fixed my issues with CS settings on drives.


I personally think we are ready to seriously consider a second run of the PCB design. Let me know when you go forward with this one and I will pre-order one :D



I installed it in one of my MS-DOS test machines last night. This is a PIII with built in USB, Ethernet, SCSI, IDE, Parallel, 2 Serial, 2 PS/2 and Video. I also have and PCMIG backplane with a few other boards plugged in.


I had a similar issue in my PIII, it went away when I disabled the onboard IDE controller. That was with BIOS .05 I believe, havent re-enabled it since.

I am going to purchase my replacement parts this weekend and see about resurrecting my card and then I will test it with the onboard IDE enabled.

Agent Orange
June 25th, 2009, 02:46 PM
I got this one up on google apps, but no one has sent me their details to invite them to add their 2 cents into it.



I personally think we are ready to seriously consider a second run of the PCB design. Let me know when you go forward with this one and I will pre-order one :D



I had a similar issue in my PIII, it went away when I disabled the onboard IDE controller. That was with BIOS .05 I believe, havent re-enabled it since.

I am going to purchase my replacement parts this weekend and see about resurrecting my card and then I will test it with the onboard IDE enabled.

I would like to get in on the next pcb test run/build up. I don't have the deep programming background that most of the folks have who've been in on the ground floor of the this project, but - my maintenance experience on mainframes and middies dates back to the Varian 620i 4-bit system days with revolving drum memory, ITT input/output, and high speed mylar tape reader. Also, Digital PDP-8, HP-1, and the 32 bit Data General in the mid 80's. I've been a tech most of my life (41+ years military and government) and can troubleshoot and solder with the best of them. Let me chip-in (pun intended)for the the cost of the parts and see what I can do. My sweetheart machine is a Tandy 1000SX with a VGA (had a Boca EGA but the monitor was very heavy and getting in the way), 10 GB Quantum SCSI, ST225 (23 years and still posting), and a "Harry Swartz" real-time clock card. Also it's "over clocked" if you will, with a NEC V-10 running at 10 MHz and sports a 8087 co-math processor.

Thanx - Agent Orange

mbbrutman
June 27th, 2009, 06:44 PM
My attempts at benchmarking are all over the map. I think I know why now.

You are turning off interrupts before reading a sector, and turning them back on after the 512 bytes are read. On a disk intensive benchmark where the time is spent reading and writing (as opposed to seeking) that causes a lot of missed timer interrupts.

What does this mean? The only way to benchmark this thing is going to be with a stopwatch. The system loses time while it is doing disk I/O. This is one situation where DMA would be an improvement.

(The AT uses a PIO loop to read/write sectors too. I don't know why it isn't affected this badly. Then again, maybe it is ..)


Mike

mbbrutman
June 28th, 2009, 09:15 AM
I've been doing a bit of testing - all of it was good. I've posted the results here:

http://wiki.vintage-computer.com/index.php?title=XTIDE_TestResults

Mike

hargle
June 29th, 2009, 09:30 AM
hi gang,

back from my vacation, and I see the wheels fell off while I was gone. ;)

Here's a group catchup post.

I have the results of the "new" BIOS chip that was installed into my Acculogic sIDE card with pictures also.(not good )

Bob, that BIOS installed in your card is really, really old, so any of the results you're seeing are going to be discarded by me because so many changes have happened since I shipped your card back to you.
You should try to locate an eeprom burner and update your card's BIOS. You will need to use Per's setup utility to change the base IO address from the default of 300h to 360h before you flash the new eeprom in.
Alternatively, you could mail the eeprom back to me and I'll flash it for you, but that could get tiresome if we need to do this everytime there's an update.



I did not see a boot menu on this machine either. I started debug and dumped D000:0 and saw the code from the bios 0.9 that I downloaded. I then tried to re-flash the ROM. NOTHING. I got 30 minutes of D000 scrolling down the screen and nothing else. I tried server different options on the flash routine. Next step is to try this in a simpler machine. I have plenty to choose from.

I'm sorry to hear you're having such a troublesome time with this card.
Obviously it worked at one time, but sounds like something has corrupted the ROM on it. Even if 1 bit is wrong in the ROM, the computer will skip calling the option rom altogether, which is what I suspect is happening.

The scrolling D000 from flash doesn't make any sense either, so there's something weird with the flash program too. I've been using an older version of flash, and haven't been having any issues with it, so it's possible (sorry per) that something was introduced in the newer builds that caused this to happen.

Since I just got back from vacation, things are a little hectic for me at the moment, but sometime this week I will be able to try out the newest flash program, and if I can duplicate your results, can try to fix that, and I can also make available the flash version that I've been using. Worst case is that the eeprom itself has gone out to lunch, but it sounds to me like the flash program isn't even able to get itself into a position to try and re-flash it, so we don't know yet. You got double wammied by unrelated issues.
AFAIK, you're also the first to put this into a Tandy, so there may be all sorts of things going on that we're unprepared for.




I personally think we are ready to seriously consider a second run of the PCB design. Let me know when you go forward with this one and I will pre-order one :D


I am thinking the same thing. Better to spend 300 bucks and be safe than to spend 2k and have a bunch of hand re-working to do.
Especially if folks continue to buy them at prototype costs, then I don't get sunk too much, plus there is a possibility that if there are no changes between this next prototype and the real production run, they may waive the setup fees, since this is just another order of an existing product.





I had a similar issue in my PIII, it went away when I disabled the onboard IDE controller. That was with BIOS .05 I believe, havent re-enabled it since.

I am going to purchase my replacement parts this weekend and see about resurrecting my card and then I will test it with the onboard IDE enabled.
Good. I was just going to suggest that with 009 BIOS, you should be able to co-exist with the onboard IDE controller just fine. I should really test that with my 486 as well. In fact, on my 486, I would be using an onboard controller, plus the XTIDE, and the drive installed in the 486 is using an INT13 overlay. That should be really interesting to see if when booting to the XTIDE drive, if I can properly access the overlay driven 486 drive. wow, that could get scary.



My attempts at benchmarking are all over the map. I think I know why now.

You are turning off interrupts before reading a sector, and turning them back on after the 512 bytes are read. On a disk intensive benchmark where the time is spent reading and writing (as opposed to seeking) that causes a lot of missed timer interrupts.


Ah! that explains why coretest runs for several minutes, claiming only a few seconds worth of benchmarking results. It did that on the acculogic card too, so I assumed it isn't us.

I do wonder if turning off interrupts while reading that data is really required.
Obviously for safety it makes sense, but really, who else would be poking around at our IO addresses in the middle of a disk read? Certainly a quick experiment to keep interrupts enabled there and see what happens.



I've been doing a bit of testing - all of it was good. I've posted the results here:
http://wiki.vintage-computer.com/index.php?title=XTIDE_TestResults


Great results! Odd how 1 drive, that is pretty much in between your other IBM drives in size and likely manufacturing date, fails to read/write.

I'd love to get my paws on that drive and dig into it.
If you could, in debug, after issuing a read command which fails, then do IN port reads of 301 and 307 and lemme know the numbers there.
307 is probably just 51h, but 301 is error register, which may have some more details. Heck, dump all 300-308 registers if you'd please.

If you could, also send me a dump of the IDentify device data. I believe I've posted a utility to do that on the wiki, and if not, I've got one that will dump it out to a text file that I should make available. I'm wondering if the drive might be locked/frozen via some security settings? I can tell from the ID data if it is in a locked state.

mbbrutman
June 29th, 2009, 05:16 PM
I think you need to keep the interrupts disabled. All of the code that I have read keeps them off. The keyboard or the timer interrupt firing could be pretty inconvenient.

On the AT the read loop uses the INSW instruction with a REP prefix. That instruction is 5 cycles on an 80286, so reading a sector takes a grand total of 1280 cycles. (0.213ms) At 6Mhz that is far shorter than the 55ms timer tick, so that is why the AT (and better) machines can use PIO and not worry too much about missing the timer tick. (I'll bet they still miss on occasionall)

Under perfect conditions your code is taking 70 clock cycles per word, not 5. (We don't have that fancy instruction.) I'm estimating that it takes between 4 and 6ms to read a single sector. Given that benchmarks do continuous reads we are often disabled for interrupts when the timer tick goes off, hence the time loss.

Now we know why PCs use DMA for disk I/O and ATs use polling. With a 80286 able to bring in a word ever 5 cycles it is running at the same speed as DMA could, with no setup for the DMA controller.

The PCjr BIOS is interesting - there is no DMA on those. They use a polling loop for the floppy drive controller, which is really slow and nasty. They were aware of the timer interrupt problem so they go through the effort to setup a private timer and check it when they are done with the I/O. If the private timer exceeds a certain time, they assume a timer tick would have gone off and they adjust the time of day accordingly.

I'm willing to live with the time loss on XTIDE. It keeps the code simple and it's just not a big issue. If anybody ever turns an XT into a database server then we'll have to think about charging them for an upgrade.

mbbrutman
June 29th, 2009, 05:18 PM
Great results! Odd how 1 drive, that is pretty much in between your other IBM drives in size and likely manufacturing date, fails to read/write.

I'd love to get my paws on that drive and dig into it.
If you could, in debug, after issuing a read command which fails, then do IN port reads of 301 and 307 and lemme know the numbers there.
307 is probably just 51h, but 301 is error register, which may have some more details. Heck, dump all 300-308 registers if you'd please.

If you could, also send me a dump of the IDentify device data. I believe I've posted a utility to do that on the wiki, and if not, I've got one that will dump it out to a text file that I should make available. I'm wondering if the drive might be locked/frozen via some security settings? I can tell from the ID data if it is in a locked state.

I'll collect some data for you. If it is inconclusive I can easily get the drive up there for an advanced debug session.

The drive is not locked though .. it booted on my Athlon 2000 box just fine. It had an old version of SuSE on it, and luckily I remembered the root password. :-)

kb2syd
June 30th, 2009, 04:54 PM
OK, I started up a plain vanilla Compaq 486 this evening. I think the Amtel EEPROM is hosed. What should I get in place of that? Anyone have a ROM already flashed. That's one thing I don't have available (an eprom programmer).

What is the layout of the two switches. I can't seem to find it right now. I also can't download the utilities at the moment.

Kelly

hargle
July 1st, 2009, 10:18 AM
I think the Amtel EEPROM is hosed. What should I get in place of that? Anyone have a ROM already flashed. That's one thing I don't have available (an eprom programmer).

I doubt it's fried, likely just corrupted and a proper flashing should do the trick.
I'll email you later today with links to the flash program that I'm using and the proper command switches to throw. i'm pretty confident we can resurrect your board with just software.



What is the layout of the two switches. I can't seem to find it right now. I also can't download the utilities at the moment.

I don't have my card in front of me at the moment, but I think it should go like this:

Left switch = IO decode
switches 5+6 should be OFF. All others ON. That's 300h.

Right switch = ROM address
switches 1,2,4 should be ON, all others OFF. That's D000h.

It would be best to not change the IO or the ROM addresses from where all of our cards are located. If you change the IO, you have to use the setup utility to modify the ROM and re-flash it, and those are variables we don't want to introduce just yet.

kb2syd
July 1st, 2009, 11:04 AM
When I ran the setcard program again last night, it reported that it was flashing the card. I thought "flash" actually flashed the card, and setcard just set up the romimage for the card.

Anyway, when it (setcard) completed, it reported a mismatch in the first 3 bits. I then went in to debug and dumped the contents of the rom. They matched the rom flash file (at least the first few bits). The setcard program said the first bits were all 1e (when they shouldn't have been).

I didn't want to change the address or the IO decode. Just wanted to make sure I didn't flick them when moving things around.

Findcard reports that the card is installed.
Setup reports that no suitable address could be found.

This was under DOS 7 (win95 without the GUI boot), and then later under DOS 6.22.

I eagerly await futher directions. In the mean time, I'm going to remove all cards from this machine (compaq prolinea 486) and replace the CMOS battery. It currently has a sound card and network card installed. I want to reduce the variables.

update:
I just removed all cards and replaced the CMOS battery. Now, when I do:
flash i:oprom.bin b:300
the flash program runs throuhg. However it still reports that the first 4 byres are stuck at E3 not 1e like I stated before. I'm going to re-download the utilities and ROM image.

Update 2:
These cards do NOT like Tandy 1000 computers. After 3 boots the ROM needs to be reflashed. It always hangs at boot menu (for the first 3 boots).
One thing to consider is that the Tandy machines initially boot in CO40 then switch to CO80 making the ROM message hard to read. Another thing to consider is that the 1000 series machines do not use standard keyboards.

Flashing STILL reports an error every time too.

mbbrutman
July 6th, 2009, 06:55 PM
I have a really basic question about the design of the board.

Right now when we read from the magic data port on the IDE drive it dumps 16 bits into two byte sized latches. The first byte sized latch is at the IO port address and we read a byte from it. (Presumably after the drive has put something in it.) The second byte sized latch is at an I/O address 8 greater than the first address, and we do a second explicit IN to read that byte. The controller doesn't respond to that port address, so it doesn't try to set the contents of that latch, leaving the original contents there for us to read.

The inner loop that reads two bytes from two different ports to make a word is limiting the speed of the card. Is it possible to have a design where we use an IN instruction that reads a full word? (The 8088 supports word transfers from ports.)

The 8088 would go through two full bus cycles to read the word from the bus, and it would handle all of that for us automatically. The first bus cycle would read the first byte, as expected. The second bus cycle would try to read the second byte. From what I can tell the same port address is on the bus for both bus cycles, so there is no way to explicitly tell if we are reading the first byte or the second byte. So the card would have to keep toggle between the two bytes, toggling each time the port is read. The toggle determines if the IDE drive is allowed to set all 16 bits (on the first read) or if the IDE drive is idle, and it also sets which 8 bits get fed back to the 8088.

If this is workable it would be much faster that what we have now.

(And forgive me if this was brought up before too ...)

mbbrutman
July 6th, 2009, 07:07 PM
Rats - answered my own question.

This link (http://bitchin100.com/files/hardware/) was discussed early in the thread, and it describes the technique.

Next question - why didn't we do this? Was it just a matter that we had something in hand that we knew worked well and were cloning it?

What we have so far is great. But the engineer in me says 'do better' :-) The performance could be at least 2x faster compared to what we have now.


Mike

hargle
July 7th, 2009, 06:56 AM
whoops, I totally missed this posting here somehow. I thought we were still waiting on your results. sorry.


When I ran the setcard program again last night, it reported that it was flashing the card. I thought "flash" actually flashed the card, and setcard just set up the romimage for the card.

i'm speaking for per, and i certainly shouldn't be.
Flash does program the part-that's the only thing I have ever used.
If you aren't moving the IO space, then flash is all you need.

If setcard can flash the part as well, then the 2 programs should be merged together so you just load up the binary image, then tweak IO address as required, and flash it all is one swell foop.

I'll leave the rest of these flash program issues for per to answer.


update:
I just removed all cards and replaced the CMOS battery. Now, when I do:
flash i:oprom.bin b:300
the flash program runs throuhg. However it still reports that the first 4 byres are stuck at E3 not 1e like I stated before. I'm going to re-download the utilities and ROM image.
Update 2:
These cards do NOT like Tandy 1000 computers. After 3 boots the ROM needs to be reflashed. It always hangs at boot menu (for the first 3 boots).
One thing to consider is that the Tandy machines initially boot in CO40 then switch to CO80 making the ROM message hard to read. Another thing to consider is that the 1000 series machines do not use standard keyboards.

Flashing STILL reports an error every time too.

well, it looks as though the re-programming is successful, as the option rom is getting called by the mainboard BIOS, even though the flash program is reporting a byte mismatch. Let's just let that be for now, and see what the tandy is trying to do to us.

You say that after 3 reboots the ROM needs to be reprogrammed. Does that mean that the main BIOS just ignores/skips the option rom after the 3rd boot and the card is "dead" from there? If that's the case, then something is corrupting the ROM itself, and it would be interesting to know what that is.

I'd do this:
Flash the card.
Use mike's ROM dump utility:
http://www.brutman.com/PCjr/pcjr_downloads.html -> pcjrcart.zip
and dump the ROM out.

Put the card in the tandy, reboot it 3 times or until the ROM is corrupt.
Dump the rom again. That'll let us compare the 2 rom images before and after and allow us to see what is getting corrupt. It might not tell us anything, but it would be interesting to know what it's doing. The next card does have a write protect on the eeprom, so that should certainly help with this, but I'm mostly curious to see what it's doing.

After that, I think we will also need to move your testing off the tandy for the time being and use it on another platform. I'd like you to get a better warm-fuzzy about the normal operations of the card rather than fighting whatever demons are inside the tandy. we'll have to concentrate on those later, like when I can get my hands on one of these machines.

Anyone have a tandy that they wouldn't mind selling/loaning me?

kb2syd
July 7th, 2009, 07:42 AM
Anyone have a tandy that they wouldn't mind selling/loaning me?

If you can't find one closer, I can mail you a bog standard Tandy 1000sx and keyboard. The SX boots from both Tandy and pc compatible HD cards depending on a switch setting.

Or, I could send an HX or EX (one of the all in ones) with the added memory so it has DMA. This would be much lighter, but the card would have to plug into a (homemade) adapter. I can include an 8 bit AT IDE card that does work with the Tandy lines for reference.

Do you have a CGA Monitor? I can send the 1000 and keyboard, but I would like them back. I would not want to box up a monitor.

Shipping would be from NJ. Anyone closer to Hargle have a 1000 he can use?

I will report back on the other requests later this week (probably Wednesday).

NobodyIsHere
July 7th, 2009, 09:23 AM
Hi! What I would do is burn a 2764 EPROM. Regardless of what the Tandy is doing, it is not going to corrupt an EPROM. From what you are describing though, it doesn't sound like the EEPROM is the problem.

I think there is most likely something damaged or broken on your card. If not, the Tandy is doing some *very* strange things.

It may be cheaper/easier to try a 2764 EPROM and/or swap cards rather than ship machines. As the Tandy is an early IBM PC "clone" it may be only semi-compatible. Its possible there are differences in its ISA bus implementation causing the anomalies.

Thanks and have a nice day!

Andrew Lynch

Great Hierophant
July 7th, 2009, 09:57 AM
The Tandy's anomalies on the ISA bus fall into three categories, the possible lack of a -5v line, differences in the bus controller compared to the IBM PC and differences in the BIOS interface.

Of course, if Hargle has no CGA or EGA monitor, he can always use the composite output and squint at its 80-column output.

kb2syd
July 7th, 2009, 10:16 AM
I'll see if I can get somone to burn one for me. I don't have a burner handy, but know people that do.

There are several signals missing on the ISA Bus. I will upload diagrams of ISA and Tandy bus.
Here are some of the differences:
B05 is NC (not -5)
B15
B16
B17
B18 are all NC

The keyboard is different. See: http://support.radioshack.com/support_computer/doc15/15797.htm

see: ftp://ftp.oldskool.org/pub/tvdog/tandy1000/documents/1kprog.zip for the programmers reference.

hargle
July 7th, 2009, 11:34 AM
yeah, it was mostly the keyboard issues and the 40 column screen stuff that I wanted to fix as well as trying to figure out why some stray writes are hitting our EEPROM. There's likely not much we can about that, short of removing the write enable line to the ROM, which will be on the next board anyway, so this is more of a curiosity over anything else.

I do have a couple CGA monitors; true blue 1535's in fact, so all I'd need is a machine and the ability to plug our card in and see what happens.

It would be great to find one closer, but shipping is not a problem if you're willing to loan one out.

NobodyIsHere
July 7th, 2009, 03:07 PM
Rats - answered my own question.

This link (http://bitchin100.com/files/hardware/) was discussed early in the thread, and it describes the technique.

Next question - why didn't we do this? Was it just a matter that we had something in hand that we knew worked well and were cloning it?

What we have so far is great. But the engineer in me says 'do better' :-) The performance could be at least 2x faster compared to what we have now.


Mike

Hi Mike,
Are you referring to this (http://bitchin100.com/files/hardware/8bit_ide.zip)?

If so, that circuit is great for Z80 ECB bus systems but won't work on ISA without some major adaptation. I believe it is the basis of GIDE by Tilmann Reh.

The major issue with design is that it is much more complex than a quick look at the schematic may indicate. It uses a PAL so it would either require some design engineering with the equations to either build from common components or converting to and accepting unique programmable hardware into the design (GAL or CPLD). That presents a major buildability issue and long term support problem. Using common 74LSxxx TTL is much easier to build and support but replacing that PAL would require several additional chips since it contains a lot of interface logic.

Probably with enough additional logic, one could make the LO and HI port read from the same IO port but it would significantly add to the complexity of the board. More parts -> more PCB area -> higher cost -> less affordable -> less demand, etc. I recall discussing this subject with per (?) a while back and looked into some alternatives but nothing really gelled.

Whatever solution there is out there will probably require some prototyping and possibly a redesign. The problem is more complex than it appears because the IDE interface requires 16 contiguous IO ports. Also, sometimes the data port $x0 must be accessed sequentially so just flipping the port between LO and HI introduces its own problems.

Feel free to make a new design and prototype it if you'd like. My plate is full with other N8VEM projects at the moment (VDU PCB, PropIO prototyping, etc) so I am kind of at the periphery of this project until the BIOS settles and the hardware design is finalized.

I still have not started the next version PCB respin as I recall there were still open issues with the hardware design although I don't recall what they are at the moment. I think we've learned a lot with the initial PCB prototypes but they are definitely getting old and its time for another rev of hardware, IMO.

For all its faults, the current design does have the benefit of a relatively low part count and small PCB area. That keeps the costs low and is essential for this project to be viable, IMO.

Thanks and have a nice day!

Andrew Lynch

mbbrutman
July 7th, 2009, 04:10 PM
Hi Andrew,

Yes, that is the project I'm referring to.

I was looking at the code that does the read and write loops trying to find a way to make it faster. We are reading and writing about 85KB/sec now and I know it can be much faster. I figured out a way to shave four cycles without loop unrolling but it is still a big loop - we have the two different port addresses to deal with and a shortage of registers. I know the 8088 is capable of 16 bit transfers - using them would make the loop simpler and much faster.

The Z80 (being influenced by Intel designs) handles 16 bit port reads in a way similar to the 8088. The Tilmann Reh design, although for a different bus, shows that the technique of flip flopping between two latches can work. His solution is more complex because he is paranoid about managing the state of the flip flop, ensuring that it always gets reset if another register is touched. (A bit over overkill, but commendable.)

I don't think the current design has a lot of faults. Functionally it is very good - most of my drives are working with it. The performance is a minor issue; there is a lot of potential to fix it. I understand that if I want to make it faster I'll have to do the work. ;-0

Another idea that I have in the back of my head is to memory map the latches instead of addressing them as I/O ports. The IDE card can continue to read or write 16 bits at a time to the latches. The PC would continue to read or write 8 bits at a time. The advantage of memory mapping is that the PC will generate a different address on the bus for the second byte - the lowest address line can be used to differentiate between the two latches. I haven't worked it out on paper, but memory mapping the registers should be transparent to the device - the read and write bus cycles are so similar for memory and I/O.

So just an idea for now but what do you think of memory mapping?


Mike

NobodyIsHere
July 8th, 2009, 04:48 AM
[snip]
So just an idea for now but what do you think of memory mapping?

Mike

Hi! I think you could make memory mapping work. It would require another set of memory decode logic (jumpers, 74LS688, pull up resistors, etc). If the memory decoding logic is specific to just 2 memory addresses then you would need to check 19 address lines which would lead to a lot of new parts as each 74LS688 can only check 8 each. In addition, whatever changes to the circuit to support the new access mode would be on top of that.

My recommendation is to think through the design and write up a schematic. Then we can look at some prototyping with wire wrap or cuts and jumpers on a PCB version. I strongly recommend prototyping any design before making PCBs. It is *very* easy to have oversights and mistaken assumptions that have dire effects on the design. Prototyping is the only practical method to test the theory, IMO.

Thanks and have a nice day!

Andrew Lynch

hargle
July 8th, 2009, 06:51 AM
ok, so now we're at a crossroads.

Change to memory map to bump the performance up a notch, or press on with the existing design and get into production.

The BIOS will change very little between the two, so that's a non issue.

Andrew seems very busy and likely can't dedicate much more time to this project, so someone else hardware oriented could take on the task of trying to prototype this new card, but I can't do it.

Or we do both. Production/2nd proto of our current design, and we play around with DMA and or memory mapped stuff over the next several months and come out with XTIDE mk II sometime next year and see what kind of interest there is.

mbbrutman
July 8th, 2009, 07:40 AM
Nah, we are not a crossroads. By all means I want us to keep on the current path. (I intend to buy a few of these current cards - I'm really happy with the way everything has come out, except for the one stinky drive that I have to deliver to you.)

The memory mapping idea is more involved and it is going to require prototyping and debugging, just like this first version of the card did. I think it is a new branch of the tree and not the design direction for the current card.

I am just trying to figure out a low cost/low complexity way to get back some of the performance. We've got a simple card that meets our requirements - there is no sense in messing that up now. But I'm developing some ideas for another version of the card later on down the road. Memory mapping those registers gets rid of that ugliness where we need a flip flop to track whether we are reading the high or low byte - it makes the CPU do that for us. That part is elegant, but it reqiures more thought to make sure it's viable.

If you count cycles, I estimate the current loop takes 70 cycles, not counting the side effects from DRAM refresh cycles and instruction prefect weirdness on the 8088. I think that well over half of the loop would disappear if we didn't have to dink around with two port addresses, the shifting of of the low byte and the xchg. The way I'm wired 2x is hard to leave on the table. ;-)

Mike

lutiana
July 8th, 2009, 12:14 PM
ok, so now we're at a crossroads.

Change to memory map to bump the performance up a notch, or press on with the existing design and get into production.

The BIOS will change very little between the two, so that's a non issue.

Andrew seems very busy and likely can't dedicate much more time to this project, so someone else hardware oriented could take on the task of trying to prototype this new card, but I can't do it.

Or we do both. Production/2nd proto of our current design, and we play around with DMA and or memory mapped stuff over the next several months and come out with XTIDE mk II sometime next year and see what kind of interest there is.

I say we move forwards with the current. But we need to do a small run on the new design.

The memory mapping is an interesting idea, but lets save that for PCB rev 2.

Twylo
July 8th, 2009, 01:22 PM
My goodness! I'm a bit overwhelmed by this thread, but I've managed to read through quite a bit of it.

I'd love to get on the list for a Rev. 2 (or new run of Rev. 1) card. I've just got my first 5150 PC, and I'd love to be able to add mass storage to it. It's got the original 5150's 65W power supply, so it's unable to power an MFM drive, and as you've all already noted, 8-bit IDE cards are rare and expensive. So the solution you've developed is ideal! I could easily power a CF card, or a modern 3.5" hard drive, and not strain the power supply.

Please let me know when the Rev.2 cards or kits are available. I've already got all the parts, and a device programmer for the EPROM, but that PCB is pretty essential ;) I'd also be open to doing a small run of PCBs myself if the gerber files are available (I'm still digging through the thread, but I haven't found them yet!)

I've subscribed to the thread, so I should get updates in email.

Thanks much!

Chuck(G)
July 8th, 2009, 01:26 PM
Re: The Z80 Reh controller. He's talking about using the same I/O address for both halves of the data lines.

On the 8088, if I code (for example)

mov dx,120h
in ax,dx

The 8088 issues two I/O port reads; the first is for 120H and the second is for 121H (high order byte). It seems to me that it wouldn't take all that much logic to detect that situation and gate the correct byte.

That would let your read loop look something like this:

mov dx,<dataport>
mov cx,256
L1:
in ax,dx
stosw
loop L1

It'd be hard to do much better on an 8088.

I apologize if this has been already discussed--I didn't feel that I had enough time to read the 90 or so pages of previous posts, so I only went back a couple of pages.

NobodyIsHere
July 9th, 2009, 04:33 AM
Hi! One idea would be to set aside a separate range of 16 IO ports immediately above the $300-$30F range that implemented the alternating reads/writes to the port. That way little additional changes would be necessary just remove the lowest address line (A4) from the 688 and use the A4 line to distinguish between the upper 16 and lower 16 IO port ranges.

The first read to the upper 16 would reveal LO port the next HI port. Basically implement using a 74LS74 flip flop on A3 to mirror the IO ports and toggling with subsequent reads using the upper 16 IO ports address decoder as a clock. Possibly tying the flip flop's reset line to the lower 16 IO ports decoder to prevent it from getting out of sync. Use AND gates to qualify A0, A1, and A2 with /A4 so that any read to the upper 16 make the existing circuit appear that A0, A1, and A2 are LOW and A3 comes from the flip flop but would have to be qualifed with the ISA bus A3 to ensure compatibility with the existing circuit.

In theory the design would preserve compatibility with the current BIOS since the existing IO ports and circuitry would still be in place (lower 16). You could basically ignore the upper 16 until the BIOS was modified to use the upper 16 IO ports. Still, this is notional stuff off the top of my head so it would still need the normal design, schematic, prototype, etc cycle. At a minimum, it would require 4 more chips (74LS32, 74LS04, 74LS08, 74LS74) unless there are spare gates we could use (I don't remember).

This is a pretty major change to the design. However, since the existing circuitry is largely unmodified someone could implement proof of concept prototype using an existing PCB with just cuts and jumpers to a "dead bug" modification. Any takers? Mike? Richard? Chuck?

Thanks and have a nice day!

Andrew Lynch

Chuck(G)
July 9th, 2009, 08:29 AM
I'd be willing to work it out, but I've only been watching this project from the peanut gallery, so I don't know if I'm the person to begin hacking on this thing.

But leaving that, my change is pretty basic. You've already got the circutry to gate the upper or lower 8 bits onto the bus. So you could use a flip-flop to toggle the upper/lower accesses; said flip-flop would be reset by any I/O or memory access that isn't to the data port+1 address, since the two 8-bit accesses of a 16-bit I/O instruction happen without any intervening memory or I/O references.

per
July 9th, 2009, 01:27 PM
i'm speaking for per, and i certainly shouldn't be.
Flash does program the part-that's the only thing I have ever used.
If you aren't moving the IO space, then flash is all you need.

If setcard can flash the part as well, then the 2 programs should be merged together so you just load up the binary image, then tweak IO address as required, and flash it all is one swell foop.

I'll leave the rest of these flash program issues for per to answer.
I'm not really home from vacation yet, but I just got a minute of internet access.

The only similarity between the setcard and the flasher is the flashing engine. The rest of the two programs are not similar; Setcard gets the image from ROM, and asks for new settings, while Flash gets the image from a file, and doesn't need the signature to be present at the target address.

I've been thinking of combining them, but I figured they work best as two seperate utilities because they use the same command line options for different purposes. In addition, it's impossible to fit the entire "syntax" line on the screen if both programs are combined ;) .


The errors reported by the flasher is simply because (for some strange reason) the flasher can't properly read the first bytes after a write. It's just normal move instructions, so I don't understand why it fails on some cards.

Druid6900
July 9th, 2009, 06:53 PM
Any takers? Mike? Richard? Chuck?



If you mean ME, I don't even HAVE one of these cards.

However, it could be easily done by sticking chips on top of existing chips, soldering the ground and Vcc legs to the chip below, bending the other pins out parallel to the board, make your cuts and use wirewrap wire to connect the appropriate pins on the new chips into the circuit.

NobodyIsHere
July 9th, 2009, 07:36 PM
Richard, I am sorry, I thought you had a card. I'd like to do it myself as I don't think this would be very hard to do but I am a bit overwhelmed at the moment.

I have N8VEM three boards in work right now (6809 host processor PCB build and debugging, VDU PCB trace optimization, and PropIO prototype and test phase). It is a bit of a juggling act but it sure is fun!

Thanks and have a nice day!

Andrew Lynch

lutiana
July 10th, 2009, 10:17 AM
Where do we stand on the design for the next run of the card? I am looking at the design now and its pretty good IMO.

What I want to do is get a table made up for the switch settings and jumper settings to be silk screened on the back side of the card, but in order to do this I need a re-cap of what Andrew did with them.

hargle
July 10th, 2009, 10:50 AM
Where do we stand on the design for the next run of the card? I am looking at the design now and its pretty good IMO.

What I want to do is get a table made up for the switch settings and jumper settings to be silk screened on the back side of the card, but in order to do this I need a re-cap of what Andrew did with them.

I too would like to see us move to the next level. I think the BIOS is pretty solid, barring any weird tandy issues and a few straggling hard drives.

I don't recall the current list of hardware issues, but the one that I do know about is the CSEL one. Currently the CSEL line is pulled high, which is something that andrew did in previous designs that helped some WD drives work.
I've found that on our card, the CSEL line being pulled high caused issues with drives which were jumpered for cable select. By pulling that line low, my issues went away.
The new design has a 3 pin jumper so it can be configured either way. I personally don't see the need for this, and would like it just pulled low and taken out of the design altogether to simplify the design and build. I'm a sample size of one though, so if someone else with a bit of soldering skill could try that on their end, that would be nice to get another opinion on.


As for jumpers and a silkscreen, here's the data we're working on:
Andrew should really double check this!!
IO Range, dipswitches 8:5


0000 = 200h
0001 = 220h
0010 = 240h
0011 = 260h
0100 = 280h
0101 = 2A0h
0110 = 2C0h
0111 = 2E0h
1000 = 300h
1001 = 320h
1010 = 340h
1011 = 360h
1100 = 380h
1101 = 3A0h
1110 = 3C0h
1111 = 3E0h

The above assume IO line 9 is pulled high, and 4:0 are pulled low, and the dipswitches are acting as bits 8:5.

Memory address, switches 4:1


0000 = C0000-C1FFF (likely invalid, since that would clash with video)
0001 = C4000-C5FFF (ditto)
0010 = C8000-C9FFF
0011 = CC000-CDFFF
0100 = D0000-D1FFF
0101 = D4000-D5FFF
0110 = D8000-D9FFF
0111 = DC000-DDFFF
1000 = E0000-E1FFF
1001 = E4000-E5FFF
1010 = E8000-E9FFF
1011 = EC000-EDFFF
1100 = F0000-F1FFF (probably invalid here onward too)
1101 = F4000-F5FFF
1110 = F8000-F9FFF
1111 = FC000-FDFFF


That's assuming bits A19=1 and A18=1, and A13=0.
The dipswitches represent A17:A14

NobodyIsHere
July 10th, 2009, 11:24 AM
Hi! I will be gone this weekend camping with the family. I'll pick this back up on my return Sunday night. Thanks and have a nice day!

Andrew Lynch

Chromedome45
July 13th, 2009, 06:38 AM
I would like to get a hold of one these too. How much will the selling price when they become available? So put me down for 1 also.

Frank G.:cool:

hargle
July 13th, 2009, 07:35 AM
I would like to get a hold of one these too. How much will the selling price when they become available? So put me down for 1 also.

Frank G.:cool:

we appreciate the interest, but we'd like to keep this thread clean of the "me too!"'s unless you've got some debugging and development insight to add.

keep this page handy, that's where the current status is located:
http://wiki.vintage-computer.com/index.php?title=XTIDE_project

Chromedome45
July 13th, 2009, 03:26 PM
I'm Sorry my bad. But if you did sell I would be interested. Again my
appologies.

NobodyIsHere
July 13th, 2009, 05:22 PM
Hi All! I uploaded new a schematic and PCB layout on the N8VEM wiki in the XT-IDE folder. Please check it out and make any comments.

I think there are two things we need:
1. someone to find out the old "to do" list and see if those have been checked off. I think so but its good to double check. Also run against the schematic and PCB layout to ensure everything is there.

2. volunteer trace routing station. Needs to be a fast computer than can run undisturbed for at least 3-4 weeks for trace optimization run. It will require some minor care and feeding to tend to the process as its running. Normally I would do this but my machines are all booked solid running other N8VEM jobs. I run a 3.2 GHz P4 with 512MB RAM Linux w/Java 6 and it is painfully slow

Thanks and have a nice day!

Andrew Lynch

per
July 13th, 2009, 10:16 PM
Also run against the schematic and PCB layout to ensure everything is there.

The /Write-Enable line of the EEPROM still doesn't got a pull-up resistor.

mbbrutman
July 14th, 2009, 03:33 AM
Hi All! I uploaded new a schematic and PCB layout on the N8VEM wiki in the XT-IDE folder. Please check it out and make any comments.

I think there are two things we need:
1. someone to find out the old "to do" list and see if those have been checked off. I think so but its good to double check. Also run against the schematic and PCB layout to ensure everything is there.

2. volunteer trace routing station. Needs to be a fast computer than can run undisturbed for at least 3-4 weeks for trace optimization run. It will require some minor care and feeding to tend to the process as its running. Normally I would do this but my machines are all booked solid running other N8VEM jobs. I run a 3.2 GHz P4 with 512MB RAM Linux w/Java 6 and it is painfully slow

Thanks and have a nice day!

Andrew Lynch

Is it threaded? I've got a newer Intel quad core with 3GB of RAM that should make short work of that.

Mike

hargle
July 14th, 2009, 06:11 AM
from the wiki, here's the list of things that were changed:
* Added a header for an external hard-drive LED
* Added a Rom Enabled jumper
* Added a write protect jumper
* Added an Int Select jumper allowing for it to be set to 2, 3, 4, 5 or 7
* Added a CSEL 3 position jumper.
* Shifted all the components over to make a 1/2" dead area on the left hand side of the card, and added a small skirt. This will allow for attachment of a wide variety of mounting brackets.
* Removed some unused gold teeth on the ISA connector.
* Added Silk screening on the back of the card to outline the dip settings and usage.

These items have been suggested and discussed

* Replace the DIP switches with jumpers
* Scale down the IO and ROM Memory range settings to 4 places instead of 8 (about 16 possibilities each)
* Adding IRQ support

I don't know of any other hardware issues that needed looking into, barring anything that may come up when we get a Tandy to work with.
edit: kb2syd is having a hell of a time getting his card to work on *any* machine (tandy/compaq 486, xt).
I'm getting the card sent back to me for debugging. Dunno what went so wrong there, but I'm optimistic that this won't cause design changes.


lutiana,
According to the schematics, my dipswitch guide from above is backwards.
Dips 4:1 are for the IO, 8:5 are the ROM decode. I think that the decoding values are correct though.

We absolutely need to do another 10 prototypes to test this stuff out.
We could probably do 5 to save a little bit of cash, since there aren't that many of us testing, but we can explore that when we get closer to production time.

shawn510
July 14th, 2009, 07:23 AM
I don't know of any other hardware issues that needed looking into, barring anything that may come up when we get a Tandy to work with.


Is the lack of a Tandy an issue? I have a working TL/2 and an untested SL (probably ok, just haven't got around to testing). If someone wants to borrow one, or even better ;) , send a prototype card here for testing I would be fine with that.

hargle
July 14th, 2009, 09:24 AM
Is the lack of a Tandy an issue? I have a working TL/2 and an untested SL (probably ok, just haven't got around to testing). If someone wants to borrow one, or even better ;) , send a prototype card here for testing I would be fine with that.

kb2syd is sending me a tandy to examine, but if you're closer than the east coast (do I remember that right?) to minneapolis, then maybe we're onto something. Otherwise, if you're up for doing some low level debugging on this to find out what the deal is, then I'll certainly send you a card. You may need an Oscope and be able to do some software debugging.

I am willing to pay shipping both directions, or would be happy to just out and out buy a tandy machine from someone.

Edit: I think I've just purchased a tandy HX machine for this project. Thanks to kb2syd, and thanks to shawn510 for the offer as well.

NobodyIsHere
July 14th, 2009, 12:51 PM
The /Write-Enable line of the EEPROM still doesn't got a pull-up resistor.

Hi! Thanks for the reminder. I will make that change tonight and repost.

Thanks and have a nice day!

Andrew Lynch

NobodyIsHere
July 14th, 2009, 12:52 PM
Is it threaded? I've got a newer Intel quad core with 3GB of RAM that should make short work of that.

Mike

Hi! Its FreeRouting.net and I don't think its multithreaded but am not sure.

Thanks and have a nice day!

Andrew Lynch

NobodyIsHere
July 14th, 2009, 03:42 PM
Hi Per,
I double checked and the EEPROM write enable does have a pull up resistor. It is the VCC to 10K ohm R7 resistor attached to /WE pin 27.

Its good to double check though. Please if anyone else has features they are particularly interested in check the schematic and/or PCB layout to see they are there or not.

Thanks and have a nice day!

Andrew Lynch

NobodyIsHere
July 14th, 2009, 04:05 PM
[snip]
Hi! I rechecked the "to do" list and everything appears done. I fixed the silk screen on the copper side with the IO and memory range information.



I don't know of any other hardware issues that needed looking into, barring anything that may come up when we get a Tandy to work with.
edit: kb2syd is having a hell of a time getting his card to work on *any* machine (tandy/compaq 486, xt).
I'm getting the card sent back to me for debugging. Dunno what went so wrong there, but I'm optimistic that this won't cause design changes.


There is something else wrong with Kelly's board. I recommend pulling that board back for some serious depot TLC. At least reflow the board and probably debug or shotgun all the components. Something is seriously whacked with it. You can send it to me if you want and I'll work on it when I get a chance.

Yes, I goofed on the IO/memory dip switch settings. That's fixed with latest version.




lutiana,
According to the schematics, my dipswitch guide from above is backwards.
Dips 4:1 are for the IO, 8:5 are the ROM decode. I think that the decoding values are correct though.

We absolutely need to do another 10 prototypes to test this stuff out.
We could probably do 5 to save a little bit of cash, since there aren't that many of us testing, but we can explore that when we get closer to production time.

Regarding prototypes, I would order more PCBs and less other parts. If money is an issue, I would just get the PCBs and let the builders supply their own components or go half and half. Testing part variations is a good thing and having multiple builders with varying construction techniques will surely produce more useful test results.

Alternatively, let prospective tester builders that you personally know and trust "buy in" to the PCB manufacturing order by sending in their own money for their board. I'd be very careful with that though since it is dangerously close to accepting pre-orders and you already know my thoughts on that.

Actually, since you got the first round, I'd be willing to pick up the second round of PCBs and pass them along with the other N8VEM boards. Its up to you though. I'd order 25 PCBs and pass them along as bare boards for builders. I'd charge just enough to cover the PCB manufacturing run. Given the history and stamina of this project so far it is an acceptable risk.

However, personally I would seek broader coverage with the second run of prototypes. We have learned a *LOT* with the first round.

Thanks and have a nice day!

Andrew Lynch

NobodyIsHere
July 14th, 2009, 06:12 PM
Hi! I put the XT-IDE PCB in FreeRouting.net on our main home computer (AMD Barton 2500) and got it to finish autorouting. That's good. The PCB is rather clean considering all the changes. It has 157 vias and 421+ inches of overall trace length. Still, it will take a while to grind it down to size. Its good it was able to solve without manual intervention though. That bodes well.

Thanks and have a nice day!

Andrew Lynch

lutiana
July 14th, 2009, 07:51 PM
.
I'd order 25 PCBs and pass them along as bare boards for builders. I'd charge just enough to cover the PCB manufacturing run. Given the history and stamina of this project so far it is an acceptable risk.


I think that this is more than reasonable at this point.

What format do you want the table for the silk screen on the back end? I will try and send it to you by the end of the week.

shawn510
July 14th, 2009, 08:47 PM
kb2syd is sending me a tandy to examine, but if you're closer than the east coast (do I remember that right?) to minneapolis, then maybe we're onto something. Otherwise, if you're up for doing some low level debugging on this to find out what the deal is, then I'll certainly send you a card. You may need an Oscope and be able to do some software debugging.

I am willing to pay shipping both directions, or would be happy to just out and out buy a tandy machine from someone.

Edit: I think I've just purchased a tandy HX machine for this project. Thanks to kb2syd, and thanks to shawn510 for the offer as well.

Congrats on scoring the HX, I am pursuing a lead on one myself. Of course you will need a plus to ISA converter, but I hear those are straightforward to build.

NobodyIsHere
July 15th, 2009, 06:23 AM
I think that this is more than reasonable at this point.

What format do you want the table for the silk screen on the back end? I will try and send it to you by the end of the week.

Hi! The data on the copper side silk screen is all entered one line at a time. KiCAD is meant for EDA and has only limited ability to enter data on the silk screen layers. For instance, it cannot enter a paragraph of text, only each line which has to be manually lined up.

In defense of KiCAD, their approach is reasonable since nearly all of the silk screen text is just little blurbs on names, functions, pin numbers, and the like. There is no capability for paragraphs or tables like you'd find in a word processor.

The key thing IMO is whether the text on the copper side now is intuitive. One thing I am going to check when I get home tonight is whether the physical switches line up with the binary representations in the text. Ideally, it would read left to right just like regular text with the MSB on the left hand side ( bit 8, switch 1 ) and the LSB on the right hand side ( bit 1, switch 8 ) so you could easily and visually picture what the DIP switch is supposed to be. Assuming you know that 0 means OFF and 1 means ON. :-)

It is easy to get things reversed since the electronics and mathematical order are opposite. You can see the switch labeling is flipped relative to bit order

http://www.jameco.com/webapp/wcs/stores/servlet/ProductDisplay?langId=-1&storeId=10001&catalogId=10001&productId=139012&

I find this very confusing and have been bitten by this particular oddity numerous times. Probably being a bit dyslexic is not helping matters.

Thanks and have a nice day!

Andrew Lynch

lutiana
July 15th, 2009, 02:07 PM
I find this very confusing and have been bitten by this particular oddity numerous times. Probably being a bit dyslexic is not helping matters.


Yeah, umm you lost about a paragraph above this statement. I will look at it closer at home, but it sounds like me putting the table together is a bit of a waste since you need to input it into the program line by line.

NobodyIsHere
July 15th, 2009, 02:23 PM
Yeah, umm you lost about a paragraph above this statement. I will look at it closer at home, but it sounds like me putting the table together is a bit of a waste since you need to input it into the program line by line.

Hi! I added the table to the copper silk screen already so its on there. That was relatively easy. Its trying to figure out if its accurate is what is confusing me. The copper silk screen is "mirrored" already and the flipping of the bits versus switch order is highly disorienting. Take a look at the PCB layout PDF (page 3) in the N8VEM wiki and you'll see what I mean.

I uploaded a new version of the PCB layout. Please do me a favor, take the PCB layout PDF and on page 3 (copper silk screen) with a picture of a 8 position DIP switch, the schematic and compare each line in the table to ensure that the bit positions match the switch positions and that they flow in numerical order right to left (the text reads left to right). You may need a mirror since the text is flipped. I suppose you could print it on a transparency and flip it over.

Thanks and have a nice day!

Andrew Lynch

per
July 15th, 2009, 02:40 PM
Hi! I added the table to the copper silk screen already so its on there. That was relatively easy. Its trying to figure out if its accurate is what is confusing. The copper silk screen is "mirrored" already and the flipping of the bits versus switch order is highly disorienting to me. Take a look at the PDF in the N8VEM wiki and you'll see what I mean.

Thanks and have a nice day!

Andrew Lynch
I've also made an utility (the current SETUP.COM) that displays the switch settings for a card that is about to be installed, if you don't like tabes.

lutiana
July 15th, 2009, 02:51 PM
I uploaded a new version of the PCB layout. Please do me a favor, /snip

Will do. I'll get back to you as soon as I can.

hargle
July 16th, 2009, 05:52 AM
I met up with mbrutman yesterday and he gave me the troublesome IBM hard drive that he had in his collection that refused to read or write for him. It was one single drive out of several that didn't work.

I popped it onto my 486 test machine with one of my cards, and sure enough, it booted right up for me. I didn't do any writes to it, but it attempted to boot to the operating system and worked just fine.

I then moved the drive onto my zenith 8088 using my other card, and the drive worked perfectly there as well.

I may be using a slightly different test BIOS than the 009 release, but I can assure you that there isn't anything in the read/write routines that would have any impact on this vs. other BIOSes.

------
So, I have 2 cards that work with the faulty drive that Mike has. The only thing different is the construction of the 3 cards (since they were all done by hand, this will always be variable) but I don't think that is the issue. I think that only leaves a possible difference in the ICs between all of the cards.

When I get home tonight I will post the exact ICs that I have on my 2 cards, and I should hope that others can do that too. We may just find a commonality between what works and what doesn't. It's possible that I just got lucky with a good combination of parts on my 2 cards and that some of you others have a slightly different mix of parts that is causing a headache.

Either way, I think we've found a drive that needs to be part of our regression testing on future builds of the cards!

mbbrutman
July 16th, 2009, 07:23 AM
I'd also like to add that there is an excellent and unpretentious little Indian cuisine restaurant not too far from where Hargle works ...

hargle
July 16th, 2009, 04:10 PM
Card #8, ICs used.
From left to right:


1) ti-sn74ls138n 2) hd74ls04p 3) hd74ls32p (says malaysia on it)

4) 74F573N
6) Atmel 28c64X eeprom
5) 74F573N

[dipswitch] 7) 74F573N [dipswitch]

8) ti-cd74hct688e 9) ti-SN74F245N 10) ti-cd74hct688e

All of the 74F573's are the same brand.

----------------------
card #1


1) ti-sn74ls138n 2) hd74ls04p 3) hd74ls32p (says malaysia on it)

4) ti-sn74hct573N
6) eeprom-emulator
5) ti-sn74F573N

[dipswitch] 7) 74F573N (singapore) [dipswitch]

8) ti-cd74hct688e 9) ti-SN74F245N 10) ti-cd74hct688e

here I have a mixture of 573 parts.


So, those are golden mixes of ICs.
I have 0 out of ~15 drives that I have tried on the card, and they are all trouble free.

honestly, I wasn't trying to pawn off faulty cards/ICs onto others. It just worked out that way! :)

hargle
July 16th, 2009, 05:05 PM
Ha!

I spoke too soon. Mike's going to point and laugh and say "told ya so". :p

I just came across the error with this drive. It cannot write reliably. The reads seem to be just fine, since I was able to boot the thing, but with mike's approval, I tried to fdisk and format the drive, and the thing just went to hell.

A little bit of playing around so far as shown me that if I blast the first few sectors to all FF's, it writes just fine.
If I try and go back and change the sector to all 00's (using norton diskedit), I get the following sequence on every 16 bytes:


00 FF 00 FF 00 FF 00 00 - 00 FF 00 FF 00 FF 00 00


Looks surprisingly like our 2nd byte of data is missing. can we blame the flip flop not being able to deliver the data fast enough? It's got to be on the harry edge though, since the 8th and 16th bytes are making it just fine.

It's interesting indeed. Not sure if this is within my capability to debug, but I'll keep playing.

Edit: ok,maybe drive strength? I don't think it's timing. I just traced into the BIOS, and single stepped through the first dozen or so writes of data out to drive, trying to change the data from FF to 00, and even after stepping through it by hand, the data didn't change after I read it back. wow. so confusing...

NobodyIsHere
July 16th, 2009, 05:35 PM
I'd also like to add that there is an excellent and unpretentious little Indian cuisine restaurant not too far from where Hargle works ...

My parents are here visiting and they live in Austin Minnesota. That's near your neck of the woods, eh? Not that it has anything to do with Indian cuisine.

At any rate, I posted the PCB for routing on the N8VEM wiki. Please download and run the FreeRouting.net router. Normally, what I do is run on Autorouter -parameter - detail parameter -rip up =100 (default) until it finishes. Then change rip up to 10, repeat, change to 1, repeat, back to 10, repeat, 100, 1000, 10000, 100000, and then cycle back down and up twice. The later cycles will take less time.

http://n8vem-sbc.pbworks.com/browse/#view=ViewFolder&param=XT-IDE

http://www.freerouting.net/fen/index.php

This may seem excessive but the extra cycles will crunch out all the trace slack and unnecessary vias possible. Obviously, having as few vias and the minimum length as possible will improve reliability and performance. It is worth the extra effort.

Thanks and have a nice day!

Andrew Lynch

PS, save frequently!

NobodyIsHere
July 16th, 2009, 05:37 PM
Ha!

I spoke too soon. Mike's going to point and laugh and say "told ya so". :p

I just came across the error with this drive. It cannot write reliably. The reads seem to be just fine, since I was able to boot the thing, but with mike's approval, I tried to fdisk and format the drive, and the thing just went to hell.

A little bit of playing around so far as shown me that if I blast the first few sectors to all FF's, it writes just fine.
If I try and go back and change the sector to all 00's (using norton diskedit), I get the following sequence on every 16 bytes:


00 FF 00 FF 00 FF 00 00 - 00 FF 00 FF 00 FF 00 00


Looks surprisingly like our 2nd byte of data is missing. can we blame the flip flop not being able to deliver the data fast enough? It's got to be on the harry edge though, since the 8th and 16th bytes are making it just fine.

It's interesting indeed. Not sure if this is within my capability to debug, but I'll keep playing.

This sounds like we need someone with a logic analyzer or trace analyzer. Subtle timing incompatibilities are usually a real ***** to find. That's my $0.02.

Thanks and have a nice day!

Andrew Lynch

mbbrutman
July 16th, 2009, 08:21 PM
My parents are here visiting and they live in Austin Minnesota. That's near your neck of the woods, eh? Not that it has anything to do with Indian cuisine.

At any rate, I posted the PCB for routing on the N8VEM wiki. Please download and run the FreeRouting.net router. Normally, what I do is run on Autorouter -parameter - detail parameter -rip up =100 (default) until it finishes. Then change rip up to 10, repeat, change to 1, repeat, back to 10, repeat, 100, 1000, 10000, 100000, and then cycle back down and up twice. The later cycles will take less time.

http://n8vem-sbc.pbworks.com/browse/#view=ViewFolder&param=XT-IDE

http://www.freerouting.net/fen/index.php

This may seem excessive but the extra cycles will crunch out all the trace slack and unnecessary vias possible. Obviously, having as few vias and the minimum length as possible will improve reliability and performance. It is worth the extra effort.

Thanks and have a nice day!

Andrew Lynch

PS, save frequently!

Austin MN is very close to me.

I will make these runs on Saturday morning - that will give me a reasonable block of time to concentrate and do it right. If I have questions I send them using the private message feature here to avoid cluttering the thread.


Mike

mbbrutman
July 16th, 2009, 08:24 PM
Hargle .. utterly craptastic.

Looks like we should have hung around until dark and tried to get some time on a logic analyzer. I see a weekend debug session in the future ...

All thing considered, it is just one of dozens of drives that work correctly. But I'm wondering now if there is something not quite right how much of an effect it is having on other drives, and if anybody is looking for it.


Mike

NobodyIsHere
July 17th, 2009, 03:38 AM
Hi! Mike & Hargle, I appreciate your thoroughness but I think we have to accept we are not going to be able to support 100% of IDE devices. The engineering investigation is goodness but there are just a lot of screwy IDE-like drives and devices out there.

Based on the experiences with the N8VEM Disk IO board which had is own timing issues I would look first at the chip select lines on the drive relative to the controller. That's were we had issues with WD and Quantum drives while Seagate and Maxtor seemed to work just fine. You might even consider trying the "smart cable" approach to tweak the timing sequencing. The N8VEM Disk IO "smart cable" fixed compatibility with WD and Quantum but I just shelved the concept as a PITA to use. The "smart cable" is easy to build as it only requires a small PCB and 2 ICs. It is general though and can be applied to qualify signals with each other. Fixing one drive's timing issues may just break anothers though.

If Mike or someone has a logic analyzer then maybe there is a chance to find the timing issue at its root. Another possibility is just brute force swapping of components among various 74X families until you stumble on the right timing combination or at least reveal clues. Certainly not the preferred approach but something doable until the test tools are available.

Still, no matter what we do there are going to be problematic drives and my suggestion is just to document them on the wiki and press on. The XT-IDE compatibility has been pretty good so far and Hargle, you've done superhuman effort to make the BIOS excellent. Publish the source and let builders tweak it. Maybe something will shake out eventually but I certainly wouldn't stress over it.

Regardless, I support the project and will follow your lead on where you want to go. The next version of the PCB looks really good. My recommendation is to review the new PCB design closely and make sure there are no problems with it that will cause us grief later on.

Thanks and have a nice day!

Andrew Lynch

hargle
July 17th, 2009, 07:01 AM
hey gang,

mike, if you've got a free saturday or sunday and want to pop up to my workplace, we can drag out the logic analyzer and we can get our hands dirty with this thing. The next 2 weekends I'm busy, but the 1st two in august appear to be available currently. Either sat or sunday would work.

I'd be willing to spend at most 1 day trying to get to the bottom of it. Maybe not getting a fix for it, but at least trying to get a bead on what the problem is so that we could make the next step to fix it. I want to put a time limit on such an endeavor entirely because this card is already a home-run in my mind (kb2syd may not think so though!) and we could easily burn a LOT of time trying to get that last 2% working, when there are plenty of drives that seem like they are all working just fine.


---

As for the next proto run, I'll gladly pick up the costs for it, but I think doing any more than 10 cards is a waste. Considering there are only about 5 of us actively working on the debug. I'm willing to pull the trigger anytime the layout is finished.

mbbrutman
July 17th, 2009, 07:32 AM
Still, no matter what we do there are going to be problematic drives and my suggestion is just to document them on the wiki and press on.

My operating system background is going to show through here. Consider the following:


This is a 16GB IBM drive from the DeskStar product line. Not exactly an obscure manufacturer or size.
On my card it IDs, but can't read or write data at all. It's not a case of corruption even - it's a permanent 'drive not ready'.
Hargle is seeing a pretty nice and repeatable pattern of corruption on his cards.


Most of the testing that has been done has been very basic. There might be many other drives out there that are sporadically corrupting bytes, and people won't realize it for a long time until things really get screwy. Our general level of testing isn't robust enough. Put another way, we don't know that all of the other drives are working perfectly.

Before we start 'blacklisting' particular drives and moving on, I want to understand what is special about this not-very-special drive and understand why it is like this. Especially since this pattern of corruption seems to be repeatable, something that I couldn't see with my version of the card because it was just so badly behaved there. After we understand what is wrong, then we need to determine if it applies to other drives or components on the card.

My 2 cents .. nothing more. Hargle has access to test equipment. We just need to find some time to do it.


Mike

hargle
July 17th, 2009, 10:16 AM
On my card it IDs, but can't read or write data at all. It's not a case of corruption even - it's a permanent 'drive not ready'.


This is one of the bits that may help us figure out the issue in a timely manner.
My cards read wonderfully. Yours doesn't, so if we can get some scope/analyzer shots of the differences between the two, we might be able to get some more insight.

My other worry is that I'm not so much of a hardware/scope monkey. I can do a few things on the logic analyzer to be considered dangerous, but setting up complex triggers is outside my comfort zone. We need someone with good hardware skills to help here too.


FWIW: I have a helltest program that writes random data out to random sectors of the drive and then reads it back and compares. You can even do the read portion later, so you can write the data patterns with a known good machine and do reads only on the XT or vice versa. Anyway, said program caught this failure immediately. No other drive I've worked with has had any issue with this program. I see that I don't have it on the wiki, so I will make it available shortly, as I think this is an excellent tool for beating the crap out of the card and any drive that we want to test with. It's likely going to bring out errors faster than just your standard fdisk+format test that most of us are doing.

mbbrutman
July 17th, 2009, 10:21 AM
FWIW: I have a helltest program that writes random data out to random sectors of the drive and then reads it back and compares. You can even do the read portion later, so you can write the data patterns with a known good machine and do reads only on the XT or vice versa. Anyway, said program caught this failure immediately. No other drive I've worked with has had any issue with this program. I see that I don't have it on the wiki, so I will make it available shortly, as I think this is an excellent tool for beating the crap out of the card and any drive that we want to test with. It's likely going to bring out errors faster than just your standard fdisk+format test that most of us are doing.

I was going to write my own, but I'll save some time and use yours. If I can run such a test on a drive for a few hours with no failures, then I'm happy to call things good.


Mike

mbbrutman
July 17th, 2009, 06:36 PM
Andrew,

I've started it running. If I read the directions correctly I am just varying the ripup parameter. The help wasn't very good - can you give me a better description of what this parameter controls, and why it helps to 'massage' the board with it in the pattern you specificed?

It looks really nice on the screen. Too bad it's not threaded ... I could be running it 4x faster.


Mike

Chuck(G)
July 17th, 2009, 07:03 PM
I'm not worried about cutting the capacity of the drive in half. I'm more worried about sector addressing issues.

If you do it that way, then you wind up with the equivalent of 256 byte sectors when they should be 512. Compensating for that is worse than just doing it correctly.

That trick is acceptable on an 8 bit micro where there is no existing API or expectations about sector size. It's not so hot for a PC solution.

From a software standpoint, it doesn't seem that bad to me. Far worse is having 1024 byte physical sectors and blocking/deblocking to 512. But going from bigger logical to smaller physical isn't a problem. You just read or write 2 when the BIOS request asks for 1.

mbbrutman
July 17th, 2009, 07:16 PM
From a software standpoint, it doesn't seem that bad to me. Far worse is having 1024 byte physical sectors and blocking/deblocking to 512. But going from bigger logical to smaller physical isn't a problem. You just read or write 2 when the BIOS request asks for 1.

That also ruins any chance of reading the drive on another system without software help.

That design discussion was a long time ago .. it might be a suitable way to go for a simpler version of the board.


Mike

Chuck(G)
July 17th, 2009, 07:51 PM
Okay, I understand. Nevermind.

per
July 17th, 2009, 09:44 PM
That also ruins any chance of reading the drive on another system without software help.

That design discussion was a long time ago .. it might be a suitable way to go for a simpler version of the board.


Mike

It can simply been an option in the SetCard program too, since it actually only depends on the firmware if the current design is used.

lutiana
July 18th, 2009, 12:26 AM
Still, no matter what we do there are going to be problematic drives and my suggestion is just to document them on the wiki and press on. The XT-IDE compatibility has been pretty good so far and Hargle, you've done superhuman effort to make the BIOS excellent. Publish the source and let builders tweak it. Maybe something will shake out eventually but I certainly wouldn't stress over it.


Here (http://spreadsheets.google.com/ccc?key=rDHsPZGqZNje6Rq7gbtVFzg) is the spreadsheet to document this. Add more rows as needed. I will turn it into a table for our Wiki and keep the table up to date.




My recommendation is to review the new PCB design closely and make sure there are no problems with it that will cause us grief later on.


My suggestions are mostly aesthetic and are non-functional.

Ok, first think I notice is the instructions for JP1 and JP2 are not very clear. Rom Enabled and Right Enabled are sort of floating there with no clear indication. There is a ton of space on the right of the jumpers. Perhaps this could fit in the space:



JPx On = Write Enabled * JPx: On = Rom Enabled*
Off = Write Disabled Off = Rom Disabled

* Default Value


Second thing is Conn_1 is not defined either. It be nice to add a "P-5 = Hard Drive LED" in the space to the right of it.

Maybe after where is says "SW1" put "See back for details" or something like that.

Conn_5x2 also needs the Word "IRQ" somewhere around it. Perhaps make the numbers a bit smaller, and put it centered below it.

Conn_3 needs a bit more explanation as well. There is space below it that could work for this.

Put the number 1 on the left of DIPS_08 and the number 8 on its right, this will help people read and use the table on the back of the card.

On the table on the back of the card put a star next to the default values (and add "* Default" at the bottom). Changing the format could make it a little more readable, try this:



Io Range
Dip Switches 4:1
4 3 2 1
0 0 0 0 = 500h
etc...
1 0 0 0 = 300h*
etc...
0 = Off 1 = On *Default setting.


Adding the dip numbers at the top and adding the space between the numbers would make it a lot more readable and easier to transfer the setting to the front.

Well that my .02 on the text of the card, other than that the layout looks damn good (thumbs up to Andrew for this one).

And in the words of our illustrious circuit designer :D



Thanks and have a nice day!

lutiana
July 18th, 2009, 12:37 AM
Hi! I added the table to the copper silk screen already so its on there. That was relatively easy. Its trying to figure out if its accurate is what is confusing me.

Am to understand from the table that an IO Range of 340h and Memory of E8000-E9FFF would look like this (as you look at the front of the card):



SW1
1 2 3 4 5 6 7 8
0 1 0 1 0 1 0 1


or would it be


SW1
4 3 2 1 8 7 6 5 (ie the switch numbers are not quite sequential)
1 0 1 0 1 0 1 0

NobodyIsHere
July 18th, 2009, 09:36 AM
Andrew,

I've started it running. If I read the directions correctly I am just varying the ripup parameter. The help wasn't very good - can you give me a better description of what this parameter controls, and why it helps to 'massage' the board with it in the pattern you specificed?

It looks really nice on the screen. Too bad it's not threaded ... I could be running it 4x faster.


Mike

Hi Mike! The "rip up" parameter in autoroute/trace optimizer is the parameter that controls the autorouter to set the "weight" in the algorithm as to when it can remove existing traces to help route new traces. The lower the "rip up" weight, the "deeper" the algorithm can search to by pulling up existing traces to route new ones. Larger weights tend to attempt routing with less or no removing of existing traces.

Each approach has its benefits and costs. The deeper searches tends to find routes which eliminate vias that shallower searches miss. Shallower searches tend to be better at reducing the over all length of the traces by improved routing of the current trace paths.

My finding is two full passes through the entire spectrum of rip up weights will produce a very well routed board with minimum vias and tight minimal trace lengths.

The key is to let the optimizer run until completion on each setting. For example, on rip up weight 100 the router will run many passes and keep going until it completes two back to back runs where it can neither reduce vias nor overall trace length.

The PCB started with like 157 vias and >430 inches of overall trace length. With some quick optimization on my home PC I was able to shrink the via count down to 79 or so. I suspect it can go much lower though with some patience in the auto router. Even small simplifications can yield big improvements in signal quality and board reliability so it is definitely worth the extra time needed to crunch the PCB trace routing down as far as it will go.

If you are feeling ambitious, you can also do manual routing to improve results. However, when you manually route you are not as constrained by the rules of the optimizer so you can sometimes introduce "weirdness" that will complicate later trace optimization. The optimizer has all sorts of rules it follows like weights for component versus copper side trace orthogonality, routing angles, etc.

I hope this helps! If you have any questions please let me know. KiCAD/FreeRouting.net is a free tool so that's why I insist on using it. There are commercial solutions available I could use but I want to keep the barriers to entry for the N8VEM builders as low as possible. A truly useful version of Eagle costs many hundreds of dollars although there are limited capability versions available for hobbyists, etc.

Thanks and have a nice day!

Andrew Lynch

NobodyIsHere
July 18th, 2009, 09:58 AM
Am to understand from the table that an IO Range of 340h and Memory of E8000-E9FFF would look like this (as you look at the front of the card):



SW1
1 2 3 4 5 6 7 8
0 1 0 1 0 1 0 1


or would it be


SW1
4 3 2 1 8 7 6 5 (ie the switch numbers are not quite sequential)
1 0 1 0 1 0 1 0



Hi! I think neither is right. I just occurred to me there is yet another level of bit flipping. To register a 0 in an bit, the switch has to be ON to ground the pin. In other words IO=300h, ROM=D0000 would be

SW1

1 2 3 4 5 6 7 8
0 1 1 1 0 1 0 0

which is the exact opposite of what I have on the silk screen table. Argh.

IO=200h, ROM=C0000h would be

SW1

1 2 3 4 5 6 7 8
1 1 1 1 1 1 1 1

IO=3E0h, ROM=FC000h would be

SW 1

1 2 3 4 5 6 7 8
0 0 0 0 0 0 0 0

It appears the table needs some rework. Would adding the a not to the table "0=ON, 1=OFF" be too confusing? Probably.

Thanks and have a nice day!

Andrew Lynch

mbbrutman
July 18th, 2009, 10:03 AM
I only have a rudimentary knowledge of circuits - my last class on it was 16 years ago. I'm fascinated that anything this powerful is free, but I guess that is part of the trend toward open software over the last 15 to 20 years.

Right now I'm very content to let it crunch away. But it is slow. If I interrupt it during a batch run to save the current work instead of letting it run to completion, how bad is that?

Right now it has been running over 12 hours and it has removed 3 vias and 0.33% of the original total trace length.

NobodyIsHere
July 18th, 2009, 10:30 AM
Hi! Thanks for all the great comments on the silk screen labels and notation. This all seems so clear to me on the bench but when staring at it on computer screen is all a jumble. Hopefully this is a better description.

I uploaded a new PCB layout. Please check it out and post any comments on improvements. This is getting better I think.

Thanks and have a nice day!

Andrew Lynch

NobodyIsHere
July 18th, 2009, 10:37 AM
I only have a rudimentary knowledge of circuits - my last class on it was 16 years ago. I'm fascinated that anything this powerful is free, but I guess that is part of the trend toward open software over the last 15 to 20 years.

Right now I'm very content to let it crunch away. But it is slow. If I interrupt it during a batch run to save the current work instead of letting it run to completion, how bad is that?

Right now it has been running over 12 hours and it has removed 3 vias and 0.33% of the original total trace length.

Hi Mike! Yes, FreeRouting.net is notoriously slow so be sure to reserve 3-4 weeks of CPU time to burn through all the iterations. At least that's what it takes on my machines. You can interrupt jobs any time you like and it will just start up from where you left off. However, it starts all passes from the lower left and works to the upper right no matter where you abort.

My recommendation is to save early and often. Just keep running until the optimizer runs out of better solutions and then change the rip up value to perturb the board for more and better crunching. It requires some patience but it will pay off. Some of my N8VEM boards have run for literally months on end.

There is another benefit to running the optimizer that is not immediately apparent... every pass that it changes tends to improve trace orthogonality so that horizontal traces are on component and vertical traces are on copper sides. This is real goodness and improves circuit performance by reducing inadvertent coupling between traces. The fewer traces the better for PCB performance.

Thanks and have a nice day!

Andrew Lynch

mbbrutman
July 18th, 2009, 10:53 AM
Three to four weeks is a serious commitment. I'm hoping this machine does a little better than that. Otherwise, I might draft a machine at work into use - I don't have to worry about people hitting the power switch on those machines.

I hope we don't have any late revisions - starting over would be painful.

lutiana
July 18th, 2009, 02:06 PM
In other words IO=300h, ROM=D0000 would be

SW1

1 2 3 4 5 6 7 8
0 1 1 1 0 1 0 0

which is the exact opposite of what I have on the silk screen table. Argh.

/snip

It appears the table needs some rework. Would adding the a not to the table "0=ON, 1=OFF" be too confusing? Probably.


Yeah, saying 0 = on and 1 = off makes it very difficult to set it properly. Can't you just flip all the bits in the table and leave 0 = off and 1 = on?

The silk screen edits look awesome btw :D

NobodyIsHere
July 21st, 2009, 02:26 AM
Hi! Yes, I will remake the table and hopefully clarify it a bit more. I'll give that a try tonight assuming I get home from work at a reasonable hour. Things at work are ramping up again so I am less available than usual.

Please, as many people as possible, download the schematic and PCB layout and review it as in depth as you can. Look for what you are interested in and ask the questions even if we have discussed it before. We need to know now and I'd rather find the problems *before* we go to PCB production than after. Especially those with electronics and design experience!

Depending on how the second round of testing goes this one design could be the one so I wouldn't save your concerns for the next round because there may not be one. Seriously, constructive criticism is not going to bother me and if you find an issue prior to spending $$$ on a PCB order will make my day.

Thanks in advance!

Andrew Lynch

mbbrutman
July 23rd, 2009, 07:57 PM
Andrew,

I've had a solid week of runtime. I started with ripup at 100, went down to 1, went up to 100,000 and now I'm back down to 10. It has not removed any vias or changed the overall trace length in the last 4 or 5 runs.

I've got it posted at http://www.brutman.com/XT-IDE_v2_optimized.dsn . Can you download it and do a sanity check?

Should I keep going, or is it done? I know you said go through two complete cycles, but I don't think it is going to make any progress.


Mike

NobodyIsHere
July 24th, 2009, 02:27 AM
Hi Mike,
The optimizer trails off towards the end but the reason for two full cycles is to allow it to shorten the overall trace length as much as possible and also improve routing "orthogonality". The autorouter/optimizer is weighted to put all horizontal traces on component side and vertical traces on copper side. It will do some juggling back and forth to improve the balance during the final cycle.

In the past I've noticed that during these final passes occasionally the autorouter/optimizer will make a breakthrough and eliminate a bunch of vias and make major changes to the layout in the process. Then I'll restart the final cycles again due to the resulting disruption of the PCB layout.

During the last couple of weeks things have been very busy at work so I am way behind on everything at home. I'll check out the latest PCB routing. There are design checks in KiCAD which will verify that all the pads are connected and clearances met.

Thanks and have a nice day!

Andrew Lynch

mbbrutman
July 24th, 2009, 05:18 AM
I will go through another cycle then.

greglentz
July 24th, 2009, 07:28 AM
I see there have been some recent postings about problems with Tandy 1000 series computers. I have a working 1000SX machine and while I can't do the kind of programming/logic analyzing you guys need I know my way around computers and hardware and I can use debug to dump code if someone points the way. I had previously posted, long ago, my interest in this project as one of my old mfm/rll drives bit the dust. My primary drive is still ok but a replacement drive for the dead one turns out to be pretty expensive. Moving to IDE drives would make maintenance a lot easier.

Off-topic: Since there seems to be a lot of hardware techs on this board I'll ask. I need to find a replacement 3.5inch 720K floppy drive for my 1000SX (1.44 drives aren't supported, even as a 720K drive). True 720K are scarce and big bucks however my research shows some models of 1.44mb drives can be "hacked" or jumpered into 720K mode for just this purpose. Can anyone suggest where I might get such a drive or even which drive to look for?

Greg Lentz

kb2syd
July 24th, 2009, 09:51 AM
I'm getting ready to ship a 1000 to hargle. It is boxed, and should be at the post office Monday. It took me a while to get everything together.

As for a 720k drive in an SX, I just pulled a 1.44 meg drive off the shelf and made sure to cover the media sense hole in the diskette. Worked perfectly (for me).

mbbrutman
July 24th, 2009, 10:59 AM
Greg,

Please start a new thread for that question - we've over 90 pages in this thread without trying to go off topic. :-)


Mike

NobodyIsHere
July 28th, 2009, 03:20 PM
Hi! I am finally catching up. The good news is I reviewed Mike's DSN file. It is OK. I had to make a couple of tweaks on the trace layout on the edge connector and there is a common radius error on one of the connector pins when I imported the files back into KiCAD. That's fixed.

I updated the copper side silk screen with the correct (I hope) switch settings. 0=off, 1=on like you'd expect. I do not trust that switch settings table and every time I think about it I get confused. The table needs your extra detailed scrutiny.

Also ran the DFM checks and DRC tests and they all are coming back clean.

Here are some files on DFM. Please download the PDFs from the N8VEM wiki XT-IDE folder. That's all for now.

PLEASE, PLEASE, PLEASE, do a thorough review and bring out all your issues and concerns. Even if its a re-hash lets flush out all the problems before this goes to PCB manufacturing.

Once there is hardware on the dock, its TOO LATE!

Thanks and have a nice day!

Andrew Lynch

Click to view Quote for design XT-IDE-full-02.zip: https://www.my4pcb.com/Net35/freedfm/0011697402352279/quote.aspx

New! Click to view PLOTS (beta release) for design XT-IDE-full-02.zip: https://www.freedfm.com/freedfm/0011697402352279/results/plots.htm

Click to view DFM results for design XT-IDE-full-02.zip: https://www.freedfm.com/freedfm/0011697402352279/results/summary2.htm

per
July 29th, 2009, 01:39 AM
Hi! I am finally catching up. The good news is I reviewed Mike's DSN file. It is OK. I had to make a couple of tweaks on the trace layout on the edge connector and there is a common radius error on one of the connector pins when I imported the files back into KiCAD. That's fixed.

I updated the copper side silk screen with the correct (I hope) switch settings. 0=off, 1=on like you'd expect. I do not trust that switch settings table and every time I think about it I get confused. The table needs your extra detailed scrutiny.

Also ran the DFM checks and DRC tests and they all are coming back clean.

Here are some files on DFM. Please download the PDFs from the N8VEM wiki XT-IDE folder. That's all for now.

PLEASE, PLEASE, PLEASE, do a thorough review and bring out all your issues and concerns. Even if its a re-hash lets flush out all the problems before this goes to PCB manufacturing.

Once there is hardware on the dock, its TOO LATE!

Thanks and have a nice day!

Andrew Lynch

Click to view Quote for design XT-IDE-full-02.zip: https://www.my4pcb.com/Net35/freedfm/0011697402352279/quote.aspx

New! Click to view PLOTS (beta release) for design XT-IDE-full-02.zip: https://www.freedfm.com/freedfm/0011697402352279/results/plots.htm

Click to view DFM results for design XT-IDE-full-02.zip: https://www.freedfm.com/freedfm/0011697402352279/results/summary2.htm
There is an error: 8765 should be 5678, and the same with 4321; it should be 1234. The values are correct.

After this is fixed, the tables could also be swaped, so the I/O Range is on the left (or rigth as it will appear in the inverted version from the PDF) and ROM-address on the rigth (or left as it will appear in the inverted version from the PDF).

hargle
July 29th, 2009, 05:39 AM
those web based layouts look fantastic. I like how simple it is to view the stuff too.

If I'm understanding that quote properly, it looks to be about $150-200 more expensive than the stuff we did in china. (for 10 parts)
I'll do it if you think it's a requirement that we use this fab house, but I'd like to check with our friends overseas too. I think they did a really good job on the last run.

------

I've got a tandy HX en route to me right now, should be here in a day or two.
There may be some things that need to be changed depending on how this machine works, so we can't quite wrap it up just yet.

mbbrutman
July 29th, 2009, 07:42 AM
Just a warning ... the trace optimization is still running. I'm still going through the last cycle, so don't do anything more until it's done and I give Andrew the last version.

(Andrew jumped the gun .. he convinced me to keep going, then started working with the partial results.)


Mike

NobodyIsHere
July 29th, 2009, 07:52 AM
those web based layouts look fantastic. I like how simple it is to view the stuff too.

If I'm understanding that quote properly, it looks to be about $150-200 more expensive than the stuff we did in china. (for 10 parts)
I'll do it if you think it's a requirement that we use this fab house, but I'd like to check with our friends overseas too. I think they did a really good job on the last run.

------

I've got a tandy HX en route to me right now, should be here in a day or two.
There may be some things that need to be changed depending on how this machine works, so we can't quite wrap it up just yet.



Hi! Yes, I would recommend 4PCB if there are features only they can provide but the manufacturer used last time should be just fine. There is nothing fancy about this design except for maybe the gold fingers on the card edge connector. The rest is bog standard PCB stuff. I don't think 4PCB is necessary here but I do get quotes from them since the free DFM service is convenient and helpful. Their prices are pretty high though.

The drawings I posted are in "near final" condition with the exception of the updated trace layout for the PCB from Mike as soon as it is available. Please download the drawings and verify as thoroughly as possible.

Thanks and have a nice day!

Andrew Lynch

mbbrutman
July 29th, 2009, 09:13 AM
And two more vias just got removed in the past hour. We're down to 53. :-)

NobodyIsHere
July 29th, 2009, 04:37 PM
There is an error: 8765 should be 5678, and the same with 4321; it should be 1234. The values are correct.

After this is fixed, the tables could also be swaped, so the I/O Range is on the left (or rigth as it will appear in the inverted version from the PDF) and ROM-address on the rigth (or left as it will appear in the inverted version from the PDF).

Hi Per! Thanks! You are right and the table was completely flipped!

I changed it all around and reposted the PDF on the N8VEM wiki.

Thanks! I appreciate your great catch! Have a nice day!

Andrew Lynch

per
July 30th, 2009, 12:56 AM
Hi Per! Thanks! You are right and the table was completely flipped!

I changed it all around and reposted the PDF on the N8VEM wiki.

Thanks! I appreciate your great catch! Have a nice day!

Andrew Lynch

Now, the tables are fine, but isn't it better if the whole thing is centered on the design?

NobodyIsHere
July 30th, 2009, 02:15 AM
Now, the tables are fine, but isn't it better if the whole thing is centered on the design?

Hi Per! Thanks! There has to be some space reserved for the installation of brackets which pushes everything to the right on the front of the board (left on the back) to reserve room for the drill holes and and machine screws, etc. I can move the tables to the left on the back a bit but not much.

Thanks and have a nice day!

Andrew Lynch

per
July 30th, 2009, 04:28 AM
Hi Per! Thanks! There has to be some space reserved for the installation of brackets which pushes everything to the right on the front of the board (left on the back) to reserve room for the drill holes and and machine screws, etc. I can move the tables to the left on the back a bit but not much.

Thanks and have a nice day!

Andrew Lynch

That's problably fine. I just don't like the text being that close to the edge of the PCB.

mbbrutman
August 6th, 2009, 03:28 PM
Andrew - I think it's pretty much done now. Have a look.


http://www.brutman.com/XT-IDE_v2_optimized.dsn


I am going to be out of touch for a bit - don't have too much fun without me!


Mike

NobodyIsHere
August 9th, 2009, 09:34 AM
Hi! I have DFM results for the latest PCB layout. I think we are ready to go. Any final thoughts need to get in soon!

Thanks and have a nice day!

Andrew Lynch

Click to view Quote for design XT-IDE-full-04.zip: https://www.my4pcb.com/Net35/freedfm/0011697402362123/quote.aspx

New! Click to view PLOTS (beta release) for design XT-IDE-full-04.zip: https://www.freedfm.com/freedfm/0011697402362123/results/plots.htm

Click to view DFM results for design XT-IDE-full-04.zip: https://www.freedfm.com/freedfm/0011697402362123/results/summary2.htm

per
August 9th, 2009, 09:55 AM
Hi! I have DFM results for the latest PCB layout. I think we are ready to go. Any final thoughts need to get in soon!

Thanks and have a nice day!

Andrew Lynch

Click to view Quote for design XT-IDE-full-04.zip: https://www.my4pcb.com/Net35/freedfm/0011697402362123/quote.aspx

New! Click to view PLOTS (beta release) for design XT-IDE-full-04.zip: https://www.freedfm.com/freedfm/0011697402362123/results/plots.htm

Click to view DFM results for design XT-IDE-full-04.zip: https://www.freedfm.com/freedfm/0011697402362123/results/summary2.htm

I thought the default ROM segment was at C800:0, not D000:0... Else, it looks great!

per
August 12th, 2009, 09:28 AM
Next week I will try to test the IDE-card with a 286 turbo-card. I do expect a difference in speed, but I don't know how much.

hargle
August 12th, 2009, 10:22 AM
hopefully by next week I will have my tandy 1000 wired up (I have to make an ISA converter) and then I can figure out what is going on with the rom corruption and keyboard weirdness.

the following week I'm on vacation, but after that, full steam ahead with rev 2 and all the stuff associated with it.

per
August 12th, 2009, 11:04 AM
hopefully by next week I will have my tandy 1000 wired up (I have to make an ISA converter) and then I can figure out what is going on with the rom corruption and keyboard weirdness.

the following week I'm on vacation, but after that, full steam ahead with rev 2 and all the stuff associated with it.

a Write-disabled jumper will problably fix most of the problems I think. What I think may be the issue is that there is some writes into the ROM, maybe made by the BIOS, maybe another program.

Too bad I don't have a Tandy 1000, or the bios files, so I can't try to do any debugging on that cause.

hargle
August 12th, 2009, 07:39 PM
Got a tandy 1000 HX machine; made my own port adapter so I could plug the XTIDE in. Not very much progress.

I can't get any IO to decode. For whatever reason, all unused ports on the T1000 return a 0x0e back when reading under debug. It should normally be 0xff, meaning that no one is decoding at that port.

I could barely find a single port that didn't return back 0x0e. 3d1 and 3d3 did, but with our card plugged in and supposedly decoding at 0x300, all I got back were more 0x0e's.

Without that working, there's nothing I can do. I'm going to throw some more cards into this thing and see if they decode properly. Stay tuned.

there are a slew of other problems to tackle as well, but this is the biggest.

hargle
August 15th, 2009, 11:21 AM
Good news everyone!

I managed to boot to a hard drive on the Tandy 1000 HX!!!!!

(please ignore the post directly above this one. I couldn't get the card to decode at 300h, because it was jumpered at 380. No wonder I couldn't find it!)

here's the details:

1) the default base address of D000 for the ROM conflicts with something inside the tandy machine. Just changing the jumpers to D800 made it work fine.

2) the tandy power on default video mode doesn't decode CR/LF, so even if you did fix #1, you wouldn't be able to see anything since all the text overwrites itself. I fixed this by adding a quick change to 80x25 video mode early in the BIOS.

3) Upon first initialization, the IDE ROM goes and examines the size of base memory, and subtracts 1k off it. this one 1k is then reserved for the XTIDE controller as a scratchpad for storing variables and as a location to issue the "identify device" command to get the model number for the sign-on screen.
I believe that the tandy is weird with that chunk of memory (reserved for video or something?) and what happens is that the IDE ROM steals 1k, issues ID to the drive, then reads the data back. The data isn't there, so the IDE ROM says that no drive is found. However, on the very next reboot (ctrl-alr-del, not a power up) the BIOS does the same stealing of 1k from the top of 640 again, but this time it would be stealing memory at 638k, not 639k. This memory appears to be not used by anything else, and then the IDE BIOS is able to install itself, issue ID properly, read the drive data back and everything is go.

This can easily be worked around by examining the machine type byte in the system BIOS and if it's a Tandy, just bump ourselves down another k at install time, and everything should be golden from there.

Now, some caveats:
I'm using my ROM emulator box for it. The tandy may very well be doing writes into our ROM, which corrupt it without the write protect jumper on the next rev. hopefully that's all that is happening.

There's some funkies in the boot menu. It shows there are 2 floppy drives, and it didn't display the model # of the installed hard drive. I also took the timeout out of the "press [esc]..." message, because it was originally locking up the machine, which I need to look into.
None of these are show stoppers.

Amazing turn of events here. I really had no hope for this card working, and now I see no reason why it wouldn't work.

Forward ho with the next rev of the card for sure!

http://www.waste.org/~winkles/tandyxtide.jpg

tezza
August 15th, 2009, 11:44 AM
Well done!

Now I have an IBM AT with the (dodgy) older hard drives, I suddenly have much more interest in this project! :)

Tez

NobodyIsHere
August 15th, 2009, 05:33 PM
Hargle! You are da MAN!

Good job!

Thanks and have a nice day!

Andrew Lynch

Great Hierophant
August 15th, 2009, 05:52 PM
Good news everyone!

I managed to boot to a hard drive on the Tandy 1000 HX!!!!!

(please ignore the post directly above this one. I couldn't get the card to decode at 300h, because it was jumpered at 380. No wonder I couldn't find it!)

here's the details:

1) the default base address of D000 for the ROM conflicts with something inside the tandy machine. Just changing the jumpers to D800 made it work fine.

2) the tandy power on default video mode doesn't decode CR/LF, so even if you did fix #1, you wouldn't be able to see anything since all the text overwrites itself. I fixed this by adding a quick change to 80x25 video mode early in the BIOS.

3) Upon first initialization, the IDE ROM goes and examines the size of base memory, and subtracts 1k off it. this one 1k is then reserved for the XTIDE controller as a scratchpad for storing variables and as a location to issue the "identify device" command to get the model number for the sign-on screen.
I believe that the tandy is weird with that chunk of memory (reserved for video or something?) and what happens is that the IDE ROM steals 1k, issues ID to the drive, then reads the data back. The data isn't there, so the IDE ROM says that no drive is found. However, on the very next reboot (ctrl-alr-del, not a power up) the BIOS does the same stealing of 1k from the top of 640 again, but this time it would be stealing memory at 638k, not 639k. This memory appears to be not used by anything else, and then the IDE BIOS is able to install itself, issue ID properly, read the drive data back and everything is go.

This can easily be worked around by examining the machine type byte in the system BIOS and if it's a Tandy, just bump ourselves down another k at install time, and everything should be golden from there.

Now, some caveats:
I'm using my ROM emulator box for it. The tandy may very well be doing writes into our ROM, which corrupt it without the write protect jumper on the next rev. hopefully that's all that is happening.

There's some funkies in the boot menu. It shows there are 2 floppy drives, and it didn't display the model # of the installed hard drive. I also took the timeout out of the "press [esc]..." message, because it was originally locking up the machine, which I need to look into.
None of these are show stoppers.

Amazing turn of events here. I really had no hope for this card working, and now I see no reason why it wouldn't work.

Forward ho with the next rev of the card for sure!

http://www.waste.org/~winkles/tandyxtide.jpg

Are you sure your scratchpad RAM will not conflict with the way the Tandy's share the video memory? In an Tandy with less than 768K of RAM, the video controller will use 16-32K of the RAM at the top of the conventional memory space by default. Do you have to use 2K of RAM instead of the 1K that you use in non-Tandys?

The HX tech ref does not indicate that there is anything at D000.

per
August 16th, 2009, 03:02 AM
Well done!

Now I have an IBM AT with the (dodgy) older hard drives, I suddenly have much more interest in this project! :)

Tez

With an AT, you can even use one of the 16-bit combined Floppy/IDE adapters. They tend to be pretty common, and they give better performance because of the 16-bit bus (this card has to convert it to 8-bit, and that's what makes it special).

The only thing you'll need for a 16-bit Floppy/IDE card is a BIOS extension that makes it utilize the IDE adapter. Some of those cards even got the BIOS ready for use.

hargle
August 16th, 2009, 07:13 AM
Are you sure your scratchpad RAM will not conflict with the way the Tandy's share the video memory?

not at all! these tandy machines are weird. Obviously there's a conflict we me taking some upper memory, so we need to find somewhere it can go when we detect it's a tandy machine instead.


In an Tandy with less than 768K of RAM, the video controller will use 16-32K of the RAM at the top of the conventional memory space by default. Do you have to use 2K of RAM instead of the 1K that you use in non-Tandys?

Good information!
Looking at it now, I see that the tandy does indeed report the top of memory just fine: the value at 40:13 is 270h, which is 624k of base memory. (I have a 640k machine), so 16k of it is reserved for video. What the IDE card should have done is checked this value, removed 1 from it, then install its 1k buffer at 623-624k. That should just work, provided everyone is using and respecting that pointer at 40:13. I'll investigate some more as to why this doesn't seem to work on the first go around.

XTIDE only needs 1k of space. I could actually do with 1/2 of that, but 1k is a nice round number, and if I'm using that pointer at 40:13, that's the granularity anyway. If we have to get really creative on the tandy, so be it.



The HX tech ref does not indicate that there is anything at D000.
yeah, I don't see anything there either, except the tandy's floating bus.
I get all E8's when I dump that memory out, except for a few straggling bytes that are changing. Looks like it's free, but when I had the card there, it would hang at the "base memory size = 640k" initial startup screen. All I had to do was move it and it fired right up.

Overall, I think I just got really, really lucky that this thing worked yesterday. None of the things I thought I had to do/fix seem to actually be problems! Man this thing is weird.
I'll keep playing, obviously.

hargle
August 16th, 2009, 09:00 AM
http://www.waste.org/~winkles/tandyfit.jpg

For those of you with tandy machines who are interested in this controller, how were you planning on mounting the card inside the machine?

This is the way mine works, with my adapter cable. the card is about 1/2" too tall to fit that way. I was wondering if I can use the lower pin connectors instead of the taller one, and if I were to use a longer cable, I might be able to have the card flipped over the other way and have the cable underneath.

or is there any chance that rev 2 of this card is somehow slightly shorter?

NobodyIsHere
August 16th, 2009, 09:06 AM
Hi! Does the card work flipped the other way and laying component side down on top of the floppy drive on the right? Please be sure to put down some sort of insulating layer of plastic or paper between the card and any other components especially metal ones...

Thanks and have a nice day!

Andrew Lynch

hargle
August 16th, 2009, 10:08 AM
That could work; may be a really tight fit due to the cover of the machine coming down at an angle toward the front of the floppy drive. There is not much room there at all!

I think I can do something like this:
http://www.waste.org/~winkles/tandyfit2.jpg

at the moment, the adapter connector doesn't fit in the lower pin header on the tandy expansion, so the edges will need to be removed, and then the 2nd header is so friggen tall, that it's causing the card to stick up a little bit too high. I may have to take the dremel to it and remove the top half of that header... it's so incredibly close of a fit, it's almost like we planned it that way. :)

this is of course assuming that the 2nd, lower pin header is identical to the taller one off the tandy expansion. can anyone verify that before I plug it in?

THEN there's the whole issue of power. there are no spare power connectors to power the drive from. I suppose I can branch off the floppy drive, but sheesh. I'll have to build my own power cable for that.

tezza
August 16th, 2009, 10:18 AM
With an AT, you can even use one of the 16-bit combined Floppy/IDE adapters. They tend to be pretty common, and they give better performance because of the 16-bit bus (this card has to convert it to 8-bit, and that's what makes it special).

Opps, duh, silly me. It's 8-bit. It's XT owners who would really benefit.

Tez

Agent Orange
August 16th, 2009, 10:20 AM
http://www.waste.org/~winkles/tandyfit.jpg

For those of you with tandy machines who are interested in this controller, how were you planning on mounting the card inside the machine?

This is the way mine works, with my adapter cable. the card is about 1/2" too tall to fit that way. I was wondering if I can use the lower pin connectors instead of the taller one, and if I were to use a longer cable, I might be able to have the card flipped over the other way and have the cable underneath.

or is there any chance that rev 2 of this card is somehow slightly shorter?

On the 1000SX, the card will mount in the in the normal fashion in a verticle slot.

Mike Chambers
August 16th, 2009, 11:05 AM
the card works perfectly in my tandy 1000tx, and of course they're normal ISA ports so it all fits in like any other card.

hargle
August 17th, 2009, 06:36 AM
the card works perfectly in my tandy 1000tx, and of course they're normal ISA ports so it all fits in like any other card.

Very cool. Then maybe the HX is the oddball and the most difficult, and thus since it appears that I can get it to work there, then we may have solved all of the potential tandy issues. (with the rev 2 card anyway)

Now if we could just jam one of these into a PCjr, we'd be set! :)

NobodyIsHere
August 17th, 2009, 06:45 AM
Hi! We can re-size the card but that's a respin. It's an option although I would suggest we reserve it for only when there is absolutely no other choice due to time required. If there is a lot of space needed vertically, then we are probably looking at a shorter but longer card and a new layout of the ICs.

Thanks and have a nice day!

Andrew Lynch

hargle
August 17th, 2009, 09:46 AM
I think we're good on the size of the card, unless there are any other tandy variants that are even more space restrained than this HX is. (anyone know?)

It appears there is plenty of space horizontally, so a shorter but longer card would work. It also looks like just moving all the ICs down 1/4" and then shaving off 1/4" off the top would also work, but again, I don't think any of this is going to be required. It'll be tight, but I'll be able to do it.

I am hoping to be able to do a little dremel action tonight on mine and I will report back if mine fits in the space. I think it will.

Is that unreasonable that purchasers of the xtide may require physical mods to their machines to get it to work? ;)

kb2syd
August 17th, 2009, 09:59 AM
I think we're good on the size of the card, unless there are any other tandy variants that are even more space restrained than this HX is. (anyone know?)


The HX is as small as it gets. Still troubles me that this card didn't work in any machine I tried it in, even something as simple as a bare 486. I didn't change the settings at all when I had it, and I couldn't even flash it after a few days. I may need to check the power supply to my basement work area.

lutiana
August 17th, 2009, 10:15 AM
Is that unreasonable that purchasers of the xtide may require physical mods to their machines to get it to work? ;)

I think the real question is there enough people out there that would require a low profile 8 bit IDE Card for any kind of machine?

per
August 17th, 2009, 11:37 AM
I think the real question is there enough people out there that would require a low profile 8 bit IDE Card for any kind of machine?

We had a poll some time ago that showed positive ressults...

Great Hierophant
August 17th, 2009, 11:55 AM
Good information!
Looking at it now, I see that the tandy does indeed report the top of memory just fine: the value at 40:13 is 270h, which is 624k of base memory. (I have a 640k machine), so 16k of it is reserved for video. What the IDE card should have done is checked this value, removed 1 from it, then install its 1k buffer at 623-624k. That should just work, provided everyone is using and respecting that pointer at 40:13. I'll investigate some more as to why this doesn't seem to work on the first go around.

XTIDE only needs 1k of space. I could actually do with 1/2 of that, but 1k is a nice round number, and if I'm using that pointer at 40:13, that's the granularity anyway. If we have to get really creative on the tandy, so be it.

I would hope looking at the pointer should be able to find the top of the free conventional memory area regardless of the graphics mode the Tandy adapter uses. The text, 160x200x16, 320x200x4 and 640x200x2 modes all require 16K, the 320x200x16 and 640x200x4 require 32K and the 640x200x16 64K.

By the way, do you think this thread should be split off into a new thread at 100 pages or 1000 posts?

lutiana
August 17th, 2009, 12:08 PM
We had a poll some time ago that showed positive ressults...

Must have missed it.

gerrydoire
August 17th, 2009, 05:12 PM
Not that this has anything directly to do with the IDE Prodject but.

Being a person who owns an Acculogic, I've been trying various CF Cards to see which ones will work with the card "as is" and boot.

The results are interesting:

The card will NOT boot any make of CF Card except Kodak(Lexar)

I have a 128 and a 512 meg card, both will boot, tested with Dos 2000
on an XT.

I've tried many other makes of cards, none will boot, 128meg, 256, 512,
2 gig, none of them will boot under the same circumstances.

Go figure...

hargle
August 17th, 2009, 06:56 PM
gerrydoire: you should go get a prom burned of our latest BIOS. All you need to do is change the base address using the setup utility to 360h (or I can do that for you) and then you can have your acculogic card booting any sized compact flash card. No reason to wait for our card when yours is ready to roll right now...


tandy HX news: Success! I've moved the adapter cable to the lower pin header and dremeled off the higher one, and now the card fits easily in the space available.
The next step is to try and find power for the IDE drive. I figured I could just tap off the floppy power, but I took it apart just now and there is *no* power going to the drive. It's powered via the cable? It all looks so standard 34 pin floppy to me; I didn't know you could power off that... man these things are weird! have to break out the multimeter and see if I can find a 12 and 5v power source...

Mike Chambers
August 18th, 2009, 12:02 AM
gerrydoire: you should go get a prom burned of our latest BIOS. All you need to do is change the base address using the setup utility to 360h (or I can do that for you) and then you can have your acculogic card booting any sized compact flash card. No reason to wait for our card when yours is ready to roll right now...


tandy HX news: Success! I've moved the adapter cable to the lower pin header and dremeled off the higher one, and now the card fits easily in the space available.
The next step is to try and find power for the IDE drive. I figured I could just tap off the floppy power, but I took it apart just now and there is *no* power going to the drive. It's powered via the cable? It all looks so standard 34 pin floppy to me; I didn't know you could power off that... man these things are weird! have to break out the multimeter and see if I can find a 12 and 5v power source...

oh yeah, HX's are goofy machines. wish mine didn't get tossed in the garbage. it was a fun one to play with. don't bother though, there's no 12 volt line on it. only 5 volt. it's identical to the floppy drives in the TX.

JohnElliott
August 18th, 2009, 12:20 AM
I think we're good on the size of the card, unless there are any other tandy variants that are even more space restrained than this HX is. (anyone know?)

Not a Tandy, but the Sinclair PC200 has a very oddly-shaped ISA bay. Full-length but only about half the proper height. If you want to have any cards plugged in you have to leave the sunroof open :)

dalbert
August 18th, 2009, 03:00 AM
I'm joining this late, but would be happy to contribute and am excited about being able to use an IDE drive in my vintage PC and XT. I am pretty handy with Eagle/PCB layout/hardware design and X86 assembler/C/C++...please let me know if I can help.

Which PCB mfgr do you use in China?

We often use PCB-Pool for smallish boards...have you tried them?

Thanks for this project...it is a great idea!

kb2syd
August 18th, 2009, 04:49 AM
Tandy 1000 hx:
The next step is to try and find power for the IDE drive. I figured I could just tap off the floppy power, but I took it apart just now and there is *no* power going to the drive. It's powered via the cable? It all looks so standard 34 pin floppy to me; I didn't know you could power off that... man these things are weird! have to break out the multimeter and see if I can find a 12 and 5v power source...

The GVP-50 taps the +12 and +5 from the buss and adds a 4 pin plug on the card. Many hard disk on a card ISA boards had this. You can do something similar.

The HX floppy cable carries the power on a couple of what would be ground pins on a standard floppy cable. They run 3 or 4 in parallel so it can provide enough current. So, you could also split the power out there. See this thread:
http://www.vintage-computer.com/vcforum/showthread.php?t=15854

for the pinouts on the HX.

Kelly

Great Hierophant
August 18th, 2009, 05:37 AM
tandy HX news: Success! I've moved the adapter cable to the lower pin header and dremeled off the higher one, and now the card fits easily in the space available.
The next step is to try and find power for the IDE drive. I figured I could just tap off the floppy power, but I took it apart just now and there is *no* power going to the drive. It's powered via the cable? It all looks so standard 34 pin floppy to me; I didn't know you could power off that... man these things are weird! have to break out the multimeter and see if I can find a 12 and 5v power source...

The drives in an HX are powered through the drive cable. You can find +5v on pins 3,5,7,9,11 and +12v on 29,31,33.


oh yeah, HX's are goofy machines. wish mine didn't get tossed in the garbage. it was a fun one to play with. don't bother though, there's no 12 volt line on it. only 5 volt. it's identical to the floppy drives in the TX.

PC floppy drive motors, at least of the HX's era generally require +12v, and the HX is no different.

hargle
August 18th, 2009, 06:41 AM
OK, I think I've got the HX power sorted out. The small power cable that runs from the power supply over to the motherboard has 12v and 5v lines on it, so I'm going to tap that and run a line over to a hard drive power adapter.

Apologies that I'm pulling the thread way off topic while doing this.

dalbert: I think you will be an excellent addition to the team, being able to play in both hardware and software land. I used http://pcbcart.com/ to do the 1st prototype board. China based, but the quality seems to be excellent, and the cost wasn't too bad. With a run of 10 boards, 4.5x4.25, the cost was $175.

I think we're just about to pull the trigger on revision 2, it would be most excellent if you were to give it a quick design review:
http://n8vem-sbc.pbworks.com/f/Printing%20XT-IDE-sch.pdf

I can also make the bios source code available to you (x86 assembly) but there seems to be enough of us working there already that the BIOS is fairly well covered. It will all end up being open source eventually, but for now it's actually easier to keep some cooks out of the kitchen to make version tracking possible.

NobodyIsHere
August 18th, 2009, 08:17 AM
tandy HX news: Success! I've moved the adapter cable to the lower pin header and dremeled off the higher one, and now the card fits easily in the space available.
The next step is to try and find power for the IDE drive. I figured I could just tap off the floppy power, but I took it apart just now and there is *no* power going to the drive. It's powered via the cable? It all looks so standard 34 pin floppy to me; I didn't know you could power off that... man these things are weird! have to break out the multimeter and see if I can find a 12 and 5v power source...

Good Gracious, that Tandy HX is one weird duck! At what point is it easier to just pull out all the components and mount them in an XT clone case or zip tie them to a piece of plywood? :-)

Thanks! Have a nice day!

Andrew Lynch

shawn510
August 18th, 2009, 11:12 AM
Good to hear that it is working on a HX.
Will it work in a Tandy with the built-in "Smartdrive" XTIDE controller? My first candidate for the card when it comes out is a TL/2.

nathan
August 18th, 2009, 12:34 PM
I'm *just* now getting to this, but had a few questions if someone in the group would like to take a stab at them:

1. I am set up to fab PCBs here at home, nothing fancy of course but something like this should be no problem. Are the original layout files available, and if so, in what format are they / which layout program was used? I may actually like to convert the layout to surface-mount since that's more convenient for me fabrication-wise (no drilling!) and the soldering is no biggie once you learn how.

2. Where can I get a PROM(?) burned with the option BIOS for this board?

3. I am soon to be in possession of a 5150 which I believe is one of the earlier BIOS versions. Is it possible to upgrade the bios in this machine (S/N 0197797) in order to use expansion cards with option ROMs?

Thanks a lot! This looks like such an awesome and genuinely useful project! :-)

per
August 18th, 2009, 01:32 PM
I'm *just* now getting to this, but had a few questions if someone in the group would like to take a stab at them:

1. I am set up to fab PCBs here at home, nothing fancy of course but something like this should be no problem. Are the original layout files available, and if so, in what format are they / which layout program was used? I may actually like to convert the layout to surface-mount since that's more convenient for me fabrication-wise (no drilling!) and the soldering is no biggie once you learn how.

2. Where can I get a PROM(?) burned with the option BIOS for this board?

3. I am soon to be in possession of a 5150 which I believe is one of the earlier BIOS versions. Is it possible to upgrade the bios in this machine (S/N 0197797) in order to use expansion cards with option ROMs?

Thanks a lot! This looks like such an awesome and genuinely useful project! :-)

1. Send lynchaj a PM, he got the files.
2. I can't help you there, but you can get the binaries from the VC wiki.
3. Very few PC's have the first BIOS, as IBM upgraded it within half a year from the original release. You may be in (or in your cause; out) of luck to get one with the firs BIOS, but you can allways burn a later BIOS to an EPROM and place that in the 5150. Just note that IBM used some unusual kind of ROM chip in the 5150, so you problably have to make an adapter if you are used to 27xx EPROMs.

*Edit*
Nevermind. Only the third revision of the PC BIOS will support BIOS extension.

hargle
August 18th, 2009, 05:57 PM
New BIOS available:
http://wiki.vintage-computer.com/index.php?title=XTIDE_project#Downloads

Rev 0.10

If you're not using the card on a tandy machine, there's no real reason for you to upgrade. All the fixes put in place were to get it to work properly on my HX.

from the history.txt file:
Note: ROMS prior to this release will not work on a tandy (HX) machine!
* quick switch to 25x80 text mode before sign-on banner. made it possible for Tandy to display.
* Interrupts enabled before pressing Press [ESC] for boot menu...
* Boot menu now displays drive model number on a tandy HX.

I haven't actually tested this code on a NON tandy machine, but I see no reason why anything I've done would cause it to fail. the changes were really minor.

Oddly enough, I am now using my card at ROM address D000 again, and it works just fine. I also didn't modify anything with where the scratch pad is being reserved at; it is all working exactly as it should. Kinda creepy, but this is a tandy machine! I'm also using kb2syd's card, and it's behaving nicely. I flashed it on the tandy itself just fine, and I'm using a Seagate ST310014ACE drive out of an xbox 1. All 8G of the drive is available via 4 partitions. It's perfect.

I even got a power hookup. I tapped into the mainboard power lead and spliced in one of those Y power splitters. Seems to be happy, and I very well may attach a CF card to this thing too, since there's really no way to get external data onto the drive other than the floppy. The 2nd power connector from the Y splitter is sitting behind the floppy drive.

http://www.waste.org/~winkles/tandywdrive.jpg

I think with just a little bit of squishing I can get the cover back on. Now to play some King's Quest on it!

Mike Chambers
August 18th, 2009, 08:28 PM
oh thats killer hargle! now i want my HX back so i could do this to it. :(

i never used it much just because i couldn't have an HDD on it.