Jump to content

sgstair

Premium Members
  • Posts

    203
  • Joined

  • Last visited

Posts posted by sgstair

  1. Hehe, well, grey seems to have hijacked the thread :D

     

    Back to the discussion at hand...

     

    About homebrew volume?

    Watch the following sites for breaking news:

    http://www.drunkencoders.com/

    http://ds.whatalicefound.net/news/

    http://scdev.org/

    and a semi-comprehensive list (though a bit older): http://patatersoft.info/links.html

     

    To answer some of your other statements:

     

    Just because an official SDK is widely used in a homebrew scene does not make it legal or justified; in all of the nintendo homebrew scenes I've been involved in, we take a lot of care not to do anything to compromise the legality of our work.

     

    About cards:

    Actually, Pirate DS cards are a very new phenomonon - the information requisite to actually making them was kept secret until recently, and now several groups are actually making "true" ds flash cards - this will be very good for homebrew, as running code will no longer require all the jumping through hoops. On the other hand, it makes piracy so much easier too, but I suppose that can't be prevented anyway.

     

    -Stephen

    PS: Sony sucks any way you look at it :lol:

  2. I got bored the other day and was scouring the net for DS homebrew and one thing really irked me: For every piece of DS homebrew, there was at least 5 for PSP. Then I started wondering why this was...and I came up with these. If anyone wants to argue a point or add more, feel free.

    I'll take you up on this;

    For starters, there's no great outnumbering of homebrew from either side, it's pretty close to 1:1 or just leaning slightly to one side or the other. If you want to make an argument about the quantity of homebrew, it would be nice to have some sort of evidence; I'm betting you just haven't found the right sites.

     

    - Incomplete/Unstable Wifi lib (I know stephen has worked hard on it, but hey, its lacking in certain places. Wifi and the touch screen being the biggest advantage to the DS, which brings me to the next point....)

    I'm not sure on this anymore, but not too long ago the only wifi the PSP was enjoying was only through the official psp SDK, which is a huge nono for homebrew development. The wifi lib for DS isn't perfect yet, for sure, but it's very easy to use and works for nearly everyone at this point.

     

    - Poor accuracy for the touch screen code (Yes, I know its improved, but when you try to hit backspace and a D keeps appearing? Irritating.)

    Yes and no, a lot of this is just older applications, recent ndslib versions greatly improve this. And if you're talking about my code, it's not using the touchpad in an optimal way (I've come up with a better way to do it now, but I haven't yet implemented it)

     

    - Mind numbing range of GBA carts -each with their own specific way of running things and hardware advantages. (e.g. compare the SUpercard CF or SD to the Magic Key 2/3)

    (edit: As a side note, the neo flash coding comp specifically states that you should take advantage of the MK2/3 hardware if you intend to win. Thats nice and all, but what is the point of alienating over 50% of DS users by making a program that only works with certain flashcarts?)

    Mind numbing range of gba cards, and yet nearly everyone agrees on a very few range of options for homebrew; all the options are mainly for pirates. :P

    And none of us should be appreciating neoflash anyway, the damage he's already done to the community is far greater than any sort of competition could undo, especially a competition that (as you stated) seems to serve to do more damange to the community.

     

    - The overhead to get the actual homebrew running. (I know, now because PSP uses the GTA game there's not much difference, but in the beginning there was. I live in Australia and had a Supercard CF delivered from Jandamann, it cost me $88. That is $12 less than what I paid for the console. After buying a 1GB CF card for $55, that's $43 more than I paid for the DS!)

    And, this didn't *used* to be a problem, but it is more so (but if you are trying to justify a freaking 1GB CF card for homebrew, that's ridiculous). The cheapest option right now is probably passme2 + a really cheap flashcard. A number of us like the GBAMP(v2), which is very cheap (~$20), widely used, and until passme2 became the norm, all you needed was a gbamp + passme....

    Besides all this, there will shortly be cheap "true" DS flashcards which will make homebrew cheaper, easier, and more universal again.

     

    Overall though, don't get the wrong idea - we're happy to have you around & contributing <_<

     

    -Stephen

  3. Ack!  So soon?  Yikes, I had better get to work.  Thanks for the answer though.  :)

     

    If nothing else, I'll try to have higher volume next release.  The volume is already all the way up on the DS, but I might be able to boost the samples.  The shoutcast directory might take me some time.  I had a brief look at the shoutcast directory in Winamp... and it looks like it would take quite a bit of effort on my part, and that's going to take some time.  But consider it officially added to the planned feature list.  :)

     

    Actually probably not so soon anymore... I've put the code on CVS now so it's more likely I'll just polish it up some more and release later.

     

    See http://blog.akkit.org/ for the details on CVS.

     

    -Stephen

  4. Is it possible at all to change the timeout value for things such as autoconnect or recv?  I find that if those operations fail for any reasons, it takes a long time, (if ever) for them to come back (I've never actually waited that long).  This essentially freezes up the DS if there's a failure.  So... is there a way to change the timeout?

    Well.... yes and no.

    Autoconnect does time out, but even so, you are in charge of the loop that waits until it's connected, so you are responsible for stopping it early if you want to.

    it is possible that recv() will never return in the current version of the lib, but work is being done to fix this - additionally you can switch to non-blocking mode and recv() will always return immediately.

     

    -Stephen

  5. Simple explanation:

    The "C" scores are a compatibility rating

    C+ should always work with the lib

    C? will often work with the lib, but no guarantee

    C- will rarely work with the lib

     

    More in depth explanation:

    C+ signifies that the router only specifies 1-2MBit as it's base (required) rate set, which the DS is fully capable of working with.

    C? is shown when the router requires 1mbit, 2mbit, 5.5mbit, and 11mbit - this requires the ds to lie about it's capabilities in order to connect, and the AP may send out data faster than the DS can handle it, require the AP to retransmit it at progressively lower rates until the DS can receive it (and some data may be lost)

    C- means that other rates besides 1, 2, 5.5, and 11 mbit are required by the router in order to connect - while it may still be possible to connect, the problems with receiving high rate information are even worse with these kinds of routers unless they're unnaturally smart. For most routers in this category, data gets retransmitted a lot of times before the DS can actually receive it, adding a lot of lag and unreliability to the connection, if the AP even bothers to transmit at a low enough rate that the DS can receive it :\

     

    -Stephen

  6. erm... I'm not aware of any behaviour that could cause it to allocate /deallocate 8 bytes periodically, if you do find something of the sort though, please let me know... As far as problems with allocating, this could happen if the allocate functions aren't reentrant safe.... I should probably look at mitigating factors further.

    To prevent any possibility of contamination though, wrap the allocation functions with a layer that temporarily disables interrupts while allocating.

    -Stephen

  7. Ok, there have been a number of people who can't connect with this version of the lib, following are some basic troubleshooting points for the current version of the lib (0.3 ONLY - later versions will fix several of these points)

     

    But, before all that - check your router's compatibility on nintendo's wifi site: http://www.nintendowifi.com/ - if it's not compatible there it's probably going to cause you grief.

     

    Problem:

    Can't see any access points, but they were there in an earlier version (v0.2)

    Probable Causes:

    * this is probably a bug in the lib, I'm looking for it..

     

    Problem:

    Hangs at ASSOCSTATUS_SEARCHING

    Probable Causes:

    * your router has SSID Broadcast disabled, this must be enabled for the current version of the lib, though it is planned to be fixed in the next version.

    * your router may be off.... well, it might be!

     

    Problem:

    Hangs at ASSOCSTATUS_ACQUIRINGDHCP

    Probable Causes:

    * your router is denying the lib's DHCP request; I've seen this on a few routers and am looking into it.

    * You have the wrong WEP key or mode configured.

     

    Problem:

    Fails to connect (ASSOCSTATUS_CANTCONNECT)

    Probable Causes:

    * Shared key authentication is enabled - the lib does not support this yet but it is planned for the next release.

    * your router has a configuration that is blocking the DS from connecting. (MAC filtering, or etc..)

     

    Problem:

    Connected OK but can't send/receive data!

    Probable Causes:

    * WEP could be incorrectly configured.

    * IP address may be manually incorrectly configured.

    * Router may be incompatible!

     

     

    If you guys have other problems connecting, please post them here - I'm sure there are other issues I haven't documented. I'm listing just the problems I know about at the moment.

     

    As always, good luck :(

    -Stephen

  8. Please direct your attention to http://blog.akkit.org/ Where the details of the dswifi lib version 0.3 release are being kept :D

     

    Many many improvements have been made to the library, and now at long last the lib has been released!

     

    Feel free to discuss the new lib here, or on my blog, and let me know if you run into any bugs or have any requests for new features.

     

    -Stephen

  9. Well, can you do a packet capture on the Smoothwall system? that would also clear it up quite quickly - or you could put an xp machine with 2 ethernet cards between the two and create a network bridge and capture from that.

     

    Off to sleep now, will talk tomorrow.

     

    -Stephen

  10. I think it's still possible you may be missing something (ethereal + most wifi cards under windows can NOT capture in promiscuous mode; it's essentially the same as being in a switched network)

     

    I'm not convinced you've managed to get the AP to communicate at a lower speed, and there may not be a way to do so.

     

    If you have an RA2500-based PCI or PCMCIA wifi card around (see http://ralink.rapla.net/) we can both verify whether or not data is being sent, and what rates it is being sent at.

     

    -Stephen

  11. (oh, and by the way, it's unlikely that the "PC was answered but the DS was not" - more than likely you are just using a switched ethernet network and the targetted response packet isn't being transmitted to your PC where you're monitoring, to save bandwidth.)

    Just thought I should mention such.

    -Stephen

  12. There's a *very* good bet that your access point is simply sending faster than the nintendo DS can receive - by it's nature the DS's hardware is limited to transmit and receive at 1 or 2 mbit/sec, and most access points I know are configured to blast data through the air far faster than that in most cases.

    I'd be willing to bet the replies *are* being sent (as the log would indicate they are) and the access point is simply sending them at too high a rate for the DS to receive them. You should check your options on the access point to see if you can drop the transmit rate down to 2 mbit, if you can't do that though, you will probably have to give up on it or use a different access point.

     

    -Stephen

  13. Hi, I'm making progress on the lib again (thought that would never happen, eh? :D )

    Anyway, I've just finished a modification to the test app that I think will clear up a specific kind of problem people are having with the test app.

     

    So, if you have had trouble with the test app in the past, please test the following, and let me know if it's still broken:

     

    wifi_lib_test_.nds - the .nds file does have some known issues evidently because of the loader built into ndstool - if you have problems with this loader please test using the .ds.gba file.

    wifi_lib_test_.ds.gba

     

    Thanks,

    -Stephen

  14. ...

    P.S. : Is there anyone, who knows, why I have to forward port 9999 on the client side too ?

    This is how I connect :

    -the client sends his login packet from clientIP:9999 to serverIP:9999

    -The server send his answer from serverIP:9999 to clientIP:9999.

    If I don'T have portmapping activated on the client side, the answer doesn't come through.... I thought the router should now where to send the packet, because it came back from the same port to the same port ?!

    It seems to work in wifichat too....Bafio, anybody ?

     

    You should use a random port on the client side, then it should work, I think. - next version of the lib will do this automaticly if you don't bind the socket.

     

    -Stephen

×
×
  • Create New...