Posts for Alyosha
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3602)
Joined: 11/30/2014
Posts: 2750
Location: US
I was curious about the GB boot rom, so I went to the source by neviksti. I opened the DMG ROM.txt file, but what I saw didn't resemble what the actual rom was supposed to look like, and it wasn't obvious to me how to extract the bits in the right order. So I went back to the original pics of the physical rom and stitched them together. But even then I couldn't figure out easily how the address decoding was supposed to work, and couldn't find any documentation on it. Luckily I found this site: DMG CPU decapped This had a better zoom which allowed me to see some extra structure, particularly here: So, you can see 16 lines going into the red box, which presumably is the address decoder for the actual mask rom (the yellowish blob in the top part of the image.) In the blue area, you can see 8 big doodads which probably hold the data bits. The important part is how they are grouped from lines in the mask rom. Each bit is pulled from 1 of 2 blocks. This is the hint I needed to decode the original text file. What you do is pull one bit from column 0 of block 1,3,5,7... to form a data byte. Then you go down one row and repeat to get the next data byte. Once you reach the bottom, then you go to column 1 of block 1,3,5,7.... Repeat until you are done with all 8 columns of those blocks. then go and do the same for blocks 2,4,6,8.... Anyway it seems straight forward after you look at that picture, but I stared at the raw bits for a couple hours without realizing what the algorithm was supposed to be. I didn't see this documented anywhere, so I guess it couldn't hurt to add a little detail to fill in neviksti's missing steps. It was an interesting exercise.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3602)
Joined: 11/30/2014
Posts: 2750
Location: US
My goodness these ports are horrible. That was a funny glitch shortcut though.
Post subject: Re: Updating the BizHawk Wiki
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3602)
Joined: 11/30/2014
Posts: 2750
Location: US
Fortranm wrote:
Alyosha wrote:
NES accuracy tests: Most of the emulators listed in the table there are irrelevant for TAS (or now even for general use.) I'm thinking of simple removing them and leaving only NESHawk, PuNES, FCEUX, and adding Mesen. Also there are some relatively new tests to add. Any thoughts on this?
I actually like the fact that the list includes ancient emulators so that it's easy to see how much progress has been made through out the years.
I think there's a better way / place for historical stuff, but at any rate you can still find the complete table here. Realistically, Mesen has superseded basically every other emulator anyway. Once it gets TAS tools, the table itself will be more or less pointless.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3602)
Joined: 11/30/2014
Posts: 2750
Location: US
Alright, I went over the obvious stuff and cleaned things up a bit. There will be more to come. A lot of the core pages only have one or 2 lines of info, maybe everything can be combined into one 'Core Information' page?
Post subject: Updating the BizHawk Wiki
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3602)
Joined: 11/30/2014
Posts: 2750
Location: US
I was looking at the BizHawk wiki page and noticed it was quite out of date. I was thinking of taking some time and giving it a bit of an update. A lot of it is just adding new information or removing old and now incorrect information, but there are a few things I would like some feedback on: NES accuracy tests: Most of the emulators listed in the table there are irrelevant for TAS (or now even for general use.) I'm thinking of simple removing them and leaving only NESHawk, PuNES, FCEUX, and adding Mesen. Also there are some relatively new tests to add. Any thoughts on this? TODO page: It's a mess, mostly years old outdated stuff. What should be there now? Is it even needed? Core road map: I guess it's not even really a road map, just a list of ideas. Are there any concrete plans for any of them? Known Desyncs: last updated in 2014, is it still relevant? If anyone has any additional thoughts feel free to chime in.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3602)
Joined: 11/30/2014
Posts: 2750
Location: US
Fixed a few bugs with GBC emulation so Slugfest intro now runs correctly and several more of Wilbert Pol's GBC variant tests pass. This also fixed a minor but very annoying bug in CUTEDEMO fish scene. So overall things are really moving forward quite well for GBHawk.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3602)
Joined: 11/30/2014
Posts: 2750
Location: US
It’s done! I’ve been watching the progress and it’s amazing what you were able to get out of this game. Yes vote!
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3602)
Joined: 11/30/2014
Posts: 2750
Location: US
For some reason I thought the character only swinging the club forward without going back first looked really funny. I also liked hitting the flag pole. Yes vote
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3602)
Joined: 11/30/2014
Posts: 2750
Location: US
Impressive improvement JigWally, especially since the previous 2 authors were AnS and McBobX.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3602)
Joined: 11/30/2014
Posts: 2750
Location: US
This is extremely impressive for a newcomer, nice work Geesk.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3602)
Joined: 11/30/2014
Posts: 2750
Location: US
Subframe input on the piano roll isn’t happening. Subframe input using LUA is potentially not too hard on in house cores. But the resulting input stream would be a non-standard file, and would probably take a convincing test case to be acceptable. I’d be willing to work with someone who was interested in seeing this happen on NESHawk. Honestly though it’s probably only useful for pathological cases like SMB3. For other cases like SMS where you can inject NMIs anywhere you want , the results for games using the pause glitch would be pretty interesting (seeing 10 second intro screens go by in only a frame.) But the core isn’t ready for it, since it does scanline and not cycle level execution . So yeah, if someone was willing to do the scripting work I’d be up for modifying cores to make it possible .
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3602)
Joined: 11/30/2014
Posts: 2750
Location: US
You can now play HuC3 mapper games in GBHawk. RTC is untested and IR functions don't work, but the mapper runs just fine. Probably next will be MM001 or TAMA5.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3602)
Joined: 11/30/2014
Posts: 2750
Location: US
Alright, a bit of exciting news, I finally figured out how to sync movies between Mesen and NESHawk! This took me many hours of frustration only to find that the problem was just a flag that was set differently between Mesen and NESHawk at power on. But now I should be able to do sync testing between them and look for differences in a way that actually makes sense. I already tried with Streemerz and the results are encouraging, perfect sync at similar power on state. And since Streemerz is known to be a ppu timing sensitive game, this brings fresh hope that it should be verifiable on console (once I re-make a run with the Mesen settings.) I also started implementing the new finds with $2006 writes, but so far it has minimal impact (since most games rightly stay away from this case.) But still it's an important accuracy improvement, with more edge cases still to come. Assuming these things sort out existing problems with getting basic runs to sync on console, it will finally be time to look ahead to the dreaded DMC DMA cases and games that use a reset sequence.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3602)
Joined: 11/30/2014
Posts: 2750
Location: US
I'm quite bad at hearing audio issues, but generally speaking GBhawk audio will sound slightly worse then Gambatte (i.e. version 2.2.2) since GBHawk always ends frames on VBL boundaries, which is good for me since it makes logging and debugging stuff easy, but slightly worse for users since the main thing this impacts is audio fidelity.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3602)
Joined: 11/30/2014
Posts: 2750
Location: US
Hey that's some really cool work there Cyorter! NESHawk and Mesen have slightly different startup timing, so any games that require ppu level sync are destined to fail for now. Not even due to accuracy really, the NES is just non-deterministic enough for these things to happen. NESHawk is tuned to a particular run of Battletoads, while Mesen is tuned to the most common case of the read_2004 test ROM I believe. Still that's a pretty good list of ones that work! Hopefully someone can take these and try them out on a console too. Awesome stuff!
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3602)
Joined: 11/30/2014
Posts: 2750
Location: US
GBHawk now passes all of Wilbert Pols sprite timing tests, hurray! These tests combine x-scroll with sprites at various positions. They are pretty grueling. I'm pretty happy to have gotten them working. It means the most complicated part of the rendering pipeline is pretty solid. Now I can move on to some of the subtleties of the GBC and weird stuff that happens with LY. EDIT: Maybe this also fixes whatever is wrong with Mickey's Dangerous Chase.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3602)
Joined: 11/30/2014
Posts: 2750
Location: US
An interesting development has come up in NES emulation recently that might lead to better possibilities for console verification. You can read about the details here: http://forums.nesdev.com/viewtopic.php?f=3&t=18113 Basically, a bus conflict exists when writing to ppuaddr ($2006) which causes incorrect scrolling to happen. The most obvious effect of this is the background glitching out. But, a side effect of this is that it can effect sprite zero hit (since sprite zero hit requires a non-zero background pixel.) Any game that happened to run into this in the past would fail on console since it was completely unemulated. I'm thinking Battletoads warpless probably ran into this at some point, but haven't tested for sure. The results are still coming in but it seems completely consistent and easy to emulate. There is also the possibility that other registers (notably ppuscroll at $2005) might have similar difficulties. This is pretty exciting since console verification (at least from my perspective looking at the emulator side) was basically stuck without any leads, and now things are starting to open back up again. So expect some relatively big commits coming down the line. Overall very few games should be effected, but it may cause desyncs in some cases.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3602)
Joined: 11/30/2014
Posts: 2750
Location: US
HA! Now that is unexpected, nice find!
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3602)
Joined: 11/30/2014
Posts: 2750
Location: US
pacman and bomberman both looked really good!
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3602)
Joined: 11/30/2014
Posts: 2750
Location: US
I’m not seeing how that would work. Any frame can be the first one. The system doesn’t track which cheats are new and need to be applied for the first time.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3602)
Joined: 11/30/2014
Posts: 2750
Location: US
is the glitchy 'world 1 Start' screen due to the pause glitch or is it an emulator bug?
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3602)
Joined: 11/30/2014
Posts: 2750
Location: US
Loading a state where the cheat isn't set yet? Then you'd frame advance without the cheat taking effect. (It's the poke afterwards that shouldn't need to be called.)
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3602)
Joined: 11/30/2014
Posts: 2750
Location: US
This is a weakness of the current implementation of the cheat system. Currently, a cheat doesn't actually freeze an address in writable memory. Instead, it just pokes it at the start of a frame. This address can still change over the course of a frame though. So, in order for things like RAM watch to make sense, you have to reset it to the desired value after the frame as well. And you can't simply make all pokes permanent. You may want a one time poke in hex editor for example. This situation is evident in the core side as well, where pokes generally just end up as one time writes. Theoretically, you can pass a variable along with a poke to tell a core whether its a freeze (cheat) or just a one time poke. In fact, as a proof of concept I just did so on my personal build for NESHawk. Then the value truly is frozen, and there would be no need for a second call. This is a tractable problem for in house cores. But, for anything non-native, it's basically hopeless. Rewriting the desired value is the only way to do it. EDIT: I should also note that the implementation I did for NESHawk is only applicable to the system bus. Fairly substantial restructuring would be required for it to be more generally applicable to other memory domains.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3602)
Joined: 11/30/2014
Posts: 2750
Location: US
About this TAS's ratings: This is the only TAS I can recall that made me feel physically irritated while trying to watch it. Something about how the art style combines with the movement just made it painful for my brain. So I really am not at all surprised if it gets low entertainment ratings, even if technically impressive. Gens and emulators: When I first started TASing I thought emulators were already perfect. I was introduced to the concept of emulators from SMW ACE, so I guess I just assumed the same capability existed for other systems. It was quite shocking to see how bad things actually were. While at first I wasn't much bothered by it, as time went on my opinion hardened on the issue of accuracy, to the point where if something had no chance of working on console, then I basically consider it pointless to even make. Why bother making something wrong? It just seems like wasted effort. I know this is an untenable position from the sites perspective. Honestly though, we really shouldn't be having genesis audio issues now, there are several very high accuracy genesis emulators to learn from. So, I don't see the harm in pointing out why things aren't quite right in the movie description.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3602)
Joined: 11/30/2014
Posts: 2750
Location: US
FractalFusion wrote:
Hello Alyosha. The first half of the run looks nice. Though I'm not sure if this is faster (touching the secret square removes the walls): In the second half, it looks like there are some places to improve (especially using deathwarps). Can input easily be hex-edited into the run? I also appreciate that you ended the run on the good (2P) ending, which I had never seen before until now. There is a 2P RTA at speedrun.com (one of the runners is the_kov) but that run kills off one of the players on the last level in an attempt to save time.
Ha! I didn't even know about that. Yeah I have no doubt that there are numerous improvements throughout the run, I did not research it super thoroughly. I have run out of motivation for it really (I guess I just don't have the motivation to do actual TASing anymore) but I'm happy I got at least a complete WIP. Anyone is free to use this WIP, it is pretty easy to edit, since there is no RNG, but be aware that it is not entirely sync friendly. Data is processed in slightly different ways on different frames as there is a sort of global timer. If you save an inconvenient number of frames in one level, later levels can desync (although in relatively simple to fix ways, it's not fatal) so just be aware of that.