MAMEWorld Forums - EmuChat - Could we have more discrete games in MAME?

> yes, but they're a lot of work and very few people are in a position to be able to do
> them.

I have the capability, but not the time. I'm currently pursuing more consistent salaried work here in the Stockholm area, as working from home actually sucks and makes it hard to focus. For now though I still need to be crunching on the contracting gig I'm doing, at least through until mid to late June.

Once I have more free time, I'm planning on turning my sights back on Stunt Cycle. The one problem there is that there's a function generator used to generate certain basic signals related to the controls, and a couple of parts (including a specific transistor type) in addition to that one will also need to be emulated.

At least, that's my hope. I managed to get Stunt Cycle showing something on-screen while I was out in the western Swedish countryside for the holidays, with my partner and his family, so I accomplished my goal to that end, I "just" need to actually wrap it up. I would welcome anyone else taking a crack at it in the meantime, but I plan to get around to it.

In case anyone's keeping score, among other things, my to-do list includes:
- 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.

Anyway, that's off the top of my head.