TASing on CEN64 when the emulator is finished

Discuss any suggestions you may have here.
Post Reply
User avatar
Patashu
Posts: 14
Joined: Sun Oct 27, 2013 5:49 pm

TASing on CEN64 when the emulator is finished

Post by Patashu » Tue Nov 19, 2013 11:27 pm

I hope that when CEN64 reaches the level of accuracy you are aiming for, you can allow it to be integrated into Bizhawk as one of its emulator cores.

Bizhawk is a multi-emulator platform used over at tasvideos to allow games of many different consoles to be TASed in the same way, with the same tools and LUA scripting functionality. It has for its N64 core atm a build of mupenplus - it's usable, but not ideal, as you want the most desync free, accurate to how the console works core that is available - especially important where things like whether the game is lagging or not effect physics, such as in Donkey Kong 64 where you move faster during lag.

Obviously this suggestion doesn't need to be acted on for a long time. Just make sure that the emulator can save and load savestates in a sync-stable way (e.g. all aspects of state are correctly saved and loaded with the savestate, such that doing the same input from a savestate is deterministic no matter what you did before, as it would be on console) and then everything else can be handled pretty easily on top of that :)

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: TASing on CEN64 when the emulator is finished

Post by MarathonMan » Wed Nov 20, 2013 2:20 am

The save files will be massive (8MB RDRAM image, 16+8KB VR4300 caches, 8KB RSP caches, pipeline latches, register files, etc.).

But, they're all just blobs of data for the most part (aside from the few that might need reconstructing).

So long as you save at a masterclock boundary, which will be supported later, I imagine that TAS tools will be simple to integrate.

User avatar
Patashu
Posts: 14
Joined: Sun Oct 27, 2013 5:49 pm

Re: TASing on CEN64 when the emulator is finished

Post by Patashu » Wed Nov 20, 2013 4:53 am

Good to hear it. Saving/loading savestates and frame advance are basically the only primitives needed.
So long as you save at a masterclock boundary, which will be supported later, I imagine that TAS tools will be simple to integrate.
Hmm, now that you mention it - is sub-frame resetting a meaningful thing? (In some SNES TASes sub-frame resetting is used to interrupt the operation of saving, thus creating a corrupted save that can be used to glitch to the end of the game quickly.) (Sub-frame input in general, too.)

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: TASing on CEN64 when the emulator is finished

Post by MarathonMan » Wed Nov 20, 2013 11:59 am

Patashu wrote:Hmm, now that you mention it - is sub-frame resetting a meaningful thing? (In some SNES TASes sub-frame resetting is used to interrupt the operation of saving, thus creating a corrupted save that can be used to glitch to the end of the game quickly.) (Sub-frame input in general, too.)
Meaningful, in this context, I think is dependent upon the user's opinion. :)

It is meaningful in the sense that, depending on the exact state of the system at any given time, there is a certain state of the input handling hardware. It could be in the middle of a keypress, a couple microseconds away from reading a controller, or microseconds after reading a controller. I have no idea how much accuracy TAS-ers would desire here, but there are certainly discrepancies (however small) between sub-frame saves and saves at frame boundaries.

User avatar
Patashu
Posts: 14
Joined: Sun Oct 27, 2013 5:49 pm

Re: TASing on CEN64 when the emulator is finished

Post by Patashu » Wed Nov 20, 2013 7:43 pm

MarathonMan wrote: It is meaningful in the sense that, depending on the exact state of the system at any given time, there is a certain state of the input handling hardware. It could be in the middle of a keypress, a couple microseconds away from reading a controller, or microseconds after reading a controller. I have no idea how much accuracy TAS-ers would desire here, but there are certainly discrepancies (however small) between sub-frame saves and saves at frame boundaries.
Sub-frame resets are basically only needed for resetting at a very specific point in a save file being written, but can produce cool, very superhuman results (such as the recent Mother 2 TAS, which not only had to do a sub-frame reset to corrupt the save file, but set up the data of the save file perfectly so the corrupted save file PASSES all checksums and can be loaded: http://tasvideos.org/2466M.html )
.
However, 99.5% of TASes will not need sub-frame resets or input. So it is pretty low priority.
Another low-priority-but-opens-up-possibilities-for-a-few-TASes is 'what states can the N64 be in when powered on for the first time?' e.g. uninitialized RAM, anything that can be in a variety of states besides just 0. (There's currently a debate on tasvideos as to whether TASes should be allowed to control the state of RAM on power on or leave it at the emulator's default pattern. It could be used to control RNG that is influenced by uninitialized RAM, for example.)

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: TASing on CEN64 when the emulator is finished

Post by MarathonMan » Wed Nov 20, 2013 8:43 pm

Patashu wrote:Another low-priority-but-opens-up-possibilities-for-a-few-TASes is 'what states can the N64 be in when powered on for the first time?' e.g. uninitialized RAM, anything that can be in a variety of states besides just 0. (There's currently a debate on tasvideos as to whether TASes should be allowed to control the state of RAM on power on or leave it at the emulator's default pattern. It could be used to control RNG that is influenced by uninitialized RAM, for example.)
Everything is zeroed out at the moment, but mostly everything is just an giant array that you could fill with random values.

User avatar
Patashu
Posts: 14
Joined: Sun Oct 27, 2013 5:49 pm

Re: TASing on CEN64 when the emulator is finished

Post by Patashu » Thu Nov 21, 2013 5:45 pm

MarathonMan wrote:
Patashu wrote:Another low-priority-but-opens-up-possibilities-for-a-few-TASes is 'what states can the N64 be in when powered on for the first time?' e.g. uninitialized RAM, anything that can be in a variety of states besides just 0. (There's currently a debate on tasvideos as to whether TASes should be allowed to control the state of RAM on power on or leave it at the emulator's default pattern. It could be used to control RNG that is influenced by uninitialized RAM, for example.)
Everything is zeroed out at the moment, but mostly everything is just an giant array that you could fill with random values.
And is this physically accurate? (e.g. some NES games completely fail to run if the RAM is initialized to entirely 0s, which is why emulators tend to use patterns like 0000FFFF0000FFFF... for initialization, just so every game except for rare pirate games work)

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: TASing on CEN64 when the emulator is finished

Post by MarathonMan » Thu Nov 21, 2013 8:33 pm

Patashu wrote:And is this physically accurate? (e.g. some NES games completely fail to run if the RAM is initialized to entirely 0s, which is why emulators tend to use patterns like 0000FFFF0000FFFF... for initialization, just so every game except for rare pirate games work)
Nope, its not at all accurate at all to zero it out.

There's a ton of work to be done before I can safely start saying CEN64 is on par with the hardware. At the moment, I'm not ever sure it warrants the title of "the most accurate N64 emulator", to be quite honest. I'm chugging away as fast as I can between my job... it'll get there eventually. :D

User avatar
Patashu
Posts: 14
Joined: Sun Oct 27, 2013 5:49 pm

Re: TASing on CEN64 when the emulator is finished

Post by Patashu » Sun Nov 24, 2013 5:46 pm

Good luck :)

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest