I've always been curious as how emulators and such work. I learned C and some C++.. and I played around with win32asm (very little though). Anyway, what should I learn to learn how to write emulators? Just want to learn how to write a simple NES emulator for example.. the basics for now, where do I start?
I know a language, now what?
- Thread starter LList
- Start date
Grab documentation on the NES first of all.LList said:
From the documentation you should know the following:
Processor (what does the work)
Hardware (video audio pads reset button etc.).
I would suggest first working to emulate the processor (actually run the code given to it). You will need to be able to deal with the ROM data as well (IE a ROM image you have to 'map' properly into your emulators space).
So once you have something that can read opcodes and execute them you need to work on something to handle memory (RAM ROM et al) on the NES.
After that.. perhaps video and last audio. Most of the instruction reads and writes probably should be ignored at first until you get the basic memory emulation functioning right.
Have fun!
JevilKnevil
New member
I think to even write a simple NES emulator isn't a easy task. But I failed to Computer Science last year so mabey it's just me 
If you don't have experience in coding emu related stuff, I think you should first start from simple things such as rom renamer. I'd also highly recommend writing some simple demo roms for the target system you want to emulate in ASM, that way you'll become familiar with the instruction set and how stuff really work.
Probably the easiest system to emulate is GB, at least it has simpler hardware than NES. Though writing GB emulator is a huge task too and you'll going to spends months to make it work.
Probably the easiest system to emulate is GB, at least it has simpler hardware than NES. Though writing GB emulator is a huge task too and you'll going to spends months to make it work.
No, the easiest system (by far) is Chip8. There are games like pacman, tetris etc for it. Use the how-to-write-a-chip8-emulator guide at http://www.goldroad.co.uk
I highly recommend writing one as a first emulation experience, it's pretty fun to see tetris running on your own chip8 emulator which you should be able to write in from an afternoon to a couple of days depending on your skills..
I highly recommend writing one as a first emulation experience, it's pretty fun to see tetris running on your own chip8 emulator which you should be able to write in from an afternoon to a couple of days depending on your skills..
JevilKnevil
New member
Cool, I think I'll even have a go!
Nice to hear When I wrote my chip8 emulator a couple of years ago I got it running most games somewhat in about 6-7 hours or so but it had some bugs that i never bothered to fix.. but it was a really fun experience that i now recommend to every wanna-be emu author i see on forums, it's a very worthwhile little task to try
When I wrote my chip8 emulator a couple of years ago I got it running most games somewhat in about 6-7 hours or so but it had some bugs that i never bothered to fix.. but it was a really fun experience that i now recommend to every wanna-be emu author i see on forums, it's a very worthwhile little task to try My only problem is that the emu runs way too fast
Pong is unplayable unless I add some slowdown code. Updating the screen after every draw instruction slows the emu nicely but causes graphics to flicker badly but using 60 FPS update looks nice
I had slight problems with instructions FX29 and FX33. But debugging some roms in CowChip helped. Anyway, writing Chip 8 emulator is piece of cake compared to making GB emulator (which I still haven't got working properly)lain:
Pong is unplayable unless I add some slowdown code. Updating the screen after every draw instruction slows the emu nicely but causes graphics to flicker badly but using 60 FPS update looks nice
I had slight problems with instructions FX29 and FX33. But debugging some roms in CowChip helped. Anyway, writing Chip 8 emulator is piece of cake compared to making GB emulator (which I still haven't got working properly)
lain:
Doomulation
?????????????????????????
Call me senile, but...I can't get the display right. It looks weird and to it - it never changes; it's the same output all the time (and yes, I've emulated most other opcodes).
Btw...how does everyone slow down the emulator...or time it right, might I say? There's still in need of timing for sound to be synchronized with the output.
Btw...that guide is pretty much useless. It explains VERY LITTLE. Not even how to emulate a stack, even. Nor does it explain how to jump to subroutines and stuff. To even code a working one (besides the 3 opcodes they show; there's lots of them needed to emulate a game!), you have to find a source and a documentation to check the opcodes against.
Oh and...I got a opcode FX73 (I think?), which isn't documented...not in my source, nor in my documentation. Anyone knows what this opcode is?
Btw...how does everyone slow down the emulator...or time it right, might I say? There's still in need of timing for sound to be synchronized with the output.
Btw...that guide is pretty much useless. It explains VERY LITTLE. Not even how to emulate a stack, even. Nor does it explain how to jump to subroutines and stuff. To even code a working one (besides the 3 opcodes they show; there's lots of them needed to emulate a game!), you have to find a source and a documentation to check the opcodes against.
Oh and...I got a opcode FX73 (I think?), which isn't documented...not in my source, nor in my documentation. Anyone knows what this opcode is?
Last edited:
It's no wonder that the display emulation gives you problems... the way how graphics are done in Chip8 is rather strange compared to modern systems. It is very important that you do the drawing in xorred mode, just blitting the sprite pixels gives you total garbage. It is also vital that you set the VF flag after every sprite draw, or otherwise the game can't detect when collisions occur. When the game starts, display is empty (all pixels in VRAM are black = 0). When first sprite is drawn, it will be draw as-is because xorring result 1 xor 0 = 1 and 0 xor 0 = 0. But if game draws exactly same sprite, onto exactly same position, the sprite will actually disappear, because when white (=1) pixel is drawn onto pixel which is set (=1) the xor will result black pixel: 1 xor 1 = 0. Now in this case the VF flag will be set to 1 using bitwise OR.
phew what a lengthy explanation. Hope you get at least something from it
And I agree with you about that tutorial, but it's not intended to be comlete spec reference. You can find a good explanation of all instructions from here.
I've tried all available roms and I've never got FX73 instruction... you probably mean FX33, FX55 or FX65?
FX33 converts value in VX into 3 bytes which represents the numbers if value in VX would be as text... eg. if VX has value 0x64 (100 in decimals) you would put into memory (starting at address which is pointed by register I) values 1, 0, 0.
FX55 dumps the registers into memory (again using I as address). For example if X would be 2, register V0 would go to Mem, V1 to Mem[I+1], V2 to Mem[I+2] (while I keeps unchanged).
FX65 simply does same thing as FX55 but reversed (e.g loads registers from memory).
phew what a lengthy explanation. Hope you get at least something from it
And I agree with you about that tutorial, but it's not intended to be comlete spec reference. You can find a good explanation of all instructions from here.
I've tried all available roms and I've never got FX73 instruction... you probably mean FX33, FX55 or FX65?
FX33 converts value in VX into 3 bytes which represents the numbers if value in VX would be as text... eg. if VX has value 0x64 (100 in decimals) you would put into memory (starting at address which is pointed by register I) values 1, 0, 0.
FX55 dumps the registers into memory (again using I as address). For example if X would be 2, register V0 would go to Mem, V1 to Mem[I+1], V2 to Mem[I+2] (while I keeps unchanged).
FX65 simply does same thing as FX55 but reversed (e.g loads registers from memory).
Doomulation
?????????????????????????
No, it was a higher opcode. I'll see what the game name was (is all chip8 roms freeware btw?).
And as I said, I used some source code to get my opcodes right. But the drawing opcode was weird and didn't work at all.
Currently, the code is much like the one posted at the tutorial. But display still isn't right; all output looks the same like this:
...all the time.
EDIT: Btw, I found these opcodes in the document, too:
FX75 Save V0...VX (X<8) in the HP48 flags (***)
FX85 Load V0...VX (X<8) from the HP48 flags (***)
Might be the opcode I found was FX75.
And as I said, I used some source code to get my opcodes right. But the drawing opcode was weird and didn't work at all.
Currently, the code is much like the one posted at the tutorial. But display still isn't right; all output looks the same like this:
PHP:
-
*
* *
* *
* *
*
-...all the time.
EDIT: Btw, I found these opcodes in the document, too:
FX75 Save V0...VX (X<8) in the HP48 flags (***)
FX85 Load V0...VX (X<8) from the HP48 flags (***)
Might be the opcode I found was FX75.
Last edited:
Doomulation
?????????????????????????
Yeah, well go figure, I don't think I'll implemt this opcode; just let it be. I still need help with getting correct display, however.
You probably used SuperCHIP (SCHIP) rom in your emulator if you got FX85 instruction? That is actually used in SCHIP emulation, I noticed it when I was implementing SCHIP support into my emulator (which works now perfect, btw). Trying SCHIP roms in your Chip8 emulator also explain why display wont work cause SCHIP roms use extended 128x64 display mode and use enhanced graphics instructions like scrolling the screen...