MarbleousDave
He/Him
Player (12)
Joined: 9/12/2009
Posts: 1554
The extra month of work of the update has payed off. Well, the detection of this new update still isn't showing up on prior versions. The New from Current SaveRAM feature in TAStudio still doesn't work.
Alyosha
He/Him
Editor, Expert player (3514)
Joined: 11/30/2014
Posts: 2713
Location: US
Mugen Senshi Valis, for PCE, has been a game unplayable in BizHawk since the release of the PCE core. I just now fixed this game, but I thought I'd write a little bit about what went wrong and why it took so long to fix. As it turns out, this game was running some timed code. It's using a VBlank loop to do a few operations, and using the remainder of frame time to load data from the CD. The VBlank loop counts down, and after a certain number of VBlanks, the last VBlank interrupt turns off VBlanks. The game is expecting the other loading code to not be finished at this point, because at the end of the loading code, it turns VBlanks back on again! BizHawk was loading in data too fast. So the loading code was finished too early, and turned on VBlanks even though they were still on. Once the VBlank loop ended, it turned off VBlanks, but now had no way to turn them back on again! Oops! To fix the problem, I just increased the loading time from CD reads, which seemed likely to be the correct solution. This all probably seems pretty obvious just reading that last paragraph, but getting to that point took many hours of debugging, I'm glad it's finally done! Now an even greater challenge awaits, why is there audio issues when loading gate of Thunder in the 4 in 1 CD? I've spent even more time on that one and still have no idea. EDIT: nevermind, 4-in-1 is fixed in the same way. Oldest issue on the tracker solved!
Joined: 5/4/2016
Posts: 67
Sameboy runs the SGB at the SGB1 clock speed, whereas BSNES runs the SGB at the original clock speed. Is BSNES emulating the SGB2?
adelikat
He/Him
Emulator Coder, Expert player, Site Developer, Site Owner (3581)
Joined: 11/3/2004
Posts: 4736
Location: Tennessee
Alyosha wrote:
4-in-1 is fixed in the same way. Oldest issue on the tracker solved!
That makes me happy ^_^
It's hard to look this good. My TAS projects
Skilled player (1703)
Joined: 9/17/2009
Posts: 4952
Location: ̶C̶a̶n̶a̶d̶a̶ "Kanatah"
I have no idea if it's a problem with my computer or the emulator, but does anyone have a problem, where after using the "Microsoft Video 1" compressor, and exporting an AVI file, Windows 10 default player (Movies & TV; Photos) show a black, empty screen with audio? Example of what I mean:
Alyosha
He/Him
Editor, Expert player (3514)
Joined: 11/30/2014
Posts: 2713
Location: US
smellyfeetyouhave wrote:
Sameboy runs the SGB at the SGB1 clock speed, whereas BSNES runs the SGB at the original clock speed. Is BSNES emulating the SGB2?
I don't think it is. SGB in BizHawk needs some work in general.
Joined: 5/4/2016
Posts: 67
Alyosha wrote:
smellyfeetyouhave wrote:
Sameboy runs the SGB at the SGB1 clock speed, whereas BSNES runs the SGB at the original clock speed. Is BSNES emulating the SGB2?
I don't think it is. SGB in BizHawk needs some work in general.
Thanks. On another note, does C64Hawk support the T64 format? It's not part of the filter when loading roms, but the core recognizes T64 files as valid files. I can't get it to run any games so I'm guessing it doesn't work? When loading a T64 file, the C64 RAM is populated, but RUN doesn't launch the game. Edit: Looking at the code it looks like the framework is there for T64 files but it doesn't actually know how to handle them. Any plans to support T64 in the future?
Alyosha
He/Him
Editor, Expert player (3514)
Joined: 11/30/2014
Posts: 2713
Location: US
smellyfeetyouhave wrote:
On another note, does C64Hawk support the T64 format? It's not part of the filter when loading roms, but the core recognizes T64 files as valid files. I can't get it to run any games so I'm guessing it doesn't work? When loading a T64 file, the C64 RAM is populated, but RUN doesn't launch the game. Edit: Looking at the code it looks like the framework is there for T64 files but it doesn't actually know how to handle them. Any plans to support T64 in the future?
I have no plans to do it myself. Probably it would only get done if SaxxonPike returns. Feel free to give it a go if you are interested.
Joined: 5/4/2016
Posts: 67
Alyosha wrote:
smellyfeetyouhave wrote:
On another note, does C64Hawk support the T64 format? It's not part of the filter when loading roms, but the core recognizes T64 files as valid files. I can't get it to run any games so I'm guessing it doesn't work? When loading a T64 file, the C64 RAM is populated, but RUN doesn't launch the game. Edit: Looking at the code it looks like the framework is there for T64 files but it doesn't actually know how to handle them. Any plans to support T64 in the future?
I have no plans to do it myself. Probably it would only get done if SaxxonPike returns. Feel free to give it a go if you are interested.
I have absolutely zero experience in emulator development so even if I did make it work, it probably wouldn't be pretty. I may take a look though assuming I can find some good references. I have a metric ton of C64 games in T64 format rather than TAP.
Alyosha
He/Him
Editor, Expert player (3514)
Joined: 11/30/2014
Posts: 2713
Location: US
smellyfeetyouhave wrote:
I have absolutely zero experience in emulator development so even if I did make it work, it probably wouldn't be pretty. I may take a look though assuming I can find some good references. I have a metric ton of C64 games in T64 format rather than TAP.
Don't worry about it being pretty, or having no experience in emulation. Just getting things working is the biggest and most important step. It's especially helpful for systems like C64 where we are really lacking the knowledge base needed to move the core forward.
Site Admin, Skilled player (1234)
Joined: 4/17/2010
Posts: 11251
Location: RU
Yeah it can be pretified after you make a pull request.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Active player (250)
Joined: 12/13/2016
Posts: 352
In the next release of BizHawk, can we update the mGBA core to 0.6.2?
Joined: 5/4/2016
Posts: 67
ruadath wrote:
In the next release of BizHawk, can we update the mGBA core to 0.6.2?
The version in the latest dev builds (and I think 2.2.2 stable?) is https://github.com/mgba-emu/mgba/commit/633449dfd4dcb9e70646cccf217cea3d4f The only commit that actually affects GBA emulation since then is 633449d and that commit has actually been reverted as of yesterday so 0.6.2 stable would actually introduce a single reversion and that's it.
Joined: 7/17/2012
Posts: 528
Location: Switzerland
smellyfeetyouhave wrote:
does C64Hawk support the T64 format?
It seems that there are also other formats like D81, G41, P00 and LNX that C64Hawk does not support. Nib (and joystick) support in Apple II core will be great too.
My Citra 3DS rerecording movie files test repositery: https://cutt.ly/vdM0jzl Youtube playlist "Citra Tests": https://cutt.ly/AdM0wg9 http://www.youtube.com/user/phoenix1291
Joined: 4/17/2017
Posts: 25
smellyfeetyouhave wrote:
ruadath wrote:
In the next release of BizHawk, can we update the mGBA core to 0.6.2?
The version in the latest dev builds (and I think 2.2.2 stable?) is https://github.com/mgba-emu/mgba/commit/633449dfd4dcb9e70646cccf217cea3d4f The only commit that actually affects GBA emulation since then is 633449d and that commit has actually been reverted as of yesterday so 0.6.2 stable would actually introduce a single reversion and that's it.
Wow... all that work I did talking about that too. He reverted the single change that didn't make the audio sound like it was coming out of a tin can and made all the bass notes higher and...? I officially give up on that emulator then.
endrift
Any
Emulator Coder
Joined: 12/14/2014
Posts: 161
arkazal wrote:
smellyfeetyouhave wrote:
ruadath wrote:
In the next release of BizHawk, can we update the mGBA core to 0.6.2?
The version in the latest dev builds (and I think 2.2.2 stable?) is https://github.com/mgba-emu/mgba/commit/633449dfd4dcb9e70646cccf217cea3d4f The only commit that actually affects GBA emulation since then is 633449d and that commit has actually been reverted as of yesterday so 0.6.2 stable would actually introduce a single reversion and that's it.
Wow... all that work I did talking about that too. He reverted the single change that didn't make the audio sound like it was coming out of a tin can and made all the bass notes higher and...? I officially give up on that emulator then.
I reverted that change *on that branch only* because it was needed to fix part of another commit, which tons of people complained caused popping on Game Boy audio. That single commit is only needed because of the other commit, which was reverted at the same time. But by all means jump to conclusions about what any of this does.
Joined: 7/17/2012
Posts: 528
Location: Switzerland
Is it possible to implement a function for the screen orientation? It would be very useful for games that change the screen orientation during the game, like Makaimura on WonderSwan.
My Citra 3DS rerecording movie files test repositery: https://cutt.ly/vdM0jzl Youtube playlist "Citra Tests": https://cutt.ly/AdM0wg9 http://www.youtube.com/user/phoenix1291
Sonia
She/Her
Joined: 12/6/2013
Posts: 435
Location: Brazil
Alyosha wrote:
Mugen Senshi Valis, for PCE, has been a game unplayable in BizHawk since the release of the PCE core. I just now fixed this game, but I thought I'd write a little bit about what went wrong and why it took so long to fix. As it turns out, this game was running some timed code. It's using a VBlank loop to do a few operations, and using the remainder of frame time to load data from the CD. The VBlank loop counts down, and after a certain number of VBlanks, the last VBlank interrupt turns off VBlanks. The game is expecting the other loading code to not be finished at this point, because at the end of the loading code, it turns VBlanks back on again! BizHawk was loading in data too fast. So the loading code was finished too early, and turned on VBlanks even though they were still on. Once the VBlank loop ended, it turned off VBlanks, but now had no way to turn them back on again! Oops! To fix the problem, I just increased the loading time from CD reads, which seemed likely to be the correct solution. This all probably seems pretty obvious just reading that last paragraph, but getting to that point took many hours of debugging, I'm glad it's finally done!
Thanks a lot for the fix! Glad to see the game is finally playable in Bizhawk now. However, there's still another issue. Basically, the game's audio is out of sync. Characters' mouth movements don't sync with their voices. This also happens in mednafen, no matter the dumped image. I once created an account in their forum to report the bug, here's the link: https://forum.fobby.net/index.php?t=msg&th=1571&start=0& According to the last post, this apparently has to do with CD-ROM seek time not being properly emulated. This could prove useful if you're willing to look into fixing stuff.
Alyosha
He/Him
Editor, Expert player (3514)
Joined: 11/30/2014
Posts: 2713
Location: US
Sonia wrote:
However, there's still another issue. Basically, the game's audio is out of sync. Characters' mouth movements don't sync with their voices. This also happens in mednafen, no matter the dumped image. I once created an account in their forum to report the bug, here's the link: https://forum.fobby.net/index.php?t=msg&th=1571&start=0& According to the last post, this apparently has to do with CD-ROM seek time not being properly emulated. This could prove useful if you're willing to look into fixing stuff.
Yeah, my guess is that the developers just ran the disc on console and just plugged in how long the load times took into the game so everything would sync up. Actually simulating it though is not something I'm going to sink time into. I'll add it as an item to the github issue though just so it's being tracked.
Skilled player (1648)
Joined: 7/1/2013
Posts: 433
phoenix1291 wrote:
Is it possible to implement a function for the screen orientation?
Thanks, phoenix1291. Seconded!
Editor, Emulator Coder, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
phoenix1291 wrote:
Is it possible to implement a function for the screen orientation? It would be very useful for games that change the screen orientation during the game, like Makaimura on WonderSwan.
Wonderswan has a keybind to flip the orientation. Is that working for you? If not, what do you want that it can't do?
Joined: 5/4/2016
Posts: 67
endrift wrote:
arkazal wrote:
smellyfeetyouhave wrote:
ruadath wrote:
In the next release of BizHawk, can we update the mGBA core to 0.6.2?
The version in the latest dev builds (and I think 2.2.2 stable?) is https://github.com/mgba-emu/mgba/commit/633449dfd4dcb9e70646cccf217cea3d4f The only commit that actually affects GBA emulation since then is 633449d and that commit has actually been reverted as of yesterday so 0.6.2 stable would actually introduce a single reversion and that's it.
Wow... all that work I did talking about that too. He reverted the single change that didn't make the audio sound like it was coming out of a tin can and made all the bass notes higher and...? I officially give up on that emulator then.
I reverted that change *on that branch only* because it was needed to fix part of another commit, which tons of people complained caused popping on Game Boy audio. That single commit is only needed because of the other commit, which was reverted at the same time. But by all means jump to conclusions about what any of this does.
Whoops. I made a mistake in my original post. I both linked to the wrong commit (I linked to the GB instead of the GBA one), and misread what was reverted. My mistake there. This doesn't matter any more anyways since 0.6.3 stable has been posted
Player (33)
Joined: 2/16/2012
Posts: 282
Is there any way to easily obtain the current V/H scanline positions for a variety of retro cores via a mid-frame lua event? Some of the trace loggers provide it as part of their output, but I haven't seen any functions that expose it to users. Some systems provide hardware registers for that purpose, but it looks like a number of them need a software trigger to actually latch the information.
Site Admin, Skilled player (1234)
Joined: 4/17/2010
Posts: 11251
Location: RU
If it is in the registers, and those registers are available to bizhawk lua, just read them when your exec callback fires.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Player (33)
Joined: 2/16/2012
Posts: 282
They aren't among the registers available by emu.getregisters() on any of the cores I've tried. Direct attempts to read the registers via the system bus also turn up as 0, though I think this is because a "read" of those addresses isn't supposed to return the address contents, but register contents. It would be a different story if the read were an actual instruction, but that's not something lua can currently do, as far as I know. EDIT: Submitted as a feature request to the github.