gbadev.org forum archive

Hi there,
I searched a bit for direct DS to DS communication (without any AP or any other wifi device) and looks like nobody did.
So I tried to do some, I succeeded to send some home made wifi packets from the DS to my computer in Monitor mode, but I didn't success in sending packets from my computer...
So I need someone owning two DSes (or someone who knows someone else having a DS too) to test my library:
Here's a sample binary: http://phhusson.free.fr/ChatNifi.nds and source code available at http://phhusson.free.fr/ChatNifi.tar

To test it simply start the two DS (you can do that with only one linker, starting the app then putting the linker in the other DS), and launch the app.
Now press A or B and see what happens on other DS

More technicaly speaking:
Channel is hardcoded to 5, "Known" packets are show on bottom screen, unknown on the top one.
At the moment i suppose all packets with BSSID starting by 99 are known ones (I will make it better later).
So I'm pretty sure sending packets works (you can check it with any wifi sniffer), now i would like to know if it works (if pressed A you will see plop, if B you will see NON).
Note if someone wants to use it to make a direct DS-DS game, you can use the lib.c file, the functions name are enough explicit.
What you send with SendMessage should appear as is in getPackets on other side.
It should work without any problem with much than 2 DS (if it works with 2).

So please try it and leave a comment to know if it works or not, and if not i'd like to have a wifi dump of channel 5 during the test.

Just tried it, I only got "Got unknown packet from 255:255" a bunch of times down the screen.

Nothing happened when I pressed A or B. Does it matter that I was in range of my AP?
_________________
I'm not a boring person, it's just that boring things keep happening to me.
Homepage

I tried it using the following equipment:

DS1: Nintendo DS firmware v1, flashme, GBAMPv2
DS2: Nintendo DS Lite, R4DS

I'm seeing the same result as spinal_cord. I did notice DS1 is receiving twice as many packets compared to DS2 though. Probably due to the different hardware.

http://forum.gbadev.org/viewtopic.php?t=11946 may help some. The last few pages have the latest downloads, though I don't know if source is included or not.

Sorry man - three DS' here (one old phat, one new phat, one old lite) and three screens covered in the 255:255 message, regardless of however many DS' have been turned on or had their buttons pressed etc!
I am sitting right next to an AP which is turned on though - will this make any difference?
_________________
Big thanks to everyone who donated for Quake2

No luck here either.

I did some tests with the source, changing destination MAC address to broadcast and the sniffer I used (CommView for WiFi / Win32) recognized everything the DS sent as 802.2 protocol packets (src MAC corresponding the DS, dest MAC being "broadcast"). This because the broadcast messages sent from my AP did go through to the DS's.

It seems like the packets sent by DS just never reach the PacketCaptureHandler in the other end. Something wrong with the packets, channel or transfer speed?

you may have the same problem as me. The promiscuous mode is not really a promiscuous mode :
- if not associated to an AP, you'll only get beacon frames.
- if associaed with AP, you'll get all

you can tweak with some register values to get more traffic being unassociated, but i never succeeded in capturing ALL traffic (for instance : the WEP-encrypted one i needed for aircrack).
a bit more info here :
http://www.1emulation.com/forums/index.php?showtopic=22649

Another pointer: You will indeed receive beacon frames, also from other DS's. In other words, first a beacon frame should be sent, received and ACK'ed before proceeding further.

I checked what kind of beacons commercial DS games send and you can get your initial packets through by changing framehdr[0] to 0x80 and using broadcast SSID (0xff all of your BSSID), both from and to DS MAC address can be set to the MAC address of the sending DS. I don't know if this is according to 802.11 specifications, but at least this is how the New Super Mario Brothers sends local wireless game beacons.

See also MightyMax's tips on this subject.

Edit: I don't have right now time to test this any further, but here's a modified and unfinished test application based on phhusson's code, sending beacon frames (non-PAlib + recognizes DS from sender MAC address): nds + sources.

Ok, Great thanks for tests, informations and new source code.
If i remember good, sgstair once said to make a connect/disconnect to a fake AP to be able to make a sort of BSSID filtering (which is what i want too so each game could have a different BSSID and won't cause problems), and to get non-beacon packets i suppose.
I will try to code it (and i will see if my packet injection does actually works ....).

But i wonder: it seems the acknowledge about direct DS to DS coding is enough, so why nobody wrote a true DS2DS network library ?

phhusson wrote:

But i wonder: it seems the acknowledge about direct DS to DS coding is enough, so why nobody wrote a true DS2DS network library ?

well. i only have one DS (and i'm not sure to succeed too !)

I'll test it later today, my friend also has a Games n' Music. He has a DS Lite with new WiFi, though, so if it uses old WiFi library it probably won't work at all.
_________________
DS Firmware 1, Datel Games n' Music card / Chism's FW hacked GBA MP v2 CF

There's no place like 127.0.0.1.

Don't even try mine calcprogrammer1 it would be a waste of time.
But you can try the one of melw.
For the DSWifi version it should be right.

I can share my little test i had created when i first poked the wifi recently. The code is an ugly copy&paste from different resources on the PC side (its PC to DS without AP, but you should have no problem to create the same packets from the DS for DS2DS

Start off, by using the wifime driver for the ralink. There is a echo example on receiving/sending data. The main.cpp now looks

Code:

// windows
#include <windows.h>
#include <ntddndis.h>
// standard
#include <conio.h>
#include <stdio.h>
// other
#include "device.h"

#define BIGENDIAN(n)    ((((unsigned long)(n) >> 24) & 0xFF) | (((unsigned long)(n) >> 8) & 0xFF00) | (((unsigned long)(n) << 8) & 0xFF0000) | (((unsigned long)(n) << 24) & 0xFF000000))

#define CRC32POLY 0x04C11DB7 /* CRC-32 Polynom */
#define CRC32POLYREV 0xEDB88320 /* CRC-32 Polynom, umgekehrte Bitfolge */

int datastream[]={1,0,0,0,1,1,0,0};
int databits=8;

unsigned int crc32; /* Shiftregister */
unsigned int crc32_rev ; /* Shiftregister */
void calc_crc32(int bit)
{
int hbit;
hbit=(crc32 & 0x80000000) ? 1 : 0;
if (hbit != bit)
   crc32=(crc32<<1) ^ CRC32POLY;
else
   crc32=crc32<<1;
}

void calc_crc32_rev(int bit)
{ int lbit;
lbit=crc32_rev & 1;
if (lbit != bit)
crc32_rev=(crc32_rev>>1) ^ CRC32POLYREV;
else
crc32_rev=crc32_rev>>1;
}

//------------------------------------------------------------------------------
void DeviceReadPacketCallback( PDEVICE_INFO lpDeviceInfo, PUCHAR lpBufferData, ULONG dwBufferSize)
{
PUCHAR lpFrameData;
ULONG dwFrameSize;
BOOL bOK;
// visual indicator that we received something
printf( ".");
// skip avs wlan header
if (*(ULONG*)(lpBufferData + 0) == _byteswap_ulong( 0x80211001))
{
   lpFrameData = lpBufferData + _byteswap_ulong( *(ULONG*)(lpBufferData + 4));
   dwFrameSize = dwBufferSize - _byteswap_ulong( *(ULONG*)(lpBufferData + 4));
}
else
{
   lpFrameData = lpBufferData + 0;
   dwFrameSize = dwBufferSize - 0;
}
// write packet
// bOK = DeviceWritePacket( lpDeviceInfo, lpFrameData, dwFrameSize);
if ((lpFrameData[1] == 0) && (lpFrameData[0] == 0x80))
{
//    return ;
}
printf("RECV: \n") ;
crc32 = 0 ;
crc32_rev = ~0 ;
for (int i=0;i<dwFrameSize-4;i++)
{
   printf("%02X",lpFrameData[i]) ;
   for (int q=0;q<8;q++)
   {
      calc_crc32_rev((lpFrameData[i] & (1<<q))!=0) ;
      calc_crc32((lpFrameData[i] & (1<<q))!=0) ;
   }
}
printf("\nCRC: %X / %X / %X\n",crc32,~crc32_rev, *(unsigned long *)(lpFrameData + dwFrameSize-4)) ;
printf("\n") ;
}

void SendHelloWorld(PDEVICE_INFO lpDeviceInfo)
{
UCHAR frame[] = { 0x08,0x02,00,00,             /* data */
               0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,    /* to */
               0x12,0x34,0x56,0x78,0x9A,0xBC,    /* from */
               0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,    /* bss */
               0x00,0x00,
               0xAA,0xAA,0x03,0x00,0x00,0x00,0x08,0xff, /* snap, protocol 0x08FF (unknwon, but in ip related) */
               'H','e','l','l','o',',',' ','W','o','r','l','d',0,
               0,0,0,0 /* crc */
            } ;

int dwFrameSize = sizeof(frame) ;
PUCHAR lpFrameData = &frame[0] ;
crc32 = 0 ;
crc32_rev = ~0 ;
for (int i=0;i<dwFrameSize-4;i++)
{
   printf("%02X",lpFrameData[i]) ;
   for (int q=0;q<8;q++)
   {
      calc_crc32_rev((lpFrameData[i] & (1<<q))!=0) ;
      calc_crc32((lpFrameData[i] & (1<<q))!=0) ;
   }
}

*(unsigned long *)(frame+sizeof(frame)-4) = ~crc32_rev ;

if (!DeviceWritePacket(lpDeviceInfo,frame,sizeof(frame)))
{
   printf("failed to send") ;
} else {
   printf("#") ;
}
}

//------------------------------------------------------------------------------
int main( int argc, char *argv[])
{
BOOL bOK;
DEVICE_INFO DeviceInfo;
UCHAR mac[6];
int key;
USHORT ver[4];
// application title
printf( "\n");
//
ZeroMemory( &DeviceInfo, sizeof( DeviceInfo));
// find device
bOK = DeviceFind( &DeviceInfo, 0);
if (!bOK)
{
   printf( "DeviceFind() failed\n");
   return 0;
}
// get driver version
memset( ver, 0, sizeof( ver));
bOK = DeviceGetDriverVersion( &DeviceInfo, ver);
if (!bOK) printf( "DeviceGetDriverVersion() failed\n");
// device info
printf( "Device Description = %s\n", DeviceInfo.Description);
printf( "Device Hardware ID = %s\n", DeviceInfo.HardwareID);
printf( "Device Location = %s\n", DeviceInfo.Location);
printf( "Driver Version = %d.%d.%d.%d\n", ver[0], ver[1], ver[2], ver[3]);
printf( "\n");
// open device
bOK = DeviceOpen( &DeviceInfo);
if (!bOK)
{
   printf( "DeviceOpen() failed\n");
   return 0;
}
// set packet filter
bOK = DeviceSetPacketFilter( &DeviceInfo, NDIS_PACKET_TYPE_PROMISCUOUS);
if (!bOK) printf( "DeviceSetPacketFilter() failed\n");
// get mac address
memset( &mac[0], 0, sizeof( mac));
bOK = DeviceGetMacAddress( &DeviceInfo, mac);
if (!bOK) printf( "DeviceGetMacAddress() failed\n");
// set channel
bOK = DeviceSetChannel( &DeviceInfo, 10);
if (!bOK) printf( "DeviceSetChannel() failed\n");
// install ReadPacket callback function
bOK = DeviceSetReadPacketCallback( &DeviceInfo, DeviceReadPacketCallback);
if (!bOK) printf( "DeviceSetReadPacketCallback() failed\n");
// start receive thread
bOK = DeviceThreadReceiveStart( &DeviceInfo);
if (!bOK) printf( "DeviceThreadReceiveStart() failed\n");
// wait for key
printf( "Press [x] to abort\n");
key = 0;
while (key != 'x')
{
   Sleep( 10);
   if (kbhit()) key = getch();
   switch (key)
   {
      case 'h':
         SendHelloWorld(&DeviceInfo) ;
         key = 0 ;
         break ;
   }
}
// stop receive thread
bOK = DeviceThreadReceiveStop( &DeviceInfo);
if (!bOK) printf( "DeviceThreadReceiveStop() failed\n");
// remove packet filter
bOK = DeviceSetPacketFilter( &DeviceInfo, 0);
if (!bOK) printf( "DeviceSetPacketFilter() failed\n");
// close device
bOK = DeviceClose( &DeviceInfo);
if (!bOK) printf( "DeviceClose() failed\n");
// exit
return 0;
}

The other files are not modified.

For the DS side, use http://mightymax.org/libwifi.nds . [A] switches the channels. Select Channel 10 on the DS. A keypress on [h] on the PC should send the "Hello World" on channel 10 string to the DS displaying it there. (At least it works here :D)

You may change the text in the frame and have the changed text displayed on the DS.

However, there are still problems with the receiving, sometimes the wifi hardware seems not to initialize correctly. Usually switching through the channels fixes this.

There should be no problem in sending the frame[] from another DS.

Hope that helps.

PS: The libwifi.ds logs all transfers (receive & transmit) in the file. "Wifi.apc" a hexeditor helps here, its not a valid wireshark capture format even if it says so by the extention. [START] stops the receiving/logging and finalizes the file
_________________
GBAMP Multiboot

Some interesting results with melw's modifications. Both DS's can receive and transmit messages. If I left a DS on for around 5 minutes, it would no longer receive messages. It was still able to transmit messages. Here is the output of both DS's sending and receiving one packet.

Code:

DS1:
Hello DS dev'rs
www.drunkencoders.com
checking wifi preinit...
wifi preinit done
wifi enabled
channel set
own mac: 0: 9:BF: A:DE:E1
DS data from: 0:19:FD:83:CA:55: plop?
Send message 'plop'
send raw tx frame

DS2:
Hello DS dev'rs
www.drunkencoders.com
checking wifi preinit...
wifi preinit done
wifi enabled
channel set
own mac: 0:19:FD:83:CA:55
Send message 'plop'
send raw tx frame
DS data from: 0: 9:BF: A:DE:E1

It is picking up packets from my Wii which has Connect24 turned on. For example:

Code:

DS data from: 0:17:AB:46:4F: 1:

I tested it,(melw's mod)
but it didn't work right either.

It wouldn't boot correctly with my DS-X.
So, I tried using DS Organize,
to boot it.(via crishm's loader)
That worked.(But, the top screen was white.)
(The only thing on any of the WiFi channels were
the DSes.)

Here's what happened when I tested
it with a original DS, and a DS Lite.

After either system sent 2 packets,
they stopped sending the packets correctly.
That is, they weren't detected by the other DS.

Here's what happened when I tested it
with the same setup as above,(a original DS and a Lite.)
except with an additional,
original DS.

After one DS sent one or two packets,
it stopped sending them correctly.
That is, they didn't get detected by
the other systems.

But, after that happened,
when I tried sending packets on
the other systems,
it did the same thing.

It kept going this way.
That is, one DS stopped sending correctly,
then tried the others,
they did the same,
and the first one did the same,
and so on.

Last edited by yellowstar on Mon Oct 01, 2007 7:40 pm; edited 1 time in total

phhusson wrote:

But i wonder: it seems the acknowledge about direct DS to DS coding is enough, so why nobody wrote a true DS2DS network library ?

Don't know about the rest, but personally I don't have much of experience in network programming, and previously estimates on getting homebrew DS to DS networking done varied from hard to impossible, which again didn't encourage on working on this. :)

But perhaps we can pull this together... At least I'm willing to help wherever I can. Continuing the tests when time permits.

zazery wrote:

It is picking up packets from my Wii which has Connect24 turned on.

Ahhah. Yes, of course. MAC address in Nintendo range doesn't always mean it's a DS sending data.

melw wrote:

phhusson wrote:

But i wonder: it seems the acknowledge about direct DS to DS coding is enough, so why nobody wrote a true DS2DS network library ?

Don't know about the rest, but personally I don't have much of experience in network programming, and previously estimates on getting homebrew DS to DS networking done varied from hard to impossible, which again didn't encourage on working on this. :)

But perhaps we can pull this together... At least I'm willing to help wherever I can. Continuing the tests when time permits.

My experience in network programming isn't big either,and i never tried to put a game to network, but many homebrew games are already networked (like dicewars or quake ds), and i think they only need a simple way to send and retrieve packets multicasted and unicasted to DSes. The only problems i see are to succeed to retrieve all packets of a BSSID (or more if we filter after), then we will "just" need to add optional ACK support (checksum are already hardware managed \o/), and i guess it won't be that hard. But we would first can do things without it (for instance with quake, it usually uses UDP which has the same problems than wifi, packet loss but checksums automatically checked/formated).
So your actual code could be enough for quake DS (mm right it would need more filtering).

Sorry, wrong topic.

I tried at my friend's house, but it didn't work. It just kept saying something about 255:255 (I forget what it said) but pressing A and B didn't do anything.

My DS:
DS "Phat" (silver) Firmware Version 1, release-week
Datel Games n' Music with stock 128MB microSD

His DS:
DS Lite (black) DS Lite Firmware, "incompatible" WiFi chipset
Datel Games n' Music with SanDisk 1GB microSD
_________________
DS Firmware 1, Datel Games n' Music card / Chism's FW hacked GBA MP v2 CF

There's no place like 127.0.0.1.

I played around with the test application a bit: updated nds download. This version breaks the 802.11 protocol in many ways, thus no source update. But at least some data does get through.

A - send a beacon frame
B - send a 802.2 data frame (only possible when a connection is been made between 2 DS's)

I'll go reading 802.3 SNAP specifications next... MightyMax, any chance of sharing you libwifi.nds source?

melw, your latest test works on my DSs, however each of them can receive (after sending 1 becon frame with A) only 5 data frames sent with B from the other, then nothing more is received. Anyways, keep up the great work!

Hardware:
2 silver "Phat" DS, both with Supercard SD
_________________
<dsFont> <Game Collection>

Follow-up questions for MightyMax: I tried your modified wifime echo main... But can't get any of the packets sent from there to show up in the DS end. If I send exactly same kind of data frame from DS, the PC app picks up the frame, but again no other DS seem to be receiving it.

The above behavior when using my own source in DS end, libwifi.nds keeps crashing constantly for me. Are there any specific DS wifi settings that should be used here?

I had no problem receiving the dataframes sent by the DS. (once the CRC was correctly, otherwise the DS rejected the frames)e

I have packed the sources as-is to http://mightymax.org/libwifi.rar .
_________________
GBAMP Multiboot

Do we really need to implement 802.11 ?
I mean just some hacks would be enough.
As the one from melw with beacons, even if it would be better to have some hardware filtering using BSSID (i will take a look for it)
Note:Mighty Max's code is interesting in understanding 802.11

It is at least partly needed in order to not break devices in range following the standard. Espacially in breadcasts try to ensure that no device might disinterprete your packets.
_________________
GBAMP Multiboot

Mighty Max wrote:

It is at least partly needed in order to not break devices in range following the standard. Espacially in breadcasts try to ensure that no device might disinterprete your packets.

Hum right,will there be any problem if we use a "false" broadcast bssid ? (for example i thaught of using 99:98:97:XX:XX:XX which would be 00:00:00 for game discovery, first XX:XX identify the game and last digits sets a room).

I look deeper in DSWifi source code and it looks like that was i read from sgstair is true: the only way in DSWifi to change current BSSID (by default it's FF:FF:FF:FF:FF that's why it only gets beacon packets) is to fake a connection in adhoc not to send false open auth, or a normal connection which would be closed just after opening it to avoid too many auth packets, if wifi doesn't gets down the bssid will remain.
So this Q&D workaround is possible, another would be to patch dswifi, which wouldn't be that hard i think but at the moment I don't really know how to synchronise arm7 and arm9

Yes, sending beacons and broadcasts all the time might mess up wireless networks. What I tried in that nifichat2.nds shouldn't be done and it won't work for steady connections anyways. Broadcasts are just for advertising that you're alive and waiting for a connection - the rest should go according to set protocols.

Phhusson, Then again at least beacon broadcasts with bssid set to source MAC go through. That should be enough for the receiving end to set the bssid accordingly and continue from there. I don't think using false broadcast id's would help in the long run anyways - just filtering the non-Nintendo MAC's out should be enough.

Currently I feel like banging my head into a thick wall, zero progress in getting any DS to DS packets going through, where as DS to PC works - it may be indeed that the DS wifi (either the library or hardware) is discarding packets right away. The CRC for the frame is calculated and should be correct (compared the PC echo frames to what DS is sending), but obviously I'm doing something else wrong.

melw wrote:

I don't think using false broadcast id's would help in the long run anyways - just filtering the non-Nintendo MAC's out should be enough.

But what happens when they add new ranges? Every time Nintendo changes the wifi hardware, they change the MAC range.
_________________
I'm a PSP hacker now, but I still <3 DS.

HyperHacker wrote:

melw wrote:

I don't think using false broadcast id's would help in the long run anyways - just filtering the non-Nintendo MAC's out should be enough.

But what happens when they add new ranges? Every time Nintendo changes the wifi hardware, they change the MAC range.

There are currently 11 known ranges which are registered to Nintendo. I haven't really followed this from the beginning, but I'd assume they were registered quite a while ago, and there won't be any other MAC address ranges to be used besides the ones listed below. Out of these 11 ranges I've seen so far 7 in use for Nintendo DS.

Code:

00:09:BF:XX:XX:XX
00:16:56:XX:XX:XX
00:17:AB:XX:XX:XX
00:19:1D:XX:XX:XX
00:19:FD:XX:XX:XX
00:1A:E9:XX:XX:XX
00:1B:7A:XX:XX:XX
00:1B:EA:XX:XX:XX
00:1C:BE:XX:XX:XX
00:1D:BC:XX:XX:XX
00:1E:35:XX:XX:XX

(source)

I got some results, i succeed to receive packets with a specific BSSID, but only non data packets ...
It seems DS hardware filter it, but i don't understand why, i should miss a Wifi register but don't know which one :/

(If anyone is interested by a little C program for linux to inject homemade packets, just ask me)

Check my sources espacially the wifi init, i did some modification to the method described on akkit.

One is to listen in mode 3 upfrom the start (dswifi starts in mode 2) and not only when trying to connect. Also changed are values to a register that is thought to be some kind of filter select (Base+0x0D0)

I have also disabled the stats (base + 0x1AE) alltogether, as their IRQ was often the last thing i was regognizing before the receiving went silent.
_________________
GBAMP Multiboot

Mighty Max wrote:

Check my sources espacially the wifi init, i did some modification to the method described on akkit.

One is to listen in mode 3 upfrom the start (dswifi starts in mode 2) and not only when trying to connect. Also changed are values to a register that is thought to be some kind of filter select (Base+0x0D0)

I have also disabled the stats (base + 0x1AE) alltogether, as their IRQ was often the last thing i was regognizing before the receiving went silent.

I will try, but is there a meaning of this 3 or 2 ?
Looking at dswifi source code it sets it to 2 at start and that's all, so it should work without it
And accoding to http://www.akkit.org/info/dswifi.htm
" The bottom 3 bits of this register specify a software mode for wifi operation (may be related to hardware but a correlation has not yet been found)"
But the 0D0 looks interesting.
Another thanks for all your informations :)

I decided to try and work with the code i have atm and create a "Lobby library" for homebrew to meet up and communicate for games/apps.

For this i have included the NDS sources into a PC-Project with the HAL exchanged to use the wifime-card. I hope to have a first working demo soon, that should also work for two or more DSes.
_________________
GBAMP Multiboot

Mighty Max wrote:

I decided to try and work with the code i have atm and create a "Lobby library"

Good luck! I lost my nerves working on this and went back finishing the Dicewars DS multiplayer version instead... However I'm more than willing to help with testing if needed (have 3 DS's and a PC laptop with Ralink card over here).

Ok, found another thing that let's the DS filter pakets out.

Sounds logical now (and stupid to ignore until now), but it was something that got me problems when sending on non-busy channels, which is now solved:

When sending raw frames via ralink, make sure to update the sequence number, otherwise every paket following the first received will be ignored until one station sends a paket with a different seqaence ID.
_________________
GBAMP Multiboot

Can someone test http://mightymax.org/libwifi.nds ?

It works relyable here now for the ralink<->ds, but i have no way to check for ds<->ds (I got myself a second DS, but no mean to flash it)

The app, when launched on only one DS should show a black screen with a letter counting up in the upper right corner. Depending on if there is traffic or not on channel 7, the letter should change every second and faster.

When the app is started on another DS at the same time, they both should regognize each other, and tell the name of the other DS (The username to be exact. In my case "Mighty Max" and "RALINK" [Images not permitted - Click here to view it])

If one DS goes silent for 4 seconds the station should timeout on the other DS, and if restarted reappear again.
_________________
GBAMP Multiboot

Works reliably with my DS and my brother's.

It works in most (~60 - 70%) cases, the names of the DS are correctly displayed. But in other cases nothing happens at all, only the counter is shown. Unfortunately I couldn't find a pattern for when this happens.

Tested with 2 Supercard SD's in 2 "Phat" silver DS.
_________________
<dsFont> <Game Collection>

Thank you both. That is at least one step further.

ThomasS's problem is something that happened also before here. (But i thought this was solved) I need to find a way to tell if the wifi core is really listening.
_________________
GBAMP Multiboot

Hum what have you changed in initialisation since your last source code ?

The first one doesn't work while the last nds app you gave works, and i use exactly same packet generator with same configuration (just rebooted the DS).
(And my app only still only gets non-data packets)

Tried 3 times in a row with 3 different DS's, also shutting down random DS and switching it back on testing timeouts - everything worked flawlessly and each device recognizing the others.

Tested with:
- DS Phat, GBAMP/SD
- DS Lite, M3 Perfect Lite
- DS Lite, R4DS

Looking good!

phhusson wrote:

Hum what have you changed in initialisation since your last source code ?

Alltho i was playing with some other RX Filter Registers, the one you are using has no changes in the init code. What's changed is the way the data is retrieved from the mac memory, and the IDing of the sent packets.

From some quick look, base+0DA seems i.e. to be some kind of selector which data is to be written in to the mac memory on receive. (Don't nail me on this, it was just an impression i got without looking too deep)

---

Btw, i still need to find a way for the ipc code im using right now to use the uncached mirror without the cached mirror corrupting the data when it is accessed near the messaging struct.

Disabling the cache alltogether, like it is now, is no option for an lib to be used in release apps/games.
_________________
GBAMP Multiboot

I got another test ready http://mightymax.org/libwifi.nds

I added a mean to send to one DS only instead of broadcasting like it is done to announce the DS to all others.

With [up],[down] select the DS/Station to send to, press [a],[b],[x],[y] to send a message "Key [*] was pressed" to the selected DS.

If all works, only the selected DS should show the message, and the others should keep silent.

:edit: There is no flow control yet, all messages are "fire and forget" atm, so msg loss shouldn't wonder ;)
_________________
GBAMP Multiboot

It worked fine, but I only have two ds's, so I don't know about any data being sent to other ones.
_________________
I'm not a boring person, it's just that boring things keep happening to me.
Homepage

Mighty Max wrote:

I got another test ready http://mightymax.org/libwifi.nds

I added a mean to send to one DS only instead of broadcasting like it is done to announce the DS to all others.

With [up],[down] select the DS/Station to send to, press [a],[b],[x],[y] to send a message "Key [*] was pressed" to the selected DS.

If all works, only the selected DS should show the message, and the others should keep silent.

(Same test setup as before - 3 DS's) Sending data works, but the data gets through always to both 2 other DS's no matter what destination has been selected.

OK, thank you.
Guess simple filtering by the software should solve that then.

:edit: arg! some debug stuff was left there, making all sent 802.11 packets broadcasts
_________________
GBAMP Multiboot

Please try again (same link: http://mightymax.org/libwifi.nds )

The packets should now addressed correct, so that using the hardware filter should work (at least it does so when i fake a third DS i send to on the PC application)
_________________
GBAMP Multiboot

Works!

Great!
Thank you again.

Now i got to start working on the "need to deliver" streams and several helpers (like to transfer more data then matching in one frame and such)
_________________
GBAMP Multiboot

It works for me as well. We should probably run some tests with 3-8 DS . I'm part of the DS/homebrew club at my university so I can probably make this test happen. Would this binary support that many DS or should I wait for another one?

Great work Mighty Max and everyone else. Seems like we're going to have some kind of revolution in the homebrew scene soon! ;D
_________________
http://licklick.wordpress.com

There is no build-in limitation in the software. What works for 3 DSes _should_ also work for a dozen. (Tho you can never be sure ;) )

But it would be nice to know that it works/doesn't work anyways. I thank everyone testing :D

The now following steps however will take time without seeing much changes:
- cleaning up the code from the debug/testing hacks
- fixing the allready known bugs and finding new ones
- detecting/avoiding the wifi-lockup
- exchange the IPC functions (I think at least some of the lockups come from here)

The "need to deliver" problem is solved, to the point that every sent data is received at least once (except for a station timing out). Fragmentation & multiple receives are not handled properly yet
_________________
GBAMP Multiboot

Lick wrote:

Seems like we're going to have some kind of revolution in the homebrew scene soon! ;D

Wii'd need to get past the digital signature first before we can have a revolution in the homebrew scene. Unlike the DS, the Wii gets remote firmware upgrades, and we can expect PSP-style cat-and-mouse.

Another problem with multiplayer DS homebrew is that you still need to launch, eject card, launch in order to get more than one DS going. But given how long the instructions for doing this on GBAs have been up on pocketnes.org, this shouldn't be too much of a problem, right?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Keep up the good work! When this software gets further I can take some flash adapters and a laptop with wmb and go into a local IGDA pub meeting (always swarming with game dev's and DS's). Would be great to try how this works with as many DS's as possible. :)

Worked well for me!
(Same setup as above,
with two original DSes, and a Lite)

This time it booted correctly on
my DS-X.

I was thinking of a file browser with sharing feature. =)
_________________
http://licklick.wordpress.com

Maybe an ad-hoc version of Moonlight's wifi voice chat? It'd be like Pictochat with less suck.
_________________
I'm a PSP hacker now, but I still <3 DS.

If you are close enough for ad-hoc, just walk to your friend and chat, you don't need a microphone. It will be good for multiplayer games.
_________________
GTAMP.com/DS

Today's info update:
- changing the underlying IPC made it more stable.
- the receive lockdown has been resolved
- there is still a problem with transmit at random times. I am trying to work out why by dumping the registers. By the look of it, it seems that there is neither a transmit complete IRQ is cast nor the TXLOC's enable flag removed. The earliest occurance was after 0x78 sends, the latest after 0x8D7 transmits. Trying to figure it out ...

:edit: seems that register base+0x25C is non zero as soon as this happens. All register dumps while sent was working showed it as 0.
:edit^2: resetting the TX CNT/TX Locs on that value seems to do the trick. I can now send until something else goes wrong (i got a memleak somewhere), i just wonder why this doesn't happen in dswifi / what i am doing wrong in the first place
_________________
GBAMP Multiboot

I have still lockdowns on send, which will now resolve due to the error check after some seconds. This is not very suitable for serious use.

Maybe someone finds the problem with my send i am blind for.

Code:

void WIFI_SendRAW(char *buffer, int length)
{
// wait until there is an slot available
while ((WIFI_REGISTER(WIFI_TXLOC1) & 0x8000) && (WIFI_REGISTER(WIFI_TXLOC2) & 0x8000))
{
   // if there is a sent lockdown, reset sends
   // looks to work, but takes a few secs?
   if (WIFI_REGISTER(0x25C))
   {
      WIFI_REGISTER(WIFI_TXLOC1) = 0x0000 ;
      WIFI_REGISTER(WIFI_TXLOC2) = 0x0000 ;
      WIFI_REGISTER(WIFI_TXLOC3) = 0x0000 ;
      WIFI_REGISTER(WIFI_TXCNT) = 0x0000 ;
      WIFI_REGISTER(WIFI_TXCNT) = 0xFFFF ;
      WIFI_REGISTER(WIFI_TXCNT) = 0x0000 ;
   }
}
// don't send while beaconing
while (REG_IF & 0x8000)    // pre beacon irq happened (but not handled)
{
   if (REG_IF & 0x4000) // beacon was done (and also not handled)
   {
      REG_IF |= 0xC000 ;
   }
}
// check first send slot
if (!(WIFI_REGISTER(WIFI_TXLOC1) & 0x8000))
{
   WIFI_REGISTER(WIFI_RETRYLIMIT) = 7 ;
   // init header
   int i ;
   for (i=0;i<8;i+=2)
      WIFI_REGISTER(WIFI_MEMORY + i) = 0x0000 ;
   WIFI_REGISTER(WIFI_MEMORY + 8) = 0x000A ;
   WIFI_REGISTER(WIFI_MEMORY + 10) = length + 4 ;
   // copy payload
   for (i = 0; i < length ; i+=2)
   {
      WIFI_REGISTER(WIFI_MEMORY + 12 + i) = ((unsigned short *)buffer)[i/2] ;
   }
   // place for CRC
   for (;i<length + 4;i+=2)
   {
      WIFI_REGISTER(WIFI_MEMORY + 12 + i) = 0x0000 ;
   }
   // enable slot, start sending of slot
   WIFI_REGISTER(WIFI_TXLOC1) = 0x8000 ;
   WIFI_REGISTER(WIFI_TXCNT) |= 0x01 ;
} else if (!(WIFI_REGISTER(WIFI_TXLOC2) & 0x8000))
{
   // send slot 2
   WIFI_REGISTER(WIFI_RETRYLIMIT) = 7 ;
   // init header
   int i ;
   for (i=0;i<8;i+=2)
      WIFI_REGISTER(WIFI_MEMORY + i + 0x300) = 0x0000 ;
   WIFI_REGISTER(WIFI_MEMORY + 8 + 0x300) = 0x000A ;
   WIFI_REGISTER(WIFI_MEMORY + 10 + 0x300) = length + 4 ;
   // copy payload
   for (i = 0; i < length ; i+=2)
   {
      WIFI_REGISTER(WIFI_MEMORY + 12 + i + 0x300) = ((unsigned short *)buffer)[i/2] ;
   }
   // place for CRC
   for (;i<length + 4;i+=2)
   {
      WIFI_REGISTER(WIFI_MEMORY + 12 + i + 0x300) = 0x0000 ;
   }
   // enable slot, start sending of slot
   WIFI_REGISTER(WIFI_TXLOC2) = 0x8300 ;
   WIFI_REGISTER(WIFI_TXCNT) |= 0x04 ;
}
}

_________________
GBAMP Multiboot

EDIT: Never mind, the following bug has been fixed
in the updated version. So, it works like it is supposed to, again.

I have found a bug.

Same setup as above.(one Lite, two originals)

The Lite was running Juglak's WMB Host.

The others were running this program.

Once the Lite was running,
I restarted the other DSes.

Here's the problem:
With a DS running the WMB Host in range,
when the DS starts up,
it fails to detect the other DS.(in this program)

Sektor wrote:

If you are close enough for ad-hoc, just walk to your friend and chat, you don't need a microphone.

If you're in the same room.
_________________
I'm a PSP hacker now, but I still <3 DS.

I think i found that bastard that locked up transmitting while cleaning up the wifi_hal.c

http://mightymax.org/libwifi.nds should be more stable now and not break after a fast sent row of frames. ([SELECT] triggers a non acked send 60times a second (vblank). The stream used for this is not shown on the other DS, but the work indicator should count the packets up, other keys as previous)

I _think_ it was caused by me ORing the TXCNT Register with the tx-slot to be used which triggered a "try to send slot" also on the other channels that were still set in TXCNT (i.e. from flushing all sends on init) and finally reaching a tx error threshold. Also the TX location for TXLOC2 was falsely set *oups*

:edit:
Btw the filter setting needed to get data frames is indeed in 0x0D0.:

Code:

#define WIFI_RXFILTER    0x00D0
// RXFILTER:
#define WIFI_RXFILTERDATA    BIT(11)
#define WIFI_RXFILTERBEACON    BIT(0)

_________________
GBAMP Multiboot

Just a note. Yesterday Martin Korth (author of no$gba) updated his gbatek with the latest information, which includes huge update on wifi hardware.

Hope it helps in any way. I think a lot of people, including me, interested in seeing a working library. Thanks for your hard work guys.

Thanks for the hint. I still was using an cached version *g*

I should contact him with my findings. I got some more register info he hasn't in it yet.

Btw, if anyone has a spare nopass ....
It's a shame that no console/modding shop has any DS related things beside Stylus replaces and such around here.
_________________
GBAMP Multiboot

I'm sure Martin would be happy with any extra info. A lot of exciting work is going on here for both homebrew and emulation. :)

Oh, and I'm in GBAtek. (ARDS/CBDS documentation) ^_^ I can die a happy man now... or something. Actually I think I'll stay in the world of the living for the time being. Heh.

Sorry, I digress. Anywho...
Keep up the good work guys!
_________________

dualscreenman wrote:

What about Gaim DS? Gaim pretty much has support for all IM programs.

tepples wrote:

"Goshdammit, the DS is not a Gaim-boy! It's a third pillar!"

I have set up a subversion repository for the testapplication

You can find it at svn://91.184.39.23/svn/repos/libwifi

It is not yet a library as the name suggests, it's just the source of the NDS i have previously posted. The cleanup is at an early stage, there are dozent of places where i tested settings, replaced code, left code commented out / unused, used dirty ways to do things etc.

It's just to share the information i've found/finding out right now. If someone wants to add to it and thus needs write access, leave me a message.
_________________
GBAMP Multiboot

The source has been converted into a library.
The previous .nds file has been converted into an example on how to use/compile against the lib.

It still misses functions to manage rooms (join/leave/advertise/sendTo/inforetrieve) and a lot of checks against failures, but it should be at least usefull enough for a first test from all the app/game developers out there.
_________________
GBAMP Multiboot

I have found a bug.

Whenever you press Start,(dosen't matter if other DSes were
detected or not)
it crashes.

By crash,
I mean an exception.
(White text on red background, with the 'Guru Meditation Error' title)

Yes., thanks. This shouldn't happen anymore with the version on SVN.

It was just my lazyness that didn't let me adjust the read buffer for the dump register debug-function ;) Nonetheless after the crash you should have a 4kB "REG.DMP" file showing the lowest wifi registers (non action mirror)
_________________
GBAMP Multiboot

Basic room management (create, join, sendTo) has been implemented, and is now nearly ready for the first DS<->DS game. I think of a simple pong game as an example. At this time i think i'll put the first binaries up on a http webserver together with the pong's source as an example on how to use the lobby.

Due to generously donations (thanks from here again!) i will be able to test all these things myself soon.

Suggestions from developers are welcome. (Need functions,fixes,etc?)
_________________
GBAMP Multiboot

Is there a problem using this together with dswifi? While doing a quick test to integrate this, they collided pretty badly.

I'm soo looking forward in getting this up and running... :)
_________________
http://www.collectingsmiles.com/colors & http://www.collectingsmiles.com/hyena

Yes. It's not compatible with dswifi.

This is partly caused by functions that are named equally in both libs (this is one easy solvable one) and due to the fact that they both use the same hardware in a different way, which is a lot more difficult to solve.

From my side it shouldn't be difficult to keep the liblobby inactive when it isn't used, but from the things i've seen and read, it is quite more difficult to stop & reinit dswifi.

I'll put on/off switches for the HAL into the todo list.
_________________
GBAMP Multiboot

So...can I give this a whirl yet? ;-)
_________________
Big thanks to everyone who donated for Quake2

Go and have fun.

You might want to replace the IPC_* functions to use your ipc in quake, but from the rest, it perfoms much more well then i thought when we exchanged PMs.

(Does'nt mean that there isn't still a ton of things to do)
_________________
GBAMP Multiboot

The problem with double function names when linking against dswifi should been resolved. It should now be at least prossible to decide at runtime whether the lobby of the dswifi should be used (alltho it is not _yet_ possible to switch to the other once the decission was made)

If there are still problems, leave me a note.

Not much else today.

Ah btw simon,
If you are using a different IPC system. Make sure the messages transfered are word aligned. (Forgot this the post made this morning.
using Send802.3snap and setting a protocol listener to snap might be all you need. I think quake does all the other fancy protocol things itself already (wasn't it IPX originally?)
_________________
GBAMP Multiboot

Err...dunno what it is that I'm doing wrong, but I can't get anything to happen!
Phusson's original ad-hoc demos from a few pages ago worked (for a few frames) but the demo program you put on the previous page didn't do anything on the four DS' that I tried (two old phats, one new phat, one old lite). One of the old phats would give a guru meditation whenever the first button pressed was start. Nice red screen btw ;-)

I also tried the example program from the svn repo and I only get one "last received text" string...then nothing else. Fearing I'd messed up the build process, I copied the bulk of the code into Quake (I use my own makefile system) but still the same result...

So...what am I doing wrong?! If I'm doing nothing wrong, what can I do to help?
_________________
Big thanks to everyone who donated for Quake2

I had tightened the RXFILTER and the modify on send settings between the working and non working versions. Maybe that is what broke it for you.
(I am currently still checking against a ralink)

I have updated the SVN with a version with the old settings in these registers.
_________________
GBAMP Multiboot

The latest svn version works quite well with the previous test scenario (2 Lite's, 1 DS Phat) - however the old DS model seems slow with recognizing the other DS's and receiving/sending while the communication between the Lite's has no visual lag. I experienced this slowness on the Phat model also in the previous svn update from yesterday but not from the tests before the svn-era.

When I have time, I'll give this library a go with Dicewars DS.

Mighty, do you still need a Nopass? I have a few unused Passkey's over here (both version 1 and 2).

melw, he's all set for hardware. ;)
_________________
NDS Homebrew Roms & Reviews

hmm, there shouldn't been a slowdown between lite and normal DSes, beside initializing RF/BB chips they should act the same.

However, the update has under the premise that no packet gets dropped in the air a worst case latency of around 1 second. However if the hardware fails to send, it will try the next update a second later. This could indeed be very noticeable in noisy environment.

I also changed the transmitting speed to 2mbit (was hardcoded to 1mbit in the first tests) maybe the older DS have more problems (read as: increased packet loss) to receive the updates at that speed (The ralink allways sends at 1mibt). I'll investigate if broadcasting in 1mbit will reduce this problem. And offcourse decrese the timespan for the next update. (To make it less noticeable)

As for the nopass: see Lynx's post. Thanks again lynx.
_________________
GBAMP Multiboot

I've implemented this into Colors! now. Does this means Colors! is the first Wi-Fi ad-hoc homebrew (apart from the Mighty Max's example) for the DS? Whee! :)

http://www.collectingsmiles.com/colors/colors_adhoctest.rar

Anyway. It's a _very_ basic implementation in a stripped debug-version of Colors!. It also lacks the room support (don't let the icons fool you) and I assume it will totally crash and burn for more than two consoles, but still... It sort of works! :)
_________________
http://www.collectingsmiles.com/colors & http://www.collectingsmiles.com/hyena

So. Some observations and some feedback for our hero Mighty Max!

It seems that some data is lost and some data is received multiple times. That can be seen in the log when running the program. I guess that multiple receives is a bug and that my implementation should handle dropped data?

Some feedback on the lib:
* You should include an "if C++ then extern "C"" in the headers like most other C libraries. It took me a while figure out why it wouldn't link.
* The MessageQueue class is nice and I wish there was something like it in libnds. The problem is that I'm not sure how I can send and receive custom data as long as that is active.
* Running LWIFI_IPC_UpdateNOIRQ in the main loop on Arm7 gives me trouble. It blocks for a second at the time and I currently run other things there that need much lower latencies.
* Feel free to fix the 'tinI' style warnings using constants like 0x74696e49 instead. :)
_________________
http://www.collectingsmiles.com/colors & http://www.collectingsmiles.com/hyena

Jesse wrote:

So. Some observations and some feedback for our hero Mighty Max!

It seems that some data is lost and some data is received multiple times. That can be seen in the log when running the program. I guess that multiple receives is a bug and that my implementation should handle dropped data?

I didn't come to document much yet. Streams with an ID lower then 0x8000 are acknowledged, so that there should not be any data loss. If the data was not acked until the next vblank, it is rerequested. (And thus probably received twice). The double receive is somethinething i need to filter, yes.

Quote:

Some feedback on the lib:
* You should include an "if C++ then extern "C"" in the headers like most other C libraries. It took me a while figure out why it wouldn't link.

Should be in most. However i need to update the headers anyways atm the global includes are the one from the project. instead they should only reveal what's needed.

Quote:

* The MessageQueue class is nice and I wish there was something like it in libnds. The problem is that I'm not sure how I can send and receive custom data as long as that is active.

You can use your own IPC, as long as with IPC_GetMessage/IPC_SendMessage data can be received/send word aligned. You can replace the functions or maybe i'll include a "CTM" message for a custom IPC you can get a callback for.

Quote:

* Running LWIFI_IPC_UpdateNOIRQ in the main loop on Arm7 gives me trouble. It blocks for a second at the time and I currently run other things there that need much lower latencies.

Didn't think about that. Allways had the default template in mind. I will add a switch for this behaviour. The blocking happens if there is a transmit waiting to be put in one of the hardware slots. Also it is always waiting for at least one message to be received. Will definately be changed.

Quote:

* Feel free to fix the 'tinI' style warnings using constants like 0x74696e49 instead. :)

Yepp. They are annoying ;) used them to replace the string comparison. i could have used simplier constants but i was too lazy yet.

Thanks for the feedback. Gonna work the points down.

:edit:
- multiple character in constant warning
- arm7 update function blocking when no message is to be received
have been addressed.
I have also added a callback (see IPC_SetCustomCallback) for all IPC messages that are not handled by the lib. This way you can use the included IPC for transfering custom data. Be sure that the lobby is initiated first.

:edit^2:
i think i found something causing a to-be-acked frame not correctly put into the "awaiting ack" list. Got to make the lists irq safe ;)
_________________
GBAMP Multiboot

I'll use this library for the cooperative mode in my Lode Runner game. Thanks for your great work!

However, before the players can play with each other, the whole level has to be transferred from one DS to the other, and this causes some problems because of this bug:

Jesse wrote:

It seems that some data is lost and some data is received multiple times.

I've modified your example code to test this. It now sends 200 bytes of data when the user presses A and displays the sent / received data graphically and in bytes. The more often the same data arrives, the longer the 'X' row gets vertically (it's intended that one DS only sends and the other one only receives).
Theoretically, the output should be the same on both DS, however, it seems that almost all packets get received at least two times, some even seven (or more) times!
When you hold B while pressing A, the data is sent on stream 0x8000 so that no acknowledge is done. Then it works almost perfectly, only a few packets get lost.

I hope this helps to improve it. Here is the code I used in the arm9 template.c:

Code:

#include "nds.h"
#include <nds/arm9/console.h> //basic print funcionality
#include <stdio.h>

#include "MessageQueue.h"
#include "802.11.h"
#include "lobby.h"
#include <fat.h>
#include <malloc.h>
#include <string.h>

int receivedMsg[32];
u32 received;
u32 sent;

void VBlankIRQ(void)
{
REG_IF = IRQ_VBLANK ;
IPC_RcvCompleteCheck() ;
LOBBY_Update() ;
}

void receiveText(unsigned char *data, int length, LPLOBBY_USER from)
{
int i;
char string[256];

received += length;

if (data[0] > 31)
{
   printf("\x1b[6;1HTransfer error: %d! ", data[0]);
   return;
}
for (i = 1; i < 200; i++)
{
   if (data[0] != data[i])
   {
      printf("\x1b[6;1HTransfer error 2! ");
      return;
   }
}

sprintf(string, "\x1b[%d;%dHX", 8 + receivedMsg[data[0]], data[0]);
printf(string);
receivedMsg[data[0]] = (receivedMsg[data[0]] + 1) % (24 - 8);
}

int main(void)
{
received = 0;
sent = 0;
memset(receivedMsg, 0, sizeof(receivedMsg));

REG_EXMEMCNT=0xe800;

powerON(POWER_ALL);
REG_IME = 0 ;
REG_IE = 0 ;
REG_IF = 0xFFFF ;

videoSetMode(0); //not using the main screen
videoSetModeSub(MODE_0_2D | DISPLAY_BG0_ACTIVE); //sub bg 0 will be used to print text
vramSetBankC(VRAM_C_SUB_BG);

SUB_BG0_CR = BG_MAP_BASE(31);

BG_PALETTE_SUB[255] = RGB15(31,31,31); //by default font will be rendered with color 255

//consoleInit() is a lot more flexible but this gets you up and running quick
consoleInitDefault((u16*)SCREEN_BASE_BLOCK_SUB(31), (u16*)CHAR_BASE_BLOCK_SUB(0), 16);

defaultExceptionHandler() ;

irqInit() ;

// Startup IPC engine
IPC_Init() ;
IPC_SetMsgCompleteCallback(&IPC_RcvCompleteCheck) ;

// usual VBlank
irqSet(IRQ_VBLANK,&VBlankIRQ) ;
irqEnable(IRQ_VBLANK) ;

consoleClear() ;

int selected = 0 ;

LOBBY_Init() ;
LOBBY_SetStreamHandler(0x0001,&receiveText) ;
LOBBY_SetStreamHandler(0x8000,&receiveText) ;

while (1)
{
   /* handle input */
   int max = LOBBY_GetNumberOfKnownUsers() ;
   scanKeys() ;
   if (keysDown() & KEY_DOWN)
   {
      selected++ ;
   }
   if (keysDown() & KEY_UP)
   {
      selected-- ;
   }
   if (max > 0) selected %= max ;

   // Send 200 bytes of data
   if (keysDown() & KEY_A)
   {
      static int dataID = 0;
      char data[200];
      char string[256];

      memset(data, dataID, 200);

      sprintf(string, "\x1b[8;%dHX", dataID);
      printf(string);

      if (keysHeld() & KEY_B)
         LOBBY_SendToUser(LOBBY_GetUserByID(selected), 0x8000, (void*)data , 200) ;
      else
         LOBBY_SendToUser(LOBBY_GetUserByID(selected), 0x0001, (void*)data , 200) ;

      dataID = (dataID + 1) % 32;
      sent += 200;
   }

   printf("\x1b[7;1dHrecv: %d send: %d ", received, sent);

   /* display all users */
   int i ;
   printf("\x1b[0;0H") ;
   for (i = 0;i<max;i++)
   {
      LPLOBBY_USER user = LOBBY_GetUserByID(i) ;
      if (i==selected)
      {
         printf("->%s (%s) \n",LOBBY_GetUserName(user),LOBBY_IsTimedOut(user)?"TIMEOUT":"OK") ;
      } else
      {
         printf(" %s (%s) \n",LOBBY_GetUserName(user),LOBBY_IsTimedOut(user)?"TIMEOUT":"OK") ;
      }
   }

   swiWaitForVBlank() ;
}
return 0;
}

_________________
<dsFont> <Game Collection>

It is in the todo list since i first implemented the acknowledging

Code:

// ToDo: need to implement a way to prevent double receiving due to resending of non acked
// data

I guess the priority of this has just increased ;)
The lib currently doesn't remember which messages have been received. And i am unsure what amount of messages to remember as received (hword each) per user would be suitable. Maybe i can limit it by "all messages that are not older then x vblanks"
_________________
GBAMP Multiboot

I've updated my archive for the people wanting to test it out.

Some new feedback:
* Custom IPC messages works nice. You forgot to pipe it through on the Arm9 side though.
* The CPU doesn't block on Arm7 when calling LWIFI_IPC_UpdateNOIRQ anymore. Great!
* In the updated version the normal wifi-stuff even works as long as you don't initialize the ad-hoc wifi by pressing a room icon. Yay!
* You forgot to declare LOBBY_Shutdown in lobby.h

Other than that, things seem to work as before. I'm still don't receive about 20% of the messages, which is the primary problem for me. I looked at the room functions, but I didn't really get how they were supposed to work since you don't seem to get an ID after creating one. I guess I could get the room by sending in myself as a user, but I guess that is not how it is supposed to work?

Edit: By the way. Are you supposed to reserve a stream-id for your application?
_________________
http://www.collectingsmiles.com/colors & http://www.collectingsmiles.com/hyena

Mighty Max wrote:

I have also added a callback (see IPC_SetCustomCallback) for all IPC messages that are not handled by the lib. This way you can use the included IPC for transfering custom data. Be sure that the lobby is initiated first.

Err. I just saw the last sentence. I don't do that and it still works. Do I do anything wrong? :)
_________________
http://www.collectingsmiles.com/colors & http://www.collectingsmiles.com/hyena

Jesse wrote:

Some new feedback:
* Custom IPC messages works nice. You forgot to pipe it through on the Arm9 side though.

Thanks. Fixed.

Quote:

* The CPU doesn't block on Arm7 when calling LWIFI_IPC_UpdateNOIRQ anymore. Great!
* In the updated version the normal wifi-stuff even works as long as you don't initialize the ad-hoc wifi by pressing a room icon. Yay!

:)

Quote:

* You forgot to declare LOBBY_Shutdown in lobby.h

The Shutdown has not been done now. There only is this unworth placeholder.

Quote:

Other than that, things seem to work as before. I'm still don't receive about 20% of the messages, which is the primary problem for me.

I will work on it this weekend.

Quote:

I looked at the room functions, but I didn't really get how they were supposed to work since you don't seem to get an ID after creating one. I guess I could get the room by sending in myself as a user, but I guess that is not how it is supposed to work?

You can only be in one room at a time. After you have received the userinfo callback USERINFO_ROOMCHANGE, you can retreive the own room with the ID = ROOMID_MYROOM or with LOBBY_GetRoomByUser with yourself (USERID_MYSELF)

Quote:

Edit: By the way. Are you supposed to reserve a stream-id for your application?

Well, you should be carefull when you send to stations you don't know. I was planning to add a game/appcode to the rooms to identify those who will follow the same concepts (And thus will know what which id is for them)

Quote:

Do I do anything wrong? :)

Nope. I was sleepy and din't want to add troubles by something i forgot to mention. The complete init was the safest way to say be sure to have the IPC iniated.
_________________
GBAMP Multiboot

Could you check multiple and loss packet receive out again please?

I have added a basic multiple filter (remembering the last 20 IDs received per user) and something i *think* will stop the packet loss.
_________________
GBAMP Multiboot

It seems that almost all messages are now received exactly 2 times, some one time. I also got a "Transfer error 2!" in my code on one DS (but I don't know if that is due to the update).
_________________
<dsFont> <Game Collection>

What is a "Transfer error 2"?
_________________
GBAMP Multiboot

Mighty Max wrote:

Could you check multiple and loss packet receive out again please?

There is no difference for me as far as I can tell. I still drop about 20% for small bursts, and it seems to increase to almost 50% while sending a 4 byte packet each vblank.
_________________
http://www.collectingsmiles.com/colors & http://www.collectingsmiles.com/hyena

My code from above outputs "Transfer Error 2!" when the content of a received packet does not match what should be received (every byte in a single packet should have the same value):

Quote:

for (i = 1; i < 200; i++)
{
if (data[0] != data[i])
{
printf("\x1b[6;1HTransfer error 2! ");
return;
}
}

Packet loss with the 0x8000 stream is for me about 1%:
One DS sent 44800 bytes, the other received 44400.
_________________
<dsFont> <Game Collection>

@Jesse,

ok thanks. I'll try to reproduce it.

@ThomasS,
Ahh. That sounds like i should re-think about how to determinate a packet was completely sent before filling the buffer again. Actually it seems that the current method changes the content of a packet with a new one while it is still in sending state in the TXSLOT ... interesting.

:edit: the more i think about it, the more i think that this might actualy the root of both problems:
Given the situation of two packets A,B are sent, and the corruption happens just after the messageID of packet A, the content of packet B is sent under the ID of A. Resulting in sending twice the content of B, but never the one of A. Unless the corrupted one gets rerequested.
_________________
GBAMP Multiboot

I have hopefully fixed the TX corruption. *pressing thumbs*

Learned: The TX-Enable bit in the TX Slot hw-register is cleared already before the packet is through.

:eidt:
Learned TXINFO register is also not useable for it. Changed to reg 0x0B6 (TXBUSY in gbatek)

:edit^2:
I am now receiving also twice in about 10% of cases.
_________________
GBAMP Multiboot

Crash and burn with the latest code. I'm not sure what happens but only a few packages goest through and the program seems to crash. A guess would be that the arm7 locks up, since it still prints out other arm9 debug info even though the program is unresponsive. Also, the example.nds prints out hex-numbers for a while if I press the buttons, but also stops responding after a few presses.
_________________
http://www.collectingsmiles.com/colors & http://www.collectingsmiles.com/hyena

I found this too. And have updated the SVN after the post was created. (At the :edit:)

I have modified the example localy to reproduce your problem, and it seems that the loss might related to the IPC code. (i.e. arm7 malloc failing) i'll try to resolve this by a feedback on the IPC send (ala OK malloc succeeded -> continue)
_________________
GBAMP Multiboot

OK, one of the problems was just plain stupid by me. (The double receive)
However i still didn't find the reason for the loss of frames, but im searching.

:edit: an update on the missing packets problem
There seems to be a problem with the packet IDs. Somehow wrong values are set, and i am currently trying to figure out why. This looks like the reason for the loss, as this is making the acking *MOO* ;)

:edit^2:
Traced it further :removed:

:edit^3:
Ok. tracked one thing down. There was a situation where a ack wait would be overwritten, thus probably not be requested again. However there seems to be another thing, that leaves some data not to be acked and endlessly rerequested.
_________________
GBAMP Multiboot

OK, missing packets have been resolved (i think)
One typo, one missing assignment. Total number of involved characters in this problem: 23 (evil!)

Please note: Alltho now every packet is received in acked streams, it does not mean that they come in-order. The last sent message might be received first in the worst case.

Reordering will be done later. For today i close the DS.
_________________
GBAMP Multiboot

I just found this topic today and nearly fell out of my chair. This is awesome! Thank you so much for working on this. To think at long last we will start seeing homebrew ad-hoc DS apps makes me giddy. Thank you so much! ^_^
_________________
Cobalt/Black NDSL
CycloDS Evolution (firmware 1.55 BETA 3) and EZFlash 3-in-1
Kingston SD-C02G JAPAN 2GB MicroSD
MoonShell 1.71, DSOrganize 3.1129, QuakeDS Pre3, ScummVM DS 0.11.1, Pocket Physics 0.6, OpenTyrian DS 0.3

Thanks for the heads up :)

The SVN (revision 40) has been updated with OOO-Management. Meaning that all packets in acked streams should be received in the same order they are sent. The ordering is done per user.
_________________
GBAMP Multiboot

All data is received without duplications now. Nice!
But there is some new problems. There seems to be a lot of lag. Small data bursts (meaning small strokes in Colors!) seems to go through with up to a second lag. Bigger strokes seems to lock things up much more. The sender seems to block if the receiver gets too far behind (somewhere around 50 bytes in the outgoing buffer). This happens becuase the receiver seems to choke with bigger data blocks, and can later be released after up to 20 seconds.

Edit: It's reproducable on the example-app as well if you mash all four buttons at the same time.
_________________
http://www.collectingsmiles.com/colors & http://www.collectingsmiles.com/hyena

Yes i know.
There is a lot of optimizing place. However sending on each vblank might allways get troubles, as packets (Resends & normal sends) accumulate because the resends/updates are done on vblank too.

I will optimize the order resends are send out, and drop of equal message sends (when a resend is to bedone while there is still one in the send queue) This should reduce the problem.

Nevertheless, sending bursts of few bytes packets is a lot of wasted overhead ;)
_________________
GBAMP Multiboot

I have changed the worst things (still some remaining) so that the lag should be reduced by a good amount.
_________________
GBAMP Multiboot

Hmm. There was no improvement as far as I can see. The sender still blocks, and there is a big delay on receiving. Basically, for each input in my program (which is read after vblank), I broadcast the draw command which is a block of 4 bytes. What I see on the receiver is that it receives some data and then usually lag out on the few last commands. The common behaviour for example a 5 vblank stroke is that I receive the 4 first commands really fast and the last one after 2 seconds. I understand that the way I send data may not be optimal on the low-level network side, but it's good from my perspective to send things out as soon as possible, since I (in theory) get minimal latency.
_________________
http://www.collectingsmiles.com/colors & http://www.collectingsmiles.com/hyena

- I have disabled the IPC-Feedback again, in the hope that this might be the cause in your app (It was reducing bandwidth of the IPC)
- I have increased the interval until a packet is resend. This should also reduce the piling up problem, on the cost of 32ms / resend retry.

Quote:

I broadcast the draw command

LOBBY_Broadcast should not work on acked streams at all.

If you send the 4 Bytes only, i think the lag will never be reduced to a level you are not recognizing it by getting two different images. The sending DS will allways execute the command before the receiving DS. Both images will be drawn slightly difference each time.

I'd recomment using timestamps to the commands, so that both DSes will execute the commands coming from different sources in the same order.
_________________
GBAMP Multiboot

Don't mean to hijack this topic or anything,
but I have a problem with SVN.(I have a Win98 and XP)

I can't find any SVN clients.
The graphical Win32 project,(Tortoise)
dosen't work on either of my computers.

The offical command-line
binarys seem to work.
But,
I don't want to use that.

Obviously,
since I can't access SVN,
I can't test and use the examples and library(s).

As for this project:

Download Play is one of the things
that should be on the to-do list.

Of course,
it dosen't need done untill after
these problems are fixed.(lag and ect)

To do this,
there would need to be a way
to have the library users
able to customize the value of the framehead,
sequence number, and other vars.

Also,
there would need to be a way
for the lib users
to send out an ACK.

I am using TortoiseSVN with the repository, so it should work.

The lib is not meant to be compatible with the official download & play games. There are other projects that are trying exactly this (See Juglak's WMB)

However it should be no problem to provide the homebrew binary in a room, so that a player can join a game after downloading the image.
_________________
GBAMP Multiboot

Mighty Max wrote:

- I have disabled the IPC-Feedback again, in the hope that this might be the cause in your app (It was reducing bandwidth of the IPC)

- I have increased the interval until a packet is resend. This should also reduce the piling up problem, on the cost of 32ms / resend retry.

Yes. It works much better now. The problems are still there though, with the sender starting to slow down (small blocks I guess) after stress sending for more than a second. Also, the receiver behaves as before but to a less extent, with the last packages almost always lagging behind a second or so. A future feature-request would be to have a non-blocking mode where a SendToUser command may fail if the outgoing buffer is full (if that is what happens).

Mighty Max wrote:

I broadcast the draw command

Sorry, my mistake. I use LOBBY_SendToUser.

Mighty Max wrote:

The sending DS will allways execute the command before the receiving DS. Both images will be drawn slightly difference each time.

Of course. I've been thinking of how the syncronization should be done best but I've not picked a direction yet. But that's my problem. :)

Mighty Max wrote:

If you send the 4 Bytes only, i think the lag will never be reduced to a level you are not recognizing it by getting two different images. .

I've been thinking on this some more, and it should be possible for me to buffer the data on the sender, without getting any noticably higher latency. Any recommended packet-sizes in mind?
_________________
http://www.collectingsmiles.com/colors & http://www.collectingsmiles.com/hyena

Quote:

A future feature-request would be to have a non-blocking mode where a SendToUser command may fail if the outgoing buffer is full (if that is what happens).

What happens there is that the sender checks the message buffer if the message to place in there next is already in the message buffer. That it slows down so much is a sign, that the messagebuffer grows big.

If i would allow a send to fail, we'd just have an eqal to unacked streams.

Jesse wrote:

Mighty Max wrote:

If you send the 4 Bytes only, i think the lag will never be reduced to a level you are not recognizing it by getting two different images. .

I've been thinking on this some more, and it should be possible for me to buffer the data on the sender, without getting any noticably higher latency. Any recommended packet-sizes in mind?

Well, i was already thinking on merging messages while they are in the send queue if they belong to the same user, reducing the overhead. If that is done, the size shouldn't matter, as many small packets would share the costs of overhead.

In numbers:
The 802.11 frame header and FCS is 28 Bytes. The 802.3 snap 8 Bytes and the lobby adds another 8 Bytes. So that the data sent by the sender is 44 Bytes + payload. The receiving DS returns an ack which payload of 8 Bytes.

Total transfered bytes = 44 + 52 + payload Bytes

So that with 4 Byte payloads we have a overhead:payload ratio of 24:1
_________________
GBAMP Multiboot

Mighty Max wrote:

If i would allow a send to fail, we'd just have an eqal to unacked streams.

Well, the idea was that I would know it had failed and could resend it later without stalling the whole program, but it may not be relevant if it's not really blocking and is just taking time.

Mighty Max wrote:

Total transfered bytes = 44 + 52 + payload Bytes

Ok. I'm starting to see what you are getting at. :)
By the way. What kinds of transfer-speeds do you think we will be able to get?
_________________
http://www.collectingsmiles.com/colors & http://www.collectingsmiles.com/hyena

Thank's Mighty,
I tried downloading and installing again,
and this time it worked!

Sorry,
I didn't know this lib isn't mean't
to use download play.

I was wondering about transfer speeds,
too.

EDIT:
How do I download everything?(on this respistory,
with the aforemetchioned program)
(Minus the source)

I have no idea about the bandwidth yet.
It might even be, that the IPC limits the bandwidth more then the actual wifi.

@yellowstar: the only binaries in the SVN is the lib itself (liblobby7d.a / liblobby9d.a). Use make to build the example. Make sure devkitpro will find the includes/libs

I think i have a good idea how to allow many short messages with much less overhead. The plan is to not put the packets into the send queue directly, but using the resend at vblank to combine small packets that are collected in the need-to-be-acked cache into larger ones (using multiple lobby-chunks in one snap frame)

Today campus-life starts again, so it can take a bit ;)
_________________
GBAMP Multiboot

I think I've found more problems:
- Try my code from above, send one or more unreliable messages (by holding B while pressing A), then no more reliable message (sent by pressing A) is received (but still unreliable messages).
- If only sending reliable messages, after ~1 1/2 rows of "X" it gets slower until it almost stands. This happens only if you send from both DS at the same time and hit the button relatively fast. Perhaps this is the result of too much re-sending if I understand it correctly that you just filter double messages out instead of reducing the amount of re-sends.

I'm using revision 45.
_________________
<dsFont> <Game Collection>

ThomasS wrote:

I think I've found more problems:
- Try my code from above, send one or more unreliable messages (by holding B while pressing A), then no more reliable message (sent by pressing A) is received (but still unreliable messages).

This sounds like one of the DSes went shortly into a timeout. would not yet reset the OOO-processing on the opposing side, resulting in a long wait for the next expected msg, but allways receives the packetIDs from the start again. (Or the other way around)

Quote:

- If only sending reliable messages, after ~1 1/2 rows of "X" it gets slower until it almost stands. This happens only if you send from both DS at the same time and hit the button relatively fast. Perhaps this is the result of too much re-sending if I understand it correctly that you just filter double messages out instead of reducing the amount of re-sends.

This slowdown can be massively reduced by hashing the messages, so that the comparison gets _much_ faster (espacially if all messages are of the same length). But i think i will go a different way anyways, but this will take a bit atm. Need to catch a good start on campus right now.
_________________
GBAMP Multiboot

I have found out I need to use save as and export for downloading.

I have found some bugs.

That crash error is back.(the exception(white text on red background))
Pressing Select causes it.

I tested with two original DSes.(didn't know were the Lite was,
will test again with it later)

When I started pressing two keys on one DS,(A and B)
eventually there was a difference between
the sent and received numbers on both systems.
This difference was 2.

When I started pressing 4 keys on one DS,
eventually the difference went upto 3,
but eventually it went backto 2.

I have tested with all systems.(both originals and a Lite)

My one DS quit receiving from the other DSes after
I mashed all the buttons for a little bit.

When the R key is held down,
the system says the message
was sent, but it isn't received on the target DS.

The 2 message difference was probably caused
by the 2 messages sent at the start of the program.

The rest of the difference could have been caused
by holding down R.

In the latest SVN there are still some problems with the transmit. This turns out to be a bit more difficult then it looks in the first place. This results in a lot more problems dropped at sending as needed to, espacially if they are going out in short time.

The worst stupidity bug in there resulting in doublte transmitting of some and dropping some other packets is fixed in the SVN. This however does not fix your described problems yet.

I will also need to test IPC performance. More and more i think a lot of trouble is caused there...
_________________
GBAMP Multiboot

Some interesting numbers on the IPC subsystem.

IPC Performance Test
Test A (100 frames each, active filling & irq triggered)
Framesize - kB/s

8 => 195.3kB/s
16 => 390.6kB/s
32 => 520.8kB/s
64 => 694.4kB/s
128 => 694.4kB/s
256 => 609.8kB/s
512 => 171.2kB/s
1024 => 155.5kB/s

(Notes: The higher speed of the 16-256Byte frames is most likely due to cache. The slow speed of 8, 16 compared to the other small packets is - i think - due to the overhead/payload ratio, as every frame is prefixed by 4 Bytes)

Test B (100 frames each, IRQ triggered filling only)

8 => 97.7kB/s
16 => 120.2kB/s
32 => 135.9kB/s
64 => 142.0kB/s
128 => 145.3kB/s
256 => 147.9kB/s
512 => 148.4kB/s
1024 => 145.1kB/s

These numbers are after a fix in the IPC system. Completely unpolled IPC transfers in the SVN atm has a speed of 0.0kB ;) but i can only commit this patch when the other code giving me troubles atm is fixed too.

At least it shows, that the IPC shouldn't be the bottleneck (yet)
_________________
GBAMP Multiboot

The SVN has had a huge update.

Larger bursts still cause problems (from delay to syncing out=stopped receive) when the messageamount per vblank tops the collector's size, but short bursts did not cause any problems anymore on my testing setup.

Short bursts in this case are bursts with (messageCount * 8 + sizeof(4-Byte-padded-payloads)) < 500

Some of the problems are still caused by the transmit routines. When sending from a system i know that works perfectly (ralink) the lobby responds instantly even on long bursts, so that i have to assume that i am still harvesting problems there.

I.e. i don't really understand why the wait for WIFI_TXBUSY bits to clear causes a complete lockup (the busy bit never resetting)
_________________
GBAMP Multiboot

I tried the update and it's much better. It's seems to be more responsive and as you say, short bursts are usually transmitted almost instantly.

I still have the receiver choking up after a while and I noticed something strange. If I turn off the sender when the receiver have started to choke the data still keeps dripping in. I got one or two packets each second for 20 seconds. I'm not sure if that is what you expected. :)
_________________
http://www.collectingsmiles.com/colors & http://www.collectingsmiles.com/hyena

Jesse wrote:

If I turn off the sender when the receiver have started to choke the data still keeps dripping in. I got one or two packets each second for 20 seconds. I'm not sure if that is what you expected. :)

Actually this is VERY interesting. Thanks for the report.
Think i'll need to enhance the IPC testcases when i return from the courses today.
_________________
GBAMP Multiboot

It seems that there are actually a lot of things going wrong at the IPC level.

There was another stupid bug fixed in the CVS, and a workaround for troubles i need to still find the reason.

This should make larger bursts work better.
In a short test, a continous send of 11 bytes payload every vblank failed not before the 1597th packet, which is a good improve against the previos reaction to vblank sending.

As i now know where the problem got to be, the next problems should be solveable. However, i still need to find the actual missprogramming/typo.
_________________
GBAMP Multiboot

I tried the update. The receiver seems to instantly stop receiving and/or crash randomly. Also, once an IPC message was passed to the CustomCallback on Arm9 without me sending it.
_________________
http://www.collectingsmiles.com/colors & http://www.collectingsmiles.com/hyena

There has been a new IPCTAG_ECHO that will return the packet to the arm9 instantly, and cause a callback if it gets received again. If you used this number as an own tag, this might have caused the unexpected receive.

Because of the bug that has to be somewhere in the IPC, sending custom IPC messages might trigger it too, causing the crashes. If you could post me the Register content the of pc,lr and the stackvalues on the crashes (red screen of death) together with the .map file (strip the things you don't want to share), this would help alot to locate the failing code
_________________
GBAMP Multiboot

Mighty Max wrote:

There has been a new IPCTAG_ECHO that will return the packet to the arm9 instantly, and cause a callback if it gets received again. If you used this number as an own tag, this might have caused the unexpected receive.

Nope. I only use commands going from 0xf0 - 0xf4.

Mighty Max wrote:

Because of the bug that has to be somewhere in the IPC, sending custom IPC messages might trigger it too, causing the crashes.

I'm not sending any custom message during this time, so that's not it.

Mighty Max wrote:

If you could post me the Register content the of pc,lr and the stackvalues on the crashes (red screen of death) together with the .map file (strip the things you don't want to share), this would help alot to locate the failing code

I have no idea how to do that, sorry. I've never bother with trying to get any kind of debugger up and running.
_________________
http://www.collectingsmiles.com/colors & http://www.collectingsmiles.com/hyena

Jesse wrote:

Mighty Max wrote:

If you could post me the Register content the of pc,lr and the stackvalues on the crashes (red screen of death) together with the .map file (strip the things you don't want to share), this would help alot to locate the failing code

I have no idea how to do that, sorry. I've never bother with trying to get any kind of debugger up and running.

Take a look in the folder your arm9 build-files are in. There should be a file with the ending .map which just tells what info is stored at which place in ram.

On the red crash-screen, the registers are labeled. Just manually copy & paste ;)

This way i can see which function is crashing, and out of which context it is called. I have tried my best to provoke a crash in the examples but i couldn't reproduce it yet.
_________________
GBAMP Multiboot

Mighty Max wrote:

On the red crash-screen, the registers are labeled. Just manually copy & paste ;)

I'm always running on actual hardware, so I'm not sure what you mean. I've never seen a red crash-screen.
_________________
http://www.collectingsmiles.com/colors & http://www.collectingsmiles.com/hyena

OK. that's no problem.

If you wondering what i'm on about (and this might help you too maybe)
When running on the hardware, set an exception handler i.e. by "defaultExceptionHandler();". Whenever a memory location is accessed (code read, data read, data write) what does not exist, the DS will then show the red screen showing what happened where, instead of just crashing. This works for the arm9 only, because of the cp15 memory protection unit which is not present on the arm7.
_________________
GBAMP Multiboot

Well there you go! For once I've spent too much time working on the actual application and not the toolset behind it. :)

EDIT: Ok. It seems like there is no arm9 exception generated. I can easily get the receiver to lock up (or at least stop generating input) after around a 100 4-byte packages. When the receiver is locked up and if I continue to send data the sender goes slower and slower until it locks up as well.
_________________
http://www.collectingsmiles.com/colors & http://www.collectingsmiles.com/hyena

I finally got the time needed and started testing with the library... One obvious thing that came to my mind: Shouldn't there be a flag or an option for broadcasting your own ID? From the traditional server-client point of view what is needed is that only server broadcasts it's id while it's accepting new users and clients connect to the server only. Currently LOBBY_Update() is broadcasting every 1/6 second (assuming it's called in vblank), right?

In other words, what I'm after on a library level:
- Server: LOBBY_CreateRoom(), start broadcasting now
- Client 1-n: see only server broadcasting, LOBBY_JoinRoom()
- Server: when max. users have joined to room, stop broadcasting OR if we decide that we're e.g. starting a game, stop broadcasting manually

Perhaps this could be as an alternative to the current "all users broadcast all the time" approach? LOBBY_StartBroadcast() / LOBBY_StopBroadcast() or passing a flag to LOBBY_Update()?

PS. MessageQueue.h is still missing #ifdef __cplusplus... I don't like SVN merging files all the time. :)

Well the transport layers (802.11, the lobby-message-delivery) are peer-to-peer and can not that easily be exchanged against server-client designs in a mobile environment without troubles.

If something goes wrong (noise, distance etc) with the "server" at session level only this one session will stop working. If the server/client design is implemented at the transport layers (broadcasts), the whole network will go down, which is something i want to prevent. If two groups are playing beneath each other i don't want that if group A stops playing (thus stops the server) will break group B's game.

The current design of the arm9 triggered broadcasts will be a thing to be changed for automatic broadcasting via beacon slot. But i will still need to broadcast the user's presence and capabilities (Just like in real 802.11 ad-hoc mode every station beacons)
_________________
GBAMP Multiboot

Ok. You have valid points there. Although I don't see how two groups playing at the same time would break each others games. Each game has of course an own server as the DS starting the game acts like it.

Well, it's easy to disregard the unneeded broadcast messages in user code, so this isn't a problem of any sorts.

melw wrote:

Although I don't see how two groups playing at the same time would break each others games. Each game has of course an own server as the DS starting the game acts like it.

The lower layers (where the broadcast is needed for) does not know about games. A hierarchy would therefor apply to all or none.

The layer for the rooms actually does allready act the way (only server broadcasts) you suggested btw. Only if the DS is a room-Owner, the room-info are appended to the broadcast.
_________________
GBAMP Multiboot

Maybe i should do a clean restart.

I already thought about doing some more checks on what which hardware register does and the meaning of some flags. When i arrive home today, lynx's great help should have arrived that makes this possible.
_________________
GBAMP Multiboot

Could you also make a small example of how rooms should be used? Browsing the library source gives some idea, but I still fail to do something as simple as listing the available rooms.

Edit: Having slept over this, I realized how the user callback works. Here's a small room example that works otherwise, but the room owner never realizes that there's a room (even if you try to join manually (SELECT) and send messages to a room (X & Y)). Any pointers on what I'm doing wrong here?

Code:

#include "nds.h"
#include <nds/arm9/console.h> //basic print funcionality
#include <stdio.h>

#include "safe_malloc.h"
#include "MessageQueue.h"
#include "802.11.h"
#include "lobby.h"
#include <fat.h>
#include <malloc.h>
#include <string.h>

LPLOBBY_USER roomOwner = NULL;

void VBlankIRQ(void)
{
REG_IF = IRQ_VBLANK ;
IPC_RcvCompleteCheck() ;
LOBBY_Update() ;
}

void receiveUser(unsigned char *data, int length, LPLOBBY_USER from)
{
printf("user msg %s: %s\n", LOBBY_GetUserName(from), (char*)data);
}

void receiveRoom(unsigned char *data, int length, LPLOBBY_USER from)
{
printf("room msg %s: %s\n", LOBBY_GetUserName(from), (char*)data);
}

void userCallback(LPLOBBY_USER user, unsigned long reason)
{
switch(reason)
{
   case USERINFO_REASON_REGOGNIZE:
      printf("user callback: %s recognized\n", LOBBY_GetUserName(user));
   break;
   case USERINFO_REASON_TIMEOUT:
      printf("user callback: %s timeout\n", LOBBY_GetUserName(user));
   break;
   case USERINFO_REASON_RETURN:
      printf("user callback: %s returned\n", LOBBY_GetUserName(user));
   break;
   case USERINFO_REASON_ROOMCREATED:
      printf("user callback: %s created a room\n", LOBBY_GetUserName(user));
      roomOwner = user;
   break;
   case USERINFO_REASON_ROOMCHANGE:
      printf("user callback: %s changed a room\n", LOBBY_GetUserName(user));
   break;
}
}

int main(void)
{
REG_EXMEMCNT=0xe800;

powerON(POWER_ALL);
REG_IME = 0 ;
REG_IE = 0 ;
REG_IF = 0xFFFF ;

videoSetMode(0); //not using the main screen
videoSetModeSub(MODE_0_2D | DISPLAY_BG0_ACTIVE); //sub bg 0 will be used to print text
vramSetBankC(VRAM_C_SUB_BG);

SUB_BG0_CR = BG_MAP_BASE(31);

BG_PALETTE_SUB[255] = RGB15(31,31,31); //by default font will be rendered with color 255

//consoleInit() is a lot more flexible but this gets you up and running quick
consoleInitDefault((u16*)SCREEN_BASE_BLOCK_SUB(31), (u16*)CHAR_BASE_BLOCK_SUB(0), 16);

defaultExceptionHandler() ;

irqInit() ;

// Startup IPC engine
IPC_Init() ;
IPC_SetMsgCompleteCallback(&IPC_RcvCompleteCheck) ;

// usual VBlank
irqSet(IRQ_VBLANK,&VBlankIRQ) ;
irqEnable(IRQ_VBLANK) ;

consoleClear() ;

int selected = 0 ;

LOBBY_Init() ;
LOBBY_SetStreamHandler(0x0001,&receiveUser);
LOBBY_SetStreamHandler(0x0002,&receiveRoom);
LOBBY_SetUserInfoCallback(&userCallback);

printf("init done\n");

while (1)
{
   /* handle input */
   int max = LOBBY_GetNumberOfKnownUsers() ;
   scanKeys() ;
   if (keysDown() & KEY_DOWN)
   {
      selected++ ;
      if (max > 0) selected %= max ;
      printf("selected [%d]: %s\n", selected, LOBBY_GetUserName(LOBBY_GetUserByID(selected)));
   }
   if (keysDown() & KEY_UP)
   {
      selected-- ;
      if (max > 0) selected %= max ;
      printf("selected [%d]: %s\n", selected, LOBBY_GetUserName(LOBBY_GetUserByID(selected)));
   }
   if (keysDown() & KEY_START)
   {
      printf("create room\n");
      LOBBY_CreateRoom("LOBBY",8);
      roomOwner = LOBBY_GetUserByID(USERID_MYSELF);
   }
   if (keysDown() & KEY_A)
   {
      printf("send a to user %s\n", LOBBY_GetUserName(LOBBY_GetUserByID(selected)));
      LOBBY_SendToUser(LOBBY_GetUserByID(selected),0x0001,(unsigned char *)"Key [A] pressed.",17) ;
   }
   if (keysDown() & KEY_B)
   {
      printf("send b to user %s\n", LOBBY_GetUserName(LOBBY_GetUserByID(selected)));
      LOBBY_SendToUser(LOBBY_GetUserByID(selected),0x0001,(unsigned char *)"Key [B] pressed.",17) ;
   }
   if (keysDown() & KEY_X)
   {
      if(roomOwner!=NULL)
      {
         printf("send x to room %s\n", LOBBY_GetUserName(roomOwner));
         LPLOBBY_ROOM room = LOBBY_GetRoomByUser(roomOwner);
         LOBBY_SendToRoom(room,0x0002,(unsigned char *)"Key [X] pressed.",17) ;
      }
   }
   if (keysDown() & KEY_Y)
   {
      if(roomOwner!=NULL)
      {
         printf("send y to room %s\n", LOBBY_GetUserName(roomOwner));
         LPLOBBY_ROOM room = LOBBY_GetRoomByUser(roomOwner);
         LOBBY_SendToRoom(room,0x0002,(unsigned char *)"Key [Y] pressed.",17) ;
      }
   }
   if (keysDown() & KEY_SELECT)
   {
      if(roomOwner!=NULL)
      {
         printf("join room hosted by %s\n", LOBBY_GetUserName(roomOwner));
         LPLOBBY_ROOM room = LOBBY_GetRoomByUser(roomOwner);
         LOBBY_JoinRoom(room);
      }
   }
   swiWaitForVBlank() ;
}

return 0;
}

Wotcha, I just checked out and built the example, but I still ain't getting a single packet received by either of the DS' I tested...
Since I could be messing up the build process, reckon you could send me a pre-built nds that I could try?
_________________
Big thanks to everyone who donated for Quake2

melw wrote:

Could you also make a small example of how rooms should be used? Browsing the library source gives some idea, but I still fail to do something as simple as listing the available rooms.

Edit: Having slept over this, I realized how the user callback works. Here's a small room example that works otherwise, but the room owner never realizes that there's a room (even if you try to join manually (SELECT) and send messages to a room (X & Y)). Any pointers on what I'm doing wrong here?

You are doing wrong nothing.

The room creator is instantly roommember #0. It is not (yet) causing a callback. I was in the middle of implementing rooms when the receive problems started, so the knife is still sticking in the room-code ;)

SendToUser, SendToRoom etc are never received by the sender.

There are a lot of things missing here, including the gameid for the room, leaving/destroying rooms, etc.

@simon: I have uploaded the example to http://mightymax.org/example.nds .
_________________
GBAMP Multiboot

Still nothing :-(
Is there something that I should be doing? I'm running it on one DS with my M3 Simply, unplugging it, plugging it into another DS and turning it on, then jabbing all the buttons on each DS. I've tried using my other flash cards too, no difference.
One thing I've noticed that when I run it on my gbamp when the program starts it says 0 packets received, 0 packets sent. When I start it on the M3 it always says 0 packets received, 2 packets sent. Uh...
_________________
Big thanks to everyone who donated for Quake2

Hmm, that is weird.
Does the normal wifi-stuff work for you?

Does anyone else have problems receiving anything?
_________________
GBAMP Multiboot

Yeah, normal wifi works fine for me, plus Phusson's original test program (which hung up after a few messages) worked too...
_________________
Big thanks to everyone who donated for Quake2

The postman just arrived.

I can confirm, that on the M3 Simply (equal to R4DS) the sent packets number starts at 2. I'll investigate why that is. But it is receiving the other station.

I'll check if i can come up with some explanation why it does not work for you/ or a test to show find the difference causing the problem.
_________________
GBAMP Multiboot

Err, more interestingness - we got all the DS' in my house together, and they all work fine! In fact the two DS' that I have worked fine when it was just them running....so I go upstairs...and they no longer work. Uh-huh.
It seems that the closer I get to the wifi antenna on my computer the worse the connection gets. Is this to be expected?

Ten seconds later I get a call up the stairs "is your Internet connection working?" :-)
_________________
Big thanks to everyone who donated for Quake2

Erm, ooookay.

The protocol shouldn't interfere with regular 802.11 nodes, but depending on the traffic that is allready in the air ...

Try using a different channel. There is no function for this yet, but you can change it by modifying the channel=7 line in LOBBY_Init()
_________________
GBAMP Multiboot

Ah, interesting. Ok my home's wifi seems to be running on channel 9. If I remember 802.11 from uni, channel 7 and channel 9 overlap - right? I changed the channel to 1 and and it worked first time! Any chance of you exposing the channel number in lobby_init()?
When I was using channel 7 I was occasionally getting a runaway detection of packets on one of my DS when it was near my AP. I had assumed it was picking up packets from that, yet when I turned off the second DS the runaway on DS #1 would stop.

One thing I have noticed is that often an 'extra' DS will be detected, when there isn't one. The further away you go the more fake DS' appear. Can anything be done about this?

Again kudos on the good work done here :-D
_________________
Big thanks to everyone who donated for Quake2

simonjhall wrote:

Ah, interesting. Ok my home's wifi seems to be running on channel 9. If I remember 802.11 from uni, channel 7 and channel 9 overlap - right? I changed the channel to 1 and and it worked first time! Any chance of you exposing the channel number in lobby_init()?
When I was using channel 7 I was occasionally getting a runaway detection of packets on one of my DS when it was near my AP. I had assumed it was picking up packets from that, yet when I turned off the second DS the runaway on DS #1 would stop.

I wanted to test on LOBBY_Init the channel with either already a DS sending on or if not, choosing the least used channel. But channel change often failed on the ralink.
Exposing the channel select shouldn't be of any problem.

Quote:

One thing I have noticed is that often an 'extra' DS will be detected, when there isn't one. The further away you go the more fake DS' appear. Can anything be done about this?

I have noticed this too again. I get "." recognized sometimes. There is evidence that this is caused by some data corruption within my code again. I'm searching.

Quote:

Again kudos on the good work done here :-D

Thanks, but right now it is in an awfull bad state.
_________________
GBAMP Multiboot

Mighty Max, I found a small bug - in LOBBY_SendToRoom() the code would never sent to any other user than the room owner:

Code:

// outside users can only send to room leader
if (room != &currentLobby->room)

Changing above line to following fixed the problem:

Code:

if (room != currentLobby->myself.room)

I don't know if this is the actual cause or result of another bug, but at least this is how I got 3 DS's in same room and sending group messages to each other working.

I've been integrating your wifi stuff into QDS and have a few questions about this lobby stuff:

- What's the difference between LOBBY_SendToAll and LOBBY_Broadcast? Neither seems to do anything for me and instead I have to do a for loop with LOBBY_GetNumberOfKnownUsers and LOBBY_SendToUser to do what I want...
- Is there any verfication of the packets that are sent? eg some kind of checksum, or should I add code to do that myself?
- I've noticed that sometimes one DS isn't noticed by the other one - is there some way to send out a message saying "I'm here, notice me!" ;-)
- do messages get sent instantly, or are they queued? If they are, how long will they live in the buffer before sent off (assuming no more data appears)?
- after I do a LOBBY_SendToUser, am I right in assuming that I can change the data after this call, since that function takes a copy of the data?

Ta :-D

Btw, doing an update every vblank is too infrequent for me, so for kicks I moved it to the hblank. However, doing this locks it up...errr....
_________________
Big thanks to everyone who donated for Quake2

simonjhall wrote:

- What's the difference between LOBBY_SendToAll and LOBBY_Broadcast? Neither seems to do anything for me and instead I have to do a for loop with LOBBY_GetNumberOfKnownUsers and LOBBY_SendToUser to do what I want...

LOBBY_SendToAll, should do exactly this: iterate through all known user and trigger a send to them. LOBBY_Broadcast will send out a message to all MACs (MAC Address "FFFFFFFFFFFF")

Quote:

- Is there any verfication of the packets that are sent? eg some kind of checksum, or should I add code to do that myself?

There is a checksum within the 802.11 frame, which is checked on receive. However there isn't one for the encapsuled data. When the sending/receive works (and not have software errors) no further verification should be needed.

Quote:

- I've noticed that sometimes one DS isn't noticed by the other one - is there some way to send out a message saying "I'm here, notice me!" ;-)

This message is broadcasted every 10th time LOBBY_Update is called.

Quote:

- do messages get sent instantly, or are they queued? If they are, how long will they live in the buffer before sent off (assuming no more data appears)?

Non-acked-Messages are sent instantly. Acked messages will be collected and sent on the next LOBBY_Update.

Quote:

- after I do a LOBBY_SendToUser, am I right in assuming that I can change the data after this call, since that function takes a copy of the data?

Yes you can. the message is appended to the needed header, and put into a cache.

Quote:

Btw, doing an update every vblank is too infrequent for me, so for kicks I moved it to the hblank. However, doing this locks it up...errr....

The timings are defined relative to the vblank atm. Meaning that broadcasting, timeouts, resending etc are fastened by 263 times, which is expected to make troubles ;)
_________________
GBAMP Multiboot

The point where the data corrupts has been found, the reason not :/

Alltho there is 0x0C00 bytes available for sent in the current setup, using tx slot #3 (0x800-0xBFF) seems to cause the problem.... disabled this slot for sending again.

I'll need to implement some handshaking (resynching the to-be-expected packetID) to fix problem of stalling after the connection timed out from one side only.
_________________
GBAMP Multiboot

This is far from finished, but as I had to take my development laptop to warranty service today (for a change), I decided to put online a small work-in-progress of Dicewars DS using Mighty's library: http://dicewars.drunkencoders.com/beta/

As stated on the linked page, this is still very much unfinished, but at least it's possible to play 2 player games. With 3 players I started to have severe timeout problems - somehow it looks like that one of the DS's (the one joining in last? not 100% sure) has more latency and starts to miss messages after a while.

I hope to be able to resume work on this soon again.

Nice :)

It works so far, that tha game is shared between the players.
But the actual game does not start then (maybe i am missing the trigger?)

---

I've found and fixed a very annoying bug btw. The irony: the better the connection the worse the lockup.
It shows that the better the connection was the less went through :p
The acks caused an ack, caused an ack .... so that after some time the whole system was busy with only sending acks over and over.
_________________
GBAMP Multiboot

Thus causing the DS itself to go *ACK* and die? Sounds like these DSes need some coughdrops so they're not acking all over each other.

Okay, I'm done now. XD
_________________
Cobalt/Black NDSL
CycloDS Evolution (firmware 1.55 BETA 3) and EZFlash 3-in-1
Kingston SD-C02G JAPAN 2GB MicroSD
MoonShell 1.71, DSOrganize 3.1129, QuakeDS Pre3, ScummVM DS 0.11.1, Pocket Physics 0.6, OpenTyrian DS 0.3

"Ack ack ack, ack ack ack ack."
-- Martians from Mars Attacks! (1996)

TFTP used to have this problem.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

A very nice movie btw. I love it :D

The ack's were not by design causing a re-ack (The chunk is placed within the no-ack streams), but a bug caused the FCS of the ack to be missread as the next chunk start, and thus sending the new ack.

Lynx's help is really starting to help a lot. Independently capturing the traffic between the now flashed second DS and the original one showed another problem. Out of one collected frame containing multiple to-be-acked chunks only two were acked ... i'll go back to trace it down now
_________________
GBAMP Multiboot

Mighty Max wrote:

It works so far, that tha game is shared between the players.
But the actual game does not start then (maybe i am missing the trigger?)

It should be possible to play games if only the amount of players is set regarding how many DS's you have in use. Set max. players value same as min. players, as remaining slots will be filled with CPU players otherwise - with missing AI code - no dice :). The game will start when minimum number of players have joined and are all marked ready (click lower right arrow or press 'A').

Works perfectly this way :) (NDSL vs NDS)

The one losing is missing a "Haha! You lost!" screen *g*
_________________
GBAMP Multiboot

I am attempting to make a 2-player pong game.

I have finished the connecting part.

It dosen't use rooms.(too incomplete)
Instead, it uses the players for connecting.

It pretends that the first player detected is
the only other player there.

This works well.(I didn't test with a third DS.)

One problem is,
the host detects all other players.(even hosts)
(I didn't test this, this is what would probably happen.)
Another thing is,
it detects the players before they choose wether
they want to be a host or client.
Obviously, it should only be after that,
and for only the clients.
(I tried to get around those problems,(the players would "broadcast" what they are(host/client),
and the players would remove all the players in te list, except for the opposite.
(client-host host-client))
(but the code for the structs wouldn't compile.)

Here's how I sync the systems for connecting.(the systems are already connected,(each has
the others LPLOBBY_USER pointer)
this is just for sync and to confirm the other is still there.)

The host sends a message to the client.(this message is same as the client's message)
The host waits on the client for the response.

The client waits for the message from the host.
Once the message is received,
it replys to the host.(it sends the same message backto the host)

They are now synced.

The problem with the way I do it is,
I have the players press A to start connecting.
(I have the giveup time for a long time,(the time it takes the player to stop sending
the message, and quit.)
but it needs to be shorter so the players know when his opponet quit.)
(It would be nice if there would be a function in the lib which would take care of this,
but that can wait till after these bugs are fixed.)

Don't expect much graphics-wise.
For the the connecting part,
it is console.

For the actual game,
it will have backgrounds and basic sprites.

After all,
the point is to see that it actually works.(this game and the lib)
And for reporting bugs otherwise.
(I might add better graphics later,
but console and better graphics wouldn't look good.)

By the way,
what does the REG_EX(E)MEMCNT
assignment do in the example?

(I'm using R 48 for this game.
(I'm not sure if this is the most recent revision.))

download
http://members.iglide.net/ticeandsons/yellowstar/yell_pong.zip
(includes the source and binarys)
(the yell stands for yellowstar)

The SVN server is back up (after crash), dunno if anyone noticed ;)

I have again reduced the load on the channel caused by a transfer stream pushing a lot of ack's (one for each chunk) onto the channel. Instead there should be a collected ack for a transfer frame of collected chunks now.
_________________
GBAMP Multiboot

Any idea of what is causing my problems? I've updated to new versions but the problem doesn't seem to change. I've updated the adhoc-test if you want to check it out.
http://www.collectingsmiles.com/colors/colors_adhoctest.rar
_________________
http://www.collectingsmiles.com/colors & http://www.collectingsmiles.com/hyena

I've just tested it between a NDSL and a NDS with a capture running on the PC:

If started on the DSL or NDSL alone, using the R4DS, the DS starts to broadcast the userinfo after the room is select.
If I start it via GBAMP on the DSL colors locks up as soon as the room is selected. No message leaves the DS.

When started both from the R4DS, it works fine in the first, but after a bit of painting, the sending of the transfer steam stops completely. Even the the packets send from the other station are not replied to. (So it is not a probelm with IDs getting out of sync)
The broadcasts will still flow.

The only reason the lobby would stop sending anything to the user would be a timeout, but as both DSes are still broadcasting their ID, there is no hint that this happens. Can you check if the users are timing out?

Another thing would be a problem with the receive on the DS that stops responding resulting in a timeout. This might be caused by a getting low on memory on the arm7.
_________________
GBAMP Multiboot

Mighty Max wrote:

The only reason the lobby would stop sending anything to the user would be a timeout, but as both DSes are still broadcasting their ID, there is no hint that this happens. Can you check if the users are timing out?

Yes, that seems to happen.

Mighty Max wrote:

Another thing would be a problem with the receive on the DS that stops responding resulting in a timeout. This might be caused by a getting low on memory on the arm7.

Seems resonable. The receiver seems to receive its messages slower and slower until it stops receiving. Still, since input is working correctly on it, the arm7 isn't locked up.

Edit: I managed to reproduce the timeout even if all data I sent managed to get through to the receiver, which seems a bit weird to me.
Edit2: Uploaded a version with the debug-log turned off, so you can see the users and timeouts. (not that it gives you any information you don't already know).
_________________
http://www.collectingsmiles.com/colors & http://www.collectingsmiles.com/hyena

I can reproduce this situation now.

Only need to find out what happens.
What i checked is the memory issue. I've made the arm7 to one-ipc-only so i am not filling the limited memory up with received dataframes and it still happens :/
_________________
GBAMP Multiboot

Got my laptop back from the warranty service (new display, yay!) Noticed that latest version has room id's, game versions and LOBBY_LeaveRoom() implemented, in other words just about everything I was lacking for my game room implementation - thanks for the update!

Unfortunately the current svn version is very unstable for me. Especially when 3rd DS powers up, one of the other DS's will crash 3/4 of the times (upper screen red, lower screen white). However no register data is printed unlike with previous crashes. And yes, defaultExceptionHandler() is being set. I also updated to devkitARM R21 + latest libnds at the same time.

I'll try to debug this more later tonight, hopefully I can isolate then a test case...

The SVN uploaded should fix a lot of the instablility.

- intermixed frames are silently dropped now, as the FCS is now created before the frame is put into the HW and the hardware FCS was disabled
- there was a function called nested in some cases (Another receive completed before a receive reply was triggered) this caused data corruption in the received frames.

I was able to complete 5 runs of an lobby example (which is not yet in the svn) transfering 150kB & exchanging 600 acked frames each. Before the last two fixes, i rarely was able to complete one run.

:edit:
After testing with bigger files (5.14MB) im observing a different problem now. I'm transfering an average of about 1MB before that happens on the receiver's side.
_________________
GBAMP Multiboot

Last edited by Mighty Max on Thu Oct 25, 2007 5:25 pm; edited 1 time in total

Mighty Max wrote:

I was able to complete 5 runs of an lobby example (which is not yet in the svn) transfering 150kB & exchanging 600 acked frames each. Before the last two fixes, i rarely was able to complete one run.

Sounds like there's quite an improvement there! Good job! Let's hope it runs fine on other's hardware as well.
_________________
http://licklick.wordpress.com

Mighty Max wrote:

The SVN uploaded should fix a lot of the instablility.

I got the timeout even sooner after this update. :/
Any ideas?
_________________
http://www.collectingsmiles.com/colors & http://www.collectingsmiles.com/hyena

Hmm, this is unexpected.

None of the changes should have a noticeable impact on the response times. It is however a bit heavier on the local memory usage of the arm9 (as each rcv callback gets it's own receive buffer, but it is free'd on leaving each callback) It shouldn't have an impact on the arm7 memory usage.

Did you update your adhoc test colors, so i can take a look?

:edit:
The problem mentioned earlier (which used to be at about 1MB) seems to be only a problem of receiving on the DS. The more traffic is on air, the faster this happens. The outgoing data remains working.
_________________
GBAMP Multiboot

Actually, i think i've found that bastard of a bug that caused the receive locking up. I'm doing some more tests before putting it on the SVN.

It seems i missed something when resetting the IF registers in the irq handler:

When resetting IF.bit24, all WIFI_IF bits needs to be deactivated at one time too. When i was receiving another frame (thus getting IF &IE !=0) while i was still processing another irq (TX complete, etc) this failed, and the wifi irq never was triggered again.

3MB transfered with no problems right now. Testing more *g*

:edit: crashed with a red screen of death, after returning from a malloc with 0 @ 3.7MB (so most likely only a mem leak in the transfer app). No problem so far, but i want to get through the complete file once before commiting
_________________
GBAMP Multiboot

Looking forward to it. Let me know if still you want me to update the adhoctest.
_________________
http://www.collectingsmiles.com/colors & http://www.collectingsmiles.com/hyena

I've commited it, as it the only crashes i could get now was the mem leak.
The memleak got to be somewhere in LOBBY_SendToUser and it's helping functions. It does not happen for small frames as far as i observed (only the DS sending 512+12 Byte chunks has this problem)

If you still get the lockups, a updated adhoctest would be good :D

:edit: the mem leak has been resolved, it was nearly holdung up a big red sign, and i still missed it on the first look-through
_________________
GBAMP Multiboot

Wonderful! It works flawless for me now. I'll better get started on getting all the features in there!
_________________
http://www.collectingsmiles.com/colors & http://www.collectingsmiles.com/hyena

I've updated the adhoctest just because I'm so happy right now. Next steps for me is to trying to figure out how to synchronize strokes properly. There is some small input stutter which probably comes from the wifi doing work on the arm7 core, but that's probably easily solved from my side. Also, I'm going to dig into doing a proper room implementation. But that's for tomorrow.
_________________
http://www.collectingsmiles.com/colors & http://www.collectingsmiles.com/hyena

Jesse wrote:

I've updated the adhoctest just because I'm so happy right now. Next steps for me is to trying to figure out how to synchronize strokes properly. There is some small input stutter which probably comes from the wifi doing work on the arm7 core, but that's probably easily solved from my side. Also, I'm going to dig into doing a proper room implementation. But that's for tomorrow.

Great!

Yes. The arm7 does get into a short blocking, when it receieves some data (it is making sure the data is sent to the arm9 before continuing) and it will wait on Sends passed from the arm9 until they are put into the HW queue.

But those were things i implemented as a "to be sure nothing happens here" and can be reversed to some degree.
_________________
GBAMP Multiboot

Excellent! Updated the svn, compiled, tested and just finished a 3 player game of Dicewars DS using the library for the first time. No crashes, no timeouts, looks like all the previous problems are gone for now. I need to still work on the game-side implementation, but now I'm very optimistic about next version being fully ad-hoc playable. :)

Great work, again!

Idea #1: pong.
Idea #2: two-player platformer where p1 controls the character and attacks the monsters, and p2 finishes puzzles and draw routes so p1 can go further.

Wouldn't Pong be an excellent tutorial for the DStoDS library?
_________________
http://licklick.wordpress.com

*listens to the first mp3 file >4MB transfered via liblobby*
"Die Toten Hosen - Nur zu Besuch" (Just for a visit)

:D

Yes, i thought about pong also, but since i have not much knowledge about programming tiled 2D on the DS, and Yellowstar starting a pong, i'm not starting on this.

There is still a lot of things to do on the lib itself. Just the worst bugs have been resolved. And some Documentation need to be done too ;)
_________________
GBAMP Multiboot

I had an idea for a Front Mission (turn-based strategy with customizable giant robots) clone using local and/or online play, but lost interest in it because of an actual Front Mission release for the DS (that, and I have yet to actually write anything for the DS since I spend more time playing with homebrew or commercial games >_<). Regardless, I think a game like that would work very well for this too.
_________________
Cobalt/Black NDSL
CycloDS Evolution (firmware 1.55 BETA 3) and EZFlash 3-in-1
Kingston SD-C02G JAPAN 2GB MicroSD
MoonShell 1.71, DSOrganize 3.1129, QuakeDS Pre3, ScummVM DS 0.11.1, Pocket Physics 0.6, OpenTyrian DS 0.3

Jesse wrote:

I've updated the adhoctest just because I'm so happy right now. Next steps for me is to trying to figure out how to synchronize strokes properly. There is some small input stutter which probably comes from the wifi doing work on the arm7 core, but that's probably easily solved from my side. Also, I'm going to dig into doing a proper room implementation. But that's for tomorrow.

Jesse, you are amazing.

Jesse wrote:

I've updated the adhoctest just because I'm so happy right now. Next steps for me is to trying to figure out how to synchronize strokes properly. There is some small input stutter which probably comes from the wifi doing work on the arm7 core, but that's probably easily solved from my side. Also, I'm going to dig into doing a proper room implementation. But that's for tomorrow.

Also, I may have just missed it, but did you leave out calibration from the latest adhoc test?

EDIT: Jesse, you should start a adhoctest bug thread, i feel bad posting here. Just wanted to let you know the latest adhoc test has problems after shutting and reopening the ds. The first time i got just a black screen and the ds was locked up. Then I restarted the ds to try it again and this time it brought the colors menu back, but i could not choose anything, it was locked up. OK bye! Thanks!

adamrgolf wrote:

Also, I may have just missed it, but did you leave out calibration from the latest adhoc test?

Well, yes. It was not meant to be used for anything other than just testing out the core part of libwifi, and I haven't really cared about anything else. Since that seems to be resolved now, I'll go work on integrating this properly into Colors!. Once that is done I'll probably post a more proper version in the Colors! thread for some feedback.

(and thanks for the bugreport, I'll keep a look out for it)
_________________
http://www.collectingsmiles.com/colors & http://www.collectingsmiles.com/hyena

Jesse wrote:

adamrgolf wrote:

Also, I may have just missed it, but did you leave out calibration from the latest adhoc test?

Well, yes. It was not meant to be used for anything other than just testing out the core part of libwifi, and I haven't really cared about anything else. Since that seems to be resolved now, I'll go work on integrating this properly into Colors!. Once that is done I'll probably post a more proper version in the Colors! thread for some feedback.

(and thanks for the bugreport, I'll keep a look out for it)

Sounds great, thanks.

With the latest version, I can finally play some levels in Lode Runner cooperatively without a lockup! That's really great, thanks a lot!
It could be that my arm7 mp3 decoding code interfers sometimes with liblobby, as I got very strange things (the game slowing down extremely on one DS and reacting strange) in a level with a specific background (= specific music), but that's likely to be more a problem of my arm7 code.
Now I need to code a better synchronization of the game states ... ;-)
_________________
<dsFont> <Game Collection>

Enumerating rooms currently seems like a pain and there is currently no way to be sure they are coming in a consistent order. A LOBBY_GetRoomByName or a LOBBY_GetNumberOfKnownRooms would make my day.

Edit: I needed this because I want my app to have 4 predefined public rooms. I can solve this by storing the roomid in the version:

Code:

unsigned int ID = LOBBY_GetRoomGameVersion(room);
Version = ID & 0x3fff;
if(Version == Colors_iVersion)
{
unsigned int iRoom = ID >> 14;

Btw, there is a bug in the SVN where the LOBBY_GetRoomGameVersion reports the GameCode instead:

Code:

unsigned short LOBBY_GetRoomGameVersion(LPLOBBY_ROOM room)
{
if (!room) return 0 ;
return room->gameCode ;
}

_________________
http://www.collectingsmiles.com/colors & http://www.collectingsmiles.com/hyena

Erm yes, copy&paste ;)

I was thinking about a
LOBBY_FindRoomByGame(unsigned short gameCode, LPLOBBY_ROOM anchor) ;
to iterate through rooms.

The GetNumberOfKnownRooms will be added too.
Btw, you can workaround it yet with GetRoomByID until the returned value is null.
_________________
GBAMP Multiboot

I have a question about the lib and the rooms:

How does a host
detect when a client has joined its room?

Or do I have to do that myself?(a way
to have the host detect joined clients.(via messages))

yellowstar wrote:

How does a host
detect when a client has joined its room?

When a user joins the room, a userinfo callback is generated with the parameter USERINFO_ROOMCHANGE. You can tell it is your room, by checking via LOBBY_GetRoomByUser.

Another way would be to monitor the number of users in your room.

Your room is allways LOBBY_GetRoomByID(ROOMID_MYROOM)

If you have some other way to get feedback on roomjoins in mind, let me know.
_________________
GBAMP Multiboot

The latest revision in svn seems to be somehow broken - after initialization I get almost immediately user timeouts, after first sent message or even before that. First I suspected something to be wrong with my game code, but compiling the svn example with the latest lib had the same problem. Reverting back to revision 60 (25/10/07) fixed these timeout problems for me.

Hmm. that is weird. The only thing changed that is related to sending/timeout is the change of the broadcast interval. ("I am here") to twice every second.

The rest are only the find room routines.

Does it work again if you use rev61 with the old timeout settings? (Line 27 of lobby.c -> change back from 30 to 10)
_________________
GBAMP Multiboot

Ok, it was only the precompiled library giving this problem. When I compiled the library myself from the r61 svn source there was no problem at all (tested with various broadcast intervals, too). I also noticed that when I compile the library myself, the liblobby9d.a is 78kb, but the version in svn is only 75kb. liblobby7d.a seems to be identical both in svn and when compiled locally.

Oh, ok.

That is my fault. I had previously tested something. And guess i didn't make it before commiting
_________________
GBAMP Multiboot

Next Version will have some performance monitoring to find the bottlenecks. ...

Code:

Function LOBBY_AckStreamHandler(0):
calls          : 1833
[Including subcall times]
   total clocks : 2033768 cycles
   total time    : 60.6841673700 msecs
   clocks per call : 1109 cycles
   time per call : 0.0330906680 msecs
[Pure times]
   total clocks : 444643 cycles
   total time    : 13.2673885280 msecs
   clocks per call : 242 cycles
   time per call : 0.0072208671 msecs

Function LOBBY_AddDataToAck(1):
calls          : 2047
[Including subcall times]
   total clocks : 1788840 cycles
   total time    : 53.3759337142 msecs
   clocks per call : 873 cycles
   time per call : 0.0260488306 msecs
[Pure times]
   total clocks : 1788840 cycles
   total time    : 53.3759337142 msecs
   clocks per call : 873 cycles
   time per call : 0.0260488306 msecs

Function LOBBY_AddToAckCache(2):
calls          : 3064
[Including subcall times]
   total clocks : 660655 cycles
   total time    : 19.7128180765 msecs
   clocks per call : 215 cycles
   time per call : 0.0064152332 msecs
[Pure times]
   total clocks : 660655 cycles
   total time    : 19.7128180765 msecs
   clocks per call : 215 cycles
   time per call : 0.0064152332 msecs

Function LOBBY_AlreadyReceived(3):
calls          : 6128
[Including subcall times]
   total clocks : 32325883 cycles
   total time    : 964.5491985096 msecs
   clocks per call : 5275 cycles
   time per call : 0.1573970005 msecs
[Pure times]
   total clocks : 32325883 cycles
   total time    : 964.5491985096 msecs
   clocks per call : 5275 cycles
   time per call : 0.1573970005 msecs

Function LOBBY_BroadcastID(5):
calls          : 442
[Including subcall times]
   total clocks : 2887819 cycles
   total time    : 86.1675921394 msecs
   clocks per call : 6533 cycles
   time per call : 0.1949335742 msecs
[Pure times]
   total clocks : 2884071 cycles
   total time    : 86.0557582138 msecs
   clocks per call : 6525 cycles
   time per call : 0.1946948679 msecs

Function LOBBY_ClearAckCache(6):
calls          : 9794
[Including subcall times]
   total clocks : 970122 cycles
   total time    : 28.9467853842 msecs
   clocks per call : 99 cycles
   time per call : 0.0029539911 msecs
[Pure times]
   total clocks : 970122 cycles
   total time    : 28.9467853842 msecs
   clocks per call : 99 cycles
   time per call : 0.0029539911 msecs

Function LOBBY_FlushAckCache(10):
calls          : 4897
[Including subcall times]
   total clocks : 22922815 cycles
   total time    : 683.9776916793 msecs
   clocks per call : 4680 cycles
   time per call : 0.1396432156 msecs
[Pure times]
   total clocks : 1481499 cycles
   total time    : 44.2054026194 msecs
   clocks per call : 302 cycles
   time per call : 0.0090111648 msecs

Function LOBBY_FlushCollector(11):
calls          : 2833
[Including subcall times]
   total clocks : 12994698 cycles
   total time    : 387.7396184591 msecs
   clocks per call : 4586 cycles
   time per call : 0.1368384160 msecs
[Pure times]
   total clocks : 12971951 cycles
   total time    : 387.0608867871 msecs
   clocks per call : 4578 cycles
   time per call : 0.1365997096 msecs

Function LOBBY_GetRoomByMAC(17):
calls          : 324
[Including subcall times]
   total clocks : 134142 cycles
   total time    : 4.0025684244 msecs
   clocks per call : 414 cycles
   time per call : 0.0123530537 msecs
[Pure times]
   total clocks : 134142 cycles
   total time    : 4.0025684244 msecs
   clocks per call : 414 cycles
   time per call : 0.0123530537 msecs

Function LOBBY_GetRoomByUser(18):
calls          : 1166
[Including subcall times]
   total clocks : 450488 cycles
   total time    : 13.4417933561 msecs
   clocks per call : 386 cycles
   time per call : 0.0115175815 msecs
[Pure times]
   total clocks : 441391 cycles
   total time    : 13.1703543962 msecs
   clocks per call : 378 cycles
   time per call : 0.0112788751 msecs

Function LOBBY_GetRoomGameCode(19):
calls          : 1166
[Including subcall times]
   total clocks : 405785 cycles
   total time    : 12.1079321025 msecs
   clocks per call : 348 cycles
   time per call : 0.0103837263 msecs
[Pure times]
   total clocks : 401321 cycles
   total time    : 11.9747339584 msecs
   clocks per call : 344 cycles
   time per call : 0.0102643731 msecs

Function LOBBY_GetUserByID(21):
calls          : 57931
[Including subcall times]
   total clocks : 22594315 cycles
   total time    : 674.1758121232 msecs
   clocks per call : 390 cycles
   time per call : 0.0116369346 msecs
[Pure times]
   total clocks : 22408313 cycles
   total time    : 668.6258297756 msecs
   clocks per call : 386 cycles
   time per call : 0.0115175815 msecs

Function LOBBY_GetUserByMAC(22):
calls          : 15023
[Including subcall times]
   total clocks : 3369883 cycles
   total time    : 100.5515594646 msecs
   clocks per call : 224 cycles
   time per call : 0.0066837778 msecs
[Pure times]
   total clocks : 3369883 cycles
   total time    : 100.5515594646 msecs
   clocks per call : 224 cycles
   time per call : 0.0066837778 msecs

Function LOBBY_GetUsername(24):
calls          : 3
[Including subcall times]
   total clocks : 186 cycles
   total time    : 0.0055499227 msecs
   clocks per call : 62 cycles
   time per call : 0.0018499742 msecs
[Pure times]
   total clocks : 186 cycles
   total time    : 0.0055499227 msecs
   clocks per call : 62 cycles
   time per call : 0.0018499742 msecs

Function LOBBY_HandleAck(25):
calls          : 2059
[Including subcall times]
   total clocks : 1589125 cycles
   total time    : 47.4167788419 msecs
   clocks per call : 771 cycles
   time per call : 0.0230053246 msecs
[Pure times]
   total clocks : 1589125 cycles
   total time    : 47.4167788419 msecs
   clocks per call : 771 cycles
   time per call : 0.0230053246 msecs

Function LOBBY_Init(26):
calls          : 1
[Including subcall times]
   total clocks : 101505 cycles
   total time    : 3.0287360254 msecs
   clocks per call : 101505 cycles
   time per call : 3.0287360254 msecs
[Pure times]
   total clocks : 100231 cycles
   total time    : 2.9907220389 msecs
   clocks per call : 100231 cycles
   time per call : 2.9907220389 msecs

Function LOBBY_OOOEnqueReceived(30):
calls          : 2046
[Including subcall times]
   total clocks : 79939896 cycles
   total time    : 2385.2701136035 msecs
   clocks per call : 39071 cycles
   time per call : 1.1658119821 msecs
[Pure times]
   total clocks : 79932783 cycles
   total time    : 2385.0578738188 msecs
   clocks per call : 39067 cycles
   time per call : 1.1656926290 msecs

Function LOBBY_PrepareCollector(31):
calls          : 2833
[Including subcall times]
   total clocks : 521484 cycles
   total time    : 15.5601928719 msecs
   clocks per call : 184 cycles
   time per call : 0.0054902461 msecs
[Pure times]
   total clocks : 521484 cycles
   total time    : 15.5601928719 msecs
   clocks per call : 184 cycles
   time per call : 0.0054902461 msecs

Function LOBBY_RecvCallback(32):
calls          : 5220
[Including subcall times]
   total clocks : 151458754 cycles
   total time    : 4519.2708201650 msecs
   clocks per call : 29015 cycles
   time per call : 0.8657580984 msecs
[Pure times]
   total clocks : 4423981 cycles
   total time    : 132.0040454199 msecs
   clocks per call : 847 cycles
   time per call : 0.0252730350 msecs

Function LOBBY_RecvChunk(33):
calls          : 4897
[Including subcall times]
   total clocks : 120597857 cycles
   total time    : 3598.4343045271 msecs
   clocks per call : 24626 cycles
   time per call : 0.7347978263 msecs
[Pure times]
   total clocks : 4089948 cycles
   total time    : 122.0370705835 msecs
   clocks per call : 835 cycles
   time per call : 0.0249149754 msecs

Function LOBBY_RememberReceived(34):
calls          : 2046
[Including subcall times]
   total clocks : 389906 cycles
   total time    : 11.6341298332 msecs
   clocks per call : 190 cycles
   time per call : 0.0056692758 msecs
[Pure times]
   total clocks : 389906 cycles
   total time    : 11.6341298332 msecs
   clocks per call : 190 cycles
   time per call : 0.0056692758 msecs

Function LOBBY_ResendUnacked(35):
calls          : 2833
[Including subcall times]
   total clocks : 15882340 cycles
   total time    : 473.9019292205 msecs
   clocks per call : 5606 cycles
   time per call : 0.1672734758 msecs
[Pure times]
   total clocks : 1528546 cycles
   total time    : 45.6092048339 msecs
   clocks per call : 539 cycles
   time per call : 0.0160828404 msecs

Function LOBBY_RoomStreamCallback(36):
calls          : 1
[Including subcall times]
   total clocks : 7113 cycles
   total time    : 0.2122397847 msecs
   clocks per call : 7113 cycles
   time per call : 0.2122397847 msecs
[Pure times]
   total clocks : 339 cycles
   total time    : 0.0101151816 msecs
   clocks per call : 339 cycles
   time per call : 0.0101151816 msecs

Function LOBBY_SendToRoom(38):
calls          : 2046
[Including subcall times]
   total clocks : 6788257 cycles
   total time    : 202.5500076402 msecs
   clocks per call : 3317 cycles
   time per call : 0.0989736210 msecs
[Pure times]
   total clocks : 1323469 cycles
   total time    : 39.4900570296 msecs
   clocks per call : 646 cycles
   time per call : 0.0192755379 msecs

Function LOBBY_SendToUser(39):
calls          : 5111
[Including subcall times]
   total clocks : 26429295 cycles
   total time    : 788.6050725799 msecs
   clocks per call : 5171 cycles
   time per call : 0.1542938179 msecs
[Pure times]
   total clocks : 24403619 cycles
   total time    : 728.1623566844 msecs
   clocks per call : 4774 cycles
   time per call : 0.1424480152 msecs

Function LOBBY_SendViaCollector(40):
calls          : 2692
[Including subcall times]
   total clocks : 837612 cycles
   total time    : 24.9929130555 msecs
   clocks per call : 311 cycles
   time per call : 0.0092797094 msecs
[Pure times]
   total clocks : 837612 cycles
   total time    : 24.9929130555 msecs
   clocks per call : 311 cycles
   time per call : 0.0092797094 msecs

Function LOBBY_SetStreamHandler(41):
calls          : 3
[Including subcall times]
   total clocks : 2338 cycles
   total time    : 0.0697619312 msecs
   clocks per call : 779 cycles
   time per call : 0.0232440310 msecs
[Pure times]
   total clocks : 2338 cycles
   total time    : 0.0697619312 msecs
   clocks per call : 779 cycles
   time per call : 0.0232440310 msecs

Function LOBBY_SetUserInfoCallback(42):
calls          : 1
[Including subcall times]
   total clocks : 637 cycles
   total time    : 0.0190069932 msecs
   clocks per call : 637 cycles
   time per call : 0.0190069932 msecs
[Pure times]
   total clocks : 637 cycles
   total time    : 0.0190069932 msecs
   clocks per call : 637 cycles
   time per call : 0.0190069932 msecs

Function LOBBY_Shutdown(43):
calls          : 1
[Including subcall times]
   total clocks : 999 cycles
   total time    : 0.0298084556 msecs
   clocks per call : 999 cycles
   time per call : 0.0298084556 msecs
[Pure times]
   total clocks : 999 cycles
   total time    : 0.0298084556 msecs
   clocks per call : 999 cycles
   time per call : 0.0298084556 msecs

Function LOBBY_Update(44):
calls          : 13716
[Including subcall times]
   total clocks : 22230013 cycles
   total time    : 663.3056619678 msecs
   clocks per call : 1620 cycles
   time per call : 0.0483380362 msecs
[Pure times]
   total clocks : 3459854 cycles
   total time    : 103.2361406078 msecs
   clocks per call : 252 cycles
   time per call : 0.0075192501 msecs

Function LOBBY_UpdateRoom(45):
calls          : 1
[Including subcall times]
   total clocks : 6774 cycles
   total time    : 0.2021246031 msecs
   clocks per call : 6774 cycles
   time per call : 0.2021246031 msecs
[Pure times]
   total clocks : 5202 cycles
   total time    : 0.1552188050 msecs
   clocks per call : 5202 cycles
   time per call : 0.1552188050 msecs

Function LOBBY_UpdateUser(46):
calls          : 323
[Including subcall times]
   total clocks : 286484 cycles
   total time    : 8.5481937983 msecs
   clocks per call : 886 cycles
   time per call : 0.0264367284 msecs
[Pure times]
   total clocks : 263165 cycles
   total time    : 7.8523946222 msecs
   clocks per call : 814 cycles
   time per call : 0.0242883713 msecs

Function LOBBY_UserResetTimeout(49):
calls          : 5220
[Including subcall times]
   total clocks : 373986 cycles
   total time    : 11.1591041938 msecs
   clocks per call : 71 cycles
   time per call : 0.0021185189 msecs
[Pure times]
   total clocks : 373986 cycles
   total time    : 11.1591041938 msecs
   clocks per call : 71 cycles
   time per call : 0.0021185189 msecs

_________________
GBAMP Multiboot

Last edited by Mighty Max on Mon Oct 29, 2007 9:38 pm; edited 1 time in total

Mighty Max, Do you have any suggestions on how to handle FIFO for own usage when using the Lobby library? In my game I disabled the sounds after starting the Lobby implementation because the FIFO was reserved... Now I'm trying to get things back beeping, but the end result is that either the lobby or sounds don't work at the same time, depending on which (my sound fifo setup or arm9 ipc_init()) is called first.

I noticed you have something like customIPCCallback in the library code - is this something could be used for passing sound playback commands from arm9 to arm7? If so, a small example would be appreciated. :)

Yes, the ipc system requires exclusive access to the fifo hardware.

The IPC system will get some change in the future to seperate it from the liblobby. For now you can just set a custom callback and send messages to the other side.

Atm you can simply use
IPC_SetCustomCallback(IPC_CUSTOMCALLBACK_PROC callback) ;
to set a callback, which will receieve any message the other side sends with
IPC_SendMessage(char *data,unsigned long length) ;
The first u32 in the message has to be >8 (as this is the tag the wifi code identifies the commands)

The include is "MessageQueue.h"
_________________
GBAMP Multiboot

Thanks! Custom IPC callbacks are working nicely now. (Having still problems with the sound playback being cut.) Edit: Got lobby and sounds working 100% at the same time.

One major thing left to do: Sgstair wifi and lobby lib in the same build. Would be optimal if player could go from internet game to local wireless game and other way around. Well, back to coding...

I am almost done with my Pong game.
All that's left is Wireless.(and bugs)
(By the way, scores are displayed in console
on sub screen, game on main.
Due to a problem with console not working
on main.)
(Will implement non-console scores later.)

The opponet's bat
is choppy.(On the recieving DS.)

Other things are out of sync,
but that's my problem.
(Only bat movement messages are sent
at the moment)

EDIT:
I am using R 60.
Has the aforementioned problems
been resolved?

EDIT2:
There are more problems.

Sometimes,
the opponets bat(on the recieving DS)
would be behind.
It would still follow the wanted movement.

In the worst case,
the opponets bat
wouldn't move at all.

EDIT3:
Another problem:

Sometimes there is some lag.
Both DSes,(at least I think it's both)
slow down.
The max is about one second.

(By the way,
I got the scores in sync.)
(They don't get updated at exactly
the same moment.)

You need to be prepared for choppy networking. It doesn't matter what the reason is. Even if the lobby library was 100% perfect, for example the users can be too much apart from each other or there's other traffic on the channel distracting the sent messages.

To the actual question - how to achieve smooth gameplay in your case? There's a handful of options you can choose from:

btw. I once did a Pong for Series 60 phones using Bluetooth (one of the most horrifyin coding experiences in my life :) That was the wonkiest networking I've dealt with, now doing things with the lobby lib life seems whole lot of easier...

It's obvious I never did any networking stuff
before...(I read I few tutorials,
but I couldn't actually do them due to
no network and Dial-Up.)

I'll try your suggestions melw,
and if those fail,
I guess I'll search gamedev and the Internet.

Thanks melw.
Thanks to your second suggestion,
I have gotten the bats to
move smoothly now.

Now,
I'm having troubles with scores
being out of sync.
(Hopefully I can figure it out.
If not, I'll try searching the Inet.)

gbadev.org forum archive

DS development > DS to DS communication: need tests

#141176 - phhusson - Sat Sep 22, 2007 11:33 pm

#141182 - spinal_cord - Sun Sep 23, 2007 12:35 am

#141190 - zazery - Sun Sep 23, 2007 2:54 am

#141194 - dantheman - Sun Sep 23, 2007 3:21 am

#141230 - simonjhall - Sun Sep 23, 2007 10:09 am

#141236 - melw - Sun Sep 23, 2007 11:47 am

#141237 - moncul - Sun Sep 23, 2007 12:33 pm

#141238 - melw - Sun Sep 23, 2007 12:50 pm

#141244 - phhusson - Sun Sep 23, 2007 2:17 pm

#141245 - moncul - Sun Sep 23, 2007 2:36 pm

#141249 - calcprogrammer1 - Sun Sep 23, 2007 3:45 pm

#141259 - phhusson - Sun Sep 23, 2007 4:45 pm

#141273 - Mighty Max - Sun Sep 23, 2007 7:10 pm

#141285 - zazery - Sun Sep 23, 2007 8:27 pm

#141294 - yellowstar - Sun Sep 23, 2007 9:17 pm

#141296 - melw - Sun Sep 23, 2007 9:23 pm

#141300 - phhusson - Sun Sep 23, 2007 10:20 pm

#141323 - Opus - Mon Sep 24, 2007 2:37 am

#141328 - calcprogrammer1 - Mon Sep 24, 2007 3:51 am

#141342 - melw - Mon Sep 24, 2007 9:03 am

#141356 - ThomasS - Mon Sep 24, 2007 2:21 pm

#141358 - melw - Mon Sep 24, 2007 2:43 pm

#141360 - Mighty Max - Mon Sep 24, 2007 4:48 pm

#141372 - phhusson - Mon Sep 24, 2007 8:06 pm

#141378 - Mighty Max - Mon Sep 24, 2007 8:47 pm

#141391 - phhusson - Mon Sep 24, 2007 10:27 pm

#141430 - melw - Tue Sep 25, 2007 10:59 am

#141466 - HyperHacker - Tue Sep 25, 2007 10:34 pm

#141497 - melw - Wed Sep 26, 2007 8:57 am

#141521 - phhusson - Wed Sep 26, 2007 5:32 pm

#141529 - Mighty Max - Wed Sep 26, 2007 6:27 pm

#141629 - phhusson - Thu Sep 27, 2007 8:31 pm

#141695 - Mighty Max - Fri Sep 28, 2007 1:57 pm

#141699 - melw - Fri Sep 28, 2007 4:32 pm

#141706 - Mighty Max - Fri Sep 28, 2007 7:16 pm

#141775 - Mighty Max - Sat Sep 29, 2007 7:16 pm

#141776 - Tets - Sat Sep 29, 2007 7:35 pm

#141777 - ThomasS - Sat Sep 29, 2007 7:35 pm

#141778 - Mighty Max - Sat Sep 29, 2007 7:41 pm

#141782 - phhusson - Sat Sep 29, 2007 10:34 pm

#141786 - melw - Sun Sep 30, 2007 12:13 am

#141805 - Mighty Max - Sun Sep 30, 2007 9:19 am

#141812 - Mighty Max - Sun Sep 30, 2007 11:45 am

#141814 - spinal_cord - Sun Sep 30, 2007 11:57 am

#141815 - melw - Sun Sep 30, 2007 11:57 am

#141818 - Mighty Max - Sun Sep 30, 2007 12:08 pm

#141819 - Mighty Max - Sun Sep 30, 2007 12:17 pm

#141820 - melw - Sun Sep 30, 2007 12:33 pm

#141821 - Mighty Max - Sun Sep 30, 2007 12:40 pm

#141828 - zazery - Sun Sep 30, 2007 5:21 pm

#141829 - Lick - Sun Sep 30, 2007 5:30 pm

#141830 - Mighty Max - Sun Sep 30, 2007 5:42 pm

#141832 - tepples - Sun Sep 30, 2007 5:53 pm

#141840 - melw - Sun Sep 30, 2007 7:59 pm

#141853 - yellowstar - Sun Sep 30, 2007 9:26 pm

#141868 - Lick - Sun Sep 30, 2007 11:41 pm

#141909 - HyperHacker - Mon Oct 01, 2007 2:37 pm

#141911 - Sektor - Mon Oct 01, 2007 3:04 pm

#141932 - Mighty Max - Mon Oct 01, 2007 8:14 pm

#141984 - Mighty Max - Tue Oct 02, 2007 8:29 pm

#141999 - yellowstar - Tue Oct 02, 2007 10:55 pm

#142011 - HyperHacker - Wed Oct 03, 2007 3:09 am

#142119 - Mighty Max - Thu Oct 04, 2007 7:06 pm

#142156 - Puyo - Fri Oct 05, 2007 12:36 pm

#142159 - Mighty Max - Fri Oct 05, 2007 1:44 pm

#142160 - dualscreenman - Fri Oct 05, 2007 2:22 pm

#142174 - Mighty Max - Fri Oct 05, 2007 7:51 pm

#142236 - Mighty Max - Sat Oct 06, 2007 7:46 pm

#142240 - yellowstar - Sat Oct 06, 2007 8:30 pm

#142242 - Mighty Max - Sat Oct 06, 2007 8:39 pm

#142371 - Mighty Max - Mon Oct 08, 2007 8:06 pm

#142375 - Jesse - Mon Oct 08, 2007 8:10 pm

#142376 - Mighty Max - Mon Oct 08, 2007 8:20 pm

#142400 - simonjhall - Mon Oct 08, 2007 11:06 pm

#142440 - Mighty Max - Tue Oct 09, 2007 5:24 am

#142499 - Mighty Max - Tue Oct 09, 2007 6:38 pm

#142513 - simonjhall - Tue Oct 09, 2007 10:33 pm

#142537 - Mighty Max - Wed Oct 10, 2007 5:20 am