Windows DTL-H10030 Driver

I was just wondering if anyone knew of (or has) a Windows driver for the DTL-H10030 External Hard Drive, or the the SCPH-10390 External Hard Drive. More specifically the PCMCIA Card.

It's not really a big deal if there wasn't one. Was just wondering.

 

It doesn't exist.

Few of us ever had access to the PCMCIA Network Adaptor and the HDD unit, so there is almost nobody who can and will code a driver.

Personally, I would like to do that... but my laptop doesn't have a PCMCIA interface. D:

 

Would be nice, but I can't see the real use of it other than to put files on and off, or to use it as one helluva cool external.

 

In theory, you should be able to connect to it through WinHiip and put games on it that way. It's not really a big deal. Was just wondering if one existed. I might try and have a go at it myself. Maybe??

 

Have you tried plugging it in and seeing what happens? There's a chance it would detect it as a mass storage device. Maybe the network won't work but it's worth a shot.
In fact, I'll see if I can find a PCMCIA slot around my house and plug 'er in.

 

I'm running Server 2003 R2 (which is XP), and in device manager (under other devices, and showing a big question mark and exclamation mark) it says (c)_Sony_Computer_Entertainment_Inc._All_Rights_Reserved. HDD_&_Ethernet_I/F_for_PS2.

I've tried right clicking and updating driver. I've also tried searching Google. All with no results.

 

It should be like that.

Just asking: What resources does the adaptor use? Silverbull mentioned that it used a single memory address range. Even if I can't code a driver for it, stating the resources it uses here will give other developers a better idea on how Windows can access the NA.

Yes, there won't be any working Windows drivers for it as it's a piece of proprietary Sony hardware. The chips in it (Excluding the PHY chip) are not even existent outside of the PS2 world.

Yea, it would be a cool external HDD unit. My 10K died not too long ago from thermal shock, so the HDD unit, NA and the console itself are now just for show. :/

 

I managed to get the Windows Driver Development Kit. Later on today I'll install it on my Server 2003 machine (it has a PCMCIA slot) and following Silverbull's Kermit driver tutorial, I'll see about making one for the card.

 

Look at the homebrewn PS2 SDK, DEV9.C, SMAP.C and ATAD.C should give you a good idea of how it works, if you ignore the stuff that is specific to the CXD9566/9611 chips.

PCMCIA card code is SCPH-10190 btw.

 

If you do successfully build a driver, even one that barely works - please do share it!

The registers on the SPEED device are the registers on the PCMCIA card.

FYI, adding on to l_Oliveira's post: The CXD9566 is the controller of the PCMCIA-type DEV9 interface, while the CXD9611 is the controller for the Expansion bay-type DEV9 interface.

The HDD units for consumer consoles are SCPH-10210 and SCPH-20400. Both are physically identical to the DTL-H10030.

For initialization code, you should follow code that gets run for the CXD9566's peripherals. Just avoid copying the reads and writes to the DEV9 interface's registers - as those probably have to be replaced with calls to Windows's PCMCIA interface control functions instead.

 

Wouldn't the driver also theoretically support the internal hard drive/network expansion for scph-30000-55000, assuming you're able to adapt the port? Afaik, those are based on the same bus as the pcmcia cards too, correct?

Pointless? Maybe, but then again, once adapted, it'd be easier to swap around hard drives.

 

Yes. However...

The SCPH-20400 is just a regular IDE disk enclosure, but connects to a proprietary interface. Other than that - it's no different from plugging your internal HDD into a regular IDE disk enclosure.

In fact, the HDD within the SCPH-20400 is a SCPH-20401 - the exact same HDD that gets inserted into the expansion bay of the newer PS2s.

It probably makes no sense to adapt the proprietary expansion bay connector to anything standard - since it's probably easier to unplug the HDD from the NA and connect it to the PC via a standard IDE disk enclosure.

After all, to connect your NA to a PC, you will still have to disconnect the NA from the PS2, won't you?

A better project for that would probably be to create a TCP/IP server that runs on the PS2 that supports the operations you need, like installing and managing games - at full 100Mbit speed. I'm working on that, but I don't have a working EE-side network stack to complete this dream....

 

Mmmm, I enjoy all this talk about making a driver. Taking time to think about it, it would be really easy to add things to the HDD. My current method involves taking the drive out, putting it in a PC, rebooting and then copying files. Not exactly efficient.

 

I guess so. Neat to hear there's some use for you guys who have the PCMCIA version PS2.

Improved transfer rate would be nice. Sure my modchip allows putting imports and even burned (illegal as the idea is) games alike on HDD, without any swap, which is a benefit over normal PS2s. Still that doesn't change how slow it takes.

 

That exists already. Name: HDLDUMP.

Edit: Only catch is, it is coded on really old SDK code and is rather slow. It's performance is satisfying for me. Also I have the impression that the PS2 side "will do anything you want" with the harddrive and the side that pulls the strings is the PC side, meaning that to change the behavior of the whole set you just need to mod the PC side client.

 

I made some experiments today, but so far it doesn't look good. I remember that a Windows 2000 laptop I tried a DTL-H10010 card on recognized it and also assigned resources (it was one memory range if I remember correctly). Unfortunately, my XP SP3 does not assign any resources, although it seemingly recognizes the card just fine.

What I wanted to do was to write a bus driver on top of the PCMCIA device, with a static list of two children. One for the ATA interface, one for the ethernet. I was hoping we could write an IDE controller minidriver via pciidex.sys. The advantage would be that atapi.sys attached automatically, and if the HDD was attached, it would automatically getting recognized and exported to applications as an ordinary device via the regular API. The same for the ethernet controller via an NDIS miniport driver.

Now for the bad news: it just plain doesn't work. I started with a KMDF driver, but it gets thrown out of memory after EvtDriverDeviceAdd completes successfully :stupid:. EvtDevicePrepareHardware is never called, which usually means IRP_MN_START_DEVICE fails. Debugging this is tough, as I cannot get the KMDF debugger extensions to work (symbols for my version of wdfldr.sys are missing on the public symbol server, rendering !wdfkd useless). I used DebugView for some quick same-machine debugging (I currently do not have a second machine for real kernel debugging available), and it reports exactly this: EvtDriverDeviceAdd succeeds, but afterwards the system sends IRP_MN_REMOVE_DEVICE and the driver is unloaded again.

Suspecting KMDF, I also tried a WDM driver instead. I used the Toaster function driver, that now gets loaded for the DTL-H10010 via a patched INF. Unfortunately it shows the same behaviour, but at least allows better debugging. Seems the real culprit is the PCMCIA bus driver, because it fails the IRP_MN_START_DEVICE with STATUS_INSUFFICIENT_RESOURCES. Which brings me to the next observation mentioned above: XP does not assign any resources to the device, the AllocatedResources(Translated) lists passed as part of IRP_MN_START_DEVICE are empty (really, both pointers are NULL, and I'm not sure whether this is even a valid way to invoke IRP_MN_START_DEVICE).

But there are also some good news, or at least I think they are not that bad: XP can read configuration information from the card. Here's a rundown (sorry for the odd formatting, the forum software removes leading whitespace and does not provide a CODE tag or similar):

The device node tree is cut down to just the path from the root node to the one for the PCMCIA function. As you can see, it reads configuration tuples from the card. This is the region that is parsed and checked by card_find_manfid in ps2dev9.

By the way: I wasn't able to read the config space myself in a modified Toaster driver. I got the BUS_INTERFACE_STANDARD, which should allow access via GetBusData, but it always returns a length of zero bytes read. The dump above shows the cache of the configuration space as seen by the pcmcia bus driver.

As an addition, here is a simple decoding of the configuration tuples. The device exports a single function that requests a single 1024-byte memory range. Unfortunately, it does not give a base address in attribute space, so I'm not sure whether Windows could configure the card: I would think it needed to tell the address decoder where the memory range resides in bus/"logical" address space, which in my opinion is impossible without a configuration tuple. But I may be wrong on this, I don't know PCI or PCMCIA well enough.

 

That isn't entirely correct. While the connector is proprietary, the interface itself is ata with a drive enable signal on a separate 2 pin connector. All the magic is done in SCPH-10190, all one would need to do is make a card edge connector and do a pin trace on the connector to match it up

 

SP193 was actually referring to the SCPH-10190 as a "proprietary" interface. Anyway, it's a vanilla PCMCIA device with non standard/ non PNP compliant IDs/TAGs, as SilverBull just identified on his analysis...

As complementary information, the SCPH-10281 units marked "SKD" (SONY Kisarasu) and "Made in Japan" are built around the CXD9624AGG which happens to be almost identical to the CXA9624GG you find inside of the SCPH-10190.

The difference is just that the AGG chip has serial (modem) enabled.

Also, these network adapters do use a PHY from National Semiconductor (DP83846) instead of the ST Microelectronics PHY found on later models of the Network Adapter.

I also happen to own a late model of Ethernet only network adapter which has a CXD9731 as SPEED chip, has SERIAL port enabled but has a National Semiconductor PHY...

Oddball stuff ... Did I mention I love oddball stuff ?

 

This place (ASSEMblergames) still amazes me. You ask a simple, if not meaningless question like

and you get so much support and knowledge from all types of people and with all types of post counts. I really appreciate everything that people have shared I always look forward to l_oliveira's exceptionally informative posts and the wealth of knowledge that rattles around in SilverBull's head. I'm glad that he's on the case, as I didn't really know what I was doing.

 

I was dumbstruck when I found that with a few PM's, I could buy a PS2 TOOL- something I had been trying to find for YEARS.

On topic though, the whole conundrum over this is getting bigger than I thought. Then again, I've never made a driver before.