MooglyGuy's To-Do List

My To-Do list, in no particular order:

• Write an ARM7TDMI JIT frontend, so things like 39in1 and gp32 have a snowball's chance in hell of running full-speed.
• Write an ARM32 JIT backend, so things like Killer Instinct and Seattle games can hopefully run full-speed on modern ARM chips.
• Write an ARM64 JIT backend, for similar future-looking reasons.
• Refactor the way screens are presented to the OSD, and refactor the way the OSD handles these screens. Ideally I want screens to simply be nodes in an overall scene graph, consumable by a standard scene issuing an orthographically-projected quad per window, showing the game content, but also potentially consumable by, say, a 3D model of an arcade cabinet which has its own material which has a shader effect that consumes the screen texture instead.
• Look into leveraging more of BGFX for things like compute shader jobs. The current bleeding-edge low-level N64 RDP emulation is more or less a brute-force approach, shoving angrylion's code as unmodified as possible into a compute shader. I'm positive that it's possible to simply emit a branch-flattened version of the pixel rendering loop for a given set of RDP state, and cache it for later use since games most likely don't use one-off RDP configurations, in order to be friendlier in terms of our GPU access patterns.
• Work on device-ifying more of the SGI Indy driver. It's pretty much the first driver that I wrote almost entirely on my own, with a hand from Arbee here and there, and I wrote it when I was still at university. With twelve years in the game industry under my belt, I look at my old code with a pretty jaded eye, and I know I can do better these days. With any luck, it may even make the driver more functional.
• Try to rally enough interest for people to look into making the sun4 driver actually chat more successfully with the SCSI controller. At this time I'm not sure if it's shortcomings with the 53C90 controller, or shortcomings with how the DMA controller is handled by the sun4 driver. I suspect the latter.
• Look into adding support for the R5900 "Emotion Engine" version of MIPS, at least enough to get the correct CPU type in the PS2-based drivers, and potentially running at least some actual boot code. Part of the problem is that I need someone to point me directly at some good solid PS2 hardware documentation, including that of the Emotion Engine and especially VU0/VU1. Previously, every time I've looked at the EE, I've spotted the various SIMD instructions it has, and gone, "Y'know what, leave it" in pretty short order.
• Cycle-accurate NES PPU. The documentation is out there on NESdev, and we have the cycle-accurate, interruptible CPU core. It's just a matter of time stopping anyone from doing it, the documentation is plentiful.
• Do more reverse-engineering of the 68HC05 "SERVO" MCU that we have a dump from, in the CD-i driver. Also start reverse-engineering the "SLAVE" MCU, as this will hopefully fix some input issues that the driver currently has. Since the Quizard games interfaced with the CD-i player through its serial port, which was in part managed by "SLAVE" in certain models, this could in fact result in additional arcade games in MAME being promoted to working, if I or anyone else put in the time.
• In the interim before GPU-accelerated RDP is production-ready, investigate using the DRC/JIT system to accelerate the RDP rendering instead, caching recompiled blocks based on a hash of the RDP state that affects rendering. There's no reason someone couldn't already make use of the DRC/JIT system to accelerate things other than CPUs, it's just nobody has bothered at this point.
• Look into emulating more discrete games, as well as get Stunt Cycle debugged and working.

Old To-Do List follows:

• Finish writing "Let's Emulate Space Invaders!" article for MAME dev wiki.
• HLSL short-term plan: Improve shadow mask simulation by operating at very-high-res internally and splitting the frame across multiple quads in order to stay below individual texture size limits, then performing repeated 4x4-averaging downsizing passes to scale to the target resolution for maximum visual quality.
• HLSL mid-term plan: Vector post-processing support. This is tricky, as currently there is a non-trivial amount of overhead from dispatching quads in immediate mode, and with each vector as an individual quad, performance goes south very quickly. However, this will need to be rectified in order to eventually support hardware rendering of individual polygons for 3D hardware.
• HLSL long-term plans:
  • Add a GLSL port of my CRT shader suite.
  • Add support for shader-based hardware rendering of 3D hardware polygons.
• N64 driver improvements (MAME/MESS):
  • Continue performance profiling and branch flattening in the RDP renderer.
  • Accelerate the RDP renderer by threading off non-overlapping triangles.
  • Emulate the 64DD peripheral.
  • Emulate the Transfer Pak peripheral.
• Continue improving the 8-bit Atmel AVR core and emulate "Craft", by [lft], in MESS.
• CD-i Improvements (MAME/MESS):
  • Work out more of the communications protocol in later versions of Quizard. This may require decapping or an actual CD-i unit on which to run tests, as inputs and possibly other things like protection are handled by a small PCB with an 8051 MCU on it that communicates with the base CD-i unit through the standard rear serial port.
  • Work out more of the CDIC behavior. Specifically, work out how to make Zelda's Adventure not hang when walking onto the next screen while also not making Lemmings crash immediately upon playing PCM audio.
  • Possibly emulate other CD-i models in order to improve compatibility by cross-checking behavior on different hardware revisions.
• Palm improvements (MESS): Add support for more hardware revisions by emulating the different 68k system-on-a-chip revisions.

If anyone wants to take these tasks off my plate, please feel welcome to do so.