my next emulation project

[serge2k]

I've started a space invaders emulator as well now.

I decided that rather than using a huge switch statement this time I would create an array of function pointers instead. Working perfectly so far.

I'm still fuzzy about interrupts, cycles, and IO.

cycles - would just putting in a variable that is set after after every execution and then decrements as the program loops (with no other executions) be sufficient?
interrupts - so I can just have a counter that decrements once per cycle and when it reaches zero I immediately generate the interrupt (so execute a RST opcode based on the interrupt) correct? If thats right then I'm just wondering where I can find info on what interrupts I need, vblank and end of vblank are mentioned on emutalk. is that all?
IO - anyone have any good sources of information for this, I'm just confused.

oh and the ram mirror. That's just an area in memory that mirrors the ram right? So if I write to the ram I have to write to the mirror and vice versa? Do I even need it or can I just have any writes to the mirror go to ram instead?

[Hatorijr]

check out the thread at emutalk, i listed the exact amount of ram space invaders requires to function perfectly.

as for cycles, it runs at 2 mhz, divide by 60 to get cycles per frame(2,048,000 / 60) at this point i can say you only need 2 interrupts to be called every frame. way i did it(there i am sure more ways but this is mine lol) i called first half of the cycles than called first interrupt than vblank, second set than last interrupt, worked very well for me.

every opcode has an amount of cycles it takes to be called and you must keep track of this, by either adding or subtracting from a total.

the interrupts in space invaders do have an opcode but usually are not called directly by the program but by the emulator. but other systems have what i consider hardware interrupts that have no opcode.

the io in space invaders is controlled by io ports, info is listed on emutalk and if you need more feel free to ask, i can give you pages i found on them.

btw, ram mirror is not needed but you will be allowing some access into there as without it, the game will crash during the demo like what happened to me.

also i highly recommend that you completely read the info supplied on the emutalk thread, helps a lot. if you need more info let me know.

i also been thinking about a unique way of doing a opcode decoding process which i am unsure as of now would benefit greatly or cause issues but if done right, would completely get rid of the switch entirely.

[serge2k]

I already got rid of my switch

void (*operation[256])(Processor *p)

operation[opcode](this)

if i wasn't using C++ then it would be easier. As it is now it works but I'm not sure if it's that good of an idea, eliminates the need to check every time but I don't know if there is any issue doing it that way.

I think I'm doing the interrupts correctly then.

I did read through the emutalk but I had questions and this place seems more active.

[Exophase]

Why did you want to replace the switch?

[Hatorijr]

not sure who you are asking but for me i am thinking of replacing it just because i would like to test my theory, of course i wont be testing it on anything complex, i plan to test it when i get around to rewriting my chip 8 to see if it does any good.

[Exophase]

The question was for serge2k, but I'd be curious to know what your theory is as well.

[Hatorijr]

well a while back i came across an interesting method in c#, where i can call any function i want on the fly, as long as the function exists in the exe i can call it as in i was calling a function. say i have a text box on a form, and in my exe exists a function called Resize_Window with a parameter for the size in this format x_y. i can type Resize_Window 200x200 and it immediately calls and resizes the window without doing any real checks except just to make sure the function receives the correct parameters. also, if i wanted to extend functionality, all i need do is add the function to the program, no extra work would be needed to make sure it can be used.

[Exophase]

I guess the question I have is in what ways would this be superior to a switch statement? Is it for organization purposes or is it for performance?

I'm saying this because there has been a common belief amongst emulator coders that function tables are faster than switches, when in reality the opposite should be true.

[Hatorijr]

well actually i was wondering that myself, as to how this method would perform. thats why i was looking to eventually test it but not on a current emulator i am working on. any insight into a similar method and as to how it performed would be welcomed.

[Exophase]

I don't know what would be faster on C# because I don't know how switches or the indirect function calls you mention are implemented. I just know that theoretically a switch can be faster than an indirect function call because there's less return overhead, more stack frame/register consistency (frame and calling convention overhead) and better potential for optimization. If the function table performs better then the compiler is not doing a good enough job.

I wrote a big post on this once but all I could find was one that was basically like this one :/

[Hatorijr]

well thanks for the reply, maybe i could recode chip 8 to use my current methods and than make a copy using the other and see which performs better, though seeing as how well a switch performs in space invaders and gameboy i am sure the switch may win but i wont know until i at least test it out.

[serge2k]

interesting, I did it that way just to experiment.

[Entityshadow]

How....can you do that........ T.T

[@ruantec]

Originally Posted by Exophase

I don't know what would be faster on C# because I don't know how switches or the indirect function calls you mention are implemented. I just know that theoretically a switch can be faster than an indirect function call because there's less return overhead, more stack frame/register consistency (frame and calling convention overhead) and better potential for optimization. If the function table performs better then the compiler is not doing a good enough job.

I wrote a big post on this once but all I could find was one that was basically like this one :/

I have to agree with you there at 100% sadly C# doesn´t like switches at all/that much but there is much room for optimization there and still better than indirect function call or loops.

__________________

Current development tools:

Visual C++.net, Visual C#.net
Visual VB.net, Visual Webdeveloper.net
Bloodshed Dev C++, Borland C++
Visual Basic 6

[Cid Highwind]

Since this is one of the overlooked sections, if you would still like a namechange, please write down your desired thread title in a reply to my post, and report your own post. This will make it easy for any mod to notice your request and it will be changed the very same day

__________________

PC Specs:
CPU: Intel Q8200 @ 2.8GHz
GPU: Sapphire ATi HD4870 / 1024MB / Core: 801 / Mem: 1000
Mobo: Gigabyte EP35-DS3 (rev 2.1)
SPU: Creative X-Fi Xtreme Music
RAM: 2GB Kingston HyperX DDR2 1066 @ 4-4-4-12 ~ 800MHz
HDD: 1TB Samsung Spinpoint, 32MB
PSU: Hiper Type-R 580W
Monitor: Iiyama B2403WS / 1920*1200

Geometry Wars: 198.400
Lumines: 999.999

Join the NGEmu Folding @ Home community NOW!

[serge2k]

Originally Posted by Entityshadow

How....can you do that........ T.T

eliminate the switch?

you can create an array of function pointers.

void (*operations[256])(Processor *p);

is how I did it.

Then just fill in the table with the appropriate functions.

Unfortunately I have a bug somewhere and am having loads of trouble finding it.

[Dax]

I'm guessing he meant how can you write an emu.

__________________

My PC Specs|My Consoles|Emu SVNs|Project OSX|How to ask a Question

[serge2k]

hmm

well that would make sense.

rather ambiguous question.

[serge2k]

I decided to scrap almost all of my original code. The function table idea could have worked but I just didn't plan it out well enough so it became a huge pain to debug.

Progress on my new version though



No colours yet and I still have a few more opcodes to work on.

and obviously the graphics there are wrong, need to fix that too.

[Hatorijr]

wow nice job so far, you probably still have some buggy opcodes but its looking good.