Emulator programming challenge

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Alegend45
Posts: 43
Joined: Thu Mar 29, 2012 6:10 pm

Emulator programming challenge

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

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

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

EDIT 3: Never mind, real-life-itis is just going to kick in...
Last edited by Alegend45 on Sat Apr 28, 2012 7:12 pm, edited 1 time in total.

User avatar
tokumaru
Posts: 11998
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

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!
Last edited by tokumaru on Sat Apr 28, 2012 6:22 pm, edited 1 time in total.

Alegend45
Posts: 43
Joined: Thu Mar 29, 2012 6:10 pm

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
Posts: 31
Joined: Mon Nov 27, 2006 11:34 pm
Location: NYC
Contact:

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

User avatar
Dwedit
Posts: 4410
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

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

PocketNES is in ARM assembly, with the non-emulation parts in C.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

User avatar
MottZilla
Posts: 2835
Joined: Wed Dec 06, 2006 8:18 pm

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

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

hcs
Posts: 31
Joined: Mon Nov 27, 2006 11:34 pm
Location: NYC
Contact:

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
Posts: 248
Joined: Fri Oct 14, 2011 1:09 am

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
Posts: 43
Joined: Thu Mar 29, 2012 6:10 pm

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
Posts: 207
Joined: Wed Mar 31, 2010 12:40 pm

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.

User avatar
digilogistist
Posts: 15
Joined: Sat May 05, 2012 9:28 pm

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!

User avatar
cpow
NESICIDE developer
Posts: 1099
Joined: Mon Oct 13, 2008 7:55 pm
Location: Minneapolis, MN
Contact:

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
Posts: 31
Joined: Mon Nov 27, 2006 11:34 pm
Location: NYC
Contact:

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.

User avatar
digilogistist
Posts: 15
Joined: Sat May 05, 2012 9:28 pm

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.

tepples
Posts: 22281
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

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.

Post Reply