Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(4626)
Location: US
Joined: 11/30/2014
Posts: 3002
Location: US
Wow pretty crazy this happened already, this pace of AI advancement is stunning. I guess if it can solve hard math problems and decompile complex software it's not surprising it can do something objective like shorten a TAS time. Still I thought we had more time before it came for us!
Rules and such aside, I am curious, did you find the process of using the AI to create this enjoyable? Was it just a test of capabilities or do you think you would continue to use AI to make TASes of other games you are interested in?
If we still want to maintain TAS time record keeping, I don't think we can simply ignore stuff like this.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(4626)
Location: US
Joined: 11/30/2014
Posts: 3002
Location: US
Link to video
Since I explicitly don't support a front end cheat code utility, I thought it would be fun to implement Game Genie support as a physical add on to my new NES core. Here is a console verification of a Super Mario Bros. TAS by PP Unknown using the "AISSON" code (I added in the necessary game genie inputs.)
Generally not that useful, and I don't want to use the Game Genie too much as it's PCB is too thick for the NES cartridge connector, but I think it's an interesting enough curiousity to keep it.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(4626)
Location: US
Joined: 11/30/2014
Posts: 3002
Location: US
I implemented the GBA video mapper today, which aside from the e-reader is the largest group of 'games' that currently weren't supported in GBAHawk. You can even watch 2 movies side by side in linked mode if you really want to.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(4626)
Location: US
Joined: 11/30/2014
Posts: 3002
Location: US
Link to video
After implementing a previously known but not emulated MMC3 glitch, I finally have a run of Astyanax that syncs on console. This game runs RNG in the wait loop, so requires cycle accuracy to sync. The MMC3 glitch causes an IRQ to be missed under certain conditions. This shows up in this game as a corrupted status bar for a frame, but this somehow escaped my notice previously otherwise I might have figured it out sooner.
This is also a pretty significant improvement to the previous run, so if I ever get the core in a release ready state I will submit the improvement.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(4626)
Location: US
Joined: 11/30/2014
Posts: 3002
Location: US
Link to video
I dumped the Star Tropics TAS from the new core and it worked on console just fine. This was one of the last runs I remember from the old console verification topic that seemed like it should work but didn't previously, so nice to have this done.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(4626)
Location: US
Joined: 11/30/2014
Posts: 3002
Location: US
I retested metroid low% TAS on my new NES core, and the per poll worked worked just fine. Previously I had to dump per frame, I guess it's a result of uninitialized memory as the previous cases. So that clears up that mystery, but my previous explanation was that the weird polling the game does makes the bot occasionally miss a poll. Now that I know this not to be true, it means Astyanax, which polls in the same way, is not desyncing from this either. I made a new run in the new NES core, but it still desyncs on console, despite all the accuracy improvements.
I don't know what the issue is here, presumably something MMC3 related. I tried other MMC3 timing sensitive runs like Tiny Toons but it plays back and dumps the exact same. the desync occurs early in level 1, so there is at least some hope of narrowing it down. If I can figure this out and add in some more mappers I think I can declare the core release ready.
EDIT: I suspect this might be a known MMC3 clocking glitch that I hadn't previously emulated.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(4626)
Location: US
Joined: 11/30/2014
Posts: 3002
Location: US
Link to video
I finally got around to making a mmc2 pcb and was able to verify a run (Phred's Cool Punch-Out 2 turbo) dumped using my new NESHawk2 core. I'll work on verifying the other Punch Out ROM hacks as well.
I hadn't previously used mmc2 for any core testing, so this is another good test point. I'm still a good ways away from having something that is release ready, but it's moving along.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(4626)
Location: US
Joined: 11/30/2014
Posts: 3002
Location: US
Couple more tests:
Pitfall: easy to resync but can't get past the menu on console, not sure what is going on.
F-Zero (Knight): easy to resync, but is sensitive to audio clock similar to battletoads. First couple of levels sync on console but desyncs after. Good adaptive sync candidate.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(4626)
Location: US
Joined: 11/30/2014
Posts: 3002
Location: US
The movie tags that are 2 words or more all appear to have broken links when selected from 'Movies by genre' tab of the 'movies' page. 'Unreleased games', 'unlicesnsed game', 'unofficial port', 'custom level set'. It looks like the hyper link is dropping the space, even though it is there in the page code.
Additionally 'oldest movie by platform' doesn't work even though the link is only one word.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(4626)
Location: US
Joined: 11/30/2014
Posts: 3002
Location: US
For some added context about emulators, over at NESDev we are seeing new emulators, some even with TAS / movie support (although these features are often broken) that are mostly / entirely vibe coded. Here is a current example:
https://forums.nesdev.org/viewtopic.php?t=26756
The extent to which the AI simply copies (and obfuscates that it is doing so) existing emulator implementations like TriCNES, Mesen, Ares, etc. is up for debate. The one I linked seems to have taken a lot from TriCNES. None the less it could reasonably be used to produce TAS movies.
So, would using such an emulator be acceptable for submissions? Do we care about the provenance of AI generated code? Under the current proposal it is my interpretation that this emulator would be approved.
I'm working on a SNES core as part of my adaptive sync project. I've reached the point where I can start running code and trace logging, above are the first few instructions of SMW. There are many many bugs in the CPU to work out still but I'm pretty happy with how it turned out architecturally. Of course the CPU is the easy part of SNES emulation. I'm hoping to have this core up and running in ~1 year.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(4626)
Location: US
Joined: 11/30/2014
Posts: 3002
Location: US
I think the proposed policy is mostly good, but I think it is missing some details with regards to attribution. I remember a couple years back seeing discussions of the first AI videos and a common phrase I saw was 'get ready because this will only get better, faster.' If you compare AI videos now to back then that has certainly turned out to be true. The same was true in math and programming, with major advancements in math happening just last week with basically just a few AI prompts. my point is that eventually, probably faster than we think, someone will submit a TAS with a submission text like 'I fed this to Claude and it found an improvement in this run, I basically did nothing lol.' How will authorship be attributed in this case? Will people be able to add 'Claude' as coauthor or will it be treated similar to ordinary botting despite the submitter doing next to no work?
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(4626)
Location: US
Joined: 11/30/2014
Posts: 3002
Location: US
GBAHawk v3.0.0 is now released!
This version has numerous core / accuracy improvements including:
- Open bus accuracy improvements
- RTC accuracy improvements
- Linking accuracy improvements
- Emulates FIFO DMA lock up
- Emulates coprocessor 14 instructions returning open bus
- Adds user created DB entries
- Adds 5 level light sensor controls
- rewritten ARM7TDMI execution loop
Additionally I have rewritten the GB core into C++ a core with plans to renew work on it when I get the chance.
This release also includes my NESHawk2 core as experimental. Note that currently it ONLY loads NES2.0 headered ROMs and WILL respect whatever is in the ROM header. Additionally it only supports NTSC NES currently, not PAL or Famicom behaviors. It is currently 140/141 AccuracyCoin tests passing as well as all the other relevant accuracy tests.
There have also been many code changes throughout the project as I continue to try and shrink and simplify the code base.
Finally thanks to Github contributor coolbho3k for some bug fixes.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(4626)
Location: US
Joined: 11/30/2014
Posts: 3002
Location: US
I finally managed to figure out why the Snood TAS I was puzzled by crashes on console. On this frame, the same frame that crashes on console, the game turns off DMA 2 after a audio FIFO reload is triggered but before it starts (there is a few cycles in between the two events.) I'm not entirely sure of the details yet, but this evidently triggers a crash. Presumably this is what GBA Tek refers to as: "DMA lockup when stopping while starting ???"
I'm not entirely sure yet how I will handle this in emulator, the behavior observed on console seems very complicated. I'll probably just trigger a jam state for now.
I'll put together a test to demonstrate the crash.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(4626)
Location: US
Joined: 11/30/2014
Posts: 3002
Location: US
I tried a couple additional games, here are the results:
Super Star Wars: RNG is very sensitive to audio frequency, doesn't seem doable.
Aladdin: Resyncable but lag is very dependent on audio frequency. The game uses auto polling so if the lag is in the wrong spot it will break, which will happen very quickly in the first level. A good candidate for my adaptive bot in the future.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(4626)
Location: US
Joined: 11/30/2014
Posts: 3002
Location: US
I successfully managed to setup an lm1981 on a bread board and extract hsync and ysnc signals from the SNES. This is a very basic operation but was good practice for my first attempt at bread boarding stuff.
Obviously I can use hsync and vsync to count scanlines, which is half the information I need. Now I need a clock source for generating ppu clocks, which are not available from the display port. If I sync the clocks (and clock generation) using hsync, Then sending this to the ADC I should be able to get pixel level resolution.
It's slow going but so far so good.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(4626)
Location: US
Joined: 11/30/2014
Posts: 3002
Location: US
My goal for GBAHawk is for everything to run at minimum 2x speed on my computer. My test case for this is the main menu of Advance Wars 2, which has several layers active, lots of sprites, DMA's happening, and doesn't use halt so code is running the whole time. Even on 2.3.2 this scene ran under 2x, averaging around 112., and the situation has gotten quite bad in master at around 105. So I took some time to address this by optimizing the CPU code. It turns out a lot of savings could be had.
Originally, I split CPU execution into 3 main code blocks, decode, execute, and cycle type specifics (i.e. reading from memory, branching, etc). Over time the code has evolved so that the separation between decode and execute was pretty artificial. This was due mostly to handling halt and DMA in a different way. So I decided to merge them together into a single step and clean up the whole thing. This actually resulted in a sizable performance improvement. The Advance Wars 2 main menu now runs closer to 115 fps, with still some room for improvements. I'm going to try to get to 120 for next release.
This is still very slow. Mesen has comparable accuracy and runs the same scene at ~370 fps on my computer. This is just the limits of my architecture though, and 120 is probably about as fast as I'm ever going to get.
These changes also make the edge case msr encodings much easier to deal with, which is a nice added benefit. I will probably deal with those after this next release.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(4626)
Location: US
Joined: 11/30/2014
Posts: 3002
Location: US
I redid the open bus emulation in GBAHawk and it now passes the openbuster test and my own new tests. This was a pretty big refactor and cost a bit of performance, but is now very transparent when and how the bus is being updated. This also cleaned up the DMA code a bit, which is necessary for when I have to separate reads and writes for edge cases when DMA is disabled in between them.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(4626)
Location: US
Joined: 11/30/2014
Posts: 3002
Location: US
It turns out I made the most basic of basic mistakes and didn't have my probe attenuation matching my scope setting, so the actual RGB voltage peak to peak is ~1.5 volts not ~0.15 volts, oops!
So now instead of attenuating to ~75% and being able to use differential input I have to attenuate to only ~33% to fit in the 500 mV peak to peak limit of the MAX1003, disaster! I tested this using basic potentiometers to divide the voltage down and got the above picture. The voltage signal is still technically DC so nothing weird happens, but the potentiometers must have some small internal capacitance because the voltage drop takes longer than for the original signal. I think this is still in time for pixel to pixel transitions, but it's pretty close.
Aside from that the signals are still pretty clean after attenuating so I will continue with my original plan.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(4626)
Location: US
Joined: 11/30/2014
Posts: 3002
Location: US
After reading the data sheet a bit more carefully, I noticed that the AD9984A requires minimum 0.5V peak to peak for operation. So to use this I would need to fairly carefully amplify each color signal. I would also need some SMD soldering tools to use it which I currently don't have. So in the interest of simplicity I settled on the MAX1003 and got a couple of those along with some LMH1981's for sync separation.
With the MAX1003 it's on me to set up clock and timing information, but once I manage that the operation is very simple. My biggest concern is drift between my clock and the SNES clock, but i think I can sync to hsync and that should be good enough for a single scanline. Another downside is that I need two of them for the 3 channels, but as long as sample timing doesn't vary too much between the two that should be fine.
Probably the AD9984A is the best choice for someone who actually knows what they're doing, maybe if I learn enough from this process I can take another look at it. I'm happy with my current choice though, getting it working seems doable. I'll report back with some pictures as i test stuff and get things going.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(4626)
Location: US
Joined: 11/30/2014
Posts: 3002
Location: US
Another digitization option is the AD9984A, which is a 10 bit ADC that can do all 3 RGB channels at once. This chip is a bit more complicated than the others in that it needs some programming to set up, but that wouldn't be too hard since I'll have an ESP32 running alongside it anyway. This also means I wouldn't be able to evaluate things until I have basically the whole system set up, which is a pretty big down side for a beginner like me.
This chip only needs the hsync and vsync signals as inputs, which I will be generating anyway, and conveniently outputs a data clock along with the ADC conversion. Using this would save me the significant trouble of creating a clock source on my own. It also has programmable sampling time, so I can target towards the end of each pixel when the color intensity is actually reached. Pretty cool.
Analog Devices has other ADCs and video decoders of various kinds, I just need to make a decision and go with it.
I finally managed to figure out why the Snood TAS I was puzzled by crashes on console. On this frame, the same frame that crashes on console, the game turns off DMA 2 after a audio FIFO reload is triggered but before it starts (there is a few cycles in between the two events.) I'm not entirely sure of the details yet, but this evidently triggers a crash. Presumably this is what GBA Tek refers to as: "DMA lockup when stopping while starting ???"
I'm not entirely sure yet how I will handle this in emulator, the behavior observed on console seems very complicated. I'll probably just trigger a jam state for now.
I'll put together a test to demonstrate the crash.
I successfully managed to setup an lm1981 on a bread board and extract hsync and ysnc signals from the SNES. This is a very basic operation but was good practice for my first attempt at bread boarding stuff.
Obviously I can use hsync and vsync to count scanlines, which is half the information I need. Now I need a clock source for generating ppu clocks, which are not available from the display port. If I sync the clocks (and clock generation) using hsync, Then sending this to the ADC I should be able to get pixel level resolution.
It's slow going but so far so good.
It turns out I made the most basic of basic mistakes and didn't have my probe attenuation matching my scope setting, so the actual RGB voltage peak to peak is ~1.5 volts not ~0.15 volts, oops!
So now instead of attenuating to ~75% and being able to use differential input I have to attenuate to only ~33% to fit in the 500 mV peak to peak limit of the MAX1003, disaster! I tested this using basic potentiometers to divide the voltage down and got the above picture. The voltage signal is still technically DC so nothing weird happens, but the potentiometers must have some small internal capacitance because the voltage drop takes longer than for the original signal. I think this is still in time for pixel to pixel transitions, but it's pretty close.
Aside from that the signals are still pretty clean after attenuating so I will continue with my original plan.