My EPROM emulator works, and I have one modified board to use it with, currently. It's UNROM (mapper #2) with a maximum ROM size of 64KB. Mirroring is horizontal, but I'll probably change it to V later. (BTW, anyone have any ideas for some type of switches to put on the board to make selecting the mirroring easier?)

So what I propose to do, since NES dev hardware isn't easy to come by, is test any programs that are requested on my NTSC top-loader. Just post a link to the ROM here in this thread, or email it to me if you want the results to be confidential for whatever reason. ;)

I need to get a few things before I'll be able to test on other CHR-RAM based boards.

what did you use for the emulator?

are you using two seperate eprom emu's like the pocket romUlator?

http://xtronics.com/memory/romutator.htm

I bought it from someone, it emulates EPROMs from 8KB to 512KB.

Since I only have one though, I'll have to stick with boards that use CHR-RAM for now.

Could you mod CHR ROM based boards to take a huge CHR RAM instead so that the init code can load CHR and then jump into the main program?

Here's how to convert a cart with hardwired mirroring to use physically switchable mirroring:

Step 1: Cut the existing mirroring trace.

Step 2: Add a single-pole double-throw single-break switch, with the inputs on CHR A11 and A10 and the output on CIRAM A10. I can't tell which pins are those because I couldn't find any 72-pin cart pinouts on nesdev.parodius.com.

I'll find the rom eventually to post here, but I would love to see how some of the difficult to emulate roms work on a real box. For example, if you could take some photos of how NEStress actually works, so we know if what our emulators are doing is correct. Also things like the sprite0 test etc.

Yeah, that should be possible. I looked at the pinouts for SRAM compared to CHR-ROMs, and they are quite a bit different though. Should be doable with a little planning.

Thanks for the mirroring switch info, I'll try doing that. There is a cart-edge pinout BTW, it's in this doc:
http://nesdev.parodius.com/rom.txt

Yeah, I can take some pics. I'll try NEStress shortly.

NEStress results:

Doesn't always run when reset. Resetting it a second time usually works.

PPU test 1 has lots of tiles on the screen besides the 0123456789 patterns. I can take a pic when I find my camera. All tests OK there, and 'palette write/read' says DPjr. Score 11/11

PPU test 2, all error. Huh? Score 11/13

PPU test 3 OK. Score 12/14

CPU tests all OK. score 48/48

I/O test doesn't work for $4017 (returns zeros even with a controller plugged in) For $4016, returns $40 if button isn't pressed, $41 if it is, and reads 9-24 return $41 also.

I/O test also corrupts one of the background tiles (I'm guess it's because I'm using CHR-RAM instead of ROM).

Nevermind about the reset thing, other NROM programs are doing it too. Might be because I'm not initializing the mapper or someting.

Is it OK if I send a binary as a 24 KB NROM (mapper 0), or should I put in the CHR loader myself before sending it?

Either way is OK, I can split it and load the CHR myself without a problem.

It's right here.

http://nesdev.parodius.com/rom.txt

-
Be whatever the situation demands.

Why not trying out that 'fau' demo you made a while ago? It'd be interesting to see how well it does on the real thing with the timed PPU writes.

I did try the FAU demo, looks like it locks up though. It's probably a sprite #0 problem.

Well, it looks like I'm having some kind of sprite problems with my dev system. So the NEStress results relating to sprites probably aren't very trustworthy.

Sprite DMA seems to corrupt certain sprites, but I have yet to figure out why (it's happening in most commercial games, too).

Bananmos, using his EPROM emulator has had the same problem also. But only on an NTSC NES, it didn't happen on PAL. How can this be? Can the EPROM emulator somehow interfere with the DMA transfer, even though the DMA'd data is coming entirely from RAM?

I discussed these sprite problems with Memblers, who was having problems with my Tetramino game that I submitted for testing. I'll guess that because the CPU is reading DMA'd data from RAM and writing it to a PPU location, the data will show up on the CPU data bus visible on the cart edge, and the EPROM emulator can bus-conflict noise into the data stream. (Dang, I just verbed "bus conflict".)

Problems on NTSC that don't show up on PAL may result from the slightly longer clock cycle on PAL.

I'm actually on my way to also get a eprom emu soon I think. Found out that a swedish electronic mag. once had an article on building a 27c256 eprom emu. and they still sold the parts for building them on their homepage :D

sorry for misspellings

The FAU screen test works now, actually it doesn't use sprite #0, it's just timed by the NMI. Problem was I was copying and running code in WRAM, I relocated it to internal RAM and it mostly works.

I say mostly because sometimes the screen is stable, and sometimes not. After resetting the NES it'll run either way, seemingly at random. Very delicately timed code there, maybe a bit too much so.

It looks the same as on any of the good emulators, except for the artifacts on the right edge of the screen, they look somewhat different.

This could look pretty cool if it had some good gfx data to show.

Could you try out Escape from Pong? I know there are some things that I've been told are unlikely to work, but I'd like to know for sure.

http://hcs.freeshell.org/files/Escape_from_Pong.zip

It's in iNES format, UNROM. Thanks!

-hcs

It runs, but I can't see the ball.

Cool, can you see the paddle? I guess either my method for loading the pattern data or my sprite updating is suspect. I use $2003 and $2004 for updating sprites, but this is for both the paddle and the ball, so if the paddle appears I guess it must be the way in which I load the ball graphic.

-hcs

Yeah, the paddle was there and looked OK.

hi Memblers.. cool site.

I read the article you recommended for collision detection. In the comments greggman suggests buying something like this:

http://www.linkerworld.com/catalog/product_info.php/products_id/30

and using it to play the mckids rom on the GBA. So does that mean the GBA has an NES emulator on it? And if so, it must be the best NES emulator ever and probably a good tool to test NES games with?

Thank you. (:

- Matt

The GBA does not contain an NES emulator in BIOS.

There are two NES emulators for GBA: PocketNES and e-reader.

Nintendo's e-readerNES (for lack of a better name), contained in the BIOS of the e-reader for GBA, is used for NES games that come in a pack of e-reader cards. Several GameCube games have GBA extras, programs that get sent to a GBA system that's connected to the GameCube as a controller; many of these extras (called "multiboots" in the GBA development and GBA piracy communities) are packages containing a version of e-readerNES and a compressed NES ROM. It appears the Famicom Mini series, which includes GBA versions of NES games, also uses a version of e-readerNES. It's likely to be the most accurate NES emulator evar, but it apparently supports only [C]NROM natively, and I don't know whether anybody has got arbitrary NES ROMs to play in it.

Loopy's PocketNES, on the other hand, is a free NES emulator for GBA published under a copyleft license. (Yes, it's by the same Loopy who made the most accurate NES emulator of 1999.) It takes NES ROMs with a variety of mappers, even homebrew ROMs, in iNES format. However, its sound has more artifacts than that of e-readerNES because for speed reasons, instead of being emulated on the GBA's PCM channel (which would take more CPU), it's largely mapped onto the tone generators inherited from the monochrome Game Boy system, and anybody who understands the GB tone generators' limitations, such as the lack of soft envelopes, the 17.2% faster master clock period, and the different looped-noise waveform, would understand the slight audio corruption in some games.
http://www.pocketnes.org/

update:

I've got another board working with the EPROM emulator, it's SGROM. So now I can test MMC1 games up to 256kB that use VRAM (but not WRAM).

So the stuff I can test currently is:
NROM (24KB/40KB)
UNROM (64KB)
SGROM (256KB)