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. :(Originally Posted by PS2Guy
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??
Last edited by PS2Guy; 05-26-2012 at 03:17 AM.
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_Re served. HDD_&_Ethernet_I/F_for_PS2.
I've tried right clicking and updating driver. I've also tried searching Google. All with no results.
Last edited by PS2Guy; 05-26-2012 at 03:41 AM.
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. :/
Last edited by sp193; 05-26-2012 at 12:00 PM.
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.
Last edited by l_oliveira; 05-26-2012 at 06:12 PM.
PlayStation Aficionado.
MSX Maniac.
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.It seems like there are many types of "PCIC", and the PCIC register to use varies...
The Kernel Loader page seems to indicate the following:
- Add possibilty to enter PCIC type in kernelloader menu:
0: No card
1: PCMCIA
2: PCMCIA
3: SCPH-10350 with PHY 83847A and MAC CXD9731GP.
This probably means that the EXPANSION BAY type (CXD9611) is PCIC type 3....
Hmm... it seems like the TIMR registers might be different for the different PCIC versions.
The CXD9566 seems to have it at DEV9_R_147E, while the CXD9611 has it at DEV9_R_1466.
DEV9_R_1466 seems to be "CSTC2" in the CXD9566.
The bits for both TIMR registers could be the same.... and both seem to only have one bit (Bit 0).
IMR -> Interrupt Mask Register
CSC -> Card Status Change?
DEV9_R_1460 -> ???
DEV9_R_1462 -> PCCARD type register
Bits:
0x03 -> Either bit set = Cardbus card, all cleared = PCMCIA card, all set = no card inserted. The DEV9 driver checks for the first bit, with the CXD9611 (Bit set = No device).
0x0C -> Voltage. 0x04 -> 3 (0v/Invalid?), 0x00 or 0x08 -> 1 (3.3v), 0x0C -> 2 (5v).
0x100 -> Powered up status bit?
DEV9_R_1464 -> SBUS_PCIC_CSC1 <- CSTC1
DEV9_R_1466 -> SBUS_PCIC3_TIMR <- CSTC2
Bits:
0x01 -> ???
DEV9_R_1468 -> SBUS_PCIC_IMR1
Bits:
0x10 -> ???
DEV9_R_146A -> ???
Bits:
0x90 -> ???
DEV9_R_146C -> DEV9_R_POWER
Bits:
0x01 -> Switch on
0x02 -> Power off/Reset? Might be different from just clearing the register...
0x04 -> Unknown. Set only when the voltage is to be 3.3v.
0x08 -> Voltage selector. Cleared = 3.3v, set = 5v.
0x10 -> Unknown. Always set, but is an argument to pcic_power.
DEV9_R_146E -> DEV9_R_REV
Bits:
0x30 -> 0x20 = CXD9566, 0x30 = CXD9611
DEV9_R_1474 -> SSBUS mode?
Bits:
0x07 -> 0x01 seems to need to be set to enable something.
3 and 5 are the modes seen in DEV9.irx.
All bits (0x07) get set in mode 5.
DEV9_R_1476 -> SBUS_PCIC_EXC1
DEV9_R_147A -> ???
DEV9_R_147C -> ??? (Seems to be related to DEV9_R_147A)
Bits:
0x01 -> ???
DEV9_R_147E -> SBUS_PCIC_TIMR
Bits:
0x01 -> ???
SPD_R_024 -> SPD_R_DMA_CTRL
SPD_R_028 -> SPD_R_INTR_STATUS
SPD_R_02A -> SPD_R_INTR_ENABLE
SPD_R_02C -> SPD_R_IO_DIR
SPD_R_02E -> SPD_R_IO_DATA
- HDD IF -
SPD_R_02E -> SPD_R_IO_DATA
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.
Last edited by sp193; 05-26-2012 at 08:58 PM. Reason: Added more information.
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.
PSN ID: Alannmc <-2 N's
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....
Last edited by sp193; 05-26-2012 at 09:54 PM.
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.
Last edited by Lum; 05-27-2012 at 03:34 AM.
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. :)
Last edited by l_oliveira; 05-27-2012 at 12:58 PM.
PlayStation Aficionado.
MSX Maniac.
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. 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.lkd> !devnode 0 1
Dumping IopRootDeviceNode (= 0x8a8a8c70)
DevNode 0x8a8a8c70 for PDO 0x8a8a8da8
InstancePath is "HTREE\ROOT\0"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0x8a8a8780 for PDO 0x8a8a88c8
InstancePath is "Root\ACPI_HAL\0000"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0x8a89cd50 for PDO 0x8a8da868
InstancePath is "ACPI_HAL\PNP0C08\0"
ServiceName is "ACPI"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0x8a8a0008 for PDO 0x8a863248
InstancePath is "ACPI\PNP0A03\2&daba3ff&0"
ServiceName is "pci"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0x8a89eee8 for PDO 0x8a823c70
InstancePath is "PCI\VEN_8086&DEV_2448&SUBSYS_00000000&REV_42\3&61 aaa01&0&F0"
ServiceName is "pci"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0x8a8d6a18 for PDO 0x8a89dcf8
InstancePath is "PCI\VEN_1180&DEV_0476&SUBSYS_01851014&REV_A8\4&13 9e449d&0&01F0"
ServiceName is "pcmcia"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0x89587268 for PDO 0x89be7858
InstancePath is "PCMCIA\(C)2000_Sony_Computer_Entertainment_Inc._A ll_rights_reserved.-HDD_&_Ethernet_I/F_for_PS2-3E87\1"
ServiceName is "sbpcmcia"
State = DeviceNodeRemoved (0x312)
Previous State = DeviceNodeStartCompletion (0x306)
Problem = CM_PROB_FAILED_START
Failure Status 0000000000
[...]
lkd> !devstack 0x8a89dcf8
!DevObj !DrvObj !DevExt ObjectName
8a821030 \Driver\Pcmcia 8a8210e8 Pcmcia1
8a8d7748 \Driver\ACPI 8a835ce8 00000079
> 8a89dcf8 \Driver\PCI 8a89ddb0 NTPNP_PCI0012
!DevNode 8a8d6a18 :
DeviceInst is "PCI\VEN_1180&DEV_0476&SUBSYS_01851014&REV_A8\4&13 9e449d&0&01F0"
ServiceName is "pcmcia"
lkd> !devobj 0x89be7858
Device object (89be7858) is for:
PcCard0-0 \Driver\Pcmcia DriverObject 8a80d990
Current Irp 00000000 RefCount 0 Type 00000022 Flags 00001040
Dacl e101787c DevExt 89be7910 DevObjExt 89be7a88 DevNode 89587268
ExtensionFlags (0x00000010) DOE_START_PENDING
Device queue is not busy.
lkd> dd 0x89be7910+0x160 l4
89be7a70 896386d8 00000001 00000000 00000000
lkd> db 0x896386d8
896386d8 01 03 d9 01 ff 1c 04 02-d9 01 ff 20 04 f1 00 00 ........... ....
896386e8 53 21 02 fe 01 15 5c 07-00 28 43 29 32 30 30 30 S!....\..(C)2000
896386f8 20 53 6f 6e 79 20 43 6f-6d 70 75 74 65 72 20 45 Sony Computer E
89638708 6e 74 65 72 74 61 69 6e-6d 65 6e 74 20 49 6e 63 ntertainment Inc
89638718 2e 20 41 6c 6c 20 72 69-67 68 74 73 20 72 65 73 . All rights res
89638728 65 72 76 65 64 2e 00 48-44 44 20 26 20 45 74 68 erved..HDD & Eth
89638738 65 72 6e 65 74 20 49 2f-46 20 66 6f 72 20 50 53 ernet I/F for PS
89638748 32 00 ff 14 00 ff 00 00-00 00 00 00 00 00 00 00 2...............
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.
01 03 d9 01 ff
DEVICE
[0].type = 0xD
[0].wp = 1
[0].speed = 1 (250ns)
[0].size = ((0 >> 3) + 1) * (512 << (1*2)) = 1024
1c 04 02-d9 01 ff
DEVICE_0C
Vcc = 1 (=> 3.3V ???)
remaining fields as in DEVICE tuple
20 04 f1 00 00 53
MANFID
manf = 0x00f1
card = 0x5300
21 02 fe 01
FUNCID
func = 0xfe
sysinit = 0x01
15 5c 07 00 (...)
VERS_1
major = 0x07
minor = 0x00
"(C)2000 Sony Computer Entertainment Inc. All rights reserved."
"HDD & Ethernet I/F for PS2"
14 00
NO_LINK
ff
END
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 ? ;)
PlayStation Aficionado.
MSX Maniac.
This place (ASSEMblergames) still amazes me. You ask a simple, if not meaningless question likeand 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.
Last edited by PS2Guy; 05-28-2012 at 05:00 AM.
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.
Posting Permissions
Reply With Quote
Bookmarks