Go Back   Project64 Forums > Public Version > Project 64 - v2.x - Issues

Reply
 
Thread Tools Display Modes
  #1  
Old 29th April 2015, 03:05 PM
tony971 tony971 is offline
Member
 
Join Date: Jul 2013
Posts: 52
Default Tricky unexpected behavior

HatCat, AIO, and I have been trying to pin down the cause of some issues I've been having with builds since the 2.1 release (haven't exactly tracked down which commit caused it). Here's what's going on:

Playing Zelda OoT will spawn CN64System:RunRSP - Unknown memory action errors. They happen at various times, but they're not random. They're setting dependent.

This is when I can expect the errors:


Now the extra tricky part is that this seems to be computer dependent. I gave my compiled version of pj64 to both HatCat and AIO and they were unable to reproduce my errors. I've tested on two Windows 8.1 machines with Ivy Bridge/Haswell CPUs. The Ivy Bridge also uses a discrete Nvidia GPU. I compiled using Visual Studio 2013 and the VS2013 makefile (on each machine). Any idea what it might be?

Last edited by tony971; 30th April 2015 at 01:32 AM.
Reply With Quote
  #2  
Old 29th April 2015, 03:46 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Quote:
Originally Posted by tony971 View Post
HatCat's fork of angrylion's RDP also causes the error at ROM boot with both the stock RSP and HatCat's RSP.
Wouldn't that mean you get the error with other LLE graphics plugins, e.g. Jabo's D3D8 LLE with my rsp?
Reply With Quote
  #3  
Old 29th April 2015, 05:41 PM
retroben's Avatar
retroben retroben is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Jul 2013
Posts: 687
Default

How well does GlideN64 run the two Zelda games compared to the powerful Jabo 1.6.1 plugin?
Maybe theboy181 could make a video or two showcasing both Zelda games with GlideN64 using various parts of the games like activating the lens of truth and a few other problem areas that affect other plugins.

The 1.6.1 version of the Jabo plugin runs both Zelda games pretty much flawlessly with even the after-image effect on Majora's title screen.
Reply With Quote
  #4  
Old 29th April 2015, 08:19 PM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Talking

Quote:
Originally Posted by HatCat View Post
Wouldn't that mean you get the error with other LLE graphics plugins, e.g. Jabo's D3D8 LLE with my rsp?
Well, all variants of Angrylion's plugin can't run Super Smash Bros with Protect Memory enabled, yet other LLE plugins can.
Quote:
Originally Posted by tony971 View Post
Now the extra tricky part is that this seems to be computer dependent. I gave my compiled version of pj64 to both HatCat and AIO and they were unable to reproduce my errors. I've tested on two Windows 8.1 machines with Ivy Bridge/Haswell CPUs. The Ivy Bridge also uses a discrete Nvidia GPU. I compiled using Visual Studio 2013 and the VS2013 makefile (on each machine). Any idea what it might be?
Certainly I know that it's a CPU recompiler issue with Protect Memory. The message is supposed to show for everyone, but for some unknown reason, it doesn't.
Reply With Quote
  #5  
Old 29th April 2015, 08:38 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Must be that they're not fully buffering the RDP command FIFO data then.

After all, the more you HLE something, the less dependencies it has on other components of the emulator being done properly.
Reply With Quote
  #6  
Old 29th April 2015, 08:40 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Quote:
Originally Posted by RPGMaster View Post
The message is supposed to show for everyone, but for some unknown reason, it doesn't.
Could it by any chance be related at all to the fact that zilmar thinks error messages and failures are only important information to testers who Enable Debugger as a run-time option in the binary?
Reply With Quote
  #7  
Old 29th April 2015, 11:50 PM
tony971 tony971 is offline
Member
 
Join Date: Jul 2013
Posts: 52
Default

Quote:
Originally Posted by HatCat View Post
Wouldn't that mean you get the error with other LLE graphics plugins, e.g. Jabo's D3D8 LLE with my rsp?
Actually, Jabo's D3D8 LLE doesn't get the error at all with your RSP. (at least at the known fail points)
Reply With Quote
  #8  
Old 30th April 2015, 01:28 AM
tony971 tony971 is offline
Member
 
Join Date: Jul 2013
Posts: 52
Default

Here's the extent of my testing. This is a chart of when I'll get the error:

Reply With Quote
  #9  
Old 30th April 2015, 07:15 PM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Talking

Quote:
Originally Posted by HatCat View Post
Must be that they're not fully buffering the RDP command FIFO data then.

After all, the more you HLE something, the less dependencies it has on other components of the emulator being done properly.
Hmm, I might try debugging Super Smash Bros, to see where it crashes, with Angrylion's plugin.
Quote:
Originally Posted by HatCat View Post
Could it by any chance be related at all to the fact that zilmar thinks error messages and failures are only important information to testers who Enable Debugger as a run-time option in the binary?
I don't think so, because I always have Enable Debugger on. I highly doubt zilmar would prefer it being hidden (unless he knew all along and couldn't be bothered to fix it ). He could have done a better job hiding it, if that was honestly his intention. Since hardware seems to be a factor, I doubt it's intentional. Also, tony already sent us his folder, so that eliminates the possibility of it being related to settings. I just think PJ64's error detection code is faulty. It reminds me of instances where DisplayError didn't work ;/ .

The key issue is that RDRAM access during SP_DMA is blocked (due to Protect Memory), when it's not supposed to be blocked.

If you want to always be aware of the problem, just put the SP_DMA_WRITE function inside of
Code:
__try{
    //SP_DMA_WRITE goes here
} __except(EXCEPTION_EXECUTE_HANDLER) {
    DisplayError("SP_DMA_WRITE");
}
Reply With Quote
  #10  
Old 1st May 2015, 02:00 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Quote:
Originally Posted by RPGMaster View Post
If you want to always be aware of the problem, just put the SP_DMA_WRITE function inside of
Code:
__try{
    
} __except(EXCEPTION_EXECUTE_HANDLER) {
    
}
mk will do.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT. The time now is 06:04 PM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.