I found an old list of accurate NES emulators from back in 2012. Well, 3 years later, what emulator is the most accurate? Is it still puNES?
I'm asking because I've got a simple demo that acts differently on different emulators - the demo just displays some static white on green BG text and plays a song using Famitone 2. It has MMC5 enabled and 512k of PRG-ROM but isn't using any of that yet. In puNES, my demo works perfectly fine, in Nintendulator it looks like it has a corrupt nametable and the music doesn't play, and in NESICIDE the music plays fine but the screen is solid white.
While puNES is still generally accepted to be "the most" accurate, since you're seeing significantly different behavior between puNES, Nintendulator, and Nestopia, you will probably have to test on hardware to determine which is actually correct.
In the mean time, to eliminate one variable, I'd try making a (temporary) test build that's something simpler than MMC5; perhaps MMC3, FME7, or mapper 82.
The obvious question is if you are initializing all of the MMC5's registers properly. There are a lot of them and I don't think anyone has written a test for the MMC5 power up state so that wouldn't be included in the accuracy metric.
Even if what you have does work on the real hardware (or on "the most accurate emulator", if there even is such an absolute title), it's worth checking out why it isn't working on some emulators. The demo isn't anything out of this world that relies on super accurate emulation, it's just a static screen with music, something that should work on any emulator. It's probably an initialization issue, and fixing it will make your program overall more stable, which is always good.
I always follow this rule when coding NES stuff: if the program isn't doing anything out of the ordinary that exploits obscure behaviors and isn't extremely timing sensitive, it should work on any decent emulator. If it doesn't, I'm probably doing something wrong, or at the very least not as safely as I could be.
Right. I improved the situation, I had moved my startup code to the very last PRG-ROM bank (since as I was told that's the default bank MMC5 has loaded), but I missed the ROM I was reading the text to display from - that text was still on the very first bank. Odd that puNES worked with that, but once I fixed it, that made it so both puNES and Nintendulator now run the demo correctly. Now I gotta keep playing around to see if I can get Nesicide and FCEUx to run the demo (especially Nesicide, I'm using that as my dev tool).
Of course, once I get the basic demo working on all these emulators and start playing around with special features like the scanline IRQ, the usable emulators may dwindle again...
Has anybody tried the Retron 5? It pulls the ROM off of the cart. You still need the cart..so I guess it kind of qualifies as emulation...
I'm pretty sure the Retron5 is just using the FCEUX source for emulating NES games....
GameFrenzyUSA wrote:
I guess it kind of qualifies as emulation...
You can stop guessing. =) Yes, it just dumps the ROM and runs it on an emulator. Apparently this means that homebrews don't work on it unless they're explicitly added to the database of known games, so the Retron 5 know how to dump them.
tokumaru wrote:
Apparently this means that homebrews don't work on it unless they're explicitly added to the database of known games, so the Retron 5 know how to dump them.
Or the homebrew is specifically doctored to produce the same checksum as one of the existing games in the database (I believe it uses CRC-32).
For unknown ROMs, why can't the Retron 5 just probe the mirroring registers to see which known mapper is most likely? Or is it just engineering incompetence?
Probabilistic algorithms fail unpredictably... And it wouldn't help for modern multicarts anyway.
But the developer might appreciate being sent an autodetection algorithm. (Maybe. I think it's worth a shot, anyway.)
tepples wrote:
...is it just engineering incompetence?
This is awfully judgemental of someone that at worst just has different priorities than you do.
lidnariq wrote:
But the developer might appreciate being sent an autodetection algorithm.
My
multi-mapper test ROM uses the method taught to me by Paul of InfiniteNESLives.com. For each mapper that has mirroring control (common ASICs and a few discretes such as AOROM and
Holy Diver), write to its mirroring ports, and see what value is put on A10 when reading $2000, $2400, $2800, and $2C00. If the mirroring behaves as expected for a particular mapper, dump and emulate it as that mapper.
If mirroring is fixed, and it's not one of the known oddball games, then it's probably either a GNROM subset (such as NROM or CNROM) or a Color Dreams subset (such as BNROM or UNROM, which can be emulated as an oversize BNROM if overdumped). My test ROM cheats by having the bank number at a predefined location in each PRG bank, but the loader can still dump other PRG banks to see where it's CCCCPPPP (Color Dreams, BNROM, UNROM) or PPPPCCCC (GNROM, MHROM, CNROM).
As for engineering priorities, your sense of priorities might change once you have to issue refunds. "I bought a copy of
Lizard and it won't even play on my Retron 5. What gives?"
lidnariq wrote:
But the developer might appreciate being sent an autodetection algorithm. (Maybe. I think it's worth a shot, anyway.)
The certainly might appreciate it, but they definitely don't deserve it.
tepples wrote:
As for engineering priorities, your sense of priorities might change once you have to issue refunds. "I bought a copy of Lizard and it won't even play on my Retron 5. What gives?"
So... are you saying that I'm incompetent?
Honestly, I think much better than a detection algorithm would be UI that lets a user select a mapper for the unrecognized cart (or override for a recognized cart), and add it to the database stored by the machine.
The current system seems to be manual intervention via support? Many homebrew games are already in the database at this point.
I restored my demo to the basics, and got it working on all emulators I tried...except FCEUx for some reason, that just displayed a white screen. I restored the MMC5 stuff and got it working on everything else except for Nesicide. Now I implemented some MMC5 HBlank IRQ effects, and it's working in puNES, Nintendulator, and Nestopia. Sheesh homebrew is tricky on emulators! Any ideas of other emulators I should try it on?
Now I want to try it on a Kevtris FPGA box...
I don't see what your end goal is. Do you only care if it would work on real hardware, or are you actively trying to make this work on a reasonable number of emulators?
Because, sure, there might be other accurate emulators out there no one has listed yet. But... I don't see how naming those helps you. Say I can name two more. One works, one doesn't. Where does that leave you?
If you only care about hardware, you need to buy it or get a rom to someone who has it to test on. If you want to support more emulators, we can't help with that without seeing what the demo is actually doing. It might be the demo doing something wrong, not the emulators. And we have no way of knowing that.
My goal is to run the game on the
Retro VGS:
The game console uses an FPGA to act as various classic game systems, the guy making it said
in an interview that they are working with Kevtris to license his FPGA cores. I won't be getting one of those to test with anytime soon, so I figured if I make my game work on as accurate an emulator as possible, I'd be at a good place for when I am able to make the switch to the Retro VGS. You're right that no matter what I do, it might be different on that hardware, but if I had an emulator that wasn't working, that I knew for sure should run my demo, maybe I could fix that in my demo now before I get deep into the game and the MMC5 special features.
I understand I've set myself up for a really challenging situation, and raised the bar by choosing MMC5, but I do like a challenge, this is a fun project of the sort I've been wanting to do for a while, really brings me back into my GBC development days when I was just getting started in the game industry and teaching myself everything.
rainwarrior wrote:
tepples wrote:
As for engineering priorities, your sense of priorities might change once you have to issue refunds. "I bought a copy of Lizard and it won't even play on my Retron 5. What gives?"
So... are you saying that I'm incompetent?
Certainly not. I'm saying Hyperkin is lazy for failing to provide for some automatic means to work with the continued release of games such as yours, such as the autodetection that I outlined or the manual mapper input that you outlined. I was pointing out to what extent Hyperkin's engineering priorities would interact with yours.
Back to main topic:
Perhaps the glitchiness in the sinusoidal scrolling effect on puNES is related to the fact that changes to fine scroll (bits 2-0 of first write to $2005) take effect immediately, while changes to the rest happen only on the next scanline if you're using only $2005 updates. The $2006-$2005-$2005-$2006 sequence always takes effect immediately. At what horizontal position are you making these writes?
The Retro VGS case shape was borrowed from that of the Atari Jaguar. And like the Atari Jaguar, the AMD Jaguar processor in the PlayStation 4 and Xbox One is 64-bit DO THE MATH.
Dreamwriter wrote:
Right. I improved the situation, I had moved my startup code to the very last PRG-ROM bank (since as I was told that's the default bank MMC5 has loaded), but I missed the ROM I was reading the text to display from - that text was still on the very first bank. Odd that puNES worked with that, but once I fixed it, that made it so both puNES and Nintendulator now run the demo correctly. Now I gotta keep playing around to see if I can get Nesicide and FCEUx to run the demo (especially Nesicide, I'm using that as my dev tool).
Of course, once I get the basic demo working on all these emulators and start playing around with special features like the scanline IRQ, the usable emulators may dwindle again...
Yeah my MMC5 is likely not very good. If you want to help fix it up.
I have a question - am I correct in the statement that the MMC5 extended attribute mode, when it comes to palettes, is really just a convenience thing so you don't have to use math to figure out which bits of which byte to set for the BG tile you want? I originally thought the NES only let you set the BG palette for any 2x2 tile square, but it looks like I was wrong, within the attribute byte for the 2x2 square you can set each individual tile to a palette using every two bits of the byte.
cpow wrote:
Yeah my MMC5 is likely not very good. If you want to help fix it up.
I've tried to figure it out, but I got stumped, so I don't think I'll be able to help much. I think I'm learning how to use the MMC5 pretty well (now that I'm setting it all up my "game" now works in FCEUx), and from what I can tell, Nesicide is loading palettes correctly, the extended attribute table data, the nametable data, and which nametable to display. It might be the CHR data or CHR bank that's different, and I might be setting that up wrong, I only have one 8k bank (the one from the Hello World template); I'm setting the iNES header to 1 8k CHR bank and telling MMC5 to use 8k CHR banks and use bank 0. Nesicide displays a white screen when I try to display the text (it's not crashing, it's just not displaying right).
Dreamwriter wrote:
I have a question - am I correct in the statement that the MMC5 extended attribute mode, when it comes to palettes, is really just a convenience thing so you don't have to use math to figure out which bits of which byte to set for the BG tile you want? I originally thought the NES only let you set the BG palette for any 2x2 tile square, but it looks like I was wrong, within the attribute byte for the 2x2 square you can set each individual tile to a palette using every two bits of the byte.
You're off by a factor of two. Each byte in the attribute table describes the palette used by 16 tiles, not 4: each 2 bits in the attribute table describes the palette used by a 4 tiles in a 2x2 square
Aha, gottit, thanks. Makes me glad I'm using the MMC5
Dreamwriter wrote:
cpow wrote:
Yeah my MMC5 is likely not very good. If you want to help fix it up.
I've tried to figure it out, but I got stumped...
I'll have to spend some time to take a look at my MMC5.
cpow wrote:
I'll have to spend some time to take a look at my MMC5.
If it'll help you I've attached my Nesicide project to this post so you can see what I'm doing - it's all still simple since I've barely started it and am still teaching myself NES/6502 programming, so should be easy to follow (Main.s sets everything up and then passes control to Title.s). I've removed the hblank warping from the title since that was just an experiment to make sure I could do it.
Nestopia UE 1.46 and puNES have an issue in Castlevania III where the whole scanline flickers where the status window is separated from the main action screen in vertical scrolling stages. Nintendulator and real hardware only have it flicker on the left side of the screen. Could that be related?
I think I figured out the problem with Nesicide - it doesn't seem to be accessing the correct CHR bank for each tile using MMC5's extended attribute table. My game is currently using 4k bank 1 for all chars on the screen, but Nesicide is showing 4k bank 0 (I put actual art into bank 0, so now I'm seeing that instead of a blank screen). This is where you store %ppbbbbbb in EX_RAM at $5C00, where %pp is the palette for the tile and %bbbbbb is the bank to grab the tile from.
Dreamwriter wrote:
I think I figured out the problem with Nesicide - it doesn't seem to be accessing the correct CHR bank for each tile using MMC5's extended attribute table. My game is currently using 4k bank 1 for all chars on the screen, but Nesicide is showing 4k bank 0 (I put actual art into bank 0, so now I'm seeing that instead of a blank screen). This is where you store %ppbbbbbb in EX_RAM at $5C00, where %pp is the palette for the tile and %bbbbbb is the bank to grab the tile from.
Yes. NESICIDE's MMC5 is unfinished so likely crap. Sorry for the confusion!
I do have your demo project you sent, though. Right? Or am I confusing threads?
If you want to send an update I'll take another look. I'm in the midst of generating a DMG for OSX for another user, and will likely be providing a Windows build also.