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

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).

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.

As you say, it depends on the goal here, but a standalone program that
interrogates the mame drivers on-the-fly to produce a very good starting point
for a 9010 script would probably expose a lot of the pitfalls.

Based on how that goes / went, the dicision would probably be easier.

You could of course get the standalone program to populate another table which
contains the actual retrieved memory map itself, stored as the above mentioned
"mame memory map" for integration into ggdb perhaps (incidentally, I wish I knew
that was there before!)

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).

I have to dash out now, but I'm sure you could traverse that link with the
correct indexing so a game could dynamicly access it's memory mamp. So, Galaxian
uses device 1, map 3 say.

Think I may be waffling off the point a bit though :O)

Martin.

> -----Original Message-----
> From: owner-techtoolslist@www.flippers.com
> [mailto:owner-techtoolslist@www.flippers.com] On Behalf Of
> James S. Bright
> Sent: 16 September 2003 14:36
> To: techtoolslist@www.flippers.com
> Subject: Re: [techtoolslist] Work in progress, opinions...
>
>
> Message
> You guys have brought up some good points... So... for those
> of you that care, I'll share a little of my database schema
> and explain the few pitfalls I currently have. If you can
> bear through reading this, and offer suggestions, it may help
> clean up a few points.
>
> [Brief background: ggdb.com was originally created because we
> were taking a lot of pictures and writing lots of
> descriptions on the same game over and over again. We also
> wanted a way to record game specific technical information,
> we I created a way to reference that information from our
> inventory system. It started from that, but I have always
> wanted to build out the technical side of it.]
>
> In the database there is a primary record called simply "A
> Game". A Game is something like "Pac-Man", "Galaxian", even
> "Mars God of War." Off of that, there are associated records
> called "Game Entries" that have properties like Class and
> Sub-Class, Manufacturer, Year, and so on. For example, there
> may be 1980, Bally Midway, 'Coin-op', 'Arcade' that relates
> to the Pac-Man main entry. The picture looks a little like:
>
> [Game] 1 --- oo [Game Entry]
> + 1 ------ oo [Game Images]
> + 1 ------ oo [Game Links
> (manuals, etc)]
> + 1 ------ oo [Game Articles (tech)]
>
> Game is used to associate different, be related items. For
> the purpose of this discussion we can just refer to the Game
> Entry because that is what everything keys off of.
>
> Before I attempted to merge in the MAME code, I was building
> out a database that could be used to manually build data
> maps. I was working on something a little like:
>
> [Game Entry] oo ----- oo [Game Board]
> + 1 ----- oo
> [Memory Map Entry]
> + 1 ----- oo
> [Chip List]
> + 1 ----- oo [Pinout]
>
> Take an example like Q*bert. The entry for Q*bert would refer
> to the "System 80 Sound Board" that may in turn be referenced
> in other games (Krull, other system 80 pins, etc.). That
> board would have entries for the memory map, and (if I was
> crazy enough), it would have the part list for cross
> reference/documentation purposes. It would look like:
>
http://ggdb.com/tech/Board.aspx?g=2221&l=6&b=6

And now I'm trying to match my Game/Game Entry (all of the "Coin-op"
entries) to what is in MAME. Part of the problem is that MAME is ROM centric.
All of the machine & driver information is set up and duplicated for each and
every game. So I have a few choices in matching MAME information to what I was
currently working on. They include choices like:

METHOD A: Just keep MAME separate anyways because it won't always match reality.
May be a little confusing, but very accurate. A separate "ROM Set" table would
exist and reference a given Game Entry. Besides, keeping it separate reinforces
the fact that this is what MAME does, not necessarily what the real world does.

METHOD B: Attempt to find the "best match" for a game and use that to build the
memory map. For example, pick the best "Pac-Man" driver and match it to the
corresponding entry in the ggdb. Problem: will drop a lot of ROM variants (NOTE:
a stand alone ROM table could be added on, and be made to work like the
"cloneof" works in the code.)

I am leaning towards Method A right now because it keeps the most data, and is
the easiest to match up (mostly by name).

Anyway, that is the gory details of the problem. There is just a lot of data and
people think of it in a lot of different ways, depending on your goals.

--James Bright
www.QuarterArcade.com
Restored Arcade Games for your Home
Received on Tue Sep 16 09:21:31 2003