nesdev.com

I can build the .exe, problem is when I run it I get "Fatal error: unable to locate any mapper DLLs!". And this is despite having them in the mappers folder like usual. I've tried putting them in the exe's folder, I guess I could try the system path next but that sounds a little desperate. Anyone have any idea what could cause this?

I'm compiling Nintendulator with Visual Studio Express 2012. No errors, just warnings.

one of these:
Warning 4 warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/SAFESEH' specification C:\proj\c\nintendulator\project\APU.obj in_nintendulator

and 191 similar this (for strcopy, sprintf, fopen, etc.):
Warning 1 warning C4996: 'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. c:\proj\c\nintendulator\src\in_nintendulator.cpp 132 1 in_nintendulator

I don't have that problem in my NDX build. I have a Mappers folder in the Release and Debug folders (where the .exe is).

You might be able to figure out the cause by stepping through the Init() function in MapperInterface.cpp.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

LNK4075: ignoring '/EDITANDCONTINUE' due to '/SAFESEH' specification is explained here: https://msdn.microsoft.com/en-us/library/9a89h429.aspx (be sure to change the pulldown near the top that says "Visual Studio 2015" to "Visual Studio 2012").

In other words: check the linker configuration for the project and see if /SAFESEH is set. If so, you can get rid of the warning doing /SAFESEH:NO, or (from what I can determine) you have to register a safe exception handler within the code itself using .safesh or other methodologies. Exception handlers... *sighing, shaking head*

C4996: 'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead is self-explanatory: several string-related functions in the CRT are considered deprecated, but cannot be explicitly rejected for backwards-compatibility reasons. strcpy() in this case doesn't have the capability/ability to check for sufficient space in the destination when copying from the source, i.e. provides a potential buffer overflow vector. strcpy_s() (link) rectifies this through use of an argument that specifies the maximum length to copy and does some additional checking of ranges/sizes. The _s suffix is supposed to indicate "secure". strncpy() (which is what I'd have used) doesn't alleviate this on Windows either. The solution is to use strcpy_s() and for the numberOfElements field, determine what the size should be (through review of the code; they could be hard-coded values, or if for literal string space you might be able to use sizeof() or strlen() in some cases).

The reason you might see these while thefox doesn't could be explained in compiler version differences (ex. one of you using a different compiler suite than the other), or possibly some global linker settings (for the former issue) or compiler flags.

I'll just throw in here that concern/care about warnings is *highly* justified. Some of the worst advice I was ever given when I was learning C back in the late 90s was "ah, just ignore them" (warnings) -- and I'm very glad, still to this day, that I ignored that advice. (Please do not let this paragraph become a focal point of the thread.)

Neither of those warnings could cause the problems described by Memblers, they are not really worth focusing on. Anyway, as was said, you can get rid of the first one by disabling "safe SEH" in the project properties, and the second one by adding _CRT_SECURE_NO_WARNINGS in the compiler's preprocessor definitions (again, in project properties).

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

I guess I should mention that I'm running Win7 64-bit, if that matters. Maybe I'll could try finding an older version of the compiler or something.

I'm not sure where the error is yet, but at least I did find the check that it's failing:
in MapperInterface.cpp line 489:

If I run it to that point, and view inside ThisDLL->DI it says <Unable to read memory> for all the fields. Other parts in ThisDLL look OK I guess, the filename is there, so it's definitely locating the files, just not using it. Fails on the first one it tries to load.

Try tracing into LoadDLL. Maybe it's a version mismatch like the DbgOut is suggesting.

EDIT: Stepping into the DLL might not be able to show you the source if you haven't compiled the mappers in the same solution. You might want to check the value of CurrentMapperInterface in interface.h of your mapper, and the same in MapperInterface.h of Nintendulator. They should match.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

Ah yeah, that's the problem! CurrentMapperInterface in my copy of Nintendulator is 0x30007, and in the mappers is 0x30008. Whoops.

Probably is about time I come out of the stone age and start using an IDE instead of using a text editor and printf style debugging, heh. Now I can get to the interesting part.

It's 0x30008 in the "Latest unstable build" (from Nintendulator website), so you could use that one. ("Unstable" is bit of an exaggeration.)

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

I too have a problem compiling, but I get a different error. I am told the linker can't open "dinput.lib". I don't believe they exist in the ZIP file. Doing a Google, I get a lot of possibilities for download. Can anyone recommend the proper file? Where in the source code project should I put it? Or do I have to do something inside VS2012 (config, project setup, references, etc?).

(If I could get this to compile and run, I could debug the question "where does the Debug/Dump function put it's files?", which you may find floating around here somewhere! )

Thanks
Charlie

You must install the DirectX SDK for the compiler you're using, which includes configuring its Include/Library folders within "Property Manager" -> "Microsoft.Cpp.[Win32|x64].user" -> "VC++ Directories".

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.

Thanks, I now can compile and run! Took a bit of time to get the right VS with the right WIN with the right DIRECTX. (FYI, I'm using VS2013 premium on Win7 Professional SP1, DirectX 11)

However, I immediately ran across a mapper problem. It couldn't find the mapper file.

Although I have minimal practice in cpp, I managed to decode the source flow to determine that the app wants the mapper file in the "...msvc71\Debug (ANSI)" directory; so,....I put it there!

But now I get the error message that says "mapper interface incompatible". This seems kind of strange, as it is the same mapper file that is used by the executable. So, either I have a mapper app mismatch to the source code, or a source code mismatch to the mapper app...or there's dumb something I'm missing.

Any ideas? (Just point me, I'll do the work!)

Thanks
Charlie

RESET..RESET
It appears that I had downloaded two versions of Nintendulator..the old one was the one that compiled and gave the mapper error. The newer one, which presumably is mapper compatible, is the one that won't compile.

So, I need to re-work this problem as per your previous help. I'm jumping on that ASAP.

If (WHEN) I have a problem with it again, you all will be sure to know it!

Thanks
Charlie

As promised, here's my latest.

I dl'ed the source for the new unstable version, compiled fine after upgrading to VS2012. Ran, but gave an error that the Mappers were of wrong version. So, dl'ed the source for the new mappers, compiles great. Copied the DLL's over to the source proj and away we go!!

Thanks all for you patience, and for the awesome Nintendulator itself.

Charlie