Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
You can hook it up as shown in the link.
The ribbon will connect to your Pi and provide power and the I2C comms (as well as everything else) to the breadboard. The "top blue board" (your boards are left and right of eachother) is not "i2c interface," it is a servo driver that communicates using I2C.
You will need to solder those headers to the servo driver board so you can plug your 3-wire connections into them.
You will also need a separate 5V PSU.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Anty-Lemon wrote:
YushiroGowa wrote:
EIGHT PLAYERS ON SNES?! Sweet Jesus that's one hell of a party!
Wait, if we can make TASes with 4 players, imagine if we could do it with eight players! Do you have any idea what that would look like?!
In theory sure, but name a game on the SNES that is made for 8 players
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
I am curious if anyone will improve emulation, or has ideas for tests I can run using modified game code to determine where emulation issues are, so this could eventually sync on console.
(Would likely mean the run would need to be redone, but...)
The problem: inputs in Kirby are polled every frame, regardless of it is a display lagframe or not. There is no method to sync input to match what is happening on screen.
For other games, polled input is usually good enough to get a game to sync. Some other games also aren't accurately emulated and don't have the same amount of frames as on emulator, but they still sync because input is polled, handled, and important actions occur on input state or on non-lagged loop iterations rather than time. (The most common example I can think of is N64 Super Mario 64, though other games are like this on NES.)
Because Kirby always polls for input, and the emulation isn't accurate enough, I have nothing to sync on. It could be a timing issue, or a loop waiting for hardware state to change, or something else. If someone can work on the emulator, and someone can hypothesize about the problems and modify the code to provide feedback, I do have a donor cart so I can burn custom test ROMs and test on console.
Worst case, the problem is the DPCM glitch in which case unless we emulate with a specific sync state and emulate this glitch we won't sync this game.
Fixing this would do two things: improve emulation quality, potentially for all games, and get a kickass run to run on actual console :)
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
blackerking wrote:
Are the blueprints somewhere published? I would like to make my own tas-snes-bot.
The schematic for my old version was, I think. The PCB was not but you can get one from me, or get a kit with all the parts. Or you could build your own design and write your own code, just depends on what you want to do / accomplish.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Not quite there.
TheAxeMan said the submitted run is faster than the one I posted and doesn't have the input delay anymore (I think?)
That said, I think this "delay" is the length of the longest possible battle?
The hold-A run can be played back with the use of only erasing the console RAM, not requiring a particular and possibly invalid situation to erase the cart. Basically it will play back on any cart after preparing using the values determined from the first battle. It's a bit unique. If only the fastest is desired, again, I think that is what this run is now?
Re: SRAM it won't decay when powered, and I think NES reset keeps it powered? (but maybe bus and data is floating and can do odd things? I don't know) Only once theory becomes practice and we know how it will work I think the question of how to proceed with resets should be answered.
Really, the real bug here is the FCEUX startup state.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Input latency is probably going to be important if button interrupts are used. I am not sure which games use this though, if any. It's not necessarily important on gameboy.
It is very likely emulation quality is not there yet. To determine if input timing is an issue, inject your own delay and determine if the results are deterministic.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
I'll need to get a copy then, or finish my flashcart. My bot already plays back / interfaces with Genesis OK but it is hard to test with the games I do have. Thanks for finding that one out.
Edit: With Ecco verification, I need to get that game instead. It looks like it's time to hack in lua bindings for movie input reading and TH pin callbacks... if someone else doesn't do this I'll look into it early next year. Hopefully someone can add this before then.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
notaz wrote:
OK, so something may be possible with Power On Reset signals, I just wonder if they also reset the phase of those refresh cycles that memory controller/bus arbiter generates.
I don't think they do; they just go through a counter and are gated, IIRC. This is why I was going to make the reset phase circuit - at power-on, my module will hold the actual reset lines on 68K/Z80 in reset for some time (to allow caps to charge, POR circuit to stabilize if present and so on), then wait until correct phase is achieved before releasing reset.
notaz wrote:
True wrote:
It's not as serious as what I need to do for SNES...
Do you have that documented somewhere? Would be an interesting read.
Two words: clock injection. =)
More words: I will document this as I go. It is confirmed / verified that CPU and sound processor clock ratio matters for some games. As an emulator will assume perfect clock, I will be injecting phase-locked clocks into the console to see if I can get Super Metroid to sync, or at least get farther. If it gets farther with only this change, then we know emulation accuracy is good, and this could be the basis of a determinism-modified SNES being acceptable for verification.
I will photodocument the process. I also discuss this stuff regularly in #tasvideos.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
keylie wrote:
When I said "arbitrary", I mean that the developers of BizHawk chose to put values in Save-RAM that are not all 0 but different values in different addresses.
If this is true, this is absurd and is a bug.
Has anyone else verified this run?
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
notaz wrote:
True wrote:
I would like to avoid a loader, but maybe it won't be possible. I was going to work on a reset circuit which would reset everything when the clock dividers were in phase to fix this issue. From minor details in your post (either uninitialized or free-running even in reset register values?) it looks like this might not be enough, though it might be a help. Wish you were on IRC, we've been discussing this a bit.
I really doubt you can reset everything, I'm not sure the VDP even cares about the reset signals.
My thought was to hold Z80 and 68K in reset at power on, then sync those to VDP clock phase. Hardware mod, yes, but only on the reset lines; we can probably look past this since it isn't on any bus and would only be at system start.
It's not as serious as what I need to do for SNES...
notaz wrote:
Yeah but currently there is no emulator that would do complete bus cycle emulation.
Yes, of this I am aware. TAS verification / legitimacy is a fairly new phenomenon, just add motivated archivists and we might get there eventually. Some quirks of these systems are known outside of this community but we're finding new ones still (like latest SMW not verifying - seems to be some unemulated register access locking up the system. Need a bigger LA to analyze that...)
notaz wrote:
Gens is especially bad at timing as it doesn't even bother emulating VDP access related stalls except DMA, and those are currently quite well understood. It's quite unfortunate most runs are made with Gens, it means most of runs will likely never be hardware verified (not that there was much choice when people started doing Genesis TASes, if only at least Fusion was open source..).
Was quite aware of the limitations of Gens. Not as much aware of limitations of gensgx core though it also isn't an accuracy emulator. Things will hopefully improve, eventually. They did for SNES after all. Hell, right now at this very moment there's heavy development on SGB integration and accuracy.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Interesting. At least it is progress.
I would like to avoid a loader, but maybe it won't be possible. I was going to work on a reset circuit which would reset everything when the clock dividers were in phase to fix this issue. From minor details in your post (either uninitialized or free-running even in reset register values?) it looks like this might not be enough, though it might be a help. Wish you were on IRC, we've been discussing this a bit.
As far as changed frames go, no in-level changes needed is a good thing. Glad to see that.
Most of the issues re: timing should be fixable in emulation. If it isn't emulated well enough, that is an inaccuracy of the emulator.
Re: R register on Z80, not sure how many Genesis games this might affect, but it is certainly an issue with SMS verification. There have been ideas posted about that earlier in this thread and at smspower. At least with a loader on SMS, we can still run the original software from the original cart without much hassle. Ideally though future TAS would support booting with a BIOS so the proper amount of frames pass and the register is set to a proper value, but right now rerecording emulators do not support BIOS for SMS, and I'm not sure when/if they will. Also need to decide which is the best BIOS to use - do we prefer speed at any cost, or prefer the more common ones (like v1.3)? Right now every SMS TAS on the site with games that use the R register is effectively unverifiable.
