[UberDjinn]

I know that alot of people have been complaining about the wireless not working in No$GBA v.2.6 or 2.6a (Pokemon) and it got me to wonder: is it possible to virtually emulate wireless? I am not a programmer but I was just thinking that the reason the emulator does not work with wireless is due the fact the program itself only emulates the environment for the games not the hardware, if that makes any sense. I think it needs to be integrated into the code so that the "hardware" thinks it is connected to the internet and then will allow for trading and other things.

But the problems are as follows:

1. How do you virtually emulate a wireless card? Is it possible for DS?
2. How do you allow it to integrate and the DS emulator to see it?
3. It is only a temperary fix: would be local ONLY
4. How do you make indentification so that two emulators on the same computer can trade or battle?
5. Is the area in the DS games for trading, battling, ect in the wireless mode allowed by the DS itself or Nintendo?
6. Friend Codes not supported unless through illegal and unethical means...

I know people will think I am a total idiot for suggesting this but I am open for suggestions and commments (and yes even critisms). Thank you.

On a side note: if a thread like this already exists, I did not know and let me know for future reference. Thank you.

 

[SCHUMI_4EVER]

Not gonna happen...and it's not quite the problem.
No$gba's current basic WiFi implementation is not broken, it's just not complete yet, it's main purpose although eventual WiFi emulation is the final goal it was not quite that just yet but mainly to allow games which have a WiFi check like for instance Pokemon games to pass that check (although even that fails in an area like the Underground).

Also from the no$gba homepage

no$gba/wifi can send/receive packets, commercial programs are still getting stuck somewhere in transmission. NEW in v2.4d: Pictochat is now successfully exchanging authentication and associations requests and responses. After that, on real hardware, the host should immediately send data frames (via port 090h presumably), in no$gba, the host doesn't send any such data frames for whatever reason (only the client does, via port 094h). Info on fixing that problem would be highly welcome. Built-in help text (in debug ver) contains almost complete wifi specs now.

 

[shashClp]

Let programmers do emulator implementation discussion, those ideas/speculations go from wrong to laughable.

 

[SCHUMI_4EVER]

Sure, i'll let you take over then. Keep it civil though please.

 

[shashClp]

SCHUMI_4EVER: I was not talking about your post, sorry if it seemed so

 

[SCHUMI_4EVER]

XD it's cool, just in the past in similar situations I had been overwhelmed by the person's strange arguments/also given slightly incorrect answers so you stepped in with all your technical knowledge to clear the situation up and I just figured you were stepping in before that happened this time.
It's all good either way

 

[shashClp]

No problem, just wanted to make clear, that after the phrase:

is due the fact the program itself only emulates the environment for the games not the hardware, if that makes any sense

There's no point to keep reading.

 

[UberDjinn]

I asked only because no one explained why the wireless does not work. I looked up about it and nothing was given for the reason why. Thank thank you SCHUMI for letting me know. I really hate it when people ask obvious questions and when looking around nothing is ever answered. So the programming is all that needs to be implemented...I wonder if the guy who does the No$GBA is still going to do it...(if he read some of the questions, I worry!)

I only asked because as I stated before, I am not a programmer but I AM a network guy and know how wifi works. Next time don't be so blunt and quick to judgment on someone else, shashClp.

 

[shashClp]

Really know how wifi works? Don't make me ask some questions to see how much you know, because I know programming and wifi, so I can ask and answer about both Now talking seriously, most of your proposals were VERY wrong from a programming point of view, not much sense to discuss them further.

 

[UberDjinn]

I will not get into an agrument with you...I at least tried to get an answer with what little information I could go on. I needed information and I got it, so now I will not ask anymore questions to this effect. Nothing was on the internet to go by except the dumb questions if wifi worked or will it trade...and I am sorry that I offend for just asking a simple and honest question...

If you were not trying to be the way you came off, I am sorry for being so blunt to you, Slash...and yes I know some people have the complex for stupidity...

 

[shashClp]

Well, the simple answer is that most of the DS wifi hardware inner workings are unknown, as it's the setup protocol (setup this register, check that, etc). Last time I checked, homebrew people were getting it to work on a bare minimum. Without some amount of information about how it does work, emulating (effectively reproducing it) is hard or impossible.

 

[UberDjinn]

so it is not just software related but might be a firmware issue too...nintendo should go into making an emulator so you don't have to hull a darn brick in your pocket...oh I wish that...

Also, it seems from what Shumi quoted that the structure of the wifi is similar to an ACK/SYN request and the communication is either not being sent or is dropped...though it is hard to tell due to the actual DS software itself...

 

[lagunareturns]

nintendo, and other console makers for that matter wont ever create current gen emulators ever. the answer is obvious it will hamper the hardware sales, it cost millions or close to it to hire developers to make everygame and feature of console to work and work with low system requirements and to make 90% of the expected audience happy to feature better graphics than the console, plus the fact it has to be so easy to use a dummy can use it.

oh and before you as about the ps1 emu on the psp, one they have a history to implement support for previous console games and two its origionally the code was a emu for pc (i think it was vg emu) and was bought out by sony, why it can psx games with very low haredware requirements and was very easy to set up... If anyone argues that the code isnt based on the emu then you didnt see it initially have the same compatability issues with the same games and the fixes/uppdates they applied to get more games working are the same as the patches and hacks that were applied to the emu

 

[shashClp]

(...)

oh and before you as about the ps1 emu on the psp, one they have a history to implement support for previous console games and two its origionally the code was a emu for pc (i think it was vg emu) and was bought out by sony, why it can psx games with very low haredware requirements and was very easy to set up... If anyone argues that the code isnt based on the emu then you didnt see it initially have the same compatability issues with the same games and the fixes/uppdates they applied to get more games working are the same as the patches and hacks that were applied to the emu

Any real proof of that (links/url/references), or you're just saying that and we have to believe? References and/or pics, or didn't happen

 

[lagunareturns]

how can i prove it without the source code, i just find it wierd to have the exact same compatability issues during the initial release on psp, like ff9 was with the emu on pc with a patch/hack applied to it...

let alone the fact it had a very similar list of compatability issues, i notice things like the timing (for audio syncing, delays/loadtimes and playing the audio exact same ways (like vagrant story having high pitched sound)) it used is the same way, or the fact was it had the same slowdpwns which are different to real ps1 hardware and every other ps1 emu... plus you are forgetting the most important fact is sony owns the code, they paid a ton of money on it and what they are going sit on it or use it where it was could be controlled and not hacked.

while the use custom firmware on psp allows unrestricted use, pops but there are no real hacks as of yet to change how it works or increase compatability or add extra features... please note I am aware of cwcheat and its able to work on pops but its more working on the game and not on pops... what i means is hacks like pops natively supporting save states, increasing rendering resolutions and/or adding a turbo button to speed up the game

 

[PsyMan]

how can i prove it without the source code, i just find it wierd to have the exact same compatability issues during the initial release on psp, like ff9 was with the emu on pc with a patch/hack applied to it...

let alone the fact it had a very similar list of compatability issues, i notice things like the timing (for audio syncing, delays/loadtimes and playing the audio exact same ways (like vagrant story having high pitched sound)) it used is the same way, or the fact was it had the same slowdpwns which are different to real ps1 hardware and every other ps1 emu... plus you are forgetting the most important fact is sony owns the code, they paid a ton of money on it and what they are going sit on it or use it where it was could be controlled and not hacked.

while the use custom firmware on psp allows unrestricted use, pops but there are no real hacks as of yet to change how it works or increase compatability or add extra features... please note I am aware of cwcheat and its able to work on pops but its more working on the game and not on pops... what i means is hacks like pops natively supporting save states, increasing rendering resolutions and/or adding a turbo button to speed up the game

It's not the same emulator. Sony might have used "parts" from VGS or any other emulator but at least the recompiler is made around the R4k.

 

[lagunareturns]

thats still using the code (i am not saying the exact same emu), optimisations that have been implemented and generally the code that makes the game work with low system requirements, you can tell it it is using the same ground work as vgs (thank you for reminding the name of the emu)

 

[shashClp]

how can i prove it without the source code, i just find it wierd to have the exact same compatability issues during the initial release on psp, like ff9 was with the emu on pc with a patch/hack applied to it...

let alone the fact it had a very similar list of compatability issues, i notice things like the timing (for audio syncing, delays/loadtimes and playing the audio exact same ways (like vagrant story having high pitched sound)) it used is the same way, or the fact was it had the same slowdpwns which are different to real ps1 hardware and every other ps1 emu... plus you are forgetting the most important fact is sony owns the code, they paid a ton of money on it and what they are going sit on it or use it where it was could be controlled and not hacked.

(...)

That means nothing, for example, several dreamcast emulators have the same issues when emulating some games, and yet still this doesn't mean anything. It's nice to speculate that it could be using the same code, but you don't have any proof, thus it's not more true than saying that's using pcsx code. Dissasembled code could be used to see if they're somewhat similar, but having the same bugs means nothing (more keeping in mind what I said earlier).

 

[Squall-Leonhart]

I'd just like to say...

It is impossible to implement wifi into the emulator. you can however emulate the wifi using certain methods.... vba-l uses pipelining for wifi and linking last i checked....

 

[PsyMan]

thats still using the code (i am not saying the exact same emu), optimisations that have been implemented and generally the code that makes the game work with low system requirements, you can tell it it is using the same ground work as vgs (thank you for reminding the name of the emu)

When it comes to this kind of software you can't really use the same optimizations on 2 completely different systems. It's technically impossible.

Also note what shashClp said about the same issues on different emulators.
The same applies for fixes happening at the same time on different emulators. Whenever new information and findings surface they usually spread to other projects too.