Jump to content

sgstair

Premium Members
  • Posts

    203
  • Joined

  • Last visited

Posts posted by sgstair

  1. Hi, here is link to source code : http://www.videolan.org/vlc/

    Do we can adapt this code for nintendo DS to receive these data for door UDP?

          Somebody is qualified to make this?

     

     

          Thanks!!!

     

    -blink-

    Okay, please don't be stupid.... too late, I suppose.

    The DS just isn't powerful enough to do any serious video decoding; Additionally it's obvious to me (and everyone else) that you don't have any idea what you're asking, or even have the first inkling of a thought of how to go about doing such a project.

    I suggest if you want such a thing done, DO IT YOURSELF. Learn how the system works and write your own program. If we want such a thing, those of us capable of doing such WILL DO SO.

     

    In the meantime, quit bugging us with unreasonable or infeasable requests, especially if you don't have a clue as to what you're asking!

     

    -Stephen

  2. heh, pepsiman and company got DSlinux up on tcp/ip, and they have a webbrowser and IRC client up running already =).. well, they didn't use Steven's lib, only his documentation

     

    By the way, the browser is nice, tried it yesterday.. its like.. wow.. to surf on the DS :s.. even if limited

     

    Actually no, they used the lib source almost verbatim,

    regardless - that's what it's there for.

     

    I'm certainly not leaving by any means, it's just taking time because I have other things that need to be done too.

     

    -Stephen

  3. While transfering big files with tftpds i noticed that it seemed to fail systematically. After studying the traffic in ethereal I came to the conclusion that dswifi calculates the checksum for the udp package incorrectly in some rare cases. I read here on the forum that it fails on odd-sized packages but this was an even sized package so it is not the same bug.

     

    After spending several hours tracking down this bug, my friend Gustav Munkby and I found the cause of this bug. In a few places in the checksum calculation code similar to this appears:

    checksum += checksum>>16;
    checksum &= 0xFFFF;

    This code is meant to take of the carries from the ones'-complement additions. The correct way of doing this is like this:

    while(checksum >> 16) checksum = (checksum & 0xFFFF) + (checksum >> 16);

    As an example, if checksum = 0x1FFFF the former code give an incorrect result (0), but the later code will give the correct result (1).

     

    I have updated my hacked version to fix this in at least some places:

    http://www.itstud.chalmers.se/~larssten/wifi_lib.tar.bz2

     

    Hi! Thanks for the feedback, but I had already noticed and fixed this in my working version of the lib (that's what I get for having long delays between releases, I guess) - I do appreciate being informed though :)

     

    -Stephen

  4. lots of misinformation here, folks.

    the Official Site states (albeit not very clearly) that the driver works for PCI and PCMCIA cards ONLY - when they have an RT2500 chipset (which means the interface chip is the RT2560)

     

    I'm not sure where the RT2570 number came from, because as far as I know USB devices also use the 2560 chip, though I haven't confirmed this.

     

    Additionally, the Nintendo USB connector *is* a RT2500 device, however as it's USB the current driver will NOT work with it.

     

    Hope this clears some some stuff up.

    -Stephen

  5. 3) afaik it is 50ms, at least based on the documentation I had - it might be wrong, but the behavior I've seen is consistent with it being 50ms. New version will allow for any timer speed in an elegant fashion ;)

    The ARM9 cpu is running at 33.514 MHz. The divisor is set to 256 gives us (33.514*10^6 / 256)^-1 ≈ 7.6*10^-6 s per tick. Then we have 13106 * 7.6*10^-6 ≈ 0.100 s. This is how I understand that the timers work anyway, I might be wrong.

    Indeed- I must have misread this somewhere or something. I'll fix it in the next release.

     

    -Stephen

  6. I've implemented a simple TFTP-server that I'm going to use for a project later. TFTP works by sending one DATA packet, wait for ACK, send next DATA, and so on. This means only one packet is in the queue at any time and therefore the protocol is very sensitive to latency.

     

    I've only gotten about 5 kb/s transfer rates. I've discovered that the bottleneck is the communication between the ARM7 and the ARM9 processors. The ARM9 polls for new packages every 50 ms, when the Wifi_Timer_50ms() function is called. That means new packages are recieved 10 times every second. Since TFTP sends 512 bytes in every package you only get a transfer rate of 10 * 512 ~ 5 kb/s.

     

    This leads me to two questions:

     

    1. Why is it using polled communications between the processors when the IPC interrupts could be used?

     

    2. Why is the IP stack implemented on the ARM9 processor and not ARM7? It would be much more efficient if I could implement the TFTP-server in ARM7... The socket functions could be made available on both processors using IPC for ease of use.

     

    And another question:

     

    3. In wifi_lib_test TIMER3_DATA is set to -13106. Doesn't that give an interrupt every 100 ms instead of 50 ms?

     

    PS. using wifi_lib 0.2b

     

    Ack! didn't notice this thread

    1) to not interfere with whatever the end user wanted to do. there *will* be support for instant notification via IPC in the next version.

    2) ease of use, speed, etc... It was a design decision.

    3) afaik it is 50ms, at least based on the documentation I had - it might be wrong, but the behavior I've seen is consistent with it being 50ms. New version will allow for any timer speed in an elegant fashion ;)

     

    -Stephen

  7. yet since firefox has all the USER made plug-ins you can personalize to limitless proportions with a great variety of options

     

     

     

    Don't be stupid, like firefox on DS would have user plugins?

    Firefox is far too slow, bloated, memory-intensive, and close-mindedly designed to work on a limited system like the DS. Opera is a great browser and I'm quite glad to see it used on the DS.

     

    -Stephen

  8. lockwood: you're an idiot. Do you really expect to be able to make anything usable?

     

    davos1: Yes, penstroke recognition and similar technologies will very likely be incorporated into future homebrew, a lot of that is in the pipeline.

     

    -Stephen

  9. Correct, this version doesn't support blocking mode (all sockets are non-blocking) - next version will start sockets in blocking mode and allow you to turn it off (with ioctl)

     

    -Stephen

  10. IJTF_Cinder: Again, you're incorrect for the most part. The only time an RSA hash is used is in the transmission of an executable binary for download play, and it's processed entirely in software - Please note that there really is no good documentation to go off of for understanding how this stuff works at present, the only way to know for sure is to do some capturing of data and figure it out on your own :D

     

    -Stephen

  11. cyberreality: actually, the question has absolutely nothing to do with the wifi lib, which is the focus of this forum.

     

    IJTF_Cinter: I'm still trying to figure out where you came up with that idea.... it doesn't make any sense, and it couldn't possibly work. (it's impractical besides the fact that there's only 32 bytes of space there, while the RSA hash is 128 bytes)

     

    -Stephen

  12. Well, this is the best forum on this site for a question like this. The big problem is that downloaded binaries are RSA signed, and we don't have the private key used to sign with (not to mention the key is basicly impossible to get)

     

    If you want a "more appropriate" place to discuss things, see the DS forums on gbadev.org

     

    -Stephen

  13. Well, you must remember, if you're currently using anything related to DS wifi, you're right in the middle of the early adopters. Early adopters for things like these especially don't get the luxury of having nice UIs and simple configuration.

     

    There is a light at the end of the tunnel though, the next wifi lib release will change a lot of things. Wifi apps will likely no longer require configuration files at all, and almost everything will start to work automatically as the developers refine their code.

     

    So, if you're interested in a mainstream product at the moment, they just don't exist, but the next lib version will begin the chain of events that will result in a lot of complete, polished apps that will work without so much work in configuring and etc..

     

    So, just be patient for now, all this will be coming soon.

     

    -Stephen

  14. i've done all that though i sent it to 192.168.2.101 (my comp ip) which is the destip on port 8888 but i get nothing.  hmmm i might try send it through the internet see where that gets me.

    i've tried everything i can think of but it wont work, i dont get it? i've basically have copied and pasted the original and this code but it wont work

    its says dest ip :192.168.2.101 (my comp)

    source 192.168.1.189 (ds)

    port : 8888

     

    but i get no response

    if(Stylus.Held) {

    if(Stylus.X>208 && (Stylus.Y>144)){

    strcpy(sendbuf,text);

     

    sain.sin_family=AF_INET;

    sain.sin_port=htons(portnum);

    sain.sin_addr.s_addr=destip;

    sendto(sock,"test",strlen("test"),0,(struct sockaddr *)&sain,sizeof(sain));

     

    }

     

    that pretty much a copy of sgstairs version but i've hardcoded a message in this case.(it was using a typed version b4)

    i noticed that yours says out and stevens says in which is odd but i swapped them and it made no difference.

     

    Please note that in general you cannot send data from a 192.168.1.* address to a 192.168.2.* without a gateway system configured for the connection between the two seperate networks (I'm willing to bet you don't have such in place)

    This isn't rocket science, but it really really helps to have a solid understanding of networking... if you do have further questions, I'm more open to talking on IRC - see #dswifi on EFnet - I'm usually around. (Forums are good for lengthy discussions about topics that most parties understand well, but are not as well suited for teaching, etc - IMO)

     

    -Stephen

  15. Yeah, the test project does have hardcoded paths for the include files and libraries - in order to use the test project, just modify the paths in the makefile.

     

    To make a new project, either add the include files' path to the makefile, or copy the include files into your project... then include the.lib files in your project too (could copy them to your project dir too)

     

    -Stephen

  16. At present... homebrew stuff (dswifi lib) supports UDP/IP (yes, it does work over the internet) - which is the less most frequently used half of the set of internet protocols commonly known as TCP/IP. In order to use this you either need an Access Point, a Wireless router, or a Wifi card that supports a soft-ap mode. - you will also need a method of running homebrew, which inferno covered briefly, but this is not the place to be asking for how to run homebrew - other places will answer that question for you.

     

    If (on the off chance) You're just talking about the Nintendo WFC (official internet play) - then you just need a router or AP or softAP - no need for anything else (besides of course the DS and the game to go with it)

     

    -Stephen

×
×
  • Create New...