Posts for Alyosha

Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4544)
Location: US
Joined: 11/30/2014
Posts: 2987
Location: US
Link to video I have the PRG0 game version so I console verified this. Cool run.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4544)
Location: US
Joined: 11/30/2014
Posts: 2987
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.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4544)
Location: US
Joined: 11/30/2014
Posts: 2987
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.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4544)
Location: US
Joined: 11/30/2014
Posts: 2987
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.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4544)
Location: US
Joined: 11/30/2014
Posts: 2987
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.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4544)
Location: US
Joined: 11/30/2014
Posts: 2987
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.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4544)
Location: US
Joined: 11/30/2014
Posts: 2987
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.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4544)
Location: US
Joined: 11/30/2014
Posts: 2987
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.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4544)
Location: US
Joined: 11/30/2014
Posts: 2987
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.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4544)
Location: US
Joined: 11/30/2014
Posts: 2987
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.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4544)
Location: US
Joined: 11/30/2014
Posts: 2987
Location: US
Since clean signals are vital for this project to work, I redid the RGBs lines with RG174 coax. Soldering it was a huge pain but now I have no cross talk noise between the lines. Now I just need to attenuate to 125 mV peak to peak. Looking at the max1003 data sheet, I can use differential AC coupled input mode and the 500 mV peak to peak setting to give myself a little more leeway too (since voltage divisions will now be twice as much.) So I think the digitization has a good plan, now I need to start breadboarding stuff.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4544)
Location: US
Joined: 11/30/2014
Posts: 2987
Location: US
I looked around a bit more and found the MAX1003 which is a 6 bit flash adc. I think this is a better fit than the MC44250FN. The 8 bits of the latter would be tricky to fit with the 5 bits of the SNES video output. With the MAX1003 I can attenuate the video signal to 125 mV from the current ~175 mV and then use the 250 mV peak to peak setting of the chip and simply ignore the top bit. I guess alternatively I can amplify to 250 mV and ignore the lower bit, but I would need to be careful about timing and distortions. Unfortunately cable testing has revealed significant noise on the RGB channels. Max red color for example can cause noise on the blue channel of the same magnitude as 1 bit would be. This noise doesn't exist when I measure from the video connector pin, so I guess that's what I get for getting cheap cables. I'll need to make something higher quality.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4544)
Location: US
Joined: 11/30/2014
Posts: 2987
Location: US
I made a cable that has all the available signals from the SNES output on it connected. I was fortunate that the SNES RGB connector cable I bought had all the pins populated, so I just had to hack it up and solder some wires to it. I terminated the other video signals with an RJ-45 connector. Here is the description of what I have currently: EDIT: Removed no longer used. I also got myself a scope and tested the RGB output channels. I made a basic test program to test maximum output levels. It looks like max of 170 mV for full 5 bits set color, which seems pretty low (I see 660mV online for RGB signals) (EDIT: I had attenuation settings wrong, its actually ~1.5 volts.). For real world testing I captured some waveforms and the results are kind of interesting. Rise times are pretty slow compared to pixel clocking rate. One pixel lasts ~200 ns and rise times can be approximately that long. Obviously this still works as the RGB output channel is used regularly but this something to keep in mind when comparing pixel color emulator. Here is a sample: I still have the option to tap the digital RGB on the ppu, but I would really prefer if I didn't have to touch the console so I will press on with this for now. Now I need a clock source, split the csync signal, and to convert to digital color.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4544)
Location: US
Joined: 11/30/2014
Posts: 2987
Location: US
I am using this thread to keep track of my progress on a project to console verify TASes using console feedback to counter non-determinism. The plan is to use video output to time when to send inputs. Let's use SNES Battletoads as an example. Battletoads turns on automatic input polling before loading music for a level. Therefore the imprecise APU clock can change how long loading takes and thus how many input polls happen before the level starts. This happens on each loading screen, and even with careful tuning I just can't get close enough to get every one right. If we were able to ignore those early automatic polls, and only use the inputs needed to play the level, console playback would be pretty easy, as there isn't any RNG that requires cycle accurate execution. Fortunately, when loading is happening the screen is black, so if we say wait for a certain pixel on screen to be a certain color to trigger sending inputs, we could avoid the unused early automatic polls. The SNES in particular is perfectly suited as a test case for this plan as it sends out multiple video signals by default. I can do video capture with the composite signal and video compare using the RGBs signals. After looking around a bit online I think I can use a MC44250FN to convert RGB analog to digital, maybe with some voltage level shifting since the SNES only outputs 5 bits of color but that chip can handle 8. Various places online say the csync signal can be split into Hsync and Vsync with an LM1881, which should give me all the information I need to count pixels. I just need a programmable counter to latch the correct data. I think I can use an ESP32 to collect all the pixel data and send out the controller polls fast enough. So that's the plan anyway. It if works out maybe the same approach can be used for N64 (which doesn't output RGB but the pins are available on the encoder chip) or even disc based systems. The obvious downside here is that any TAS that requires cycle exact execution between emulator and console to sync will not work. I'll post again when I have the cable made and have good signals. Sidenote: Fiskbit on NesDev told me that the SNES actually has digital RGB outputs available on the ppu. It needs a bit of a mod to access but would save me a conversion step. I want to avoid touching the console if possible but I'll keep this in mind as a backup plan.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4544)
Location: US
Joined: 11/30/2014
Posts: 2987
Location: US
I have console verified this run: Link to video
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4544)
Location: US
Joined: 11/30/2014
Posts: 2987
Location: US
I was actually able to fix both of the above issues without too much trouble. Additionally I fixed a recent accuracy coin test to get to 139/139. I've been going over my list of previously verified movies to make sure I haven't broken anything, as well as checking linking against known working test cases before. So far so good with no regressions.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4544)
Location: US
Joined: 11/30/2014
Posts: 2987
Location: US
Dimon12321 wrote:
Hello, Alyosha! If you want to blow the dust off GBA, here is some new TAS material of Serious Sam Advance. User movie #639126240314619325
works fine, first try no adjustments needed: Link to video
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4544)
Location: US
Joined: 11/30/2014
Posts: 2987
Location: US
Woah revolutionary find, amazing work!
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4544)
Location: US
Joined: 11/30/2014
Posts: 2987
Location: US
Link to video After crafting some multi-tap cables and with some help from TASbot folks I was able to verify Super Metroid GEG (the most recent NTSC run anyway since I don't have any PAL stuff.) Normally I wouldn't bother with obsoleted runs but I was pretty interested in this one and it seemed just on the edge of what careful tuning to console could accomplish. Even with fine tuning APU frequency and start up offset, I estimate the overall likely hood of success to be only ~1/10. I doubt any significantly longer run could work. I also had to swap controller pairs like controllers 1,2 became 3,4 on console, but maybe that's just the state of the I/O pin or something. So it's pretty cool that worked out, and now I have known good multi-tap cables to work with (I also ran the SMW snake / pong one successfully), a pretty productive round of testing.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4544)
Location: US
Joined: 11/30/2014
Posts: 2987
Location: US
I've been reworking my linking code to closer match how hardware works. This results in much more bookkeeping on the core side but much simpler linking logic. Now I match the current mGBA serial tests to my GBP, as well as have code that is much easier to improve when I start to implement the other linking modes. As I was working on this I came across this cool video of a demo that streams video from one GBA to another: Link to video This isn't quite working yet on GBAHawk. I'm not sure if I will try to fix it for this release or save it for the next one. Flevoriux has also recently released a new version of the painful sprite horizontal mosaic test that I currently don't pass. I haven't looked into the details of this one yet, hopefully this doesn't break my increasingly strained pixel pipeline.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4544)
Location: US
Joined: 11/30/2014
Posts: 2987
Location: US
I tested Battletoads a bit more with my console tuned parameters. I'm leaving some notes here about it. I am getting a desync now at the very start of the run, at the first jump the toads make. I tried adding and subtracting polls, and have verified that the initial starting and menuing are happening at the correct time all the way up to loading into the first stage. Small changes in initial parameters do not effect the loading times or other relevant behaviors. Once loading is done and the toads start to warp in, the game uses a counter at RAM 0x41 to determine when to give control to the player. The counter starts at 0 and the player gains control at 0xC0. By adding a poll before the first accepted input, I can get sync to happen at least past level 1. The game actually starts automatically polling before loading is finished however. It turns on autopolling at scanline 0xE5 (229), at horizontal position 0xB0 (176), 16 frames before loading is done. Loading ends at scanline 0x94 (148) with a WAI instruction, so there is plenty of time until the next frame. This initial activation of the auto-polling is currently not recognized as a poll by the emulator. I have to imagine that it is however recognized by the console and this is where my missing poll is. So either loading up to this point is taking too long and the enable is happening too late compared to console, or the enable should be recognized as creating a polling event. EDIT: Audio loading happens directly before polling enable, and changing audio frequency does indeed add in the extra poll I need. So my console is probably slightly faster than 32045, but not quite 32046.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4544)
Location: US
Joined: 11/30/2014
Posts: 2987
Location: US
eien86 wrote:
I - It is the most botted movie of all time, and it will remain so for the longest time hereafter. My botting machine unfortunately broke down, and I decided to downsize it (sell RAM) to recoup the investment. It will take a few years for me to buy something at a larger scale.
What broke? Do you think it was due to the botting?
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4544)
Location: US
Joined: 11/30/2014
Posts: 2987
Location: US
I resynced the last NTSC Super Metroid ACE to bsnes115. It wasn't too hard, depending on apu frequency you have to add a frame at the last elevator before starting the moonfall in order to line up the collision check counter at RAM 5B6, but otherwise nothing needs to be changed. EDIT: movie removed, superceded I currently don't have the right cables to test this so I'm just leaving this here for future notes. Seems like it should work though with enough tries.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4544)
Location: US
Joined: 11/30/2014
Posts: 2987
Location: US
I saw Super Metroid HISHE pop up a while ago and I finally got around to testing it, after a few tries, it surprisingly worked; Link to video This uses my console tuned setting and it took a few tries, but it's encouraging to see something Super Metroid related actually sync.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (4544)
Location: US
Joined: 11/30/2014
Posts: 2987
Location: US
Since Ares has oninputpoll available I tried some poll based dumping. It did a bit better than lag based dumping but ultimately didn't even make it around the first turn in wave race. I'll probably wait for Ares to be updated a bit more before putting much more time in testing. EDIT: Upon further review I realized that I wasn't saving the analog input as the proper two's complement format expected. After fixing this I get better sync, but the wave patterns in wave race are off. I need a simpler test case I think.