Hi,

I just finished a nasty IDE header repair, that required me to trace some of the IDE signals back to source in order to reconnect them to the badly damaged header.

Lacking a schematic for the player makes repairs very tricky, but I think I now understand some more of how it is wired up internally.

The SA-1100 has a built-in PCMCIA controller -- which basically presents an ISA bus (IBM PC AT expansion bus) interface for the CPU and peripherals. The IDE drives (which by definition have built-in controller electronics) simply attach directly to this bus, as does the CS4231A, the USB controller, and other stuff (?).

If both the CS4231A and the IDE are not working, it could be due to:

(1) the logic that manages chip selects for them, if there is any such logic (they could just be using separate address lines for each device). To check this, one will need to customize a kernel to loop repeatedly, toggling the chip select(s) high for one second, then low for one second, ad infinitem, so that you can then use a logic probe / scope / voltmeter to test for the signal(s) getting to the CS4231A pins. Then repeat this test for the IDE header CSEL lines.

(2) the problem could be the IDE header, but if you disconnect all drives and the CS4231A still fails, then the header is likely innocent.

Anyway, the way to get this player working again is to use the approach described in (1) above -- custom code here and there to toggle appropriate signals, and see which ones are getting to the chip and which ones are not.

The code would be like this:

while (1) {

   unsigned long timestamp = jiffies;

   unsigned char data = 0xff;

   while (jiffies < (timestamp + HZ))

       outb_p(data, port_address);  // or inb() 

   while (jiffies < (timestamp + (HZ+HZ)))

       outb_p(0x00, port_address);  // or inb()

}

Note to picky programmers: the jiffie logic is not 100% correct, but is simple and works well enough for this isolated situation.

Cheers