Windows DTL-H10030 Driver

[SilverBull]

Some .inf magic later:



But don't get your hopes up too soon, I'm afraid the real roadblocks have not even shown up yet.

I'm using a LogConfigOverride to reserve 4K of system physical address space. This solves the problem of the card not having a CONFIG tuple, but unfortunately it doesn't tell the PCMCIA bus driver that it should not attempt to configure the card (i.e., put the base address of said memory region somewhere into the attribute space). I haven't found the correct INF directive yet, and don't even know whether there is one.

Next problem: the assignment of my custom driver to the card's node itself does not work. This would mean that, in above image, getting rid of the "Sony DTL-/SCPH-10190 PCMCIA Card" entry and installing the SMAP Controller driver for the device enumerated by the PCMCIA bus driver. If trying to do this, it refuses to assign resources. I have no idea what's going on, so there is a dirty hack in place: I use the multifunction driver as a "proxy" for the PCMCIA device. MF gets the LogConfigOverride, PcCardConfig and MfCardConfig directives, and seems to be perfectly happy with that. Then, it enumerates a single child node and assigns all resources to it. That's the node my SMAP Controller driver gets loaded for. Neat side effect: it gets its resources via regular PnP means, because MF acts as a full PnP bus driver. No LogConfigOverride necessary .

Luckily, MF also passes all relevant requests to the real PCMCIA driver stack, including QUERY_INTERFACE and READ_CONFIG. Above test uses BUS_INTERFACE_STANDARD::GetBusData on PCCARD_ATTRIBUTE_MEMORY, starting at offset zero, 4 bytes at a time. Granted, its extremely slow in comparison to a single memory read, but at least it returns some data. If you compare it to the output I posted yesterday, you'll see its the same structure .

Although the memory window is mapped to virtual address space, I do not use it to access the card. I currently do not know how to use PCMCIA_MODIFY_MEMORY_WINDOW to create the mapping at the PCMCIA bridge, because its arguments are not sufficiently documented by MS . Quote:

AccessSpeed [in, optional] Specifies the access speed of the PC Card or CardBus card. The value of AccessSpeed is encoded as specified by the PC Card Standard, Release 6.1. If Enable is FALSE, AccessSpeed is not used.

Does anyone have a copy of the PC Card Standard? I guess I can continue using GetBusData, but speed will be abysmal.

[SilverBull]

I hit a road block, as expected .

The card does not seem to access its devices for memory reads (and possibly writes, too) from the common memory space. I dumped the first 0x800 bytes (using what seems to be 16-bit accesses, at least if I interpret the PCMCIA controller's registers correctly), but they all read as zero. I had expected a view similar to what the PS2 showed when in normal mode: control registers at +0x0, ATA at +0x40.

As the card is reported as an I/O card, I'm afraid it wants to get I/O accesses (don't know whether PCMCIA can distinguish between common and attribute memory spaces for these, though). If I guessed correctly, the DTL-H10190 maps its devices with a starting base of zero; the call to pcic_ssbus_mode(5) in ps2dev9 then changes the controller to output I/O accesses instead of normal memory ones, and the PS2 can perform I/O accesses to the card via the mapping at 0xB0000000. It clearly switches from all-zeros to config space by the first two writes in card_find_manfid, and again from config space to "normal operation space" by pcic_ssbus_mode(5) afterwards. Unlike x86, the MIPS/R3000 does not have separate I/O and memory spaces, so if the card really needs I/O cycles, there must be an external register (possibly some bit in the SSBUS or DEV9 range) controlling the corresponding PCMCIA pins.

Now, why is this I/O space mapping a problem for Windows (XP in my case)? Because MS's PCMCIA bus driver does not support I/O port remapping . This means that I/O ports being accessed must have the same numerical value on both sides of the PCI-/PCMCIA-bridge. So I would need I/O ports 0x00-0x80 or so for the PCMCIA device, but unfortunately this is entirely within the port range used by regular x86 mainboard devices...

I will try to remap ports by accessing the controller registers directly. Unfortunately, that will make the driver depend on the PCMCIA bus driver (I need to parse its in-memory structures, and maybe even invoke one of its internal routines via a hard-coded address); but if it works, it'll still be better than nothing. Hopefully my PCMCIA controller really is a Ricoh 5C476II and implements these registers, otherwise I'm really lost...

Or does anybody else have an idea what I could be doing wrong, or why the card would not react to memory reads? A kingdom for a PCMCIA bus analyzer...

[PS2Guy]

I hit a road block, as expected .

The card does not seem to access its devices for memory reads (and possibly writes, too) from the common memory space. I dumped the first 0x800 bytes (using what seems to be 16-bit accesses, at least if I interpret the PCMCIA controller's registers correctly), but they all read as zero. I had expected a view similar to what the PS2 showed when in normal mode: control registers at +0x0, ATA at +0x40.

As the card is reported as an I/O card, I'm afraid it wants to get I/O accesses (don't know whether PCMCIA can distinguish between common and attribute memory spaces for these, though). If I guessed correctly, the DTL-H10190 maps its devices with a starting base of zero; the call to pcic_ssbus_mode(5) in ps2dev9 then changes the controller to output I/O accesses instead of normal memory ones, and the PS2 can perform I/O accesses to the card via the mapping at 0xB0000000. It clearly switches from all-zeros to config space by the first two writes in card_find_manfid, and again from config space to "normal operation space" by pcic_ssbus_mode(5) afterwards. Unlike x86, the MIPS/R3000 does not have separate I/O and memory spaces, so if the card really needs I/O cycles, there must be an external register (possibly some bit in the SSBUS or DEV9 range) controlling the corresponding PCMCIA pins.

Now, why is this I/O space mapping a problem for Windows (XP in my case)? Because MS's PCMCIA bus driver does not support I/O port remapping . This means that I/O ports being accessed must have the same numerical value on both sides of the PCI-/PCMCIA-bridge. So I would need I/O ports 0x00-0x80 or so for the PCMCIA device, but unfortunately this is entirely within the port range used by regular x86 mainboard devices...

I will try to remap ports by accessing the controller registers directly. Unfortunately, that will make the driver depend on the PCMCIA bus driver (I need to parse its in-memory structures, and maybe even invoke one of its internal routines via a hard-coded address); but if it works, it'll still be better than nothing. Hopefully my PCMCIA controller really is a Ricoh 5C476II and implements these registers, otherwise I'm really lost...

Or does anybody else have an idea what I could be doing wrong, or why the card would not react to memory reads? A kingdom for a PCMCIA bus analyzer...

Dude you are seriously the man. Thanks for this. It wasn't really a big deal, and I appreciate all that you're doing. If it doesn't work, it doesn't work, and that's cool.
The driver is always something that I've wondered about. It just seems weird that Sony hasn't got one.

[sp193]

I hit a road block, as expected .

The card does not seem to access its devices for memory reads (and possibly writes, too) from the common memory space. I dumped the first 0x800 bytes (using what seems to be 16-bit accesses, at least if I interpret the PCMCIA controller's registers correctly), but they all read as zero. I had expected a view similar to what the PS2 showed when in normal mode: control registers at +0x0, ATA at +0x40.

As the card is reported as an I/O card, I'm afraid it wants to get I/O accesses (don't know whether PCMCIA can distinguish between common and attribute memory spaces for these, though). If I guessed correctly, the DTL-H10190 maps its devices with a starting base of zero; the call to pcic_ssbus_mode(5) in ps2dev9 then changes the controller to output I/O accesses instead of normal memory ones, and the PS2 can perform I/O accesses to the card via the mapping at 0xB0000000. It clearly switches from all-zeros to config space by the first two writes in card_find_manfid, and again from config space to "normal operation space" by pcic_ssbus_mode(5) afterwards. Unlike x86, the MIPS/R3000 does not have separate I/O and memory spaces, so if the card really needs I/O cycles, there must be an external register (possibly some bit in the SSBUS or DEV9 range) controlling the corresponding PCMCIA pins.

Now, why is this I/O space mapping a problem for Windows (XP in my case)? Because MS's PCMCIA bus driver does not support I/O port remapping . This means that I/O ports being accessed must have the same numerical value on both sides of the PCI-/PCMCIA-bridge. So I would need I/O ports 0x00-0x80 or so for the PCMCIA device, but unfortunately this is entirely within the port range used by regular x86 mainboard devices...

I will try to remap ports by accessing the controller registers directly. Unfortunately, that will make the driver depend on the PCMCIA bus driver (I need to parse its in-memory structures, and maybe even invoke one of its internal routines via a hard-coded address); but if it works, it'll still be better than nothing. Hopefully my PCMCIA controller really is a Ricoh 5C476II and implements these registers, otherwise I'm really lost...

Or does anybody else have an idea what I could be doing wrong, or why the card would not react to memory reads? A kingdom for a PCMCIA bus analyzer...

I remember that the DEV9 module writes a value to the MANFID region within the pcic_ssbus_mode() function, and it seems to reconfigure the device to reveal it's hardware registers in the MANFID area....

Then again, I know nearly nothing about the PCMCIA specification. D:

[Tokimemofan]

I hit a road block, as expected .

The card does not seem to access its devices for memory reads (and possibly writes, too) from the common memory space. I dumped the first 0x800 bytes (using what seems to be 16-bit accesses, at least if I interpret the PCMCIA controller's registers correctly), but they all read as zero. I had expected a view similar to what the PS2 showed when in normal mode: control registers at +0x0, ATA at +0x40.

As the card is reported as an I/O card, I'm afraid it wants to get I/O accesses (don't know whether PCMCIA can distinguish between common and attribute memory spaces for these, though). If I guessed correctly, the DTL-H10190 maps its devices with a starting base of zero; the call to pcic_ssbus_mode(5) in ps2dev9 then changes the controller to output I/O accesses instead of normal memory ones, and the PS2 can perform I/O accesses to the card via the mapping at 0xB0000000. It clearly switches from all-zeros to config space by the first two writes in card_find_manfid, and again from config space to "normal operation space" by pcic_ssbus_mode(5) afterwards. Unlike x86, the MIPS/R3000 does not have separate I/O and memory spaces, so if the card really needs I/O cycles, there must be an external register (possibly some bit in the SSBUS or DEV9 range) controlling the corresponding PCMCIA pins.

Now, why is this I/O space mapping a problem for Windows (XP in my case)? Because MS's PCMCIA bus driver does not support I/O port remapping . This means that I/O ports being accessed must have the same numerical value on both sides of the PCI-/PCMCIA-bridge. So I would need I/O ports 0x00-0x80 or so for the PCMCIA device, but unfortunately this is entirely within the port range used by regular x86 mainboard devices...

I will try to remap ports by accessing the controller registers directly. Unfortunately, that will make the driver depend on the PCMCIA bus driver (I need to parse its in-memory structures, and maybe even invoke one of its internal routines via a hard-coded address); but if it works, it'll still be better than nothing. Hopefully my PCMCIA controller really is a Ricoh 5C476II and implements these registers, otherwise I'm really lost...

Or does anybody else have an idea what I could be doing wrong, or why the card would not react to memory reads? A kingdom for a PCMCIA bus analyzer...

It may be a bit odd but in your test PC, have you looked up the PCMCIA chipset? There is a possibility your chipset is buggy. I have several that refuse to work with multifunction cards (such as the Sandisk 6-in-1 card reader which changes it's ID based on the type of card inserted) Another took a few years to find a Wi-Fi card that it actually liked. Another thing that can trip these things up is ACPI. If you ever get a driver beta going, I would be happy to help testing it.

[PS2Guy]

If you ever get a driver beta going, I would be happy to help testing it.

Me too. As I sort of asked the question in the first place. But like I've kept saying "not really a big deal"

[SilverBull]

Dude you are seriously the man. Thanks for this. It wasn't really a big deal, and I appreciate all that you're doing. If it doesn't work, it doesn't work, and that's cool.
The driver is always something that I've wondered about. It just seems weird that Sony hasn't got one.

You're welcome. I actually had a similar idea and wanted to write a driver for this card for some time, so its really no big deal for me. And even if it doesn't work, the time won't be wasted because we'll hopefully learn why; either saving others the time or encouraging them to try where we stopped .

I remember that the DEV9 module writes a value to the MANFID region within the pcic_ssbus_mode() function, and it seems to reconfigure the device to reveal it's hardware registers in the MANFID area....

Then again, I know nearly nothing about the PCMCIA specification. D:

Do you mean the line "SPD_REG8(0x20) = 1;"? I thought that already went to I/O space (I'll just call it that for now, even though I don't know which bus cycles are used to access it), but I'll recheck.

Do you have an idea why the parameter to pcic_ssbus_mode is called "voltage"? It only accepts values 3 and 5, but the only call in the entire dev9 driver uses a hard-coded 5 as its parameter. Could this be Vpp (auxiliary power)?

By the way, this is how the memory mapping looks like on my TOOL during card initialization. This is two days old, so it doesn't include the dumps from before and after above write to SPEED space. I'll get these later today.

Before card_find_manfid
dsidb S> dh 0xbf801460 0x20
0xbf801460: 0x0000 0x01f8 0x0000 0x0000 0x0010 0x0090 0x0017 0x0020
0xbf801470: 0x0000 0x0001 0x0000 0x0000 0x0000 0x0000 0x0000 0x0001
dsidb S> dw bf801418 c
0xbf801418: 0x001a00bb 0xef1a3043 0x00051011
dsidb S> db 0xb0000000
0xb0000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb0000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb0000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb0000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb0000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb0000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb0000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb0000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb0000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb0000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb00000a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb00000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb00000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb00000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb00000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb00000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

################################################## #############################
After card_find_manfid
dsidb S> dh 0xbf801460 0x20
0xbf801460: 0x0002 0x01f8 0x0000 0x0000 0x0010 0x0090 0x0017 0x0020
0xbf801470: 0x0000 0x0001 0x0000 0x0000 0x0000 0x0000 0x0000 0x0001
dsidb S> dw bf801418 c
0xbf801418: 0x001a00bb 0xef1a3043 0x00051011
dsidb S> db 0xb0000000
0xb0000000: 01 00 03 00 d9 00 01 00 ff 00 1c 00 04 00 02 00 ................
0xb0000010: d9 00 01 00 ff 00 20 00 04 00 f1 00 00 00 00 00 ...... .........
0xb0000020: 53 00 21 00 02 00 fe 00 01 00 15 00 5c 00 07 00 S.!.........\...
0xb0000030: 00 00 28 00 43 00 29 00 32 00 30 00 30 00 30 00 ..(.C.).2.0.0.0.
0xb0000040: 20 00 53 00 6f 00 6e 00 79 00 20 00 43 00 6f 00 .S.o.n.y. .C.o.
0xb0000050: 6d 00 70 00 75 00 74 00 65 00 72 00 20 00 45 00 m.p.u.t.e.r. .E.
0xb0000060: 6e 00 74 00 65 00 72 00 74 00 61 00 69 00 6e 00 n.t.e.r.t.a.i.n.
0xb0000070: 6d 00 65 00 6e 00 74 00 20 00 49 00 6e 00 63 00 m.e.n.t. .I.n.c.
0xb0000080: 2e 00 20 00 41 00 6c 00 6c 00 20 00 72 00 69 00 .. .A.l.l. .r.i.
0xb0000090: 67 00 68 00 74 00 73 00 20 00 72 00 65 00 73 00 g.h.t.s. .r.e.s.
0xb00000a0: 65 00 72 00 76 00 65 00 64 00 2e 00 00 00 48 00 e.r.v.e.d.....H.
0xb00000b0: 44 00 44 00 20 00 26 00 20 00 45 00 74 00 68 00 D.D. .&. .E.t.h.
0xb00000c0: 65 00 72 00 6e 00 65 00 74 00 20 00 49 00 2f 00 e.r.n.e.t. .I./.
0xb00000d0: 46 00 20 00 66 00 6f 00 72 00 20 00 50 00 53 00 F. .f.o.r. .P.S.
0xb00000e0: 32 00 00 00 ff 00 14 00 00 00 ff 00 00 00 00 00 2...............
0xb00000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

################################################## #############################
After pcic_ssbus_mode(5)
dsidb S> dh 0xbf801460 0x20
0xbf801460: 0x0001 0x01e8 0x0010 0x0010 0x0010 0x0090 0x0016 0x0020
0xbf801470: 0x0000 0x0001 0x0007 0x0000 0x0000 0x0000 0x0000 0x0001
dsidb S> dw bf801418 c
0xbf801418: 0xe01a3043 0xef1a3043 0x00051011
dsidb S> db 0xb0000000
0xb0000000: 00 00 11 00 03 00 00 00 00 00 00 00 00 00 02 00 ................
0xb0000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb0000020: 01 00 00 00 00 00 00 00 00 40 00 00 00 00 ff 00 .........@......
0xb0000030: 00 00 00 00 00 00 00 00 60 00 00 00 00 00 25 0a ........`.....%.
0xb0000040: 80 ff 80 ff 80 ff 80 ff 80 ff 80 ff 80 ff 80 ff ................
0xb0000050: 80 ff 80 ff 80 ff 80 ff 80 ff 80 ff 80 ff fe ff ................
0xb0000060: fe ff 02 00 12 00 01 00 fe ff fe ff fe ff fe ff ................
0xb0000070: 24 00 35 00 83 00 ba 4a ba 4a fe ff fe ff fe ff $.5....J.J......
0xb0000080: 00 00 01 00 20 00 00 00 00 00 00 00 00 00 00 00 .... ...........
0xb0000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb00000a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb00000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb00000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb00000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb00000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb00000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

What I found interesting is the mixture of 8-bit and 16-bit registers. The whole config space is 8-bit (as per the specification), so the high-order byte of each 16-bit unit is technically undefined. The "I/O space" seems to use 16-bit registers for device information, but 8-bit for ATA. The register assignment seems to be standard, so if I could map this to PC I/O space somewhere, there is a slight chance that the MS ATAPI driver could handle the channel. It would still need a SMAP-specific minidriver, though, but that should be possible via PciIdeX if it really is a standards-compliant ATA channel . It would be a different situation if it were memory-mapped; atapi.sys does not work with memory resources, so I would need to re-implement everything...

It may be a bit odd but in your test PC, have you looked up the PCMCIA chipset? There is a possibility your chipset is buggy. I have several that refuse to work with multifunction cards (such as the Sandisk 6-in-1 card reader which changes it's ID based on the type of card inserted) Another took a few years to find a Wi-Fi card that it actually liked. Another thing that can trip these things up is ACPI. If you ever get a driver beta going, I would be happy to help testing it.

Interesting, I wasn't aware of such problems.

I'm using an IBM Thinkpad A31p. The PCMCIA chip reports VendorID=1180, DeviceID=0476, so it looks like a real Ricoh 5C476II. Do you know of any particular bugs with this chip?

Me too. As I sort of asked the question in the first place. But like I've kept saying "not really a big deal"

Don't worry, you will get a beta when there is one. In the meantime, I will announce the progress and if I get anything working.

I'm also going to stock up on books and equipment. And if I cannot figure it on from the software side alone, there is still a HP 1630 sitting in the basement . I don't have a PCMCIA adapter yet, but its ordered and will hopefully arrive soon. I currently do not have access to the logic analyser (its a few hundred kilometers away), but will see what I can do with just an analog oscilloscope and multimeter.

[sp193]

Do you mean the line "SPD_REG8(0x20) = 1;"? I thought that already went to I/O space (I'll just call it that for now, even though I don't know which bus cycles are used to access it), but I'll recheck.

Yes, I meant that line.

Honestly, now after I've re-read your messages, I'm not too sure whether I had understood the problem that you have encountered properly... D:
The register dumps you have provided proves that you have configured the card properly.

I think that this problem you are facing now might be related to how well this Sony PCMCIA card complies with the PCMCIA specification. Sorry, but I've been quite tired these few days from staying up late to complete work.

By the way, is the card fully PnP compatible after all? If it isn't PnP compatible, maybe a non-PnP driver has to be written instead?

Do you have an idea why the parameter to pcic_ssbus_mode is called "voltage"? It only accepts values 3 and 5, but the only call in the entire dev9 driver uses a hard-coded 5 as its parameter. Could this be Vpp (auxiliary power)?

No, I don't know what that variable really does for sure.

However, I do know that:
1. The original developer who labeled that argument as 'voltage' probably didn't know what that argument was actually for, and named it 'voltage' just because some 16-bit PCMCIA cards were 5V and 3.3V cards (And he probably assumed that the SCPH-10190 was a 5V card). The PS2's SCPH-10190 is a 3.3V 16-bit PCMCIA card actually.
2. Since the function is clearly meant to reconfigure the SSBUS's (Or part of the SSBUS) operational mode, it probably makes more sense if the argument was the 'mode'.
3. From what I have learned 2 days ago from reading up about the PCCARD, it could be for configuring the PCMCIA bus for I/O or 'Memory-only' mode.

By the way, this is how the memory mapping looks like on my TOOL during card initialization. This is two days old, so it doesn't include the dumps from before and after above write to SPEED space. I'll get these later today.

Interesting. It seems like the dumps you are getting are exactly the same as the dumps I got of my SCPH-10190 during the various phases of initialization.

What I found interesting is the mixture of 8-bit and 16-bit registers. The whole config space is 8-bit (as per the specification), so the high-order byte of each 16-bit unit is technically undefined. The "I/O space" seems to use 16-bit registers for device information, but 8-bit for ATA. The register assignment seems to be standard, so if I could map this to PC I/O space somewhere, there is a slight chance that the MS ATAPI driver could handle the channel. It would still need a SMAP-specific minidriver, though, but that should be possible via PciIdeX if it really is a standards-compliant ATA channel . It would be a different situation if it were memory-mapped; atapi.sys does not work with memory resources, so I would need to re-implement everything...

That would truly be great. :)

The ATA channel's registers are most likely proprietary again, as it's register layout doesn't seem to be similar to the register layout of any known controllers. Otherwise, it probably wouldn't be impossible to code a driver that operated the hardware at UDMA mode 5 and above, based on the functions from the Intel IDE controller driver.

It seems to be 100% compatible with the ATA-4 standard, although the ATAD.IRX module doesn't have a generic method of detecting HDDs from across standards.

For example, it cannot detect my Western Digital Caviar 2200, which was manufactured in 1992 and was based on the obsolete ATA(-0) specification, and which only supported PIO mode 0.

By the way, I don't know whether you already know this, but this PCMCIA adaptor does not support DMA since it lacks a bus master (Which only cardbus controllers have). The DEV9 DMA channel is used for DMA transfers to the PCMCIA bus, but the data probably gets written manually by the PCMCIA controller.

Congratulations on getting so far! I realized that I forgot to congratulate on that in my previous message lol. D:

[SilverBull]

As promised, here is the state after all relevant accesses to DEV9 and SSBUS space.

Summary:

• "DEV9_REG(DEV9_R_1460) = 2" in card_find_manfid() switches the view to configuration space. This command is repeated in pcic_ssbus_mode() without effect.
• "DEV9_REG(DEV9_R_1474) = voltage; (=5)" in pcic_ssbus_mode() has no visible effect on the mapping
• "DEV9_REG(DEV9_R_1460) = 1;" in pcic_ssbus_mode() switches the view to all-zeroes
• "SPD_REG8(0x20) = 1;" in pcic_ssbus_mode() leaves the card in some undefined/intermediate state in which it returns only 1s. Maybe disables card output and leaves last output byte from DEV9 interface on bus?
• "DEV9_REG(DEV9_R_1474) = 7;" in pcic_ssbus_mode() has no visible effect. Device still in intermediate state
• "_sw(0xe01a3043, SSBUS_R_1418);" in pcic_ssbus_mode() seems to toggle between 8/16 bit bus operations, and maybe something else? Device still not in meaningful state
• Why is there a "DelayThread(5000)" in pcic_ssbus_mode()? Does the power supply some time to stabilize?
• "DEV9_REG(DEV9_R_POWER) = DEV9_REG(DEV9_R_POWER) & ~1;" in pcic_ssbus_mode() finally switches to operating mode

in card_find_manfid: after DEV9_REG(DEV9_R_1460) = 2; <= change mapping to configuration space

dsidb S> dh 0xbf801460 0x20
0xbf801460: 0x0002 0x01f8 0x0000 0x0000 0x0010 0x0090 0x0017 0x0020
0xbf801470: 0x0000 0x0001 0x0000 0x0000 0x0000 0x0000 0x0000 0x0001
dsidb S> dw 0xbf801418 c
0xbf801418: 0x001a00bb 0xef1a3043 0x00051011
dsidb S> db 0xb0000000
0xb0000000: 01 00 03 00 d9 00 01 00 ff 00 1c 00 04 00 02 00 ................
0xb0000010: d9 00 01 00 ff 00 20 00 04 00 f1 00 00 00 00 00 ...... .........
0xb0000020: 53 00 21 00 02 00 fe 00 01 00 15 00 5c 00 07 00 S.!.........\...
0xb0000030: 00 00 28 00 43 00 29 00 32 00 30 00 30 00 30 00 ..(.C.).2.0.0.0.
0xb0000040: 20 00 53 00 6f 00 6e 00 79 00 20 00 43 00 6f 00 .S.o.n.y. .C.o.
0xb0000050: 6d 00 70 00 75 00 74 00 65 00 72 00 20 00 45 00 m.p.u.t.e.r. .E.
0xb0000060: 6e 00 74 00 65 00 72 00 74 00 61 00 69 00 6e 00 n.t.e.r.t.a.i.n.
0xb0000070: 6d 00 65 00 6e 00 74 00 20 00 49 00 6e 00 63 00 m.e.n.t. .I.n.c.
0xb0000080: 2e 00 20 00 41 00 6c 00 6c 00 20 00 72 00 69 00 .. .A.l.l. .r.i.
0xb0000090: 67 00 68 00 74 00 73 00 20 00 72 00 65 00 73 00 g.h.t.s. .r.e.s.
0xb00000a0: 65 00 72 00 76 00 65 00 64 00 2e 00 00 00 48 00 e.r.v.e.d.....H.
0xb00000b0: 44 00 44 00 20 00 26 00 20 00 45 00 74 00 68 00 D.D. .&. .E.t.h.
0xb00000c0: 65 00 72 00 6e 00 65 00 74 00 20 00 49 00 2f 00 e.r.n.e.t. .I./.
0xb00000d0: 46 00 20 00 66 00 6f 00 72 00 20 00 50 00 53 00 F. .f.o.r. .P.S.
0xb00000e0: 32 00 00 00 ff 00 14 00 00 00 ff 00 00 00 00 00 2...............
0xb00000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
dsidb S> next

in card_find_manfid: after _sw(0x1a00bb, SSBUS_R_1418); <= nop, register already configured

at=0001000c v0-1=00000002,bf801418 a0-3=001a00bb,bf801460,00f15300,1bf0281b
t0-7=1bf0281b,00000000,00011e28,00011d10, 1ef7681c,00000000,0001165c,000116b8
s0-7=bf801460,00000000,00000001,007fee78, 00000000,00096900,00033c74,0001d7f0
t8=00000000 t9=00000000 k0=000978e8 k1=00000000 gp=000a0450 sp=007fedf0
fp=007fee78 ra=00097468 lo=00000000 hi=00000000 PC=000978ec bada=fff91bde
$cr=0x00000024 [ CE0 Breakpoint ]
$sr=0x00000404 [ IM0 IEp ]
0x000978e4: 0xa4a20000 sh $v0,0($a1)
0x000978e8: 0xac640000 sw $a0,0($v1)
->0x000978ec: 0x00002821 move $a1,$zero
0x000978f0: 0x3c02b000 lui $v0,0xb000
0x000978f4: 0x00451021 addu $v0,$v0,$a1
0x000978f8: 0x90430000 lbu $v1,0($v0)
0x000978fc: 0x24a50002 addiu $a1,$a1,2
dsidb S> dh 0xbf801460 0x20
0xbf801460: 0x0002 0x01f8 0x0000 0x0000 0x0010 0x0090 0x0017 0x0020
0xbf801470: 0x0000 0x0001 0x0000 0x0000 0x0000 0x0000 0x0000 0x0001
dsidb S> dw 0xbf801418 c
0xbf801418: 0x001a00bb 0xef1a3043 0x00051011
dsidb S> db 0xb0000000
0xb0000000: 01 00 03 00 d9 00 01 00 ff 00 1c 00 04 00 02 00 ................
0xb0000010: d9 00 01 00 ff 00 20 00 04 00 f1 00 00 00 00 00 ...... .........
0xb0000020: 53 00 21 00 02 00 fe 00 01 00 15 00 5c 00 07 00 S.!.........\...
0xb0000030: 00 00 28 00 43 00 29 00 32 00 30 00 30 00 30 00 ..(.C.).2.0.0.0.
0xb0000040: 20 00 53 00 6f 00 6e 00 79 00 20 00 43 00 6f 00 .S.o.n.y. .C.o.
0xb0000050: 6d 00 70 00 75 00 74 00 65 00 72 00 20 00 45 00 m.p.u.t.e.r. .E.
0xb0000060: 6e 00 74 00 65 00 72 00 74 00 61 00 69 00 6e 00 n.t.e.r.t.a.i.n.
0xb0000070: 6d 00 65 00 6e 00 74 00 20 00 49 00 6e 00 63 00 m.e.n.t. .I.n.c.
0xb0000080: 2e 00 20 00 41 00 6c 00 6c 00 20 00 72 00 69 00 .. .A.l.l. .r.i.
0xb0000090: 67 00 68 00 74 00 73 00 20 00 72 00 65 00 73 00 g.h.t.s. .r.e.s.
0xb00000a0: 65 00 72 00 76 00 65 00 64 00 2e 00 00 00 48 00 e.r.v.e.d.....H.
0xb00000b0: 44 00 44 00 20 00 26 00 20 00 45 00 74 00 68 00 D.D. .&. .E.t.h.
0xb00000c0: 65 00 72 00 6e 00 65 00 74 00 20 00 49 00 2f 00 e.r.n.e.t. .I./.
0xb00000d0: 46 00 20 00 66 00 6f 00 72 00 20 00 50 00 53 00 F. .f.o.r. .P.S.
0xb00000e0: 32 00 00 00 ff 00 14 00 00 00 ff 00 00 00 00 00 2...............
0xb00000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

################################################## #############################
in pcic_ssbus_mode(5): *bf801474 = 0 => continue
in pcic_ssbus_mode(5): after DEV9_REG(DEV9_R_1460) = 2; <= nop, register already set
in pcic_ssbus_mode(5): after DEV9_REG(DEV9_R_1474) = voltage;

dsidb S>
at=bf800000 v0-1=00000007,00000001 a0-3=00000005,ffffffff,b0000000,00000022
t0-7=000000ff,00000000,00011e28,00011d10, 1ef7681c,00000000,0001165c,000116b8
s0-7=bf801460,00000000,00000001,007fee78, 00000000,00096900,00033c74,0001d7f0
t8=00000000 t9=00000000 k0=0009770c k1=00000000 gp=000a0450 sp=007fedf0
fp=007fee78 ra=0009747c lo=00000000 hi=00000000 PC=00097710 bada=fff91bde
$cr=0x00000024 [ CE0 Breakpoint ]
$sr=0x00000404 [ IM0 IEp ]
0x00097708: 0x24030001 li $v1,1
0x0009770c: 0xa6040014 sh $a0,0x14($s0)
->0x00097710: 0x3c01bf80 lui $at,0xbf80 # 0xbf801460
0x00097714: 0xa4231460 sh $v1,0x1460($at)
0x00097718: 0xa0c30020 sb $v1,0x20($a2)
0x0009771c: 0xa6020014 sh $v0,0x14($s0)
0x00097720: 0x08025db6 j 0x000976d8
dsidb S> dh 0xbf801460 0x20
0xbf801460: 0x0002 0x01f8 0x0000 0x0000 0x0010 0x0090 0x0017 0x0020
0xbf801470: 0x0000 0x0001 0x0005 0x0000 0x0000 0x0000 0x0000 0x0001
dsidb S> dw 0xbf801418 c
0xbf801418: 0x001a00bb 0xef1a3043 0x00051011
dsidb S> db 0xb0000000
0xb0000000: 01 00 03 00 d9 00 01 00 ff 00 1c 00 04 00 02 00 ................
0xb0000010: d9 00 01 00 ff 00 20 00 04 00 f1 00 00 00 00 00 ...... .........
0xb0000020: 53 00 21 00 02 00 fe 00 01 00 15 00 5c 00 07 00 S.!.........\...
0xb0000030: 00 00 28 00 43 00 29 00 32 00 30 00 30 00 30 00 ..(.C.).2.0.0.0.
0xb0000040: 20 00 53 00 6f 00 6e 00 79 00 20 00 43 00 6f 00 .S.o.n.y. .C.o.
0xb0000050: 6d 00 70 00 75 00 74 00 65 00 72 00 20 00 45 00 m.p.u.t.e.r. .E.
0xb0000060: 6e 00 74 00 65 00 72 00 74 00 61 00 69 00 6e 00 n.t.e.r.t.a.i.n.
0xb0000070: 6d 00 65 00 6e 00 74 00 20 00 49 00 6e 00 63 00 m.e.n.t. .I.n.c.
0xb0000080: 2e 00 20 00 41 00 6c 00 6c 00 20 00 72 00 69 00 .. .A.l.l. .r.i.
0xb0000090: 67 00 68 00 74 00 73 00 20 00 72 00 65 00 73 00 g.h.t.s. .r.e.s.
0xb00000a0: 65 00 72 00 76 00 65 00 64 00 2e 00 00 00 48 00 e.r.v.e.d.....H.
0xb00000b0: 44 00 44 00 20 00 26 00 20 00 45 00 74 00 68 00 D.D. .&. .E.t.h.
0xb00000c0: 65 00 72 00 6e 00 65 00 74 00 20 00 49 00 2f 00 e.r.n.e.t. .I./.
0xb00000d0: 46 00 20 00 66 00 6f 00 72 00 20 00 50 00 53 00 F. .f.o.r. .P.S.
0xb00000e0: 32 00 00 00 ff 00 14 00 00 00 ff 00 00 00 00 00 2...............
0xb00000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

in pcic_ssbus_mode(5): after DEV9_REG(DEV9_R_1460) = 1;

dsidb S>
at=bf800000 v0-1=00000007,00000001 a0-3=00000005,ffffffff,b0000000,00000022
t0-7=000000ff,00000000,00011e28,00011d10, 1ef7681c,00000000,0001165c,000116b8
s0-7=bf801460,00000000,00000001,007fee78, 00000000,00096900,00033c74,0001d7f0
t8=00000000 t9=00000000 k0=00097714 k1=00000000 gp=000a0450 sp=007fedf0
fp=007fee78 ra=0009747c lo=00000000 hi=00000000 PC=00097718 bada=fff91bde
$cr=0x00000024 [ CE0 Breakpoint ]
$sr=0x00000404 [ IM0 IEp ]
0x00097710: 0x3c01bf80 lui $at,0xbf80 # 0xbf801460
0x00097714: 0xa4231460 sh $v1,0x1460($at)
->0x00097718: 0xa0c30020 sb $v1,0x20($a2)
0x0009771c: 0xa6020014 sh $v0,0x14($s0)
0x00097720: 0x08025db6 j 0x000976d8
0x00097724| 0x3c03e01a lui $v1,0xe01a
0x00097728: 0x24020001 li $v0,1
dsidb S> dh 0xbf801460 0x20
0xbf801460: 0x0001 0x01f8 0x0000 0x0000 0x0010 0x0090 0x0017 0x0020
0xbf801470: 0x0000 0x0001 0x0005 0x0000 0x0000 0x0000 0x0000 0x0001
dsidb S> dw 0xbf801418 c
0xbf801418: 0x001a00bb 0xef1a3043 0x00051011
dsidb S> db 0xb0000000
0xb0000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb0000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb0000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb0000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb0000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb0000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb0000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb0000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb0000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb0000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb00000a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb00000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb00000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb00000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb00000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb00000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

in pcic_ssbus_mode(5): after SPD_REG8(0x20) = 1;

dsidb S> next
at=bf800000 v0-1=00000007,00000001 a0-3=00000005,ffffffff,b0000000,00000022
t0-7=000000ff,00000000,00011e28,00011d10, 1ef7681c,00000000,0001165c,000116b8
s0-7=bf801460,00000000,00000001,007fee78, 00000000,00096900,00033c74,0001d7f0
t8=00000000 t9=00000000 k0=00097718 k1=00000000 gp=000a0450 sp=007fedf0
fp=007fee78 ra=0009747c lo=00000000 hi=00000000 PC=0009771c bada=fff91bde
$cr=0x00000024 [ CE0 Breakpoint ]
$sr=0x00000404 [ IM0 IEp ]
0x00097714: 0xa4231460 sh $v1,0x1460($at)
0x00097718: 0xa0c30020 sb $v1,0x20($a2)
->0x0009771c: 0xa6020014 sh $v0,0x14($s0)
0x00097720: 0x08025db6 j 0x000976d8
0x00097724| 0x3c03e01a lui $v1,0xe01a
0x00097728: 0x24020001 li $v0,1
0x0009772c: 0xa6020014 sh $v0,0x14($s0)
dsidb S> dh 0xbf801460 0x20
0xbf801460: 0x0001 0x01f8 0x0010 0x0010 0x0010 0x0090 0x0017 0x0020
0xbf801470: 0x0000 0x0001 0x0005 0x0000 0x0000 0x0000 0x0000 0x0001
dsidb S> dw 0xbf801418 c
0xbf801418: 0x001a00bb 0xef1a3043 0x00051011
dsidb S> db 0xb0000000
0xb0000000: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
0xb0000010: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
0xb0000020: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
0xb0000030: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
0xb0000040: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
0xb0000050: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
0xb0000060: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
0xb0000070: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
0xb0000080: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
0xb0000090: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
0xb00000a0: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
0xb00000b0: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
0xb00000c0: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
0xb00000d0: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
0xb00000e0: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
0xb00000f0: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................

in pcic_ssbus_mode(5): after DEV9_REG(DEV9_R_1474) = 7;

dsidb S> next
at=bf800000 v0-1=00000007,00000001 a0-3=00000005,ffffffff,b0000000,00000022
t0-7=000000ff,00000000,00011e28,00011d10, 1ef7681c,00000000,0001165c,000116b8
s0-7=bf801460,00000000,00000001,007fee78, 00000000,00096900,00033c74,0001d7f0
t8=00000000 t9=00000000 k0=0009771c k1=00000000 gp=000a0450 sp=007fedf0
fp=007fee78 ra=0009747c lo=00000000 hi=00000000 PC=00097720 bada=fff91bde
$cr=0x00000024 [ CE0 Breakpoint ]
$sr=0x00000404 [ IM0 IEp ]
0x00097718: 0xa0c30020 sb $v1,0x20($a2)
0x0009771c: 0xa6020014 sh $v0,0x14($s0)
->0x00097720: 0x08025db6 j 0x000976d8
0x00097724| 0x3c03e01a lui $v1,0xe01a
0x00097728: 0x24020001 li $v0,1
0x0009772c: 0xa6020014 sh $v0,0x14($s0)
0x00097730: 0x3c01bf80 lui $at,0xbf80 # 0xbf801460
dsidb S> dh 0xbf801460 0x20
0xbf801460: 0x0001 0x01f8 0x0010 0x0010 0x0010 0x0090 0x0017 0x0020
0xbf801470: 0x0000 0x0001 0x0007 0x0000 0x0000 0x0000 0x0000 0x0001
dsidb S> dw 0xbf801418 c
0xbf801418: 0x001a00bb 0xef1a3043 0x00051011
dsidb S> db 0xb0000000
0xb0000000: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
0xb0000010: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
0xb0000020: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
0xb0000030: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
0xb0000040: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
0xb0000050: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
0xb0000060: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
0xb0000070: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
0xb0000080: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
0xb0000090: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
0xb00000a0: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
0xb00000b0: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
0xb00000c0: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
0xb00000d0: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
0xb00000e0: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
0xb00000f0: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................

in pcic_ssbus_mode(5): after _sw(0xe01a3043, SSBUS_R_1418); <= toggle 8/16 bit access and ???

dsidb S> next
at=bf800000 v0-1=bf801418,e01a3043 a0-3=00000005,ffffffff,b0000000,00000022
t0-7=000000ff,00000000,00011e28,00011d10, 1ef7681c,00000000,0001165c,000116b8
s0-7=bf801460,00000000,00000001,007fee78, 00000000,00096900,00033c74,0001d7f0
t8=00000000 t9=00000000 k0=000976e4 k1=00000000 gp=000a0450 sp=007fedf0
fp=007fee78 ra=0009747c lo=00000000 hi=00000000 PC=000976e8 bada=fff91bde
$cr=0x00000024 [ CE0 Breakpoint ]
$sr=0x00000404 [ IM0 IEp ]
0x000976e0: 0x34421418 ori $v0,$v0,0x1418
0x000976e4: 0xac430000 sw $v1,0($v0)
->0x000976e8: 0x0c02600c jal 0x00098030
0x000976ec| 0x24041388 li $a0,0x1388
0x000976f0: 0x3c03bf80 lui $v1,0xbf80 # 0xbf80146c
0x000976f4: 0x9463146c lhu $v1,0x146c($v1)
0x000976f8: 0x00002821 move $a1,$zero
dsidb S> dh 0xbf801460 0x20
0xbf801460: 0x0001 0x01f8 0x0010 0x0010 0x0010 0x0090 0x0017 0x0020
0xbf801470: 0x0000 0x0001 0x0007 0x0000 0x0000 0x0000 0x0000 0x0001
dsidb S> dw 0xbf801418 c
0xbf801418: 0xe01a3043 0xef1a3043 0x00051011
dsidb S> db 0xb0000000
0xb0000000: 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 ................
0xb0000010: 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 ................
0xb0000020: 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 ................
0xb0000030: 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 ................
0xb0000040: 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 ................
0xb0000050: 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 ................
0xb0000060: 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 ................
0xb0000070: 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 ................
0xb0000080: 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 ................
0xb0000090: 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 ................
0xb00000a0: 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 ................
0xb00000b0: 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 ................
0xb00000c0: 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 ................
0xb00000d0: 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 ................
0xb00000e0: 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 ................
0xb00000f0: 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 ................

in pcic_ssbus_mode(5): after DEV9_REG(DEV9_R_POWER) = DEV9_REG(DEV9_R_POWER) & ~1;

dsidb S> next
at=0001000c v0-1=00000000,00000016 a0-3=00000404,00000000,00000000,1bf4ff28
t0-7=1bf4ff28,00000000,00011e28,00011c70, 400cdcc1,00000008,0001165c,000116b8
s0-7=bf801460,00000000,00000001,007fee78, 00000000,00096900,00033c74,0001d7f0
t8=00000000 t9=00000000 k0=00097700 k1=00000000 gp=000a0450 sp=007fedf0
fp=007fee78 ra=000976f0 lo=00000000 hi=00000000 PC=00097698 bada=fff91bde
$cr=0x00000024 [ CE0 Breakpoint ]
$sr=0x00000404 [ IM0 IEp ]
0x00097690: 0x10820006 beq $a0,$v0,0x000976ac
0x00097694| 0x2405ffff li $a1,-1
->0x00097698: 0x8fbf0014 lw $ra,0x14($sp)
0x0009769c: 0x8fb00010 lw $s0,0x10($sp)
0x000976a0: 0x00a01021 move $v0,$a1
0x000976a4: 0x03e00008 jr $ra
0x000976a8| 0x27bd0018 addiu $sp,$sp,0x18
dsidb S> dh 0xbf801460 0x20
0xbf801460: 0x0001 0x01e8 0x0010 0x0010 0x0010 0x0090 0x0016 0x0020
0xbf801470: 0x0000 0x0001 0x0007 0x0000 0x0000 0x0000 0x0000 0x0001
dsidb S> dw 0xbf801418 c
0xbf801418: 0xe01a3043 0xef1a3043 0x00051011
dsidb S> db 0xb0000000
0xb0000000: 00 00 11 00 03 00 00 00 00 00 00 00 00 00 02 00 ................
0xb0000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb0000020: 01 00 00 00 00 00 00 00 00 40 00 00 00 00 ff 00 .........@......
0xb0000030: 00 00 00 00 00 00 00 00 60 00 00 00 00 00 25 0a ........`.....%.
0xb0000040: 80 ff 80 ff 80 ff 80 ff 80 ff 80 ff 80 ff 80 ff ................
0xb0000050: 80 ff 80 ff 80 ff 80 ff 80 ff 80 ff 80 ff fe ff ................
0xb0000060: fe ff 02 00 12 00 01 00 fe ff fe ff fe ff fe ff ................
0xb0000070: 24 00 35 00 83 00 ba 4a ba 4a fe ff fe ff fe ff $.5....J.J......
0xb0000080: 00 00 01 00 20 00 00 00 00 00 00 00 00 00 00 00 .... ...........
0xb0000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb00000a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb00000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb00000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb00000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb00000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0xb00000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

Yes, I meant that line.

Honestly, now after I've re-read your messages, I'm not too sure whether I had understood the problem that you have encountered properly... D:
The register dumps you have provided proves that you have configured the card properly.

I think that this problem you are facing now might be related to how well this Sony PCMCIA card complies with the PCMCIA specification. Sorry, but I've been quite tired these few days from staying up late to complete work.

No problem, any idea can help . You may be right that the card does not fully comply to the specification, or uses a non-standard configuration of the PCMCIA bus.

By the way, is the card fully PnP compatible after all? If it isn't PnP compatible, maybe a non-PnP driver has to be written instead?

The card is not PnP-compliant, as it does not contain tuples regarding its functions (as in: functional block), does not advertise configuration registers, and does not request resources from the host. All it contains is a minimal Card Information Structure (CIS) such that a PCMCIA controller recognizes it and tells the user it is supposed for a PS2.

Regarding non-PnP driver: unfortunately it is not that easy. Windows' PnP manager is in charge of resource assignment, so anything that needs resources must (directly or indirectly) interact with it. That's why I'm using LogConfigOverride in my .inf file, to make the system allocate 4KB of the physical address space to my device.

No, I don't know what that variable really does for sure.

However, I do know that:
1. The original developer who labeled that argument as 'voltage' probably didn't know what that argument was actually for, and named it 'voltage' just because some 16-bit PCMCIA cards were 5V and 3.3V cards (And he probably assumed that the SCPH-10190 was a 5V card). The PS2's SCPH-10190 is a 3.3V 16-bit PCMCIA card actually.
2. Since the function is clearly meant to reconfigure the SSBUS's (Or part of the SSBUS) operational mode, it probably makes more sense if the argument was the 'mode'.
3. From what I have learned 2 days ago from reading up about the PCCARD, it could be for configuring the PCMCIA bus for I/O or 'Memory-only' mode.

I also think its related to memory versus I/O space, but there is also another possibility: the routine could activate the auxiliary power supply (Vpp) of the card, which could awaken other logic that is in some kind of sleep mode directly after connection. This presents me with the problem of finding the correct Vpp for the card; under Windows, I can only select between 0V/off, same-as-Vcc, and 12V (which is not supported by all PCMCIA controllers). I cannot individually request 3.3V or 5V for Vpp if Vcc uses the other voltage ... Keep your fingers crossed that the card does not require such a setting .

Does anybody know for certain which supply voltage the card needs? Maybe someone has an opened 10k and can measure with a multimeter on the Vcc and Vpp pins while an HDD is active?

As the PCMCIA standard requires Vpp to be turned off after card insertion, the card is probably designed such that it does not take any harm when being inserted into a regular PCMCIA socket; and I would also expect likewise, that an arbitrary PC Card or Cardbus card inserted into the PS2's socket does not take any harm as well. Therefore, it wouldn't surprise me if Vpp was only activated later, as part of pcic_ssbus_mode, because this routine only runs after the dev9 driver has confirmed that the special PCMCIA card is present.

I could insert code to activate Vpp in the Windows driver, but I'm currently reluctant to do so. I don't want to feed Vcc (or, worse, 12V) to the card, at least unless I get confirmation from someone knowing this hardware that doing so is safe and the card normally operates at such voltage levels.

The ATA channel's registers are most likely proprietary again, as it's register layout doesn't seem to be similar to the register layout of any known controllers. Otherwise, it probably wouldn't be impossible to code a driver that operated the hardware at UDMA mode 5 and above, based on the functions from the Intel IDE controller driver.

Its standard ATA channel register layout (eight 8-bit registers in a row, plus some other single 8-bit register later). The reason the registers are separated and split over a 16 byte range lies in the PCMCIA standard: its word-addressed, not byte-addresses. So when doing 8-bit accesses over its 16-bit bus, A0 is expected to be low, and A1 and higher increment for each byte. So when doing 16-bit accesses (which use all address lines), but accessing an 8-bit device, two consecutive registers seem to be 16 bit apart, not 8 bit.

You can see the same thing in configuration space, it also uses bytes only at even addresses.

It seems to be 100% compatible with the ATA-4 standard, although the ATAD.IRX module doesn't have a generic method of detecting HDDs from across standards.

For example, it cannot detect my Western Digital Caviar 2200, which was manufactured in 1992 and was based on the obsolete ATA(-0) specification, and which only supported PIO mode 0.

Interesting. I'd think this is a software limitation of ATAD.IRX, because it simply uses PIO-mode 4 instead of the highest one supported by the drive?

By the way, I don't know whether you already know this, but this PCMCIA adaptor does not support DMA since it lacks a bus master (Which only cardbus controllers have). The DEV9 DMA channel is used for DMA transfers to the PCMCIA bus, but the data probably gets written manually by the PCMCIA controller.

Slave-mode DMA, as in old ISA systems? The PCMCIA card is supposed to have DMA request and acknowledge lines, after all, so it can communicate with an external DMA controller.

Congratulations on getting so far! I realized that I forgot to congratulate on that in my previous message lol. D:

Thank you. Let's hope this leads to anything, and that we do not recognize at some later point that the card simply cannot work on a standard PCMCIA controller due to some "clever" card interface by Sony.

[ASSEMbler]

I hope this may help.

027.JPG
031.JPG
032.JPG

[l_oliveira]

Oh, The DTL-H10190 is actually slightly different than SCPH-10190 due to the ehternet connector being different.

Interesting stuff.

[Tokimemofan]

You're welcome. I actually had a similar idea and wanted to write a driver for this card for some time, so its really no big deal for me. And even if it doesn't work, the time won't be wasted because we'll hopefully learn why; either saving others the time or encouraging them to try where we stopped .

Do you mean the line "SPD_REG8(0x20) = 1;"? I thought that already went to I/O space (I'll just call it that for now, even though I don't know which bus cycles are used to access it), but I'll recheck.

Do you have an idea why the parameter to pcic_ssbus_mode is called "voltage"? It only accepts values 3 and 5, but the only call in the entire dev9 driver uses a hard-coded 5 as its parameter. Could this be Vpp (auxiliary power)?

By the way, this is how the memory mapping looks like on my TOOL during card initialization. This is two days old, so it doesn't include the dumps from before and after above write to SPEED space. I'll get these later today.



What I found interesting is the mixture of 8-bit and 16-bit registers. The whole config space is 8-bit (as per the specification), so the high-order byte of each 16-bit unit is technically undefined. The "I/O space" seems to use 16-bit registers for device information, but 8-bit for ATA. The register assignment seems to be standard, so if I could map this to PC I/O space somewhere, there is a slight chance that the MS ATAPI driver could handle the channel. It would still need a SMAP-specific minidriver, though, but that should be possible via PciIdeX if it really is a standards-compliant ATA channel . It would be a different situation if it were memory-mapped; atapi.sys does not work with memory resources, so I would need to re-implement everything...

Interesting, I wasn't aware of such problems.

I'm using an IBM Thinkpad A31p. The PCMCIA chip reports VendorID=1180, DeviceID=0476, so it looks like a real Ricoh 5C476II. Do you know of any particular bugs with this chip?

Don't worry, you will get a beta when there is one. In the meantime, I will announce the progress and if I get anything working.

I'm also going to stock up on books and equipment. And if I cannot figure it on from the software side alone, there is still a HP 1630 sitting in the basement . I don't have a PCMCIA adapter yet, but its ordered and will hopefully arrive soon. I currently do not have access to the logic analyser (its a few hundred kilometers away), but will see what I can do with just an analog oscilloscope and multimeter.

I don't think I have any Ricoh chipsets at all My experience is mainly with Texas Instruments chipsets, a lot of them have some spectacular bugs.

[SilverBull]

Thanks for the pictures, ASSEMbler. They are really useful, by telling what can definitely not work. Based on the pinout from http://pinouts.ru/Slots/PcCard_pinout.shtml:

SPKR is not connected. So this is no sound card .
Vpp is not connected. The card does not use a secondary power supply.
WE is not connected, meaning there is no reaction to writes to either common or attribute memory space. It seems all writes must go via the I/O path.
CE2 is not connected. This is the enable line for D8-D15, so if I interpret the specification correctly, the card can only perform 8-bit accesses. I have no idea why D8-D15 are still connected, though; maybe Sony is doing something non-standard here.
Of the 26 address lines, only A0-A15 and A23,A25 are connected. This would explain why the contents of the 0xb0000000 memory window on the PS2 repeat every 64KB.
VS2 is not connected, but there is place for a resistor or solder bridge to connect it to some signal line.

Could anybody confirm these observations? Or does anybody notice something being missing from this list?

There are two things that worry me. One is the lack of CE2, but the PS2 clearly being able to do both 8-bit and 16-bit accesses, as seen by the register dump for normal operation. I wonder how the host interface notifies which part of the data bus is being used? Or is this just a static configuration, i.e. the drivers make sure there are only accesses that will just work, by configuring the DEV9 and SSBUS registers accordingly?

I also wonder about A23 and A25. These are the highest address lines available, and I have no idea why they are not disconnected like the others above A15. With A0-A15, the card could decode 64KB address space, which seems to be the case on the PS2. So why the extra two lines?
The problem on x86 is that the processor only has 64KB of I/O space. The PCMCIA bridge (at least the Ricoh one I hope to be using) also cannot map PCI-side memory accesses to card-side I/O, so the processor absolutely needs to perform I/O accesses in the first place. Now, this can only work if the card responds with both A23 and A25 being zero. I'm not aware of any means to set them for I/O operations; even the I/O window remapping of the Ricoh chips is only documented for 16-bit addresses. I hope this is not Sony's way of ensuring that this card cannot be used on PCs...

What are your thoughts?

[Tokimemofan]

I have an SCPH-10000 if you need a photo of the board.

[SilverBull]

I have an SCPH-10000 if you need a photo of the board.

Thank you, that could be helpful. Can you please make high resolution photos of both sides?

[Tokimemofan]

The pin order seems to be 1,35,2,36 etc.

DSC04776.JPGDSC04775.JPGDSC04774.JPG

[SilverBull]

The pin order seems to be 1,35,2,36 etc.

Thank you. The card uses the same kind of interleaving.

Unfortunately there is almost no external logic, it seems everything is done by the CXD9566. As the connector is completely populated, I'd assume this is a fully-functional PCMCIA interface; just cut down via software (or lack thereof) to support one official card only. The board even has Vpp (auxiliary power supply; the 4 interconnected vias), although the card does not need it.

I experimented with mapping the card's I/O space, but so far it returns nothing but zeros. I think it requires some kind of additional initialization, just like sp193 wrote. Like an extra power cycle with nonstandard signalling. I hope to get more information when the adapter arrives.

Another interesting thing: at some point, the card did not report as the usual "HDD and Ethernet Interface", but as a multifunction device exporting (if I remember correctly) "PS2-MTD1" and "PS2-MTD2" functions. I have no idea why this happened or how to repeat it, but it seems the card can switch to a different configuration space under certain conditions.

[sp193]

I also think its related to memory versus I/O space, but there is also another possibility: the routine could activate the auxiliary power supply (Vpp) of the card, which could awaken other logic that is in some kind of sleep mode directly after connection. This presents me with the problem of finding the correct Vpp for the card; under Windows, I can only select between 0V/off, same-as-Vcc, and 12V (which is not supported by all PCMCIA controllers). I cannot individually request 3.3V or 5V for Vpp if Vcc uses the other voltage ... Keep your fingers crossed that the card does not require such a setting .

Yea. :/

The problem here is that we are dealing with Sony, a company that changes everything as it sees fit.

And there is a possibility that the implementation might be 'broken'. Remember the i.Link controller? No matter how I try adjusting the 'unused' or 'reserved' bits, it seems like the DBUF FIFOs are only functioning in big-endian mode.

That might explain why Sony doesn't use the DBUF FIFOs.

Its standard ATA channel register layout (eight 8-bit registers in a row, plus some other single 8-bit register later). The reason the registers are separated and split over a 16 byte range lies in the PCMCIA standard: its word-addressed, not byte-addresses. So when doing 8-bit accesses over its 16-bit bus, A0 is expected to be low, and A1 and higher increment for each byte. So when doing 16-bit accesses (which use all address lines), but accessing an 8-bit device, two consecutive registers seem to be 16 bit apart, not 8 bit.

Sorry, but you've lost me here. :/

It has a standard ATA register layout? Which standard does it follow? If it truly follows a standard, we might be able to adjust the clocks to run at UDMA mode 5 (ATA-100).

Interesting. I'd think this is a software limitation of ATAD.IRX, because it simply uses PIO-mode 4 instead of the highest one supported by the drive?

Yes, it's hardcoded to use UDMA mode 4 after it detects a 'supported' drive. Otherwise, the channel defaults to PIO mode 0.

But, the method of probing for an ATA device seems to be rather simple and only working with ATA-4 compliant disks. Maybe it works with ATA-1 disks too, but those disks won't work with the PS2 because ATAD.IRX will default to UDMA mode 4.

I don't have one of those disks that are incompatible with the PS2, but just maybe... the compatibility issue can be fixed as it is a software issue.

Slave-mode DMA, as in old ISA systems? The PCMCIA card is supposed to have DMA request and acknowledge lines, after all, so it can communicate with an external DMA controller.

Uh. From what I read, the PCMCIA standard does not support bus mastering, which means that the device alone cannot initiate DMA transfers.

Since the PS2's SCPH-10190 is a 16-bit 3.3V PCMCIA card, it probably does not support such DMA transfers. I believed that the PCMCIA hardware was probably responsible for the DMA transfers to the PCMCIA card, for that reason.

Thank you. Let's hope this leads to anything, and that we do not recognize at some later point that the card simply cannot work on a standard PCMCIA controller due to some "clever" card interface by Sony.

Yes, I hope so too.

By the way, I don't remember if I told you about this before... but the PCMCIA slot seems to be configurable for 5V and 3.3V PCMCIA cards, and even Cardbus cards too.

At least, it can detect the presence of Cardbus cards, but the DEV9 driver lacks support for such devices.

I don't know whether it has a complete hardware implementation for Cardbus support though. :/

[PS2Guy]

Did anything ever happen with this??

[SilverBull]

Did anything ever happen with this??

Not really, besides a broken primary power supply of my HP 1630G (due to bad caps ). But at least that's repairable.

Quick and easy: as I understand it, the DTL-H10030/SCPH-10190 cannot work with PCMCIA/CardBus controllers found in standard PCs or laptops.

These cards, although having a PCMCIA connector and seemingly complying to the 16-bit PCMCIA specification, are actually "hybrids". They behave like a PCMCIA device when inserted into a corresponding slot, but to actually work the way they are intended, the slot must support another protocol. The PS2 starts in PCMCIA mode, but after detecting the card, it changes the slot's operating mode; lacking a better name, I'll call it "SSBUS" mode, because it appears to be exactly the same as the external IOP bus. That would also explain why the Sony IC that drives the interface is referred to as an "SSBUS buffer".

SSBUS mode is not that different from PCMCIA, but still sufficient to make it completely incompatible with any standard controller. PCMCIA is a demultiplexed, asynchronous bus: separate address+data+control lines, no clock (the memory+I/O read/write strobes are no clock). CardBus (which is usually supported in conjunction with PCMCIA) is a multiplexed, synchronous bus, much like PCI. SSBUS mode is demultiplexed and synchronous, like a CPU's front side bus .

SSBUS mode uses the same pins for address, data and strobe lines (memory+I/O) as PCMCIA. The RESET line is inverted, but that's about it; the remaining control lines are completely different. It uses one of the pins (sorry, don't remember which one right now) as a CLOCK line, and possibly some others for DMA request/grant and interrupts. That's "possibly" because I cannot check with my equipment. The 1630G does 50MHz timing analysis (which is unusable if you don't know how to set trigger conditions, due to not knowing what you are looking for), but only 25MHz state. And the SSBUS clock runs at around 38MHz, which just happens to be the IOP's clock; so no meaningful bus traces. But wait, it gets even better: when the measurement adapter for the PCMCIA slot is used, there is so much RF interference on the bus, I can literally watch the clock from any other line on the interface. Sure, its damped, but clearly visible. Makes reading anything on the analog oscilloscope a pain (at some point in time, I had a total of 6 analog channels on two scopes connected). But at least the frequency counter is happy with that signal...

However, I did get some insights into some of the memory-mapped registers of the SSBUS buffer IC. Control of the slot's voltage regulator (you can power a 3.3V-only PCMCIA card with 5V if you ask the controller nicely ), PCMCIA signalling lines, card insert/eject/status change interrupts. I can post this if there is any interest; but honestly, it does not help in any way to get these cards to work with standard PCs. You would need custom hardware with your own PCMCIA controller design, then add this "SSBUS" mode as an additional operating mode besides PCMCIA and CardBus.