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.
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!
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:
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?
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.
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.
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.
Joined: 4/17/2010
Posts: 11495
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
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.
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.
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.
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.
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.
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.
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.
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?
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
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.
Joined: 4/17/2010
Posts: 11495
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
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.
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.
