NES emulation- correct me if I'm wrong

It's my first post, so please go easy.

It's my understanding that when it comes to accurately emulating the NES system, the hardest part is accounting for the multi-memory controllers. However, you only need to deal with MMC emulation (mappers) when working with roms since you can't dump a MMC chip. That means that if you are interacting with an actual cart with an actual MMC chip inside it, a mapper is not needed.

This begs the question why Famiclones and NES-on-a-chips are so piss poor when it comes to compatibility and accuracy. Is it just poor workmanship or what? If the MMC chips are the toughest part and you don't even have to deal with that when creating a famiclone, how come they suck so bad?

 

mandated by Chinese law

 

So you're saying there's no technical reason why one couldn't create an accurate emulation of NES hardware using suitable microcontrollers like certain ATmega products or the Parallax Propeller? I know they'd be more expensive parts-wise than what they use for NES-on-a-chips, but the added quality would be well worth it, don't you think?

 

kevtris cloned the NES with FPGAs or some other such devices. There's no reason NES clones can't equal the real NES. It's just no one does R&D. They all copy the same old NoaC design.

 

Some of the newer clones like the RetroDuo are supposed to have much better compatibility. Apparently Yobo finally updated their designs. The sound is still a little wonky, but I guess how can they justify spending the R&D time when only a fraction of their customers can tell the difference?

 

Too true, any real gamer would just by a NES. Clones seem to be designed for those who knew a friend who had a neighbor who had a videogame thingy and they want to relive a tiny piece of their life.

 

Are there any NES clone systems available yet that can switch between 50Hz/60Hz and output RGB? Thats what ive been hoping for...

 

No. Also I have doubts anyone isn't using the same NoaC design. The so called "improvements" were from not wiring the cartridge port incorrectly. The actual NoaC is the same. The sound "wonkeyness" really makes it terrible in many games.

 

MMCs are actually one of the easiest parts next to the controller and address decoding.

Because they are wired incorrectly to the connector and because NOAC have mistake(s) in the audio circuit and on chip analog elements (DACs) aren't exact.

Poor workmanship? A clone in the first place is EXCELLENT workmanship, you talk like it's woodworking or something...

It's not a clone in that he copied Ricoh's design, it's his own design so I really doubt the PPU is as accurate as a NOAC. Since it doesn't interface to external carts, we'd never know if he uses hacks like old emulators either or everything is down to the clock edge (I highly doubt it).

You could accurately emulate a NES with any Turing-complete computer including a single instruction computer, but not in real time. Microcontrollers are not suited to clones AT ALL, NOAC clones are HARDWARE clones, they copy the hardware logically at the gate-level or transistor-level. For pixel-perfect emulation in real time on a RISC with highly optimized code you'd still need at least a G3 Mac/Gamecube with independent audio/video controllers. MCU aren't there yet, and might be phased out before their I/O could interface with a cartridge and keep accurate timing, generate the A/V in software etc. No worries though because a non-volatile FPGA with internal block memory can also make a cheap NOAC and it can do a hell of a lot more.

No because all NES clones in existence now (apart from pseudo-logical clones like Kevtris' console) are literal clones of NTSC (AFAIK) chips.

They don't have to be for casual gamers, a $200 "clone" with high definition output could cater to elitist collectors as well.

 

I remember chips from a Chinese company called "UMC" UM6527/UM6528 (NTSC 60) UM6547/UM6548 (PAL-M60 for Brazil) a PAL-N (Argentina) version exists too but I don't know the correct number.

These chips work exactly as the original Ricoh chips and are pin compatible, but there's only one issue:

The UM6527/6547 chips (CPU) generate one of the sound channels with an slightly different pitch.

Besides that even DPCM works right so for example in games like Teenage Mutant Ninja Turtles 3 you hear "Cowabunga" instead of "CowaCowa" some cloned NES CPUs do. And some of the fake CPUs/PPUs also run quite hot.

If it were not for the pitch difference on the output I would say that UMC NES clone chips were perfect. Also UMC was the first company to manufacture the NoaC, so I bet it's their design the other companies are copying.

 

Cool info, thanks.

 

Calpis, it seems like there was only one part of my posts you didn't quote.

I have to disagree with you there, Calpis. I've personally seen a few projects implemented with a couple of Atmel chips and one with a Parallax Propeller that have come extremely close to emulating the NES or similar hardware. The ones that have attempted the NES, however, got hung up on the mappers since they were attempting to run ROMs.

The reason I ask all of this is because I feel like people are casually overestimating the number of viable NES units still floating around out there. It may have been one of the most produced vg systems, but I still feel like we'll see the beginnings of a shortage well within my lifetime at least. And I can't stand the thought of the NES hardware becoming rare. I want my children and my children's children to experience the simple joy of the NES.

It's not purely science. There is an art to good programming and good electrical engineering.

 

How is it extremely close? "Similar hardware" leads me to believe they implement "8-bit like" A/V. Can you provide links?

IIRC Kevtris, mentioned in this thread, wrote a CPU/APU emulator for a MCU, but it's not nearly the same as running a CPU/APU/low level PPU all in sync while generating the video signal in software (meaning you can only compute the frame during blanking). Even if it could do that, emulation is far different than a hardware clone expected to interface with a cartridge. A MCU can't fetch ROM data via its I/O at 200+ MHz when computing the frame either, the fastest a NES cart can run is <3 MHz.

Because someone tries doesn't mean it's doable. If they got hung up on mappers, surely they won't get very far. Mappers are like pointers, they're very simple but you need a lower level of understanding to get them and if you don't have that, there's no way you're making an accurate clone. Maybe a very high level emulator, but that isn't good enough for a NOAC. Honestly, mappers are a horrible excuse because there are probably 500 games that DON'T use mappers and are often the ones you want to test your emulator on. I know from experience, I worked on a software NES software for a couple years then adapted it to hardware, which I hope to eventually get ASIC ("NOAC") worthy.

IMO it is purely science; there's an art to good design and planning but good implementations are science. But I don't know where that came from, I meant that it's wrong to criticize work which practically nobody can reproduce, cloning chips is crazy hard--exactly why fewer than a handful of groups have done it and probably nobody will ever do it again. Any future clones will probably be functional "clones", ie hardware emulators such as Kevtris' and mine.

 

Now you're just arguing semantics.

The Random House Dictionary clearly shows that the term 'emulation' can apply to both hardware and software. It doesn't matter if you use one MCU, two MCUs, or a hundred MCUs. It doesn't matter if it is interfacing with a cartridge or reading from a ROM. If some hardware is running NES software and isn't using a Ricoh 2A03 and a Ricoh RP2C02, it's emulating the NES. It's an emulator. Even your hardware clone is emulating the NES.

 

Could you please quote me where I'm arguing semantics? I mean I even called my "clone" a hardware emulator so I'm not sure what you're sore about. It's actually very important to differentiate between a clone, a software emulator and a hardware emulator in this discussion. You argued that a microcontroller can implement a NOAC, not loosely emulate a NES. You wouldn't call a GBA running PocketNES a NOAC would you? GBA are implemented in a single chip. NOAC are widely understood to be ASICs reusing original NES mask work or hardware emulators where at least all of the logic is implemented in a single chip.

To reiterate:

NOAC/clone - ASIC containing replicated original mask work, no more of an "emulator" than an legitimate IC revision.

Software emulator - all functions are carried out one logical operation per execution unit at a time (not in real time). As game hardware must interface with the NES in real time, this method is only possible if emulation is in sync and all I/O is updated at the level of the smallest timeslice which happens to be the pixel (0.18uS). Because this could easily require a billion instructions per second, it quite possibly will never be feasible with discrete microcontrollers and in general is a ridiculous solution compared to a hardware emulator.

Hardware emulator - all functions are carried out simultaneously in real time (asynchronously). No original mask work is used, nothing is "executed", only logical functions assumed from the original hardware are synthesized. Can logically implement the hardware better than the original hardware. This is the only reasonable contemporary solution as it's cheaper/more legal than cloning and will be device/vendor independent so one can shop around for a physical implementation.

 

Heh, well he did say it was his first post...

 

At least we're on the same page now as far as terminology goes.

But I'm still confused. Didn't you say that microcontrollers are not suitable for use as hardware emulators? Unless you meant that microcontrollers aren't suitable as ASIC solutions. In that case, of course they aren't. They are designed to be application inspecific to encourage wider usage.

As for my criticism of Chinese NOAC implementations, I think the criticism is justified. My beliefs regarding work ethic is not to bother doing something unless you're going to do it right and the fact remains that they released a faulty product with the view that it is "good enough".

Seems like the best solution at this time is to go with a hardware emulator and allow for the quirks of the original hardware. I believe that one can create a "perfect" replica using this method. Perfect being defined as indistiguishable in video, audio, timing, and compatibility.

Back to the microcontroller issue. It's my belief that microcontrollers are perfectly suited to hardware emulation. Obviously, we're not talking PIC-class MCUs. I'm talking about Propeller (20 MIPS x 8 cores) or various Atmel chips (200+ MIPS). These chips seem more than capable at emulating the NES.

I apologize for any confusion. I was never referring to a homebrew ASIC solution. I was comparing the quality of existing ASIC solutions (NOAC), which I perceive as poor, to hypothetical homebrew hardware emulation solutions.

And if all else fails, we can just call it CATURDAY! :icon_bigg

 

I don't see how the NOAC are just "good enough" as I never saw a game fail booting/working properly on either NOAC (I mean systems using an single chip which is operational equivalent of a NES chipset) or Famiclones (Systems built on chips that are pin to pin compatible with original Ricoh parts and the respective glue logic/memory parts an original system has).
Mostly the problems with NOAC systems are the wiring from the NOAC chip to the cartridge port being wrong or it's "built in games" subsystem being badly designed and causing problems with cartridges.

Famiclones are usually perfect provided that the parts used aren't "too shabby".
I even own a pirate SNES console which is 100% perfect copy of a SNES and it even do mode 7 properly. This one can even run Nintendo's Burn in test tool correctly. Not even the best emulators (SNES9x and ZSNES) do that one right.

I just mean to say that blamming the NOAC chip is not fair as more things can be wrong on the system.
Minor accuracy problems need not apply here (I mean really minor things like an audio channel with different pitch and it might even be some kind of signature from the chip maker, purely intentional...)

 

http://www.xgamestation.com/

The guys here might be a good group to ask about their suitability for NES replication. Andre Le Mothe has launched two dev kits based on both the Propeller and the Atmel chips and I believe someone was in the process of emulating the NES with one of them.

 

???? Microcontrollers only run software, they cannot implement hardware so by their very nature are not suitable for hardware emulators.

Actually, microcontrollers are always meant to be implement ASICs.

Shit happens, someone messed up the audio circuit, it wasn't easily fixable and most customers probably don't care so nothing was done about it. Practically every chip has errata!

It's the ONLY solution if you want to interface with real cartridges unless a software emulator first dumps the game then emulates it out of real time using local memory.

Again, they cannot implement hardware, just run software. Yes they can emulate the NES, but not as well as you think. I'd be surprised if even the most expensive 32-bit AVR could emulate a NES accurate to the pixel. Even if it could, where is the benefit of running the emulator on an AVR opposed to a Wii or PC? There is just no point.

Other things to consider is that MCU do not have enough internal memory to store typical games so they are at the mercy of slower/expensive external memory. MCU are modified Harvard architecture so emulation of Von Neumann architecture will be tricky in itself!

Woo only $250 for the Hydra + SRAM card ($40 of chips I believe) which might be able to pull off Nesticle quality emulation :lol: