Checklist for Cleaning Up Drivers

From MAMEDEV Wiki
Revision as of 13:15, 24 June 2008 by Madskunk (talk | contribs) (New page: Over the past year, I've done some driver "cleanup" work. This generally involves picking apart a driver, revisiting all the assumptions using whatever information is available, and updati...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Over the past year, I've done some driver "cleanup" work. This generally involves picking apart a driver, revisiting all the assumptions using whatever information is available, and updating it to take advantage of newer features in MAME that have been introduced since it was first written. To do this work, I keep a checklist of things to do, just to make sure I've covered all the bases. This list is constantly updated, but I figured I would share it, since it is a good set of guidelines when updating a driver or writing a new one from scratch.

Timing/interrupts:

  • all crystals on the PCB documented via #defines
  • all CPU and sound clocks derived from #defined crystal values
  • re-verify interrupt generation timing and sources
  • implement interrupt acknowledges (many older drivers didn't bother)
  • add accurate watchdog durations

Memory:

  • unified read/write memory maps (they used to be separate)
  • map the entire address space fully, if possible from schematics
  • use AM_SHARE where appropriate (better than sharedram read/write handlers)
  • convert memory banking to the new system (memory_configure_bank)

Graphics:

  • gfx layouts should use RGN_FRAC wherever possible instead of hard-coded values
  • gfx layouts that are common should be shared (vidhrdw/generic.c)
  • accurate hblank/vblank/visible areas, derived from schematics if possible
  • convert from old macros to new screen macros for display info
  • use new more accurate screen timing routines for H/V positions
  • convert to tilemaps, if applicable
  • change to use resistors for palette generation
  • add limits on sprite drawing (i.e., how many per scanline) if known

Inputs:

  • tag all input ports
  • change all port references in code to use tags
  • convert non-DIP configurations to configs
  • use PORT_CUSTOM where appropriate instead of memory overrides
  • connect coin counters (often missing)
  • connect PCB outputs via the new output system
  • add DIPLOCATIONS
  • verify DIPs and inputs

ROMs:

  • memory regions reduced to minimum size (they don't have to cover the whole address space)
  • make sure ROM names are good and accurate to what we know
  • check for any unemulated clones

General:

  • update source files to be in order: header, includes, constants, typedefs, macros, globals, inlines, code
  • update driver file to be in the same order, followed by: address maps, input ports, graphics definitions, sound configs, machine driver, ROMs, driver init code, drivers
  • add save state support
  • move all globals to hang off of driver_data
  • de-obfuscate the code where it is confusing

Actually, that's quite a lot of stuff. I'm sure I've missed a thing or two in some of my recent driver updates, but some examples that are pretty up to date include: ccastles.c, cloud9.c, missile.c, turbo.c, zaxxon.c.