3.0 Alpha Testing

[retroben]

Important realization has been made im accordance to lack of code functionality.

What I said in the ShoutBox to preserve it:

I found out why some codes are just not working as intended!
First,I was using my lighting intensity code...

Lighting Intensity (D-pad directions)
D1081084 0800
8110E446 4B80
D1081084 0400
8110E446 C480
D1081084 0200
8110E446 3F80
D1081084 0100
8110E446 4280
Use d-pad to change Banjo and some enemies lighting intensity,works on Pure Interpreter in realtime.

On Dynarec,it obviously fails,while Pure Interpreter works dead-on instantly.
The thing is,I tried Cached Interpreter,lo and behold the code does not work.
Interestingly enough,exiting and switching back to Pure Interpreter makes my lighting change on resume,which means the value is being changed properly while not being read correctly.
So I deduced this to being the issue,and I assume Dynarec is using a "Cached" method and thus breaking code functionality after the boot sequence,and the solution is to make "Pure" Dynarec available as an alternative option.
Cached Interpreter runs slower (30/60fps compared to Pure's 40/60fps on the title seqeunce
both with "no frameskip" code enabled) than Pure interpreter anyway,so maybe Pure Dynarec is faster.

I finally found out about the cause of the issue,and I really want this.
So,who can apply this change for Dynarec so that all activator codes can finally be fully functional on Mupen64Plus AE?
Please,please,PLEASE!,someone do this! I'm begging you! I would be so happy about this.

[littleguy]

@retroben Great diagnosis

This is out of my league but Gilles might be up for it.  I wonder if the same issue affects the PC version of mupen64plus.  If so, then there's a lot better chance that the cached interpreter can be fixed (multiple devs with the skills).  And if the flaw in the cached interpreter is fixed, then it might provide a clue for the dynarec.  (Or maybe not.  They both cache instructions, but not necessarily in the same way or at the same level of abstraction.)

[retroben]

I was actually kinda going for a non-cached dynarec.

[littleguy]

I think by definition that doesn't exist   The very nature of dynamically recompiling machine code requires you to cache results.  Otherwise you'll just have a slide show.

[retroben]

Then why does Pure Interpreter run identical speed (or even better) than Cached Interpreter?

The Pure Interpreter does not run all that slow considering it runs decent on the limited Android OS.

It makes me wonder,what business does PJ64's Recompiler have running under the hood?
A good question to ask zilmar or the other devs about on their forum.

I already knew that activator codes worked better on Mupen64Plus AE's Pure Interpreter,but it was recent when I figured out approximately why they fail on the other two choices.

[littleguy]

Then why does Pure Interpreter run identical speed (or even better) than Cached Interpreter?

Very good question indeed.  This might be worth posting to the upstream forum.  Your experiences suggests that (at least in this particular situation) the overhead of caching is actually more expensive than recomputing stuff every time.  Very odd result indeed.

[retroben]

At least on Android OS since caching is slower in some cases,especially for outdated Qualcomm drivers like my FireTV's.

[retroben]

More things to think on.
What is all being cached on the dynarec?

Excluding performance,what's the purpose of caching all of the RDRAM when you could just read from it directly?
For example,Banjo-Tooie with a chunk of RDRAM from around 80090000-80120000 is unchanging values.
This chunk can be read and yet my codes based on this location fail to work with activators but are still being written.
Since this location is needlessly cached,the toggled code is never read and thus does not function since the cached data is from the boot sequence and not altered like the original copy and is the one being read from.

If you haven't already,I will try to make a post on the upstream Google Groups site to see what they think.

Edit: About the performance,I tried a comparison with Conker's Bad Fur Day and Pure Interpreter is faster than Cached Interpreter on that game as well.

[retroben]

(That's what overclocking could be used for!)

Just thought of something,what about non-cached recompiler with alternate overclocking to give it all of the extra needed Mhz to run at top speeds?
Maybe even segregating Mhz (if even possible/please be possible) to 100Mhz normal running and a large extra chunk like 400-600Mhz used by the thousands of instruction calls so that they can be called at maximum force!
(Of course both on the same CPU core.)

Sure this means using extra battery,but it is a trade-off for scary good performance and closer to "accurate" emulation since no cached instructions.
All of the Android devices nowadays have at the very least 1.0Ghz,mediums of 1.5-1.7Ghz and powerful ones with 2.0+Ghz so it would be very easily accomplished.

If none of this can even conceptually work,then a fellow can dream.

Edit: But,if at least I can get some info from PJ64 devs,maybe it will be possible to import some functions from their Dynarec's source code so activator codes can all work properly.

[littleguy]

What is all being cached on the dynarec?
Excluding performance,what's the purpose of caching all of the RDRAM when you could just read from it directly?

It's not RAM that's being cached.  It's the instruction translations.

Here is an analogy.  You speak English (ARM).  The original N64 instructions (i.e. the info stored in the cartridge) are in Spanish (MIPS).  The pure interpreter uses a spanish-to-english dictionary.  Every time it sees a sentence in Spanish (MIPS), it looks up every word in the dictionary and converts it to English (ARM).  Then it reads the sentences (instructions) in English to the hardware to perform the task.

Cached interpreter works almost the same way, but every time it translates a new word, it writes the translation down on a one-page "cheat sheet".  Then whenever it translates the instructions from Spanish (MIPS) to English (ARM) it looks at the cheat sheet first (which is very easy to search) before looking in the full dictionary (which takes a lot longer).  Most of the time, most of the words in the original Spanish (MIPS) instructions are already in the cheat sheet, so the cheat sheet makes the translation process go more quickly.

Dynarec works on a higher level.  Instead of reading a sentence and translating it word for word using a dictionary, it instead understands whole phrases in Spanish, and converts the whole phrase to an equivalent phrase in English.  So where the pure interpreter would translate Spanish "de nada" to English "of nothing", the dynarec translates "de nada" to English "you're welcome" because in a particular context that's actually what "de nada" means at a high level.  The problem is that it takes a lot more up-front effort to translate things by phrase (dynarec) than by word (interpreter) because understanding the context is difficult.  So the dynarec will always need to cache the most common phrase translations, in order for it to pay off.  In practice, there aren't that many phrases to translate in most games, the phrases can be cached, and the up-front cost of translating by phrase pays off because the resulting translations are much easier for the hardware to understand.

So, as William Shipley said in the upstream forum, it would never make sense not to cache the phrase translations that the dynarec performs.  If you didn't cache them, it would be faster to just use a pure interpreter.

All that said, it is always good to isolate which mode (pure intepreter, cached interpreter, and dynarec) the bug occurs in.  Every bit of information from testers is valuable.

[retroben]

Aren't the instructions placed in RDRAM?

What I was about to post before re-reading your comment.

Code: [Select]

So the optimization route is the only way to go by making it detect the changes a cheat code makes and writing it to the respective place in the cache instead of outright ignoring the change.

One smart way to do this is to take the addresses of enabled cheats and set them to a "watchlist" that allows real time changes to be completely effective by sending them to their matching cache address in realtime and allowing cheats with activators to be fully functional like my example code would do.
Maybe a seperate process can be made in a non-used core to do this function to eliminate any chance of performance loss.

I was told to use the IRC on the PJ64 forum to try to get help from anyone like zilmar,but I can't really grasp how to begin.
If it can be figured out,you could possibly get PJ64's method of handling the more troublesome GS cheats on Recompiler.

A different thought,maybe there can be another approach that reacts to enabled cheats for addresses that are cached and results in forcing an additional write to the equivalent cached addresses.
*ingenius* Or skipping the whole step and writing directly into cache if the address is in that range.

[retroben]

Then there is only one viable solution...
We need to find out and implement the function that PJ64's recompiler uses to make all GS codes with activators work.

Just need contact with zilmar to see if he would like to send us in the right direction.

[retroben]

Trying to call this to attention again...

Is there a way to fix the issue where rendering has that ugly dot-matrix visual on the game's screen?

I finally decided to upload n image to show this issue as seen in DK64 while all other games also have the ugly dot-matrix filling the screen.

http://www.2shared.com/photo/a_nd8stU/donkey_kong_64-001.html

The blue from the water makes this stick out like a sore thumb,and even DK has it on him.
It is not caused by the water itself,I have seen it in other games away from water,just easier to point out this way.
I recommend using Perfect Viewer to look at the fullsize image at its native resolution.
If you can't see it,look really close and it should be visible.
And if you have a 1080P or better HDTV,and a way to display it on that HD screen,look at it that way as well.
(I am sure Nvidia includes a proper HDMI wire for their BEAST of a Shield tablet for use on a large TV screen)

I really wanna see the visual quality become crystal clear,I hope there is a simple fix for this.

[xperia64]

That would be the dithering. It's used more in older games, especially on the PSX. I don't know how feasible it would be to disable it.

[retroben]

Just tried DK64 in a computer on PJ64 (1.7.0.50b23) and I can't see ANY dithering on it.

I can upload a screencap of it if you wanna see what I saw.

Edit: I think its a problem with Android rendering since even some image viewers have dithering on the renderer.
(for example looking at a sharp picture with a lot of orange in it)
It should not be too difficult to find a fix for.

Edit2: Tried an instance in all three emulators I can run on PC.
PJ64,1964,and Mupen64++ with none of them having the dithering.

Edit3: Here is another one I took a while ago on Android,it really points out the dots on the whiter spot.

http://www.2shared.com/photo/2zeuoG3c/banjo_tooie-005.html