Windows DTL-H10030 Driver

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 :congratulatory:.

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 :biggrin-new:.

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 :grief:. Quote:

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

 

I hit a road block, as expected :disgust:.

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 :mad-new:. 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... :moody:

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.

 

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:

 

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.

 

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

 

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 :biggrin-new:.

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 :cool-new:. 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 :love_heart:. 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.

 

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?

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.

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.

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:

 

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

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

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.

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 :concern:... Keep your fingers crossed that the card does not require such a setting :dejection:.

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.

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.

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?

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.

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.

 

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

Interesting stuff.

 

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.

 

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 :highly_amused:.
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?

 

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?

 

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.

 

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. :nightmare:

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

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).

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.

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.

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. :/

 

Did anything ever happen with this??

 

Not really, besides a broken primary power supply of my HP 1630G (due to bad caps :grief. 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. :moody:

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 :stupid:.

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... :dejection:

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 :disgust, 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.