1 2
12 13 14
19 20
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
I've only been testing the GBC version so far, and saveRAM and the lua script both work fine for me. Yeah it looks like saveram isn't in the code path of reboot core from what I see. Flush Saveram is the manual method to save the saveram. If you want to save it at any time, use that. But remember it won't load unless you have 'use existing saveram' set to true.
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
@jlun2: I fixed the cart RAM domain in GBHawk so your lua script should work now, please retest and let me know if everything is good. This was unique / troublesome enough that I decided to write down the technically details, anyone interested can read on. This was actually a pretty weird case that shows how important it is to watch out for garbage collection in managed code in C#. What went wrong is here:
var CartRam = new MemoryDomainByteArray("CartRAM", MemoryDomain.Endian.Little, cart_RAM, true, 1);
This function takes the whole of cart_RAM as an argument and used in an assignment :
Data = data (where data is cart_RAM in this case.
Data has a setter:
public byte[] Data
		{
			get => _data;
			set
			{
				_data = value;
				Size = _data.LongLength;
			}
		}
_data is another byte array that is internal to the memory domain. Internally, this assignment is an assignment by pointer. _data gets a pointer to cart_RAM, even though it doesn't look like it. In c++, this would be what you want and expect. But in C#, the underlying domain cart_RAM can be moved without you knowing, in an attempt to manage memory for you. From here on is somewhat speculative, but what I THINK is happening is that memory management moves cart_RAM, but the original copy can't be deleted because their is a pointer to it. So you get left with a stale copy of cart_RAM that the memory domain points to while the actual cart_RAM array getting updated as it should. This, is super annoying. The solution is to just use the delegate method of defining domains that doesn't rely on a pointer internally. The weird thing is that other cores (ex NESHawk) use this method of defining memory domains by default and I've never seen a case where this has happened before. Probably it should be used for static arrays only (or not at all if it's just going to leave a stale copy clogging up memory.)
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
I made a new setting in GBHawk to sync memory domains to VBlank. This makes LUA scripts for GBHawk more consistent with Gambatte. This also helps in comparing memory in Hex Editor. NOTE: this only works for individual memory domains, not system bus. Also it doesn't apply to writes, writes always go to the actual underlying memory. You can turn this on or off anytime in the settings menu.
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
Some interesting developments have been happening in gameboy console verification. I looked into this for jlun2 in Wario Land II:
jlun2 wrote:
While routing for 100%, I asked TiKevin83 to check for if the OoB in this game was emulated right by given them input files for any% improvement. An input file that did not soft reset the game synced back, but the one that did use a soft reset to alter OoB layout did not.
This was an interesting desync because it involved the cpu accessing VRAM (0x8B2C) when it was still in use by the ppu for rendering. Normally this would be expected to return 0xFF, but the way the desync happened this could not be the case. In fact, the underlying value was already 0xFF, so whether or not the cpu could access this address, it should still be returning 0xFF. But the console verification attempt revealed that this could not be the case, what needed to be returned was a value for a coin. The only clue about what might be happening is that this access was blocked on the very last pixel of rendering, right before access was restored to the CPU. This is just speculation, but I think what happened is that access is restored to the CPU, but it's too late for the address latch, so what gets returned is just the last latch on the bus that the PPU read. The PPU is always reading from memory, even when it has all the tile data it needs already. Sure enough, if I implement this behaviour I get a coin and desync exactly as in the console verification attempt. Also, execution between Gambatte and GBHawk is identical cycle for cycle up until this exact moment. Some test ROMs will be needed to determine if this is truly what's happening, but I don't see any other way for a value other then 0xFF to be returned without this behaviour. I have it implemented in the current version of GBHawk and hopefully a console verification of Wario Land II can work with this. ___________ Also in the realm of Wario Land, there was some speculation on whether or not the game end glitch run was actually possible on console for wario land 1. The thought was that the STOP would not be able to escaped from because interrupts for joypad were not enabled. However some test roms from https://github.com/AntonioND/gbc-hw-tests require STOP to be returned from with joypad press even if interrupts are turned off. So the mechanism itself should work. However, the STOP happens on the same frame buttons are already being pressed. It seems that in this case STOP is not exited. So maybe this will need subframe timing in order to release the buttons before the stop.
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
I made optimizations / accuracy improvements / cleanup to GBHawk's serial port code today. It is noticeably faster now, especially in 4 player mode. Normal GBHawk is faster too by about 5-10 fps. If anyone notices any issues with the linking now let me know. I tested a lot of different cases and everything still seems to work though. Also the VRAM access glitch above is still under investigation, definitely some new behaviour there but details aren't nailed down yet.
EZGames69
He/They
Publisher, Reviewer, Expert player (4460)
Joined: 5/29/2017
Posts: 2761
The recent submission of Pokemon Crystal has revealed an audio issue with music, some of the audio has weird static or echoy noises to it (most noticable with the Oak theme intro). I wrote a ticket about this here: https://github.com/TASVideos/BizHawk/issues/2006
[14:15] <feos> WinDOES what DOSn't 12:33:44 PM <Mothrayas> "I got an oof with my game!" Mothrayas Today at 12:22: <Colin> thank you for supporting noble causes such as my feet MemoryTAS Today at 11:55 AM: you wouldn't know beauty if it slapped you in the face with a giant fish [Today at 4:51 PM] Mothrayas: although if you like your own tweets that's the online equivalent of sniffing your own farts and probably tells a lot about you as a person MemoryTAS Today at 7:01 PM: But I exert big staff energy honestly lol Samsara Today at 1:20 PM: wouldn't ACE in a real life TAS just stand for Actually Cease Existing
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
I've cleaned up a lot of HDMA edge cases and fixed up speed switch timing, almost ready to start checking double speed mode and looking at the pokemon TCG runs. I had looked at TCG1 earlier but failed due to speed switch timing issues (also TCG1 constantly turns the screen off which makes syncing pretty tedious.) Still a lot of work to be done, but I'm hoping some more robust double speed mode accuracy isn't too far off.
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
I refectored GBHawk audio, so games should sound much better now. There's a bit more popping then in Gambatte in certain cases (like pokemon yellow) but in those cases it is shutting off Wave channel, so not sure why it wouldn't pop. Games and demos that use DC bias and direct volume modulation should in particular sound much better.
Editor, Reviewer, Skilled player (1358)
Joined: 9/12/2016
Posts: 1646
Location: Italy
SubGBHawk needs to implement CycleCount value for header.txt of .tasproj and .bk2 files, like Gambatte does when EqualLengthFrames is set to false. It's necessary for the site parser to be able to automatically calculate the accurate movie length.
my personal page - my YouTube channel - my GitHub - my Discord: thunderaxe31 <Masterjun> if you look at the "NES" in a weird angle, it actually clearly says "GBA"
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
^ Fixed in master.
Skilled player (1741)
Joined: 9/17/2009
Posts: 4981
Location: ̶C̶a̶n̶a̶d̶a̶ "Kanatah"
I'm not sure if this is normal, but on Sailor Moon, the function emu.totalexecutedcycles() seems to be returning a value ~twice the amount in GBHawk compared to GameBatte in in interim: Is this normal? Gamebatte is the left, GBHawk on the right. (Interestingly, the script I was using checks 0xD102 in System bus to display stuff, and it seems the BIOS in GBHawk vs Gamebatte is different in it's value at this point. Not sure if that affects anything) The lag differences between the 2 are now much smaller; previously every transition would greatly lag by 17+ frames, but now the difference is more like +1 or 2 frames in Gamebatte compared to GBHawk (per transition). This makes comparing much easier for this game.
TiKevin83
He/Him
Ambassador, Moderator, Site Developer, Player (155)
Joined: 3/17/2018
Posts: 358
Location: Holland, MI
There was a fix for GB mode BIOS in 2.4.1, it was being edited under certain conditions which only affect GBC. The totalexecutedcycles count is probably different intentionally. The cpu works in t-cycles but everything works out to a multiple of 4 t cycles due to being memory bound, which is where you get m-cycles at 1mhz. But to account for GBC double speed mode Gambatte counts at twice that rate. GBhawk is probably counting single speed t cycles.
Editor, Emulator Coder, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I don't think there's a right or wrong answer here. TotalExecutedCycles should be relative to a "master clock", but the rate choice for the master clock is somewhat arbitrary, and as pointed out the architecture of the GB makes it more ambiguous than some systems what the right master clock rate is. Ideally we should be exposing a MasterClockRate or similar field as well.
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
Trace Logger gives the same cycle counts for both cores. Looks like gambatte's count is being cut in half for the lua function somehow, I'll look into it. EDIT: Yeah, Gambatte is using master clock rate (~4MHz) / 2 for TotalExecutedCycles. This comes from the audio code it seems like? Not sure yet how to get the count it uses for Trace Logger.
Editor, Emulator Coder, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Alyosha wrote:
Trace Logger gives the same cycle counts for both cores. Looks like gambatte's count is being cut in half for the lua function somehow, I'll look into it. EDIT: Yeah, Gambatte is using master clock rate (~4MHz) / 2 for TotalExecutedCycles. This comes from the audio code it seems like? Not sure yet how to get the count it uses for Trace Logger.
The frame advance external API uses the 2mhz notion of master clock, not a 1mhz, 4mhz, or 8mhz, because gambatte's audio code has always worked that way, so it was natural for that. Looks like a lot of CPU stuff internally uses a 4mhz master clock. Tracelogger using 4mhz when frame advance already used 2mhz was just an error for sure. I worry that the tracelogger's notion of timing might be busted after a while; doesn't gambatte's cyclecounter variable occasionally reset backwards to account for 2^32 rollover?
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
natt wrote:
I worry that the tracelogger's notion of timing might be busted after a while; doesn't gambatte's cyclecounter variable occasionally reset backwards to account for 2^32 rollover?
I thought this was fixed, but I checked just now and it is not. Not sure how difficult it would be to make it 64 bit instead of 32.
Editor, Emulator Coder, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I worry about changing the cycleCounter that the emulator uses internally; touches a lot of things. Wouldn't it be easier to change just the tracelogger code?
Joined: 7/17/2012
Posts: 543
Location: Switzerland
Maybe this can interest you Alyosha (or others). Edge of Emulation: Game Boy Sewing Machines
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
Skilled player (1741)
Joined: 9/17/2009
Posts: 4981
Location: ̶C̶a̶n̶a̶d̶a̶ "Kanatah"
I compared every frame it took for the first stage in Sailor Moon for the overworld segments, excluding lag and dialogue: https://cdn.discordapp.com/attachments/280808167993245707/721823687031914546/unknown.png Is there something going on that leads to the non-lag frames being slightly different between the cores? This has the effect of also affecting RNG. Here's the input files for the 2.4.2 movies https://cdn.discordapp.com/attachments/280808167993245707/721825124906696704/Bishoujo_Senshi_Sailormoon_R_Story_Gamebatte.bk2 https://cdn.discordapp.com/attachments/280808167993245707/721826054980894831/Bishoujo_Senshi_Sailormoon_R_Story_GBHawk.bk2 The platformer length is different since the "lag" is different is different in GBHawk so I haven't optimized it yet. Edit: ThunderAxe31 mentioned GBHawk uses equal length frames, which I forgot. Need to retime Gambatte, wait. Edit 2: Added timing for Gambatte 2.4.2 equal frame length. It matches far more closer to GBHawk now too, so nice work. The RNG is now similar(ish, haven't checked platformer), but non lag is still different by 1 frame? https://cdn.discordapp.com/attachments/280808167993245707/721938795200774264/unknown.png https://cdn.discordapp.com/attachments/280808167993245707/721936551042351134/After_Burst_Japan_Normal_GambetteEq_Frame.bk2 [MOD EDIT: Unembedded large images]
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
Gambatte's 'equal length' frames option doesn't actually make every frame equal length. So, unfortunately there isn't a way to get a one-to-one comparison with GBHawk just by looking at frames, some adjustments have to be made.
Editor, Emulator Coder, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
It's equal up to jitter caused by instruction length granularity, right? It was always a political TASVideos thing more than anything else -- in the long run, it will exactly match God's Perfect Framerate.
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
The jitter is always positive though, and generally averages out to about 4 cycles (but can occasionally be greater) so it accumulates over time. Also I'm not sure how input is processed in gambatte in equal frame mode, if I remember right there was a pokemon run that had an issue with one input falling in between controller reads and causing an issue,
Editor, Emulator Coder, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Alyosha wrote:
The jitter is always positive though, and generally averages out to about 4 cycles (but can occasionally be greater) so it accumulates over time.
This sounded wrong, so I checked it. The code still works as it did since we added the selection for two different frame timing options. Gambatte may never undershoot a request, but we remember that and ask for fewer cycles next time when it overshoots. Manually logging values confirms that it's behaving correctly; some frames are shorter than 35112, some are longer, and the average is 35112 as it should be. The only way there could be drift is if there was a fundamental timing flaw deep in Gambatte that wasn't showing up in its reconciliation of audio timing.
Alyosha wrote:
Also I'm not sure how input is processed in gambatte in equal frame mode, if I remember right there was a pokemon run that had an issue with one input falling in between controller reads and causing an issue,
It's about as bad as every other attempt to merge real systems with their real behaviors and the absolute pipe dream fantasy that is constant framerate TASing. The most obvious problem with equal length frames is that measured latency between what you input into the controller and what you see on the screen can vary by +/- 1 frames as alignment shifts. Beyond that, is there a possibility that a particular game that only polls once per "frame", could poll twice in one of these "frames"? Sure, with the jitter and other variations in timing lining up right. I never wanted equal length frames.
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
Looks like you're right, I must be mis-remembering something from somewhere, can't look back right now though.
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
http://tasvideos.org/userfiles/info/64261017438734931 After many hours of head scratching, I've finally gotten double speed mode timing to the point where I can sync an actual TAS. This is the current submission of pokemon trading card game resynced to dev build of GBHawk. This has been a very challenging process and I'm only on the first step, but the timing needed for this TAS to work is very tight and it nails down some hard points that I can build off of for future work. Also, GBHawk and Gambatte are starting to diverge in terms of which tests they pass and which they fail. Its amazing to me that so many TASes that require very careful timing are console verified while disagreeing on some pretty important tests. And these aren't just random un-used edge cases either, they could realistically show up in games, they just haven't yet.
1 2
12 13 14
19 20