Aaron's To-Do List: Difference between revisions

From MAMEDEV Wiki
No edit summary
No edit summary
Line 1: Line 1:
Note that nothing here is a promise. This all just represents ideas in my head. Who knows if I'll get to it all!
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==
==High-level==
* Integrate proper localization (work with MAMEPlus!)
* convert sound cores into devices
* Compile with UNICODE=1 for all builds (will deprecate Windows 9x support)
* make scheduling a device thing instead of a CPU thing, allowing any device to participate
* 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
* define & implement more general pipe-like interface for external communication
* change OSD sound interface so it creates sound "targets" much like render targets
* 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
* allow setting of realtime clock to fixed value from command line for regression testing


==CPUs/Timing==
==CPUs==
* write x86 DRC front-end, unifying all x86/NEC variants
* investigate and fix TMS32031 calculation bug
* 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==
==Debugger==
* add timer window
* add CHD viewer window
* make workable in a fully command-line fashion
* convert to using pipes
* convert to using pipes
* separate debugger from core application
* 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==
==3D==
Line 36: Line 29:


==Video==
==Video==
* fix drawgfx/palette global palette-ness
* render crosshairs in UI layer not in game containers
* render crosshairs in UI layer not in game containers
* game-specific crosshair bitmaps and sizes
* game-specific crosshair bitmaps and sizes
Line 46: Line 38:
** find a good unicode font
** find a good unicode font
** user-selectable at runtime via menu?
** 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==
==Outputs==
Line 74: Line 63:
==Other Stuff==
==Other Stuff==
* look into inpout32.dll for hooking up ZVG to WinMAME
* 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);

Revision as of 00:25, 8 January 2009

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

High-level

  • convert sound cores into devices
  • make scheduling a device thing instead of a CPU thing, allowing any device to participate
  • 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

  • write x86 DRC front-end, unifying all x86/NEC variants
  • investigate and fix TMS32031 calculation bug

Debugger

  • add timer window
  • add CHD viewer window
  • make workable in a fully command-line fashion
  • convert to using pipes
  • separate debugger from core application

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

  • 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?

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
Retrieved from ‘https://wiki.mamedev.org/index.php?title=Aaron%27s_To-Do_List&oldid=1946’