After the working Arkanoid title screen (which means VROM has been used so far) just as you go to play my emulator crashes with an error. Upon debugging it says that it tried to access VRAM. Nowhere in the program is VideoRAM being set to 1 by mistake and if I try to manually trap the illegal access with...

"Happens 80% of the time" usually means some kind of concurrency problem. It's impossible to say based on the information that you gave. Because you talked about PCH files, I assume you use Visual Studio, so why don't you debug from the point where the crash happened? (Look at the disassembly if you have to.)

"Happens 80% of the time" usually means some kind of concurrency problem. It's impossible to say based on the information that you gave. Because you talked about PCH files, I assume you use Visual Studio, so why don't you debug from the point where the crash happened? (Look at the disassembly if you have to.)

I have deleted my PCH once already and that helped but it came back after a few tries. Whats more it only seems to happen about 80% of the time. Just WTF is going on?

Check your CHR bank switching code. Make sure you're never selecting VROM banks other than 0 or 1. I'm assuming you mean Arkanoid (U).nes. When I run that it is CNROM and has 2 CHR banks. Make sure that no matter what is written to $8000 - $FFFF you only use the number of bits necessary to select between the actual number of banks present in the image.

I looked at my CNROM implementation and I don't mask any bits so that implies that the correct values are written to $8000 - $FFFF at least by Arkanoid (U).nes [which works for me].

Code does not modify itself unless explicitly told to. You are probably a victim of the common buffer overflow (bufferus overflowis). C++ provides many abstractions to prevent buffer overflows, for instance std::vector<> or std::array<>.

For issues like these you might want to make use of utilities like Valgrind or Electric-Fence in order to find potential error sources faster.

Quote:

Upon debugging it says that it tried to access VRAM.

So it actually halted execution and entered the VS debugger? In that case you should be able to see what value VideoRAM has when execution halts. Does it look valid (you seem to be writing only 0 and 1 to it, so then it should never contain anything else)? If it doesn't you might be having problems with buffer overflows as Jsolo suggested.Another potential error source would be concurrency, though I have no idea how you've structured your emulator, and it's impossible to say from the snippets of code pasted here. If you've got dependencies to a global variable in more than one thread and at least one of those threads is modifying the variable you'll typically want to make those pieces of code mutually exclusive from one another.

Quote:

Nowhere in the program is VideoRAM being set to 1 by mistake

At which points do you set it to 1 on purpose though? Might that have happened sometime earlier during execution, and now you're looking at an old value of VideoRAM while VRAM has been freed?

Quote:

are you sure it's not just uninitialized ... memory?

Only local variables (i.e. those allocated on the stack) are truly uninitialized in C++. A global or local static variable should contain a zero value if not explictly initialized.

I was under the impression that the use of global and static variables was "considered harmful" nowadays. Global variables make it harder to turn an object into one that supports multiple instances (such as the parallel emulators that power nemulator's Wii Menu-style game chooser). Global variables also interfere with multithreading, especially now that computers have multiple cores, and cores in low-cost or low-power CPUs such as Atom and PPE have simultaneous multithreading to hide the negative effects of in-order execution.

I was under the impression that the use of global and static variables was "considered harmful" nowadays. ... Global variables also interfere with multithreading, especially now that computers have multiple cores, and cores in low-cost or low-power CPUs such as Atom and PPE have simultaneous multithreading to hide the negative effects of in-order execution.

Just a quick update for you guys. As I have fixed elements of broken mapping/mirroring/timing etc. the whole thing has gotten a lot better. I think that maybe before the PPU was getting into a loop that it couldn't get out of or something.

Who is online

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum