Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
thecoreyburton wrote:
Thanks for all the very quick replies. I'll dump my DSP files for LLE
AFAIK, all Gamecube and Wii consoles have the same DSP firmware.
So if it is dumped from Gamecube or Wii or what region it is (USA, Euro, Japan, etc..) doesn't matter.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
CoolKirby wrote:
Ilari wrote:
There are also graphics plugin independent problems with 4148S, causing the emulator to possibly crash or lock up at ~1h point.
There are? This is the first I've heard of this.
Basically, the game causes Dolphin to read texture memory out of bounds.
Now, if there is sufficient amount of stuff after texture memory buffer, it will work, just returning garbage.
But if the linker didn't place enough stuff after texture memory buffer, the reads can run to unmapped page. Boom. Emulator takes a page fault.
Depending on precise conditions, the emulator may instantly crash, or try to retry the failing operation (after supposedly "fixing" the problem, which doesn't seem to do anything), causing new page fault, ad infinitum.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
4116S works with OpenGL. 4148S possibly has trouble with OpenGL, but that manifests as serious graphic glitching, not desyncs.
There are also graphics plugin independent problems with 4148S, causing the emulator to possibly crash or lock up at ~1h point.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
Masterjun wrote:
Moving on to the next example, Yoshi's Island. The same happened to the short and the long run.
In this case, the short run does corrupt memory and the long one doesn't, but the reason why the short run corrupted memory was not the key factor to the credits glitch. It corrupted memory because I had to waste time for the controller registers to update and so I activated random DMA channels, which corrupted VRAM.
I though that the whole mess started with corrupting the egg list (or something) and escalated from there to game jumping to hyperspace?
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
Well, it is possible to reprogram the OAM referesh routine (and there is bit over 10kB of empty space in RAM).
OAM refresh routine runs every frame, and it is never rewritten. And that unused memory is just plain never touched by the game code at all.
So it is possible to hook the OAM refresh to execute custom code every frame.
However, what this can do is limited, given that most routines and interesting data is fixed in ROM.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
Hmm... If one did the following:
- Take the movie file, and remove savestate and reset from it.
- Load the modified movie, pausing immediately (frame 0).
- Run a lua script to poke the memory locations listed.
- Continue execution.
Would it sync then?
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
Starting from SRAM / memory card requires a verification movie (doesn't have to be optimized).
This is because one can really screw many games by feeding specially constructed saves.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
Mothrayas wrote:
The Gameboy has 8 buttons to send input, which would be good for 1 byte per frame.
One can spam read of relevant hardware register (IIRC, 0xFF00) to get data faster than 1 byte per frame.
I haven't tried how fast one could actually read it. The hardware register actually reads one nibble at a time.
Mothrayas wrote:
The SNES has 8 controllers with 16 buttons to send input, and input can be sent at least 3 times per frame to sync on consoles - that's 48 bytes per frame. Without console verification in mind, that can go up all the way to 480 bytes per frame.
IIRC, when I tested no-limits read speed, I got something like bit over 1024 bytes per frame. Of course, that is burst speed, only maintainable for a bit over a second. Moving the data somewhere else (e.g. APU or PPU) will slow things down.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
CoolKirby wrote:
Oh, that's a shame. I guess the most we can do is encourage those who make these address lists to make sure the list they're creating will contain meaningful content and be able to be loaded into BizHawk.
Yeah, it offers wch download for systems where it can't work, and the domain support is what screws over easily changing the system...
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
jlun2 wrote:
According to google's cache, 19 was "Bobby is Going Home".
http://i.imgur.com/doOU8Qx.png
Hence why I'm concerned if others were legit game entries. :o
46 and 47 looks have been sets for Paper Mario: The Thoursand Year Door. However, those were empty (no addresses).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
Leeadamaa wrote:
in an ideal world. a Reference frame could be fed in to resync but then you would need to have the emulator running and scanning every frame to determine which one the console is at....... the analoginess of the signal makes this impossible.
Another crazy idea would be to monitor the address bus between SNES and cartridge. One could determine the lag from that and poll signals. Problem is, that address bus runs at several megahertz...
Oh, I have also seen "not quite lag". Basically, the game is doing operations on background that take variable number of frames and don't freeze the action.
And if AI of something waits for such operation to complete, the duration can react with the AI in major ways (In one case, I saw few frames caused some actions to slow by over half a second!).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
Leeadamaa wrote:
Emulator accuracy is quite "of the horrible".is the inital state lag of the SNES constant or very random. I know lag is random but if there some consitency it may be easier to compensate for it.
The actual problem here is bit subtle:
The problem is not determining how much lag would occur under given conditions (accurate SNES emulation), but that SNES initial state is random and in some games that affects lag.
And thanks to automatic polling, there is no known method to compensate for lag that varies with initial state.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
Leeadamaa wrote:
is the inital state lag of the SNES constant or very random. I know lag is random but if there some consitency it may be easier to compensate for it
It depends on the game if it is consistent or very random.
- Super Mario World has consistent initial lag.
- Speedy Gonzales has quite random lag. It only sometimes even gets to the first level (and then desyncs quickly).
