This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

AVS for NES dev?

AVS for NES dev?
by on (#186114)
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.
Re: AVS for NES dev?
by on (#186115)
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.
Re: AVS for NES dev?
by on (#186116)
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.
Re: AVS for NES dev?
by on (#186120)
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.
Re: AVS for NES dev?
by on (#186124)
WheelInventor wrote:
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.

tokumaru wrote:
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!
Re: AVS for NES dev?
by on (#186125)
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).
Re: AVS for NES dev?
by on (#186127)
hackfresh wrote:
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.
Re: AVS for NES dev?
by on (#186128)
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
Re: AVS for NES dev?
by on (#186136)
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.
Re: AVS for NES dev?
by on (#186143)
koitsu wrote:
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.


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
Re: AVS for NES dev?
by on (#187398)
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?
Re: AVS for NES dev?
by on (#187399)
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 :cry: ) at some point just to test PAL compatibility. But they are so darn expensive nowdays! They used to be so cheap.
Re: AVS for NES dev?
by on (#187400)
WheelInventor wrote:
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?

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.
Re: AVS for NES dev?
by on (#187401)
Quote:
I plan to get a PAL NES again (our old one was thrown in the garbage by my sister :cry: )

OUCH.

Quote:
But they are so darn expensive nowdays!

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. :P I guess i didn't have that distinction clear.
Re: AVS for NES dev?
by on (#187434)
tokumaru wrote:
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.

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

WheelInventor wrote:
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)

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.
Re: AVS for NES dev?
by on (#187438)
rainwarrior wrote:
Where were you told this? We speculated that it might not earlier in this thread but nobody posted a definitive answer / source about it.

Was it speculation? I could swear whoever said it was stating a fact. Sorry about that. I really don't want to propagate any misinformation.
Re: AVS for NES dev?
by on (#187447)
I also compiled a list of compatibility considerations for various types of Famicom and NES systems. Here is an excerpt from a PAL perspective (Rainwarrior already mentioned some though):

Famicom only
* The oldest Famicoms (before the RP2A03E CPU) doesn't support looped noise. These Famicoms aren't that common though so I wouldn't care about this too much (besides looped noise is a cool sound).
* Only late Famicoms (RP2C02G-0 PPU and later) has a readable $2004 so it's best not to rely on its readability (Codemaster games tend to read it though). These Famicoms are common and includes earlier Twin Famicoms.
* $4016.1 and $4017.1 needs to be read, and if they are not used for 4 player mode, they needs to be merged with controller I and II data so that Famicom users can use external controllers with your game.
* Start and Select is missing on controller II so the game shouldn't require those buttons. If $4017.1 is merged with controller II though, it will be possible to press Start and Select via an external controller.
* If you want four player mode, you'd need to read $4016.0 as controller I, $4017.0 as controller II, $4016.1 as controller III and $4017.1 as controller IV. A Four Score can't normally be connected to a Famicom.

NTSC Systems (NTSC NES and Famicom)
* Red and green emphasis bits are reverse from PAL NES.
* Vertical blanking period is shorter, can't use the full PAL vblank time.
* Faster CPU clock (sprite movement speed, scroll speed and music tempo)
* APU Pitch is different
* Raster effects will need to be different from PAL

RGB PPU (Sharp C-1 and Famicom Titler)
* Grey colors $D2 and $D3 are missing so it's best not to use them ($00 and $10 are good greys to use)
* Color emphasis effects brightens the colors instead of dimming. Setting all three bits makes the screen totally white and the player can't see anything.

Dendy (and some other PAL Famiclones)
* Emphasis bits red and green are swapped in $2001 just like on PAL NES.
* UMC based CPU clones have swapped 25% and 50% Duty Cycles for the Square Channels.
* Speed is like PAL (affects sprite movement speed, scroll speed and music tempo)
* APU Pitch is like NTSC
* Raster effects will need to be like NTSC
* Some Famiclones are both missing Start/Select and the microphone on controller II so you don't want to require the player to do any of these inputs.

So Dendy is like a mix of PAL and NTSC. You might want the player to be able to mix and match speed and pitch settings however he wants in an options menu if you want to safely support NTSC, PAL and Dendy.

WheelInventor wrote:
Quote:
I plan to get a PAL NES again (our old one was thrown in the garbage by my sister :cry: )

OUCH.

It belonged to her so she took it to her home one day when she was bored and wanted something to do. Years later I asked her what she did with it and it turned out that she had thrown it out because the games didn't work anymore. It wa probably just a cart connector problem...


Quote:
Quote:
But they are so darn expensive nowdays!

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...

Oh 600 kr is a good price for a CIB system.
Yeah thanks, I've been scanning Tradera and ebay now and then to get a feel for the current prices. The problematic cart connector in NES systems is one reason why I hesitates.