gbadev.org forum archive

EDIT: Test program available on page 3 of this post. (01/30/07)

---

I started working about a month ago on a WMB host for the DS itself (for a small game I'm working on to have multiplayer functionallity... to FlashMe'd DS's only of course).

Well, after a couple weeks of on and off work on it, I finally got my first success of hosting and sending a homebrew game from one DS to another DS (flashme, again, of course) through the Download Play DS firmware option.

The code is super ugly, and skips many many checks for things. (IE: Will not work if anything is on the same channel, at the moment).

I ran into a few issues.

To note, I'm doing this all through RAW packet processing.

1. Even running the code directly on the ARM7 (no IPC delays for packets and such) the top speed I was able to get the data sent to the other DS was roughly 300kbit/sec. Much slower than normal DS to DS in retail games. I noticed that just sending raw packets one after the other with no processing (just to test) resulted in about the same results. So, I'm not 100% sure how they're able to get the speed boost.

2. For some reason, the wifi init code (most from dswifilib) only init's the wifi about... hrm... 60% of the time? Other times the wifi hardware still isnt usable. This I am having serious hair loss trying to figure out.

3. Not completely sure how to get multiple DS's to download at once. Software issue, but, none the less, an issue I'm having.

I'm going to tidy the code a bit and post it later on. Right now its an ugly buggy nightmare, but with success.

My main reason for posting this is, has anyone figured out how the retail DS games (including the DS Download Station) host the data? It must do something other than RAW TX/RX to handle the data, because, thats just not fast enough.

Also, I attempted to make a Download Play Client as well. It works fine with WMB hosted on a PC, and with my WMB DS host, but when trying to download a hosted Mario 64 game (or any other retail game) the packets are just too fast, and its impossible to get a response out in the 1ms window they give using raw TX/RX.

I'm assuming there is some way to get the WIFI hardware to directly respond to this data possibly.

It took hours of poking at registers just to get the DS Download Play Client (normal one) to receive raw packets correctly from my host.

A snippet if anyone is working on this:

Code:

// Makes WIFI Hardware receive and store ALL 802.11 packets (no filtering)
WriteWifi(0x80D0,8095);

// I've dubbed doing this "True Raw TX Enable"
// Doing this makes the DS Wifi hardware NOT modify any outgoing packets for duration, sequence, etc.
WriteWifi(0x8194,0x05);

// I'm thinking this has something to do with contention free timing? (I'm probably way off)
// but without this being set, the DS Download Play Client seems to ignore any packets from my host
WriteWifi(0x81A0,0x91D);

Hopefully thats useful to someone. If not, it will at least show I'm not a complete idiot, considering this is only my second post on this forum. :)

If anyone has any advise on this, please post and let me know. Any help is appreciated.

I hope to condense this all into a simple usable library to host .nds files from a DS. Hopefully someone will use it in a multiplayer homebrew game. ;)

Cheers!
_________________
My goodies: 1xDS Lite - Supercard Lite, DSi, Supercard DSONEi

Last edited by Juglak on Tue Jan 30, 2007 3:31 pm; edited 1 time in total

Wow! This is amazing!

But don't you need adhoc mode if you actually want to use wireless multiplayer after you downloaded the game?
_________________
Nintendo DS homebrew on Wikipedia

Great!

The filtering was something that prevented a lot of things! Thanks for poking that out.
_________________
GBAMP Multiboot

Excellent work figuring out the register settings.
I looked into this a while back (there is a not working DS version in the source for my WMB for linux host). Some register settings that got my host partly working were:

Code:

8012 = 0x703f
81ae = 0x1fff
80d0 = 0x0301
80e0 = 0x000d
8008 = 0xe000
8004 = 0x0001

The problem I was having was that the Wifi would die at some point during the transfer (every time). I never figured out why or how to recover before I gave up. Trying to figure out the Wifi settings was not fun and a rather lengthy process.
One of my reasons for putting a GDB debugger stub into the Desmume emulator was to have a look at wifi setup (not got round to it yet).

Hopefully your work will help make DS to DS multiplayer a possibility.

On the client side you seem to have hit the same problem as I did (regard to speed of response). I got an email a few months back from somebody saying that they had run my WMB client with some success and had then gone on to develop a Pictochat client (never heard anything more though) so it may be possible. Never did port the client to the DS.

felix123 wrote:

But don't you need adhoc mode if you actually want to use wireless multiplayer after you downloaded the game?

That or some sort of soft-AP mode, which a program using "true raw" mode could do in theory.

But for people like me who carry a NoPass + GBAMP (or a NoPass-RW), pak-swapping is probably a more reliable way to get your multiplayer game booted on multiple machines than flashing them all and using WMB.
_________________
Driven from Tilwick by ice storms, couldn't fit in in Flower Bud...

Nintendo DS: With two ARMs, who needs legs?

tepples wrote:

felix123 wrote:

But don't you need adhoc mode if you actually want to use wireless multiplayer after you downloaded the game?

That or some sort of soft-AP mode, which a program using "true raw" mode could do in theory.

But for people like me who carry a NoPass + GBAMP (or a NoPass-RW), pak-swapping is probably a more reliable way to get your multiplayer game booted on multiple machines than flashing them all and using WMB.

A WMB host acts similarly to an Access Point (with some changes to the frame formats) so it would not be too much work to make an AP for multiplayer game networking. The big problem is getting a better understanding of the hardware to get good performance out of it. For example, if the filtering was fully understood then it would save the DS processing frames which have no meaning for it.

masscat:
I had tried to make a Pictochat client as well, but again, speed issues. The pictochat "server" in the standard DS firmware just sends/receives packets too dang fast.

If I can find a host somewhere that wont kill my files, I'll try and post some tests I've made.
They're ugly, but they work mostly.

I can boot snesDS.nds with Super Mario World (about 1MB) consistantly with my code. I've tried files up to about 3MB and they work just the same. Just takes ages.

Right now, you put test.nds in the root of your CF/SD card (gba_nds_fat) and load up the host, and it broadcasts beacons on channel 13, then responds to the first client that requests it.

Also to note, that my beacons arent consistantly received by a client DS? As in, my game ad sometimes never shows up in the download list, even though passively capturing with the PC shows the beacons are in fact going out. A restart of my host usually always fixes it though.

Well, anyway, I'm going to clean up this source a bit, comment it a bunch, take out use of my crappy libjuglak (lol) and make it pretty standalone.

Cheers.
_________________
My goodies: 1xDS Lite - Supercard Lite, DSi, Supercard DSONEi

Are you transferring the entire file with the downloading DS on the Download Play screen? If you put a little program on there (a few kb) that communicates with the first DS when the Download Play screen fades out, you might be able to pull some extra kbit/s.

NeX wrote:

If you put a little program on there (a few kb) that communicates with the first DS when the Download Play screen fades out, you might be able to pull some extra kbit/s.

I am sending it all to the download play screen now, yes.

One issue with that is that the data packets are limited to about 512 bytes, so, using a custom prog. to load would probably speed things up a bit (about 4x).

But, would be nice to have it all done... well, normally I suppose. :)
_________________
My goodies: 1xDS Lite - Supercard Lite, DSi, Supercard DSONEi

Is there a reason why you can't use Wireshark to get a dump of the wireless packets?

That doesn't help you decode the registers, but at least it would frame the problem (how often does it beacon, is it using official 802.11 packets or something else, is it pure UDP, or actual TCP, etc.)

I use some custom software and the DS wireless card driver for the PC to capture the packets in a similar fashion for analysis in various other software such as Ethereal and some other DS specific analysis programs I've written.

The timings are all there, and you can see distinct differences between my hosting (using TX/RX of raw frames) and a passive capture of a retail DS game hosting.

The differences are really only in timings, as I've pretty much emulated the protocol exactly as a real DS would. The problem is, using raw TX, my host can't send packets out even close to as fast as the retail game is somehow able to. There seems to be a delay of about 1ms (not 100% sure on that, dont have the captures in front of me) when sending raw packets on the DS (even using all three TX locations in the WIFI hardware).

I've tryed reversing a handful of retail games to determine how it is able to do this, but, without proper emulation of the wifi hardware, its pretty difficult. The closest thing to it is the $15 version of the No$GBA, which is able to actually boot the retail DS firmware and load up the Download Play Client in the emulator. The problem is, the wifi hardware isnt emulated at all yet, so, its pretty impossible to find out exactly whats going on, since the code checks the wifi regs for things and does different things accordingly. And since they arent emulated, theres no way to know if what it ends up doing is actually what the real ds would do.

Phew.

Well, hopefully sometime this week I'll have this code ready for at least a public beta.

I'm actually just rewriting it, since its SUCH a mess, and uses a library I wrote which is so messily written that I'd be ashamed to release it in its current state. So, I'm going to just rewrite it using only libnds, with all the wifi stuff completely contained in my code (since to just do raw TX/RX doesnt need a whole lot of the extra code in dswifilib used for IP protocol).

And then, I plan to continue working on it. But, even if I don't end up doing so (which is possible, I get pretty busy), it will be "out there" and useful to someone.

Cheers
_________________
My goodies: 1xDS Lite - Supercard Lite, DSi, Supercard DSONEi

I'm beginning to hate the DS wifi hardware... i think...

Well, I was working on starting a second, cleaner version of my WMB host, so I started by basicly copying and pasting the majority of the WIFI code over.

I set everything up, got it all ready, and tryed to send and receive some test packets...... nothing.

The hardware is acknowledging that it is transmitting my packets... but it isnt actually transmitting, and nothing is being received from my test software (which I have confirmed is indeed transmitting on the PC end).

It doesnt make any real sense, since, I just copy and pasted the dang code.

Then, I gave up on my existing code, and used the pseudo code on the wifi lib page to make my own... with the exact same result as before.

So, I thought maybe I broke the hardware somehow... tried my original binary... worked perfectly.

I'm just not understanding why this isnt working... driving me crazy.

What could I be missing? The wifi code is doing the exact same thing to the wifi hardware as far as I can tell. The fact that I couldnt get the pseudo code to work either is really what gets me.

Guess its back to scratch again... when my patience rebuilds...

-A frustrated Juglak
_________________
My goodies: 1xDS Lite - Supercard Lite, DSi, Supercard DSONEi

Maybe time to start looking for memory corruption, timing changes, etc.
_________________
I'm a PSP hacker now, but I still <3 DS.

Ok, I spent hours running the code through No$GBA debugger version... and still having problems.

The wifi registers are being set virtually exactly the same... I took out some repeated stuff, but, thats all. Even put that back and still no luck (on a real ds).

So, according to the emu, all is the same.

But the wifi on the real ds will not work.

Has anyone written their own wifi init code that works?

*rips out hair*

-J
_________________
My goodies: 1xDS Lite - Supercard Lite, DSi, Supercard DSONEi

Well put back the repeated stuff? As these are hardware registers, the reads/writes may be triggering things even if they're redundant.
_________________
I'm a PSP hacker now, but I still <3 DS.

Juglak wrote:

I took out some repeated stuff, but, thats all. Even put that back and still no luck (on a real ds).

Yah, I tried putting it back in, making it all exactly the same as before, and still no luck. :-\
_________________
My goodies: 1xDS Lite - Supercard Lite, DSi, Supercard DSONEi

[quote="Juglak"]

NeX wrote:

But, would be nice to have it all done... well, normally I suppose. :)

Sorry I don't have a lot of useful input, but I thought I would mention that pretty much every WMB game I have seen does the 'tiny program first' method. EG: Mario you send over a tiny program, and then it goes to the loading screen where princess sends the mushrooms.

I always figured they did this just so that you would have a nice loading screen to look at, but maybe they were trying to get around that packet size restriction afterall

I only bothered reading the first few posts, but if you think about it:

If you keep this up and manage to get a working DS download play downloader and a pictochat client, maybe then a completely customisable DS firmware could come into reality :)

While we are at discovering what the register values are, (i think) i just found out the meaning of the RF_Writes that are done from the firmware values.

If im correct, the wirtes consist of 22 bits each: bit0-bit17 is data, bit18-bit22 the address.

The register set seems to match (at least it would make sense to interprate them like) the register in http://www.rfmd.com/pdfs/2958.pdf

For the default settings in RF_Init() it looks like

Code:

RF_Write(0x00C007) ; // address 0: CFG - RF_VCO_EN | IF_VCO_EN | IF_VGA_EN | DIVIDER_BYPASS
RF_Write(0x129C03) ; // address 4: RFPLL1: Voltage(3) | NG_PHASE | AUTO_CAL | CHARGEPUMPLEAKAGE2X | CAL_EN | RF_EN
RF_Write(0x141728) ; // address 5: RFPLL2: DIVIDER(0x5C) | NUMERATOR_HIGH(0x28)
RF_Write(0x1AE8BA) ; // address 6: RFPLL3: NUMERATOR_LOW(0x2E8BA) => Numerator := A2E8BA
RF_Write(0x1D456F) ; // address 7: RFPLL4: VCO_KV_CAL(0x0F) | VCO_COARSE_Tun(0x06) | VCo_CAL_DELTA(0x145) ;
RF_Write(0x23FFFA) ; // address 8: CAL1: LOCK_DETECT_RES(0) | VCO1_COARSE_REF_CLCK(0x1F) | VCO1_TUNING_LOCKTIME(0x1F) | VCO1_WARMUP_TIME(0x1F)
RF_Write(0x241D30) ; // address 9: TXRX1: TX_BANDWITH_FILTER(0x2) | RX_BANDWITH_FILTER(0x2) | TX_GAIN(0x7)
RF_Write(0x280001) ; // address 10: PCNT1: TX_DELAY(1)
RF_Write(0x2C0000) ; // address 11: PCNT2:
RF_Write(0x069C03) ; // address 1: IFPLL1: VCO_CORSE_TUNING_VOLT(3) | LOCK_DETECT_EN | AUTO_CAL_EN | PHASE_DETECT_NG | COARSE_TUNE_EN | PLL_EN
RF_Write(0x080022) ; // address 2: IFPLL2: IFPLL_DIVIDE(0x22) ((default!))
RF_Write(0x0DFF6F) ; // address 3: IFPLL3: VCO_CAL_KV_DEF(0x0F) | VCO_CORSE_TUNING(0x06) | VCO_CAL_DELTA(0x1FF) ;

The reserved (forced 0s) seem to match, as well some of the default values are provided at the correct position in the registers.

I just dont have any clue about the logic behind these funky names, but i bet one of you guys might have ;)
:edit: the TX_GAIN ... looks promising for increasing the transmit range, doesnt it? *g*
_________________
GBAMP Multiboot

Last edited by Mighty Max on Mon Jan 01, 2007 11:03 pm; edited 1 time in total

Mighty Max wrote:

:edit: the TX_GAIN ... looks promising for reducing the battery life, doesnt it? *g*

Fixed.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

tepples wrote:

Mighty Max wrote:

:edit: the TX_GAIN ... looks promising for reducing the battery life, doesnt it? *g*

Fixed.

Or you could lower TX_GAIN, and get more battery life when you are near enough to your communication partner.
_________________
GBAMP Multiboot

Can these registers be used with the regular wifi lib? I sit right next to my AP so using the minimum amount of power for the wifi would be great as the debugger really chews my battery...
_________________
Big thanks to everyone who donated for Quake2

It should work, alltho changing the channels might overwrite the settings you put in. (Depending on if sgstairs rewrites all settings or just the ones needed for the frequency settings.

But you should be able to do a RF_Write to set it without breaking the lib. (See page 13 and following of the pdf for the accepted values)
_________________
GBAMP Multiboot

Figured out how to read the registers (and fixed the write, was missing the CR set)

Code:

#define REG_WIFI_RF_D2    *((volatile unsigned short *)0x0480017C)
#define REG_WIFI_RF_D1    *((volatile unsigned short *)0x0480017E)
#define REG_WIFI_RF_BSY    *((volatile unsigned short *)0x04800180)
#define REG_WIFI_RF_CR    *((volatile unsigned short *)0x04800184)

void RF_WriteRaw(unsigned long data) {
REG_WIFI_RF_CR = 0x18 ;
while(REG_WIFI_RF_BSY & 1) ;
REG_WIFI_RF_D1=(data & 0xFFFF);
REG_WIFI_RF_D2=(data >> 16);
while(REG_WIFI_RF_BSY & 1) ;
} ;

void RF_Write(unsigned long addr,unsigned long data) {
data = (data & 0x0003FFFF) | (addr << 18) ;
RF_WriteRaw(data) ;
} ;

unsigned long RF_Read(unsigned long addr) {
REG_WIFI_RF_CR = 0xFF98 ;
while(REG_WIFI_RF_BSY & 1) ;
REG_WIFI_RF_D1= 0x0000 ;
REG_WIFI_RF_D2= ((addr * 4) | 0x0080) & ~3 ;
while(REG_WIFI_RF_BSY & 1) ;
unsigned long in = 0 ;
in |= (REG_WIFI_RF_D2 << 16) ;
in |= REG_WIFI_RF_D1 ;
while(REG_WIFI_RF_BSY & 1) ;
REG_WIFI_RF_CR = 0x18 ;
return in & 0x3FFFF;
} ;

@simonjhall: Any result on changing them yet?

:edit:
Here are the functions to set PWR levels and TX Gain Value (the higher the less gain) :

Code:

void RF_SetTXGain(unsigned char gain) {
RF_Write(0x09,(RF_Read(0x09) & ~0x07C00) | ((gain & 0x1F) << 10)) ;
} ;

void RF_SetMaxPWR(unsigned char pwr) {
RF_Write(0x0B,(RF_Read(0x0B) & ~0x3F000) | ((pwr & 0x3F) << 12)) ;
} ;

void RF_SetMidPWR(unsigned char pwr) {
RF_Write(0x0B,(RF_Read(0x0B) & ~0x00FC0) | ((pwr & 0x3F) << 6)) ;
} ;

void RF_SetMinPWR(unsigned char pwr) {
RF_Write(0x0B,(RF_Read(0x0B) & ~0x0003F) | (pwr & 0x3F)) ;
} ;

Gain value: 0 = max gain, 0x1F = min gain

PWR Values: User programmable MAX output power provided. This
allows the power control function to be customized for various PA?s. The 5
MSB?s are integer portion in dBm. The LSB is 0.5dBm.
_________________
GBAMP Multiboot

Nice work all.

Been super busy lately... sorry. Going to get back on this project soon though.

-J
_________________
My goodies: 1xDS Lite - Supercard Lite, DSi, Supercard DSONEi

Arg. Been busy lately, still. So many projects. A lot not DS related.

Anyways... I was trying to get this to work again with my new clean version of the program, with no luck.

I think, just for the heck of it, I'll post a binary of my super crappy version, assuming I can find somewhere to throw it... just as proof of concept, since it does work... just not very consistantly.

I'm going to start over again on the new version, I think. I'll probably start with the latest dswifi from the devkitpro CVS repository. Get that to function, then rip out everything I won't need. ARM9 doesnt need any way to do anything with the wifi, really, for this to work. No TCP/IP, etc. Heck, not even AP Auth/Assoc/etc are needed.

Then, assuming it still works after ripping all the unneeded stuff out, I'll add the WIFI_REG entries to enable raw RX/TX (posted earlier) and reconstruct my WMB server code, all on the ARM7... to reduce delays as much as possible, for one... and to just make getting/sending packets that much easier. Also would make for decently simple implementation as a library for hosting WMB games in other programs (which is my "ultimate" goal i suppose)

Anyways... if I can find somewhere to put this file, I'll post a link to it so you people who want to send an NDS file from one DS to another for fun, can have your thrills. :P

-J
_________________
My goodies: 1xDS Lite - Supercard Lite, DSi, Supercard DSONEi

Alright, here it is... hopefully...

A quick google search for some free file hosts turned up these places where I tossed the file. I dont trust any of them to keep files for long, so, if someone wouldnt mind putting it somewhere more perm, that'd be great.

Links:
http://www.2send.us/uploads/190b476d52.zip
http://www.filefactory.com/file/b32fc1/
http://www.badongo.com/file/2079306

...

To use, you'll need a flash cart that works with the old gba_nds_fat lib...

Put the NDS file you want to be sent in the root of your media named test.nds.

Fire up my binary, and it SHOULD start spitting out WMB Beacons on channel 13.

Grab another DS and open the Download Play screen.

It'll show up as something generic, eventually, when the second DS finds the broadcast.

Poke it, download, and wait.

It's pretty slow. Well over a minute for a 2MB file. But hey, it works.

Keys:
Right Trigger - Mode 1: Back to broadcasting beacons... THIS IS THE ONLY MODE THAT CLICKING A DOWNLOAD WILL ACTUALLY SUCCEED IN... (default mode)

Left Trigger: Mode 2: Poke wifi regs... not much use now, but, who knows... up and down change values, A reads the value, B writes it.

Start: Reinitialize the wifi hardware. Don't do it unless its just not broadcasting... reboot is more likely to succeed.

Notes:
* Because of some bugs I've yet to locate, the program doesnt always initialize correctly. Might take a couple restarts to get it to work.

* I've only tested this with my SuperCard Lite (SD), but I compiled the fat lib with everything else enabled as well, so, it SHOULD work with others.

* Sometimes, again due to an unknown bug, the download will show, but clicking it fails and the host somewhat hangs. Press the RIGHT TRIGGER to go back to broadcasting beacons. That should unhang it.

I think thats it. Hopefully this is of some use to someone. If my source code wasnt such a mess and completely embarrassing, I'd post it. But, I'll get the clean version working before I do.

Have fun sending stuff from one DS to another!

-J

Edit: Almost forgot... this can only send to FlashMe DS's... it doesnt send the SHA1 signature if it exists.
_________________
My goodies: 1xDS Lite - Supercard Lite, DSi, Supercard DSONEi

DownloadPlayHost.zip 170KB

WMB_Host_0.1.zip 1,447KB
_________________
GTAMP.com/DS

Last edited by Sektor on Tue Jan 30, 2007 4:42 pm; edited 1 time in total

Hm, I'll have to try this tomorrow. No way to get the binary to my miniSD card while here at school. Good thing I flashed my friend's DS a couple of weeks ago.

It worked. I renamed spoutex.nds to test.nds, put it on a DS-X and used your program to send it from a DS lite to a flashed silver DS. It took a few tries and reboots but at least it worked. This is the first homebrew I've used that was able to communicate with another system without a router in the middle. Nice job, it has great potential.
_________________
GTAMP.com/DS

Excellent. Glad to see it works for someone other than me. Thanks for testing. I'm working on the better version. So far so good. I'll keep everyone updated.

-J
_________________
My goodies: 1xDS Lite - Supercard Lite, DSi, Supercard DSONEi

I saw this yesterday but didn't get around to test it until today.

I've tried to get it working for about an hour now but it just doesn't seem to work.

I'm using M3 CF and the "test.nds" I'm trying to send is the game Nibbles (by DesktopMan).
The furthest I get is this the other DS getting the beacons, accepting the transfer and it starts sending for a VERY short while:

Quote:

{Beacons}

* 0000:0000 - 81A0=0911
*(2/5)

Received Association Request...
B

After that I get a communication error on the second DS.

Yah, not 100% sure if it will work with all flash carts. :-\

It should be saying "DS ACKED DATA" or something along those lines at the top of the sub screen when its sending.
_________________
My goodies: 1xDS Lite - Supercard Lite, DSi, Supercard DSONEi

I get the exact same thing as Agilo does, using a Supercard miniSD. I didn't have a chance to try other files, as we were limited on time, but I got that exact error message each time I tried to send the file.

Jugluk, you got PM.

:edit: observation deleted, issue was resolved in the desmume cvs.
_________________
GBAMP Multiboot

Last edited by Mighty Max on Sun Jan 28, 2007 8:15 pm; edited 1 time in total

Thanks for your hard work

Tried it today and it doesn't really work. DS1 is silver, originally firmware v2; DS2 is white, originally v4. Both are phat with Flashme v7.

With DS1 as host, the download only showed once on the download play screen. With DS2 as host, it showed for all except one in about half a dozen tries. In all cases, I get communications error within seconds.
_________________
Nintendo DS homebrew on Wikipedia

Yah, it has some issues for sure...

As for the IPC stuff... i'm not actually using the FIFO. I've just got a struct of variables and pointers in uncached ram (0x02400000+ area), and its polled and such. Pretty crappy method, but it works for testing stuff.

I've only gotten it to work with my DS Lites... I tested it on an old DS that I put flashme on for a friend, and it was able to be the client, but my host wouldn't completely fire up the Wifi for whatever reason, consistantly.

As for you getting it to show up in the download play list, that means its working and Wifi is inited successfully. But, if communication just fails after attempting, it means my code just cant find /test.nds. It doesnt actually do any checks for it to see if it actually exists or whatever. It just assumes it is, and when its not, the RAM addrs are all 0's, so the client DS simply rejects the RSA header and fails.

I've almost got the cleaned up version working, so, I'm going to post the source soon. Hopefully then it can be modded to work with more than just my supercard lite.

Most likely isnt working with other supercard products, because I modified the ASM for the write routings for the supercard so that write access worked more reliably. But I dont think the new routines would be fully compatible with other versions.

More to come...

-J
_________________
My goodies: 1xDS Lite - Supercard Lite, DSi, Supercard DSONEi

The wifi init did take use of the FIFO, and it was trying to receive from an empty fifo. That was however caused by a bug in desmume, which is now fixed. (a register write to 0x04800000 and up was overwriting the regular HW registers)

Your DownloadPlayHost now returns the correct MAC address and initializes everything to send. Now just need to find out why everything it sends are a set of zeros.
_________________
GBAMP Multiboot

Ok, after many hours of back-breaking hard work, I have finally completed the cleaned up, fully working version of the WMB Host program for the DS.

Here are some links to download it from some free upload sites I found. Hopefully one or more of them will be working when you attempt to download this.

http://www.2send.us/uploads/62df474e38.zip
http://www.filefactory.com/file/37a70e/
http://www.badongo.com/file/2126031
http://upload2.net/......./WMB_Host.zip.html
http://d.turboupload.com/d/1480045/WMB_Host.zip.html
http://www7.spread-it.com/dl.php?id=.....
http://www.keepmyfile.com/download/85d9d81359419

All except the top link are NOT direct downloads. So, probably shouldn't try directly saving them.

Again, if someone would be kind enough to host these somewhere more perm, and post a link, that would be great, as I don't have any webspace anywhere at the moment.

The software binaries and source code are included.

This basicly works the same as my original binary, with some changes. Mainly, the souce code is pretty clean and I'm not too embarrassed to release it. lol.

Another difference is, if it can't find and use your GBA flash cart's file media (SD/CF), then it will use a small demo I've added to the binary (you'll find it lz77 compressed in the data directory of the source code).

That way even if you don't put a test.nds file in the root of your media, it should still host something, for demo purposes.

This code should repeat over and over for multiple downloads. Only one DS at a time, though.

If the code hangs (Communication failure on the client DS) just press X on the host and it will reset the state machine from the beginning.

Again, this only works if the client DS has FlashMe installed.

Files must be able to be loaded and fit into DS main memory for hosting, currently. So, that limits you to about 2400KB for test.nds. You can recompile with a smaller demo program to squeeze another 450K out of it probably, if needed.

I've tested this code with several different DS's, all successful. Sometimes the host would hang a few times, but it always eventually worked. All tested using my Supercard Lite (microSD) GBA cards, and using Tim Schuerewegen's PC based WMB host to test the demo broadcasting when no GBA cart is present. Overall about 90% success.

As far as the code goes, it simply uses a lot of shared RAM (uncached main ram) to do interprocessor-com. No fifo is used, just to make things a little simpler. Probably not the most efficient method, but, the wifi hardware delays the sending of packets enough that it doesnt make the slightest difference how fast the IPC comm is. I've tested directly shooting packets from the ARM7 with no IPC and they come out just as quickly as shooting them over my IPC memory.

The wifi hardware is init'd using init routines from the latest dswifi lib, slightly modified to be able to TX/RX truely raw packets. The dswifi lib ARM9 side has been removed, along with any TCP/IP code, AP search, etc etc.

I added some checks to make sure the MAC address packets were going to was actually the DS host before it responded, which I neglected to do in the previous version and it caused random problems with stray wifi traffic.

I've hard-coded the use of channel 13. I figured it would be the least traffic'd channel in the USA, since it can be used, but most wifi hardware only goes to 11. Also, beacons need to be modified to tell what channel was being used and such, and I, well, just didn't write all that. So, channel 13 it is.

Well, hopefully I've started to inch open the floodgates for multiplayer wireless homebrew everywhere.

Enjoy.

-Juglak
_________________
My goodies: 1xDS Lite - Supercard Lite, DSi, Supercard DSONEi

Good job so far. But in order to actually send FlashMe and not just official demos ripped from DS Download Station, you'll need to figure out how the protocol of Super Mario 64 DS or some other DS Download Play multiplayer game works and then exploit that to load homebrew.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

The main problem should be solved when declaring RIPC as volatile.

It is not guaranteed that a while(nonvolatile == 0) ; will exit when the memory content at &nonvolatile is changed (i.e. through the other CPU). The while might be using a register representation of nonvolatile within the while loop.
_________________
GBAMP Multiboot

Mighty Max wrote:

It is not guaranteed that a while(nonvolatile == 0) ; will exit when the memory content at &nonvolatile is changed (i.e. through the other CPU). The while might be using a register representation of nonvolatile within the while loop.

Although ideally, a compiler should detect when the loop condition depends on a variable whose value does not change in the loop and then give a "warning: shouldn't this variable be volatile?"
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Tried this with two DS Lite's and a M3 Lite (MicroSD) adapter and it worked perfectly. Excellent job! In fact, it works even better than the Windows WMB host that can't send files to the newer Lite model I have here. :)

I guess the obvious feature request here is a file selector where you can choose which file to send, this would then be a perfect software for application sharing with friends having flashed DS's...

I have some suggestions:
1) DLDI
2) You should base it off a demo/dlp game so you can send it to not-flashme'd DS's, or just crack the RSA code.

Gunnex wrote:

2) You should base it off a demo/dlp game so you can send it to not-flashme'd DS's

That would be WiFiMe2, which nobody seems to have the time to investigate because NoPass and SLOT-1 flash cards are so easy to buy and use.

Quote:

or just crack the RSA code.

That could take centuries.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Nice. I don't suppose anyone's made progress on a homebrew Download Play client?
_________________
I'm a PSP hacker now, but I still <3 DS.

Thanks for releasing the source!

A quick note: when I compiled it it told me it was unable to find "riyo.h" (in the arm7 code) so I had to change

Code:

#include <riyo.h>

to

Code:

#include "../../ARM9/Source/libriyo/ipc.h"

After that, it compiled.

As for sending; my second DS isn't picking up the beacons at all now (whereas last time it did --after quite some time-- but it failed when sending).
I thought it crashed after it went into mode 1 (when you press X) so I added some iprintf's to make sure (and it didn't crash, it just doesn't show anything after pressing X :P).

After an hour (literally) of continuous testing I became desperate and thought to try the SuperCard version (I have an M3 adapter, CF version), which (when launched) worked instantly. :S
Anyway, it still didn't recieve anything (it hung at "* Sent RSA Frame..."), even after resetting dozens of times.

I tried multiple files as "test.nds" and none seemed to work.

I then removed "test.nds" completely and tried the built-in demo and after all this time, that did finally work!

edit: I now know what the problem was.
The .ds.gba version was never in the original zip file (I thought the .nds was it, that it had been renamed already).
I removed "cp $(TARGET).sc.nds H:/" from the makefile (It caused an error for me when compiling; I have no "H:\") and a .ds.gba file was made, I placed that on my M3CF as .nds and it works.
I'm now trying to send the "test.nds" again, but so far; no luck (10 minutes into it now, doesn't look promising).

edit 2: Sending a custom "test.nds" fails (spent half an hour with a few different "test.nds" files), but it doesn't matter, the point is made: it works! :)

Just tested it with a Phat SCSD with FMv7 hosting and a Plain DS lite. It seems to work ok (well, the Lite isn't flashed, so I can only guess). I've tried the sc.nds version but it doesn't seem to make any difference. One difference I did notice was that when the Lite was low on battery it didn't seem to like transferring properly, it would always hang on 'Sent RSA frame'. Keep up the good work!

Does anyone tried to reuse this code to make ds <> ds wifi communication (a simple talk program for example)?

We need somebody motivated in order to write a ds to ds com lib (libds2dswifi?), it would be a great progress for the nds homebrew scene!

Ok, here it is how I got it working with two phat DS, Flashme Silver, it worked always if I did it like this, but not if I did it like described ( I use a Gbamp):

1. Start Application and wait until the other DS has found the Juglak WMB Host
BUT DON'T DOWNLOAD IT RIGHT NOW !!!!!! Just let it like it is.

2. Shut off the sending DS, and start it up again, open the WMB Host Program the 2nd time.

3. Wait 10~20 Seconds then press the A button twice on the recieving System.

4. Now it should download and then run the Application.
_________________
Starcraft DS ?

Last edited by pas on Thu Apr 12, 2007 10:35 am; edited 1 time in total

great job. i haven't tried it yet but great job

wow.. that sounds like a lot of work.. but damn.. great work guys. i know u were looking for a place to host it more permanently so i'll host it for ya..

you can dl it here now:

www.dsrepublic.com/files/WMB_Host.zip

thats a page i planned to do something with but really haven't yet.. just that front end radio thing.. either way.. i'll host some files to help the scene. i can give someone on this project access to the ftp if you want so u can upload updated versions of other projects.. all i ask is u don't go nuts with it ;)

thanks..
_________________
/ . o 0 avid 0 o . /
[ NDSL + R4DS + 2GB SANDISK MicroSD TF ]

Wow... so when we release our 3D version of our Super Smash Bros. Clone (a.k.a, Sensational Smack Bretheren Clash!) the code should have progressed enough to allow us to do wireless multiplayer, right? Now if only I could set up a dedicated server for online play... ^_^

If you haven't noticed yet, Summer has come along. We're working on dual versions of the game (a GBA and an NDS one) so keep an eye out for updates on both. I fully plan to emphesize multiplayer on both, so keep me posted as this develops, it looks promising. ^_^

-gamefreak
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

*Removed text asking
Juglak to release his Download Play client*

There are people that don't have FlashMe.(Me included)(We
NoFlashMe users use something like NoPass or
something similar for homebrew.)
(Since us NoFlashMe users
don't have FlashMe,
we can't run the
programs sent by
this program.)

As for the speed problem,
maybe crishm,
or one of the libnds developers,
could could try to RE
some of the official games
to try to find out how the
official games do local wireless,
for DS download play.(What registers are set to what
values, and ect., not the format/spec for the
frames in those games)

As for having more than 1 DS client
download through DS Download Play,(I haven't tried this)
maybe you could try the following:
(Note, the following suggestion
is differn't than what official games
would do.
The following suggestion has
the host communicate with newly connected
clients, and already downloading
clients at the same time.)

Have a dynamicly alloced
array, for a list of addresses of the clients.

In the Timer_Beacons function,
you could move the state machine there.
(the device that handles DS Download
Play Wireless)

Also,
you could have a dynamicly alloced
array which contains the mode
the state machine is in for each client.

And in the Timer_Beacon function,
you could have it loop through
both dynamicly alloced arrays.

Also,
I have found 3 bugs in this program.
These bugs are all in the code for the ARM9,
in the main code.

I have never used the dswifi library,
nor have I used WiFi, in programming for DS.(This is because
I don't have the hardware for WiFi on the DS.)

The first two have to do with the
numbers shown about the current/total
number of players.

The last one has to do
with when it broadcasts its
ad for the DS Download play clients.

The current/total number of players bugs:

On the offical multiplayers games which
have the DS Download Play option,
in two player mode,
when the host is only broadcasting,
the numbers look like this:
1/2

These numbers is the current/total
number of players.

But,
In this program,
the numbers always look
like this:
0/1

This is because,
in the source,
it only includes the clients,
not the host,
in the numbers shown.

Here's how to fix it:

On line 223,
it says this:(In the SendBeacon function)

Code:

ds->advert_sequence_number = 1; // max players at this point?

This is actually the total numbers of players.(Including the host.)

Change it to something like this:

Code:

ds->advert_sequence_number = connected_clients + 1;//Total players at this point.

connected_clients is a parameter in the SendBeacon function.

ds->connected_clients dosen't do anything,
that I know of.

On Line 508,
it should say something like this:(In the main function)

Code:

ad->max_players = 1;

Change the value it is being set to, to 2.

The Ad/Beacon timing bug:

This program broadcasts its ad/beacon
all the time, unlike the official games.

The official games stops broadcasting there ad/beacon
once the host starts sending the game
to the clients.

This program broadcasts its ad/beacon all the time.

Once the following modifications are
done, the difference between the total time
taken to transmit an program goes down ~3 seconds.
Unfortunatly, that isn't signifignate enough
to affect the transmit speed much.

To fix this, do the following:

Add this line of code near the top of the source:

Code:

bool allow_broadcast = true;

Once you do the rest of these modifications,
it will only broadcast its ad/beacon when
this variable is true.

At the top of the Timer_Beacons function,(before the call to SendBeacon)
add this code:

Code:

if(!allow_broadcast)
return;

This will make the program stop broadcasting
its ad/beacon when allow_broadcast is false.

In the WMB_Main function,
in the if control statement
mode==4,
after vblank_happened=0,
add this:

Code:

allow_broadcast = true;

At the end of that function,
above the last } in that function,
add this code:

Code:

allow_broadcast = true;

Last edited by yellowstar on Wed Dec 12, 2007 3:19 am; edited 2 times in total

I have found another bug.

Instead of communicating on the correct channel,
channel 13,
it communicates on channel 11.

At least according to the CFTP version of DSFTP,
in the Packet Capture Tool.

HyperHacker wrote:

Nice. I don't suppose anyone's made progress on a homebrew Download Play client?

I am trying to make one.

But, it never makes it past the Authication step.

According to the tool I metioned above,
it dosen't send its frames for the Authication step.

yellowstar wrote:

According to the tool I metioned above,
it dosen't send its frames for the Authication step.

Or maybe... Those frames are sent at a different speed than 2Mbit/s... Sneaky.

Or maybe thats impossible and I'm totally wrong :P
_________________
If I use a term wrong or something then feel free to correct, I?m not much of a programmer.

Original DS Phat obtained on day of release + flashme v7
Supercard: miniSD, Kingston 1GB, Kingston 2GB
Ralink chipset PCI NIC

Is there an easy way to convert either efs or wmb_host so that they are compatible?

I have a game that stores info using efs, but when downloaded it canot load the efs data... I assume memory problems.....

anyone know about where stuff is stored able to help?

cheers.

EFS tries to load the filesystem from a DLDI compatible device and not from DS RAM. Best to either embed your resources in the NDS (rather than append) or if you want the .nds to send quicker/fit into RAM then load your resources from a slot1 or slot2 device using libfat.
_________________
GTAMP.com/DS

I thought the efs append meant that when I sent the nds for download, these files were also sent and therefore in memory rather than on the card......hmmmm.... poo

I am trying to continue the comms after a download so that you can download a game and then play multiplayer.... making very slow progress as I'm not 100% sure of what I'm doing..... anyone else working on this?

Are you trying to use liblobby or code based on this WMB_host?

I am using WMB_Host as I have got that working..... I guess you are going in the other direction, starting with your lobby and working towards download :)

I am at the stage of getting the two correctly setup.....

That idea concerning liblobby and WMB in that other topic is purely theory. I never tested it, but I don't see any reason at all why it wouldn't work.

So you're trying to associate the two DSes after the WMB transfer, so they can begin multiplayer? If so, try analyzing the code in WMB_host for the associating step.

Be careful with this WMB_host... It's possible you'll screw nearby WiFi devices, as mentioned in the liblobby topic. You should format the packets in the 802.11b standard to prevent this.(Again, check the source for this)

Which do you think is the best way to go?

WMB_Host -> multi

or

LibLobby -> download

? Hmm not sure where to start.....

WMB_host. It would probably be faster than liblobby.(liblobby file transfer rate is ~4.0 KBytes...)

Thanks for the tool. I tested it and it works fine with the included demo.
I was not able to broadcast another file with it, because it doesn't find "test.nds" or so.

I wondered if this would work with official DS demos from Nintendo (even to unflashed DS units)?

That would be cool, because I'm currently capturing official DS demos from the Wii's "Minna no Nintendo Channel".

But I still need help assembling them to .nds files! It would be awesome if anyone could help me:
→ http://forum.gbadev.org/viewtopic.php?t=15117 (Namco Museum DS Demo included)
Thank you.

Filb wrote:

I wondered if this would work with official DS demos from Nintendo (even to unflashed DS units)?

No, not without modification. I sucessfully modified this WMB_host, to send the RSA signature. My mod works with practically everything but the DS Download Station binary.(Out of all the demos I tested)
So, if you're interested in modding your copy of this host, I can let you know how.

Filb wrote:

That would be cool, because I'm currently capturing official DS demos from the Wii's "Minna no Nintendo Channel".

But I still need help assembling them to .nds files! It would be awesome if anyone could help me:

I can't help you there... I don't have a wireless device for capturing and such, so I've never gotten to the point of assembly.(I tried capturing with hb on my DS, but, failed)

Any chance of releasing the modified source code?

If my mod wasn't broken, I would release it now that somebody asked for it.
My mod of the WMB_Host strangely quits during the transfer, so the download is never finished...

I could rewrite the mod from scratch, but since my homebrew card is broken, I can't test changes myself... If somebody would step up and would do some testing of the rewritten mod, it could be fixed and released. The messaging would be done PMs. The PMs would contain a link to a zip archive containing a binary of the mod, which would be around 574 KBytes.
Source and binary will be released when it is finished.

Anybody that is interested, PM me. I will post here once a tester is found, stating that a tester was found, and whom the tester is, if he/she is okay with that.
(By scratch, that means starting over, and using the original WMB_Host code, and adding the mod to that.)

Not only does my mod do RSA, it also grabs banner data form the nds. This means on the Download Play screen, you would see the same icon, title, discription, ect, as the original demo did.(When it was captured from the DS Download Station, or wherever.)

Somebody has asked to be a tester, I will post later whom once I get permission. Since he has DSes with only FlashMe on them, I am going to release a beta version first, before the full version. Unless bugs are found, the full version will most likely be the same as the beta, minus the version number.

EDIT:
The tester is tepples. We have found that both this version and the old version have the same bug: The code which copies the RSA-signature and the SHA-1 into the outgoing packet, that's done before the RSA-handling code. So, the RSA-signature and SHA-1 are never sent, which cause the bug.

A while ago when I was tinkering with this,(When I got the RSA working)
I discovered something. This behavior is part of why both versions won't work as they should.

yellowstar wrote:

it seems that the DS WMB client intentionally quits on the host when the SHA-1 signature in the RSA frame is wrong.

I said before that I was going to do a rewrite...
Well, I decided not to... Basically I started with the original WMB_Host, and copied and pasted into the original...(The project is named differently of course)
The code is really difficult to rewrite... However, I improved the code for the mod, and in my opinion, it significantly better now.(I forgot the state that code was when I said rewrite... It was a long while ago since I ever looked at that code before recently...)

As long as this new version works, it should be released soon. But, tepples has only DSes with FlashMe on them, so he can't test the RSA-part of the mod. So, at first it will be released as a beta. Once a few people confirm that it works, it will be released as the full version.

Sorry it's taking so long to release this mod...

It works okay without any stray Wifi traffic, minus the occasional crashes.(Wifi means Wifi dongles, routers, and even DSes doing wireless)
But, with Wifi traffic, it starts to slow down, then it eventually crashes. I have some ideas, but I'm not sure if they'll work.

However, I just tried one idea. It crashed the first time, then the next time it worked. If it works for tepples, it will hopefully be released by tomarrow.(Maybe today if it's working good?)
(Or soon after the time when tepples reports that it's working)

EDIT:
tepples reported it's not working correctly. Looks like the release is delayed again.

Okay, I need some input. This mod is good enough to be released. Before I release it, I need some input.

This mod has a channel scanning scheme. Here's a description of it, from the PMs to tepples:

Quote:

This mod remembers what channel it used last. The first time it's run,(or when a certain file isn't found)
it hunts for a free channel, then saves the channel that's going to be used to fat. Next time the host is run, it uses the channel number that was saves to fat. It was designed this way to reduce time spent on channel finding, and in the process, it seems the host works better after power cycles.

Quote:

Power cycles are only needed after the first run of this mod. The cycle should be done right after it says which channel it's using.
The channel file would need deleted, and the above would need done, whenever other traffic shows up on the channel in use.
Really, the only time power cycles would need done, is on the first run, when stray traffic appears, and like you said, when you use the host
in a different location than when the host was first run, but only if there's problems.(However, it would be a good idea to delete and cycle whenever moved)

This channel code only scans on the first run, and then the channel file is created, with the used channel number inside. When the file exists, the code will only
use the channel number in the file, it will not scan. When the file is first created, the host should be power cycled.

The reason why there is such a scheme, is to fix errors/hangs. Most routers/Wifi dongles have their channel set to channel 11, when their is a Wii, or a DS Lite around with homebrew. By default, this mod scans channel 11 first. If 11 is clear of traffic, it uses 11, otherwise it uses channel 1 if clear, otherwise it uses the the first channel it finds to be clear of traffic, channel 10 and down.

So, my question is, those you that are going to use this mod, are you okay with doing power cycles?(Turn off the DS, then run the hb again)
As I said in those PMs, power cycles only need done on the first run of this mod, when you use the hb in a different location than the first time you ran it,(You'll need to delete a file on the card first)
and after the file was deleted.

However, for average home use, you'll only need to cycle after the first run, and the first time you run it after the file was deleted, or when the card's filesystem was formated/corrupted/ect.(Maybe delete the file and power cycle when you get more hangs than normal. Note that WMB_Host and this mod seem to preform best on channel 11/13, while other channels have more issues)

Just a warning: If nobody responds to what I said in the previous post, or people respond in a positive way, the mod will most likely be released Monday.(Don't worry, it won't get delayed this time!)(Most people would use the mod in about the same location all the time, usually, anyway.)

Here's the mod.

Here's the changes again:

1. RSA-signature is now sent. This means you can now send official demos, to DSes, with the original firmware.
2. Icon is now sent. So, you now see the icon in the .nds you send. For the built-in test hb demo, this is the original blue icon, description, game name, such. For an .nds off the card, the icon in the .nds is used, but this time the game name and discription is "DS Download Station Demo", for simplicity, and without dealing with buggy code for grabbing the description from the .nds. WARNING: Sending homebrew will result in a strange icon. You can resolve this by adding an icon to the hb. You could use the blue icon and such like the built-in demo.

Usage:
About the same as the original: Copy the mod's .nds to your card, then copy the demo as test.nds to the root of your card, then run the mod. Next, you MUST restart your DS.(See the above post about this)
Like I said before, you need to run the mod and reboot, when wmb_host_mod_chan.dat in the root of your card gets deleted, or when your card gets formatted, and on the first run of the mod.

My main issue with the previous release was that it used old gba_nds_fat code, so while I could send over the test file to my friend's flashed DS, it couldn't pick up the "test.nds" file on my card. I'm assuming this one was compiled with a recent version of libfat to correct this?

This is very interesting, something I definitely need to check out. I flashed a few of my friends' DS systems to get rid of the warning screen, so I'll see if they're interested in testing it out. Thanks for the update!

EDIT: just to clarify since I was confused after reading your post, this doesn't require an AP, correct? I can send a demo to another DS in an area that has no wireless AP nearby, right?

dantheman wrote:

My main issue with the previous release was that it used old gba_nds_fat code, so while I could send over the test file to my friend's flashed DS, it couldn't pick up the "test.nds" file on my card. I'm assuming this one was compiled with a recent version of libfat to correct this?

The answer to that is a resounding no.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

Dang. Is that related to the new DevKitARM release breaking all ad-hoc Wifi attempts such as this one? Or was it an upcoming libnds update that would do that? Curse my non-coder lack of knowledge.

I'll test it out anyway at some point still.

dantheman wrote:

My main issue with the previous release was that it used old gba_nds_fat code, so while I could send over the test file to my friend's flashed DS, it couldn't pick up the "test.nds" file on my card. I'm assuming this one was compiled with a recent version of libfat to correct this?

EDIT: just to clarify since I was confused after reading your post, this doesn't require an AP, correct? I can send a demo to another DS in an area that has no wireless AP nearby, right?

wintermute is correct, nothing changed for the filesystem, basicly only what I mentioned in the previous posts. A mod does mean that it's about the same as the original, except with some modifications. This is normal Download Play, it works similarly how official games do Download Play multiplayer.

dantheman wrote:

Dang. Is that related to the new DevKitARM release breaking all ad-hoc Wifi attempts such as this one? Or was it an upcoming libnds update that would do that? Curse my non-coder lack of knowledge.

I'll test it out anyway at some point still.

No, it's because I didn't attempt to update the code to libfat.

Well, maybe I should look into implementing libfat. Me and tepples will be communicating again if I decide to though.(My homebrew is completely totaled, it's useless now. a.k.a, a brick)
But, If I do implement libfat, I'm going to rip out gbafs.(That's used for the built-in demo)

I finished a beta release of the new version with libfat support. Instead of having tepples do it, I decided to let everybody test it as a beta - once a few people report success, this will be released as version 1.2.(This beta has a differen't URL than the original - once finalized, the original will be replaced with this one)

WMB Host RSA mod version 1.2 /w libfat beta.

How far would this be from using it for in-game comms?

Very far, about the same as the original. You'd have to handle all the wireless communication and such, just like you did before. Does the libfat beta work iprice?

Once I was trying to(in a different version from these main ones)
change the shared memory IPC,(This is for IPC, and TX & RX queues for wireless)
to FIFO. Here's something very interesting:

gbatek wrote:

Wifi Regions in NDS7 I/O Space

4800000h-4807FFFh Wifi WS0 Region (32K)
4808000h-4808000h Wifi WS1 Region (32K)
4810000h-4FFFFFFh Not used (00h-filled)

Wifi Registers appear more stable in WS1 region?
Wifi RAM appears more stable in WS0 region?
Wifi Registers & RAM cannot be written to by STRB opcodes (ignored).

Structure of the 32K Wifi Regions (WS0 and WS1)

4800000h-4800FFFh Registers
4801000h-4801FFFh Registers (mirror)
4802000h-4803FFFh Not used (FFh-filled)
4804000h-4805FFFh Wifi RAM (8K)
4806000h-4806FFFh Registers (mirror)
4807000h-4807FFFh Registers (mirror)

I'm thinking that the "... appears more stable in ..."
applies to the RX & TX queues. Doing this FIFO change is VERY difficult. And that's why I haven't touched that code in a good long while. And I really don't like the idea of having other people testing this branch.

I would test it, but I don't have any compiler or anything for doing this.
Which files would I have to download? Or can you provide a .nds?

Downloaded, built and used my own demo and worked fine..... I am still having problems getting the actual messages sent..... the format is OK, the handling is OK but its the typer and order that I have problems with.....

iprice wrote:

Downloaded, built and used my own demo and worked fine..... I am still having problems getting the actual messages sent..... the format is OK, the handling is OK but its the typer and order that I have problems with.....

I'm assume you're talking about your game based on this WMB_Host code? I really didn't think this mod would help your problems with your game... Is it the same problem you had before, with packets not being sent? If/when that Wifi mod gets done,(in the above post)
there's a very high possibility that your problems would be solved.(At least the packet sending failures)

@Flib: Whenever I get around to it, I'll send an PM to you, with an link to an .nds.

Any progress? Haven't been receiving a PM yet.

No. I haven't touched that code since I posted about that. I'm busy with that wmb_asm program and such right now. Once those things are done, I'll try to work on that code again.(That code is extremely difficult to switch over to FIFO)

Since nobody has reported problems with the libfat beta of this WMB_Host mod... Whenever I get the code implemented so it works correctly with binaries assembled by my wmb_asm program, I'll release WMB_Host mod version 1.2 final. Speaking of wmb_asm... I thinking about rigging my wmb_asm program so if it detects that if the host is the Wii Nintendo Channel, it would throw in some extra data. When sending the demo with this WMB_Host mod, the program will try to find that extra data. If it finds it, instead of having "DS Download Station Demo" for the game name and discription, it would have something like "Wii Nintendo Channel Demo".

Wmb_Host mod version 1.2 has been released.
The code has that libfat code. Also binaries assembled by my wmb_asm program should work correctly. All I did was change some code in the RSA-check code. Now, it checks the game code in the header. If it's the homebrew #### code, RSA isn't sent. Otherwise, it assumes that the .nds is an official demo, and sends the RSA.

EDIT:
Fixed link.

Wmb_Host mod 1.5b has been released.(beta)
No changes were done to the hostname code. The code which checks if the binary has a RSA-signature is different now. If the romSize field in the header is not the same as the filesize as the binary, the binary is assumed to have a signature. Otherwise, it is assumed to not have a signature. The banner is done better now. The offset for the banner is now grabbed from the first header, instead of the second header. Which should fix problems with some demos having a strange banner.(Which should fix the faded-nintendo logo-because-of-faded-RSA-check with some demos, and other problems)
Homebrew that doesn't have a banner, and anything that doesn't have a banner, should now have a banner/advert similar to the original banner for the hb demo included in the program. The game name and description should work fine now. The name stored in the binaries' description is used, and the description from the banner is used. Channel scanning code is better now. Now it only scans channels 1, 7, and 13. According to gbatek, these are the only channels the official WMB client uses.

Downloaded and tried your app. It doesn't work for me.

The main problem is that it isn't detecting the RSA stuff currectly. I am attempting to use this to send homebrew, but the WMP host program mistakes it for having a RSA when it does not, so as a result, the client ds stops with a communication error. I attempted to make a simple source code change to disable RSA checking, but the resulted file afte compiling is a ds.gba file which is useless to me since I use a slot-1 device for my homebrew and it does not use that format.

I'm sure this works great for RSA signed stuff like the official demos, but I'm left out in the cold here since it doesn't work.

I'd use a older version that has no RSA support, but those have no DLDI support either. I would recommend you make an updated non-rsa version for people who use DLDI.

As for what I would suggest for the next version. There is only one thing I request:

The ability to navigate and select the rom of choice instead of being stuck to using test.nds. This would eliminate the need to use the PC everytime you want to use a different homebrew/demo. If you must keep RSA enabled, at least give the ability to make the RSA detection to manual so I can turn it off if auto-detection doesn't work.

As of now, I still find it easier to just hack the european ds download station rom to send homebrew. Its a bit picky on what you can send, but at least it works.

And yes both DS's have been flashme'd.
_________________
Sig under construction...Please check back after the sun explodes....

Does the official demos work? I'll need to work on this... As for the file selection, I thought of that before, but that would be a major change for the UI and code. I might add that sometime however, but that RSA bug needs fixed.

ahh good to hear from the develper himself I was worried you moved on to other projects given the age of your last post here.

I'd understand the time it would take to improve the UI when adding that feature, so I'm in no rush for that.

As long as that bug gets fixed, I'm a happy camper! The UI improvement is just a luxery lol

By the way, whats the maximum file size for the rom you can send? So far all official Download stations crash if anything over 700kb-1mb is used. (but can very depending on which station rom your using)

Perhaps use a CRC check on the Security section? The Rom Header v2.0 tool I use seems to easily tell when a rom has a valid RSA, since the CRC would show as BAD for anything homebrew/modified. I used it on a demo rom and showed a security CRC as "OK" and shows "BAD" when using homebrew or modified retail games.

I'm no programmer, so I can't really tell how hard it would be to do that.
_________________
Sig under construction...Please check back after the sun explodes....

WMB Host mod 1.6b has been released.
This should fix the bug with homebrew compatibility. My RSA-check code, which checks if the .nds has a RSA-signature, assumed if the romSize field in the header, and if the filesize was different, the .nds has a signature. Normally, the romSize field would be the same as the filesize, minus the RSA-signature in official demos, and any appended data. I'm not sure, but devkitARM might have a bug. With homebrew, romSize is one byte less than what it should be. It's writing the correct number of bytes, it's just that romSize is wrong. My code now checks if romSize is the position for the signature, with: if(romSize >= filesize-136)//136 is the signature length. If this expression is true, the .nds has a signature.

"When I compiled it I didn't see any .nds..."
??? Are you sure you just didn't see it? It compiles fine on my computer.

"Client crashes..."
No, I don't think that was the problem. It was probably caused by the host trying to read the signature, when it didn't exist. This made it attempt to read data that wasn't even in the file, accessing memory outside the buffer, and thus crashing it. This would be called an "Access Violation" on a computer.

"Max .nds size?"
I don't really know. The DS only has 4 MB, so try to only send binaries ~3 or ~3.90 MB. Nothing 4 MB. The client DS will reject anything too big, with the "Communication error" message.(I didn't experience that error because of filesize myself, but I heard about that.)

Great work, I'll give it another run! Even when limited to just one rom at a time, this should still be easier to use then hacked DL Station roms!

I look forward to your next release!

Also, when I compiled, I think I only got a ds.gba file, but it appeared to be a standard NDS file, since a lot of my NDS tools could open it. It started up on the DS, but later froze, probably because what I did to the source code. But now thats no longer a problem since you fixed the bug anyway!

EDIT:

Hmm still seems to get a communication error on the client.

It seems to be detecting it currectly but still doesn't work. The client DS quits right after the server reads "Sent RSA Frame".

Was it supposed to send a RSA frame? Perhaps it detected it as homebrew but sent a RSA anyway? I tried 3 different homebrew roms and all stop after that message goes by on server. (communication error).

So it can't be the file size doing it. Also, I tried a demo that does have a RSA and it seems to fail at detecting it. It now thinks that the demos that do have an RSA don't have one. I get a communication error when using either.
_________________
Sig under construction...Please check back after the sun explodes....

Are you sure the host isn't crashing? Does resetting with X do anything? It doesn't matter if the .nds has a signature or not, the RSA-frame must be sent. It's all part of the WMB/Download Play protocol. I should add that code again which displays whether or not it detected the RSA-signature...

Hmm..well the host doesn't freeze as far as I can tell. The client DS just displays a communication error and refuses to do anything. The server still works to my knowledge since I told the client DS to try again a few times and the server still sends data out to it and such, so I know the server doesn't crash or freeze.

So I guess that whole "Sent RSA Frame" is normal for any rom.

However its not detecting the RSA on roms that have it, since it said it didn't detect it even when I used a rom that had it.

I made sure both DS's were flashed, so its not a security related error.
_________________
Sig under construction...Please check back after the sun explodes....

Well, I guess I don't need to add that code - it already displays that. :-) (Whether it thinks the binary is signed or not.)
So you get this error with everything you try, no matter how many times you restart/power cycle the host?

Correct.

I retried on both ends. I even tried using different flashcart on the server DS. Same error on client everytime.
_________________
Sig under construction...Please check back after the sun explodes....

Apache Thunder wrote:

Perhaps use a CRC check on the Security section? The Rom Header v2.0 tool I use seems to easily tell when a rom has a valid RSA, since the CRC would show as BAD for anything homebrew/modified. I used it on a demo rom and showed a security CRC as "OK" and shows "BAD" when using homebrew or modified retail games.

The header, which contains the checksums, isn't even sent before the RSA-frame, so the client has no clue what the checksums are until the data transfer begins. So that can't cause any RSA-frame errors. But modifying anything in an .nds to be sent in WMB will cause the infamous faded frozen Nintendo logo due to a bad RSA-signature, on NoFlashMe systems.

AFAIK, the client DS in WMB doesn't check the Security CRC in the header. That's only used for booting from Slot-1, I think.

I knew about this error before, but it only happened a few times, it never before did this the whole time...

Try this Apache. With this test .nds, the host will not send the RSA-signature at all. Uh ho... Buffer overflow alert... I have fixed that. This used to happen when the binary isn't signed. It used to write more zeroes into the rsa buffer then the the amount of RAM allocated for it, so it used to overwrite data it shouldn't be.

No, I meant that the server checks the crc to see if a rom has a valid RSA. The client doesn't have to know about that.

Its an idea for a RSA detection improvment on the servers side. The CRC stuff is onl used to see if its homebrew or not!

EDIT: I'll try that out. Looks like you came back to the forums the exact same time I did!
_________________
Sig under construction...Please check back after the sun explodes....

Apache Thunder wrote:

No, I meant that the server checks the crc to see if a rom has a valid RSA. The client doesn't have to know about that.

Its an idea for a RSA detection improvment on the servers side.

Checking the RSA on DS... That will take a while to code...

Yeah, I guess if you wanted to, do it after all the bugs are worked out.

As for now. Even with the test version I'm still getting a communication error on the client DS. Tried resetting the server, same result.

Also I noticed that the power LED doesn't flash like it does for most other wifi apps. Why is that?

This homebrew app looks very promising and I want very badly for this to work.

UPDATE:

Appears that the server isn't loading the rom into memory currectly since I was able to get the client DS to work when the server is using the builtin demo. So it looks to be a problem in the DLDI or libfat area. I'm not a programmer so I can't pin point it, but in my opinion the server sees the test.nds file and trys to load it. Something goes wrong but the server doesn't say anything and thinks it has it loaded (according to what it says on screen anyway, I don't have a true way of debugging this)

Since when the server trys the builtin demo everything works fine. It reports a valid filesize for the arm7/9 on the bottom screen. But when it tries to use the test.nds file, it reports a "0" on both arm7 and arm9 filesize, so it didn't load it me thinks.

It can't be my DLDI driver since tried this both on my N-Card and on my Max Media dock, and the same thing happens on both. Hopefully this additional info will help solve the problem. Maybe not, but I can't really know for sure since I didn't write this.

I have finally got the source code for this to compile (been having problems getting the currect version of devkit)

So I tinkered around a bit with the code. But nothing I can do will fix it. I looked at the code that loads the test.nds and see nothing wrong with it. But I have little knowlege of this code so obvoisly I won't beable to do much. I recognize a few stuff here and there. I used to work the source code of a old Mario DOS game that used Turbo Pascal 5.5 (yeah reallly old lol). So I do have a little bit of coding experience. Just not in this field.

By the way, in your opinion, how hard would it be to port a Turbo Pascal 5.5 DOS game to the DS? The game I used is a Mario clone that is reletively simple. 256colors 320x400 resolution uses PC speaker for sound. Doesn't access any external files and only took up like 60kb of PC ram.

Tthe DS could easily play that game. But porting the source code would be the major challenge! But this is a discussion best left in a different thread.
_________________
Sig under construction...Please check back after the sun explodes....

Apache Thunder wrote:

Also I noticed that the power LED doesn't flash like it does for most other wifi apps. Why is that?

With normal homebrew Wifi apps, dswifi has the option of using the blinking LED used for wireless. But with this, that has to be done manually. Juglak didn't bother to add it, and the blinking LED doesn't really affect wireless at all, so, I didn't add it either.(But do you want that blinking LED feature?)

Apache Thunder wrote:

UPDATE:

Appears that the server isn't loading the rom into memory currectly since I was able to get the client DS to work when the server is using the builtin demo. So it looks to be a problem in the DLDI or libfat area. I'm not a programmer so I can't pin point it, but in my opinion the server sees the test.nds file and trys to load it. Something goes wrong but the server doesn't say anything and thinks it has it loaded (according to what it says on screen anyway, I don't have a true way of debugging this)

Thanks a lot for that. I guess the next thing I'll try is checking if fatInitDefault failed, and if the file opening failed.(Or did you already try that?)

Apache Thunder wrote:

I recognize a few stuff here and there. I used to work the source code of a old Mario DOS game that used Turbo Pascal 5.5 (yeah reallly old lol). So I do have a little bit of coding experience. Just not in this field.

By the way, in your opinion, how hard would it be to port a Turbo Pascal 5.5 DOS game to the DS? The game I used is a Mario clone that is reletively simple. 256colors 320x400 resolution uses PC speaker for sound. Doesn't access any external files and only took up like 60kb of PC ram.

Tthe DS could easily play that game. But porting the source code would be the major challenge! But this is a discussion best left in a different thread.

I have never ported anything. I never really got into DS dev beyond the black and white console, due to a problem that has since been resolved. Obviously the resolution would need adjusted to the DS screens. IMO, porting the code from Pascal to C/C++ would be the hardest part. In particular when you're not really good at C or Pascal, that would make it harder than if you would, I think.(I'm not so good at Pascal, but at C/C++, way better.)
(Sometime I'm going to attempt to port this PC game I made to DS. Those troubles with music need resolved first though... It will be even harder since it was originally made with Game Maker, which is written by Mark Overmars.)(I don't even use GM anymore, but porting it would be a good learning exercise, I guess.)

The WMB Host mod test .nds binary has been updated.
I have found a bug in the code which checks whether the test.nds code exists or not. The file used to be not closed properly when the file exists. Also, if FAT initialization fails, it will report this, and it will use the built-in demo.

Tested new binary...Same results.

Perhaps this will help. I have taken photos of the server screen when it was working and sending the builtin demo, and a photo of it just sitting there when trying test.nds. It appears that doesn't even attempt to send the test.nds to the client. Click the links to view them. Looks like this forum doesn't allow IMG tags.

Works when sending builtin demo:
http://img141.imageshack.us/img141/8333/workingdt1.jpg

Fails when test.nds is used. Notice the zero file size report for the arm7/arm9:
http://img141.imageshack.us/img141/491/brokenza7.jpg

Perhaps that will help a bit. By the way, do you have any way of testing this with two DS's or do you rely on a external person? Since it looks like I've become your tester for now :)

Also on the screen that shows it sending "DS packed Data" when sending the builtin demo, it appears to be missing the letter P. Right now it reads "DS ACKED DATA" It probably should read "DS PACKED DATA".

And for the "Initializing data" text that it shows. It loooks like it needs an additional text line since binary has the letter y wrapped to the bottom. Doesn't look pretty. See if you can reduce it by one letter or if you can add an additional text line so that the word binary appears below instead of being cut off on the fist line.

Adding the LED blinking feature would be nice. Don't bother right now if it would take a lot of code work to do it though since its certainly not on my priority list.

I've also noticed that with homebrew, the LED doesn't blink the same way that it does when retail games use WiFi. Is it because all homebrew writers decided to make it blink that way, or is it the DS's way of showing that homebrew has access to less Wifi speed then retail games?
_________________
Sig under construction...Please check back after the sun explodes....

DATA ACKED DATA is normal, it's supposed to display that. That basically means that the client received the data packet with sequence number shown.

Well, my flash card broke a good while ago... So the only way for me to get my stuff tested if other people test it. I should have a new card either this month, or next month. Even if I had an card to test with, you'd probably still need to test, since this error never showed up before with other cards.

The LED and wireless have nothing to do with each other. Code can change how the LED blinks, but LED and wireless, they can't do anything to the other. It's just that official games make the LED blink when doing wireless, that's all.

Oh well I thought the message was a typo. lol

Ahh so the Retail games just tell the LED to flash a certain way, and that most homebrew decides to flash a pattern different then what Retail games do?
_________________
Sig under construction...Please check back after the sun explodes....

With Wifi apps made with dswifi, there's the option of having the LED blink for wireless, or no blink at all. Does the LED blinking happen to look anything like the Sleep mode blink? That might be a bug in dswifi, I don't know.

Yeah, wireless homebrew stuff looks like sleep mode.

Correct. The rate of blinking is much slower when using homebrew.

When using retail games, the LED blinks twice rapidly, then pauses slightly, then repeats.

Homebrew is just a slow blink similer to that of the sleep mode blinking.
_________________
Sig under construction...Please check back after the sun explodes....

What flash card are you using Apache?

There is two that I currently use.

1. Max Media Dock - Where most of my homebrew is. This is what I used to do most of the testing for your WMP app. (this is a slot-2 device)

2. N-Card - This is what I use for my games, I did not run the WMB app on this, though I did try once to make sure, it got same error.(this is a slot-1 device) I rarely use this for homebrew. I do have Moonshell on it and a few emulators, but they are setup to access slot-2 device for their files.
_________________
Sig under construction...Please check back after the sun explodes....

The test .nds has been updated.
Some changes were made in the code which reads the .nds, which might fix this bug, I don't know. Also, the program now displays the filesize of the .nds. Tell me if the value displayed differs from the real filesize.(The filesize visible when you check the file's properties)
Also, dump.bin is now created on your card when you use this, and it finds test.nds. Send me the dump, and tell me what .nds you used.

Hmm still doesn't work. It seems to report a file size of 2bytes which is wrong since the test file is 500 something KiloBytes.

The dump file produced is 2 bytes in size. It still reports the Arm7/9 as 0.

Here is the dump file it produced:

http://0ki.info/uploads/b0ba4a6226.rar

It also contains the test.nds file I used. It was TunaVIDs v1.1 (the player, not the directory viewer part)
_________________
Sig under construction...Please check back after the sun explodes....

WMB Host Mod RSA 1.7b has been released. The RSA code is back. The host will attempt to find the RSA signature, and send it if it finds it. The filesize display is gone, and dump.bin is gone.(It's creation anyway)
I found the bug. I was using fseek, in the code which gets the filesize, wrong.

Last edited by yellowstar on Wed Jul 16, 2008 4:30 pm; edited 1 time in total

Umm...URL is dead link.
_________________
Sig under construction...Please check back after the sun explodes....

My bad, link fixed.

HOLY CRAP IT WORKS NOW!!!

Great work!

It reported the correct file size for arm7/9 and displayed the sending acked message (as in, it was actually sending the test.nds rom this time) to the client. The client rom worked exactly as I expected it to once sent to the client DS. It even displayed the icon for the test rom when selecting it on the client's DL Play menu.
_________________
Sig under construction...Please check back after the sun explodes....

Great! But does it still screw up on the RSA signature sometimes still?(Detecting a signature when there isn't a signature, and not detecting the signature when there is a signature.)
If it still does, could you tell me all of the names of the homebrew/demos that aren't working correctly?

No problemo. So far I've tested Tunavids and jEnesisDS.

With the homebrew I used so far, it has detected that it has no RSA correctly. I will now go and check a a RSA'd demo and see if that works.

UPDATE:

RSA seems to work currectly. I used a RSA signed rom (the menu loader sent to client DSs when using the official DS download stations) and it detected the RSA on it currectly. The client DS loaded it currectly and it seems that the nintendo logo on the top screen appeared currectly. Which means this could work on a unflashed DS.

All the homebrew I used had a corrupted Nintendo logo on the top screen before boot, which indicated that homebrew wouldn't work on unflashed DS's. But that is normal.

Since I don't have any unflashed DS's I can't tell you for 100% certainty that this will work on unflashed DS's, but I'm pretty confident that it will.

Looks like all the major bugs have been worked out.
_________________
Sig under construction...Please check back after the sun explodes....

Last edited by Apache Thunder on Wed Jul 16, 2008 8:34 pm; edited 2 times in total

Apache Thunder wrote:

All the homebrew I used had a corrupted Nintendo logo on the top screen before boot, which indicated that homebrew wouldn't work on unflashed DS's. But that is normal.

No, the strange logo doesn't mean that. The only reason why homebrew fails to boot on an unflashed DS, is because of an invalid RSA signature. Us homebrewers can't get the private key, which only Nintendo has. The strange logo appears because most homebrew doesn't really have a WMB logo. This can be added with ndstool, I think. It wouldn't change anything on a unflashed DS regarding booting if you would add a logo, it still wouldn't boot.

Ahh well I didn't expect a rom having a logo to work on unflashed DS's. I just noticed that all the RSA roms had a working logo.

On a different subject:

I see no reason why you can't just hard code it to send the RSA even if its homebrew. Whenever I used a DL station rom to send my homebrew, it would work just as well as this (though they had strictor file size limits), I assumed the official DL station always sent the RSA even if you were using homebrew inplace of the original rom..

The RSA stuff wasn't what broke it for me when I first tried this. Your last bug fix (the filesize bug) seemed to have been the one that fixed the whole thing. But having RSA on all the time shouldn't hurt. Plus you can save some space on the screen since you don't have to report the RSA status onscreen anymore.

But this is just my theory. If there is a specific reason why it isn't a good idea to keep RSA on, then I guess this wouldn't work. But thats my idea for it anyway.

I just tested a Genesis emulator and confirmed that the filesize limit for roms for this version of your WMP app seems to be around 2.3MB. I tried one at 2.6MB, and got a communication error on client DS. The server reported that it failed to find a portion of the file or something (I forgot the exact error message)

So 2.3MB seems to be the safe limit on all roms. This is still better then the official DL stations. They top out at 1.7MB or smaller.
_________________
Sig under construction...Please check back after the sun explodes....

When homebrew is sent/RSA isn't detected, instead of having a real signature, all of the bytes in the signature is set to zeroes. For homebrew, minus the one byte glitch seemingly in devkitARM, normally the romSize is the same as the filesize. If I were to attempt to read and use the RSA from the .nds all the time, the host would most likely crash, since the host would usually attempt to access memory that it shouldn't accessing.(AKA Access Violation on Windows)
In this case, it could only screw it's own memory, and that could cause random glitches.

Oh well. I guess RSA detection is required then. But right now RSA detection seems to be working well. It was just an idea from a person with no coding experience, so I was expecting something along the lines of that.

Does the official DL Stations have RSA detection when they send out the demo rom? (the rom for the menu loader) Since I did use homebrew for the retail DL stations and most of them worked fine. But since there's no message screens for them, I can't tell if the DL station sent the RSA or not, so I assumed that it always did. But then again, I doubt the retail DL stations were built with devkitarm, so that all just could be irrelevant to this case.
_________________
Sig under construction...Please check back after the sun explodes....

Apache Thunder wrote:

Does the official DL Stations have RSA detection when they send out the demo rom? (the rom for the menu loader)

I don't know. But they probably do. As you said, homebrew works. If the Download Stations wouldn't have RSA detection, when you'd try to send homebrew, the host should crash, since homebrew doesn't have a RSA-signature. But since the hosts don't crash, it must have rsa detection.

I'm curious as to why they would have RSA detection. The retail DS download stations are designed to work with standard DS's, so ALL roms put into it by the official coders will have RSA. So why would they code in detection for it?

Unless secretly the people who coded it knew that someone would later hack in homebrew roms?
_________________
Sig under construction...Please check back after the sun explodes....

They probably knew that it wouldn't matter if the host would have RSA detection code or not, that could be hacked in by us homebrewers without much trouble.(With people knowledgeable with Reverse Engineering, hacking, and ect, at least.)
So they added the RSA detection code, since it wouldn't matter if they didn't add the detection code.

Hmm...Makes sense.

So now that you got the major bugs worked out, what do you plan to add in the next version? What do you envision the final version to look like?

Also I noticed that "Tuna-viDS" has a seperate rom that seems to send info to the player rom on what file to load (the player defaults to "tuna-vids.avi" if you don't use the loader rom). Perhaps you can make a few simple changes to that app and to the main WMP app so that they can work together?

Use the loader app to browse for the rom you want to host, and then it will tell WMP rom what to load. Not sure if this would be any easier then just adding directory browsing to the main app though, so if its more trouble then that, then...don't bother lol.

In the next major release, that is really the only feature I want. The file browser. Aside from that, I'm happy to accept any new features you will add.

Also perhaps you can make use of the top screen. Have the "name of author" and other non changing details up there (perhaps even a user customizable image instead?) and have the status messages displayed on bottom screen. I guess a way bit into the far future your app may eventually have a graphical user interface. But that's a lot of coding and it would be quite a bit from now before you can get that added.

I'm just running through any ideas I might have right now.
_________________
Sig under construction...Please check back after the sun explodes....

I've never used Tuna-viDS, and since my flash card is still broken and I still don't have a new one, I couldn't try the binary included with that dump download you sent me.

It's very unlikely I'd add a file browser until I get a new flash card. However, there's plans for wireless-related features:
Multi-cast. Meaning more than one DS could download at the same time. I got as far as getting it so you'd have to press a button to start the transfer after the client DSes connect. But, still only one DS can download. It needs more work.

And a some-what hidden feature of WMB, is that it is possible to transfer multiple demos at the same time. This was done in the past in Japan, that is until Download Stations with the client needing downloaded over WMB, came along. I'm planning on adding this feature of WMB into this host. However, that cannot happen until multi-cast is done, and also another thing: The code I figured out for getting the gameID from the client(s), it doesn't work all the time. This feature can't be implemented until a flawless method is found.(This feature of WMB was discovered by Filb, or you could say somebody did discover this, but never said anything about it. So in that case, it would have been re-discovered. For more information on this, dig through the WMB assembler topic in the DS Misc section.)

Alright then. Any new version you release, I will happily test for you!
_________________
Sig under construction...Please check back after the sun explodes....

Thanks, that's great. (It seems to be much easier to get people to test this mod, unlike Wmb Asm DS, or DSPacketCapture... The former needs testing, but unforuntely I forgot to enable the debug log, so unless it actually finishes reading a capture, well, it would be impossible to find out what's the problem this time. Since nobody replied to those Wmb Asm SDK DS compiling errors, there's not much I can do with Wmb Asm DS until those are fixed.)

Compiling errors can be a real bitch sometimes >)

I had my fare share of problems when I was working on that Mario clone dos game.
_________________
Sig under construction...Please check back after the sun explodes....

I still get some RSA getting not sent properly as even all official demos wont boot on my unflashed DSL, and if it could be on the top screen by way of lcdswap() it would be cool

cboomf_, with what officials demos did this happen?

table tennis, submarine, volume 8 loader, volume 1 loader, all volume X loaders

Try sending those binaries again, except this time try using this. If any of them still don't work, tell me what values it displays for RSA pos and Filesize. Are you using binaries from here? Demos/binaries from the DS Organize Homebrew Database were tested before with this mod, and booting failed on NoFlashMe DSes. This may be just be a problem with the DSO HBDB Polarium demo, however, this is unknown if this is a problem with all demos on that server. However, the same demo from another web site worked correctly. Have you tried any other demos? I analyzed the table tennis/hockey from akkit.org, and it appears that demo on akkit.org is missing the last byte of the RSA signature. This may be the same problem the DSO HBDB demo(s) have. There is no way any demo can boot without a complete signature, and with the official WMB client.

EDIT:
It seems there isn't any bytes missing - I verified this binary with ndsrsa, and it passed the signature check. So a bad signature most likely isn't the cause of this bug.

This _debug version sends it on channel 6, but i thought wmb was on 1,7, and 13, also this version doesn'y detect any of the RSA even on the official ninty demos, and yes i am using the ones from akkit, the server clients are ripped out of the servers

cboomf_ wrote:

This _debug version sends it on channel 6, but i thought wmb was on 1,7, and 13

That's correct, WMB uses channels 1, 7, and 13. This channel 6 bug happened before, but I thought I fixed it... Once you test the updated debug version I'm going to post, you'll need to send me the .nds you're trying to send, the dump.bin that will be written to the root of your card, and log.txt.

yellowstar wrote:

Apache Thunder wrote:

All the homebrew I used had a corrupted Nintendo logo on the top screen before boot, which indicated that homebrew wouldn't work on unflashed DS's. But that is normal.

No, the strange logo doesn't mean that. The only reason why homebrew fails to boot on an unflashed DS, is because of an invalid RSA signature. Us homebrewers can't get the private key, which only Nintendo has. The strange logo appears because most homebrew doesn't really have a WMB logo. This can be added with ndstool, I think. It wouldn't change anything on a unflashed DS regarding booting if you would add a logo, it still wouldn't boot.

perhaps a n00b question here, but how would I add this with NDStool, I haven't used it so maybe it's obvious if I were to run it, but I'm on a MAC right now...

cboomf_, Wmb_Host_mod_debug.nds has been updated.

@Mohammad:

ndstool help wrote:

Logo bitmap/binary -o file.bmp/file.bin

For the first parameter, put the .nds filename there, then for the following parameters, add -o logo.bmp. So you'd do something like: ndstool homebrew.nds -o -logo.bmp. The .bmp needs to be monochrome, as the logo is 1-bit. The dimensions need to be 104 x 16. Goto this web page for example logos.

that debug version does exactly the same as the older one, ch 6 and doesn't detect the RSA on anything :-(

EDIT : The ch 6 thing was the .dat file getting stuck, so that was my fault ;-(, but it doesn't detect rsa

*sigh* that didn't work, I downloading one and used that, it displays a palib version of that then freezes... what am I doing wrong! (Man 'tis will be neat to do homebrew with my friends) Also what about games that need DLDI? I take it they don't work, and also isn't that just for browsing the card?

@cboomf_:
I need those files...

Quote:

you'll need to send me the .nds you're trying to send, the dump.bin that will be written to the root of your card, and log.txt.

@Mohammad:
You're sending the homebrew over WMB, with the clients DSes using FlashMe, correct? The logo won't change anything for homebrew booting on unflashed DSes. If you are using FlashMe, does it work when you don't change the logo? This WMB Host RSA mod will not make homebrew boot on unflashed DSes with WMB, only official demos/signed binaries.(Well, it's supposed to send the rsa signature so they boot...)

no I'm using two unflashed DSes, okay so it's not done yet huh? I'll try out the offical binaries later if I can

Mohammad, homebrew failing to boot over WMB has nothing to do with the host. WMB uses RSA. Only binaries signed with Nintendo's private key can boot on a NoFlashMe DS. Since us homebrewers can't get the key, or have the binaries signed, booting will always fail on a unflashed DS, unless you use FlashMe. This host can send homebrew, but it will not work unless the client is flashed.(It's impossible to brute force the key, at least in a feasible about of time. It would take many years, perhaps 100 years.)

wow... they have a secure key! Shame it hasn't leaked out nor have we extracted it... hopefully someone will come up with something soon...

The key is stored on Nintendo's computer(s) used for signing. It is impossible to extract it from any nds software. A leak will never happen, the key is under high security. Third-parties/official developers do not know the key, they just ask Nintendo to sign there binaries. The key is not stored in the binaries. There is public keys. This is most of the signature. This is decrypted with RSA public key decryption, and is compared with a combined SHA-1 hash of the header, arm9 binary, and arm7 binary. If the decrypted hash and the calculated hash match, the RSA verification passes, and the binary will boot. But if they don't match, and the firmware isn't flashed, the verification will fail, and the binary will not boot. Just changing one bit in the .nds, like in the Arm9 binary, drastically changes the calculated hash, and in the process, invalidates the signature, causing the binary to fail to boot.

Quote:

hopefully someone will come up with something soon...

If you want to send homebrew to friends' DSes, why not just boot it from your flash card? Unless there DSes are flashed, that's the only way to boot homebrew.

http://www.megaupload.com/?d=KNFN9WJJ

log.txt
test.nds
dump.bin

oh so is RSA like those little keychains that have the "password" that changes like every minute or so? And exactly why would Nintendo do that? I mean what's so bad about us using download play that they would actually think about it?

Cos the easier it is for us to get code on there, the easier it is for us to rip their games. Another is that by downloading a signed program it's a guarantee that what you're playing is a quality piece of software that has passed many tests and is assured by Nintendo that it's not gonna brick your DS/blow it up in your face.
However, we've gotten code on there now so I guess this is one less reason to have signed programs.
_________________
Big thanks to everyone who donated for Quake2

simonjhall wrote:

Another is that by downloading a signed program it's a guarantee that what you're playing is a quality piece of software that has passed many tests and is assured by Nintendo that it's not gonna brick your DS/blow it up in your face.

Let's not forget the fat wad of moneys Nintendo make on this process.

yellowstar wrote:

If you want to send homebrew to friends' DSes, why not just boot it from your flash card?

So that means I should boot players 4, 3, 2, and finally 1 by removing the flash card while the DS is turned on, right? And what should I do if I want to boot a DS whose SLOT-1 is not accessible, such as a demo unit in an electronics store?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

cboomf_, WMB_Host_mod_debug.nds has been updated. Your binaries, well at least table tennis, should work correctly. If any binaries still do not work, send me those files written to your card, again.

That link's broke ;-)

Just a guess, but the correct link may be this.

You guessed the correct link, Filb. I manually wrote the URL, without copying the filename, and I forgot the rsa part... :\

it detects everything but the table tennis demo still wont boot on an unflashed DSL

http://www.megaupload.com/?d=M3RISFBV

log.txt
dump.bin
test.nds

Have you tried a demo other than Table Hockey? I remember having problems sending it to an unflashed DS, too. Not sure what's wrong with it.

Again the table hockey still doens't work and neither does the submarine demo, download volume 8 client or volume 1 client, still testing polarium demo ....

EDIT:

polarium works, the others still dont

EDIT EDIT:

can't get the files for the ones that dont work as i have no way of reading my card atm

WMB Host Mod RSA debug version has been updated.

cboomf_ wrote:

neither does the submarine demo, download volume 8 client or volume 1 client

Hmm... Some values in some binaries have certain values set to zero. This may include the romsize field for these clients... Some binaries also set the bannerOffset field to zero, which will make the binary, to this host, appear to not have a banner. Does the banner appear with these clients? If the host still does not work with these clients, I guess the next thing I'll try is calculating the romsize, if it is zero, but this calculated value will only be used for checking if a rsa signature is present. This would most likely not happen, failing to find the signature with DLStation clients, if you were using a binary assembled from WMB packets, but since you're using the client directly from the station's rom, this can happen.

this is from the new ver sending the sub demo

http://www.megaupload.com/?d=ZB69XI6H

log.txt
dump.bin
test.nds

So the host is not detecting the RSA signature? "This binary not RSA-signed; It's homebrew."? Or "This binary is RSA-signed."? The romsize and the calculated value romsize needs to be, for the binary to have a signature, are exactly the same... :\

all of the demos come up as rsa detected but dont boot
"The binary is RSA signed"

wmb_host_mod_rsa_debug.nds has been updated. I'll need the rsa.bin that will be dumped to the root of your card.(If you try the Submarine binary, you can just send the rsa.bin, instead of the other files, since you already sent me the other debug files.)

here it is

http://cbnds.ulmb.com/sub_rsa.zip

RSA.bin

Updated. This should fix your problems with this host. The last byte of the SHA-1 hash/last byte of the whole signature, was missing. This was caused by a wrong offset. The romsize field is zero-based. I was using the filesize - 136, the size of the signature. The result of this operation resulted in a value that was one byte larger than the romSize, resulting in the missing byte.

Still wont boot on unflashed ds (submarine), outputs are below:

http://cbnds.ulmb.com/sub_outall.zip

test.nds
RSA.bin
out.bin
LOG.txt

PS/NOTE/REQUEST : is there any possibility of adding a test.nds file chooser so multiple demos can be chosen from

cboomf_ wrote:

Still wont boot on unflashed ds (submarine), outputs are below:

http://cbnds.ulmb.com/sub_outall.zip

test.nds
RSA.bin
out.bin
LOG.txt

I'm on vacation right now, and the version I transferred unto this vacation computer, apparently it's an old version. Zero debugging code. So those files you uploaded, those are the exact same file you uploaded before. So I'm not sure if this version is the same as the latest one on my main development computer, minus debugging, or if this version has those bugs I fixed before. Sorry, we can't try much for about 2-3 days.

cboomf_ wrote:

PS/NOTE/REQUEST : is there any possibility of adding a test.nds file chooser so multiple demos can be chosen from

I'm not planning on added this, or any new features, to WMB Host RSA mod. I'm working on my own liblobby-based WMB Host and Client, integrated with Wmb Asm. As a PoC for liblobby WMB,(The liblobby I'm using is a modified version for WMB)
I ported/modified WMB Host RSA mod to use this modified version of liblobby. But there's bugs, and this isn't even the point where any packets are sent/received. Red guru meditation crash screens. No crash happens when usage of liblobby is disabled. The Wmb Asm WMB Host/Client has a bunch of features planned, but development of the Host/Client will not most likely not begin until the PoC is working correctly. The crash is most likely due to Juglak's memory code...

have a gd trip

Updated. If the binaries still don't work, send me all of those files again.

Sub demo still doesn't work but polarium does

sub :

http://cbnds.ulmb.com/sub_outall2.zip

polarium :

http://cbnds.ulmb.com/pol_outall.zip

Updated. If anything still doesn't work, just send me log.txt and rsa.bin.

Here :

http://cbnds.ulmb.com/sub_outlogrsa.zip

log.txt
rsa.bin

NOTE : Are we sure that the sub demo actually has been rsa signed ?/is the signature broken ?

Yeah, I would try non-E3 demos... those were the very first captures ever.

cboomf_ wrote:

NOTE : Are we sure that the sub demo actually has been rsa signed ?/is the signature broken ?

It is signed, and the signature is not broken. I checked the signature with ndsrsa, and the sub demo passed the signature verification. The signature dump is perfect... It's exactly the same as the one from the .nds... :\

Updated. capture.cap will be written to the root of your card. Send it to me. However, when shutting down the host, press Select first, then power off the host.

http://cbnds.ulmb.com/sub_outcap.zip

capture.cap
capture_log.txt

NOTE : This new host never gets past the "Recieved Association Request" message

@Flib : Makes sense because the Polatrium demo works ...

Updated.

That just freezes at "Testing wifi ..."

cboomf_ wrote:

That just freezes at "Testing wifi ..."

4me2~

@cboomf_:
Apparently the host was writing those packets it sends when testing wifi, to capture.cap... That's not really needed, and it should be disabled... It's difficult to fix these capture writing freezes without capture_log.txt. I guess it would be best to just dump the header the host sends, and the data it sends to a .bin, instead of using a capture... This way I could re-construct the sub demo .nds, compare with the original .nds, so the problem could be found, and verify the RSA signature.

@leinad:
Are you having problems with the original build of WMB Host RSA Mod? This
debug build, wmb_host_rsa_mod_debug.nds, is primarily intended for those having problems with the host.

WMB Host RSA Mod debug build updated.
cboomf_, I'll need header.bin, arm9.bin, and arm7.bin. And try running with and without dumping the packets, by pressing A or B when it asks. When you run it in packet dump mode, send me capture.cap and capture_log.txt.

I have 2 DS'es
Ill call them blue & white , booth phat

Just as an info , they are unflashed, and until now I just tried with the unsigned-one in the package - so it wont start so or so, but its weird:

Blue Host, White client: White finds the server and is downloading , hangs up on the screwed logo ^^" [logicaly since its not RSA signed]

White Host, Blue client: On white the output is the same like on blue, but Blue cant find the server ...

---
This reminds me of some older WiFi-Hardware problem, in earlier WiFi-lib builds my White-DS never was able to execute wifi-code. Among that the blue DS did~

leinad wrote:

White Host, Blue client: On white the output is the same like on blue, but Blue cant find the server ...

The channel the white DS host was using was either channel 1, 7, or 11/13, right? Try deleting wmb_host_mod_chan.dat in the root of your card, before running the host on the white DS.

It always hosts on channel 7... on blue too
deleted the file 5times, always starts into channel 7

ive set the value in the file into 8, now it says "Using channel 8", but still no effect....
Hm might be just the fact the DSes are unflashed...

How to get RSA signed demos =/ ? [ore even "where", not sure if its legal to download/distribute them]

leinad wrote:

ive set the value in the file into 8, now it says "Using channel 8", but still no effect....
Hm might be just the fact the DSes are unflashed...

How to get RSA signed demos =/ ? [ore even "where", not sure if its legal to download/distribute them]

It doesn't matter if they're unflashed, the client DS should still detect the beacons. Does liblobby software work okay with your DSes? Would you happen to have a way of capturing wireless packets? Download demos from here.(For more demos, check the 22nd page of that topic) There's nothing illegal about downloading demos off of Internet - Nintendo wanted the demos to be freely distributed, so there's no problem here. But it's a completely different matter with roms.

gets stuck after client accpets the download or the client never sees the beacons

http://cbnds.ulmb.com/sub_outcap2.zip

capture.cap
capture_log.txt

with out the packet dumping, the client ds finds the beacons and will download, but fails to boot

cboomf_ wrote:

gets stuck after client accpets the download or the client never sees the beacons

http://cbnds.ulmb.com/sub_outcap2.zip

capture.cap
capture_log.txt

yellowstar wrote:

WMB Host RSA Mod debug build updated.
cboomf_, I'll need header.bin, arm9.bin, and arm7.bin.

I need header.bin, arm9.bin, and arm7.bin from the root of your card. With these files I can fix this bug, instead of using the incomplete capture apparently caused by slow wireless transfer rates, but without it, it's very difficult.

header.bin doesn't get created :-) but the others do :-

http://cbnds.ulmb.com/sub_outbin.zip

they don't seem big enough though .....
remember it always fails to send .....

These two Arm7/9 binary dumps are the correct size. However, the contents of the dumps are invalid... The start the actual code/data in the Arm9 dump doesn't start until offset 983040, while it should be 2094... The data at the end of the dump is wrong too... And the Arm7 dump only contains zeroes...

WMB Host RSA Mod Debug build updated.

http://cbnds.ulmb.com/sub_outall3.zip

header.bin
arm7.bin
arm9.bin
capture.cap
capture_log.txt

Still fails to send but this time header.bin is created ...

EDIT : (pleading) could this be switched to the top screen as my bottom screen is now broken, has a massive crack and pretty rainbow effect ....

EDIT 2 : Question ..... why does it just freeze at random points at the DS ACKED DATA part, not always at the same point ?

EDIT 3 : Having hex dumped the arm9 and 7 bins, they are just blank, but the header.bin is actually there ....

EDIT 4 : The polarium demo used to work but now it doesn't :-(

http://cbnds.ulmb.com/pol_outall2.zip

header.bin
arm7.bin
arm9.bin
capture.cap
capture_log.txt
rsa.bin
test.nds

cboomf_ wrote:

EDIT : (pleading) could this be switched to the top screen as my bottom screen is now broken, has a massive crack and pretty rainbow effect ....

Okay, next release of the debug version will use the top screen, and one button will be used to switch screens.(That button will most likely be R)

cboomf_ wrote:

EDIT 2 : Question ..... why does it just freeze at random points at the DS ACKED DATA part, not always at the same point ?

Not sure atm... That can happen if the SHA-1 hash, the last 8 bytes of the signature, are all zeroes,(with a rsa signature that doesn't have all zeroes)
but that's not the case with this...

cboomf_ wrote:

EDIT 4 : The polarium demo used to work but now it doesn't :-(

http://cbnds.ulmb.com/pol_outall2.zip

header.bin
arm7.bin
arm9.bin
capture.cap
capture_log.txt
rsa.bin
test.nds

There's data at the end of the Arm9.bin, around the size of one data packet. The rest of the binary dumps are all zeroes...

Debug build updated. By default the screen used is now the main screen, but it can be swapped between the main and sub screens with the R button now.

http://cbnds.ulmb.com/pol_outall3_uncap.zip - Polarium demo, no capturing - froze at DS ACKED DATA 13F
http://cbnds.ulmb.com/sub_outall4.zip - Sub demo, no capturing - froze at DS ACKED DATA 360 and arm9.bin got corrupted and wouldn't copy from M3

Discoevery (may be minor) - The ds acked data runs quickly at blank space (i.e all 0's) but when the data because more dense (i.e less blank bytes) it really slows up to one ds acked data increase per 2 minutes

Debug build updated. After asking about dumping packets, it will now ask another question. It will ask whether to send a 352 byte long header, or a 250 byte header. A will set it to send a 352 byte header, and B will set it to send a 250 byte header. Try both header length settings for the sub binary. Also, try the DS Download Station client binaries with both of these settings, if they didn't work before.

So far tested on capturing with 250 and 325 and no capturing with 250 and 325, tested 4 - 5 times on each and always failes at "Sent RSA Frame" :-?

With no cap and 325 it seems to fail alot at "DS ACKED RSA"

Could it be in the timings, cos somewhere i read that the ds has to respond in a certain time or the other ds quits...

No cap, 250 - http://cbnds.ulmb.com/sub_outalluncap250.zip
No cap, 325 - http://cbnds.ulmb.com/sub_outalluncap325.zip
Cap, 250 - http://cbnds.ulmb.com/sub_outallcap250.zip
Cap, 325 - http://cbnds.ulmb.com/sub_outallcap325.zip

Tried the download station binaries, they just crash the server :-(

Is this still going or has it run in to a large and immovable wall ?

Well, my Acekard 2 arrived last week, and I've been trying to debug this, but it's difficult... With my Acekard 2 and the submarine demo, it usually stops at "Sent RSA Frame", but when it does pass the RSA stage successfully, it randomly stops during the data transfer...

Yeh this is what happens to me ...

gbadev.org forum archive

DS development > Wireless Multiboot Host (WMB) for the DS (no PC)

#112195 - Juglak - Thu Dec 14, 2006 7:32 am

#112209 - felix123 - Thu Dec 14, 2006 10:56 am

#112213 - Mighty Max - Thu Dec 14, 2006 11:56 am

#112215 - masscat - Thu Dec 14, 2006 12:40 pm

#112227 - tepples - Thu Dec 14, 2006 4:05 pm

#112255 - masscat - Thu Dec 14, 2006 10:42 pm

#112257 - Juglak - Thu Dec 14, 2006 10:44 pm

#112267 - NeX - Thu Dec 14, 2006 11:00 pm

#112268 - Juglak - Thu Dec 14, 2006 11:03 pm

#112517 - bsder - Sun Dec 17, 2006 10:11 am

#112571 - Juglak - Sun Dec 17, 2006 11:31 pm

#112652 - Juglak - Tue Dec 19, 2006 6:01 am

#112661 - HyperHacker - Tue Dec 19, 2006 8:32 am

#112887 - Juglak - Thu Dec 21, 2006 5:23 am

#112890 - HyperHacker - Thu Dec 21, 2006 6:32 am

#112956 - Juglak - Thu Dec 21, 2006 11:43 pm

#113210 - Goosey - Sun Dec 24, 2006 12:54 pm

#113440 - Dan2552 - Wed Dec 27, 2006 8:40 pm

#113953 - Mighty Max - Mon Jan 01, 2007 8:57 pm

#113954 - tepples - Mon Jan 01, 2007 9:35 pm

#113955 - Mighty Max - Mon Jan 01, 2007 9:40 pm

#113960 - simonjhall - Mon Jan 01, 2007 10:55 pm

#113961 - Mighty Max - Mon Jan 01, 2007 11:02 pm

#114008 - Mighty Max - Tue Jan 02, 2007 6:49 pm

#115053 - Juglak - Fri Jan 12, 2007 3:30 pm

#116300 - Juglak - Wed Jan 24, 2007 7:18 am

#116301 - Juglak - Wed Jan 24, 2007 7:53 am

#116302 - Sektor - Wed Jan 24, 2007 8:08 am

#116340 - dantheman - Wed Jan 24, 2007 5:01 pm

#116408 - Sektor - Thu Jan 25, 2007 10:12 am

#116419 - Juglak - Thu Jan 25, 2007 3:06 pm

#116430 - Agilo - Thu Jan 25, 2007 6:25 pm

#116518 - Juglak - Fri Jan 26, 2007 3:28 pm

#116539 - dantheman - Fri Jan 26, 2007 5:04 pm

#116564 - Mighty Max - Fri Jan 26, 2007 10:06 pm

#116678 - felix123 - Sun Jan 28, 2007 6:21 am

#116728 - Juglak - Sun Jan 28, 2007 9:54 pm

#116785 - Mighty Max - Mon Jan 29, 2007 5:32 pm

#116869 - Juglak - Tue Jan 30, 2007 3:29 pm

#116878 - tepples - Tue Jan 30, 2007 5:03 pm

#116884 - Mighty Max - Tue Jan 30, 2007 5:52 pm

#116887 - tepples - Tue Jan 30, 2007 6:00 pm

#116890 - melw - Tue Jan 30, 2007 6:53 pm

#116894 - Gunnex - Tue Jan 30, 2007 7:05 pm

#116929 - tepples - Wed Jan 31, 2007 2:13 am

#116940 - HyperHacker - Wed Jan 31, 2007 4:49 am

#117024 - Agilo - Wed Jan 31, 2007 8:49 pm

#117722 - sonny_jim - Tue Feb 06, 2007 11:11 pm

#119340 - Noda - Thu Feb 22, 2007 12:49 am

#120465 - pas - Sat Mar 03, 2007 11:36 pm

#120489 - max482wert - Sun Mar 04, 2007 3:53 am

#130115 - avid - Thu May 31, 2007 1:22 am

#130136 - thegamefreak0134 - Thu May 31, 2007 6:35 am

#134879 - yellowstar - Tue Jul 17, 2007 10:31 pm

#135487 - yellowstar - Mon Jul 23, 2007 10:19 pm

#135494 - Dood77 - Mon Jul 23, 2007 11:11 pm

#151399 - iprice - Mon Feb 25, 2008 9:12 am

#151401 - Sektor - Mon Feb 25, 2008 9:50 am

#151402 - iprice - Mon Feb 25, 2008 10:35 am

#151794 - iprice - Tue Mar 04, 2008 11:50 pm

#151806 - yellowstar - Wed Mar 05, 2008 2:35 am

#151830 - iprice - Wed Mar 05, 2008 6:25 pm

#151862 - yellowstar - Thu Mar 06, 2008 1:47 am

#151909 - iprice - Thu Mar 06, 2008 3:51 pm

#151948 - yellowstar - Thu Mar 06, 2008 11:49 pm

#152001 - Filb - Sat Mar 08, 2008 12:17 am

#152008 - yellowstar - Sat Mar 08, 2008 4:43 am

#153366 - wolped - Sat Mar 29, 2008 6:36 am

#153407 - yellowstar - Sat Mar 29, 2008 8:33 pm

#153413 - yellowstar - Sat Mar 29, 2008 10:03 pm

#154138 - yellowstar - Fri Apr 11, 2008 9:36 pm

#155016 - yellowstar - Wed Apr 23, 2008 10:49 pm

#155189 - yellowstar - Sat Apr 26, 2008 4:52 am

#155372 - yellowstar - Mon Apr 28, 2008 9:54 pm

#155398 - dantheman - Tue Apr 29, 2008 3:34 am

#155399 - wintermute - Tue Apr 29, 2008 3:41 am

#155400 - dantheman - Tue Apr 29, 2008 3:46 am

#155402 - yellowstar - Tue Apr 29, 2008 4:01 am