Writing A New Emulator...

[taratata]

Here's my idea: I'd like to enter emulation from the other side, the technical side. Until now, the only thing I've done with emulators is use them (or add games in MAME, but that's not really challenging).

 

So I want to begin writing an emulator. Of course, I won't begin with a system like Naomi: it would preferably be an old and already-emulated system.

 

Is anyone interested in writing it with me? (I just don't really feel like doing that alone, but I will if noone wants (or can) give a hand). Right now I only have a (limited) experience with Java and Scheme, but I could learn another language (would take much time though).

 

Or could you advise me concerning a system that would be easy to emulate?

 

Until then, I'll try to think about the time all this is going to take

[Agozer]

Well, no emulator is easy to code unless you know exactly how the emulated system works; how it stores data, registry usage, memory usage, video signal mapping, input handling etc. etc.

...and you have to be very experienced with different code debuggers.

 

The first thing would be to learn all that is possible about the sytem you want to emulate. Next, you'll need the technical documents, without those you'll get nowhere. For the tech docs, you can always check http://www.zophar.net or other

emulation and programming related sites.

 

Then knowing C++ or Assembly is is a big plus, but Java and Visual Basic works too...although the results are worse, unless you now how to optimise Java and VB code to it's limits.

 

Finally, coding an emulator isn't a walk in the park and requires skill, time and dedication. If you have any doubts, just walk away now. Also, there are so many emulators for those *easy-to-code* systems that a new emu won't make a big difference, unless it has something that the others seriously lack.

 

P.S. A note to those that haven't heard already: Forgotten (the VBA author) has decided to stop developing VBA and is moving out of the emu-scene.

Edited May 26, 2004 by Agozer

[taratata]

Well, no emulator is easy to code unless you know exactly how the emulated system works; how it stores data, registry usage, memory usage, video signal mapping, input handling etc. etc.

...and you have to be very experienced with different code debuggers.

I didn't think about it as easy. But why do you have to be very experienced with different code debuggers?

 

The first thing would be to learn all that is possible about the sytem you want to emulate. Next, you'll need the technical documents, without those you'll get nowhere. For the tech docs, you can always check http://www.zophar.net or other

emulation and programming related sites.

I'll check zophar

 

Then knowing C++ or Assembly is is a big plus, but Java and Visual Basic works too...although the results are worse, unless you now how to optimise Java and VB code to it's limits.

That's why I'll try with an old system, otherwise it will be near-impossible to get full speed on a virtual machine (such as java's or some schemes'). I may learn C and C++, but not now (and I'm not masochist enough to mess with Assembly). I'll just try in Scheme.

I have also found a Scheme to C translator, but haven't tried it yet.

 

Finally, coding an emulator isn't a walk in the park and requires skill, time and dedication. If you have any doubts, just walk away now. Also, there are so many emulators for those *easy-to-code* systems that a new emu won't make a big difference, unless it has something that the others seriously lack.

I don't really want to make a big difference, this is mainly for learning purposes. I'll try with all my skill and dedication; too bad I'm really lazy

For the system, I'm thinking about the original gameboy.

[Agozer]

Well, no emulator is easy to code unless you know exactly how the emulated system works; how it stores data, registry usage, memory usage, video signal mapping, input handling etc. etc.

...and you have to be very experienced with different code debuggers.

I didn't think about it as easy. But why do you have to be very experienced with different code debuggers?

Well, if the emulator doesn't do things the way it's supposed to, like corrupting memory addresses or registries, triues to load the wrong stuff or hangs when executing some part of the code....You'll need the ddebugger so you can see what goes on in the memory, how the emulator handles the memory while code is being executed, and what could be done to fix possible bugs. That's why it's called a debugger.

 

Sure, altering the code itself works most of the time too, but you'll need the debugger along with it to see the memory calls, interrupts and other very useful stuff.

 

As for the Gameboy, I'd say that's a pretty good choice.

[taratata]

OK I see; I was mislead by the "different debuggers" part. I'll just use the included debugger

[ugenn]

Assembly language knowledge is not optional in creating emulators. Not only must you be proficient in it, you also have to know the instruction set and architecture inside-out. After all, an emulator is really a virtual machine that simulates the behavior of the target environment.

[taratata]

Assembly language knowledge is not optional in creating emulators. Not only must you be proficient in it, you also have to know the instruction set and architecture inside-out. After all, an emulator is really a virtual machine that simulates the behavior of the target environment.

Well, you have to know the target environment's instructions set and architecture, but not those from the processor it will run on. Assembly in itself is quite simple, it's writing a program in it that's really a pain in the ass.

 

I found a document on zophar.net about Super Gameboy: has anyone ever heard about that? I've never even heard the name before.

[Ash_crimson]

Assembly language knowledge is not optional in creating emulators. Not only must you be proficient in it, you also have to know the instruction set and architecture inside-out. After all, an emulator is really a virtual machine that simulates the behavior of the target environment.

Well, you have to know the target environment's instructions set and architecture, but not those from the processor it will run on. Assembly in itself is quite simple, it's writing a program in it that's really a pain in the ass.

 

I found a document on zophar.net about Super Gameboy: has anyone ever heard about that? I've never even heard the name before.

ive heard of gameboy, gameboy pocket, gameboy pocket color, gameboy color ang gameboy advance but never super

[Agozer]

There is indeed a Super Gameboy, I think it was like an add-on cart for the SNES that let you use Gameboy carts in SNES, In color too. It had some other features as well that made it stand out from the Gameboy, but I've forgotten what those were

Edited May 26, 2004 by Agozer

[random guy]

There is indeed a Super Gameboy, I think it was like an add-on cart for the SNES that let you use Gameboy carts in SNES, In color too. It had some other features as well that made it stand out from the Gameboy, but I've forgotten what those were

That might be a cool place to start!

[Ash_crimson]

There is indeed a Super Gameboy, I think it was like an add-on cart for the SNES that let you use Gameboy carts in SNES, In color too. It had some other features as well that made it stand out from the Gameboy, but I've forgotten what those were

That might be a cool place to start!

so would that be emulationg a gameboy? or a snes game/addon capable of playing gameboy games???