is there a test rom can test the access speed of cpu men amd ppu mem(the read and write speed)?
Well, do read/mem operations in a given period of time (like, NMI to NMI) while counting how many operations were performed.
NES doesn't use any waitstates, so it should be the same timing regardless of what the memory speed is.
The only way this could be meaningful is if you also overclock the NES.
byemu wrote:
is there a test rom can test the access speed of cpu men amd ppu mem(the read and write speed)?
Please describe what you mean by access speed in terms of a NES program running (please, nobody else answer my post, because this is for the benefit of the questioner).
blargg wrote:
byemu wrote:
is there a test rom can test the access speed of cpu men amd ppu mem(the read and write speed)?
Please describe what you mean by access speed in terms of a NES program running (please, nobody else answer my post, because this is for the benefit of the questioner).
Like this:
t0 = timeGetTime();
sta $0
lda $0
t1 = timeGetTime();
how to implement the resault t1-t0?
Are you looking for a way to calculate the elapsed time in CPU cycles used by a particular subroutine?
If you want coarse timing, you can put a counter in a timed interrupt or NMI, and just read the counter and see how many interrupts have passed.
If you want fine timing, under many conditions the timing for any particular piece of code will be fixed, so you can just calculate it yourself. You can read cycle counts from a debugger like FCEUX, for example. If it's a loop with a variable count, figure out the cycles for the loop and multiply it by the count to calculate the time.
Didn't someone implement cycle counting in an emulator? Like, you used some special registers to start and stop counting, or something like this.
Personally, I like the color emphasis method. As long as the code runs during the visible part of the frame (i.e. outside of VBlank) you can use color emphasis or the monochrome bit to see how long specific tasks are taking. For small things I just count cycles manually.
Yeah, I often have a debug mode that will make the PPU render greyscale when the frame is done updating to see visually how much free time I have left before the end of frame (i.e. bottom of screen).
I think there is a special build of Nintendulator which lets you insert cycle counters by writing a particular memory location that you can look at in the debugger view. They're not readable by the program, though... byemu was not clear whether he wants to use the timing as part of the program, or just wants to analyze the code.
To use the timing as part of the program, you need to either use the scanline-granularity counter of the MMC5 or make your own mapper. (Debugging features of an emulator are included in "your own mapper.")
Are you asking how a ROM can determine how many nanoseconds RAM/ROM takes to access? This is not possible without either having your program assume the clock speed of the NES (possibly knowing about PAL/NTSC), or adding external hardware that times things. Put another way, you can determine the answer to this without even running a program, since each memory cycle on an NTSC NES takes 1/1789772.7 of a second, and the number of cycles for instructions is documented.