5 ms·

Super cool. Is it mentioned anywhere how big the payload is? How many button presses? Are the audio samples "streamed" or does it all fit in NES RAM?

by baobun 1y ago

larsiusprime 1y ago
There’s a full write up. Audio is streamed as button presses.
gregdeon 1y ago
The entire TAS file takes about 16 MB, far more than the 4 KB of RAM on the NES. During the audio + video playback, the TAS is streaming via the controller by making inputs roughly 500 times per frame (15 kHz).
- ninjin 1y ago
  Indeed, if you want to see what is possible with only a Famicom (or NES) itself you can have a look at Little Limit's incredible Bad Apple "port" [1]. This recording is from an emulator [2], but I know from personal experience that it plays perfectly fine on my "New Famicom" (HVC-101). This is not to detract from how amazing the posted ACE is, but it is indeed different in terms of data limitations. [1]: https://littlelimit.net/bad_apple_2_5.htm https://littlelimit.net/bad_apple_2_5.htm [2]: https://www.youtube.com/watch?v=eNU1lzr_m4Q https://www.youtube.com/watch?v=eNU1lzr_m4Q
  - lll-o-lll 1y ago
    Interesting. The visuals, presumably somewhat hand crafted, look infinitely better in this rendition. The sound is much less compelling, however.
  - korhojoa 1y ago
    I like this version. https://youtu.be/WPUYjDNks9Y https://youtu.be/WPUYjDNks9Y It's impressive what can be done if a lot of effort is put in.
    - ninjin 1y ago
      It really is impressive, but it is also fair to point out that it uses the MXM-1 mapper which only came into existence in 2022 [1]. I find it pointless to argue whether it is "cheating" or not as the technology it uses was used for other consoles at the time and it is fun to see new mappers like this, but it is, again, very different compared to keeping it within the realm of original Famicom/NES mappers and limits. [1]: https://somethingnerdy.com/unlocking-the-nes-for-former-dawn https://somethingnerdy.com/unlocking-the-nes-for-former-dawn
  - LocalH 1y ago
    The submitted run here is also technically "only a Famicom (or NES)". The only difference is the rate of input from the controller to feed the data. Outside of the need to start in N-1 (which can be done on hardware with unmodified games by booting up SMB3 and then hotswapping to SMB1), if you feed these same controller inputs, frame by frame, to a real NES with no modifications, using an unmodified retail copy of SMB1 (and SMB3), this will work. The only "modification" is wholly external to the system, and is necessary to feed the controller inputs at a superhuman rate. The SMB1 (and SMB3) code is the exact same code Nintendo shipped on mask ROMs, and the Famicom (or NES) is also completely unmodified.
    - ninjin 1y ago
      This is art, so arguing about exact boundaries is pointless in my book. But can we at least agree that there is rather a big difference between "This is something that plays from a standard cartridge with a standard mapper on the Famicom/NES you have from your childhood" and "This is something that plays from a standard cartridge with a standard mapper on the Famicom/NES you have from your childhood with a modified superhuman-speed controller to in real time feed 16 times the amount of data of the largest cartridge ever released for the system"?
100th_Coin 1y ago
Hey, I'm the TASer who put this run together. This was 5.8 million inputs. I share the full assembly code in the tasvideos writeup: https://tasvideos.org/8991S#HereSTheAsmCode https://tasvideos.org/8991S#HereSTheAsmCode To summarize what I put in the writeup, the 7-bit PCM audio was streamed in at approximately 25 Khz, (reading from the controller and writing to address $4011 every 71 CPU cycles.) while occasionally dipping to 9 Khz while streaming in the graphics data.
- voidUpdate 1y ago
  yooo, its funny cartridge swap guy!
- temperceve 1y ago
  I'd love a laymane overview of what you've done here
  - GrantMoyer 1y ago
    I'm not the author, but these video-in-game projects typically work with a few phases: 1. Get the game into a specific state by performing specific actions, moving to specific positions, performing specific inputs, etc. so that a portion of the game state in RAM happens to be an executable program. 2. Jump to that executable code such as by corrupting the return address in the stack with a buffer overflow 3. (optional) The program from 1 may be a simple "bootstrap" program which lets the player directly write a new, larger program using controller inputs then jumps to the new program. 4. The program reads the video and audio from the stream of controller inputs, decodes them, and displays them. The encoding is usually an ad-hoc scheme designed to take advantage of the available hardware. The stream of replayed inputs is computed directly from the media files.
    - LocalH 1y ago
      Specifically, this TAS abuses the fact that SMB doesn't clear RAM on bootup to use SMB3 to write $16 to the "continue world" RAM location, and then hotswaps to SMB1 to start the game in World N-1 which makes the rest of the TAS possible. If you download the TAS and use it with SMB1 on an emulator, the included base savestate will already have $16 in that RAM location, for convenience. The main HN link for this submission has the full technical writeup.

Super cool. Is it mentioned anywhere how big the payload is? How many button presses? Are the audio samples "streamed" or does it all fit in NES RAM?

by baobun 1y ago

Super cool. Is it mentioned anywhere how big the payload is? How many button presses? Are the audio samples "streamed" or does it all fit in NES RAM?

larsiusprime 1y ago

There’s a full write up. Audio is streamed as button presses.

gregdeon 1y ago

The entire TAS file takes about 16 MB, far more than the 4 KB of RAM on the NES. During the audio + video playback, the TAS is streaming via the controller by making inputs roughly 500 times per frame (15 kHz).

ninjin 1y ago
Indeed, if you want to see what is possible with only a Famicom (or NES) itself you can have a look at Little Limit's incredible Bad Apple "port" [1]. This recording is from an emulator [2], but I know from personal experience that it plays perfectly fine on my "New Famicom" (HVC-101). This is not to detract from how amazing the posted ACE is, but it is indeed different in terms of data limitations. [1]: https://littlelimit.net/bad_apple_2_5.htm https://littlelimit.net/bad_apple_2_5.htm [2]: https://www.youtube.com/watch?v=eNU1lzr_m4Q https://www.youtube.com/watch?v=eNU1lzr_m4Q
- lll-o-lll 1y ago
  Interesting. The visuals, presumably somewhat hand crafted, look infinitely better in this rendition. The sound is much less compelling, however.
- korhojoa 1y ago
  I like this version. https://youtu.be/WPUYjDNks9Y https://youtu.be/WPUYjDNks9Y It's impressive what can be done if a lot of effort is put in.
  - ninjin 1y ago
    It really is impressive, but it is also fair to point out that it uses the MXM-1 mapper which only came into existence in 2022 [1]. I find it pointless to argue whether it is "cheating" or not as the technology it uses was used for other consoles at the time and it is fun to see new mappers like this, but it is, again, very different compared to keeping it within the realm of original Famicom/NES mappers and limits. [1]: https://somethingnerdy.com/unlocking-the-nes-for-former-dawn https://somethingnerdy.com/unlocking-the-nes-for-former-dawn
- LocalH 1y ago
  The submitted run here is also technically "only a Famicom (or NES)". The only difference is the rate of input from the controller to feed the data. Outside of the need to start in N-1 (which can be done on hardware with unmodified games by booting up SMB3 and then hotswapping to SMB1), if you feed these same controller inputs, frame by frame, to a real NES with no modifications, using an unmodified retail copy of SMB1 (and SMB3), this will work. The only "modification" is wholly external to the system, and is necessary to feed the controller inputs at a superhuman rate. The SMB1 (and SMB3) code is the exact same code Nintendo shipped on mask ROMs, and the Famicom (or NES) is also completely unmodified.
  - ninjin 1y ago
    This is art, so arguing about exact boundaries is pointless in my book. But can we at least agree that there is rather a big difference between "This is something that plays from a standard cartridge with a standard mapper on the Famicom/NES you have from your childhood" and "This is something that plays from a standard cartridge with a standard mapper on the Famicom/NES you have from your childhood with a modified superhuman-speed controller to in real time feed 16 times the amount of data of the largest cartridge ever released for the system"?

100th_Coin 1y ago

Hey, I'm the TASer who put this run together. This was 5.8 million inputs. I share the full assembly code in the tasvideos writeup: https://tasvideos.org/8991S#HereSTheAsmCode https://tasvideos.org/8991S#HereSTheAsmCode To summarize what I put in the writeup, the 7-bit PCM audio was streamed in at approximately 25 Khz, (reading from the controller and writing to address $4011 every 71 CPU cycles.) while occasionally dipping to 9 Khz while streaming in the graphics data.

voidUpdate 1y ago
yooo, its funny cartridge swap guy!
temperceve 1y ago
I'd love a laymane overview of what you've done here
- GrantMoyer 1y ago
  I'm not the author, but these video-in-game projects typically work with a few phases: 1. Get the game into a specific state by performing specific actions, moving to specific positions, performing specific inputs, etc. so that a portion of the game state in RAM happens to be an executable program. 2. Jump to that executable code such as by corrupting the return address in the stack with a buffer overflow 3. (optional) The program from 1 may be a simple "bootstrap" program which lets the player directly write a new, larger program using controller inputs then jumps to the new program. 4. The program reads the video and audio from the stream of controller inputs, decodes them, and displays them. The encoding is usually an ad-hoc scheme designed to take advantage of the available hardware. The stream of replayed inputs is computed directly from the media files.
  - LocalH 1y ago
    Specifically, this TAS abuses the fact that SMB doesn't clear RAM on bootup to use SMB3 to write $16 to the "continue world" RAM location, and then hotswaps to SMB1 to start the game in World N-1 which makes the rest of the TAS possible. If you download the TAS and use it with SMB1 on an emulator, the included base savestate will already have $16 in that RAM location, for convenience. The main HN link for this submission has the full technical writeup.