Homebrew Emulation GameYob, a gameboy emulator for DS

liamash3

Well-Known Member
Newcomer
Joined
Jul 6, 2008
Messages
88
Trophies
0
Age
29
Location
Frankston
XP
222
Country
This seems awesome so far :)
Even so, I'm sticking to Lameboy till all the kinks are worked out with widescreen support (it's too tiny for me as is)...Keep up the good work!
 

Thesolcity

Wherever the light shines, it casts a shadow.
Member
Joined
Oct 2, 2010
Messages
2,209
Trophies
1
Location
San Miguel
XP
1,138
Country
United States
All I get is a white screen when loading a game. Oh, and a 0kb SAV file is created as well. I'm on a DSTWO what am I doing wrong?
 

CoolAs

Well-Known Member
Newcomer
Joined
Oct 21, 2011
Messages
75
Trophies
0
XP
109
Country
Graphical frames. It would wait for vblank, then send keypresses and wait for the other DS's keypresses. So that way, it's more like: (pseudocode)
Code:
swiWaitForVBlank();
nifiSendPacketByte(gbKeys);
unsigned char otherGbKeys = nifiWaitForPacket();
runEmul(gbKeys);
runEmulSlaveGb(otherGbKeys);
That wouldn't work perfectly though, as the graphical frames will not be in synch - both DS' will have VBlank's at different times. (unless you can synch them somehow)
It's still a cool idea though, that could possibly work.
 

Deleted member 319809

MAH BOI/GURL
Member
Joined
Dec 22, 2012
Messages
900
Trophies
0
XP
461
Country
Canada
That wouldn't work perfectly though, as the graphical frames will not be in synch - both DS' will have VBlank's at different times. (unless you can synch them somehow)
It's still a cool idea though, that could possibly work.
Oh... Crap. I actually didn't think of that. I doubt it's possible to sync up the vblank period itself, that's probably constant in hardware.

Well spotted.

The link initialisation phase could determine which VCOUNT line would start emulation and keypress-waiting, and on DS A it could fire up at VCOUNT 150 while on DS B it fires up at VCOUNT 35 or something... That way, the GB vblanks would be synchronised. Food for thought.
 

CoolAs

Well-Known Member
Newcomer
Joined
Oct 21, 2011
Messages
75
Trophies
0
XP
109
Country
Oh... Crap. I actually didn't think of that. I doubt it's possible to sync up the vblank period itself, that's probably constant in hardware.

Well spotted.

The link initialisation phase could determine which VCOUNT line would start emulation and keypress-waiting, and on DS A it could fire up at VCOUNT 150 while on DS B it fires up at VCOUNT 35 or something... That way, the GB vblanks would be synchronised. Food for thought.
Actually, just had a look at GBATEK under the DS Video section.
VCOUNT register is write-able, allowing to synchronize linked DS consoles.
It tells you how you can actually synch the VCOUNT, you need to do it in a specific way.
I haven't actually tried it, and it may not work, however there is some hope.
Pausing for Nifi in the middle of a screen wouldn't be good as you may pause for to long and produce visual artifacts depending on how the code is written. (But then if you do pause for too long, you could resynch the VCount to pause at)

Another way would be to hook an interrupt on one of the DS timers instead of the VBlank, which would be easier and more straightforward to synch.
 

Drenn

Well-Known Member
OP
Member
Joined
Feb 22, 2013
Messages
574
Trophies
0
XP
696
Country
Canada
Since gameboy vblank is kind of attached to ds vblank, it would be preferable if they were synchronized. This is just speculation, but if the lcds are disabled and re-enabled at the correct time, maybe they could be synchronized? Assuming the ds doesn't keep firing "virtual" vblanks and vcounts when they're disabled. Edit: nvm, didn't read CoolAs's post properly. This could work.

But there could be an easier way, the way nesds does it. ds B runs a few frames behind ds A, where ds B records each ds's input for the last few frames to replay it. That way they don't really need to be synched, but ds B has noticeable input lag.
All I get is a white screen when loading a game. Oh, and a 0kb SAV file is created as well. I'm on a DSTWO what am I doing wrong?
I... have no idea. What game are you trying? Are you using the official v0.3 or the latest build dropbox link?
 

Drenn

Well-Known Member
OP
Member
Joined
Feb 22, 2013
Messages
574
Trophies
0
XP
696
Country
Canada
The other day I was going to start a randomized Nuzlocke playthrough of Pokemon Blue, when I realized... I can't play this game without proper colour! So I got started on Super Gameboy emulation. It's not complete yet, but enough has been done to run the 1st gen Pokemon games in glorious colour! No borders yet. This was all done in the master branch, not newgfx like I said earlier. I'm not all that enthusiastic about the newgfx branch lately. I'll try to get it in working order, then I'll probably offer it as an alternative for people who want scaling, for those games which it runs at a good speed.
 

windwakr

Well-Known Member
Member
Joined
Sep 13, 2009
Messages
502
Trophies
1
Website
windwakr.github.io
XP
1,792
Country
United States
windwakr may i ask why are you not working with Drenn on his GIT to improve GameYob together.

Drenn would rather see a change in libnds.

I'm not sure if the libnds developers would change anything, though. IRQ_NETWORK, which they use for updating the clock, doesn't exist in the 3DS's DS mode*(and from what I've been able to piece together, didn't officially exist in the DS, but worked). That means they'd probably have to use one of the timers to update the clock, which would cause problems for many homebrew developers.


*or may exist in a way that is accessed differently. But most likely, it was just not implemented.
 

Drenn

Well-Known Member
OP
Member
Joined
Feb 22, 2013
Messages
574
Trophies
0
XP
696
Country
Canada
Does this mean it will run other SGB-enhanced GB games in color? For example, Mario's Picross 2 (which I believe doesn't have a border, just the SGB color)?
Yes, in theory, but most super gameboy games aren't working 100%. It seems that Mario's Picross 2 isn't working properly yet, as the entire screen uses only 1 of the 4 palettes.
Drenn would rather see a change in libnds.

I'm not sure if the libnds developers would change anything, though. IRQ_NETWORK, which they use for updating the clock, doesn't exist in the 3DS's DS mode*(and from what I've been able to piece together, didn't officially exist in the DS, but worked). That means they'd probably have to use one of the timers to update the clock, which would cause problems for many homebrew developers.


*or may exist in a way that is accessed differently. But most likely, it was just not implemented.
I never did get around to looking at your fix for the clock. If it's not realistic to expect a change in libnds then I'll probably merge what you have. I imagine you don't want to keep updating your branch to keep up with mine...
 

2ndApex

Well-Known Member
Member
Joined
Jul 12, 2012
Messages
677
Trophies
0
XP
419
Country
United States
Yes, in theory, but most super gameboy games aren't working 100%. It seems that Mario's Picross 2 isn't working properly yet, as the entire screen uses only 1 of the 4 palettes.

I never did get around to looking at your fix for the clock. If it's not realistic to expect a change in libnds then I'll probably merge what you have. I imagine you don't want to keep updating your branch to keep up with mine...


Can you upload the SGB build onto the Dropbox?
 

xdpirate

Member
Newcomer
Joined
Sep 8, 2008
Messages
23
Trophies
0
XP
175
Country
Norway
After compiling the newest commit last night, Kirby's Block Ball isn't working. Sound, fps and input are all fine (loaded a state to check), but the whole screen is a light shade of blue. This probably has to do with the new SGB support, as Kirby's Block Ball has a custom border and palette when used in one :)
 

DaniPoo

Well-Known Member
Member
Joined
Jan 2, 2013
Messages
925
Trophies
1
Age
35
XP
2,287
Country
For link cable emulation, what you could do is emulate both Game Boys on each DS.

That way, all of the information that is missing for the link cable session is the keys pressed on the other Game Boy, which is provided by the other DS. The link cable can then be emulated locally, as if the other Game Boy had sent what it needed to send given its global state and the keys pressed on it.

The link initialisation would be as follows:

1. Pause both GBs at the next vblank, collapse cached flags, etc.

2. Synchronise the ROM such that "GB B" on DS A gets a copy of the ROM on GB B on DS B. Similarly, synchronise the ROM such that "GB A" on DS B gets a copy of the ROM on GB A on DS A. This step may require memory allocations or the creation of a scratch file on both DSes, and may be helped by global hashes and block hashes to avoid sending an entire ROM. From this point on, each DS emulates both its own ROM (showing its progress on-screen) and the ROM of its link slave (hiding its progress on-screen).

3. Synchronise all other emulation variables such that "GB B" on DS A gets a copy of the state of GB B on DS B. Similarly, synchronise all other emulation variables such that "GB A" on DS B gets a copy of the state of DS A. This step could be implemented by writing a saved state and the SRAM in memory, then sending it to the other DS perhaps with compression. From this point on, each DS can see the progress of both its Game Boy and the other DS's Game Boy.

4. End link initialisation. Enter "link mode".

In link mode:

1. The controls pressed on GB A of DS A are sent to DS B at the beginning of each frame, so that DS B can be made aware of how GB A will advance for the frame, and vice-versa. Each DS waits for the other GB's keypresses, which can be encoded in one byte. Each DS ignores keypresses until its own Game Boy has emulated one frame, so as to keep the synchronisation (e.g. you can't press A and have it apply in the middle of a frame anymore, because the other Game Boy will never know).

2. Each DS also emulates a single frame of each Game Boy, given the controls pressed at the beginning of their respective frames. The control passes from one Game Boy to the other when a byte is sent on the cable, so that the other Game Boy can receive the byte that was just sent.

3. Show the screen and sound only for the Game Boy respective to each DS.

That way, the link cable emulation can simply be 1 byte per frame! Each Game Boy will advance correctly, given that it has the memory contents of the other at all times, so you can press A on one Game Boy then A on the other to trade a Pokémon (which the other Game Boy will know about, so it can send the right bytes on the pretend cable), or the arrow keys in Tetris to move a piece (which the other Game Boy can turn into the right data for the link cable).

I take no credit for this idea.

Sounds alot like my idea :)
http://gbatemp.net/threads/gameboy-emulation-and-linkcables.345532/#post-4598732

Maybe this is just a coincidence, or someone actually saw the potential of the idea of emulating both Gameboys on each machine!

But yeah, it's not like I would play some fast racer multiplayer using this method because the delays of remoting eachothers Machines could be pretty bad. However its perfect for games like pokemon.
 

Drenn

Well-Known Member
OP
Member
Joined
Feb 22, 2013
Messages
574
Trophies
0
XP
696
Country
Canada
After compiling the newest commit last night, Kirby's Block Ball isn't working. Sound, fps and input are all fine (loaded a state to check), but the whole screen is a light shade of blue. This probably has to do with the new SGB support, as Kirby's Block Ball has a custom border and palette when used in one :)
You can disable sgb mode, in the "GB Modes" submenu, for the games which aren't working properly. But I've fixed Kirby's Block Ball. Such a silly mistake, it was supposed to be 0x40, not 40!
Sounds alot like my idea :)
http://gbatemp.net/threads/gameboy-emulation-and-linkcables.345532/#post-4598732

Maybe this is just a coincidence, or someone actually saw the potential of the idea of emulating both Gameboys on each machine!

But yeah, it's not like I would play some fast racer multiplayer using this method because the delays of remoting eachothers Machines could be pretty bad. However its perfect for games like pokemon.
Yeah that's basically what Nebuleon was describing. In theory if this works, the only potential problems would be emulation speed and input lag, so other than that your racers would work fine.
 

sverx

a DS homebrewer
Newcomer
Joined
Dec 23, 2008
Messages
32
Trophies
0
Website
adshomebrewersdiary.blogspot.com
XP
108
Country
Italy
IRQ_NETWORK, which they use for updating the clock, doesn't exist in the 3DS's DS mode*(and from what I've been able to piece together, didn't officially exist in the DS, but worked).

That IRQ is only triggered on ARM7, and it's connected to the RTC. If it doesn't work on a 3DS then it means either the 3DS isn't working correctly in DS mode -or- the libnds has some bugs that appears only when running on a 3DS. libnds programmers are surely interested in knowing what's wrong.
http://nocash.emubase.de/gbatek.htm#dsinterrupts
http://libnds.devkitpro.org/a00124.html
 

windwakr

Well-Known Member
Member
Joined
Sep 13, 2009
Messages
502
Trophies
1
Website
windwakr.github.io
XP
1,792
Country
United States
That IRQ is only triggered on ARM7, and it's connected to the RTC. If it doesn't work on a 3DS then it means either the 3DS isn't working correctly in DS mode -or- the libnds has some bugs that appears only when running on a 3DS. libnds programmers are surely interested in knowing what's wrong.
http://nocash.emubase.de/gbatek.htm#dsinterrupts
http://libnds.devkitpro.org/a00124.html

Yes, it is documented in GBATEK and libnds, but that doesn't mean it is actually supposed to be there. If you dig a little deeper(can't help you there), you'll see that it's not supposed to exist/work.
 

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
  • No one is chatting at the moment.
    Maximumbeans @ Maximumbeans: butte