Jump to content

sgstair

Premium Members
  • Posts

    203
  • Joined

  • Last visited

Everything posted by sgstair

  1. No problem Yes, what I mean as a "true" flashcard is a DS-card slot flashcard. -Stephen
  2. I'll also note that DragonMinded's DSOrganize has a built in download function to download homebrew from a list he's assembled on his server to a supported CF/SD card. See DSOrganize here: http://www.dragonminded.com/?loc=ndsdev/DSOrganize -Stephen
  3. Hehe, well, grey seems to have hijacked the thread 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
  4. 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. 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. 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 cards, and yet nearly everyone agrees on a very few range of options for homebrew; all the options are mainly for pirates. 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. 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
  5. *pokes head in* *suggests http://somafm.com/* *runs away* -Stephen
  6. There is a known issue with DHCP at this point, but I haven't figured out what's causing it yet - it is planned to be fixed by next full release though. -Stephen
  7. 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
  8. Ack, I tried to post here earlier and it didn't go through. Grey: I am working towards a release in the very near future - my official target is this weekend but it's unclear if I'll make that. -Stephen
  9. *pokes head in* oooh, nice sorry I didn't notice this thread to answer questions earlier. -Stephen
  10. 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
  11. 754boy: you have either a problem with open system authentication (which will be added in the next lib), or your configuration isn't set up the way you think it is - due to your explanation I can't tell which it is. thoduv: what kind of packet capture? I'm not sure what your problem is yet.
  12. 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
  13. 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
  14. Please see the newly created thread here (connection issues thread) which should help you solve your problem. -Stephen
  15. 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
  16. I'm sorry El Hobito, you just released this app and now I've already released another lib that changes a lot of things Good luck moving your app to the new lib though, it is a bit different -Stephen
  17. Please direct your attention to http://blog.akkit.org/ Where the details of the dswifi lib version 0.3 release are being kept 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
  18. The wifi lib test has been updated again! lots of new stuff! See the first post in the thread for current details -Stephen
  19. 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
  20. 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
  21. (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
  22. 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
  23. Hi, I'm making progress on the lib again (thought that would never happen, eh? ) 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
  24. 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...