• Please review our updated Terms and Rules here

Forthcoming XT-IDE Board - Cast Your Vote

Forthcoming XT-IDE Board - Cast Your Vote

  • As original XT-IDE, with a 40-pin header only

    Votes: 4 10.5%
  • With a 44-pin header and board space to mount a 2.5" IDE HDD (i.e. a hard-card)

    Votes: 7 18.4%
  • With an optional Compact Flash socket (as master or slave) and a 40-pin header

    Votes: 26 68.4%
  • With a Compact Flash socket only

    Votes: 1 2.6%

  • Total voters
    38
  • Poll closed .

pearce_jj

Veteran Member
Joined
May 14, 2010
Messages
2,808
Location
UK
Ian at Dangerous Prototypes has ported the existing XT-IDE board design to a 'CPLD' based design, which means that the whole circuit design can be programmed. In other words, as well as ROM changes, circuit design changes can be implemented by reprogramming it!

So far two prototype boards have been made and have worked with every disk and compact flash card so far tested (only about 10 devices, but a promissing start) and it works fine in PC/XT and higher-spec machines too (tested up to Pentium III I think).

Currently a v2 board is being drawn up, which will have even less components than the prototype, but there are several ideas being thrown around. Hence I would like to collect please opinions on it - please cast yor vote!

For those interested:

 
The Hard Card is a neat idea, and would be nice. But I think ultimately it would be too limiting, same with only putting a CF slot on the card.

The CF and 40 pin option is nice because it allows for quite a bit of flexibility in storage options, plus CF cards are easy to find in any size needed, and plugging one in makes it a solid state drive for an 8 bit PC which is pretty cool.
 
CF is 21st century? From my understanding, they're on the way out, being replaced by higher-capacity, cheaper, and ever-faster SDHC cards, whether full-size or micro. About the same for 44-pin vs 40-pin. Unless you have alot of laptop spares, 44-pin cables aren't usually in the parts bins. 40-pins are, as is the ever-present 44->40 pin 2.5" adapters.

That said, I'm happy with anything, and whatever keeps costs down. If a 40-pin IDE is on there, I can add an IDE->CF adapter cheaply (I have several). If a 44-pin IDE, I have a cable in the parts bin. If a CF, I have a spare 4gb microdrive out of an iPod mini upgrade and/or a few different CF card sizes.

Although I wouldn't be ordering Ian's board until after the v2 XT-IDE comes out. I want to see what Hargle, Andrew, et. al. have come up with.

And I think that there's room on Ian's board for a floppy simulator if someone was on-board to program software for it. Now THAT would be a cool adapter.

(as I'm still drooling over Chuck's proof-of-concept)
 
...which means that the whole circuit design can be programmed. In other words, as well as ROM changes, circuit design changes can be implemented by reprogramming it!
That's not quite accurate. They didn't add the latches to the CPLD nor did they route most of the signals through it. The CPLD in his design is only being used as an address decoder. It means changes similar in scope to the 'Chuck mod' have to still be done with wire rework. I routed everything through the JR-IDE board's CPLD. All IDE pins and all relavent bus pins are connected directly to 5V GPIOs and everything is through hole. I have more proving out to do on the JR-IDE board this weekend then I need to make all the necessary changes for a P2 board spin early next week. I'm also planning a P1 spin of an ISA version (with only IDE and Flash disk) at the same time. The design files for the JR-IDE P1 are here and the discussion thread (very long) is here. I'll be updating things next week (and moving the site) to include the PLD code once the P2 design is finalized. JR-IDE has the 'Chuck Mod' implemented for writes as well as reads and uses memory mapped I/O. DMA could be doable for the ISA version as well as I experimented with a self bus-mastering version for the JR.

The current layout I have for the ISA CPLD board is literally a single chip + header + a couple offset socket pads for either a 28 or 32 pin 27xx/28xx ROM (28 pin) or 39SF0x0 Flash (32 pin and much much cheaper).

The JR version also has a flush PCB board mount for a 2.5 hard drive (screwed in from the back of the PCB). I ran out of real-estate in my Eagle license to add a 40 pin .1" header as well. With CF, you're back into SMD and the tighter pitch of most sockets combined with the proximity to plastic is going to make soldering them more challenging with an iron vs hot air.
 
That's not quite accurate...changes similar in scope to the 'Chuck mod' have to still be done with wire rework

We've demonstrated the v1a board with Chuck-mod via reprogrammed CPLD - possibly at crossed-purposes though?

I routed everything through the JR-IDE board's CPLD....JR-IDE has the 'Chuck Mod' implemented for writes as well as reads and uses memory mapped I/O

I'm very interested in your implementation and how the circuit design has been modified to run the enhanced writes! So thanks for the links, I'll have a good look through later. The "100% CPLD" approach is what the v2 board being discussed here is going for also.

The JR version also has a flush PCB board mount for a 2.5 hard drive (screwed in from the back of the PCB).

This is very neat for sure, and I like neat :) but I'm not sure it makes the board more future proof than CF, and anyway the cheapest 2.5" IDE HDD is 10x the price of a (1GB) CF card (of course many of us will have such drives sitting about though). As the recent range of Canon Pro bodies are CF based, hopefully it will be around for some time to come yet.

Thanks for all the input thus far!!
 
We've demonstrated the v1a board with Chuck-mod via reprogrammed CPLD - possibly at crossed-purposes though?

I'm very interested in your implementation and how the circuit design has been modified to run the enhanced writes! So thanks for the links, I'll have a good look through later. The "100% CPLD" approach is what the v2 board being discussed here is going for also.

I was using Chuck's change as a flexibility example. For him to get the registers ordered to correctly fetch the lower bus value and then the upper bus latched value, he had to cut and switch two address lines. Those address lines are not routed through the CPLD in the DP design. So it isn't ideal in a sense. To do things ideally, you would have the 24 necessary independent IDE signals, the 33 necessary ISA signals, 4 DMA, ROM CS, and possibly bus clock routed to pins on a PLD (63 total requiring a PLCC-84 or TQFP-100). Then soft code everything in the middle. That's what I've tried to do. And by using a true 5V part with a high drive current, there isn't a need to add separate buffers for IDE either. You can literally do it with one chip and change 100% of it. I apologize for this turning into a design discussion about architecture. And there's already been a number of discussions on PLD part choice and positions well voiced.

Ian has done nice work and I definitely thank him. But I think there is still a little room for improvement. Just adding my $.02
 
I appreciate your input on this. Just confused about the chuck-mod, as the DP design does do the expected 230KB/s with it (and without any physical changes to the board). But then, it doesn't take much to confuse me :)
 
Ian included Chuck's address lines changes in his board version. However if anything needed to be changed again, exacto and iron time.

I just registered over a DP forums and continuing the design discussion there.
 
I'm with the SD/SDHC idea. Cheap, small and definitely what everyone seems to be using. I view CF in the same light that I view PATA--yes, you can get it, but it's definitely not on the leading edge. I just picked up a bunch of "universal flash card readers"--and CF isn't one of the card types supported. Since the protocol is serial, the incremental expense of adding another CF socket is pretty much the cost of the socket.

On the other hand, microcontrollers with integral USB support capable of hosting USB flash drives are now inexpensive (and 3.3V, but that's a different issue) and readily available. That aspect does hold a certain attraction, as USB ports are everywhere and heck, USB flash drives are given away as door prizes now.

These retrofits are becoming harder. I was reading about a new line of DSP µCs that are inexpensive and fast. Then I started reading the specs--1.8V (okay, I can deal with translating to 5V logic; it just gets harder) and available only in fine-pitch BGA (definitely not in the DIY category).

And who's this "Chuck" guy, anyway? :)
 
Any chance of getting the PCB short enough that it could be hacked into a PCjr sidecar without needing any cutting? (Or, heck, making one physical PCB that could do double-duty as either a standard PC/XT card or a PCjr sidecar with just the soldering on of the sidecar slots and putting in a sidecar enclosure?)
 
On the other hand, microcontrollers with integral USB support capable of hosting USB flash drives are now inexpensive (and 3.3V, but that's a different issue) and readily available. That aspect does hold a certain attraction, as USB ports are everywhere...
I had started down the path of doing this with a PLD and USB MCU but there was seemingly no interest and I also had no time. People kept responding with "Why USB? SD & CF adapters are cheap and plentiful.." That was also the almost unanimous response to the same idea but with a USB-SATA bridge on the back-end and the possibility of optical storage and ATA CD-ROM emulation.

These retrofits are becoming harder. I was reading about a new line of DSP µCs that are inexpensive and fast. Then I started reading the specs--1.8V (okay, I can deal with translating to 5V logic; it just gets harder) and available only in fine-pitch BGA (definitely not in the DIY category).

Microchip PIC32s (MIPS R4K), Atmel AT32UC3xxx (AVR-32) and FTDI VNC2s (proprietary 16-bit) all would do the job fine for XT class speeds. If you wanted to extend the USB idea to faster machines (ATs and up), they all have a common problem of effective USB through-put. Each tops out at 400-600 KB/s max. AT32UC3A3s are the only possibility in that bunch that may be able to go higher. But none will come close if you have to do a lot of state processing to interface as a slave on the host bus at an IDE register level. And they all have little to no hardware support for interfacing as a parallel slave. That's where I was going with using PLD as the perfect hardware glue. The PLD provides a hardware IDE register file, sector ring buffers, and throws an interrupt on register write to an MCU that's filling the requests from USB mass storage or whatever else. The concept never picked up much traction.

IAnd who's this "Chuck" guy, anyway? :)
I heard he was an idiot savant but a bit of a trouble maker.
 
Any chance of getting the PCB short enough that it could be hacked into a PCjr sidecar without needing any cutting? (Or, heck, making one physical PCB that could do double-duty as either a standard PC/XT card or a PCjr sidecar with just the soldering on of the sidecar slots and putting in a sidecar enclosure?)

You mean like this?

jride_board.jpg


See post #5 of this thread for links to the JR-IDE effort.

1MB of RAM, 512 Flash, RTC, POST, bus activity monitor, IDE interface.
 
You mean like this?
See post #5 of this thread for links to the JR-IDE effort.

1MB of RAM, 512 Flash, RTC, POST, bus activity monitor, IDE interface.

Squee! How did I miss the fact that JR-IDE meant PCjr??? Make a CF card fit entirely internally, and it's perfect to me!
 
lol I love how legit you aimed. Even an IBM drive on there ;-)

:) That was just the only 2.5" PATA drive Fry's still carries. PATA is just getting rare. I'm starting to think P2 just needs a 40 pin .1" header and a co-layout for CF. I'll see if I can fit that in. I just hate putting something that is SMT with a .5mm pitch with near-by melt-able plastic. But I suppose it's needed.

One of the 2 fatal flaws that board has is the 44 pin 2mm header you see there is backwards. I had to put a ribbon cable on it to flip the pins before the drive would power up and work. The other flaw was the drills for the side car connector were too small for the friction-lock pins. I had to grind down 60+ pins with a Dremmel.
 
I'm up to page 23 so far on the JR-IDE discussion, and what is very clear is that much of ground being covered by the DP CPLD build has already been covered there, and that Hargle's XT-IDE Mk.II is further along that I'd thought.

I'm really interested in the memory-mapped IO being discussed, and indeed whether it would be possible and hopefully not frowned upon to make the DP CPLD code BIOS compatible with what is being built elsewhere. Indeed there seems to be much overlap with the JR-IDE already. I guess the key as stated already is to get enough connections to the CPLD to make it entirely programmable.

Anyway, many thanks for all the input thus far!
 
Back
Top