Emulator

I want to fix this issue....

I hope this bug gets fixed soon

This issue should have been fixed by now. What seems to be the problem?

just tested with vba-m r1001 and dolphin r7442 x64, dolphin stays frozen, gba screen only shows the "gameboy" logo, so gba connection still not working for this game

Yeah, it's still broken. Just confirming.

Still broken and the developers don't care.

How do you know they don't care? It's not like they have to prioritize this over any other issue, anyway. I'd like to see it fixed as much as anybody, but I'm also respectful of the devs' time/priorities.

Agreed, but is it Dolphin or VBA-M? which is not functioning - wheres the break so we could know which to address.

The game does not send the gba ucode to the dsp. Other than that I don't know what is wrong.

with the gba link open, i got some performance issues. for hints how to solve these issues i'd be very thankful.

i recognized using "options -> speed -> turbo mode" (i think it's the same like using the turbo button) helps increasing the framerate in ffcc. but it's still unplayable :( it seems the data transfer from vba-m to dolphin is stuck or slowed down somewhere and increasing process speed helps compensating this. i hope this information is useful and helps finding the reason for this issue.

Yo, last update was too long ago for such a great game. I've been testing a lot of configuration lately to get the stuff working but christsake it seems very hard.

I'm currently using the North american FFCC version with VBA-M Lastest release. Dolphin 3.0, on a intel core-I5 2500K with a 6850, 8gb ram. GBA bios is always the same.

All-in-all, i've manage to make the game freeze while enabling Joybus connection. It seems able to recognise the VBA-M but cannot show anything else. Since the emulator goes slower than usual when i connect it, i believe it recieve connection information, but the VBA never (NEVAR!!!1!) shows the ''nintendo'' that means the connection is good.

Hope it helps, i really wanna get this issue fix as soon as possible. Thanks for the good work. Peace out.

look what i got here, with latest vba-m (r1049) i managed to bring up a connection, unfortunately the gba screen only shows this crystal chronicles background (as this is singleplayer the gba screen should show additional information about the dungeon). When the vba-m window is not in the foreground, dolphin will freeze, in addition the speed is pretty terrible and somehow depends on the speed of vba-m...

Excellent! I hope shuffle checks this out. I haven't looked at the svn of VBA-M to see what's changed between 1030 and 1049, but I'll certainly do that now. Maybe Squall can enlighten us.

Please fix this. Thanks :D

We don't are in a restaurant, ok

What are you talking about? 'We don't are in a restaurant, ok" ??

Seems pretty straightforward. He's just kindly letting us know that we aren't in a restaurant.
We don't are in a gymnasium, ok

So can anyone narrow the issue to VMA or is it dolphin or both? I just want to play this game multiplayer =(

Where are you getting VBA-M 1049? I can only find 1022.
on that note, I noticed that on it's own, Dolphin takes up ~10-20% of my CPU while running FFCC, and that drops to like 1% as soon as I connect VBA-M. Dolphin mostly freezes, but it says it's running at 8% speed and there is sound. after a few seconds, full visual freeze but sound continues. usually. the VBA-M also dosen't show anything. at all. like, it's just a black screen. :(

don't know what would cause this, but it's not a lack of capability on my computer's part. i7-2600k, overclocked to 4.8 ghz and AMD Radeon HD 6950. 8Gb of RAM.

latest builds of vba-m are on emucr.com

okay, with latest versions of everything (don't even know if that changed anything) I cranked up the throttle on the GBA emulator, since someone had commented that the game was dependant on the speed of the GBA. Dolphin now runs, but I have to figure out how to get the two to link properly. my GBA emulator is sitting on the GameBoy screen. :/

OH SHIT it works. I... I don't even know how I did it. it was connected and sitting on the GameBoy screen, and I closed Dolphin and turned it back on and started the game and didn't close down the VBA-M. when I connected, it got the blue screen like above, but there's also a "waiting for connection" screen on the GBA and the controlls all work and Dolphin is working at 70% speed O.O ghasps for air

except, in not knowing exactly how it happened, it's REALLY hard to reproduce. apparently. :(

Version of your stuff?

sounds like he mounted the gba-m version of ffcc, instead of the bios...

Just downloaded dolphin and VBA-M today. Based on what I read on here and reviewing youtube vids i was able to get the single-player VBA-M screen to work with Dolphin running at about 60%. For VBA-M I have Frame skip at Auto, Turbo mode enabled, and GBA Linking enabled. Also in Emulator -> Bios Files i enabled the GBA Bios. When I loaded FF CC it originally only displayed "Gameboy" on VBA-M however once i entered the first level and waited like 5 min everything slowly loaded to what is in the picture. Not sure how helpful this is but its not too bad at 60%.

I know it says 83% on the pic but when you switch over it lowers to 58-63%.

Can we get your dolphin and VBA-M version?
There were no real change on mine.

''what I read on here and reviewing youtube vids i was able to get the single-player VBA-M screen to work with Dolphin running''

What video? Cant seems to find any that actually help.

ok I sort of have this working... it started at 20% for a while and now its down to 0%.
I have the lastest version of VBA-M and Dolphin (as of today, 31 jan 2012)

baiscally i started off with what JHidson18 did.

start dolphin. run ffcc. set controller one to gba.
start vba-m. run gba bios. enable joybus... Both emulators apparently freeze. let windows force close dolphin.

Start dolphin again. load up ffcc. (again make sure controller is set to gba) then run the joybus options again. POW it works.

Problem with this is dolphin starts running at 16% and during the opening video it goes slowly down to 0% and freezes. this is as far as i've got :(

managed to get it working with single player by following the guy above me.. though i easily bypasses his "opening video problem" by simply loading a game instead of starting a new one. I almost had two gbas connected, i saw the player 2 red ring at the character select screen, but it would not connect. but i think it's possible. although, the dolphin never went above 40% for me. so even if it ever worked, it's going to be slow.

no news?

I can get it to work VERY slowly. I seem to have more consistent results if I do a save state with the VBA-M on the waiting for connection screen. As the initial connection seems to be the majority of issues. If someone else wants to work on it further I've uploaded the save state.

Tried various versions of VBA-M and Dolphin with nearly identical results.

"start dolphin. run ffcc. set controller one to gba.
start vba-m. run gba bios. enable joybus... Both emulators apparently freeze. let windows force close dolphin."
Works fine for me. Put turbo on the GBA, and minor adjustments to the EMU i was able to get it working at 68-80% no matter which windo i had selected. Currently im running one GBA in its in multiplayer mode.

VBA-M(SVN!337), Dolphin 3.0-433 dirty

i cant find vba-m svn 337 i searched google and got svn 854

Issue 5275 has been merged into this issue.

Since this has been merged with the Tingle Tuner Issue, I think I should give a slight run-down of my experience. I've tried this in every order, jsyk. After opening and connecting Dolphin and VBA with Frame Skip to Auto, Turbo Mode on, and turning Pause While Inactive Window off, Dolphin plays at a decent speed for me. When I try to take out the Tingle Tuner in game to create the connection, the green Nintendo icon appears on VBA. The VBA screen turns white and Wind Waker says that the connection timed out. Around a minute later, VBA advances to the next screen showing Tingle flying across the screen and the word "Calling" being shown. The screen advances at about 1/2 fps. If you wait long enough, eventually Tingle gets about 3/4 across the screen and the screen turns red and says that an error has occurred and to reset the GBA. Closing Dolphin at the white screen causes the same to occur, except that it goes full speed. Seems that when VBA turns white, Wind Waker expects that the GBA will load quickly and so it times out rather quickly. I'm not sure if it is reasonable, but it would be interesting if VBA and Dolphin would interact and play at similar fps when linked. I imagine that this may help this issue.

This stuff happens to me too, I can't get past the GBA bios. If you can please make this work, I will perform oral sex on you.

good lord I have been waiting 2 years! for them to fix this and I'm at the point to donate $200 if the dolphin development team can get this to work!

same i really wish this worked by now but i wont rush. I know its hard and I appreciate all the work done so far. I look forward to dolphin 4.0 and pray this will be fixed by then and before 5.0 lol.

So using the the savestate given by gyphero (comment 45), I managed to load up multiplayer successfully! I've got 2 characters, two VBA windows. Both are playable and have their own controllers. The general setup I had to get each player started:
Dolphin 3.0 -377 dirty
VBA-M SVN 1088
i7 920 @ 3.3ghz
2x 1gb ATI Radeon HD 5670
6gb ram

1. Start emulator with GBA as the controller
2. Start VBA (with bios directory selected).
3. Reenable joybus. The game should freeze now.
4. Open the bios. It should stay at the Gameboy Advance screen, but Dolphin resumes
5. Load the savestate that Gyphero attached. Now it will connect that player.
6. Open a second window and repeat all of these steps. Be sure to bind your controllers appropriately to get them to work!

With just one gba connected I had 20fps (out of 30 fps) in Tipa, 16fps with 2 players

Here's attached two example photos, as well as Gyphero's save again

hi,

what chenn wrote works for me,too. but i only reach about 35% gamespeed and i don't know why. which settings do you use?

regards,
wong.

At this point we've solved the big issue.

Up to someone that can polish the code, maybe figure out a way to make all the programs stop fighting for processor priority to finish the job at this point.

I can code, but this is beyond me by far.

So cmon hard part solved IT WORKS. Make it work better.

can some of you please post you technical stats?
just so the team know where it works at.

also, the FF issue has been resolved, it seems to me that it runs like four swords adventures and therefore is a different issue than the tingle tuner one.

my specs are: 7 home premium x64 SP1 Pentium P6200 2.13 GHz dual core 4GB RAM
idling Wind Waker at 95% CPU and 72% RAM usage and it runs at ~50% gamespeed

hey guys,

i made a video where i connect 4 players and run the game, showing of the issues I had with the connecting process, may be someone can find any useful information in that.

Thanks for all your hard work!

http://youtu.be/vyD9i1oPKIA

Related to Comment 53 (which was myself), here are the settings on my emulator for my output:

Dolphin 3.0 -377 dirty
VBA-M SVN 1088
i7 920 @ 3.3ghz
2x 1gb ATI Radeon HD 5670
6gb ram

Enable Dual Core
Enable Idle-Skipping
JIT Recompiler
UNCHECK Skip EFB Access
Ignore Format Changes
EFB Copies to Texture
DISABLE External Frame Buffer
Disable Per-pixel depth
OpenMP Texture Decoder

I play FFCC (ntcs), VBA-M svn947 and dolphin 3.5 (compiled 24/12/12).

have:
intel i5 2400 sandy bridge (clock 3,4)
radeon hd 6850
8GB RAM

Get it running to at MOST 60%... two players
:/

Issue 6338 has been merged into this issue.

Hi, just wanted to say I got it working following the steps from post 53.

have:
intel core i7 980x
GeForce gtx 580

Best I could get was about 25-30fps with 2 players (better than most it seems). It was kinda playable, but I was looking to get 3 players working anyway. Audio skipping was the most annoying. Also, frequent disconnects (have to reload the save state often).

Might I suggest implementing the VBA into the emulator somehow rather than using a virtual network connection or whatever?

Glad to see this is still being worked on.

In addition to FF:CC and the WW Tingle Tuner, I believe this same issue also prevents the GBA Island in Animal Crossing from fully working. Dolphin recognizes VBA-M (running the GBA bios) as a connected GBA, so you can visit the island in Dolphin, but when Dolphin attempts to send data to VBA-M over the network to load the island on the GBA, VBA-M slows down almost to a halt and the connection times out.

Can someone help me to config dolphin and vba-m? which version I have to tae for have the best amont of speed?

I have dolphin version 3.5 64 bit with vba-m svn 1147 and 1200.

I have:
Alienware
8go ram
Intel core i7-3610QM CPU @ 2,30GHz
Nvidiab 3d card and an integrate graphic card.

I only manage to go at 11-12% speed with two vba-m on...
If someone can help I would appreciate.

It's not going to run well currently. The best thing you can do is set VBA to turbo mode.

The best thing to do at this moment is enable 200% throttle mode, because turbo mode makes the emulator put its frame skip at maximum.
Using only throttle 200% I could play Zelda 4 sowrds pretty well with VBA-m.

Reminder that the Wind Waker Tingle Tuner issue was merged with this and none of these "fixes" even manage to get it to work.

Just note, with Four Swords Adventure, setting the throttle to 100% works just fine for getting full speed on VBA and Dolphin.

Hey guys, poster from comment #53 again. I've got some new hardware and clean OS install so figured I'd try this again.

Dolphin 4.0.2
VBA-M SVN 1206
i7 920 overclocked to 3.81ghz
2x 2gb Nvidia Geforce 660 Titanium
18gb ram
Same settings as comment #53

This game is cpu-limiting, I figure, so the improvements I'm about to show may be from me milking an extra .5ghz out of my CPU. I can only upload a few photos. Results are sorted by player number

1. Single Player mode with a GBA in slot 2 is working at 100%

2. 1st photo is 2 player, working at 90%, with some stuttering in controls (from Turbo?).

3. With 3 GBAs. 76% output, 22 FPS. Games not playable by this point, of course. But it's faster with 3 people (22fps) than my previous attempt with only 2 people (16fps)

4. With 4 GBAs. 61% output, 17fps. Just as fast as my 2 people attempt months ago. Pretty good progress!

5. I wanted to see how the game performs in a smaller cell (moogle house in Tipa). Slight improvement to 70%, 22 fps. with 4 people

6. Second photo is 4 people at the entrance to River Belle Path. 60% output, 13 FPS. I figured a large map like this would have its struggles.

So there's my update! If only more than 2 cores were supported, then who knows how well things could go!

You do realize that just setting dolphin to more than 2 cores would do nothing. Also, putting 7 MB worth of images on the limited space of the google code will not earn you any friends.

Anyway, part of the problem of this is that the VBAs are also in turbo mode, as you probably noticed, once you added more than 2 VBAs, framerate sharply took a nose dive. Don't forget that the GBA emulators in turbo can easily take up a core on their own!

I just read an explanation on the cores, and yeah it makes sense. Sorry about the photos! Wanted to provide some proof of performance, but compressed jpg probably would have been better.

Is it possible (or reasonable) to direct a vba-m to work on the non-used cpu cores? Would that offload strain from the 2 cores working on dolphin, or are both emulators obligated to remain on the same cores?

It's no problem, I'm glad to see someone else has been getting good speeds on this.

The VBA-Ms will eventually use a full CPU core if turbo'd high enough, which is where the problems come in.

And next time, use imgur and link to us, and that'll save us space, and we still get to see the proof. Either way, we're still working on this issue on the hardware side, trying to figure out what exactly is going wrong that the GBAs need turbo mode at all. Fixing that will drastically decrease CPU usage (at least from the GBA emulators, maybe that will allow better performance on dolphin, too?)

Imgur! Good idea. Here are those images and more in an album. For anyone interested to see it. http://imgur.com/a/HmrPo

The work you guys are doing is beyond my skill, but hopefully I can get into it soon!

posting to confirm chenn's method in #53 works in single player with 30fps for me

I am using dolphin 4.0-653 with 3x native resolution and VBA-M SVN1206
The VBA will occasionally disconnect but it can be fixed by reloading the connecting save state

http://i.imgur.com/fIPvqi5.jpg

I noticed the VBA disconnect myself and can confirm it.

I wrote a script for AutoHotkey that is useful for checking the bonus condition in singleplayer mode:

http://pastebin.com/Qe71PZX8
(also attached)

To use the script you should first (in addition to #53):

• change the path in the script to the same as where your VBA-M is
• make a copy of the "connecting" save state and rename it [BIOS FILE NAME]1.sgm (ex. gba_bios1.sgm for gba_bios.bin)
• make sure the most recently loaded file in VBA-M is the bios file
• install autohotkey and run the script as an .ahk file

Numpad-dot will run VBA, load the most recent file (bios), then load the first save state (connecting state). If VBA is already open, it will close VBA. It DOES NOT enable turbo mode so the script is not currently suitable for having VBA open while actually playing.

Numpad-zero will make VBA load the first save state again for when it disconnects.

I basically use it at the beginning of a level to quickly check the bonus point condition, then close it so it doesn't affect my frame rate.

I'm glad to see that this is being worked on. FFCC is one of my goto games for multiplayer, sucks not being able to play it on Dolphin without some serious framerate issues.

Question, is the problem on VBA-M's side or Dolphin's? Is there support for playing with a physical GBA?

I got 25-28 frames in River Belle Path with one VBA-M. Already took a nosedive with two VBAs at 17 FPS in the same area. Other areas tend to load pretty fast, but the frames are inconsistent and the controls stutter.

I have a decent laptop, but I wish I had a overclocked Haswell desktop processor just so I can emulate this.

At most I can get 11 FPS on an i7 920 @ 3.5ghz
Running 4 emulators at once is no issue but it seems like the communication between the emulators is a huge bottleneck. What's up with that?

We believe Dolphin or the GBAs are not accepting/sending information fast enough, causing the bottleneck and one side running too slowly.

All I currently know is, the GBA side is a huge hack. It is slicing up an arbitrary amount of time to poll for new data from Dolphin. When I play with that value, it has a profound effect on the link cable functionality, although nothing seems to get it right. I'm not sure what exactly is going on and where exactly fault lies, but I'm guessing it's mostly VBA-M's messy code. From the GameCube side, the link cable code is pretty simple.

Heck using VBA-M for its intended purpose is a little buggy. I wish more people were working on that not just for this game, but for playing GBA games on multiple computers (preferably over the internet) instead of just all on one desktop.

I found two forks of VBA-M that are supposedly cleaner, more efficient version of it f it.

https://github.com/libretro/vbam-libretro

https://github.com/libretro/vba-next

Anyone care to test?

How would I go about running those from the links?

I am able to run the game with a playable speed with 2 player but I am having issues with focus attack/magic because the connection dosen't seem to be 100% stable. When I hold A to cast a spell it get interrupt by the connection. If anyone able to solve this problem I would probably able to play.

Try turning off idle skipping.

@89 You have to download the sourcecode from Github, compile it, and then
run the executable after its done. Later I may compile it for Windows
myself. If I can I'll share the compiled versions on here.

Even when I turn off idle skip its still not working completly but I found a way to stop it from interrupting but I need to make VBA-M crash by loading a savestate that was fully working in a map when the emulator lose the connection. This way vba freeze but is still useable. I can still control and now I can cast spell without any interruption but I lose the use of the menu. The use the menu I need to reset vba and reload it then recrash it after I finish with the menu. It may take 2-3 minut for every crash/reload but its worth a try. So I will give it a try completing the first stage with my girlfriend.

Actually after playing a bit like this I realized that the interruption only happend when the player is on the radar screen but sadly the radar is also the only screen that provide a "speed up" to the vba...

I spoke to the developer behind gba.emu (based on VBA-M) for Android and
iPhone about including support for Joybus and he has said he will look into
it

https://twitter.com/rakashazi/status/441087279700795393

Based on his work so far if and when he does include joybus support it will
actually be rather well done.

After reading the new dev entry where they switched over from float to int
I decided to try out FFCC on the
4.0-1192https://dolphin-emu.org/download/dev/a9a8c730748b8c8a2e83feb4c38626361cf9daa1/binary
for winx64. If you have an AMD card, I suggest trying it out.
Normally I would get between 20 - 45 FPS when playing CC, now I get 40+.

I've personally offered to pay the developer of gba.emu to add in the
needed functionality.

@SVasquez1994 It is being kept up to date. If there is no new information here, then nothing has changed. A lot of people have starred this issue, and they all receive an email when you post, so please do not post here unless you have something constructive to add.

If you're going to pay someone to add the functionality, talk to no$gba's creator or something. He's probably one of the few people who could implement the GBA side correctly on his own.

I'm sure there are others, but he just pops into my head.

gba.emu, which is based on VBA, is for android and iPhone, so I feel that
it would be more appropriate.

We don't want one based on VBA. We'd want one based on a more accurate GBA emulator. One with proper documentation. Hence my suggestion of no$; that's the person several of the dolphin devs have reached out to in the past.

Yours is only for Windows and is closed sourced, so I can't see how you
have any better documentation. Not going to do me any good, especially
considering I'd rather not have the linked screen on the same screen.

@chris

Well, documentation-wise: http://nocash.emubase.de/gbatek.htm

I thought we were talking about source code documentation and not what
appears to be low level hardware documentation.

Seriously lets stop spamming this with garbage.

The issue with Dolphin stuck/freezing seems to be because Dolphin was waiting for reply data from VBA-M for infinity (might be due to recv buffer were full and dolphin couldn't get the new data)

Here are the last packets captured right before Dolphin stuck:
On Dolphin side:

Send: Return Code: 0x00000000
00000000 15 00 E0 80 01 .....

Receive: Return Code: 0x00000000
00000000 32 2

Send: Return Code: 0x00000000
00000000 00 .

On VBA-M side:¶

Receive: Return Code: 0x00000000
00000000 15 00 E0 80 01 .....

Send: Return Code: 0x00000000
00000000 32 2

Receive: Return Code: 0x00000000
00000000 00 .

Send: Return Code: 0x00000000
00000000 00 04 08 ...

As you can see VBA-M managed to sent the reply data but Dolphin failed to received it from the recv buffer, and ended looping for infinity waiting for the reply data.

Yeah, I had a hunch. Modifying things from the VBA side can change behavior, but the root of the issue is still unknown to me.

No matter what changed in VBA-M it won't fix the freezing issue on Dolphin, because the main issue is at Dolphin side. I don't know why Dolphin couldn't read the data that was sent from VBA-M.

A possible fix might be to make sure the recv buffer is empty before sending a command to VBA-M, this can be done by reading/dumping leftover data in the recv buffer, so dolphin can receive the reply data from VBA-M successfully. Or try to increase the buffer size.

After rechecking the codes on both side (Dolphin and VBA-M) it seems both of them have similar issue, where they tried to read more than what available in Recv buffer, causing the socket to block CPU emulation waiting for more data to be available (which shouldn't be existed)

Here is the fix for Dolphin (SI_DeviceGBA.cpp)

// Blocking, since GBA must always send lower byte of REG_JOYSTAT
void GBASockServer::Transfer(char* si_buffer)
{
if (!client.IsValid())
if (!GetAvailableSock(client))
return;

for (int i = 0; i < 5; i++)
	current_data[i] = si_buffer[i ^ 3];

u8 cmd = *current_data;

if (cmd == CMD_WRITE)
	client.Send(current_data, sizeof(current_data));
else
	client.Send(current_data, 1);

DEBUG_LOG(SERIALINTERFACE, "> command %02x %02x%02x%02x%02x",
	(u8)current_data[0], (u8)current_data[1], (u8)current_data[2],
	(u8)current_data[3], (u8)current_data[4]);

memset(current_data, 0, sizeof(current_data));
size_t num_received, num_sz = 0;

switch (cmd) {
case CMD_READ: 
	num_sz = 5;
	break;
case CMD_WRITE: 
	num_sz = 1;
	break;
case 0x00:
case 0xff:
	num_sz = 3;
}

if (num_sz > 0)
if (client.Receive(current_data, num_sz, num_received) == sf::Socket::Disconnected)
	client.Close();

DEBUG_LOG(SERIALINTERFACE, "< %02x%02x%02x%02x%02x",
	(u8)current_data[0], (u8)current_data[1], (u8)current_data[2],
	(u8)current_data[3], (u8)current_data[4]);

#ifdef _DEBUG
size_t num_expecting = 3;
if (cmd == CMD_READ)
num_expecting = 5;
else if (cmd == CMD_WRITE)
num_expecting = 1;
if (num_received != num_expecting)
ERROR_LOG(SERIALINTERFACE, "%x:%x:%x", (u8)cmd,
(unsigned int)num_received, (unsigned int)num_expecting);
#endif

for (int i = 0; i < 5; i++)
	si_buffer[i ^ 3] = current_data[i];

}

PS: i'll also report the fix for VBA-M to their devs

Thanks Adam! I'm glad I asked for help on the VBA-M forums.

Has anyone tested this yet?

I'll check it out in a bit, I'm a bit slow with code though. Is this expected to fix any other issues, or just disconnects?

This should fix the freezing issue, but both side need to be fixed for them to communicate properly.

I'll test it after it's fixed on dolphin, since i can't compile dolphin my self (i only have vs2010 which getting a lot of syntax errors with the latest dolphin)

Here's a build of dolphin with the above change: https://dl.dropboxusercontent.com/u/11111638/t/dolphin%20gba.7z

I tried but couldn't get vba-m to compile myself :/

Ohhhhh. I'm honestly surprised that it was simply an issue with sockets rather than having to do with the way it was emulated. Like I said, I did manage to affect the issue when messing with VBA-M code, but now I can see it was more or less a fluke (or at least not terribly relevant to the problem.)

BTW, did you happen to post a fix for the VBA-M side, or is it implied that the same sort of modification needs to be made? Either way, nice catch.

Thank for the build, i'll give it a try :)

And yes, i posted a fix for VBA-M here http://vba-m.com/forum/Thread-visualboyadvance-m-svn-1229-mfc-info-and-download?pid=6662#pid6662

I tried out the patches, and unfortunately, I couldn't get either game to work better. Other games still suffered from disconnects as well.

Have you noticed that the speed issues + disconnects as well?

I've tried it with Zelda - Four Swords (the only gamecube game i have in this laptop ^_^) last night using a special build (VBA-M svn1030d), and it was stable, it's no longer stuck, although i still hate the slow performance issue :(

When the first time i tried the patched Dolphin, the FPS on Dolphin is a bit higher, but it still stuck, after adding a few more fix on VBA-M it's no longer stuck, but FPS on Dolphin is back to what it was before :(

The fix for Dolphin seems to be correct, but apparently there are more issue on VBA-M side that need to be fixed.

I'm still looking a way to improve the performance a bit by changing the codes in VBA-M before releasing my build.

Do you guys have the patched Dolphin x86 build? i can't capture the winsock packets on 64bit application :(

Four Swords Adventures has always worked for me on Dolphin, so I don't know what you're doing incorrectly.

It always stuck in the middle of the long story text scrolling from bottom to top on my computer.

Here is the special build of VBA-M svn1030d https://www.dropbox.com/s/trqx5c2pheelsu5/VisualBoyAdvance-M1030d.zip

Let me know if you still experiencing freezing. About disconnects, it never happened to me, atleast based on the software i used to capture packets from both side, none of their sockets ever disconnected in the middle of gameplay.

PS: eventhough it's based on the old svn1030, it's special because it's the 1st GBA emulator that support wireless multiplayer with more than 2 players.

I've played multiplayer in Four Swords Adventures on normal builds of VBA-M + Master Dolphin without issues. It's any of the other games that I have problems on. Also, the japanese version wiht Tetra's Trackers doesn't work either, but, that's to be expected since it seems to require a reconnect even on console.

Also, please don't take this as rude, I'm legitimately curious: Why do we care about wireless multiplayer for Dolphin?

Please test my build with the games that have the freezing issue, let me know if it's still have issue, i'll try to download the game later (my internet is abit slow)

I didn't mean the wireless thing is for dolphin, i just mentioned it just in case there are people who wonder why it's not using the latest svn ^_^ (have been asked about it many times before)

I'm 99% sure that the slowdown issues are caused by VBA or Dolphin not getting the right rate of data.

Anyway, I'm still unable to connect in Final Fantasy Crystal Chronicles, will try out Four Swords with this build too though.

This also breaks Four Swords for me, makes it so it thinks it's connecting over and over again.

I need to say this after messing around more. The build with the patch alone (rachelb provided it last night) actually does connect for me in the main game of Four Swords Adventures, but requires the framelimit to be set to 120% for Dolphin to go full speed.

Does not seem to be any positive effects, unfortunately. Disconnects are not the main problem from within the emulator, but really the games that do work tend to require one emulator to run at the incorrect speed for the other to run at the correct speed.

If you could look at that, it'd be nice, but other than that, neither of these builds fix anything.

I do find it interesting that it breaks connecting though, perhaps that will tell us something more about what the communication requires.

OKay, I'm turning off the send email option on this one because I'm spamming up the issue enough. But, I don't really want to forget anything I'm doing, so here it goes.

I can't test more than one of your provided VBA build; running a second one won't let the bios load for some reason.

I actually got the Nintendo Logo to show up on Final Fantasy Crystal Chronicles with your build, which is better than the original patched one and better than VBA normally. It does not go anywhere.

Using a savestate I got earlier in your build, connects your version to Final Fantasy Crystal Chronicles, and does not seem to disconnect, but the framerate is extremely low unless I turbo mode VBA.

With Turbo Mode, VBA constantly disconnects, but Dolphin runs full speed, and I can control the characters. VBA tends to reconnect after a few seconds. I hope this helps.

I see, i guess my build only works for slow computer like mine ^_^

The reason for the slowdown is because VBA-M use an interval to check incoming data from dolphin, the longer the interval the slower VBA-M will respond thus causing dolphin need to wait longer for reply data.

What i did with mybuild is lowering the interval so it can respond faster, and also check for JOYBUS mode on the SIO before reading the socket (the official svn didn't check for the correct SIO mode, thus have a chance to send an invalid JOYBUS data).
However, during my test if the interval is being too small it will make VBA-M stuck on the 'GAMEBOY' screen.

I guess i should add an option for user to change the interval by them self, as it seems to have different effect on different computer.

Is there any way you could make a configurable option like that? I mean, something is obviously very wrong for Dolphin to need the VBA running at 1200 fps to get full speed communication in Final Fantasy Crystal Chronicles, while it only needs 70ish fps in Four Swords Adventures.

I have a feeling something is very broken.

Also, I started getting the permanent disconnects in FFCC again in game unfortunately.

Is there a way to make it so that Dolphin and VBA-M can talk to each other
so they can find out what the interval needs to be without the need of the
user having to manually configure it?

This feels hackish regardless.

Here is a new build with the option to change the interval https://www.dropbox.com/s/trqx5c2pheelsu5/VisualBoyAdvance-M1030d.zip

The interval value is in GBA's CPU clock ticks

It doesn't seem to work, every time I set a new tickrate it just resets to the old one.

Ah it was visual bug, the value was correctly changed but everytime the joybus window opened the text in the exit box is using a constant text instead of showing the actual value.

I've reupload a new build to fix the visual bug https://www.dropbox.com/s/trqx5c2pheelsu5/VisualBoyAdvance-M1030d.zip

Are there any instructions for how to use this? I tried putting the rate at 0, and then at 10,000, and at an increment of 1000 every so often and it hasn't done anything.

There are a lot of moving parts in the networking stack. I'm going to (finally) implement low-overhead shared memory when a local link is detected, which should make communication pretty much instantaneous between vba-m and dolphin. At least then we can have dependable, low latency, and synchronous transfer method on which to experiment. Hopefully just implementing shared memory will fix some things, and we can compare the TCP implementation to that in order to see what's going wrong.

I've gotten vba-m building simply on VS2013 here: https://github.com/shuffle2/vba-m (this is also based on an older version of vba-m). Patches are welcome to port any (useful) changes from vba-m svn which are not included in this branch, but for the most part it is a snapshot to change vba-m for dolphin compatibility reasons.

@chris: there is no way to detect the rate as GBA joybus act as a slave it can't initiate a transfer, it can only reply when gamecube send something, so the one who have the actual rate is the gamecube.

@JMC: its just a simple interval from the first attempt to check incoming data and the next time. The value used by the original VBA-M is 12288, you can try using higher value than that.

@godisgovernment: yes it might reduce the overhead and slightly improved performance, but the main culprit of the miscommunication isn't on how fast it was transfered. i think it's related to the joybus state, whenever i tried to make VBA-M to check for incoming data on every tick it makes dolphin performance higher, but it makes Dolphin sending a command to read the GBA's joybus state for too many times instead of starting the actual communication.

Btw, with shared memory you won't be able to capture the packets using sniffing tools like tcp/ip.

Speed becomes an issue when the networking stack can do non-deterministic buffering and things behind your back, and as we can already see it varies a lot if you have a slow computer or not, plus other factors :p I think it will also help performance - since the transfers must be synchronous you often end up with one end waiting for the other.

You're right, increasing frequency of checking the channel for a pending command is also something that needs to be done. With shared memory it should be pretty straightforward to just plop a synchronization primitive into the shared region and directly trigger events between the processes. That way the gba core can realize there is new data extremely quickly - it doesn't need to poll anymore.

Explaining why this is an issue...:
The GC is essentially the bus master, and pushes commands/pulls responses. The GBA only reacts to commands. The bus is serial interface, which is implemented on GC with some scratch buffer (0x80 bytes). On real hardware, GC software would begin serial transfer and later receive an interrupt indicating that it should copy from the scratch buffer since the transfer is done. On dolphin the ppc is essentially stalled while the transfer takes place. This fact alone shouldn't cause an issue because vba-m is also processing the serial transfer instead of running arm cycles, so it also appears instantaneous there. So (as you've noticed), the comes from the time period between when dolphin asserts that there is some command and when the arm core essentially halts and handles the command. If vba-m is too slow to notice a new command, the arm core will eventually think that the GC has stopped talking to it just because of the skew. If it's too fast, we run the risk of GBA spending too much time in interrupt handlers which would lead to not enough "work" being done by the GBA, or it detecting an error condition as it probably isn't supposed to be possible to generate such interrupts so rapidly. Note: perhaps this is something else we should watch for - attempting to raise an interrupt in vba-m when it's still busy handling previous interrupt.
And then there is the issue that each GBA/GC may be running at non-realspeed, which will probably just have to be avoided somehow (ie if dolphin is maxing out at 70% speed, probably have to throttle vba-m too).

Logging the transfer isn't really an issue, if we really wanted we could just dump shared memory transactions to a capture file. It's all on the local system so you can just use the system clock without much complexity.

I've tried to check incomming data as soon as possible before (ie. on every CPU tick) it does improve the performance on Dolphin, but both of them failed to communicate properly (ie. VBA-M stuck with the 'Nintendo' text changing colors)

I think the reason for the miscommunication is because GBA BIOS program might using a very short timeout whenever it's waiting for a command, and if it gets timeout it will think the JOYBUS is disconnected (ie. showing "Waiting for Connection")

Anyway, i just download FFCC (US) and tested it, and yes it doesn't works with my old build.
After making a few more checking on the JOYBUS Control and State registers before reading the sockets and reply it, i finally managed to get up to the Intro scene after choosing Multiplayer.

However, as you can see in my screenshot, it didn't show any message in VBA-M, is this intro not suppose to be skip-able? How do i skip this slow motion intro?

"After making a few more checking on the JOYBUS Control and State registers before reading the sockets and reply it"

Yes, I think you happen to be covering both points I mentioned (gba can't be too slow or too fast), at least well enough that it works better for you.

To rephrase, while checking incoming data quickly is important, it's also important to realize that the gba software needs time (ie time spent running arm cycles) in order to process some event that has occurred on the serial link. Probably a decent amount of time, since the cpu is quite slow :p

Do you have patches available somewhere? (patches, please don't copy the code into this issue).

iirc, there is no way to skip FF:CC cutscenes :(

Sadly it can't be skipped and to make matters worse it's long and boring as
hell. I usually go do something else for the 4~ minutes it plays for.

Question about the shared memory approach: that would make it impossible to
have VBA-M on one machine and dolphin on another, wouldn't it?

@chris: It would fall back to networking if not on the same computer. Hopefully networking will still work, it will just be easier to tell what's going wrong if we have some correct implementation to compare to.

Ah, alright. I can't wait for this to be fixed. My SPs are starting to
die :(

Since it's not skip-able, i guess it's correct not to show the "Look at your TV" message.
Here is the new build if anyone want to tr it https://www.dropbox.com/s/trqx5c2pheelsu5/VisualBoyAdvance-M1030d.zip

I'm not sure whether all the checking needed are there or not, because GBATEK didn't give much information about when is the right time to expect a command. Since sometimes i'm having difficulties to get the colorful "Nintendo" from showing, it probably need more checking.

Here is tips if you're having difficulties to get the Nintendo text from showing:
1). Run GBA BIOS
2). Run the game in Dolphin with GBA controller
3). when the game screen is started to show, activate joybus on VBA-M

If you gets "Waiting for connection" message for too long and it doesn't restore it self after awhile, try changing the Interval (double the value or reduce the value by half)

Sorry i never do any patch before so i don't have it, and the files i modified since last year are no longer suitable with the latest VBA-M svn (major changes)

Ok, well if you provide the changed files somewhere, I can create a diff and apply the changes as a branch in my github repo or something :)

The changes for dolphin should be easier to show?

Why not use the latest VBA-M svn?

Ah the "Why not use the latest VBA-M svn?" question XD
Because at the time i was fixing the linking bug on VBA-M that nobody fixing it for years, svn1030 was the latest one.
But then i caught 3 kind of illness and bedridden for almost a year, and at the time i'm cured i barely remember what i was working on, and recently regained some of my memory about it and i decided to continue fixing the wireless linking,
but there have been major changes since svn1030 and i feels lazy to start all over again ^_^

I'm planning to release the full source code (which have been made into a branch at SF) later after receiving a few feedbacks about the linking stability from VBA-M users later.

After rechecking the code in dolphin again, i think the changes for dolphin i posted above aren't really necessary because it's a fix for blocking sockets, and apparently dolphin uses non-blocking socket (by calling: "server.SetBlocking(false);") unless someone is changing the blocking to non-blocking later.

So that patch for dolphin is more of a prevention of a possible bug that may appear in the future (just in case someone tried to use blocking socket later)

Because it's a pain in the ass to build the latest VBA-M SVN, at least, that was my issue.

@anr2000: the SetBlocking(false) only applies to the server listening socket. Client sockets are blocking. As I've described above (and the comment on the function states), this is definitely required.

Owh, then the fix is needed :D i couldn't compile or debug dolphin with vs2010 so i can only trace the function by checking who referencing it, i thought it was related to joybus socket handler ^_^

Anyway, there are 2 more thing that i think need to be checked before replying a command, but if my latest build works for you guys i don't need to make additional checking (may be later)

Testing games over and over on a slow computer with low framerate can be frustating, especially if the intro can't be skipped :(

Setting the client socket to non-blocking is definitely not a fix. It will break the connection.

I know this is probably stupid to ask, but do we have any idea why tons of games run 1 fps during connection, other games run about 10 fps without turbo mode, and two games (namely Metroid Prime and Four Swords Adventures (but not the Japanese + version)) run okay?

Yes, just changing the blocking to non-blocking will only brings more issue, that's why i posted a fix for dolphin yesterday so it can handle blocking socket properly to prevent it from blocking unintentionally (trying to read a data which is not suppose to exist)

How the game perform when using joybus are different depend on what kind of data being transferred, since GBA joybus aren't simply sending keystroke, they also used to send game data/contents (ie. sprite/tiles etc.)

At the time the framerate is higher usually the game only send a command to check the joybus state on GBA side (ie. waiting for a keystroke or something simple like that)
But when joybus being used to send game data/contents it will cause a slowdown, due to higher traffic, and slower response on the GBA because the GBA need to process the game data content first(ie. rendering it to the screen) before checking the next command.

When using turbo mode, GBA CPU will be overclocked thus can process the data faster and eventually response faster to commands.

I realize that, but shouldn't there be something on one side, the other side, or both that realizes "oh shit, I need to send more/less data"?

I know this disconnecting thing is a problem, but data rates cause huge problems too!

There is also a possibility of miscommunication which can slowdown further,
for example when one side expecting a certain data but the data being received is not the right one, it will try again over and over until it gets the right one and move on.

That's an excellent point. An update on games that I can get to currently connect:

Four Swords Adventures (got 4 players full speed with my overclock)
Metroid Prime (no known issues)
Wind Waker (Needs the hacked VBA/Dolphin provided earlier)
Sonic Adventure Tiny Chao Garden (1/4th of an fps)I was unable to get
Sonic Adventure 2 Tiny Chao Garden (1/4th of an fps)
Tetra's Trackers (Disconnects are common, but can work a little, runs very slow)
Final Fantasy Crystal Chronicles (only with a savestate, or using the hacked VBA/Dolphin)

Using your hacked build and hacked GBA, I actually got FF Crystal Chronicles working pretty much perfectly, just a tad slow just now. So, nice? Even if it's sorta broken, it fixes connecting in two games.

Did you get the "Waiting for connection" message with FF CC ? sometimes i'm getting that message in VBA-M screen during intro scene. Sometimes it restore itself after awhile and sometime i need to change (increase the interval) to restore the connection.

since i haven't found a good documentation of a proper joybus communication, it won't be perfect, my only reference is GBATEK and don't know how joybus being treated on gamecube side.

Btw, i've attached a modified file for dolphin that contains the fix i posted yesterday (just in case someone want to make the patch file) :)

I get lost/waiting for connection in every game after a while using your builds :(

It's nice to see it connecting though; not sure if it's progress or a false lead considering all the other problems.

Are you using the default interval value?
If you are, try using the interval value used by the original VBA-M which is 12288

After testing it more on FFCC looks like turbo was the one causing too many connection issue :( using throttle 200% is much more stable, i can even use 0 interval w/o much problem compared to turbo during gameplay.

Using Turbo or throttle higher than 200% seems to increase the chance of "waiting for connection" to occur.

Here is a new build https://www.dropbox.com/s/trqx5c2pheelsu5/VisualBoyAdvance-M1030d.zip

Hey guys. Any recent progress on this? I'm not very savvy with dolphin but recently I've been trying to set crystal chronicles up over netplay.

I've tried to get save states for each of the 4 GBAs without much luck, but ultimately it seems like it'd remain unplayable due to the frame rate loss; connect more than 1 GBA and dolphin is reduced to 2 FPS at best.

Has there been much luck with these hacked builds?

No. Netplay isn't happening on this game for a long time; we still need to get it working on one computer then find a crazy dev to fix it on netplay.

The best I can do with non-hacked builds is about 20 fps/40 vps with 4 players on my computer, but the disconnects make it impossible to play unfortunately.

I've added another joybus option called "Fast Status Reply" to improve dolphin performance.
since command 0x00 only used to get the GBA's joybus state and doesn't change any register or data i can safely reply it as soon as possible even when the GBA bios is still processing data from previous command.

This will significantly improve Dolphin performance (it doesn't need to wait too long just to check the state) when VBA-M not using turbo (almost as fast as turbo especially with 0 interval), since turbo affect the stability too much it's not recommended to use turbo.

If you're getting too much "waiting for connection" issue try lowering VBA-M speed(throttle) and increase the interval by large number.

I guess this is the best i can do to improve the performance while maintaining stability.
Here is the new build https://www.dropbox.com/s/trqx5c2pheelsu5/VisualBoyAdvance-M1030d.zip

Four Swords is unaffected, Final Fantasy Crystal Chronicles will not connect with fast reply.

Does this require a special build of Dolphin? I tried connecting VBA-M to
Dolphin 4.0.1 and it caused the emulation window to freeze. Trying to stop
emulating caused Dolphin to crash.

Try enabling the Auto-Detect, it will automatically try to connect.
1). Run GBA BIOS iwth auto detect,
2). when VBA-M shows a lag (attempting to connect) run the game in dolphin

@chris: you'll need to use the patched "Dolphin 4.0-1547" posted a few posts above to fix the freezing issue on dolphin.

Alrighty. The comment number is 116 in case anyone else wants to know.

My issue with the freezing and crashing still persists.

This is a feature for advanced users only, if you're never familiar with both emulators and how they work, and the pitfalls of this feature, you should probably stay away.

I understand how they work, the issues being faced, etc. I'm just trying
to help provide more information

Anywho, third time it worked and from then on it worked fine. No idea
why.

My experience:

If I changed the interval from 10000 to anything else I would get
disconnects.

With Fast Status Reply enabled:
Without turbo on my framerate is about 2 FPS 4 VPS - 7%. With turbo set to
400+% I get about 10 FPS 20 VPS - 30%.

With Fast Status reply disabled:
Without turbo on my framerate is about 1 FPS 1VPS - 1%. With turbo set to
400+% I get about 1 FPS 2 VPS - 3%.

Performance wise this is worse than vanilla VBA-M and Dolphin BUT there
isn't any issues with the initial connecting, as with vanilla you would
have to use a savestate and hope for the best.

I've also noticed that if you try and stop the emulation before closing
VBA-M, Dolphin will hang until VBA-M is closed.

Try using throttle 200% in VBA-M and change the interval to 0-2000 after you enter gameplay (no longer detecting joining players)

On my laptop (core-i3 2.2ghz & geforce 610m 1gb)
With vanilla VBA-M (svn1229):
I'm getting 3 FPS during Single/Multiplayer screen w/ VBA-M 100% and 11-12 FPS w/ turbo
I'm getting 5-7 FPS during gameplay (Port Tipa) w/ 100% and 14-16 FPS w/ turbo (sometimes i also getting connection issue and it doesn't seems to be able to recover it self after awhile)

With my Build(with Fast Reply and 2000 interval):
I'm getting 7-8 FPS during Single/Multiplayer screen w/ 100% and 12-13 FPS w/ turbo
I'm getting 12-13 FPS during gameplay (Port Tipa) w/ 100% and 17-18 FPS w/ turbo.
connection issue usually able to recover itself after awhile (also sometimes it's showing "waiting for connection" but the buttons can still be used as input)

So it's an improvement.

Regarding the stop-responding dolphin, i think it's because with auto-detect VBA-M will try to connect again when the socket is not connected, and it seems dolphin still try to connect also even though it's not suppose to connect when exiting.

I don't get how this is an improvement. If you do manage to get GBA's to connect in regular VBA and regular dolphin, you can get full speed with 2 players and over 20 fps with 4.

i don't know what kind of powerful computer you're using :) but on my tests with my computer it's faster and less connection issue.

To show the performance IS better with actual numbers I ran vanilla and
jotted down the numbers and settings.

Also, seems I forgot to list the CPU and GPU last time. i5-3470 (3.6 GHz,
Quad Core) and a Radeon 7850.

No turbo
5 FPS 9 VPS - 11%

Turbo at 200%
17 FPS 31 VPS - 52%

Turbo at 400%
No difference from 200%

Vanilla + Turbo 200% is nearly twice as fast as the modified build versions.

Hmm.. that is odd, i don't know why my build make dolphin slower on stronger computer, but since i don't have such computer to test with i probably won't be able to find out the reason.

Btw, with vanilla VBA-M which version are you using? the latest one or old one?
i wonder if the old one have different joybus code

For me it's VBA-M 1229 (latest release) + Dolphin 4.0.1

On vanilla 1030 VBA-M

No throttle
5 FPS 10 VPS - 17%

Throttle 200%
11 FPS 24 VPS - 11%40

Throttle 400%
No change.

So 1229 is actually a decent bit faster than 1030.

Also, I noticed that disconnects are far more prevalent in 1030. VBA-M
disconnected on me twice with in just as many minutes.

Oops, thats suppose to read as 41%, not 11%40.

Speed isn't the problem here; the problem is that the thing doesn't work right at all. Simply flipping numbers around isn't going to help. This is more or less just trying to squeeze juice out of a rotten orange.... do oranges rot? I'm sure they do.

Yes, the current implementation is pretty broken, but these simple tests
and their numbers help point to the idea that 1229 is probably doing
something right, at least more right than 1030.

Also, 1030's code base is more than 2 and a half years out of date. Again,
why is it being used?

You can get juice out of a fermented orange, but not a rotten one. That's
just slim.

Ok, I've made several build to separate all of the thing i changed (was suppose to be to improve the performance on my computer) so i can figured out which one that causing a slowdown on a fast computer.
I've also made several build of the latest svn by using a slightly different joybus fix (suppose to improve the stability) but i don't know which one is the best for fast computer.
All of these build doesn't have much difference on my laptop but may affect fast computers.

Here are the builds https://www.dropbox.com/s/28w5tg1hm0pe10z/VBAMTestBuild.zip
Let me know which one is the best in performance/stability and which one is the worse (so i can remove the bad code)

I got "Error mapping file" for the 1030 builds and "Error opening event"
for the 1231 builds.

Apparently I still had VBA-M open. Oops. The builds open now, but the are
giving me a "Failed to load library ENU" error before the GUI appears.

Build 1 of 1030:

No throttle
2 FPS 4 VPS - 6%

Throttle 200%
9 FPS 17 VPS - 29%

Throttle 400%
18 FPS 36 VPS - 60%

Build 2:

No throttle
2 FPS 4 VPS - 6%

Throttle 200%
4 FPS 8 VPS - 13%

Throttle 400%
11 FPS 21 VPS - 36%

Build 3, 4, and 5 all had the same stats

No throttle
3 FPS 5 VPS - 9%

Throttle 200%
5 FPS 11 VPS - 18%

Throttle 400%
12 FPS 23 VPS - 38%

Build 1 and 2 of 1231 had the same stats

No throttle
0 FPS 1 VPS - 1%

Throttle 200%
5 FPS 11 VPS - 18%

Throttle 400%
No change

Build 3:
No Throttle:
3 FPS 5 VPS - 9%

Throttle 200%
21 FPS 40 VPS - 66% - It should be noted that it reached 30/60/100% right
before VBA displayed the message for me to look at the TV

Throttle 400%
No change

I also noticed that sometimes when the throttle is set above 100% Dolphin's
FPS will drop to 0 but the VPS will reach 60. Closing VBA-M will cause
Dolphin to reach my usual 30/60/100%. This was more prevelant with builds
3,4,and 5 of 1030 and builds 1 and 2 of 1231.

Also, in the 1030 builds I never once saw anything other than the Gameboy
logo. The 1231 builds were fine

To fix the "Failed to load library ENU" issue you'll need to change VBA-M languange to English.

Is svn1231 still slower than vanilla VBA-M?
With svn1231 did you get's connection issue even when using turbo?
During my test svn1231 only stable if i use turbo, w/o turbo i usually get's "waiting for connection" and can't recover it self.

Are all of the builds on 1030d have the same connection issue regardless of using turbo/not?

languange to English.

Got it, thanks

I'm having issues with connecting (FPS drops to 0 VPS hits 60, issue) using
vanilla, but when it does work it's the same as build 3 of 1231.

Kind of. I decided to do a little in game testing and found that I can't
do button combos reliably nor hold down the button. The character was
acting like I was pressing the button and then releasing it for a very
short period of time.

But I never suffered from an unrecoverable disconnect.

of using turbo/not?

Yes, not a single one connected regardless of settings.

The issue with hold down is it on vanilla or all of svn1231?
i didn't have any issue holding down the arrow to move around during my test on svn1231 with turbo.

Among all the test builds i made is svn1231 Test3 is the best one for you?

I've made 2 more builds of svn1231, compare these with the best build of svn1231 from previous test to see whether this one is better or not, also compare it with vanilla 1229.

Hopefully this will be the last test.

oops forgot the link, here https://www.dropbox.com/s/bjcyfwum9stl7ma/vbam1231test.zip

Test3 is indeed the best. I did a bit more testing and I noticed when
transitioning to different areas VBA-M will briefly flash that it has lost
connection. This does NOT happen on the real hardware. Might be worth
checking out.

I'll have to compare them tomorrow. It's getting late here and I still
have some things I need to do.

Is that connection issue during transition happened on Test3?
i didn't get that issue on Test3 as long i press the turbo button while entering the door/area.

Yes, it was with Test3. Here are the Test Results

Build 4:
No Throttle:
3 FPS 5 VPS - 9%

Throttle 200%
18 FPS 35 VPS - 59% - This build also reached 30/60/100% right before VBA
displayed the message for me to look at the TV

Throttle 400%
No change

Build 5 (never actually connected)
No Throttle:
0 FPS 1 VPS - 1%

Throttle 200%
5 FPS 9 VPS - 15% -

Throttle 400%
No change

Build 3 is so far the best. No issues with connect that I've seen,
disconnects do not seem to be as common (need someone else to confirm), and
has at least the same performance as vanilla.

Ok, thanks for the feedback.

Build3 (and vanilla) need to use Turbo (400%+) in order to prevent it from showing "Waiting for connection" issue during my test.

Need any other tests?

well i changed something again but not sure whether this one is better or not compared to svn1231 or vanilla

Here it is https://www.dropbox.com/s/wt4pvuhc07gjo43/VisualBoyAdvance-M1030d1.zip
Try using the default setting first, if you gets connection issue try changing the interval to 12000 or 13000

Here is another build that uses the same code with svn1231 Test3 https://www.dropbox.com/s/ka2vfh1r70toapy/VisualBoyAdvance-M1030d2.zip

During my test with zelda four swords this one seems to be faster compared to vanilla/svn1231 test3, since this is based on the old joybus code only interval option can be used, the other options (Fast Reply and Peek) aren't used.

Here's something I think you guys will like.

https://www.youtube.com/watch?feature=player_embedded&v=IkjMn7WcgvE

You tease us with this and yet you show us no FF:CC. You are an evil person

That said, sweet. Can't wait to see more games supported.

Does the performance difference significant between shared memory system and tcp/ip?

No idea; Higan is a lot harder to run than VBA though. VBA isn't causing a performance drain anyway; it's just tons of waiting, too much waiting.

It's because the waiting on VBA-M (ie. blocking socket) is using Sleep so it doesn't uses CPU resource, Higan drained CPU resource probably because it doesn't sleep much while waiting.

i was having similar issue when i was working on wireless socket handler on VBA-M (the handler runs on a different thread), so i added SleepEx(1,TRUE) every 160ms(10frames) and it significantly reduce the CPU resource w/o noticible performance impact)

Btw, based on the official documentation of GBA, joybus have 160ms timeout, if the GBA didn't get any SIO irq within 160ms the link will be considered as lost (ie. cable unplugged) and when it's re-plugged it will be treated as a reset command.
This information didn't exist at GBATEK :(

I added built-in joybus emulation, so bios file no longer needed https://www.dropbox.com/s/trqx5c2pheelsu5/VisualBoyAdvance-M1030d.zip

I still don't know how to make FF:CC stable :( as different games uses different code to handle joybus commands, it's difficult predict when they're done processing old data and are ready to receive new data, cutting in the middle of data processing might cause them to think there is connection issue.

I think JMC4789's approach might be best. Might want to get with him(her?)
so you guys can work together on this issue.

Well i won't be working on joybus anymore (need to start working on GBA singlepack), unless there is a game that doesn't works at all with current joybus codes.

Awww, oh well.

I've always wanted to play FFCC multiplayer so I got this set up, but I'm having the same problem as Frozs (Feb 27, 2014). I can play the game, but when I hold down the attack button it usually just attacks, sometimes charges for a few frames then cancels, and very rarely lets me actually finish charging.

I disabled idle skipping in dolphin, but it didn't seem to help.

Is there a fix for this particular issue or is anyone still working on the project?

Lots of people are still working on the project. You can view the latest commits at https://github.com/dolphin-emu/dolphin/commits/master . However, as far as I know, nobody is actively working on this particular issue at the moment. You may want to check on the forums.

I talked to JMC on reddit a week or two ago about this and they said that
no one has really worked on the issue. The approach where Higan and
Dolphin share memory looks to be great, it is just that no one is working
on it.

In a stunning turn, skidau decided to go back to VBA without using shared memory (as it was actually less accurate to have that much bandwidth/speed, I guess?) Anyway, long story short, progress is being made.

https://dl.dropboxusercontent.com/u/484730/4PlayerFourSwords.jpg
https://dl.dropboxusercontent.com/u/484730/FFCC.jpg

Do you still need a super computer (your words, not mine) to do 3+ gba
connects or has Skid solved that issue in the last couple days?

It really comes to the point where you have to be able to run all five emus without your computer getting 100% maxed out. I just have a core i5 3570k. I think people with AMDs will actually be the ones that don't have a problem with this.

emus without your computer getting 100% maxed out.

I think thats a yes?

Ha, I don't think you realize how high end that is. The i5s are in the high
end bracket in both cost and performance, while the the 3570k being at the
very top of that category for the Ivy family. It also costs over $200,
which is more than most people are willing to spend.

Think about what you're attempting to do. Linking 5 different emulators together in a manner where they all have to communicate to one another. If you can think of a way to do that on a slow computer, then go for it.

I imagine the performance requirements would scale down the fewer players you have. What do you think they would be for two players?

Are these improvements in the master branch? As in, are they available for the general public to try out? 30 FPS on any multiplayer configuration in FFCC is pretty impressive.

I have made available a test build and am looking for test results. Please test this version out and post the results to the thread below. More information is available in the thread. This WIP build is a Windows build.
http://www.mediafire.com/download/qtgcgo0k6d4l15z/Dolphin_VBA-M_GC_GBA_link_test.7z

https://forums.dolphin-emu.org/Thread-green-notice-development-thread-testers-wanted-gba-gamecube-link-cable-test-build

Works the best I've seen so far, but the characters still stutter. If you want to eliminate the stuttering, with ALL GBAs linked, press select to switch to GBA mode (it may press it for you twice), press B to go to the menus, select again, and viola.

The reason why the characters are stuttering (just mentioning for the sake of documentation) is because it's updating the maps, player locations, etc constantly on every GBA screen when players move around. When your character moves without the radar screen on, it moves lag-free.

Again, the most lag I've seen is in River Belle. I have no idea why. Every area I've seen so far, even the cave where you cross some sort of rift towards the top of the first map, has 30 frames pretty consistently.

So yea, this is pretty playable. It's just a little laggy with River Belle. I'd like e-mails (Or simply replies here I guess to help others) to links with best configurations for FFCC for best performance if possible.

Have updated the builds with various fixes, speed ups and slow downs. Both Dolphin and VBA-M builds have to be used together. The WIP builds are Windows builds.

http://dl.dolphin-emu.org/prs/pr-2139-dolphin-latest-x64.7z

Updated VBA-M and patch:
http://www.mediafire.com/download/d1h8u2hokg4b1ed/VBA-M_update_GameCube_cable.zip

Same thread with more info:
https://forums.dolphin-emu.org/Thread-green-notice-development-thread-testers-wanted-gba-gamecube-link-cable-test-build

Last I checked, spell casting was extremely problematic, making the game
impossible to complete in multiplayer. Has this been fixed yet?

That's not within the scope of the issue. You can make it more consistent by turning off the map and switching to another of the menus though.

JMC4789 wrote:

That's not within the scope of the issue. You can make it more consistent by turning off the map and switching to another of the menus though.

Hi, i don´t know if any issue like this remains in the entire Dolphin´s issues page, but actually, the FF Crystal Chronicles is 100% playable at full speed with 4 instances of VBA-M (In the wikia says that is too slow, but i can´t edit and change the text, i don´t have access)

So, the FFCC is fully playable right now (at least with latest dolphin versions) maybe the only problem remaining is the Goblin Wall.