Posts for Bigbass


1 2
6 7
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
linja wrote:
what is it about Lua that makes it the only contender in this space?
linja wrote:
outside of popularity (which doesn't immediately translate to UX here)
Popularity most certainly does affect the user experience. The more popular, the more resources there are, and more people to offer help when someone has questions. Additionally, Lua's popularity also means that a user who has used Lua scripting one place, doesn't need to learn a brand new language just to write a script in another place. Lua is also a highly extendable language without being overly complicated. All classes/objects are just tables in disguise.
linja wrote:
Lua has thousands of tiny quirks
I don't know about thousands, but yeah it's got quirks, however, so does every other language too. That doesn't mean the language isn't worth using. Many of Lua's quirks are those that typical uses likely won't encounter anyways.
linja wrote:
where does a language like Janet or Wren fall short
Besides the fact I've never heard of such languages before (and I suspect the same goes for many people), Janet definitely doesn't look simple or beginner friendly at all. There's a lot of superfluous syntax which gives off a strong esoteric vibe. Plus, there seems to be only one implementation, and its Github repo admits there is no language spec. This means that the number of emulators that can readily use it, is somewhat limited. Some languages may be able to produce C bindings and use it that way, but not all. Also not seeing any clear way of extending the provided functions, may not even be possible. In which case, it is completely useless for the emulator use-case (which requires being able to add custom functions that hook into the rest of the program.) Wren's syntax is better, but compared to Lua it's also more complex (more keywords and concepts the user must understand). It appears to include some kind of foreign module loading, but it's not super clear to me what's possible. It also has much better docs than Janet, but again no language spec as far as I can see. Otherwise it suffers many of the same problems as Janet. Lua on the other hand, has much better and more comprehensive docs. It has been reimplemented probably hundreds of times, across many different languages. It's relatively easy to extend. (Programs can provide custom APIs, with or without using imports.)
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
I concur with EZGames69 and DrD2k9. To me, April Fools is seen here as a time to submit all the wacky and bizarre ideas people have come up with since the previous year, even if only to make a joke. It's the act of submitting the TAS for people to enjoy, among all the other silly submissions, that I think people enjoy the most. If it happens to get published, great, if not, no big deal.
htwh wrote:
[...] publishing the best (and nothing but) gag runs on 4/1
Rules regarding what does or doesn't get published are the same regardless what day it is. Just because it's April Fools Day doesn't mean we should only publish "the best gag runs". Just because a movie is funny, doesn't mean it should be published. Generally speaking, most April Fools Day submissions do not end up being published, and that's completely expected by TASers.
htwh wrote:
Everyone else who just appreciates the runs, and would appreciate a good joke too, misses out.
I don't believe that's true. People can and do still enjoy the jokes even if they are not regulars in the community. Anyone is free to lurk in the Discord server, or to check in on new submissions on the site (especially on a specific day of the year). If you choose to only focus on the YouTube channel, then of course you're only going to see the content that gets published there. The whole point of these submissions is to try whatever strange, abnormal, or random ideas you can come up with. The goal is not publication.
Most importantly though, I fear this idea would put far too much pressure on judges and publishers leading up to April 1st. It's just not practical to try coordinating everything in advance. Especially considering that sometimes these TASes are created within days of April 1st. The judging process can take awhile, depending on many factors, including how much time the judge has to allocate to the site and the complexity of the TAS. Even if a TAS is explicitly made as a joke, it still deserves just as much consideration as any other TAS.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
warmCabin wrote:
Do you happen to have a VOD of your console sync attempts? Not that I have any remote ability to help, I just wanna see.
Here's several tests I had done for 100thCoin, one of which was the longest I was able to achieve. (I had also performed numerous other attempts besides these.) Note that these attempts were performed with a custom test ROM. Link to video As part of my testing, I had use my logic analyzer to monitor the controller signals for each replay attempt. As far as I could tell, each attempt seemed to replay the inputs perfectly, despite the replay apparently failing at random.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
DJ_Incendration wrote:
dwangoAC wrote:
SmashManiac wrote:
The run cannot be reproduced by an independent 3rd party because some of the data needed to do so has never been released publicly due to copyright concerns.
As was the case with SMB on SMW, site rules dictate we cannot link to ROMs and as such we also can't release the full payload for the same reason, we'd be in violation of the site's rules if we did. Instead, we've released the open source portions, and those have been independently verified.
If you can't link to roms, and a payload in itself is not a rom, it doesn't make sense that the full payload can't be released. Same for this submission.
The payload is indeed not strictly a rom, but it does contain copyright protected materials. As such, it still falls under the same rule.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
dwangoAC wrote:
EZGames69 wrote:
For what it’s worth, the current all levels publication says it’s console verified, but I’m unsure how it handles the resets and if it has different rng each time.
Just like this:
python3 tastm32.py --hardreset --blank 2 --console nes --players 1,5 --transition 675 S --transition 1614 S --transition 2910 S --transition 4067 S --transition 5153 S --transition 6318 S --transition 7279 S --transition 8247 S --transition 9118 S --transition 9995 S --transition 10832 S --transition 11676 S --transition 12528 S --transition 13385 S --transition 14247 S --transition 15170 S --transition 16133 S --transition 17313 S --transition 18515 S --transition 19573 S --dpcm drmario-resets-2b.r08
Just to provide some context in case this is unfamiliar to anyone: What dwangoAC posted above is the command used to tell the TAStm32 replay device what inputs to replay (drmario-resets-2b.r08), and on which input "frames" a reset should occur (--transition X). As long as the replay starts from power on (for Dr Mario), the moments the resets must occur at are consistent between attempts. Actually, that's how resets are always handled on the NES; they are initiated at predetermined frame or latch counts relative to the beginning of the replay.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
PLANET wrote:
Also from perspective, a few years ago it was not ok to be even somewhat slightly harsh to a person here, now - not even the product of this person. What's next? Feels like a poison of (political) correctness spreading further and further...
You were warned a few years ago for blatantly insulting a TAS author, and after being called out, you insulted the author again. Now today, whether intentionally or not, you've conveyed disregard to another author and their work. You've made no attempt to apologize for this, quite the opposite actually.
PLANET wrote:
Being straight to the point when it comes to the run is exactly what it is, a criticism, even if not always the most constructive.
There are many more considerate and respectful ways to convey that a TAS needs improvement. Your repeated disregard for other people and their work on this site, will not be tolerated here. You are now banned indefinitely.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
PLANET wrote:
fsvgm777 wrote:
PLANET wrote:
Waste of time.
Calling this submission a "waste of time" is very unhelpful and at worst, may actively discourage the TASer from actually learning from their mistakes. In fact, darkman425 and KusogeMan already provided some pointers on where they could improve.
"Waste (loss) of time within the run" : > Some advice was left on YT video actually, where author actually responds.
That's not what you said though, and is just as unhelpful as before. If you felt there were areas that could be improved, then state that constructively rather than disregarding the submission as a "waste of time". Even if that's not what you meant, your words can still have consequences, and as such care should be taken when providing feedback.
PLANET wrote:
Some advice was left on YT video actually, where author actually responds.
This is no excuse for being rude here on the forums.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
While debatable, I don't think there's any version of Linux that is strictly "intuitive for a long time Windows user", though it can vary greatly on your experience and understanding of computers. That said, getting into Linux isn't incredibly difficult either. Can't speak to the other emulators you named, but BizHawk has actually worked on Linux for awhile. It's just that Lua wasn't supported until recently, and even before that, you could run it in a Windows VM (as annoying as that was). Generally speaking, anything that only releases on Windows, will probably still function on Linux via wine. There are a plethora of Linux distros available. You could spend a lifetime exploring them all hehe. First though I think it's best to understand some basic concepts when choosing distros. Under the hood, most distros are very similar to each other, but have a different set of pre-installed packages (software) and configuration that give it its distinct look and feel. One of the most critical differences will be which package manager the distro uses. The package manager is software that you use to install/update/remove other programs; it's vital to using Linux in any practical capacity. Some of the most common include apt, yum, and pacman. Within that, the next major difference comes from which package repositories the distro makes use of by default. The package manager uses a list of these repositories to actually find packages for installation. Many distros will often have their own repositories for various packages (and this isn't necessarily a good thing). The other defining feature is which "desktop environment" the distro uses. This is a collection of packages that (usually) gives you a Windows-like desktop, with windows, a taskbar, maybe some desktop shortcuts, file explorer, etc. Some distros will offer multiple options (Linux Mint is a good example of this). Theoretically, because desktop envs are just a set of packages like any other piece of software, you should be able to swap them out with whatever you want, but sometimes you can run into problems if a distro expects a certain desktop env (like missing or broken functionality).
That all said, I recommend you try out Kubuntu. It is a "flavor" of Ubuntu, which uses the KDE desktop environment. Ubuntu is one of the most popular distros and package repositories in the Linux ecosystem. Ubuntu normally comes with Ubuntu's own desktop env, but frankly I don't like it, and it's definitely not like Windows at all. KDE on the other hand, is pretty similar, and extremely customizable. Kubuntu is essentially just Ubuntu, but with KDE installed by default. I suggest choosing version 23.10. The older "LTS" version is often touted for stability, but you also often get stuck with very out-of-date software. Also, I would strongly suggest you get a new (decently sized) drive to install Linux onto. A clean drive makes the install process a lot simpler (you don't have to mess with existing partitions). To actually install it, this should be a pretty decent guide, just that you'll be using the Kubuntu ISO file instead. The installer may look different, but it should follow the same general flow.
Personally, I go for a more custom approach. I install Ubuntu's "Server" version and choose its "minimal install" option. It gives me a practically empty Ubuntu-based installation that has minimal bloat (though I still have to remove a few annoying packages). From there I'll usually install KDE but it depends on my use-case. This isn't something I'd recommend to someone unfamiliar with Linux though; as it requires some experience using just the terminal to perform tasks.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
I think it would be useful to come up with some written guidelines for determining when a warning is beneficial. If anyone knows of some reputable sources for learning more about photosensitivity and epilepsy, particularly in regard to videos, possible triggers and risks involved, that would be quite useful. If anyone here actually has epilepsy or a related disorder, I'd be very curious in hearing their opinions on this subject. Such as what would be most helpful for them when viewing a movie, and what sorts of situations we should look out for. The most common trigger I've heard of is rapidly flashing lights, but it seems there is more to it than that. Does the whole screen have to flash, or just a small part of it? Does the flashing have to be sustained, or would a single flash warrant a warning? Is a notice in the video description or publication text sufficient, or would placing a momentary message at the start of the video be best?
alexheights1 wrote:
loading time should be removed from ZX Spectrum encodes by default because literally nobody wants to watch that noise.
The loading screen is counted in the TAS timing, and so it's part of the movie. Removing it, despite how annoying it may be, isn't something I could agree with. Just because the encode includes something you expect no one would want to watch, doesn't mean it should be removed from the video. For example, [5109] NES Home Alone by ShesChardcore in 00:17.87 contains almost 20 minutes of watching the same screen before the game ends, and that isn't even part of the TAS movie, yet it is still included to show that the game actually finishes.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
TakuikaNinja wrote:
Another thing to note is that the SMB1 speedrunning community no longer approves FCEUX for submissions due to the default settings being deemed not accurate enough for high-level runs.
RTA rules do not apply here. FCEUX is a completely acceptable emulator to use for TASing, and TASVideos still accepts movies made with it. I've also had pretty good success console verifying TASes made with FCEUX, and there are many verified publications from as far back as FCEU 0.98.12. SMB1 in particular is emulated plenty accurately for TASing, as evidenced by how all current publications of SMB1 were made with FCEUX and have been verified on hardware. There are definitely games out there that are more accurately emulated in BizHawk, but it's not perfect either. The NesHawk core in particular is also rather slow compared to FCEUX, which could be problematic for some people depending on their computer hardware.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
Darth_Marios wrote:
I tried to make a script to pause at specific frame, but i keep getting syntax error. Im not good with C and other languages, but i used something similar with psxjin (just changing client.pause with emu.pause) and it worked, but in EmuHawk it doesnt: What i did wrong?
For reference, you should use Wiki: Bizhawk/LuaFunctions to know what functions are available in bizhawk. Syntax-wise you're missing the () parentheses on the pause function, and you're missing an end keyword. I also suggest indenting your code, it helps with readability and knowing where the end keywords should exist.
Language: lua

while true do if emu.framecount() == xxx then client.pause() end emu.frameadvance() end
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
Bigbass wrote:
So from here, the next thing to try is to insert the 2 input frames into the original dump.
This worked! The player entered the door as intended. However, it then fails to grab onto the vine, and falls down the waterfall. I'm not too surprised by this. I've never had complete success trying to insert inputs into a desyncing TAS. But at least this further supports the idea that the emulator has an inaccuracy. In addition to your research and the circumstances of where exactly the desync is occurring, I think it's safe to conclude the emulator is at fault here. Unfortunately that means there is likely no way for this TAS to ever verify unless resynced to a different emulator. Theoretically, it might be possible to keep inserting/removing inputs until it works, but this would take significantly more time than it would in an emulator, and makes it difficult to compare to the original movie.
If someone wishes to try resyncing this for the purposes of verification, I highly suggest stopping around the 8 minute mark, and then asking myself or another verifier to check whether it works on hardware. That way if there's still a problem, they don't waste time trying to resync a 2 hour movie.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
For what it's worth, just because something doesn't directly port to another emulator isn't a strong indicator of anything, including accuracy. Sadly based on your research, this appears to be an instance of what I consider a flaw in how TASing tools typically operate. In that TASers must provide inputs based on whatever the emulator claims is a "frame", regardless of how the game is actually reading inputs. (SubNESHawk in BizHawk is an example of the other methodology, where each row in TAStudio represents a single latch, rather than an entire "frame".) That said, I'll still attempt doing what I described in my previous post.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
Unfortunately I am unable to get this to verify on console. The desync consistently occurs little under 8 minutes into the run. It's first visible at frame 28258, when the player fails to enter the door. Everything leading up to that point visually looks correct, except that it seems like the player turns to the left 2 frames too early (on frame 28258 instead of the expected 28260). I tried modifying the movie by add 2 duplicate frames immediately before 28260, and redumping the input data. (The movie desyncs on emulator shortly after this point, so this isn't a fix, but just an easy way to test what would happen with 2 extra frames.) Interesting, this change enables the replay to move into the door as the TAS expects! This also indicates a high chance of an emulator inaccuracy. So from here, the next thing to try is to insert the 2 input frames into the original dump. I don't have tooling for doing this, but should be doable still. Will try later today and post back with the results. (note: even if this works, there's still 2 hours left in the run for something else to break..)
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
Here is the console verification of this movie. Link to video While the movie does indeed verify, I'm a little suspicious of how much time was actually saved here. It's been shown before that BizHawk can have less lag frames at the start than FCEUX. Similarly, this submission has 1 less lag frame at the start than the current publication. That said, the other saved frame may truly come from more optimal game play. The quantity of input frames is the same between these two movies, which would seem to indicate the other saved frame is a result of less lag.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
ThunderAxe31 wrote:
I wish to see a console verification of this movie: #8581: Pankaj's NES Batman in 09:11.86 This game as a huge history of optimization, and now for the first time we got a BizHawk movie file, unlike all the previous ones that were done on FCEUX.
Testing right now. Edit: Movie verified!
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
Samsara wrote:
I started with rewriting Wiki: WelcomeToTASVideos, which should hopefully better reflect how we currently operate. Let me know ASAP if anything can be improved/added/changed: Given that this is one of the first pages new users are likely to see, it's extremely important to me that it's as good as it possibly can be.
As far as I can see, there's no mention of the Discord server. So perhaps under the Wiki: WelcomeToTASVideos#WhatIsTasvideos section, add a link and a brief description of what exists there? Also, I noticed the introduction video is 11 years old now, and the image quality is quite low. Are there any other videos that might better show off TASing in the last decade?
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
Thanks Randomno for compiling these lists. Worth noting however that these changes can only be performed by judges or other staff. Editors cannot modify submissions (except for catalog changes).
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
dwangoAC wrote:
https://wiki.tas.bot was created to specifically address console verification and charity event TASBot aspects
Any console verification topics that don't directly involve TASBot, should remain here, not on wiki.tas.bot. Last year I reworked Wiki: ConsoleVerificationGuide to provide more details about each step of the verification process, and have made a few updates since then. There's still parts missing, I only have so much time/energy for projects. Plus some parts, like the Console Specifics section, needs more research to write properly/accurately.
dwangoAC wrote:
there's a lack of folks who have an interest in editing the wiki
That will always be a problem. Writing documentation, especially in one's free time when other projects could be worked on, isn't something most people have motivation to do. Additionally, the kind of information that would be written on these pages, can't be written by just anyone; it needs someone who understands the subject matter. In the case of console verification for example, there are very few people capable of adding to the wiki(s), since so few people do regular console verifications. Or in the case of TASBot's charity work, it requires someone who is familiar with the events TASBot has been apart of, or knows how to research such details.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
Always glad to see improvements to this beautiful game, well done! Regarding emulator choice, as far as I'm concerned, as long as the movie verifies on real hardware, that's all that should matter when "faithfulness" is a concern. Based on this newly recorded verification, I can confirm that this submission works on real hardware. Link to video It is entirely possible that there could be more or less so-called "lag" frames on console compared to any given emulator. Given the right hardware, I believe it would be possible to measure the potential difference (via composite VSYNC to track real frames). But how that translates to real time may differ wildly between different NES consoles. So there could be an argument that the total framecount of a movie may not be 100% accurate. That said, I have successfully verified over 90 movies made with FCEUX, from varying versions and time periods. Even as far back as 2007, which used FCEU v0.98.16. The reason that many movies made with old versions of FCEUX still sync on newer versions, is because the emulator's behavior in regards to accuracy doesn't typically change much between versions, and even when it does, the changes don't necessarily affect all games.
eien86 wrote:
But even worse, you are still using a very old version of it. Insisting with this choice in 2023 seems lazy, at best. This discourages potential challengers to improve the movie in the future.
I don't see how this discourages collaboration/improvements. FCEUX is a very usable emulator and for many games is plenty accurate for TAS development. If anything, telling someone they must use a specific emulator despite the existence of accepted alternatives, is much more discouraging.
eien86 wrote:
I would strongly request a resync to a more accurate emu (Bizhawk 2.9.1). I know this is possible and can be done without much effort.
The difficulty of resyncing a movie between emulators (or versions of the same emu) can potentially require a lot of effort. Depends on multiple factors including emulation differences between the two emus, and how much the game in question depends on said differences. It could be as simple as adding/removing an empty frame here or there. Or it could require reworking entire chunks of the TAS.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
The verification I mentioned for Wonder Boy is now up on youtube, and the publication updated. I also have a PCB and the components to hopefully make a flashcart, but won't know if the design is good until I assemble it and experiment with some firmware. While it's true I had problems with other games, like Sonic Spinball, the fact that Wonder Boy, a TAS from 16 years ago, verified without any issues shows that there may be potential for many more verifications on this system. Though of course, no way to know for certain until more games are tested.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
feos wrote:
I have a theory that the movie should sync on your device if the run is resynced on a core that replicates your ppu decay. But if we all agree that it should sync in theory after an accuracy tweak, then it's possible to do on console in principle. In which case we should just accept it without resyncing.
Could be. I'm not too knowledgeable when it comes to open bus or really anything to do with the PPU. In regards to acceptance though: While I would definitely like to see this verified, I do feel that it should be acceptable, as long as the glitch appears plausible, according to the knowledge the community currently has. Unless the author explicitly wants to hold off until verification? As I'm sure the judges know, there's always a chance that TASes could rely on emulated behavior that does not match the real console. While a successful verification proves the TAS is possible, a failed verification does not prove the TAS is impossible.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
Over the last week I have been working on Genesis/MegaDrive verifications; particularly trying to add decent support to my replay device and writing dump scripts. The way Genesis games read controller inputs is rather quirky, and existing emulators don't provide great support for capturing those inputs with much precision. Neither BizHawk nor Gens gives you any way to see what values the game writes to or reads from the relevant memory mapped registers for the controller ports. BizHawk has a memory callback API, but as far as I can tell, it always returns 0x00 as the value (indicating the core implementation doesn't support it). Gens' callback API doesn't even provide a value parameter, even though the internal function that handles the callbacks, is in fact provided with the read/written value! In the case of Gens, I was able to write a very simple code patch that passes the value to the lua callback which I'll get posted on github soon. Along with some build instructions, because the repo doesn't offer much help, and it appears you are required to use VS2010 which Microsoft doesn't provide a download for anymore. The callback value is important because it is required in order to understand how the game is polling a controller. Different games poll in different ways. There's no special "latch" signal like on the NES. There is something similar, but it can be in two states, and the input values change depending on how many times the state is changed, what the state is, and the delay between each state change. The game is free to write the same state multiple times, or to read multiple times without changing the state. It also appears that for some games, such as Sonic Spinball, Gens may be misinterpreting which frame the polls actually belong to, which further complicates dumping and replay. The current publication of Sonic Spinball in particular may be impossible to replay on hardware; I kept running into weird problems like the above, or the start button not registering inputs properly for no measurable reason. Additionally, there aren't many games I can't test, because I don't have a flashcart for this system, and very few carts exist at all. Everdrive is the only decent one but that costs either $100 or $260 depending on the version. But I'm concerned it may modify the state of the console (similar to the NES one does). I've made my own flashcart design, but I haven't ordered it (or thus tested it) yet.
However! There is one bit of good news. I did manage to verify [570] Genesis Wonder Boy in Monster World by Aqfaq in 42:10.45! My recording setup is a mess right now due to Genesis research, and I'd like to get some input displays. But I should get a recording up for that within a couple weeks; or maybe I'll record a basic one in the meantime just to show it works.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
feos wrote:
This version too please, it records slowest/fastest now: https://cdn.discordapp.com/attachments/450038053159960577/1098779612433108992/ppudecay.nes
Link to video Wasn't sure how long was sufficient. After around 10 minutes the results were:
Fastest:
7F-025B 3F-025A 7F-0259 7F-0255
3F-0253 7F-0267 7F-0266 FF-0262

Slowest:
01-065E 10-0736 40-0B0D 40-0B2B
40-0B31 40-0B37
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
feos wrote:
lidnariq made a test ROM for PPU open bus decay. Can people with NES run it and maybe film the results?
Link to video
TAS Verifications | Mastodon | Github | Discord: @bigbass
1 2
6 7