Emulator programming challenge

Alegend45 · Post by **Alegend45** » Sat Apr 28, 2012 5:55 pm

Hello. I am not very well known here, but here goes. I have a challenge for all of you, to write a NES emulator in a language other than C, C++, Perl(Yes, it's been done), or any other language in which it's been done. It has to support only 10 mappers. Also, I'm going to need language suggestions, because I'm doing this challenge too.

EDIT: Say, has a NES emulator been written in D?

EDIT 2: Never mind, looks like D is for me!

EDIT 3: Never mind, real-life-itis is just going to kick in...

tokumaru · Post by **tokumaru** » Sat Apr 28, 2012 6:18 pm

I find it pretty amazing that a JavaScript one exists. There's also one written in QBasic, but it hasn't been worked on in 13 years!

EDIT: Actually there are a couple other emulators for Q(uick)Basic, which I find quite surprising!

Alegend45 · Post by **Alegend45** » Sat Apr 28, 2012 6:19 pm

Geez, and I thought computers of the time were too slow for NES, except for NESticle.

hcs · Post by **hcs** » Sat Apr 28, 2012 6:40 pm

I wrote one in MIPS R4000 assembler for N64, it happens to support exactly ten mappers (iNES 1,2,3,4,7,9,11,34,66,71). It wasn't the first for N64 or the first in MIPS, but...

Dwedit · Post by **Dwedit** » Sat Apr 28, 2012 6:45 pm

PocketNES is in ARM assembly, with the non-emulation parts in C.

MottZilla · Post by **MottZilla** » Sat Apr 28, 2012 9:47 pm

ItMightBeNES is written in Assembly for the Playstation 1. Has impressive performance too.

hcs · Post by **hcs** » Sat Apr 28, 2012 10:06 pm

MottZilla wrote:ItMightBeNES is written in Assembly for the Playstation 1. Has impressive performance too.

Yep, that's the earlier MIPS one I was thinking of.

Bisqwit · Post by **Bisqwit** » Sun Apr 29, 2012 1:05 am

I wrote one just recently in 386 assembler, runs on DOS. Renders alternatively in paletted mode (256x240 onto 320x240 Mode-X without scaling), or using NTSC filtering with correct borders & aspect ratio to 320x240 truecolor, or with regular palette & gamma-corrected dithering in 320x240 Mode-X. No sound support. Requires about 6 GHz computer to be playable. :D

Alegend45 · Post by **Alegend45** » Sun Apr 29, 2012 6:21 am

LOL. I once tinkered with your C++11 NES emulator, Bisqwit. It was quite hard to get it fully working, but once I did, I noticed speed wasn't too consistent.

beannaich · Post by **beannaich** » Mon May 28, 2012 2:54 am

My emulator is written entirely in C#, using a managed wrapper for DirectX for input and output. Runs at ~120 fps on a 3gHz dual core CPU.

digilogistist · Post by **digilogistist** » Mon May 28, 2012 4:26 am

I privately wrote a working, pure real-mode x86 ASM-coded (source: 4600 lines; code/data size: 11KB), DOS-compatible (works under Win98 too) emulator with about 10 mappers of support, full 2A03 sound channel implementation w/SB16-only stereo audio playback, a keyboard-button game-jump multitasking function, 2 SNES pad support via parallel port, plus a sprite flicker reduction system, and some mode-x tweaks for a truly full-screen 256x240 video mode (and 2 other video modes that run the game at 90Hz and 180 (!) Hz). The thing runs full-speed on any Pentium-class system (even @ 180Hz, if that's not too fast to play at ;p), but because of some kinks that will take me a zillion years to iron out, I stopped working on it back in 2007.

Writing an emulator suitable for the public domain is insanely difficult to do, especially in any kind of low-level language. Nowadays, I wouldn't even care if my emu turned out to be slow-ass bloatware, just so long as I could get into the source, and routinely fix mistakes in a timely manner. I'd still like to write a new NES emu/multitsker (this time, using an external 2A03 chip for sound playback) based on lots of new information, but it's a bit of a learning curve: I started coding my first emulator way back in 1999!

cpow · Post by **cpow** » Mon May 28, 2012 6:10 am

digilogistist wrote:slow-ass bloatware

Unfortunately since I went for complete cycle accuracy and haven't yet bothered to figure out how to implement any catch-up algorithms, this is where my emulator has stagnated for quite a while. It runs great on my i5 but not so well on my core 2 duo.

hcs · Post by **hcs** » Mon May 28, 2012 9:49 am

digilogistist wrote:Writing an emulator suitable for the public domain is insanely difficult to do, especially in any kind of low-level language.

Indeed. Fortunately I was still overconfident when I released Neon64 or it never would have seen the light of day. I worked on it pretty much all through high school, 2001-2004.

Nowadays, I wouldn't even care if my emu turned out to be slow-ass bloatware, just so long as I could get into the source, and routinely fix mistakes in a timely manner.

I've thought of doing an SNES emu on N64 many times, since I know now much better how to wrangle C for the stuff that doesn't need to be asm. Not up to the challenge yet, and I'm increasingly fed up with simulating stuff that already exists.

digilogistist · Post by **digilogistist** » Mon May 28, 2012 4:58 pm

I welcome the day when simulators will be able to run full-blown digital representations of decapped chips like the 2A03 & 2C02, so that us programmers will no longer require knowledge of how the chip works to get a retro system to work properly (for just the simple purpose of entertainment and enjoyment), but rather face a new challenge: unrolling, compressing, optimizing and compiling sequences of the gate logic that is represented in the perfect digital manifestation of those chip's internal digital circuits, with computer machine code portable and executable on any modern-day multicore processors.

After all, this has already been done for the 6502, and I think Quietust has an on-line 2A03 simulator that can simulate one phi 2 cycle in about one second, so this is just the beginning of a new age of retro game system restoration.

At one time in PC emulators (late 90's), it may have been practical to use dynamic compilation on executed 6502 instructions to get phenomenal speed out of emulating the NES (like on a 486 or a Pentium). Nowadays though, PCs are 100x (or more) faster, and the effort of implementing such a sophisticated system of dynarec emulator operation is just overkill for a system like the NES (even the most state-of-the-art and accurate of emulators nowadays can run full speed (even with HQx effects) on any top-end system that anyone can buy today).

After all, even if the most optimized and speedy NES emulator can completely render 1000 frames a second on a top end system of today, the fact of the matter is that generally you only really need 60 FPS to do the job. My point here, is that emulator operation optimizations, is a dying art of relevance to modern computer systems (not that people didn't notice this trend, but it was a hard lesson I had to learn by writing a whole NES emulator in barebones x86 assembly code for DOS, which now looks like not much more than a whole lot of wasted time on my part, other than learning about how to write an NES operating system for PC

.

Right now, simulation is in it's infant stages, and it's going to be a while before even something like the 2A03 can be ran in real-time, and this is where dynamic code compilation is going to resurface in this area of NES emulation (but it's not really emulation though, because you are simulating electrons/voltage through vast arrays of logic circuits, not emulating guesses and opinions about how sophisticated sequential digital hardware behaves in the NES (which just can never be 100% accurate, because it is impossible to know everything about how tens of thousands of transistors behave several millions of times a second in a system like the NES)).

I myself am not educated enough to tackle such a titanic task of writing an NMOS chip simulator software program (not yet, anyway), but lets also not forget that at one time, iNES and Nesticle were the only emulators that people knew could play NES games. If skilled tech people around the world didn't love the NES system and it's software to death, we wouldn't be where we are today, where pretty much every known detail about the system's operation has been tested & accurately documented (the MMC5 still has some interesting secrets, however). The days for the NES only just keep getting better and better.

Post by **tepples** » Mon May 28, 2012 5:49 pm

digilogistist wrote:At one time in PC emulators (late 90's), it may have been practical to use dynamic compilation on executed 6502 instructions to get phenomenal speed out of emulating the NES (like on a 486 or a Pentium).

NESten did this. But what ends up happening is that this sort of dynarec can only help the CPU, not the PPU.

on any top-end system

My system isn't top end; it's an Atom netbook. An Atom netbook will run FCEUX 2 with the old PPU, but there's slowdown if I go to higher settings. It won't run NESICIDE Emulator at full speed at all, and I've reported this to cpow. Nor is a mobile phone a top-end PC.

After all, even if the most optimized and speedy NES emulator can completely render 1000 frames a second on a top end system of today, the fact of the matter is that generally you only really need 60 FPS to do the job.

Unless you want to emulate a room full of NES consoles or an arcade full of Vs. or PC10 machines.