Welcome to Emulationworld

Forum Index | FAQ | New User | Login | Search

Make a New PostPrevious ThreadView All ThreadsNext Thread*Show in Threaded Mode


SubjectCreating GBA Emulator new Reply to this message
Posted bycubexrock
Posted on08/05/04 08:41 PM



hi, i'm a newb in the boards, i just starting to get into c programming, i was wondering if its possible to create a Gba emulator with C programing and wat i would need in order to start,i have a couple different compilers,i've been writting some programs, tyring to neways,and i'm trying to really get into C programming. I know i'm kinda jumping the gun but i'm moving through c programming at a good pace, i just wanted to know wat it takes to make a gba emulator, i'm on my own for know but i have a friend who knows C and is working with C++ right now and may help me with the project.
Is knowing C++ a must if i want to make a gba emulator?

Any helpful suggestions would be great thanx





SubjectRe: Creating GBA Emulator new Reply to this message
Posted byBart T.
Posted on08/05/04 09:33 PM



C is just fine but you need to understand how computers work and how to program applications with graphics. On Windows, this means you'll have to learn to use DirectX or SDL down the road. In order to do that, you'll want to be very proficient with C.

Additionally, you should learn about computer architecture and be comfortable with working at a low level: Dealing with bits and bytes. A good way of doing this is learning an assembly language; either X86 or ARM. Either way, you'll encounter plenty of ARM code because of the GBA but knowing X86 (one of the nastier assembly languages out there) is going to be very helpful.


> hi, i'm a newb in the boards, i just starting to get into c programming, i was
> wondering if its possible to create a Gba emulator with C programing and wat i
> would need in order to start,i have a couple different compilers,i've been
> writting some programs, tyring to neways,and i'm trying to really get into C
> programming. I know i'm kinda jumping the gun but i'm moving through c
> programming at a good pace, i just wanted to know wat it takes to make a gba
> emulator, i'm on my own for know but i have a friend who knows C and is working
> with C++ right now and may help me with the project.
> Is knowing C++ a must if i want to make a gba emulator?
>
> Any helpful suggestions would be great thanx
>


----
Bart


SubjectRe: Creating GBA Emulator new Reply to this message
Posted byfinaldave
Posted on08/06/04 06:16 AM



> hi, i'm a newb in the boards, i just starting to get into c programming, i was
> wondering if its possible to create a Gba emulator with C programing and wat i
> would need in order to start,i have a couple different compilers,i've been
> writting some programs, tyring to neways,and i'm trying to really get into C
> programming. I know i'm kinda jumping the gun but i'm moving through c
> programming at a good pace, i just wanted to know wat it takes to make a gba
> emulator, i'm on my own for know but i have a friend who knows C and is working
> with C++ right now and may help me with the project.
> Is knowing C++ a must if i want to make a gba emulator?

On the contrary, I wrote my first emulator in C++ and I ran into trouble from the outset, I wrote my next emulator in C and it was fine


>
> Any helpful suggestions would be great thanx
>


You learn something old everyday...



SubjectRe: Creating GBA Emulator new Reply to this message
Posted byRaiden16
Posted on08/09/04 03:06 PM



> On the contrary, I wrote my first emulator in C++ and I ran into trouble from
> the outset, I wrote my next emulator in C and it was fine

What kind of trouble? The only thing I can think of is it being slower than C.




SubjectRe: Creating GBA Emulator new Reply to this message
Posted byBart T.
Posted on08/09/04 09:43 PM



> > On the contrary, I wrote my first emulator in C++ and I ran into trouble from
> > the outset, I wrote my next emulator in C and it was fine
>
> What kind of trouble? The only thing I can think of is it being slower than C.

Sometimes object-oriented design is way more trouble than it's worth.


----
Bart


SubjectRe: Creating GBA Emulator new Reply to this message
Posted byRaiden16
Posted on08/10/04 01:21 AM



> Sometimes object-oriented design is way more trouble than it's worth.

I agree, however I'm curious if he meant something that I hadn't heard about before. ;)





SubjectRe: Creating GBA Emulator new Reply to this message
Posted byfinaldave
Posted on08/11/04 07:03 AM



> > Sometimes object-oriented design is way more trouble than it's worth.
>
> I agree, however I'm curious if he meant something that I hadn't heard about
> before. ;)
>

...well all I'll say is, try making a C++ class out of StarScream and then running two Megadrives at once...
;-)

That's what I tried to do in the first iteration of DGen and the results were... messy!



You learn something old everyday...



SubjectRe: Creating GBA Emulator new Reply to this message
Posted byRaiden16
Posted on08/12/04 02:42 PM



That does sound painful. But then again I've still yet to put together an emulator myself. I did walk through a Phoenix emulator setp-by-step and got it running. However for some odd reason my ship would always move left unless you were moving right. Not to mention I don't particulary like phoenix. It was also confusing to me to use the cpu core.

Oh well, plenty of time to try again.

> > > Sometimes object-oriented design is way more trouble than it's worth.
> >
> > I agree, however I'm curious if he meant something that I hadn't heard about
> > before. ;)
> >
>
> ...well all I'll say is, try making a C++ class out of StarScream and then
> running two Megadrives at once...
> ;-)
>
> That's what I tried to do in the first iteration of DGen and the results were...
> messy!
>
>
>
> You learn something old everyday...
>





SubjectRe: Creating GBA Emulator new Reply to this message
Posted byerikduijs
Posted on08/13/04 02:42 PM



> > > Sometimes object-oriented design is way more trouble than it's worth.
> >
> > I agree, however I'm curious if he meant something that I hadn't heard about
> > before. ;)
> >
>
> ...well all I'll say is, try making a C++ class out of StarScream and then
> running two Megadrives at once...
> ;-)
>
> That's what I tried to do in the first iteration of DGen and the results were...
> messy!
>

I don't know StarScream, but I could imagine it maybe doesn't lend itself very well to wrap it up in a class? Other than that, I wouldn't know why you wouldn't be able to run 2 megadrives at once using OO if the rest of the megadrive emulator is OO too...
Also, when you go for OO you have to be careful to keep polymorphic virtual calls down as you will pay for them.
<- erik rewriting his OO 68k interpreter to a code generator ->




SubjectRe: Creating GBA Emulator Reply to this message
Posted byRiff
Posted on08/13/04 04:02 PM



> I don't know StarScream, but I could imagine it maybe doesn't lend itself very
> well to wrap it up in a class? Other than that, I wouldn't know why you wouldn't
> be able to run 2 megadrives at once using OO if the rest of the megadrive
> emulator is OO too...

I'm not sure what the incentive would be to attempt to emulate the system emulation state of two megadrives using the same process when you can just run an emulator executable twice. Emulating multiple processors is a completely different story. There is no reason that an object oriented implementation of a processor core should be particularly inefficient. I use a class for my Nuon processor core and have four of them running at the same time. The indirect-pointer overhead is negligable compared to overhead associated with interpretation and multi-processor synchronization. When you emit native code, all of this overhead can go away if you use a separate code buffer for each processor.



SubjectRe: Creating GBA Emulator new Reply to this message
Posted byerikduijs
Posted on08/13/04 07:22 PM



> The
> indirect-pointer overhead is negligable compared to overhead associated with
> interpretation and multi-processor synchronization.

From what I understand, polymorphism is not just indirect calls, but it leads to conditional branches which can slow things down considerably.
What slows down multiple processor synchronization so much? In my own emulator, running 3 CPU's sync'ed with much interleaving takes exactly 3 times as much time as just 1 CPU (obviously without interleaving), so I don't see any overhead...




SubjectRe: Creating GBA Emulator new Reply to this message
Posted byRiff
Posted on08/13/04 09:07 PM



> > The
> > indirect-pointer overhead is negligable compared to overhead associated with
> > interpretation and multi-processor synchronization.
>
> From what I understand, polymorphism is not just indirect calls, but it leads to
> conditional branches which can slow things down considerably.

My quote didn't mention polymorphism at all, only "OO," and I don't see any reason why polymorphism is required to be considered object-oriented. Virtual functions still do not require conditional branches that I know of, or at least they shouldnt in many cases. All the compiler needs to do is assign a fixed vtable address that is shared between the classes containing the virtual method. When calling a virtual method, the compiler simply uses the vtable entry belonging to the object instance. The entry is used as a pointer to the correct function. I suppose it may be the case that combined with multiple inheritance and other peculiarities, it might be possible to run into a situation where the vtable ordering cannot be matched such that the method lookup cannot be performed without some comparisons. The overhead I was referring to was the overhead of indirect addressing to access member variables. If you have an array of processors, you probably would have this overhead anyway, but if there is only one emulated processor, its an overhead that would still exist in a non-static C++ class implementation, but not in a C implementation.


> What slows down multiple processor synchronization so much? In my own emulator,
> running 3 CPU's sync'ed with much interleaving takes exactly 3 times as much
> time as just 1 CPU (obviously without interleaving), so I don't see any
> overhead...

The overhead stems from the increased latency of instruction execution on a given processor and the effect that latency has on timing events. The raw cycles spent on bookkeeping is pretty much linearly proportional to the number of processors being emulated. On the other extreme, a program that has a main processor waiting for coprocessors to finish tasks, and/or uses vsync will suffer a non-linear slowdown factor due to a couple reasons. One big one is that that idle coprocessors still need to be emulated. Putting idle processors to sleep might not be an option if they do more than spinwait. This means that the slower your emulator is, the more idle processing instructions you emulate. These emulated cycles are a complete waste if the processor is just spinwaiting. Additionally, if the program is vsync based where the rendering must occur during vblank, the wasted cycles may cause vblanks to be missed. A vicious cycle forms and as you make the core faster, you end up seeing a non-linear speed gain due to the timing dependencies.

Parallel code adds overhead by nature. On a real multi-processor machine, more function calls and instructions may be executed when a program is configured to use multiple processors versus a single processor. This can end up being faster on a real system because the code is executed in parallel. An emulator running on a single processor has to emulate the instructions sequentally in an interleaved fashion. This is not parallel and depending on the slowdown factor of the emulator, the overhead of a parallel program may be expanded to such an extent that it creates noticable performance degredation.



SubjectRe: Creating GBA Emulator new Reply to this message
Posted byerikduijs
Posted on08/14/04 06:31 AM




> My quote didn't mention polymorphism at all, only "OO," and I don't see any
> reason why polymorphism is required to be considered object-oriented.
>

Oh, right of course. I just thought you referred to my earlier comment about polymorphism.


>
> The overhead stems from the increased latency of instruction execution on a
> given processor and the effect that latency has on timing events. The raw
> cycles spent on bookkeeping is pretty much linearly proportional to the number
> of processors being emulated. On the other extreme, a program that has a main
> processor waiting for coprocessors to finish tasks, and/or uses vsync will
> suffer a non-linear slowdown factor due to a couple reasons. One big one is
> that that idle coprocessors still need to be emulated. Putting idle processors
> to sleep might not be an option if they do more than spinwait. This means that
> the slower your emulator is, the more idle processing instructions you emulate.

Maybe I don't understand you correctly, but shouldn't that be: The less interleaving you do, the more idle processing instructions you emulate? I mean I can understand that if a main cpu triggers a coprocessor to do something, the coproc. should leave any idle loops as fast as possible. One simple way to do that is to increase interleaving, right?

> These emulated cycles are a complete waste if the processor is just spinwaiting.
> Additionally, if the program is vsync based where the rendering must occur
> during vblank, the wasted cycles may cause vblanks to be missed. A vicious
> cycle forms and as you make the core faster, you end up seeing a non-linear
> speed gain due to the timing dependencies.
>
> Parallel code adds overhead by nature. On a real multi-processor machine, more
> function calls and instructions may be executed when a program is configured to
> use multiple processors versus a single processor. This can end up being faster
> on a real system because the code is executed in parallel. An emulator running
> on a single processor has to emulate the instructions sequentally in an
> interleaved fashion. This is not parallel and depending on the slowdown factor
> of the emulator, the overhead of a parallel program may be expanded to such an
> extent that it creates noticable performance degredation.
>

Hmmm, so what you're saying is that to ensure proper synchronization you have to interleave as much as possible, right? In my own emulator, the only overhead this adds just is more interrupt checking. Sure this adds overhead and it can add up, but the overhead is not really noticable on my emu but maybe that's because I only emulated fairly simple machines.





SubjectRe: Creating GBA Emulator new Reply to this message
Posted byRiff
Posted on08/14/04 03:48 PM



> Maybe I don't understand you correctly, but shouldn't that be: The less
> interleaving you do, the more idle processing instructions you emulate? I mean I
> can understand that if a main cpu triggers a coprocessor to do something, the
> coproc. should leave any idle loops as fast as possible. One simple way to do
> that is to increase interleaving, right?

I suppose that you could call it increasing or decreasing the amount of interleaving depending on which side you approach it from. If you have four processors, A, B, C and D, the maximum interleave would be acheived by executing a single instruction from each processor per round. If one processor is idle processing, it suffers from the biggest waste of time. I would say that decreasing the amount of interleave minimizes the amount of time spent emulating a polling loop. Its not quite that easy, though. The load on an active processor is path dependent. There is often no way to determine the processing requirement for a given processor and sometimes no way to tell if a processor is idle or not. The ideal solution would be to keep processors in lock-step while both are active, and then when one processor goes idle waiting for the other processor, only execute instructions on the active processor until the wait condition is satisfied.

I currently mitigate this by forcing interpretation of branches. The idle loops executed tend to be only a few packets long and fit within a basic block whereas non-idle code tends to have much larger basic blocks. As a result of switching to the next processor after each basic block, more active code is executed than idle code. This helps considerably, but is still far from optimal given that the active code may contain lots of branches in which case the behavior is similar to maximum interleave.

>
> Hmmm, so what you're saying is that to ensure proper synchronization you have to
> interleave as much as possible, right? In my own emulator, the only overhead
> this adds just is more interrupt checking. Sure this adds overhead and it can
> add up, but the overhead is not really noticable on my emu but maybe that's
> because I only emulated fairly simple machines.
>

I don't really need to provide maximum interleave, but there are some features that will benefit from it. The Nuon processors can use a low latency communications bus to talk with each other. They often poll the receive status. Other than that, there really is no hardware based synchronization. The standard software configuration is to have one main processor and three slave rendering processors. In most games, the load balancing between master and slaves is non-existant, so there is significant emulation overhead, particularly when the three slaves are waiting for their next rendering task.


Previous ThreadView All ThreadsNext Thread*Show in Threaded Mode