Posts for Alyosha


Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Today I found a new way to crash the GBA. For some background info, the GBA has a prefetch unit that can read instructions from the cartridge ahead of time and store them in a buffer that can be read quickly by the cpu. Also, the ARM7TDMI has two modes of operation, ARM mode which uses 32 bit instruction, and Thumb mode which uses 16 bit instructions. Finally, the cpu has a 3 stage pipeline, so the currently read instruction is 2 ahead of the one being executed. The prefetch unit doesn't care what mode the cpu is in, it just reads 16 bit values. If the prefetch buffer has only 1 16 bit value available, the next fetch just carries on as normal to complete the 32 bits needed. You can branch back and forth between ARM and Thumb modes with a single instruction. So, if you branch two instructions ahead, the next value you have to read will also be the next value in the prefetch buffer, because of the 3 stage pipeline (it if has that many values available of course.) In this case you can continue to read values from the prefetch unit even if you changed execution modes from 16 to 32 bits. Except, the prefetch unit will halt if its limit is reached, which is 8 16 bit values. In this case it waits until it is empty to do anything else, and it also waits for the start of the next instruction read to be re-enabled. So, if you were to fill the buffer in Thumb mode, then branch to ARM mode 2 instructions ahead with an odd number of values in the prefetch buffer, you will still read from the buffer but run out of values half way through reading a 32 bit ARM instruction. In this case, the console will crash, as it cannot the read for the next instruction. (At least this is my understanding of what I'm seeing.) This is not such a contrived setup as it may seem. Games branch 2 instruction ahead pretty commonly, they just don't do so between cpu modes that I've observed. Also the prefetch buffer can be quickly filled up if repeatedly reading values from EWRAM, and this also happens in games, and is important to emulate for console verification. I'd be curious to know if Nintendo was aware of this possibility. Obviously this isn't very helpful, but it's cool to see something new.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
It's pretty surprising how easy it still is to write test ROMs that fail in GBAHawk but pass on hardware with just a few assembly instructions. Some things are nonsense, like only writing the first half of a BL instruction in thumb mode, which hopefully no games do. Other things are important, like writing modes to CPSR with upper mode bit clear, which is well known in various emulator issue trackers to break Grunty's Revenge if you don't emulate keeping the bit set. So far I haven't been able to conjure up the correct test that fixes Flinstones though. I've tried to resync other games that look short and glitchy enough to be interesting test cases, but without much success. Bionicle desyncs about half way through the game in a way I can't figure out how to fix. But on console it desyncs even earlier than that, I think due to inconsistent input read times. Ty 2 is very sensitive to EEPROM timings, may or may not be workable depending on EEPROM consistency. I still think the most likely problem for Flintstones is somehow the prefetcher, I just have no idea how. The next game I will try is DK: King of Swing
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Unsurprisingly I'm facing a desync on console on the very first game I tried after Metroid Fusion (which happened to be Flintstones.) So far I can't figure out what the problem might be. The up side of game testing is that it stresses the console much more than crafted tests do, but the down side is that when a problem shows up, it's very challenging to figure out what it might be, since it could be anything in the system. At first I expected it to still be the prefetcher, and I made several new tests, fixed a few bugs, and cleaned up prefetcher code quite a bit. This didn't fix the desync though. Currently I am out of ideas. I think all I can do for now is keep testing with other games and see if any patterns emerge. So, testing continues.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
despoa wrote:
Can you put an "About" tab that shows the version number so it will be easier to keep track of various versions for movie playback purposes?
Yeah I'll do that for next rtelease.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I've released GBAHawk v2.0.0 now that Metroid Fusion is finally console verified. This also contains misc. other bug fixes, including to EEPROM timing where I thought I was following the GBA Tek spec for timing but I made a mistake and things were happening instantly. I'll be focusing on resyncing and testing various other games now. There are a lot of cool GBA games, but also a lot of them use Flash or EEPROM which may have timings imprecise enough to cause problems in verification. For now I'll focus on SRAM games or games without saving to make sure I'm not missing anything common enough to effect a lot of games, then I'll try some of the other save types. In terms of emulation there are still a multitude of untested / unimplemented edge case behaviours, but I'm content for now to take a break and work on verifications. If past verification efforts have taught me anything its that unexpected emulation typically show up in testing, so I'll probably have plenty to keep me busy for a long while to come.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
EDIT: Video removed, superceded by proper resync retaining original inputs Finally was able to console verify (a resync of) Metroid Fusion. It turns out there is some quirky edge cases of branching to the next address the prefetcher will fetch, and emulation of this needs to be correct enough for Metroid Fusion to sync. This run ended up requiring many precise timings and careful emulation of edge cases, so I'm cautiously optimistic that other games will console verify as well. RetroEdit's Shrek 2 input hack also now works in GBAHawk, so that's another good sign (although the actual game uses EEPROM which has imprecise timings.) But hopefully many SRAM games will work at least. Console verifying this game has been my goal ever since I started working on GBAHawk, so its really cool to finally see it working. I have a little clean up to do in the code and will release GBAHawk 2.0.0 with the emulation fixes needed for this to work. Now the grind to resync other runs can start. I'm really interested in Castlevania and mega Man Zero series. Would be cool to see those working. I can't figure out how to resync Fire Emblem, so I'm going to put that one on hold for now. Eventually I also have to characterize EEPROM and Flash timings, but that's something for later.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
With a bit more work on the prefetcher I was able to get correct values in RetroEdit's Skrek 2 ROM Hack: I just needed to be a bit more careful with the full prefetch buffer behaviour to get things to work. Metroid Fusion currently desyncs on the Nightmare fight. Probably something is still missing with the prefetcher not covered by Shrek 2, possibly LDM / STM as I noticed those used quite a bit in the trace log. Getting really close to console verification now.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Making test ROMs is going pretty well. I found a new (but obvious in hindsight) audio FIFO behaviour (can't add samples to the FIFO manually while audio power is off) and nailed down exact timing of FIFO DMA. I also found an interesting prefetcher behaviour. When the prefetcher is full, it seems to stall until it is empty again, and then continue with non-sequential timing on the next access. This behaviour is actually important for Shrek 2. That game uses EWRAM a lot, and also runs a lot of code from ROM, so the prefetcher has a lot of time to work. When I implement this behaviour in GBAHawk, I get 0x25FC on the final time, only 21 frames from the correct value of 0x2611. I imagine the remaining issues with Shrek are prefetcher related, but I currently have ideas of what to test. I may just make tests running long lists of various instructions and see if anything unusual pops up.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
The lag frame at the start is because FCEUX is hard coded to idle for an extra frame at power on.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I've released version 1.7 of GBAHawk which has more stable linking and improved emulation accuracy, particularly for prefetch. It also cleans up numerous minor bugs. With this release I've finally reached the point where I'll have to develop some of my own tests to make more progress. Things are finally starting to come together and it's refreshing to be on the frontier of emulation for a change. Audio DMA tests will definitely need to be first, so progress will slow down for a while as I figure out how to put things together.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Since it seemed to me like prefetch was the most likely source of sync error, I decided to recompile the tte_demo with prefetch enabled to see what errors popped up. To my surprise there was only one failing count. Looking into it, the only possible fix (that didn't break everything else) was for ROM accesses that aren't instruction fetches to completely reset the prefetcher. Previously I had only reset the current fetch. The prefetcher can have up to 8 values buffered, but rarely has more than 1, so this behaviour escaped previous testing. Implementing this finally brings further sync progress to Fire Emblem: EDIT: video removed, superceded by complete resync Unfortunately re-syncing Fire Emblem is incredibly tedious as the current run was made on VBA, so many lag frames have to be added. So it will be a slow grind working on more stages from here. Metroid Fusion now syncs up to 30 minutes into the run, surprisingly easily. Lots of good progress there. Finally RetroEdit's Shrek 2 with built in inputs now gives 25DA as opposed to 2520 previously, much better but still not quite there (supposed to be 2611.) I'm going to keep working on Fire Emblem and see how far I can get. I'm also going to look for shorter runs to work on now that I'm starting to see some progress.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
It turns out that until now I had missed an important detail in prefetch emulation, in that the prefetcher only runs when executing code from ROM. This is stated pretty clearly in mGBA's article on the matter, and it makes sense (no point running a whole separate component if you are say executing code from IWRAM) but I evidently just glossed over it. After implementing this, Metroid Fusion now syncs to as far as I have managed to resync the movie file itself: EDIT: video removed, superceded by complete resync. It's cool to see some new progress on first party games syncing on console. This fix doesn't seem to help Fire Emblem at all though, so still improvements left to be made. EDIT: Oh, and also in testing I realized Sushi the Cat actually wasn't behaving the same on console as in the TAS. It turns out there are two LESS lag frames at one point in loading. The run still plays out ok, but you can see the difference in how enemy animation frames line up. GBAHawk gave the correct lag, so I resynced the movie and redid the verificaiton from it.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Cool and very obscure new discovery, nice. I wonder how many other games have stuff like this? I managed to console verify this (I used BizHawk which has one less lag frame at the start but is otherwise identical.) Link to video
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I took another look at 'world_map_gba' to try to resolver the issue. The first thing I did was try out the ROM on GBP to see the expected result: The interesting scanline is the one with a single brown pixel that sticks out on the right side of the castle into the grass approximately at the height of the player's eyes. This scanline is indicative of audio DMA delaying execution of the code that updates the reference regs when HBL IRQ happens. GBP seems to internally blend frames together, and this is why the effected scanline is slightly duller and blurrier than the others, as it is flickering between frames. In fact this is exactly what NanoboyAdvance gets if you turn on LCD ghosting (without it the flickering is noticeable, but this is a display issue not an emulation issue.) Then I looked at the code the game was using to see what the driver of the issue is and why GBAHawk wasn't matching hardware. It turns out pretty much everything except FIFO DMA is a non-factor. The timer that ultimately runs the FIFO is turned on after a VBlank IRQ, and the prefetcher isn't turned on at the time, and as these are well studied things, the absolute timing of when FIFO ticks happen is set. The latching of various involved ppu parameters is also well tested. So really the only movable parameter is timing of the FIFO DMAs. Before I could mess with that though I had several small bugs in the audio code (off by one errors and not clearing fifo on reset) as well as the ppu (a mish-mash old and new code from when I was working on reference point latching.) Once those were fixed it was just a matter of checking which FIFO ticks the DMA needed to run on to match hardware. Having done so however, the results are kind of awkward, new DMAs occur when the sample buffer has 14 samples left, instead of the expected and more natural 16. So something still likely isn't right. I implemented what I had for now though, as it was still better than before and fixes some definite bugs. A more thorough testing of FIFO DMA is still needed.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I finally redid my IRQ code, and the results are much cleaner and resolve a couple of issues. One issue is when IME was being checked which would have been hard to fix with my old code but is pretty naturally following the correct timing in the new code. The other is an edge case encountered in trading in pokemon where a serial IRQ was triggered at exactly the wrong cycle to skip an IME enable. The old code had no way to follow up on this and trigger it later, but its not a problem for the new code. Below is a video of pokemon trading in action. Link to video The linked core is able to keep up at 60 fps everywhere except saving. Other games like Advance Wars 2 also don't make it to 60 fps with multi-pak linking at all, as there is simply too much code running, but at least there are no linking errors. I have some more clean ups to do before making an official release. So far in my testing there are no regressions in test ROMs, games, or TASes, so that's good (you never really know what will happen when changing something fundamental like IRQs.) The last thing I want to do is figure out cancel-irq-ie.gba, which seems to be an issue of figuring what happens when flags/enables are being set/cleared at the same time.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I released GBAHawk version 1.6.1 mainly as a bug fix release. A major bug was saving cart RAM twice, which obviously bloats the state size needlessly, especially when playing games with 256k RAM. Besides bug fixes I also added support for Warioware Twisted. I use a different control scheme than mGBA uses, at least in the BizHawk implementation. There, mouse position corresponds to angular rate (which is what the cart ultimately reads.) In GBAHawk mouse position corresponds to angular position. So you control the game with speed of mouse movement. I actually got a cart (JPN version) just to test this out. I think I captured the feel of the real game pretty well, hysteresis and all. That brings game compatibility up to where I want it for now. Next up is a rewrite of the IRQ handler.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
In the hide and seek level you can use your ghost to collect the gems and save several seconds.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
WhiteHat94 wrote:
I did an RTA run of the NES port last year, not sure how directly similar the versions are but figured I would mention it at least. https://www.youtube.com/watch?v=HNmJgGi-7zw
The games arent directly comparable, but yuour run did make me realize that i didnt consider death abuse, which would save me a lot of time in the third and forth dungeons, so thanks for posting.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
-superseded- Here is a console verified complete test run of the game. I was really happy the verification made it all the way to the end. It turns out there are some interesting tricks and glitches in this game. The biggest one is being able to hit enemies with multiple weapons at the same time. With some precise positioning this allows me to kill several bosses very quickly, including the last boss with only a single dynamite and sword slash. The next most important glitch is enemy despawn. Occasionally enemies simply won't spawn. The most important use of this is the Bat boss refight, where I manipulate him not to spawn which saves a lot of time since this version of the boss has greatly increased health. Also if you press up against a wall while going around a corner, you get a small but noticable boost. This saves a few frames at a time, which adds up to a lot over the course of the run. Routing is pretty fixed, since you need items in each previous dungeons to complete the next one, and they are all far apart. The only real routing choice is whether or not to get the powerup and red key from the desert cave. It takes 29 seconds to cross the desert without going to the cave, and 76 seconds with the cave. The time it takes inside the cave is about the same as it would take to go out of your way to get a red key in the third dungeon if you didn't get it in the cave. So, this mean it costs 47 seconds to go to the cave and get a weapon powerup. However this time is also spent farming, since you need 100 gold by the time you reach the merchant to buy the dynamite. So I think if I greatly improve farming early game I can skip the cave. It's hard to estimate how much time the powerup saves, but I doubt it is more than 15 seconds. So I should be roughly 30 seconds ahead.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Here is a really well polished homebrew adventure game called Anguna. I made a test run of the first dungeon: https://tasvideos.org/UserFiles/Info/638263248982014754 So far it syncs on console: -supercded- I'm going to be working on it over time in between emulation improvements. Seems interesting enough but not too long.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I released GBAHawk v1.6 with support for RTC and solar sensor. So now Pokemon RTC events should work and Boktai games can be played. I also added a setting for disabled RTC, which i guess is what pokemon speedruns use. I haven't tested pokemon linking yet, that's one of the next follow up things to work on. I believe with this the only other incompatibility is in WarioWare which needs a different kind of gyro sensor than Yoshi uses. I'll implement that eventually. Of course there are many peripherals but those hold no interest to me, so probably I'll leave it at that. Maybe the only nice thing to have would be the e-reader, but that's in the future. Time now to look at those IRQ tests, then I'll finally be caught up at the point of having to write my own test ROMs.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Pretty interesting little puzzle game, nice work!
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I released version 1.5.1 of GBAHawk which contains numerous bug fixes including initial compatibility for pokemon (though RTC still doesn't work.) I also realized I missed the 'archived' NBA tests in my accounting, where I currently fail some of the IRQ tests, seems to be some non-trivial things happening there I haven't looked at yet. I think the ppu tests are working, so current number of failed tests is 3. For now though it's finally time to finish RTC and solar sensor.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
The initial release of GBAHawk led to the uncovering of a variety of bugs. Several small bugs were cleaned up straight away. There was however one very serious bug in the cpu emulation that somehow eluded detection until now. This bug made it so that unsigned bytes could sometimes be loaded as signed bytes due to not properly clearing the flag that decides which to do. This occurred partly because I was sloppy in managing the flag, but also partly due to a much more subtle error. I was setting the flag on instruction decode, but clearing it on instruction execution. This is normally fine, but ARM instructions can be executed conditionally. So the flag could be set and then never cleared. Surprisingly this didn't cause chaos everywhere, as I only noticed this by happenstance when looking over the unreleased Another World. It could have been effecting RNG or enemy behaviour in other games which wasn't so far detectable, so I'm glad I stumbled upon this before making too many TASes. Anyway I finally got around to implementing VRAM open bus for BG fetches, resolving another test ROM, leaving only 2 that fail. It seems I should do something similar for OAM accesses, but it is not clear to me how several edge cases should be resolved, so I'll hold off for now. The next immediate thing to do though is work on the RTC so gen 3 pokemon can be played. This will probably also lead to more work on linking. EDIT: also fixed obj window test, and associated demo, so that leaves only world map not working.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
With GBAHawk now being accepted for publication, the improvements to Powerpig and Coin Fall are published and verified. An improvement to my original Feline run is also published and verified. Additionally, 2 other homebrews, Sushi the Cat and Anarchaeologist were able to be verified with the mGBA core in BizHawk. This brings the total number of current GBA console verified runs to 6. It would be 7 but Sonic Advance was improved a few months back and the improvement hasn't been verified yet. It's also worth noting that 5 of these are short homebrews. I had retested both Fire Emblem and Metroid Fusion after the latest round of accuracy improvements. Fire Emblem made it much further than before, but eventually desyncs shortly into level 1. No improvement to Metroid Fusion. It appears both desyncs occur due to one extra lag frame on console compared to emulator. RetroEdit put a lot of work into Shrek 2, revealing that every emulator tested under counts lag. This is not unexpected given the results from Fire Emblem and Metroid Fusion. I expect the resolution to come from improved prefetcher emulation, but currently there are no failing test ROMs that would point out the way to improve things. So still a lot of work to do but progress is being made.