New modified SMAP driver with FULL DMA support + HDL Dump svr 0.8.7

[deba5er]

Thanks volca. I'm also glad you are still working it. I bet everyone with a Slim and OPL is too ;-)

[hominem.te.esse]

Good work SP193 and Volca. I hope it will lead to improved eth performances

We're waiting on news



-> SP193 (damn post rules that prevent me to use 'at' symbol):

I have a question also, I saw somewhere that you were working on adding rename (or was it "write") support for USB device/driver. I'm pretty sure you do that on some custom version of usbhdfs you use in PSESDL, right ? Does it means we can't in any way merge/port these changes into OPL one ?

[RandQalan]

@ hominem.te.esse

I left some visitor messages of some thinks that might improve OPL

can't seen you PM without at least 30 post so left it on your visitors sorry about the inconvenience

[hominem.te.esse]

For Shadow Hearts 2 Final Mix, I read the whole thread, but that kind of changes is out of my skills. Only Jimmi can validate it, and moreover I'm not sure the values you found are 100% safe (last posts about some increased freeze rate for Ar Tonelico 2).

Let's hope he came back

[SP193]

-> SP193 (damn post rules that prevent me to use 'at' symbol):

I have a question also, I saw somewhere that you were working on adding rename (or was it "write") support for USB device/driver. I'm pretty sure you do that on some custom version of usbhdfs you use in PSESDL, right ? Does it means we can't in any way merge/port these changes into OPL one ?

I was working towards adding rename functionality to the USBHSDFSD driver. But my efforts have now gone up in flames because my HDD containing all my work files (Some of them weren't backed up yet) was corrupted.

If I do find a backup on my external disks, I might continue working on it in the future, but now I'm going to be short of time again because the next schooling semester begins tomorrow.

Yes, that new driver will be usable in all homebrew software. Merging the new feature into an existing driver is possible too.

[nodots]

Any improvements or changes in the last month, or is school getting in the way (in a good way)? I am interested to see new code, to follow the process. I am trying to learn C, so...

Anywho, just a friendly "thread bump".

[SP193]

Any improvements or changes in the last month, or is school getting in the way (in a good way)? I am interested to see new code, to follow the process. I am trying to learn C, so...

Anywho, just a friendly "thread bump".

Hmm... I don't know whether there has been any progress. I thought that Volca was working on the SMAP driver.

I stopped working on the SMAP driver after realizing that he seemed to have taken interest in it and was working on it too, partly because I had too many commitments elsewhere and I simply lack the proper facilities to debug and build the SMAP + TCP/IP protocol stack.

When the SMAP driver or the protocol stack crashes, developers like me will lose our only channel for receiving debugging information, so debugging the PS2 with only the SMAP is really difficult.

On the up side, I think that I did recently made a customized copy of the SMS TCP/IP protocol stack stable with DMA support, although I didn't do too much testing with it at all.

Transfer rates were slow on my *new* hardware lol - ~1.40MB/s. But then again, even that ultra-fast 5MB/s driver ran that slowly too!
(Developing on my laptop just isn't the same as developing on my desktop! )

[nodots]

That sounds like me previously using XDMCP login to my server over wireless with a 300MHz laptop. Sloooooooow. I agree, there are better ways. Too bad I can't shell out for a PS2-Hackathon in Vegas, LOL. Then all the great minds could get together and share code/ideas AND hardware use.

[hominem.te.esse]

@volca, SP193

Any news, facts, story about this epic challenge, just to keep us in suspense ?

[volca]

Hey, sorry for the delay.

I left the effort sometime at the end of last year, solely for the lack of time. The state I left it was that I still didn't come up with a way to stop the freezes. I think the culprit is double sema locking, so disabling interrupts instead could help. The only combination that did work was using the SMS assembly fifo handling with the threaded SMAP code, which produced some 0.5 Mb/s speed gain, probably due to the fact that it does not block the IOP so much.

I thought about the way to get from the mess that it is currently in. I came up with a plan I currently have little time to realize:
1. Write a threaded SMAP.irx replacement, from scratch, that does not depend on SMSTCPIP.irx in any way.
2. Tune this on a piece of packet generating code - prepare a blocking read method that'd replace the one in SMSTCPIP at the end of the journey. In this state the PS2 should be able to reply to some hand made packets.
3. Rewrite the ARP, ICMP and UDP parts of the stack, so it will be able to communicate by UDP, reply to ping packets and manage ARP requests.
4. Write TCP stack on top of this.

By the end this should be capable doing client side of TCP.

I know jimmi has started such a rewrite, but without threading the SMAP - it may still be viable alternative, all we need is DMA code in single thread and working blocking read impl. Problem was doing DMA in interrupt context - namely dev9DmaTransfer which uses non-interrupt Sema calls, if not because of other problems.

Also, I think write operations should borrow buffers from the packet driver and write into those directly - should save some time.