It doesn't matter if they have the same bits set or not since we're testing for zero/nonzero.
Another thing you could do: store a function pointer somewhere and call it in the function. Change the pointer value when timer_control is changed.
Language: c
public void timer_control_AND_3_is_1() {state = divider_reg & 0b0000001000;}
public void timer_control_AND_3_is_2() {state = divider_reg & 0b0000100000;}
public void timer_control_AND_3_is_3() {state = divider_reg & 0b0010000000;}
public void timer_control_AND_3_is_0() {state = divider_reg & 0b1000000000;}
public void timer_control_has_been_set() inline; // or just put these lines to where timer_control is set
{
// pointer array of 4 pointers
StateOperation = StateOperations[timer_control & 3];
state_c = timer_control & 0x4;
}
public void tick_2()
{
divider_reg += 1;
// call StateOperation here
// this procedure allows several glitchy timer ticks, since it only measures falling edge of the state
// so things like turning the timer off and resetting the divider will tick the timer
// if ((state == 0 || state_c == 0) && (old_state > 0 && old_state_c > 0)) {
if (((state & state_c) == 0) && ((old_state | old_state_c) != 0)) {
timer_old = timer;
timer += 1;
// if overflow, set the interrupt flag and reload the timer (4 clocks later)
if (timer < timer_old) {
pending_reload = 4;
reload_block = false;
}
}
old_state = state;
old_state_c = state_c;
}
EDIT: Maybe it also works with a switch that uses a variable which is set when timer_control is changed.
It doesn't matter if they have the same bits set or not since we're testing for zero/nonzero.
(state & state_c) == 0
^ This part will always return true (state_c only has bit 2 set but state never has bit 2 set), but that's not what we want. I don't think the original expression can be simplified unless you shift one to match the same bit being set as the other. I'm not sure that's any faster though.
Mmh, right.
Did you test the speed with a function pointer (or a variable tested in a switch) that is set when timer_control is changed?
yup, no effect. I would have thought this would help, since it saves so many 'x & 3' operations, but maybe some kind of compiler optimization happens with the '& 3' in the switch since there are exactly four choices there.
Posting an update since I'm back to working on this. I've cleaned up MBC1 emulation and added multi-cart support for Bomberman collection and Mortal Kombat I & II.
Next step will be finally tackling audio which is the last step before the core is nominally functional.
Going forward, GameBoy emulation will be disabled from Gambatte and and switched to GBHawk. Color GameBoy emulation will continue to be provided by Gambatte. This should allow time for bug fixes and improvements to the core before I add CGB support to GBHawk and remove Gambatte altogether.
Also I have removed BIOS support from Gambatte since I don't think it's worth the time to sort out the bugs.
I expect I'll be able to start making Dev builds within the next month.
DO we want to keep Gambatte around as the "performance" core, similar to snes9x/bsnes, quicknes/neshawk ?
I don't know. I think Sameboy would serve this purpose better then Gambatte, but we'd need to set it up for GB support to see. I doubt it would approach 1700 fps since Gambatte is a speed machine, but it might be worth it since it would be maintainable and has a comprhensible code base. Plus we don't really need 3 GB cores.
What kind of performance can we expect at an unlocked framerate compared to Gambatte?
Currently I can get about 300 fps for GBHawk and 1700 fps for Gambatte. Once audio is added I would expect it to be closer to 270 fps.
On the title screen for Kirby's Dream Land, I get around 370 in GBHawk and around 3000 from Gambatte. I know scaling isn't perfect, but I doing the math, that's around 5.6x faster for you and and 8.1x faster for me. That's a pretty significant difference in scaling.
Also, would you be able to expose more memory domains from GBHawk at some point later on? I know my use case is pretty specific but it'd suck to lose all the domains that Gambatte offers over GBHawk (especially the ROM domain as File on Disk doesn't work for my usage).
On the title screen for Kirby's Dream Land, I get around 370 in GBHawk and around 3000 from Gambatte. I know scaling isn't perfect, but I doing the math, that's around 5.6x faster for you and and 8.1x faster for me. That's a pretty significant difference in scaling.
Ah, yeah results will vary by game. Kirby's Dream Land is pretty intense with sprites. I only get 260 on the title screen in GBHawk (Gambatte is hardly bothered at 1650.) GBHawk does everything one cycle at a time, so things take significantly longer if there are sprites to process.
Also, would you be able to expose more memory domains from GBHawk at some point later on? I know my use case is pretty specific but it'd suck to lose all the domains that Gambatte offers over GBHawk (especially the ROM domain as File on Disk doesn't work for my usage).
Of course! I'll be adding all the bells and whistles as things progress. That's part of the point of going in house with this.
Having said that, if anyone is interested in jumping in and helping with development, there is still tons of stuff to do. Despite the lack of audio, the core is fairly mature and robust from an architecture standpoint, and really it's matter of building up capability, so now is a good time for people who want to try their hand at development to give it a go.
Is this about recording?
A 60fps TAS of 30 minutes has 108,000 frames, and at an uncapped framerate of 300fps it would still take only 6 minutes to record a video dump, which seems fast enough for me.
Is this about recording?
A 60fps TAS of 30 minutes has 108,000 frames, and at an uncapped framerate of 300fps it would still take only 6 minutes to record a video dump, which seems fast enough for me.
Nah. While I do have an interest in both speedrunning and TASing, my main usage of Bizhawk is through my work on and my usage of the Real Time Corrupter mod. Recently I've been working on a little project to build blacklists which involves iterating through every single possible one-byte corruption for a game and checking for a crash.
I've been building up lists of single address/value combos that guarantee a crash for specific games (primarily the most popular games on the simpler systems) so I can then play around with creating a blacklist system.
Once it reached a more mature state, I was interested in running GBHawk through on a few games I've already run Gambatte through as I wanted to see how it would handle them compared to each Gambatte (NESHawk and QuickNES will sometimes handle the same corruption in VERY different ways).
The limiting factor in my current approach (which is just iterate through every possible single-byte corruption possible within the main ram, so 2088960 iterations per run) is the speed of emulation as I have to let the game progress a few frames to detect if a crash occurs. I also have to run it with multiple states to test if it's a guaranteed crash or dependent on what else is loaded into memory. I was hoping GBHawk would be relatively fast so I could do a larger comparison than I was able to with NESHawk vs QuickNES without waiting forever.
Small update as I work through the Audio test ROMs.
I'm about 50% done. Everything is up and running and sounds mostly correct (with a few small glitches to sort out.) I made it through the first few test ROMs without too much trouble, and I made sure to integrate save state support as I go. Really the only difficult part left is the waveRAM tests, which will probably take a while since they are regarded as being quite challenging. Overall though things are progressing pretty well.
I also tested out Sameboy for GB support. It was only slightly faster then GBHawk though, so probably can't serve the purpose of 'performance core' after all. So I guess Gambatte will live on in this role.
Alright, well luckily other people had already been through the trouble of figuring out how the wave RAM tests work so I basically just had to read through some posts to get the right behaviour. That made it much easier.
With this GBHawk is nominally operational.
I integrated it into the Dev Builds for anyone who wants to test. There are still some bugs so if anyone finds anything please report it here.
I also removed BIOS support from Gambatte due to it's bugginess.
I also put a core picker into BizHawk so you can choose between GBHawk and Gambatte.
There is still a long way to go in terms of development, but as it is right now it's already passes almost all the available test roms, which means it's really solid as a baseline model to develop on.
Next steps will be working through mappers, adding link cable support, implementing nitty gritty details of the ppu, and fixing bugs.
Once all that is done I might take a look at cgb.
Things I've found so far (this post is going to be edited as I go along). I'm not sure how much you already know about so I'm just going to post everything I run into. I'm just going to be picking random games and looking for obvious issues.
-You may already know this one, but at the moment you're not opening the BIOS dialog if the bios file is missing (it says the bios couldn't be found but it doesn't give the normal prompt to set the bios). The core attempts to run without the bios and crashes as you'd expect.
-There's also no default controller mapping but I'm assuming you also know that one as well. Just posting it in-case you manually set your controls and forgot about the auto-config.
-Having some weird issues with the sound in Kirby's Dream Land. Just load the game and play the Green Greens intro sequence. You should hear the issue right away. There's an extra note thrown in there, a note isn't cut-off, and the timing at the end gets funky and it speeds up a bunch.
Gambatte: https://streamable.com/9rubp
GBHawk: https://streamable.com/k60pe
BSnes SGB: https://streamable.com/rbtze
Sameboy SGB (this is pitched up a semitone for some reason): https://streamable.com/gew79
I don't have any hardware on-hand to test against but it's clear it's incorrect.
-Tetris has a note on the intro text that shouldn't be there. https://streamable.com/trdwz
-Super Mario Land 2 has the same issue (as well as some other audio issues). https://streamable.com/mbyuj
-Many other games have that same issue (seems like one of the channels just isn't properly getting cut off if nothing else plays in that channel?)
-Barbie Game Girl has some horrible audio squeals that don't exist in other cores. https://streamable.com/ps2hk
-The Pokemon games don't boot (mapper?)
-Who Framed Roger Rabbit has a myriad of issues (mapper?). https://streamable.com/391ie
-HAL Wrestling gives a screen full of random garbage during its transition screens (doesn't do this on Gambatte). https://streamable.com/d163r
-Rewinding in Kwirk's menu breaks the audio https://streamable.com/w8s9k
-The same issue applies to Tom & Jerry
Thanks for the testing. Yeah any reports are helpful, don't assume I know anything! 8D
I fixed the BIOS and controller initialization issues.
Hmmm, I'll have to look into those audio issues, the test ROM tested everything except the volume envelope pretty thoroughly, so maybe I messed up something there.
Thanks for the testing. Yeah any reports are helpful, don't assume I know anything! 8D
I fixed the BIOS and controller initialization issues.
Hmmm, I'll have to look into those audio issues, the test ROM tested everything except the volume envelope pretty thoroughly, so maybe I messed up something there.
Sounds good. I also edited that post and added a few more issues. Once you fix those audio issues, I'll go looking again. I don't want to plague you with things related to the same core audio issues as it meant a bunch of extra testing.
Also is there any easy way to tell with GB if it's just an unimplemented mapper issue? I don't know much about the Gameboy itself and a quick google search wasn't revealing much info on various Gameboy mappers
Controls seem to be messed up in all games. I guess it's a controller initialization thing?
Metroid 2 has glitchy graphics.
BTW, are there any chances for a new SGB core based on GBhawk in the future?
Controls seem to be messed up in all games. I guess it's a controller initialization thing?
Metroid 2 has glitchy graphics.
BTW, are there any chances for a new SGB core based on GBhawk in the future?
Can also confirm that the update which added the controller initialization broke the controls all together (Up is Right, A is Start, etc).
Also the volume levels output by GBHawk are basically the quietest of any core. Could the output volume be bumped up to match the other cores a bit better? I know there's no standard volume (in my opinion there really needs to be) but getting it closer to the other cores would at least help with the issue.
Fixed the controllers, sloppy mistake by me there.
Fixed audio desync in kwirk.
Removed all BIOS code from Gambatte entirely, so I'm really hoping that fixes any random crashes.
I'll try and track down those audio bugs next (and adjust the volume, which is really just multplying the output by a larger number.)
Not sure about SGB support, it would be really nice, but the parts that need to use snes hardware would be tricky.
EDIT: Audio fixed, I think, I increased the volume too.
EDIT2: Actually I noticed the coin sound in mario land 2 is way off, I'll try to fix that next.
Fixed the controllers, sloppy mistake by me there.
Fixed audio desync in kwirk.
Removed all BIOS code from Gambatte entirely, so I'm really hoping that fixes any random crashes.
I'll try and track down those audio bugs next (and adjust the volume, which is really just multplying the output by a larger number.)
Not sure about SGB support, it would be really nice, but the parts that need to use snes hardware would be tricky.
EDIT: Audio fixed, I think, I increased the volume too.
EDIT2: Actually I noticed the coin sound in mario land 2 is way off, I'll try to fix that next.
You said it was passing all the test roms, right? I'm surprised it was able to pass the test roms with so many audio errors in place
Edit: Going through my list from before and re-checking. I know some of these haven't been fixed but I'm going to re-list them for clarity sake.
I'm still shotgunning more games and checking for extremely obvious issues that manifest within the first minute or two. I'll test more in-depth against games I know better later on.
New issues I've found:
-If emulation is paused for any reason, the audio gets messed up slightly at unpause (then fixes itself). https://streamable.com/bst5h
-Mario's jump noise is completely wrong in Super Mario Land. https://streamable.com/m0rxu
-Jeopardy Teen Tournament has weird behavior where the music pauses when the screen draws an update in the intro. Gambatte handles it the same as real hardware whereas it manifests as crackles in GBHawk
-The end of the Green Greens intro in Kirby's Dreamland speeds up dramatically when the screen fade occurs. https://streamable.com/zc0jh
-Metroid II has some graphical issues (garbage showing during the screen transition and Samus just not appearing until I walk past a certain point): https://streamable.com/qzyfu
-The vibrato effect seems to sound off in general. I can't figure out how exactly to describe it but once you hear it you'll hear it. One of the best examples I could find was Star Wars
Gambatte: https://streamable.com/1nz7a
GBHawk: https://streamable.com/bt993
Outstanding issues:
-Barbie Game Girl still has horrible audio squealing. https://streamable.com/zv0qm
-The Pokemon games don't boot (mapper?)
-Who Framed Roger Rabbit has a myriad of issues (mapper?). https://streamable.com/391ie
-HAL Wrestling gives a screen full of random garbage during its transition screens (doesn't do this on Gambatte). https://streamable.com/d163r
Alright, well luckily other people had already been through the trouble of figuring out how the wave RAM tests work so I basically just had to read through some posts to get the right behaviour. That made it much easier.
With this GBHawk is nominally operational.
I integrated it into the Dev Builds for anyone who wants to test. There are still some bugs so if anyone finds anything please report it here.
I also removed BIOS support from Gambatte due to it's bugginess.
I also put a core picker into BizHawk so you can choose between GBHawk and Gambatte.
There is still a long way to go in terms of development, but as it is right now it's already passes almost all the available test roms, which means it's really solid as a baseline model to develop on.
Next steps will be working through mappers, adding link cable support, implementing nitty gritty details of the ppu, and fixing bugs.
Once all that is done I might take a look at cgb.
