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

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