Re: [techtoolslist] Work in progress, opinions...

Well given that MAME's creed, "the main purpose of the project is to
document the hardware (and software) of the arcade games."

Is there any interest in from the MAME programmers to intergrate or support
our hardware centric work?

Or is there some benefit of overlaying?

The ultimate tool would be a database of components, nodes & software
descriptions per board that then can be exported to a SPICE simulator of
some type. But I think that is a few years out yet?

Kev

> > Am I oversimplifying things by thinking you could have a seperate table
> > containing all the mame drivers with a unique ID (1,pacman.c 2,glaxian.c
> etc),
> > and then each of your game level entries references one of those
records
> (1 or
> > 2 etc).
>
>
> Yes, this is probably a likely scenario now.
>
> [Game Entry] 1 --- oo [MAME Virtual Machine]
> + 1 --- oo [Addy Entries]
>
>
> > You could I guess potentially have two entries, one for the mame driver
> memory
> > map and one for the actual memory map if it's different. I think this is
> then
> > leaning towards A.
>
> Something that I thought about. I'd probably roll it right into the Game
> Entry table (or the equivalent). *OR* have a mechanism to verify/validate
> the map generated from MAME. How important is it to be able to refresh the
> "MAME Virtual Machine" from new versions of MAME? If I want to keep
updating
> the database with new version, then I probably want to keep that part
> separate (even if it is inaccurate) and then have "actual" real world
> hardware rolled right into the Game Entry table. That would be where guys
> like us put in things by hand. The MAME Virtual Machine would be
> auto-refreshed once a quarter or something.
>
> > SO, you would have, a table of driver files, which would exist on a many
> to one
> > basis (one or more games referencing each driver file). Then you would
> have a
> > memory map table which is referenced on a one to many basis with the
> drivers
> > table (each driver has at least one memory map within it).
>
> Yes. Gets a little more complicated because each MAME driver has one or
more
> CPUs (not illustrated in my drawing), with each CPU having its own memory
> map. But, yes, that is what I'm thinking too.
>
> Okay, so I am leaning towards Method A (MAME data is referenced and
matched
> up to my entries), as it allows people to browse the MAME entries and
review
> the implementation right down to the source code. And that does not
preclude
> me building out the part that has real world references to individual
boards
> and components. Something that is lost in MAME...
>
> --James Bright
> www.QuarterArcade.com
> Restored Arcade Games for your Home
>
>
Received on Tue Sep 16 09:21:31 2003