Since the Project64 2.1, i'm having crashes on Pokemon Stadium 1 and 2, to fix these crashes i'm using the interpreter. Now in the latest build of Emucr on Pokémon Stadium 1 the crash only happens with Glide64, but on Pokémon Stadium 2 crashes still happen on Pokemon selection screen before the battles with every video plugin.

When using LLE GFX plugins Killer Instinct will not load. Changing to CPU interpreter fixes the issue, but I imagine at a cost of speed.

Steps to reproduce:

First, edit the Game Settings as follows:
-Disable 32 bit Engine
-Set Function lookup method to Virtual Lookup Table
-Uncheck every Self Mod Method

This is in onder to make the game able to start correctly on the Recompiler. (also to be consistent with the Retail ROM settings)

To reproduce the error:
-Start the game
-Wait a couple of seconds.

You'll see that even the N64 logo is scared of these cryptic error messages :p

Setting the RSP to interpreter doesn't make a difference.
It only works correctly if I set the CPU core style to interpreter.

(Just a note, the ROM will appear as "Bad ROM? Use GoodN64..." in the ROM browser. The actual ROM name is "CBFD ECTS")

Reported:
http://forum.pj64-emu.com/showthread.php?t=4839

Saved state and EEPROM battery save file:
http://mega.co.nz/#!EolUEB7b!VyJOeMuUjKalTu6DP-4C_9ApTCBoZgQqhOJwJV18lac

Patiently doing nothing from the point at loading his saved state and waiting for me to pretty much die and finish getting beat, the SP DMA error messages do start to finally happen in Project64 RSP recompiler, but I have not managed to get the SP DMA crashes to happen when running the Project64 RSP in interpreter mode, just recompiler. Also, simply clicking "OK" repeatedly in the SP DMA error messages still lets you continue the game normally...no corrupt audio or anything.

there is a pull request (#27) that has updates to jabo's1.6 plugins.

I am wondering if we even should have the 1.6 plugins, the 1.6.1 plugins are mostly a refactored 1.7 plugins that are there.

What plugins do you think pj64 2.2 should install with ?

Rather, I want to tell you what they're bringing in GIT version, there are mistakes, like the case of sound that PLUGINS Jabo's Direct Sound does not work. I have run the game JAMES BOND 007, only the sound is worse. As the speed that certain games that lower FPS and are delayed. As for DONKEY KONG both the graphics and speed.

Hopefully they can fix that problem

I was wondering what the plans are for updating the RDB. It's missing a few roms, particularly revisions and prototypes and homebrew. For example-

Aidyn Chronicles 1.1
Animal Forest fan translation(s).
Glover 2 prototypes.
Indiana Jones and the Infernal Machine PAL.
Perfect Dark NTSC debug.
Superman 64 prototype.
Variety of Turok 3 prototypes.
Wonder Project J2 fan translation.

Plus some other stuff like 64doom and the Wolfenstein homebrew. Not that those work since they only function on cycle accurate emulations such as Cen64, but I think the RDB would benefit from being more complete.

Not sure if this can be emulated correctly, but MK64 has issues with emulating the correct speed while playing Mario Kart multiplayer. Most noticeable in DK jungle with 3 or more players. I think that Nintendo has coded the game to increase some multiplier to achieve reasonable results in frame rate when playing MP on the real HW. This is only emulated correctly on the Wii VC.

Hello
use the LLE Video in F-ZERO X, an error occurs before the race start.

This issue in both Windows 8.1 and XP.
When Taskbar located at top edge or leftmost, move the window position each time.
Sure, Taskbar located in the default position (bottom edge), no problems.

Whenever you run a Mario64 hack the emulator shows a black screen and goes between 25 and 1 VI/s

Break point found at
.\N64 System\Recompiler\Recompiler Class.cpp
151

Virtual lookup table never works for any ROMs, demos or anything.
It works if I set to CPU interpreter, but that I guess is because virtual lookup table is only for recompiler.

I never remembered needing that option to get anything to work/fixed/faster speed anyway.
So why should it exist?

I play Mario Kart 64 with N-Rage & a mouse

For example: When I drive on Luigi´s Raceway & try to steer to a side, it´s works like everytime before in 1.6 til 1.7.0.49.exe

After that it feels like left is not left but left-up, only when I move the mouse left-down it´s like left
It´s weird to explain

The problem starts after the 1.7.0.49.exe & goes til 2.1.0.1 (but not tested all 1.7 & 2.0)
Settings are the all the same

Hope you understand

The current default of 2200 makes many games run too fast, a prime example being Perfect Dark. 1500 runs at the correct speed in all these games. The default should be 1500, and if any game benefits from a higher value it should be set in the RDB.

This is a trivial change and I've actually made it in the source (despite not actually knowing how to program, lol), but I'm still setting up git and so I can't make a pull request yet. Would somebody please take care of it?

After a lot of complicated troubleshooting with the Evangelion SP DMA errors, which happened with RSP audio ucode in LLE from various saved states on various emulators' interpreter cores, we ran into very consistent, very easy-to-find problem with BattleTanx:

1. load ROM
2. press START
3. "New Game"
4. If you get tired of waiting for the stupid cinematics you can just keep pressing A.
5. SP DMA read error! No saved state necessary.
6. only happens with LLE gfx, audio could be HLE doesn't matter

The fascinating thing is that when the SP DMA errors start varies...sometimes it starts right after you press START button to get through the menu, sometimes it happens after you begin a new game. Interpreters shouldn't be giving random/unpredictable results like this though I would have thought? Then again I'm not really a R4300 person.

The Game Quake64 working very slow.

Neon64 is a NES emulator which runs on the N64.
You can download the ROM at: http://hcs64.com/neon64.html

Once again, if it can make it without crashing on 1964, it could be fixed on Project64 too:

Mia Hamm Soccer 64 never boots without RSP interpreter, regardless of R4300 CPU settings.

Not much more I can say...pretty easy to reproduce; just try loading the ROM. I have to forcefully shutdown the EXE, as it seems to be stuck in an infinite loop within the RSP compiler thread rather than the main CPU, I guess.

It might coincide with recompiler bugs in some other games.

Basically if I disable expansion pack, use HLE graphics, and have advanced block linking enabled, I get an error message "Breakpoint found at N64 System\Recompiler\Recompiler Ops.cpp 324". I always had "enable 32bit" disabled, and tried both virtual and physical lookup table. If I enable expansion pack or disable advanced block linking, it's able to boot the game.

After doing more checking, I found that LLE graphics doesn't seem to work. Regardless of whether I use cpu recompiler or interpreter ;/ . Probably a different issue though. I tested both AL's gfx plugin and Jabo 1.7.0.57 ver5. I'm sure I've gotten LLE graphics to work before, so I need to figure out what settings work. Although I remember not being able to get LLE working, when expansion pack was enabled.

Steps to reproduce:

1. Start the game, get to the Barn Boys chapter; select the Mad Pitchfork one.
2. Get to the cutscene after Frank the pitchfork says is going to "kick your ass".

http://forum.pj64-emu.com/showthread.php?t=3595

Attempting to create a new MemPak immediately crashes the emulator.

The only entry in the log file is this.

2015/01/27 20:20:28.174 01176: Error : WinMain: Exception caught (File: ".\main.cpp" Line: 401)

Rat Attack is working in PJ64 1.X but not PJ64 2.X

lol nope

When using the VR4300 (main CPU) recompiler, Project64's speed takes a nosedive at this point in Super Smash Bros.:
http://ft.trillian.im/785abe041074fd64135ab3318aff1ec8767ab03d/6w1yA1Z2ZpECrmjj9AsaFtA1W4NVq.jpg

It's consistently reproducible. HLE / LLE gfx and RSP recompiler / interpreter do not affect the issue at all. Here is a HLE screenshot, to contrast with the LLE plugin screenshot above, same issue at the same exact spot:
http://ft.trillian.im/785abe041074fd64135ab3318aff1ec8767ab03d/6w1yMs9sC74LYm2iBIpprttwSnRqR.jpg

I have found only one fix (well two if you count switching to the interpreter):
Go into the RDB settings and uncheck "Start changed" from the re-compiler methods.
Whether you uncheck PI DMA, Protect Memory, or any of the other 4 techniques has no effect.

When CF is set to 3, I get a black screen after booting the game. It doesn't matter what GFX & RSP plugin I use. For some odd reason, the issue appeared somewhere between http://www.emucr.com/2015/01/project...-20150124.html and http://www.emucr.com/2015/01/project...-20150125.html

It seems to be some undefined behavior, since it works fine on theboy181's computer.

Having Glide64 for PJ64 read (and write!) configuration settings from the RDB is a major hassle. First, because it means I have to maintain the settings for Project64, the Jabo plugins and Glide64. It is not possible to separately update the RDB and Glide64 settings. Plus, most people use the offical Glide64 Final anyway, since the PJ64 version introduced some bugs. And it will probably be obsoleted in a few months when GLideN64 is released, which gives me even less insentive to update it's settings.

Could we make Glide64 for PJ64 use a separate configuration file? Maybe just clone Glide64 and change the name only?

Re-reading Gonetz's GLideN64 blog I noticed this bit:

Technically, emulation of CPU rendering is easy. Image to display is stored in RDRAM, its address is known. The image is just loaded as texture to video card and rendered as full screen rectangle. The problem is the same as with CPU based fb effects: graphics plugin does not know that CPU started rendering by itself, emulator does not notify the plugin about it. To be honest, plugin's specification has the function for such notification, but it almost never works. Thus, plugin can’t rely on emulator’s help.

It would be nice if the function to notify the graphics plugin that the CPU has begun writing to the color framebuffer was fixed. It would allow correct emulation of such instances (which currently relies on a hack), and frankly it's a bit embarrassing that Project64 doesn't have a fully correct implementation of Zilmar's specification.

And by the way, would it be hard to document the 1.7+ plugin specs (Audio 1.2, GFX 1.4, Input, 1.2, RSP 1.2)?

EDIT: It appears this is the function in the spec that needs fixing:

/******************************************************************
Function: ShowCFB
Purpose: Useally once Dlists are started being displayed, cfb is
ignored. This function tells the dll to start displaying
them again.
input: none
output: none
*******************************************************************/
EXPORT void CALL ShowCFB (void);

I guess this has been known about in the RDB file for quite a while.

But 1964 0.8.5, 0.9.9, 1.? support it just fine, so why can't we have a solution in Project64 sometime?

Also, unintended rhyming. ("file..while"; "fine..sometime"...idk lmao I swear I didn't mean that)

Legend of Zelda OOT 1.2

When using HATS RSP and HATS RDP and you press start to the menu, sometimes rainbow colors occur in the frame.

Neither Vigilante 8 game works with Advanced Block Linking enabled. (Enabling it will cause a freeze during level loading.) Also, disabling the frame limiter will result in the game's main menu not triggering correctly. The screen will be frozen just before the main menu until the frame limiter is enabled. A momentary pause, and then then the main menu appears. This appears to cause issues across all the major menus and loadscreens.

While testing Killer Instinct in Mupen 0.5 I noticed that the exact same LLE plugins I was using in PJ64 were outputting a lower resolution (320x240). Should be 640x480, and I believe its interlaced. This is odd that it happens in this game and think this issue might be larger than this particular game.

I will send a pull request shortly to enable Glide64's debugger logging feature when building as Debug.

In the meantime, running the debug build of PJGlide64, I get reports of memory leaks with weird C++.

One is Config.cpp line 1116:
hostWindow = new wxWindow();
The other is Config.cpp line 1291:
hostWindow = new wxWindow();

Evidently the same thing--the only difference, one is in DllConfig, the other in DllAbout. If you run this plugin in debug mode and close out of Project64 with a normal exit, a debug message should tell you a memory leak occurred because you tried to configure the plugin or click the About button.

I was able to reproduce the findings of Ambient_Malice at this thread spot:
http://forum.pj64-emu.com/showthread.php?p=59953#post59953

I wasn't able to change RDB settings so far in a way that would fix it, and it apparently hasn't had the issues on 1964 0.8.5 interpreter or Mupen64Plus. So I will have to try testing older versions of this repository to see as of which commit may have broken this (unless the issue goes back further than GitHub itself >.< hopefully not).

(This issue assumes all default Jabo plugins.)

The speech in 007 - The World is not Enough is quite a PITA. No settings seem to provide perfect
speech + framerate.
#1-With the recently introduced default of Sync Using Audio ON, Fixed Audio Timing OFF, the game runs at a steady 30 DL/s without audio crackling, but the speech sounds garbled like in PJ64 1.6.
#2-With Sync Using Audio OFF, Fixed Audio Timing ON, the game runs at a steady 30 DL/s with correct speech, but the audio goes slightly fast and crackles. This was default PJ64 1.7 setting.
#3-With both Sync Using Audio and Fixed Audio Timing ON (a), or with the above (#2) setting + Sync Game to Audio ON in the sound plugin (b), the audio and speech sound correct, but the game runs at 28-29 DL/s.
#4-Let's not even talk about both Sync Using Audio and Fixed Audio Timing OFF. Vi Refresh 2200 also royally screws the audio.
#3 seems to be closest to the real N64. We should pick one of the poisons above and edit the settings in the RDB to reflect that choice. Also worth noting is that settings #1 and #3a allow for PFR* , while #2 and #3b allow the user to easily pick their poison via Sync Game to Audio, but do not allow PFR*.

*PFR: Perfect Forwards Reproducibility, a term I just coined for the problem of being able to replicate the exact same game behavior from a set of key strokes, for online sync and TAS recording support.

(Please ignore the links to other issues that were created automatically.)

Unhandled CicChip(-1) in First DMA error in pj64 when trying to load Aleck64 ROMS

Some ROMS will load but into test menu (Eleven Beat). Missing RDB entry for proper testing too.

When I right-click a game in the browse window & choose game settings this occurs error-window

ScreenHertz= XX doesn't work any longer in the RDB

I like to use this to OC the VI's for testing purposes. Was this change on purpose? Can we please add it back in?

Thanks

Resident Evil 2 currently requires a RSP interpreter plugin.

RAM CFB capture when using RSP 1.7.0.9 "recompiler":

CFB capture with properly done RSP:

First reported by angrylion to be a (albeit entirely different, and unrelated to this) bug with my RSP plugin.
The RSP interpreter/recompiler plugin with Project64 also has a different LLE graphics bug here.

With the Project64 RSP plugin, it is missing some triangles in the enemy's body:

With my RSP plugin (also ziggy's port of MAME LLE), the result is correct:

To the best of our knowledge this is not a CPU core/VR4300 issue and is only a RSP issue.
I am self-assigning myself this one and plan to investigate it myself.

Here is the Project64 saved state that angrylion sent me via e-mail all those months ago just in case somebody else feels like looking at it:
https://dl.dropboxusercontent.com/u/16494013/n64/Quake%2064%20%28U%29.pj.zip

The pause menu in Zelda OoT takes several seconds to come up, and sometimes it will just freeze the game. Counter Factor=1 mitigates this to some degree. There is a GameShark code in the RDB which "fixes" this issue, but it will break the GLideN64 plugin's framebuffer emulation: https://gliden64.blogspot.com/2013/11/frame-buffer-emulation-part-i.html

Thus, we need a proper fix in the emulator so as to at least prevent the freezing.

Error   1   error RC1015: cannot open include file 'afxres.h'.  C:\Users\no\project64\Source\RSP\RSP.rc 10
Error   2   error RC1015: cannot open include file 'afxres.h'.  C:\Users\no\project64\Source\Glide64\Glide64.rc 10
Error   3   error RC1015: cannot open include file 'afxres.h'.  C:\Users\no\project64\Source\Project64\User Interface\UI Resources.rc   10
Error   4   error MSB6006: "cmd.exe" exited with code 2.    C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets  170

1>------ Build started: Project: Glide64, Configuration: Release Win32 ------
2>------ Build started: Project: RSP, Configuration: Release Win32 ------
2>RSP.rc(10): fatal error RC1015: cannot open include file 'afxres.h'.
2>  
1>Glide64.rc(10): fatal error RC1015: cannot open include file 'afxres.h'.
1>  
3>------ Build started: Project: Project64, Configuration: Release Win32 ------
3>User Interface\UI Resources.rc(10): fatal error RC1015: cannot open include file 'afxres.h'.
3>  
4>------ Build started: Project: Project64Setup, Configuration: Release Win32 ------
4>  Performing Custom Build Tools
4>  Inno Setup 5 Command-Line Compiler
4>  Copyright (C) 1997-2011 Jordan Russell. All rights reserved.
4>  Portions Copyright (C) 2000-2011 Martijn Laan
4>  Inno Setup Preprocessor
4>  Copyright (C) 2001-2004 Alex Yackimoff. All rights reserved.
4>  
4>  Compiler engine version: Inno Setup 5.4.3 (u)
4>  
4>  [ISPP] Preprocessing.
4>  [ISPP] Preprocessed.
4>  
4>  Parsing [Setup] section, line 7
4>  Parsing [Setup] section, line 8
4>  Parsing [Setup] section, line 9
4>  Parsing [Setup] section, line 10
4>  Parsing [Setup] section, line 11
4>  Parsing [Setup] section, line 12
4>  Parsing [Setup] section, line 13
4>  Parsing [Setup] section, line 14
4>  Parsing [Setup] section, line 15
4>  Parsing [Setup] section, line 16
4>  Parsing [Setup] section, line 17
4>  Parsing [Setup] section, line 18
4>  Parsing [Setup] section, line 19
4>  Parsing [Setup] section, line 20
4>  Error in C:\Users\no\project64\Source\Installer\Installer.iss: The [Setup] section must include an AppVersion or AppVerName directive.
4>  Compile aborted.
4>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(170,5): error MSB6006: "cmd.exe" exited with code 2.
========== Build: 0 succeeded, 4 failed, 12 up-to-date, 0 skipped ==========

So I got 12 to succeed; 4 of the modules fail to build.
I know that the RSP plugin and Project64.exe failed to build, PJGlide64 too I guess.

Here's the interesting thing: It compiles just fine at my desktop computer at home, on MSVC 2013. It's only here, on my laptop, that it fails to compile and find afxres.h. I wonder if it's something particular to my installation of Community Edition of VS2013.

I'll try to solve this issue myself when I get home to figure out why it works on my home desktop copy, unless somebody else has some hints to interject for me which might help.

Here's a screenshot of the intro with RSP interpreter, using HatCat's fork of Angrylion's plugin for graphics.

Here's what it looks like in a match, also using zilmar's RSP interpreter.

When enabling both of these, it causes problems in certain games. The odd thing is that it may be unnoticeable on certain RSPs, but if you debug it, you can see that there's a problem.

The best way to reproduce the issue, is to enable RSP_SAFE_DMA, run the emulator in a debugger (MSVC), and set a breakpoint at the beginning of the loop in SP_DMA_WRITE. Use LLE graphics, and run Jet Force Gemini. The reason I suggest enabling RSP_SAFE_DMA is simply because it's more of a hassle to debug memcpy, rather than a generic for loop.

Basically, while stepping through instructions in MSVC, an error will happen after writing to the destination.

If you would rather not / can't debug with MSVC, then you can just do something like
__try {
SP_DMA_WRITE();
}__except (EXCEPTION_EXECUTE_HANDLER) {
DisplayError("Problem with SP_DMA_WRITE");
}
inside of RSP_Cop0_MT and it will always expose the problem.

Also, Super Smash Bros does not work with Angrylion's or Shunyuan's plugin, with protect memory and cpu recompiler enabled. Fortunately, I don't think that game needs Protect Memory, but Protect Memory might be the default setting for Super Smash Bros. I can't remember ;/ .

Supercross 2000. Interesting game. Runs at 620x480, which I find to be very interesting since "true-ish" 480i resolution is extremely rare.

Anyway, attempting to boot the game in PJ64 in LLE mode results in the following error.

MTC0
CMD_START

In 1964 LLE, this error does not display, but the game freezes upon reaching the main menu. mupen64plus runs it fine.

Thought this might be relevant to the Indiana Jones and the Infernal Machine problems.

I have n-rage 2.3 compiling in the current source branch. I would like to look at replacing jabo's input plugin with the n-rage one.

Is there any changes that are needed? What Changes would be good to have in it?

In jabo's one I do like the picture of the controller and the setup button that goes through all the buttons in a row.
There is also a closer linking of the two so it goes through the pj64 settings config similar to what I did for glide so all user settings are in the cfg file.

is there anything else that should/would be good to be done with it?

An instruction such as:

SSV     $v21[6], -24($23)

... is incorrectly getting disassembled with a hexadecimal offset:

(Saying "T7" instead of "$23" is fine though if you declare an assembly language macro to name it T7.)

FFFFFFE8_16 is not a valid RSP offset, either as a 16-bit for primary ops or a 7-bit offset for SWC2.

Valid range of offsets is (-64 <= offset < +64).

If we had wanted to write this as hex you would say (-0x40 <= offset < +0x40), but either one is still much easier to type in something like Windows Calculator than "FFFFFFE8" if you're just trying to add the addresses. (Typing "- 24" decimal isn't really any less convenient either, and decimal is the standard base for arithmetic analysis.)

The current "User Manual" is from Project64 1.6, and inside the document it says this:

About this file: This document only covers official Project64 releases, and was written by Smiff for the official Project64 v1.5 release. Any other versions of Project64 available may differ in any number of ways, and this help file may not apply - please refer to the documentation included with them.

Working with the current RDB, there is a lot of stuff that didn't exist back then (and also a lot of stuff that no longer exists). To cite a few:

[Microcode Identifiers] - This section of the RDB has never been explained, and currently all it's contents are commented out.
32bit= - I get this is an optimization, to not have to deal with 64-bit whatever on 32-bit computers. However I wonder what kind of effects should I expect from this, if it doesn't work will it obviously crash or can it cause obscure errors deep into the game? Also honestly, since most computers are currently 64-bit, wouldn't it be better to deal with the 64-bit stuff natively?
The whole Recompiler settings tab: Judging by CXD's struggle here: #22 , this definitely needs explaining. For example, how is TLB Unmapping supposed to be used compared to the standard TLB option? And what settings can be used in conjunction with the Interpreter, Physical/Virtual Lookup Table (and what does that option itself do?)? How do the current SMCM options work? Etc.

And also, the .h files in the Plugin Specs folder should be updated to the current plugin specs.

All of this would allow more efficient configuration of the emulator, and make it easier for me and others in the future to use and maintain it.

I compiled the latest Setup build last night and when I tried to open PJ64 the GUI wouldn't load. I moved the older PJ64.exe to the folder and ran it. after that the new build loaded fine.

I think there must be a regression in the new PJ64.exe and it inst crating some config files correctly.

Enabling Instruction Re-ordering in RSP recompiler caused graphical issues in Yoshi's Story, SD Hiryuu, and Quake II. Simply disabling the option fixes the problem.

I haven't really debugged to figure out what causes these bugs, since I honestly don't see a point in reordering instructions, when the recompiler doesn't use register caching.

Is there a real benefit to instruction reordering, while there's no register caching? If so, then I will try seeing if I can fix it. Otherwise, I'll just continue to keep it disabled.