Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Tried verifying this run.
MM1: Desyncs at first boss. Issue with the weapon menu.
RM1: Desyncs in IceMan stage, at the glitch point. The game gets extremely laggy, the enemy zips really fast downward, then Rockman dies off the top of the screen. The glitch as seen on emulator never executes.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Warp the Post Deleter Supreme wrote:
TheAxeMan wrote:
TASbot currently can't do hard or soft resets.
Just keep it that way. No need to ruin yet another cool project.
I don't understand this "ruination" part?
My new replay device has aux IO for specifically doing things like this. It even supports its own voltage rail if desired (up to 6V). Here are my ideas for hard/soft reset:
Hard reset is simply an output signal that goes high/low depending on if the run is running. Basically I already have this with the "RUN" LED which is lit while running and off when done. So what would happen would be any run with hard reset / power cycle would be split into multiple runs, and the run segment would end by immediately signaling this output, which can then control a relay or other device to turn the console off. In the case of NES, one would need to wipe console memory before loading the next portion of the movie. I made a cart to do just that.
Soft reset is trickier. The way I am proposing is using an actuator to actually hit the button as it involves no additional wires to the console and for a casual observer it looks more impressive. This is again simply an aux output.
How would supporting this "ruin" my project?
dwangoAC wrote:
TASBot as a "person" has become something far larger than I ever imagined.
While I don't fully agree in the case of this thread, in general I understand and agree with you.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Chamale wrote:
True wrote:
Chamale wrote:
The NES seems less reliable with TASbot than other consoles, particularly because the hardware is more variable than later Nintendo systems
I'm sorry; what? If you know something about my bots (that everyone calls TASbot now) that I don't I'd like to know?.
I think it's an issue with the console and not the bots. NES consoles are older and have more variation between individual units, and TASbot had more synchronization problems at AGDQ with the NES than with the other consoles. I've also heard there are more issues with runs that sync on one NES failing to sync on models that should be identical, but as the others pointed out EMI may be the cause of the problems at AGDQ.
You are misinformed and working on hearsay. Additionally, your thoughts on this subject are wrong.
Perhaps the mentioning of differences of console on-screen is confusing you, because it confused them too - if an NES run syncs on a production NES, it will sync on any production NES.
My original replay device (which is not called TASbot by the way and is not limited to playing back TAS) only plays NES and SNES. The reason there were more NES problems, and specifically on only one game, are possibly because there was more screen time for NES so more chance to run into problems. The problem was not related to console variation.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Chamale wrote:
The NES seems less reliable with TASbot than other consoles, particularly because the hardware is more variable than later Nintendo systems
I'm sorry; what? If you know something about my bots (that everyone calls TASbot now) that I don't I'd like to know?
TheAxeMan wrote:
The bot setups I have seen, particularly last year's AGDQ, don't seem to have thought about EMI at all. Putting the bot board in a metal enclosure and shortening the controller wires to a minimum should make a huge difference.
Yeah, should be enough really. My MultiReplay bot may be more susceptible to EMI than the old bot (or maybe not) but if the old one is manipulated to do this run, it should work well with shorter cables.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Tub wrote:
The 1/256 chance is only true if we assume that every bit has a 50/50 chance to be 1 or 0 before initialization. Due to slight differences in hardware, that's rarely the case. If you want to do it from power-on, your best bet is to buy 256 NESs and hope that one of them favours the 0x80 value you need.
Not even. Default values at power-up are not guaranteed but will likely favor a "blank" value (usually 0x00 in SRAMs) - so this is likely unattainable in practice. Also this is probably a debug code that could be poked by the debugger that was left in.
EDIT: I was thinking of NES for some reason even though SNES is in the title. SNES uses a PSRAM so it is more accurate to say that yes, the power-on states will differ by console, and consoles will independently have different patterns, favorite set/reset bits, and so on.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
I don't think NESbot will ever be capable of running this. Let's not confuse names please.
That said, I think the run is too long for marathon to hope you don't get a desync because of EMI or some other factor.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
TheReflexWonder wrote:
Not sure if it could be applied in a way that would be suitable for max speed in a TAS, but you can apparently skip the credits scene by dying and opting to quit out while getting Neo X/Robot Y to kill himself with your flying body:
http://youtu.be/pP5cksstsvI
Would that count as beating the game by TASVideos standards?
BADASS.
And yes. (I'm sure SOMEONE would cry about it though)
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
It isn't your computer. Your video shows very clearly that you 1) believe heavily in your cargo cult and you do not understand what you are doing which leads to the fact that 2) you have no idea what you are doing.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Dyshonest wrote:
I know you're spewing more crap across threads where a lookup table or equivalent somehow turns into executing arbitrary instructions but can you please tell me where you got this ignorance and how I might be able to get it also? thanks.
Oh, your ignorance comes from watching videos on Youtube! It all makes sense now. You ACE'd me bro! I'll start watching Youtube videos so that I can become a master ignoramus in no time! Thanks for the tip!
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Dyshonest wrote:
...which I guess might be faster than repetitively doing the Trainer Fly/Mew Glitch to get Pokemon? Though again, that's still ACE (assuming you're using item underflow and there's not some hidden thing to CoolTrainer that also triggers odd encounters).
I know you're spewing more crap across threads where a lookup table or equivalent somehow turns into executing arbitrary instructions but can you please tell me where you got this ignorance and how I might be able to get it also? thanks.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
SMS UPDATE
SMS now syncs on my Model 1, BIOS 1.3 console :)
HOWEVER, the game I am testing, Alex Kidd in Miracle World, has some sort of nondeterministic RNG where the moneybag drops are not always big bags, but sometimes small bags. So the midget doesn't have the money to buy the bike in the second stage. :( But Stage 1 syncs nearly every time (sometimes not because of vsync offset, but >80%) so progress is being made. Just need SMS games, and maybe someone to look into Miracle World...
EDIT:
Ordered 19 SMS games and I lucked out; now I have all 4 common external mapper types (5208/5235/5235+BBRAM/5365) so I should be able to attempt to verify every SMS game. None of the games I ordered have runs on this site yet so they will all have to be donors :( Technically only the 5235 type should be needed but I want to be as similar to original hardware as possible when original hardware isn't made available.
I tried Wonder Boy III (thank you Walter Payton) and it does not sync; both emulator and console act similarly (but not the same) in that they don't start a new game and hit Continue instead. I made a demo movie and it was wildly different with sync and start time. Site run probably needs old emulator? Other emu problems? From my experiences so far I don't think SMS emulator accuracy is even close to other consoles.
I will also probably need to either modify the console or build an actuator of some type to hit the Pause button for games that use it. I am pretty sure WB3 is one of these games.
So progress is being made for the first SMS verification, but nothing promising yet.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Warp wrote:
I'm going to be completely honest here: I'm getting tired of the prevalence of runs that just glitch to the end of the game. In fact, I'm getting so tired of them that I may just start skipping them altogether at some point, if and when people keep making them. They just don't interest me anymore.
blah blah blah blah
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
creaothceann wrote:
True wrote:
Keep in mind: Open Bus glitches are likely exploiting an emulator deficiency, or maybe a bug. The bus is likely not implemented properly when open.
"The bus" is just an 8-bit register that is simply not updated when the CPU does a read request from an address that has no hardware mapped to it. This is well understood. (Actually, there are several MDR in the SNES (PPU and APU, iirc) but the CPU MDR is the most useful one.)
I understand exactly what it is, and the address buses / data bus in use on the SNES, but did not know the actual hardware implementation of the data bus. While perhaps well understood it is far from well documented. I am trying to find out why SMW is behaving as it does and this was the potential low hanging fruit. As edited in my post well before your reply, this behavior seems to work as expected on console.
(And while it may work somewhat like a register, or be implemented internally as one to the CPU, it is called a "bus" for a reason. Again, I understand the technology, but did not understand this specific implementation. After some tests with total confirming behavior and moving the focus of the specific problem, I understand it now.)
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Keep in mind: Open Bus glitches are likely exploiting an emulator deficiency, or maybe a bug. The bus is likely not implemented properly when open.
If Masterjun doesn't finish his test, then I'll write one for SNES. (Having a flash cart or other dev thing would be nice but if I can't get a hold of one I do have an EEPROM I can use instead.)
edit: total did some testing and it looks like open bus reads are working as expected on console. Maybe he can write details...
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Why is this still being argued? You guys are too easy to troll.
Either the guy is being ignorant on purpose or is ignorant of his ignorance. He doesn't know how microprocessors work. Nothing will come of this. But please continue if you want to provide minor and ever dwindling entertainment value.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Genesis Update
I probed around a bit on an early Genesis Model 2 tonight and half turned on some thinking abilities to try to figure out why Sonic 1 seems to have such wildly different startups.
Basically, Sonic 1 on console will have different lag periods and sometimes different frame counts at and around the opening SEGA scream. Everything is divided down from one master clock, so I was thinking it was a clock phase issue. So I probed around a bit, just to document:
* The clock is still divided and running when the CPUs are reset by the main ASIC. Whatever counters are involved are not reset. Which makes sense; it doesn't realistically matter.
* Holding the Z80 in reset, Sonic 1 boots and runs fine. I'm sure it's no surprise, Sonic 1 doesn't use the Z80 at all.
* Every boot of Sonic 1 results in different lag timings, and sometimes different frame counts. It doesn't matter if the console is hot or cold. Two very cold attempts will still result in very different results.
So what I think now is the same as what I was thinking, just with different parts: the clock phase difference between the VDP and 68K is the root cause of the non-determinism.
CPU and sound clocks are divided by 7, VDP and Z80 (I think) by 15. LCM of these dividers is 105, so this might explain why Sonic 1 syncs so rarely but does sometimes sync. (This is with GhostSonic's input file; I don't know what he changed with it.)
My next thing to try is a phase detect reset circuit to try to force the clocks to be in phase (as I imagine an emulator would do). With this, even if the run doesn't sync at first, I could at least see if it results in a deterministic Sonic 1 boot. And if it does, it's only a matter of shifting the offset around until we get a deterministic, repeatable sync...
(Note to the console verification complainers: yes, this would mean I would have a modified console for verification. However the modification only means I don't have to try hundreds of times for a sync that IS otherwise possible on console, just one in a hundred times on average.)
Would anyone mind looking at what happens during Sonic 1 boot? Is there any crazy shit going on? Anything funny with VDP registers?
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
I'd love to verify this, but it might be either hardware impossible, or at least not possible on either of my Model 2s. I'll write more in the console verification thread.
