nesdev.com

Does anyone know if the RetroUSB AVS reproduces the NES's hardware quirks, e.g. the DMC/gamepad conflict? I'm looking into purchasing a hardware NES for dev-testing purposes, and the AVS seems like a more dependable option than an eBay-sourced original, assuming it can do what I need it to do.

It contains a FPGA programmed to replicate behaviour. I don't know how exact the FPGA in the AVS replicates everything, so i'm just saying this: there are probably some obscure behaviours in the original which aren't even fully charted yet. This is a theoretical and (to be fair) small problem which you nevertheless can avoid by getting original hardware.

_________________
http://www.frankengraphics.com - personal NES blog

If you know of a 100% reliable way to test for such quirks, either in a game or a test ROM, let me know and I'll be happy to try it on my AVS.

People are still discovering quirks in the original hardware every once in a while, so I think it's safe to say that the AVS can't possibly work 100% like the original console. Until someone decides to replicate CPU and PPU dies at the lowest level, copying their exact transistor layouts, we're stuck with "close-but-not-quite" replications of the original logic.

If the software you're developing doesn't make use of intricate raster effects or pushes the boundaries of the console's design too much, it should be safe to use accurate emulators and/or an AVS during development, and have someone else test the final build on original hardware for you just to be sure everything is OK. But if you're doing complex effects that rely on very precise timing and/or manipulation of hardware registers at sensitive times, you definitely should be using the original console for testing.

Looks like I'll have to stick with the real deal to ensure flexibility and compatibility, then. I'd kind of suspected as much, but I'm glad (though also slightly disappointed) to have it confirmed. Thanks for your help!

The other thing to think about is what % of the people you want to sell this to will still be using an original NES to play the game vs some other clone (retron, AVS, etc).

The original console is always the common ground though, since all others are modeled after it. Even if all original Nintendo units fail, the original design is still the reference for all other implementations. If different developers start to cater to the inaccuracies of this or that clone, the standard is lost.

Given how many emulators don't implement the DPCM glitch without compatibility problems, and that the PAL revision doesn't have the glitch, it might have been a sensible idea for the RetroAVS not to implement it (depending on point of view / implementation details).

As far as test ROMs, maybe these ones will do?
http://forums.nesdev.com/viewtopic.php?p=63998#p63998

I can understand why one might choose not to implement the DPCM glitch, but if programmers suddenly started ignoring this glitch while still marketing their products as "NES games", that could be a problem for anyone still using the original console.

Not that this kind of problem is unheard of, even back in the commercial days of the NES. For example, there are a few games reading from $2004 for timing reasons, but IIRC, early PPUs didn't support $2004 reads. The Master System port of Earthworm Jim apparently has problems with its status bar, because not all consoles support scaled sprites, unlike the Game Gear, where the original game's status bar worked fine.

In addition to the glitch test that rainwarrior linked, this OAM-synchronized controller read test looks like it could be a good way to see how cycle-accurate the AVS is:
viewtopic.php?f=2&t=14319&start=15#p172188

Here's a similar yet different question:

I test on a PAL unit, and am looking to get a NTSC unit to cover most cases (for testing timing, cross-compability, palettes, and so on).
Except PAL not having the playback/controller bug, and maybe not AVS either, would it suffice to have an original PAL + AVS?

_________________
http://www.frankengraphics.com - personal NES blog

AVS is maybe fun for playing with, but for development I'd get real hardware just to be sure testing is reliable.
An AV-modded Famicom is perfect for this and probably cheaper than an NTSC NES. If you do you can also play around with the microphone.

I plan to get a PAL NES again (our old one was thrown in the garbage by my sister ) at some point just to test PAL compatibility. But they are so darn expensive nowdays! They used to be so cheap.

I say buy an AVS if you wanna own an AVS (I really want one myself, but there's no way I can pay what it'd cost to import it), but there are no guarantees that it'll make a good development tool. Timing can be tested in a bunch of accurate emulators, an emulator with an NTSC filter will probably be much more helpful with palettes than the AVS, and I have no idea what you mean by cross-compatibility. If you're looking for an excuse to buy an AVS, I don't think this is it.

The AVS is targeted to players, not developers, so I'm sure that accuracy was a concern when creating it only up to a certain point. For example, I've been told that bunnyboy deliberately decided to omit the DPCM controller reading bug, because it doesn't bring any benefits to players. It's actually safer to not implement some quirks of the original hardware and be a little lenient than do a 1:1 copy.

EDIT: Apparently there's been no confirmation about the DPCM/controller bug.

OUCH.


I got my second one (including box and everything) for ~600 sek off tradera. That was two years ago, though.

Right now there's two superficially dysfunctional units up, one that probably only needs a good cotton wipe with cleaning gasolene or doctors' alcohol (don't know the proper english terms), or worst case, evening out the connector pins with flat-surface pliers, and one that probably needs a LED change or resoldering. You could save one of those from somebody installing a death grip connector.

Link 1 and 2.

EDIT1: Better than pliers, you can construct a small vice from two 1-2mm thick aluminium panels, two screws and nuts. That way youy can apply an even pressure. PM me if you want to discuss local material sources.

Alternately or additionally, having a cartridge pcb in the connector while clamping them gives evenly distributed support.

re tokumaru:
By cross-compability i mean writing code that may work on PAL but glitch out on NTSC (i'm a novice and don't know the proper way around many things yet, or have a comprehensive idea over making multi region ROMs)
But yeah, i want a NTSC unit for testing purposes, but at the same time an AVS because of its added features. I guess i didn't have that distinction clear.

_________________
http://www.frankengraphics.com - personal NES blog

Where were you told this? We speculated that it might not earlier in this thread but nobody posted a definitive answer / source about it.


If it doesn't rely on specific timings or the long vblank, most things on PAL NES will still work on NTSC NES. I tried to make a list of differences recently here.

If it runs on a PAL NES and also in NTSC mode on a relatively accurate emulator like Nintendulator, you're probably OK.