Aaron's To-Do List: Difference between revisions

From MAMEDEV Wiki
No edit summary
Line 9: Line 9:


==CPUs/Timing==
==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
* investigate and fix TMS32031 calculation bug
* replace cpuexec.c and timer.c with more generic scheduler
* 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
* 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.
* 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.

Revision as of 00:43, 3 June 2008

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

  • investigate and fix TMS32031 calculation bug
  • replace cpuexec.c and timer.c with more generic scheduler
  • 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);