Image Map Image Map
Page 1 of 10 12345 ... LastLast
Results 1 to 10 of 96

Thread: XT-IDE rev 4 Development

  1. #1
    Join Date
    Jan 2010
    Location
    Central VA
    Posts
    4,105

    Default XT-IDE rev 4 Development

    I've been working on revision 4 of the Hargle/N8VEM open source XT-IDE design. It started off with the following changes, mostly suggested by users here and on IRC:

    • Better parts numbering (U1 is top left, U2 to its right, et c.)
    • Thicker/more consistent silkscreen (some board houses produced illegible/broken silkscreen on some labels and symbols)
    • Larger pads around some of the jumper headers
    • Better pin 1 indication for ICs
    • Rotate IC part number text (e.g. 74LS68 to match typical orientation on ICs
    • Change bypass cap values to match parts kit (changed to C instead of a uF value)


    I also added better test points with labels on both the front and the back to make the Slot 8 Support mod board easier to install, and routed *CARDSEL through the last DIP position on the I/O address switches. The status LED got flipped so that I can use some right-angle LEDs I've got in stock on personal builds, too.

    During the process, I ran into Alan Hightower (eeguru) at VCF East, who is working on the NetPi-IDE Raspberry Pi interface. He'd ran into a timing problem with how the high byte is latched on the XT-IDE and had to work around it with his FPGA design. He described the problem to me, which seemed to be a race condition on the read side of things: when *IOR de-asserted from the ISA bus, a sufficiently fast ATA device, like his NetPi-IDE board, would present invalid data to the high byte latch before it could de-assert and latch the data. This is due to the propagation delay in the logic on the original Hargle/N8VEM design, which I think is worth keeping as it preserves BIOS compatibility with the older BIOSes. The solution is to slow down the *IOR signal a little. I hooked up the HP 1650A logic analyzer to take a look:



    IORISA is the *IOR strobe essentially directly off of the ISA bus. IORIDE is the same signal after passing through four sections of a 74LS04 inverter, this adds around 20 nS of gate delay. HI RD is the latch strobe to U1, the high byte read latch that stores the upper 8 bits of the ATA device's output data during a read, so we can grab it later. As seen in the timing diagram, where HI RD used to lag IORISA by 10 nS, it now leads by 10 nS due to the 20 nS delay chain. This means the latch stores its value 10 nS before the ATA device stops outputting valid data, which is well within the spec for even the 74LS573 latch (the kits typically come with 74F573 latches, because I have a supply of them).

    I decided to go ahead and check out the write timing as well, though it hadn't been pointed out as a problem:



    IOWIDE is the *IOW signal essentially directly off of the ISA bus. HI WR is the latch strobe for storing the upper byte before doing a 16-bit write to the ATA device. HI OUT is the delayed "2 signal" from the XT-IDE logic (I've since relabeled it *HI_BYTE_OUT on the schematic, which I think is clearer). It was delayed by running it through two sections of a 74LS04 inverter and one section of a 74LS32 OR gate, with one input of the OR gate tied to ground. As seen in the timing diagram, *HI_BYTE_OUT now de-asserts 10 nS after the *IOW line, ensuring that data is presented to the ATA device for 10 nS past the end of the ATA write operation. I'm not sure if many (or any) ATA devices are this picky about the timing, but correcting it at the same time as making other rev 4 changes didn't require any spare gates.

    All of this was breadboarded on an old XT-IDE rev 3 prototype board from the initial rev 3 design, with a 74LS04 dead-bugged onto the circuit board and wired in. I made the read delay chain modifications and had some more prototypes run. Alan has one of them, which he used to confirm that the read timing was fixed. I modified a second with a socket for the 74LS04 so that I could test faster devices, as well as adding in the high byte output delay. I tested 74S04, 74LS04, 7404, and 74F04 devices, to make sure that whatever got stuck in there by someone assembling an XT-IDE would provide sufficient delay. All provided sufficient delay, the 7404 was the only measurable difference, providing around 25 nS instead of 20 nS, which is fine.

    I've ordered production boards for the XT-IDE rev 4, since I'm almost out of XT-IDE rev 3 boards from the last run. They'll look approximately like this:





    Those are from the earlier prototype order, since then I've switched the OSHW logo to a copper/solder mask relief, and moved the identification text back toward the OSHW logo. There have been some routing tweaks as well, but nothing major, other than adding in the hi byte output delay. Probably the biggest change people will notice is the extra 74LS04, and the switch to custom IC silkscreen legends from the stupid defaults included in newer KiCad releases. I'd stuck with the older KiCad 2.x style IC silkscreens on the rev 3 board because I thought the pin 1 designations were really, truly awful on KiCad 4.x default libraries.
    Last edited by glitch; August 15th, 2017 at 10:06 AM.

  2. #2
    Join Date
    Mar 2011
    Location
    Atlanta, GA, USA
    Posts
    1,248

    Default

    James Pierce also noticed the same and added a similar fix to his boards. I noticed it when testing a memory mapped port of JR-IDE to ISA. I think it will make many more ATA devices work with the board.

    Thanks for your hard work!
    "Good engineers keep thick authoritative books on their shelf. Not for their own reference, but to throw at people who ask stupid questions; hoping a small fragment of knowledge will osmotically transfer with each cranial impact." - Me

  3. #3
    Join Date
    Oct 2014
    Location
    near frankfurt/m, germany
    Posts
    708

    Default

    Two more wishes:
    - A 16 BIT AT version also would be welcome.
    - Enable/Disable Olivetti M24 / AT&T 6300 compatibiliy mode by jumper for the 8 bit version - or even better: special M24 16 bit version ...

  4. #4

    Default

    I second the notions of kudos for your engineering skill and hard work. I sure as hell couldn't do it.

  5. #5
    Join Date
    Mar 2009
    Location
    Pleasant Hill, CA USA
    Posts
    2,586
    Blog Entries
    1

    Default

    Quote Originally Posted by 1ST1 View Post
    Two more wishes:
    - A 16 BIT AT version also would be welcome.
    Just use a regular 16 bit IDE controller with the XT-IDE Universal BIOS housed in a free ROM socket (network card are great for this). Works perfectly.

    IBM 5160 - 360k, 1.44Mb Floppies, NEC V20, 8087-3, 45MB MFM Hard Drive, Vega 7 Graphics, IBM 5154 Monitor running MS-DOS 5.00
    IBM PCJr Model 48360 640kb RAM, NEC V20,, jrIDE Side Cart, 360kb Floppy drives running MS-DOS 5.00
    Evergreen Am5x86-133 64Mb Ram, 8gb HDD, SB16 in a modified ATX case running IBM PC-DOS 7.10

  6. #6

    Default

    Yes, the lo-tech 8-bit MUX honours the timing spec in both directions as well.

  7. #7
    Join Date
    Jan 2014
    Location
    Melbourne, Australia
    Posts
    523

    Default

    This is awesome! Great work man. My rev3 board is a wonder, I don't know what I did without it! Looking forward to the new rev.

    Bobby.
    Bobby.

  8. #8
    Join Date
    Jan 2010
    Location
    Central VA
    Posts
    4,105

    Default

    Thanks, everyone! Again, there's no reason to upgrade from an earlier board if your board is doing what you need -- these changes just increase ATA device compatibility, which seems to already be pretty good. If you were planning on doing a Slot 8 Support modification, the rev 4 makes that slightly easier.

    Quote Originally Posted by 1ST1 View Post
    Two more wishes:
    - A 16 BIT AT version also would be welcome.
    - Enable/Disable Olivetti M24 / AT&T 6300 compatibiliy mode by jumper for the 8 bit version - or even better: special M24 16 bit version ...
    As mentioned, you can use a regular 16-bit ISA IDE card if your machine has a 16-bit ISA bus, with the XUB on a network card or something else with a ROM socket (you could even use an XT-IDE board with only the ROM parts populated).

    I'm not sure what you mean by M24/6300 compatibility mode. Part of the reason that the Compatibility/Chuck Mod mode jumpers were retained (rather than doing a permanent Chuck Mod) was to keep the board compatible with M24/6300 systems. Is there something more required? I don't have one to test with.

  9. #9
    Join Date
    Oct 2014
    Location
    near frankfurt/m, germany
    Posts
    708

    Default

    Quote Originally Posted by lutiana View Post
    Just use a regular 16 bit IDE controller with the XT-IDE Universal BIOS housed in a free ROM socket (network card are great for this). Works perfectly.
    Yes, possible, but with disadvantages:
    a) needs an regular 16 bit IDE controller. Hard to get...
    b) needs a free ROM socket

  10. #10
    Join Date
    Jan 2010
    Location
    Central VA
    Posts
    4,105

    Default

    Quote Originally Posted by 1ST1 View Post
    Yes, possible, but with disadvantages:
    a) needs an regular 16 bit IDE controller. Hard to get...
    b) needs a free ROM socket
    You can also use a 16-bit IDE channel on a sound card, if you have one with real IDE on it (some cards have a manufacturer-specific header that only works with a handful of CD drives). I could certainly lay out a 16-bit IDE board, there's not much more than some buffers and decode logic to it, but the board would probably be $15-20 for the bare board due to the larger number of gold-plated edge contacts and size increase. At that point, you might as well buy a vintage 16-bit IDE board -- if people are having a hard time finding these, I have several to go through, test, and sell. Most are multi-IO, too, so you get floppy and often serial/parallel.

    If there's enough interest in a 16-bit IDE card with ROM socket, I'll add it to the list of things to be laid out and run, but it just seems that they're way too common/cheap currently to really justify spending the time and money on running boards.

    W.R.T. the ROM socket, a network card is, as mentioned, a popular option, since most people want Ethernet on their vintage PCs nowadays anyway. You can also use an XT-IDE board with only the ROM circuitry populated, which has the added benefit of being able to program its own EEPROM. If anyone is having a hard time finding a 16-bit controller/ROM board combination, PM me and I'd be happy to put something together from my surplus parts!

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •