how to make this much faster?

[AGS]

I was thinking: the emulator takes a .NES file as input.

It then processes the content of the .NES file. This processing happens in an interpretive style. Decoding happens in exec6502(dotickcount) and several other routines/macros. Interpreting code is a slow process even if you find a way to optimize the interpreter.

Writing an interpreter that runs at high speed (making it interpret code really fast) is something of an art. The fastest interpreters are JIT interpreters or even tracing JIT interpreters. A good example of what is possible using a JIT is the PYPY project that uses JIT interpreting instead of the 'normal' non - JIT interpreting.

It achieves a speed up with an average rate of a factor 3 over non - jit interpreted python code. That's a huge difference.

Another project (LuaJIT) does the same for LUA. It achieves even better performance numbers and on average it achieves an astounding speed up over non - jitted lua code.

To put it short: if you want the emulator to run at a faster pace you have to make the interpreter faster.

I don't want to sound too negative but developing a jit interpreter pace takes lots of time and you have to know a lot of low level assembler stuff.

So why not take some existing virtual machine/interpreter (java, luajit, pypy, llvm etc....) and write code that takes advantage of the speed reached by those interpreters?

Having written all of this I do think the moarnes program has a value on it's own. I think moarnes is one of few interpreters written in the fb language that does not interpret some programming language (like LISP of BASIC) but acts as an emulator for a chip. It deserves a special place somewhere in the fb distribution.

I'm pretty sure the devs will not agree with the coding style (will not approve of the coding style used) but this projects is just too good not to be part of the fb distribution.

Me likes moarnes.

[Mike Chambers]

I used to play NES games in an emulator called NESticle back in the day which ran full speed on my 486. FB won`t be as fast as the fastest assembly but I`m sure you could do better than needing a 1Ghz+ CPU.

You are calculating the name table address and the character pattern address from scratch for every pixel. This is a lot of redundant calculation. Once you`ve calculated the name table address at the beginning of one scanline you can read the remaining bytes for that line sequentially (except when hittting the boundary between name tables during horizontal scrolling). Also, once you`ve calculated the character pattern address you might as well get all eight pixels from it for that line instead of only one.

BTW, instead of using MOD to make calcy wrap at 240 how about an if-then?

label: if calcy>239 then calcy=calcy-240:goto label

since the maximum possible value is only 239+255 right? (GOTO avoiders can use a while loop or something instead)

you've got a couple good ideas there, i'm going to see what happens with those. thanks.

[Mike Chambers]

I was thinking: the emulator takes a .NES file as input.

It then processes the content of the .NES file. This processing happens in an interpretive style. Decoding happens in exec6502(dotickcount) and several other routines/macros. Interpreting code is a slow process even if you find a way to optimize the interpreter.

Writing an interpreter that runs at high speed (making it interpret code really fast) is something of an art. The fastest interpreters are JIT interpreters or even tracing JIT interpreters. A good example of what is possible using a JIT is the PYPY project that uses JIT interpreting instead of the 'normal' non - JIT interpreting.

It achieves a speed up with an average rate of a factor 3 over non - jit interpreted python code. That's a huge difference.

Another project (LuaJIT) does the same for LUA. It achieves even better performance numbers and on average it achieves an astounding speed up over non - jitted lua code.

To put it short: if you want the emulator to run at a faster pace you have to make the interpreter faster.

I don't want to sound too negative but developing a jit interpreter pace takes lots of time and you have to know a lot of low level assembler stuff.

So why not take some existing virtual machine/interpreter (java, luajit, pypy, llvm etc....) and write code that takes advantage of the speed reached by those interpreters?

Having written all of this I do think the moarnes program has a value on it's own. I think moarnes is one of few interpreters written in the fb language that does not interpret some programming language (like LISP of BASIC) but acts as an emulator for a chip. It deserves a special place somewhere in the fb distribution.

I'm pretty sure the devs will not agree with the coding style (will not approve of the coding style used) but this projects is just too good not to be part of the fb distribution.

Me likes moarnes.

thanks for the input, glad you like it! :D

the actual CPU interpretation and emulation code is pretty quick, the NES wasn't very powerful at all. if i disable background rendering, moarnes runs the NES code multiple dozens of times faster than the real console on a 1 GHz box.

and regarding the coding style, were you referring to the fact that i did it in the fblite dialect?

here is a new build, btw. there are a few more bug fixes, and it's a little bit faster. same games that weren't working before will play now, like startropics plus others.

http://rubbermallet.org/moarnes-0.11.5.7.zip

one of the bugs i fixed was related to determining the nametable to use on the background. there was a problem that caused the background to be completely black on mega man 3 and a few other games if the background horizontal scroll wasn't 0. it works fine now.

btw AGS, if you want to see an even cooler interpreter i wrote in FB message me and i'll let you have my source for Fake86. i wrote an 8086 CPU emulation core that works by interpreting too, and then wrote a full PC emulator around it. it's not finished, but it can do all kinds of stuff already. it can boot DOS from a drive image file, and run programs/games. it runs wolf3d, windows 3.0, borland turbo c++, and pretty much anything else perfectly. 100% pure FreeBASIC. :)

it's kind of like a super stripped-down QEMU written in FB.

[AGS]

and regarding the coding style, were you referring to the fact that i did it in the fblite dialect?

No, the fblite dialect is not the problem. Actually I'm not all that sure what it would take for a program to be distributed with the fbc. Most examples in FB_INSTALL_DIRECTORY/examples are small(ish).

Perhaps it would be a new thing to distribute bigger, user submitted projects with the fbc.

here is a new build, btw. there are a few more bug fixes, and it's a little bit faster. same games that weren't working before will play now, like startropics plus others.

http://rubbermallet.org/moarnes-0.11.5.7.zip

one of the bugs i fixed was related to determining the nametable to use on the background. there was a problem that caused the background to be completely black on mega man 3 and a few other games if the background horizontal scroll wasn't 0. it works fine now.

Great! I 'discovered' lots of NES games on the net. I've never owned one myself but the games are familiar. Mortal Kombat, paperboy,pirates... oops, the previous version of your emulator couldn't handle pirates, mortal kombat and decathlon. The screen just turns grey. I'll test using the new version.

btw AGS, if you want to see an even cooler interpreter i wrote in FB message me and i'll let you have my source for Fake86. i wrote an 8086 CPU emulation core that works by interpreting too, and then wrote a full PC emulator around it. it's not finished, but it can do all kinds of stuff already. it can boot DOS from a drive image file, and run programs/games. it runs wolf3d, windows 3.0, borland turbo c++, and pretty much anything else perfectly. 100% pure FreeBASIC. :)

it's kind of like a super stripped-down QEMU written in FB.

Yes, I want to see the source of the 8086 CPU emulator. But posting messages on this forum is not possible (I think?). I can be reached at sourceforge.net (username: agsags).

A super stripped-down QEMU written in FB... yes, I'd like to see that.

[Mike Chambers]

damn.. i can't log into my old sourceforge account. all the passwords have been reset, and i dont even remember what e-mail address i used when i set it up. got another way to get in touch?

[AGS]

damn.. i can't log into my old sourceforge account. all the passwords have been reset, and i dont even remember what e-mail address i used when i set it up. got another way to get in touch?

Sure, makkers at live.nl.

[counting_pine]

damn.. i can't log into my old sourceforge account. all the passwords have been reset, and i dont even remember what e-mail address i used when i set it up. got another way to get in touch?

What's your sf.net ID? If you go to www.sf.net/users/your_id_here, then you might be able to send yourself a message.
If you get back in, you could tie it to your Yahoo account and then you can log in with OpenID.