Yeah- it's still gonna be a while. I've spent the past several months researching niche NES behavior, developing my most accurate emulator yet, and writing the script for that video, only to realize that the knowledge from the yet-to-be-made preceding video (mario 3 in 0.216 seconds, explained) is required. Currently putting together 2 videos simultaneously, while still making finishing touches to the emulator I'm developing for the microsecond TAS. Apologies for the wait.

The limitations of the NES are still very much in play. The amount of instructions the NES can process within the vertical blanking period, the graphical limitations from the color palettes, attribute tables and nametables, as well as the speed in which I could write data are all limitations this TAS had to work with. Though the speed in which inputs are sent to the NES is absurd, it's still processed by the NES's CPU. This is far from the only TAS that used tools such as this to provide inputs. Some games have been brute forced, though I wouldn't call those TASes invalid just because the brute forcing was performed by more powerful computers than the one playing back the inputs. "how much of this is honestly the NES handling it?" All of it. 100% of this is the NES interpreting the button presses I provide it.

@@100thCoin I understand that. Ultimately the NES needs to be able to process end results (drawing tiles to screen, making whatever current "noise" the sound chip is capable of at that fraction of point in time). But like, even if we were to ignore how absurdly this goes over the limit of an NES cart's data, what of the memory banks? If bank switching was factored in, would this still be possible? I feel like the drawing of graphics is easy sure. But the way sound is being done is just astronomically blowing away what an NES had access to. From what I know, the amount of data available for the sound channel needed for this was EXTREMELY small. So in order to feed that much unique sound data into it, you would practically be bank switching more than once in a single scanline? I do get it though. Obviously at the end of the day, the NES can produce all this itself. I just feel like skipping over all the data handling, transfer from cart to memory, and the hard limitations on some of those things would impact the potential if they weren't all being skipped over by a super computer (in comparison to the NES) doing all that work and just throwing all of it into the memory itself. I guess what I am saying is, if you could somehow go past what I think was a hard limitation of less than a meg of ROM, and put it on an NES cart, could you make that cart actually do this without any other input?

The faster controller reading was brought to my attention... I forget why I didn't use it. I think it was some limitation of bizhawk? An even faster method was also brought to my attention where you never un-strobe the controller and constantly read a stream of bits through the A button, but that wouldn't work in bizhawk either.

Yeah, that would be possible! I wonder if interlacing with 8 pixel wide stripes looks worse than 1 pixel stripes? In any case, the Bad Apple video is 30FPS so the method I chose seems fitting, though perhaps for something like DOOM TAS I could've tried interlacing. That's a good idea to keep in the back of my mind if I revisit this concept.

A non L+R TAS of this could certainly exist. For this TAS specifically, I only did the series of SMB3 inputs at the start of the video, as optimal SMB1 gameplay isn't my strong suit, and some friends of mine in the SMB speedrunning discord (Seraphmlll and Mizumaririn) did the SMB1 inputs. If I were to make that TAS myself it would likely be suboptimal.

@@100thCoin Ah, ok. I was only wondering because I wanted to see what the best run could be.

This run has been verified on actual hardware: kzbin.info/www/bejne/hXu7qaB6lLaeaNE

I have a video that explains in, but in short- I'm writing PCM data to the audio chip about 25,000 times a second.

yes it does! kzbin.info/www/bejne/hXu7qaB6lLaeaNE

9:38 or that one

It's real. Up for download and works in the latest Bizhawk release at the time of this writing.

I know I'm replying to this a week after you sent it, but there's a TON of documentation for creating NES emulators! Check out www.nesdev.org/wiki/Nesdev_Wiki It's a bit overwhelming at first, but I've had a lot of fun with the emulators I've developed. There are also youtube tutorials you can follow for nes emulation.

more like 𝓯𝓻𝓮𝓪𝓴𝔂 code execution

It's compressed data used while loading the title screen!

in the Bizhawk emulator, under "View" is an option for "Display Input" which shown on screen the buttons being pressed. It's not very intuitive to display inputs like that for a subframe TAS though, as there are hundreds of inputs per frame.

@@100thCoin tysm

I don't really appreciate the "blood on my hands" comment, but I can safely say I'm not planning to stop making videos any time soon. I'm almost done with the research/script-writing of my next video. Not sure how long recording and editing process will be, but I assure you this is on-par with my Bad Apple in SMB explanation video.

@@100thCoin I am glad you're trapped! Thanks. Have a blessed day.

I could be misunderstanding your comment, though everything done here can be done (and has been done) on official hardware. I'm not injecting video and audio files, I'm just pressing buttons on the NES controller.

A rom hack that has a game similar to this would certainly be possible. Keep in mind, this was the prototype of what would become the bad apple TAS. The "game" shown in this TAS is very much not playable, and it's just a music engine that can move sprites around the screen and update the background.

Correct, there's not really a limit to the duration of the clip played.