Read Me

ModularEmu: a modular multiple architecture emulator.

Scott Lawrence
yorgle@gmail.com


----------------------------------------
Goals:

	The main purpose of the project is not to document the
	hardware (and software) of the arcade games.  

	The main purpose of this project is to allow users to have
	a good, managable emulation experience.  By having a modular
	solution that is able to update itself and retrieve modules
	automatically from various sources, the modules/drivers can
	just be dropped in.

	This emulator will also allow the homebrew enthusiast an
	easier way to test and run their patches and productions,
	legally.


----------------------------------------
Features:
	- Modular design

		- only the CPU/Sound/Video cores needed are required
		  to emulate a machine.  No reason to have extra
		  modules that you will never use or want.

		- Multiple versions of the same Module can be swapped
		  in/out as needed.  An example would be a CPU core
		  that is available in "fast", "slow but accurate"
		  and "debugging" styles.  Obviously, this is not
		  required, but it means you can have modules made
		  for space constraints that lack features that you
		  don't require.

	- support for retrieving modules from multiple repositories

		- Modules can be retrieved at runtime from a module
		  repository or collection from a website.  This
		  means that the user only needs to download the
		  core backbone, and support modules will be retrieved
		  as they are required.

		- Repository also supports machine architecture
		  files, so a user can get those files as needed.

		- Repository also supports driver files, which
		  specify which modules are needed to run.  As new
		  hardware configurations are supported, the modules
		  are retrieved automatically.


	- Multiple repositories for distruting load, local caches, etc.

		- There can be a central repository of modules, or
		  you can have a nearby cache on a custom webserver,
		  or even a cache on a local DVD-ROM or thumb drive.
		  It also allows for multiple sources to be defined,
		  so if a module isn't found in one place, it can
		  fall back on other repositories.

		- Modules (and drivers) can also be run out of a
		  read-only device, allowing for a "personality
		  disc" approach to an emulation system.  Put the
		  OS, and core executable on a small disk inside
		  an emulation cabinet, and allow roms and modules
		  to be run from DVD-ROM.  Swap in the DVD-ROM for
		  the gameset you want to play.   Or, you could
		  just use the DVD-ROM as an update source, where
		  its files are copied to an internal repository.


	- Machine architecture descriptions are in plaintext files

		- If a new "Bunny Blaster" romset variant surfaces,
		  or an enthusiast creates their own romset for an
		  existing game, no recompiling of anything is
		  necessary, as long as no driver support code is
		  needed.  The description files can be copied,
		  edited and run immediately.


	- ROM load routines support binary file patches

		- If you have a patch for a copyrighted romset,
		  you can legally distribute just the binary patch
		  that has your changes in it, requiring the user
		  to obtain the roms to be patched themselves.


----------------------------------------
Development Schedule:

	- Phase 0: (Design)
		Design of the emulation architeture
		Design of APIs
		Design of machine architecture files
		cute names for each of the parts of the system

	- Phase 1: (Prototype)
		Put many of the concepts together, and see if it will work.
		

	- Phase 2: (Deployment)
		Support for OS X using libSDL as the GUI interface.