Aaron's To-Do List

Note that nothing here is a promise. This all just represents ideas in my head. Who knows if I'll get to it all!

General

• Integrate proper localization (work with MAMEPlus!)
• Compile with UNICODE=1 for all builds (will deprecate Windows 9x support)
• define & implement more general pipe-like interface for external communication
• change OSD sound interface so it creates sound "targets" much like render targets
• allow setting of realtime clock to fixed value from command line for regression testing

CPUs/Timing

• universal DRC backend
  • define common IR that all DRCs compile to
  • write backends for x86/x64
  • also write canonical "C" interpreted backend, designed to be run in parallel
  • update MIPS3 DRC to the new backend
  • look into TMS32031 and/or ADSP support
• investigate and fix TMS32031 calculation bug
• replace cpuexec.c and timer.c with more generic scheduler
• add MDRV_SCANLINE interrupt generators
• change MDRV_CPU_VBLANK_INT to specify a screen number
• change MDRV_INTERLEAVE to specify interleave as per-second, not per-frame
• add timed interrupt generator: cpunum_toggle_input_line_timed(cpu, input, time). This will ASSERT_LINE immediately and then CLEAR_LINE after the specified time. 'time' can be zero, which is equivalent to PULSE_LINE, though perhaps we should discourage such usage since it's not realistic. If you've asserted the line via this function, and another cpunum_assert_input_line_timed() call is made, it will override the previous CLEAR_LINE time with the new time. Note that this is not a proper wire-OR, so we could alternatively reschedule the CLEAR_LINE to the maximum of the new time and the previously pending time.

Debugger

• convert to using pipes
• separate debugger from core application
• add timer window
• add CHD viewer window

Devices

• create new generic device model based off of sndintrf
  • devices are specified in machine driver with tags, just like sound cores (except tags are required)
  • generic device I/O handlers that can be referenced via new memory map primitives
• convert sound cores into generic devices
  • how does routing work?
  • fix routing anyways

3D

• Add texture management to poly.c
  • Accepts array of 8 32-bit parameters
  • Hashes those parameters and performs lookups
  • Automatically manages via LRU
• Pre-compute textures in voodoo at upload time and remove on-the-fly format conversion for a bit more speed

Video

• fix drawgfx/palette global palette-ness
• render crosshairs in UI layer not in game containers
• game-specific crosshair bitmaps and sizes
  • user selectable?
• fix crosshair rendering to understand scale and offset factors
• font improvements:
  • start with built-in font, then load others
  • standardize on BDC as the font format, provide BDF2BDC converter
  • find a good unicode font
  • user-selectable at runtime via menu?
• add laserdisc video viewer in F4 menu if A/V CHD is attached
  • support straight playback with frame info
  • single step forward/back

Outputs

• convert output system to use pipes
• add ability to get XML description of current game

Drivers

• write tests to figure out 3dfx mipmapping algorithm
• remove use of MDRV_VBLANK_INT(count) where count > 1
• cliffhgr.c:
  • add proper latching/buffering to ensure no dropouts
  • fix 9928a emulation to match screenshot
• 3DO-based systems

Documentation

• write debugger documentation
  • Debugger basics (covers the main window, the keyboard shortcuts, and a couple of very basic commands)
  • Viewing memory (covers disasm/dump, memory and disassembly windows)
  • Breakpoints and watchpoints (covers basic breakpoints and watchpoint usage)
  • Expressions (covers using expressions to change values and the whole expression syntax)
  • Advanced breakpoints and watchpoints (covers conditionals, actions, etc)
  • Other techniques (covers tracing and other things)
• write description for how to compute crosshair parameters

Other Stuff

• look into inpout32.dll for hooking up ZVG to WinMAME

Scheduler

• Clients register with two callbacks (CPUs and sound cores are clients; video as well)

typedef mame_time (*scheduler_execute_callback)(void *parameter, mame_time curtime, mame_time target);
typedef void (*scheduler_abort_callback)(void *parameter, mame_time abort_time);

scheduler_client *scheduler_client_register(scheduler_execute_callback execute, scheduler_abort_callback abort, void *parameter);

• Events can be requested, and can cause synchronization between limited groups of clients

typedef void (*scheduler_event_fire_callback)(mame_time curtime, void *parameter);

scheduler_event *scheduler_event_register(mame_time event_time, scheduler_event_fire_callback callback, void *parameter, const scheduler_client **sync_list);

• The current execution can be aborted (this is implicitly done if an event is registered that times out in the middle of the current execution):

void scheduler_abort_execution(void);

• Clients can be suspended/resumed:

void scheduler_client_suspend(scheduler_client *client, UINT32 reason_mask);
void scheduler_client_resume(scheduler_client *client, UINT32 reason_mask);

• Scheduler owns global time and local time for each client:

mame_time scheduler_get_global_time(void);
mame_time scheduler_client_get_current_time(scheduler_client *client);
mame_time scheduler_event_get_fire_time(scheduler_event *event);

• Scheduler keeps track of real time spent executing (debug only?)

osd_ticks_t scheduler_client_get_real_time(scheduler_client *client);