New SMAP driver + HDLDump v0.93 prototype

To think that I screwed my PS2 sdk trying to fully rebuild it ... I ended downloading something newer from bitbucket with mercurial and am re-compiling it with "my patches" to it as I type this ...

Hope stuff keep working ... lol


edit:

Recompiling broke a lot of things, so I restored a backup I made before installing the new compiled version and did compile just the patched stuff...

 

Some updates

I've got good news: I've gotten the SMS TCP/IP stack working on the IOP with the HDL Dump v0.86 server after porting it to interface with NETMAN.
(So yea, rejoyce OPL users...)

I got about 1.39MB/s, which means that Sony was right about the EE-side TCP/IP stack granting higher throughput... which is a relief for me after I saw some really weird results in the early tests (IOP-side stacks used to outperform those EE-side stacks). :concern:

The only problem left here appears to be a problem with packet transmission. The current release of the SMAP driver has a problem as I forgot to load and restore the GP register in some of the exported functions, so there is actually a critical stability issue that I have fixed.

The problem now is that it seems like TCP transmissions stall up after a certain amount of data is sent. This behaviour seems to be common among the EE and IOP-side stacks, which is a good sign since it's at least replicatable in both areas (Which means that it's either a problem with the protocol stack itself or with the SMAP driver... not the SIF RPC interface).

I know that the PS2 is still responsive because it responds to PINGs, but just seems to not be sending TCP responses (It goes silent... and then if you wait long enough, you may see it sending out one or two packets before another long moment of silence).

IF I ever get this fixed, we have accomplished our mission of bringing stable network support to the homebrew PS2SDK.

EDIT: I found that the lack of response was cased by the SMAP driver's threads eating away CPU time. Re-raising the protocol stack's threads in priority has restored responsiveness... but now the problem is that the TCP sequence numbers seem to go haywire after transmitting data for a while.

I once even saw packets with malformed headers. I don't remember whether the checksums were right or not.

Does anyone here have any idea why the sequence numbers go wrong after a while? This seems to happen only when a lot of data is sent from the PS2, and I don't think that this happened a lot previously because the old SMAP drivers were quite slow.

 

New version released!

Changelog:

1. Modified how the NETMAN Rx packet allocation function is designed. Packet management should be done by the network protocol stack itself.
2. Modified the SMAP driver to clear the TxEnd event flag when a packet is to be sent, for more accurate TxEnd event detection.
3. Fixed GP pointer setting for functions exported to NETMAN by the SMAP driver.
4. Added a port of LWIP v1.4.1 for the IOP.
5. Split apart the SMAP testing platform into it's base components, so that the components can be used in other projects.

LWIP v1.4.1 is now used instead of LWIP v1.4.0, and its source package should be placed in the common/tcpip folder instead of iop/tcpip. That folder does not exist in homebrew PS2SDK installations yet, so please create it.


EDIT: Forgot to mention that the EE-side port of LWIP v1.4.1 probably can't be used to rip games from a Playstation 2 console, since it has some problem that I can't track. It doesn't seem to be a problem with my SMAP driver setup... so it may be a problem with LWIP itself.

After some packet exchanges with my Windows 7 PC, my PC would just go quiet after sending a duplicated ACK to one packet that it had previously ACKed before (Strange eh? ).

If someone was to test and fix that, that'll be great.

 

New build released!

Changelog:

1. Fixed the sys_arch file in the EE LWIP v1.4.1 port, as I've misread the documentation for PollSema. This is why iReleaseWaitThread() seemed to not work.
2. Cleaned unused code within the sys_arch file for the IOP LWIP v1.4.1 port, as well as the structure of functions (Reduced the number of return statements).
3. For both LWIP ports: cloned alloc_msg() as try_alloc_msg(). alloc_msg() will wait until a message slot is available, while try_alloc_msg() will return if no slots are available.
4. Adjusted the options used for both ports so that they will be the same.
5. Modified the "lightweight" protection mechanism used by the EE LWIP v1.4.1 port. I'm not sure whether this one will work right either.
6. The EE-side of NETMAN has NetManRpcNetIFSendPacket() completed. It will now wait for space to become available if the current Tx FIFO is full. This has not been intensively tested.
7. Removed the inclusion of "..\main.h" from the standalone PKTDRV IOP module.
8. Adjusted the Makefiles to use the built modules that are stored in the PS2SDK\iop\irx folder instead.

Since it seems to be getting quite reliable, I've included pre-compiled versions of the IRX and EE library files.

If nobody complains about the stability of the libraries (NETMAN and LWIP for both the EE and IOP), I'll see that it gets commited into the PS2SDK repository on Github sooner or later.

Documentation for the NETMAN APIs is still a work-in-progress, sorry.

Please refer to the first post of this thread for links to the precompiled binaries and source code archive.

I need people to help me verify that the "lightweight" protection mechanism I'm using within the EE LWIP port will work right.

NetManRpcNetIFSendPacket() within the EE-side NETMAN library (rpc_client.c of the EE library) needs to be checked too, to ensure that it won't ever cause a deadlock when waiting for Tx FIFO space to become available. I'm known to be weak with logic... somehow.

 

Thanx
I used [IOP] PKTDRV.elf in combination with HDLDumb and average speed is about 5.1MBps

I'm not sure what you can do with the other elfs in the package...

 

Thank you for testing!

In this release, nothing was changed for the IOP-side PKTDTV platform. It's probably already as fast as it gets.

So yea, this release isn't going to benefit those who want to make fast game installs... but is meant for testing the EE-side LWIP v1.4.1 stack as TCP support is important for other homebrew software.

 

FYI: The download link in the homepage (http://ichiba.geocities.jp/ysai187/PS2/smap.htm) seems to be dead.

 

Thank you! The project has been closed after the new modules were committed into the PS2SDK.

But I have neglected to reflect its closure on its homepage. :/

Thanks for reminding me!

EDIT: Right now, I'm updating various software to support the new SMAP driver. OPL's update project page is here: http://psx-scene.com/forums/f150/up...to-negotiation-dma-support-111155/index4.html

 

Its theirs any link for updated SMS w/ smap driver?

 

No, there isn't such a thing.

AFAIK, SMS already has its own SMAP driver that supports DMA. If it's slow, it's likely due to how the IOP just is and there is no fix for it.

 

OPL not like SMS in terms of SMB mode, SMS too slow even low resolution AVI 320x240, 128 bits super stuttering . I thinks its only Kbs in transfer.