UNIversal System Emulation Framework (UNISEF)

[dcook32p]

As a few of you may know, I announced my intention to develop a low-level Nintendo 64 emulator in <a href="http://www.emutalk.net/showthread.php?threadid=16062">this thread</a> [emutalk.net].

I started work last night on a formal software development plan for this emulator, and I had an even better idea.

I propose to create a framework under which future emulators for any system can be developed and current emulators can be ported. It will build on the already useful plug-in architecture of certain PlayStation and Nintendo 64 emulators while offering portability between platforms, independent component development and re-use, and an optional layer of abstraction available to "homebrew" game and application developers who would like to develop their software in a high-level language.

Several previously unrelated components will need to be brought together before something like this could happen. For instance, the abstraction layer requires assemblers for each architecture supported and compatible targets added to existing compilers. Portability will require a platform independent program "kernel" to be developed to allow messaging between the different modules (more below). And the modules themselves will need a highly-specific standard by which to communicate.

In other words, how will the NES CPU module communicate with the PPU module, on-cartridge "mapper" chip, and the VRAM image? Since most emulators are written as one big program rather than multiple modules linked together, this hasn't really been an issue. Would a messaging system not unlike that integrated into the GNU/Hurd kernel be optimal for our purposes?

I am calling the project UNIversal System Emulation Framework (UNISEF) in recognition of the fine work of the United Nations Children's Fund (UNICEF). This project is copyrighted under the <a href="http://www.gnu.org/licenses/gpl.html">GNU General Public License</a> [gnu.org] version 2.0.

I look forward to reading any ideas the community may have. Please note that by posting to this thread you are giving me the right to use your idea in this <a href="http://www.gnu.org/philosophy/free-sw.html">free software</a> [gnu.org] project.

The ideas herein are (c) 2003 Dustin D. Cook under the <a href="http://www.gnu.org/licenses/fdl.html">GNU Free Documentation License</a> [gnu.org] version 1.2.

 

[ShadowPrince]

Beside funky name for your project,this idea is anything but new. Take a look at <a href="http://www.mame.net/"> MAME</a> or <a href="http://www.mess.org/">MESS</a> , those are two projects,similar to what you describe, one for arcade machines and another for consoles and computers.
Despite of rather bad performance relatively to stand alone emulators,i must admit those two are very impressive emulation projects ,growing and improving quickly.

 

[Lillymon]

Perhaps developing a Nintendo 64 driver for MESS would be the way to go?

 

[Remote]

What I would like to see is a emu which emulates all avalible nintendo consoles, a good and very user freindly gui with a good doze of self thinking is probaly required though to not get lost in all avalible options... But sadly I don't see that happening anytime soon, since the end result is avalible anyways..

 

[dcook32p]

MAME and MESS vs. UNISEF

Beside funky name for your project,this idea is anything but new. Take a look at <a href="http://www.mame.net/"> MAME</a> or <a href="http://www.mess.org/">MESS</a> , those are two projects,similar to what you describe, one for arcade machines and another for consoles and computers.

There are a few fundamental differences between their implementations of this idea and my proposed framework.

<ol>
<li>Neither system allows "homebrew" developers to work in their high-level, non-byte-code language of choice (C, Fortran, PASCAL, etc.) to write their work. UNISEF will provide for this using several existing and new tools (see below).</li>
<li>Although MESS seems to be a bit more modular than MAME, neither of them come close to what I envision UNISEF to be. The framework doesn't just allow people to develop "drivers", but instead it allows people to develop individual components of systems in a more thorough and accurate way. So, for example, instead of developing a Famicon Family Computer / Nintendo Entertainment System driver a developer would create a 6502 module, a Famicon PPU module, and multiple modules for mappers. Various "disk images" could be created for the Famicon / NES VRAM and the cartridge's internal RAM.</li>
<li>And we don't stop there - input and output modules can be developed to interface (through a well-documented and defined API) with these modules allowing new and old input methods to be used. If you want to output to a PAL television then create a module that takes video output from the PPU and sends it either directly to your TV-out port or to your display driver to let it handle the load. Do you want to output to a MPEG-1 movie? Great! Write a module for it. Do you want to develop a keyboard for the Famicon? Great! Write an input module for it.</li>
<li>With the power of a messaging-based program kernel, the program allows even greater flexibility than the current crop of multi-machine emulators. Greater flexibility for ROM hackers and game developers in debugging their applications, a comprehensive standard by which the framework can communicate with other components over a network connection (Kaillera is, as far as I'm concerned, a closed standard that does not allow industry collaboration), the ability to write cross-platform compatible software without having to use multiple emulators, software development kits, and programming languages, and other great things make this project unique.</li>
</ol>

Yes, this is incredibly ambitious. Yes, this is bordering on insanity. But it's not impossible, and it hasn't been done before.

The ideas herein are (c) 2003 Dustin D. Cook under the <a href="http://www.gnu.org/licenses/fdl.html">GNU Free Documentation License</a> [gnu.org] version 1.2.

 

[pandamoan]

i like it dude, it makes way more sense in many ways than some of the other emulation techniques i have seen. and i like it's hardware/software emulation idea altogether.

Hell if you have enough electronic components emulated accurately by modules, you could build any piece of equipment purely in software, and inventers / electronic tinkerers could test their devices rather fully before construction.

all in all, your idea for a set of software modules emulating hardware components has a million potential very useful apps.

i'd like to make some moog / theramin type stuff with this set of tools, should it become available.

jamie

 

[Remote]

Don't grasp for too much, all that sound like a shitload of work... But if you believe you can do it and share, I'm game...

 

[dcook32p]

Sourceforge.net Project Announcement

Sourceforge.net has approved my project submission.

All further information and exchange regarding UNISEF can be found <a href="http://sourceforge.net/projects/unisef">here</a> [sourceforge.net].

<b>Edit:</b> Corrected message subject.