Windows DTL-H10030 Driver

[l_oliveira]

SilverBull, you happen to know anything about the I2C interface that exists inside of the SSBUS chip ? (CXS9566/9611) The one the PS2 uses to send commands to the DVE chip ? We need information on that stuff for a secondary project (related to the GSM app and DVD player drivers) ...

[SilverBull]

SilverBull, you happen to know anything about the I2C interface that exists inside of the SSBUS chip ? (CXS9566/9611) The one the PS2 uses to send commands to the DVE chip ? We need information on that stuff for a secondary project (related to the GSM app and DVD player drivers) ...

Sorry, I don't know anything about that. Frankly, I didn't even know there was an I2C bus to the digital video encoder before I saw that other thread...

Do you know which component is normally responsible for communicating with that chip? May be worth a look.

[sp193]

Your research is very interesting, although it's a shame that the SPEED device is using a proprietary protocol.

I'm interested into knowing the register definitions, so could you please share that with me?

On the bright side, we should be able to access our HDD units remotely soon. I'm going to release my SMAP stuff soon, but the speed is a bit disappointing (4MB/s top). :(

The auto negotiation issue is still there, so even the Sony driver probably didn't have a software workaround that hardware fault.

At least, it doesn't seem to freeze up after transferring data for a while.

This may be off-topic, so we may have to split it into another thread: Do you know whether there were performance enhancements made to the IOP thread manager after the first few literations?

People say that queuing the frames for transmission should improve throughput as the Playstation 2 SMAP device has a small Tx FIFO, but adding a queue (Involving semaphores) of any sort seems to do the reverse - performance dips by quite a bit (0.8MB/s).

I believe that it has to be related to the thread manager, since it seems like context switches are really bad for performance.

Even the Sony DEV9 driver seems to not not use a semaphore to get around this issue (It polls the DMA CHCR register to know when the DMA transfer ends). If one was to modify the homebrew DEV9 driver to use the polling original method used by Sony, performance increases by about 0.6MB/s.

Do you know what sort of performance the Sony SMAP driver offered? My SMAP driver is based on their SMAP v2.25 driver, and performance provided by their design was about 2.2MB/s (Before I changed that to make Tx occur in the calling thread instead).

Placing the network stack on the EE seems to cause a dip in performance too, seemingly because of the SIF (Probably causes thread context switches, or the SIF is really just that slow - 0.6MB/s dip).

[SilverBull]

Your research is very interesting, although it's a shame that the SPEED device is using a proprietary protocol.

I'm interested into knowing the register definitions, so could you please share that with me?

Here you go (hoping I did not make any mistakes while trying to decipher my notes):

GND is ground, "L" is low potential (i.e., GND ), "H" is selected high potential (Vcc, changable via power control register). Output voltage of CDx and VSx pins cannot be changed for obvious reasons, but other control pins can. The state of Vcc-dependent pins (like BVDx, WP, READY and so on) cannot be read until power has been applied to the card and OE=1 in the power control register.

BEWARE: there is no hardware protection against the wrong voltage being applied to a PCMCIA/CardBus card. Misuse of the power control register can fry a card, so BE CAREFUL.

BF801460 (r/w): Target memory space. Selects which PCMCIA space is accessed via memory accesses to 0xB0000000 on the IOP. Only the lower 3 bits keep a written value.
xxxxx...: ? (unchangable)
.....x..: ? (changable, interpretation unknown)
......xx: 00=>common memory (P#61/!REG=H); 01=>I/O (P#61/!REG=L); 10/11=>config (P#61/!REG=L)

BF801462 (ro): Card status pins.
.|.......x: P#36/!CD1: 0=>L
.|......x.: P#67/!CD2: 0=>L
.|.....x..: P#43/!VS1: 0=>L
.|....x...: P#57:!VS2: 0=>L
.|...x....: P#63/!STSCHG/BVD1: 0=>L (only valid if Vcc+OE)
.|..x.....: P#62/!SPKR/BVD2: 0=>L (only valid if Vcc+OE)
.|.x......: P#33/!IOIS16/WP: 0=>L (only valid if Vcc+OE)
.|x.......: P#16/!IREQ/READY: 0=>L (only valid if Vcc+OE)
x|........: ? Indicates error if 0 after power on

BF801464/BF801466 (r/w): Interrupt status register. Bits set when condition occurs, writing a 1 clears the bit. At least 9 bits in use.
.|.......x: !CD1
.|......x.: !CD2
.|...x....: !STSCHG/BVD1
.|..x.....: !SPKR/BVD2
.|.x......: !IOIS16/WP
.|x.......: !IREQ/READY
x|........: ? Something related to Vpp ?

BF801464 is for "signal asserted" (e.g., !CD1 going from H to L), BF801466 is for "signal deasserted" (e.g., !CD1 going from L to H)

BF80146C (r/w): Power control. Only the lower 5 bits known.
xxx.....: ?
...x....: 1=> Vpp=Vcc; 0=> Vpp=GND
....xx..: 00/11=> Vcc=0V; 01=>Vcc=3V3; 10=>Vcc=5V
......x.: 1=> OE=Vcc (Vcc-dependent outputs enabled); 0=> OE=L (Vcc-dependent outputs to GND)
.......x: 1=> RESET=L; 0=> RESET=Vcc (if OE=Vcc, otherwise L)

BF80146E (ro?): Device identification register (?)
xxxx....: 0010=>CXD9566 (PCMCIA). 0011=>CXD9611 (ExpBay)

On the bright side, we should be able to access our HDD units remotely soon. I'm going to release my SMAP stuff soon, but the speed is a bit disappointing (4MB/s top). :(

The auto negotiation issue is still there, so even the Sony driver probably didn't have a software workaround that hardware fault.

At least, it doesn't seem to freeze up after transferring data for a while.

Good job. Seems a release is near?

This may be off-topic, so we may have to split it into another thread: Do you know whether there were performance enhancements made to the IOP thread manager after the first few literations?

People say that queuing the frames for transmission should improve throughput as the Playstation 2 SMAP device has a small Tx FIFO, but adding a queue (Involving semaphores) of any sort seems to do the reverse - performance dips by quite a bit (0.8MB/s).

I believe that it has to be related to the thread manager, since it seems like context switches are really bad for performance.

Sorry, I don't know whether they changed the thread manager after the initial release.

You know that the IOP is slow, so it is no surprise that any kind of additional overhead influences the transrate rate. Waiting for a semaphore may cause a thread switch; then comes the interrupt from the device (requiring the context of the current thread be safed, so it can be restored once the handler completes); then another thread switch back to the original thread. In comparison, interrupt-driven systems are usually slower when doing I/O with a single device; that is, in comparison to systems using polling, simply because the latter ones can react faster to hardware events.

By itself, a queue does not help to improve throughput. You need to synchronize access to the queue, and copy data in and out. If you do that via a semaphore, you may end up switching thread contexts, which is always slow... Even on modern PCs. Although with all their caches and high clock frequencies, it isn't such a nuisance as on the IOP .

Why do you use a semaphore for the queue, anyway? That requires writing all packets to the TX FIFO in thread context, because your interrupt handler cannot touch the queue (it cannot acquire the semaphore, because the interrupt may come in just after a thread has acquired it and is inserting something). I would try to just disable interrupts while accessing the queue. Something like this:

When attempting to send a packet, in normal thread context:

• Disable interrupts
• If TX possible: write packet to FIFO
• If TX not possible: insert packet into queue
• Enable interrupts

When an interrupt comes in:

• If TX possible and queue not empty: dequeue packet and write to FIFO

Can interrupt handlers be nested on the IOP? That is, can one device interrupt the interrupt handler of another device? If so, and you want to allow other modules to send packets from their interrupt handlers as well, you also want to disable further interrupts from inside your handler. Otherwise its not needed, because you cannot be interrupted therein (no pun intended).

Even the Sony DEV9 driver seems to not not use a semaphore to get around this issue (It polls the DMA CHCR register to know when the DMA transfer ends). If one was to modify the homebrew DEV9 driver to use the polling original method used by Sony, performance increases by about 0.6MB/s.

Do you know what sort of performance the Sony SMAP driver offered? My SMAP driver is based on their SMAP v2.25 driver, and performance provided by their design was about 2.2MB/s (Before I changed that to make Tx occur in the calling thread instead).

Placing the network stack on the EE seems to cause a dip in performance too, seemingly because of the SIF (Probably causes thread context switches, or the SIF is really just that slow - 0.6MB/s dip).

Sorry, I have never experimented with the SMAP system before and don't have any numbers. But I remember reading a comment in the homebrewn SMAP (or was it DEV9?) driver about using interrupts instead of polling; the homebrew developer wondered why Sony used polling in the official driver. Guess we know that reason now...

What do you mean by "placing the network stack on the EE"? Are you accessing the SMAP/DEV9 devices directly from the EE, in the same way you would on the IOP (just using other memory addresses for direct device access)? That would require each such access being sent over the SIF, and essentially block the EE in the meantime (no core multi-threading to mask those latencies).

[sp193]

Here you go (hoping I did not make any mistakes while trying to decipher my notes):

GND is ground, "L" is low potential (i.e., GND ), "H" is selected high potential (Vcc, changable via power control register). Output voltage of CDx and VSx pins cannot be changed for obvious reasons, but other control pins can. The state of Vcc-dependent pins (like BVDx, WP, READY and so on) cannot be read until power has been applied to the card and OE=1 in the power control register.

BEWARE: there is no hardware protection against the wrong voltage being applied to a PCMCIA/CardBus card. Misuse of the power control register can fry a card, so BE CAREFUL.

BF801460 (r/w): Target memory space. Selects which PCMCIA space is accessed via memory accesses to 0xB0000000 on the IOP. Only the lower 3 bits keep a written value.
xxxxx...: ? (unchangable)
.....x..: ? (changable, interpretation unknown)
......xx: 00=>common memory (P#61/!REG=H); 01=>I/O (P#61/!REG=L); 10/11=>config (P#61/!REG=L)

BF801462 (ro): Card status pins.
.|.......x: P#36/!CD1: 0=>L
.|......x.: P#67/!CD2: 0=>L
.|.....x..: P#43/!VS1: 0=>L
.|....x...: P#57:!VS2: 0=>L
.|...x....: P#63/!STSCHG/BVD1: 0=>L (only valid if Vcc+OE)
.|..x.....: P#62/!SPKR/BVD2: 0=>L (only valid if Vcc+OE)
.|.x......: P#33/!IOIS16/WP: 0=>L (only valid if Vcc+OE)
.|x.......: P#16/!IREQ/READY: 0=>L (only valid if Vcc+OE)
x|........: ? Indicates error if 0 after power on

BF801464/BF801466 (r/w): Interrupt status register. Bits set when condition occurs, writing a 1 clears the bit. At least 9 bits in use.
.|.......x: !CD1
.|......x.: !CD2
.|...x....: !STSCHG/BVD1
.|..x.....: !SPKR/BVD2
.|.x......: !IOIS16/WP
.|x.......: !IREQ/READY
x|........: ? Something related to Vpp ?

BF801464 is for "signal asserted" (e.g., !CD1 going from H to L), BF801466 is for "signal deasserted" (e.g., !CD1 going from L to H)

BF80146C (r/w): Power control. Only the lower 5 bits known.
xxx.....: ?
...x....: 1=> Vpp=Vcc; 0=> Vpp=GND
....xx..: 00/11=> Vcc=0V; 01=>Vcc=3V3; 10=>Vcc=5V
......x.: 1=> OE=Vcc (Vcc-dependent outputs enabled); 0=> OE=L (Vcc-dependent outputs to GND)
.......x: 1=> RESET=L; 0=> RESET=Vcc (if OE=Vcc, otherwise L)

BF80146E (ro?): Device identification register (?)
xxxx....: 0010=>CXD9566 (PCMCIA). 0011=>CXD9611 (ExpBay)

Wow! This is very comprehensive! :)

I'll spend some time studying these findings at my own time, to see whether I can get it to accept normal PCMCIA or CARDBUS cards.

Good job. Seems a release is near?

Precisely. I've decided to just go ahead and make a release once I complete a Network I/F manager like the Sony NETDEV module, so that people can enjoy my work and possibly even help me.

I think that the addition of a network I/F manager would be good, as the network stack and network adaptor driver won't be so closely coupled.

It's also so that the same modules can be used with both a IOP and EE side stack without being recompiled.

Sorry, I don't know whether they changed the thread manager after the initial release.

You know that the IOP is slow, so it is no surprise that any kind of additional overhead influences the transrate rate. Waiting for a semaphore may cause a thread switch; then comes the interrupt from the device (requiring the context of the current thread be safed, so it can be restored once the handler completes); then another thread switch back to the original thread. In comparison, interrupt-driven systems are usually slower when doing I/O with a single device; that is, in comparison to systems using polling, simply because the latter ones can react faster to hardware events.

By itself, a queue does not help to improve throughput. You need to synchronize access to the queue, and copy data in and out. If you do that via a semaphore, you may end up switching thread contexts, which is always slow... Even on modern PCs. Although with all their caches and high clock frequencies, it isn't such a nuisance as on the IOP .

That was what I was thinking, but I'm glad that you have made it clear that it's a common problem for computers. :)

(Especially for the IOP, which is really not too suitable for multithreading and yet remaining responsive )

Why do you use a semaphore for the queue, anyway? That requires writing all packets to the TX FIFO in thread context, because your interrupt handler cannot touch the queue (it cannot acquire the semaphore, because the interrupt may come in just after a thread has acquired it and is inserting something). I would try to just disable interrupts while accessing the queue. Something like this:

It's because I have no confidence with doing that properly (But I don't clearly remember why). :/
But I'll try again after I make a release, so that more people can play with my work until then.

Well, I need to keep packet transmission and receiving in a thread, because the DEV9 driver's DMA transfer function must be executed outside of the interrupt context as it uses a semaphore for exclusive access.

But I'll try getting a queue to work again with disabling interrupts instead of a semaphore, when I get some time again after I make my first release (Should be soon).

Can interrupt handlers be nested on the IOP? That is, can one device interrupt the interrupt handler of another device? If so, and you want to allow other modules to send packets from their interrupt handlers as well, you also want to disable further interrupts from inside your handler. Otherwise its not needed, because you cannot be interrupted therein (no pun intended).

I think that interrupts cannot interrupt handlers handling the interrupt assertions of other devices, or the PS2 wouldn't have "frozen up" when my older i.Link driver was spamming data with the IEEE1394 enclosure I have.

That old driver used to copy data from the FIFOs with a loop in the interrupt context, since DMA support was non-existent back then (You know why).

Since the EXPANSION BAY consoles will generate an interrupt whenever the RESET button is pressed and this will in turn invoke the poweroff handler to power off the console, it means that interrupts cannot be nested as the RESET button was non-functional while my i.Link driver was transferring a lot of data in the interrupt context.

I remember that the RESET button was totally not functional, as if my SCPH-39006 had hung (But it was still playing my FMVs smoothly like never before).

Sorry, I have never experimented with the SMAP system before and don't have any numbers. But I remember reading a comment in the homebrewn SMAP (or was it DEV9?) driver about using interrupts instead of polling; the homebrew developer wondered why Sony used polling in the official driver. Guess we know that reason now...

Exactly!

Well, that comment you saw is in the DEV9 driver, above the DMA transfer function.

Actually, I think that the increase performance was probably 0.8MB/s instead, as I remember modifying the DEV9 driver I'm using to not turn the DEV9 hardware interrupt on and off whenever data is transferred. It gained about 0.2MB/s through that modification alone (Hence how I thought that it was an improvement by 0.6MB/s).

What do you mean by "placing the network stack on the EE"? Are you accessing the SMAP/DEV9 devices directly from the EE, in the same way you would on the IOP (just using other memory addresses for direct device access)? That would require each such access being sent over the SIF, and essentially block the EE in the meantime (no core multi-threading to mask those latencies).

The "network stack" I'm referring to is the network protocol stack (Layers 3 and 4 of the OSI model).

The SMAP driver entirely resides on the IOP, and I/O requests from the protocol stack to the link layer go over the SIF.

I'm currently aiming to imitate what Sony has been doing, since projects like OPL will benefit from having an entirely IOP-only network stack and driver.