link cable emulation between multiple instances about sameboy

[dev01111]

It was planned and mostly completed for v0.12, but sadly it had severe performance issues I've haven't managed to solve yet.

@LIJI32 Please put more attention into this issue. I mean, it's 0.15.x now, and we STILL haven't had network play arrive to SameBoy yet. I'd LOVE to have network play as a feature so I can battle Pokemon with my friends. Please work harder, I'd be willing to help!

[LIJI32]

It was planned and mostly completed for v0.12, but sadly it had severe performance issues I've haven't managed to solve yet.

[andres-asm]

Woo

[andres-asm]

geezzz...

[LIJI32]

Glad you got it fixed. :)

For extra credits, you should add IR support, the API is quite simple:

void GB_set_infrared_input(GB_gameboy_t *gb, bool state);
void GB_set_infrared_callback(GB_gameboy_t *gb, GB_infrared_callback_t callback);

[andres-asm]

Ok this is great :)

Thanks for your help @LIJI32
still way to go for a stable proper implementation, I think we're gonna need a few API (libretro API) additions.

[andres-asm]

@LIJI32 finally figured out the GUI https://youtu.be/A_noOBHC3Z8

[LIJI32]

Sadly yes. While I do have a working POC, the performance penalty is too high and needs more work.

Ah man I thought it will come soon...
I am still struggling with getting netplay to work with the libretro core.

[LIJI32]

I plan to add netplay and multiple instances link cable emulation in version 0.11 (version 0.10 will be released this month).

[JulienNoble]

nice! Thanks 👍

[andres-asm]

That would be amazing, for the libretro core I could make a single libretro core run two instances if you can help me to link them :)

[LIJI32]

Actually, adding it to the libretro core might actually be already possible as SameBoy already emulates the Link Cable – the things missing in the Cocoa and SDL ports is the GUI, and networking and synchronization code, which are already provided by libretro itself as far as I know.

The Link Cable API is:

• GB_set_serial_transfer_start_callback – called when the GB is in master mode and starts sending a byte of data.
• GB_set_serial_transfer_end_callback – called when the GB is in master mode and finishes sending a byte of data. The callback should return the byte received by the other side.
• GB_serial_get_data – call this function when the GB is in slave mode; it returns the data the GB wants to send over the cable. This should be called when the master side requests data from the slave side.
• GB_serial_set_data – call this function when the GB is in slave mode to set the data the GB would read. This should be called when the master side provides data to the slave side.

[andres-asm]

I wanted to start working on that, so I have a core that runs 2 instances (thanks to @bparker06 for helping me with the blitting issue)

But I have exactly half performance now, I suspect because of the vblank thing, not sure if there's a sleep somewhere that causes this.

Once we manage to iron these out I can start trying to hook up the proper API

[andres-asm]

Errr... fixed the slowdown by commenting the audio_callback from GB2... guess that means I need to try to hookup serial now 📦

[LIJI32]

Oh looking cool! Slowdown makes sense because IIRC libretro times everything by the audio, and you were giving it 2 times the amount of audio. I hope frame synchronization would be good enough for serial though, it might be tricky.

[andres-asm]

Well I have questions about the API, do I have to actually implement the callback for link cable?

Because as far as I can see in printer.c your actual implementation is there, so I guess I would need to know exactly what needs to be sent?

[LIJI32]

The printer is always running is slave mode (therefore the Game Boy runs in master mode), therefore the Game Boy side uses the callback API. Since you're emulating two Game Boys, both need to implement both master and slave logic (Because you can't know which will be master).

Basically it's very simple, you set configure the callbacks for both instances:

• When GB_set_serial_transfer_start_callback is called for GB1, you call GB_serial_set_data on GB2 with byte_received, and vice versa
• When GB_set_serial_transfer_start_callback is called for GB1, you return GB_serial_get_data on GB2, and vice versa.

Assuming both instances are synchronized well enough, this should just work :)

[andres-asm]

Well, it does.. something

https://www.youtube.com/watch?v=m62frQp3DPg&feature=youtu.be

[andres-asm]

What should I return in the end callback?

[LIJI32]

This is.. interesting... The end callback should return the value received from the other side of the serial. I.e. GB_serial_get_data(&gb2) for gb1 and GB_serial_get_data(&gb1) for gb2

[andres-asm]

Ok that makes more sense now, I think you made a typo in your explanation
Let me test.

[andres-asm]

Ok both "linked now" very slowly and input no longer worked :P
But yay progress

[andres-asm]

Progress?

https://youtu.be/BrNBAqrzztc

static void serial_start1(GB_gameboy_t *gb, uint8_t byte_received)
{
   GB_serial_set_data(&gb2, byte_received);
}

static uint8_t serial_end1(GB_gameboy_t *gb)
{
   return GB_serial_get_data(&gb2);;
}

static void serial_start2(GB_gameboy_t *gb, uint8_t byte_received)
{
   GB_serial_set_data(&gb1, byte_received);
   
}

static uint8_t serial_end2(GB_gameboy_t *gb)
{
   return GB_serial_get_data(&gb1);;
}

This is my code

[LIJI32]

Looks correct other than the nop call to GB_serial_get_data(&gb2). Can you test a Pokémon link battle in GSC? I'm relatively familiar with serial oddities there.

[andres-asm]

*GBC/GSC I guess?
I think I need a save for that? also I need to hookup saves for GB #2 :P

[LIJI32]

Yeah you'd need a save for that (otherwise it'd be very annoying) but it can be the same save for both instances. Any Gen 2 game would work.

[andres-asm]

I just get this on pokemon

[andres-asm]

I pushed it into a branch in case you want to check it out
https://github.com/libretro/SameBoy/tree/link

[LIJI32]

Exactly what I thought. Since you run the instances frame-by-frame, the master instance is always one frame (about 1/60 seconds) ahead of the slave one. The serial, however, runs in 8192Hz, meaning it sends about 17 bytes per frame. This means the master instance sends the slave instance 17 bytes before the slave instance gets a chance to process anything, and then it effectively processes the last byte 17 times in a row.

The way to solve it is by redoing how synchronizing the instances is done. An easy, naive, wrong, but still better way of doing it is by using GB_run instead of GB_run_frame, and using a vblank callback to end the run loop manually. A better method would require a slight API improvement on my side.

[andres-asm]

What function would I use to end the loop in the vblank callback?

[LIJI32]

Set a VBlank callback for both instances that simply sets a bool to true. Then, instead of using GB_run_frame use:

while (!vblank1_occurred || !vblank2_occured) {
    GB_run(&gb1);
    GB_run(&gb2);
}
vblank1_occurred = vblank2_occured = false;

[andres-asm]

Wasn't able to figure it out :p

[LIJI32]

I'll have a look at it tomorrow :)

[andres-asm]

Cool ty!

[andres-asm]

Hey, did you have a chance to take a look?

[LIJI32]

Yeah, I just finished adding proper synchronization between the two instances yet Tetris 2 behaves the same. I'll have to investigate further I guess.

[LIJI32]

Tetris 2 does seem to work on an old internal build of SameBoy 0.7 that has experimental Netplay support, so it's clearly not an emulation bug.

[andres-asm]

ahh, ok, well let me know if I can do anything :)

Hey I like netplay.
If I can help in anything I would.

[LIJI32]

Fixed it! I'll create a pull request for your branch in a minute. It has been a while since I touched serial emulation. Basically the code I gave you had a race condition where in some (effectively all?) games the "slave" Game Boy "skips" the first byte it wants to send, essentially making the two Game Boys completely out of sync. Together with the improper synchronization, it makes sense nothing worked.

[LIJI32]

I guess it'd be easier to just submit a patch. Note that you will need my latest commit from master for it to use (it adds a return value to GB_run that allows tight synchronization between instances)

patch.txt

[andres-asm]

Cool, I'll try it ASAP!

[andres-asm]

Just did a test for the lulz, and loaded a state (on GB1 only) while trading pokemon and GB2 ended up completely locked on a Please Wait!

Would that happen on a real GB? (unplugging while on the trade screen)

Anyway cool stuff, so many things to fix / provision now!

[LIJI32]

This is not equivalent to unplugging the cable – as data is still being received and sent by both sides, but they're completely out of sync. A disconnected cable is quite easy for a Game Boy game to detect – the slave side would simply not receive any more data, while the master side will only receive 0xFF bytes.

[andres-asm]

The link branch is almost complete now but I don't think merging this would be good, maybe we can keep this downstream only for now (my code is a bit messy even though I tried to clean it up as much as possible)

Regardless, it works, even in netplay but there are still several things that will need to be addressed by the libretro API (it's the first such case we have) to allow loading different content in each slot, and also different saves per slot OFC)

I made it possible to change models for each slot, and link cable is a toggle, not hardcoded anymore. @bparker06 is adding left-right mode soon too.

Check it out.

Check it out

[andres-asm]

For some reason Super Mario Bros DX fails, tetris and pokemon are fine tho, weird because Mario worked earlier before I made it use for loops...

I didn't change anything timing related though.
libretro@052bddf

Quite weird... I don't see any mistakes immediately between what worked and what doesn't

[andres-asm]

It's definitely something between those two though... weird
If I checkout the older commit all games link properly

[andres-asm]

I redid that commit in stages, first I converted everything from gb1, gb2 to gb[0], gb[1] and it broke, so... converting it to an array breaks it

https://hastebin.com/amukucepul.cs

Serial read request while using internal clock.
Serial write request while using internal clock.

[andres-asm]

ok nvm came up with a (lame) fix, it's a rookie mistake and I'll have to read more on pointers to pointers to array members to fully understand this (not really a dev)

[cyberic99]

So what is the status regarding @JulienNoble initial feature request?
Is there a way to externally receive or send bytes to the link port?

[andres-asm]

After some sleep I was able to figure it properly and force pushed a fix..
The problem was that the serial_end callbacks have GB_gameboy_t *gb in the signature and I was using that exact name for my gameboy array...

static uint8_t serial_end1(GB_gameboy_t *gb)
{
    uint8_t ret = GB_serial_get_data(&gb[1]);
    GB_serial_set_data(&gb[1], byte_to_send1);
    return ret;
}

So I renamed my array and boom! back into working status, sorry for all the noise

[andres-asm]

@cyberic99 the API is quite easy, you just have to write the networking code or wait for @LIJI32's implementation

[Tatsuya79]

Nice work.
It adds 1 frame of input lag for player 1 and 2 frames for player 2 though.
(after a fix similar to this one couldn't make it faster. +2 frames of lag for each player before any fix.)

edit: actually it is variable for P2, sometimes 1 frame sometimes 2 of lag with GB_update_keys_status moved into retro_run before GB_run_frame.

[andres-asm]

I guess the only way to make both run perfectly synced and without the extra delay would be to run gb2 in a separate thread (or co-thread via libco)

[andres-asm]

@LIJI32 the current link cable branch is rather mature now, and having two makes it a moving target and harder to mantain, maybe we could promote this to master.
I even added support to load different games for each slot (subsystem in Libretro lingo)

The only thing I couldn't figure is Auto model selection (if I enable it it crashes when switching models even in single mode so I disabled it by removing Auto from the core options).

Let me know if you agree.

Too load in link mode you have to do: retroarch -L corename $rom1 --subsystem gb_link_2p $rom2

I have to work on the RA side of things to support this use case via GUI

[andres-asm]

One other thing, I was trying to make link cable a runtime option, but there is no API to clear the serial callbacks, I tried using GB_disconnect_serial but it seems it's for something else.

[andres-asm]

[LIJI32]

As for threading – this won't help performance as you would need to sync between the threads anyway. The current way of running is probably equivalent to what libco would do.

Merging into master sounds OK for me, I'll just figure out why Auto crashes for you.

GB_disconnect_serial is the correct API, but clearing any kind of callback in SameBoy can also be done by simply setting it to NULL.

Anyway, good job! Have you added infrared support yet?

[andres-asm]

No, I'm working on the RA gui now since the multi cart aspect never had one.
Once I do that I can give it a spin.

[andres-asm]

the link branch superceded the old master since it seems to be working rather well
the only thing missing is the auto model thing that I dunno how I managed to break.

If you haven't looked at it by the weekend I may try again :P

BTW, for android, we haven't figured a way to run hexdump previously (jni makefiles are a bit more limited than the normal ones) so we still have no solution to build it for android.

[LIJI32]

I'll have a look next weekend and merge it to my master as well. As for Android, I'm rather confused – why would Android's makefiles be more limited? Aren't they just being run using standard make on the same machine as the other builds with different target settings? What am I missing?

[andres-asm]

No, android cores are build with ndk-build which is a wrapper around make that builds for all the supported ABIs at once. It uses this: http://android.mk/

…

On Wed, Feb 7, 2018 at 4:11 AM, Lior Halphon ***@***.***> wrote: I'll have a look next weekend and merge it to my master as well. As for Android, I'm rather confused – why would Android's makefiles be more limited? Aren't they just being run using standard make on the same machine as the other builds with different target settings? What am I missing? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#18 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABpC0DQz5ruR_B9jjDf4OzvxHl8hhO3Nks5tSWi6gaJpZM4QWq7R> .

[LIJI32]

I see. I tried building it myself (cd libretro; NDK_PROJECT_PATH=. ndk-build) and after fixing some paths it failed because it didn't forward several important CFLAGS (specifically -DGB_INTERNAL). However, hexdump did seem to work; I added the following line to Android.mk:

$(error $(shell echo quack | hexdump -C))

And got, as expected:

jni/Android.mk:26: *** 00000000 71 75 61 63 6b 0a |quack.| 00000006. Stop.

Am I somehow missing the problem?

@LIJI32 The problem I'm noticing is that this only works to produce files that aren't part of LOCAL_SRC_FILES, otherwise it checks that they exist before running any $(error) or $(info) commands. We've done a lot of research on this and the general consensus seems to be that it's not possible to shoehorn this functionality into the limited abilities of Android.mk, and the recommended approach is to generate any sources externally before running the build.

[LIJI32]

@bparker06 Found the problem and mostly fixed it (locally), but I'm having troubles with how relative paths are used with that weird thing. Can you post the exact command line you're using to build, and what's the CWD you use to run it?

In the top-level folder of a clone of the libretro-super repo:

SINGLE_CORE=sameboy EXIT_ON_ERROR=1 FORCE=YES ./libretro-buildbot-recipe.sh recipes/android/cores-android-jni

This is exactly how our buildbot does it as well.

[andres-asm]

that would imply he's using super and he knows how to use the buildbot though.

@LIJI32 if you have the android toolchain set configured, you build inside the jni folder

ndk-build -j6 APP_ABI=armeabi-v7a
Like that

[LIJI32]

@fr500 @bparker06 Android builds should work now.

[andres-asm]

wow I missed this, gonna update the fork then.
BTW, gonna make a change so we don't have to be doing this "remove bootroms" "add bootroms" dance all over the place.

Gonna have a buildbot branch with bootroms, and I'll keep rebasing on top of master.

[andres-asm]

@LIJI32 all in good working order. That said.
Are you sure threading wouldn't help? In dual mode it's 40fps on Tegra X1!

In threaded mode we could go back to retro_run_frame no? and remove waiting. Even if there's a cost to threading itself it may be fullspeed since each emulator would be running in a separate core.

Sadly I really don't feel comfortable working with threads but I may give it a shot after some reading.

[lpla]

Hi all. Any progress on link connection in Cocoa version of SameBoy? I am very interested to connect instances of the emulator between my Macbook and my girlfriend's one for Pokémon G/S/C trading and fights.

Also, I would like to implement a MIDI interface to connect SameBoy running LSDJ or similar ROMs with DAWs in OS X like Logic Pro or Ableton Live, simulating the Arduinoboy, so, the link feature is quite a big dependency.

[LIJI32]

The Cocoa/SDL port of netplay is constantly being delayed, but early 2019 (v0.12) is the current estimate. The link cable, however, is fully emulated, it's just that it's not relayed over network. Both frontends can be easily modified to support the MIDI interface.

[lpla]

Okay! No problem with netplay delay. When you say that link cable is fully emulated you mean in the C API, not the Cocoa interface, isn't it? The only frontend that I see that has link implemented in "master" is the Retroarch core.

[LIJI32]

Exactly. In addition to the Retroarch-available netplay, there's also Game Boy printer support which also uses the link API. The Cocoa frontend provides an interface for the printer support.

[andres-asm]

I just noticed super mario bros dx disconnects at the level select screen, pokemon seems to still work properly though

[andres-asm]

Tetris seems to still work too:

And Tetris DX

[andres-asm]

Some guy did some thorough testing btw
https://www.youtube.com/watch?v=hTeZiN1S4i4&feature=youtu.be

A bit outdated gonna ask him if he can re-test

Mario tennis works great.

Anything new with this?

[LIJI32]

My estimate of v0.12 (First half of 2019) still applies :)

[lpla]

I guess this is delayed until v0.13, isn't it?

[whazzzzzup17]

Anyway to load (4) games with this feature instead of two for multiple players to play through RetroArch? Not so much interested in the trading aspect, but more interested in loading (4) separate Game Boy instances for each user to play their own game, such as Pokemon.

[LIJI32]

Isn't that just 4 instances of SameBoy open without any link cable emulation? What am I missing?

[whazzzzzup17]

Yes, but I don't believe there is anyway to run this through one RetroArch emulation. I've been using the link to run both side by side, but it would be awesome to run (4). Top-left, Top-right, Bottom-left, Bottom-right.

Running multiple SameBoy instances is a lot of manual work with a mouse and re-alignment, etc.

[andres-asm]

I don't think there's a way to link 4 so I didn't think it would be worthwhile to implement that.

[whazzzzzup17]

Bummer. Looks like I'll just have to create a script to run multiple SameBoy outside of RetroArch and re-assign controllers to each exe.

[LIJI32]

There actually is a device that allows linking four Game Boys, but it's not emulated yet.

[whazzzzzup17]

I guess I'm more interested in not linking them through each game, although it would be great. It would be better having multiple instances run side by side, which would thus make a (1) player game into up to (4) players because each would have their own controller and it fills up the rest of the screen real-estate.

Its nice having them all lined up and not have to manually modify each .EXE settings during each initial setup. Whereas through RetroArch, the controller auto set. See example below where I cropped out the title bars, the bottom task bar, etc. But I would still need to change each exe setting before going forward.

[andres-asm]

I did this for mgba at some point and I just realized I nuked that repo :P Edit: ahhh the PR still exists libretro/mgba#81 I guess I can use it for reference. I do think the multi instance code in the libretro core can accommodate this easily

…

On Sat, Jun 22, 2019 at 10:46 AM whazzzzzup17 ***@***.***> wrote: I guess I'm more interested in not linking them through each game, although it would be great. It would be better having multiple instances run side by side, which would thus make a (1) player game into up to (4) players because each would have their own controller and it fills up the rest of the screen real-estate. Its nice having them all lined up and not have to manually modify each .EXE settings during each initial setup. Whereas through RetroArch, the controller auto set. See example below where I cropped out the title bars, the bottom task bar, etc. But I would still need to change each exe setting before going forward. [image: image] <https://user-images.githubusercontent.com/52107441/59965950-e900ec80-94c9-11e9-8676-76e18b83d515.png> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#18?email_source=notifications&email_token=AANEFUFUWSKHBKC55O3LFGTP3ZCLPA5CNFSM4EC2V3I2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYKL7WY#issuecomment-504676315>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANEFUH6WKMRF7ITCUGENQ3P3ZCLRANCNFSM4EC2V3IQ> .

[whazzzzzup17]

Not to mention if (1) user wants to play Pokemon, the other (3) users can play totally different games all through one monitor at the same time. Extremely useful if you have a big 65 inch TV or something like that.

Not sure if this is a different request or can be modified through the same request, as they both involve running multiple instances

[andres-asm]

It's a different request for sure.

…

On Sat, Jun 22, 2019 at 11:04 AM whazzzzzup17 ***@***.***> wrote: Not to mention if (1) user wants to play Pokemon, the other (3) users can play totally different games all through one monitor at the same time. Extremely useful if you have a big 65 inch TV or something like that. Not sure if this is a different request or can be modified through the same request. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#18?email_source=notifications&email_token=AANEFUBGHGC3D7IYY2WKMA3P3ZESTA5CNFSM4EC2V3I2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYKMLDY#issuecomment-504677775>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANEFUHIROSV4OYYA3NOM4DP3ZESTANCNFSM4EC2V3IQ> .

[VGkav]

So his isn't implemented, right? Because in Retroarch if I go to Subsystems and select "Load 2 Player Game Boy Link" it asks me for a rom, I select Pokemon Crystal and it seems to just load it normally.

(I just want to "trade")

[andres-asm]

subsystems is definitely implemented correctly in the core.
No idea if they changed / broke something in the RA side

Hi guys,

@fr500 and @LIJI32 , I can confirm that subsystems still works on RetroArch 1.9.0 (latest git code).
Tested on Lubuntu 20.04 64-bits.

For users, the steps are :
1°) Select Subsystems -> Load 2 Player Game Boy Link -> Your Game N°1 .
2°) Select Subsystems -> Load 2 Player Game Boy Link -> Your Game N°2 .
3°) Select Subsystems -> Start 2 Player Game Boy Link.

And Have a nice run ^^ . Congratulations for these huge works guys !

Note : Like me, you are in love with commands lines? Need this info for Retropie, EmulationStation and co? Here is an example of how to use it :

retroarch --libretro=/PATH/of/sameboy_libretro.so --subsystem gb_link_2p /PATH/of/Game/Player1 /PATH/of/Game/Player2
Ex: retroarch --libretro=$HOME/.config/retroarch/cores/sameboy_libretro.so --subsystem gb_link_2p $HOME/games/game1.gbc $HOME/games/game2.gbc 

[andres-asm]

glad it works for you, you're from VBA right? does VBA have a similar API without relying on network?

I'm not an official dev of VisualBoyAdvance-M, but I worked on a fork of VBALink that becames now a fork of VisualBoyAdvance-M with a working TCP/IP network for Linux and Windows (uses native socket code instead the SFML Library). In my knowledge, but i have never successfully used it, they have a support for local mode ( on the same computer ) that uses multiple instances.

For the tests that I done today with my code, I can use the equivalent method : use multiple instances on the same machine ( Player1 = server , Player 2 to 4 = client that connects to 127.0.0.1) with a working retroarch core . But I don't know if we can modify it to support the method you and @LIJI32 used in SameBoy, because of the lack of a system/API method in VBA-M and in my fork.

If you're interested to look on my project, I can create a repository of my fork if you want to look on the code ( personnally, GBA Link code is the main objective on my project (Multi-Pak and General Purpose Mode for FFTA works), the Joybus Protocol isn't necessary, and the GB/GBC Link works very better on SameBoy than VisualBoyAdvance-M + my fork ).

EDIT : Does mGBA libretro core already have this feature ?
EDIT2 : Yes apparently but it is not implemented on RetroArch core : mgba-emu/mgba#756 (comment)
EDIT3: After some research, can we really load different cores on a subsystem like said here ? libretro/RetroArch#7997 . I will create a repository that contains the work I done on GBA Link. I will begin to study that. I could be awesome to play GBA Link directly on a same computer on Retroarch like that

The RetroArch core could also play online with some sort of rollback but i remember not getting it to work like I wanted lol.
I mean it was kinda playable when I played Mario Tennis with someone else but the rollback was messed up a bit.