Until a couple years ago the core was not actively maintained either but trapexit took over after investigating a screen tearing bug and continues to work on the project.
Top hotspots found while profiling
freedo_arm_execute
freedo_dsp_loop
TexelDraw_Arbitrary
dsp_operand_load
vdlp_render_line*
Super Street Fighter 2 seems to rely on VINT1. The calculation for VINT1 appears to be wrong. The symptom is most obvious on the intro animation. The thunder is out of sync with the lightening. The Japanese demo does not have this issue though. Code is in freedo_3do.c and freedo_clio.c. Turns out the animation problem is a bug in the game. Would be interesting to compare the demo with retail to see if it could be fixed.
Figure out how to get the diagnostic port working and to trigger built in tests in the ROM.
Emulate a larger NVRAM. Seems like there is at least room for another 32KB above the existing 32KB.
Add HLE for DSP instruments. The 3DO Company never released development tools for the DSP so most if not all games used 3DO provided “instruments”. These could be statically compiled and embedded into the codebase and SWIs caught to emulate.
Add HLE of the NVRAM filesystem access. Save files to host directly rather than in the emulated NVRAM.
Attempt to improve XBUS / CDROM performance. Mnemo's USB adapter loads faster than the emulator on Wolf3D.
Auto set mode (NTSC,PAL1,PAL2) and ROM based on game support.
Figure out software reset. Writing 0x30 during vblank to CLIO register 0x28? Function 0x0303706C in FZ-10 ROM.
HLE (high level emulation): HLE of the matrix arithmatic OperaOS SWI calls have been implemented which improves performance on some lower end systems. Adding more high level emulation could further improve performance. Other
SWI calls are an obvious target.
Add support for different hardware revisions: there is already the ability to toggle between the wire wrapped and Green MADAM chips (the former missing matrix hardware). It'd be nice to support all CLIO, MADAM, and RAM configurations. Even ones that may not have existed (
like increased RAM).
PAL support: most things are hard coded for NTSC and/or lack proper emulation to support PAL devices. trapexit is actively working on this.
VDLP improvements: the VDLP is only emulated enough to get most games to function. It is missing interpolation support among other features.
Understand why the VDLP needs a hard coded VDL to see software's Banner at boot and why not all show.
ARM core: the ARM CPU core is messy. It takes up a large portion of the emulation time and I suspect performance could be improved quite a bit.
DSP core: the DSP should be more bespoke of a component in the codebase and if properly isolated could likely be safely* put into it's own thread to improve performance. (* libretro 4DO has a multithreaded mode which does this but is experimental. Critical sections have not all been safely managed.)
CEL rendering: the CEL rendering code is messy and difficult to read. There are lots of generic codepaths with conditionals all over. If these code paths could be streamlined and branching done earlier in execution the readability and performance could be improved.
Hacks: there are a number of specific game hacks in the code. Likely due to improper emulation. Fixing these would help simplify and cleanup the code.
Emulate MADAM memory fences?
freedo_clio.c: clio_handle_dma - if and else are the same code?
Add keyboard support. No games use the keyboard
API as far as we know but for homebrew it could be useful.
Fix lightgun support. The lightgun protocol is apparently incorrect. While the code currently “works” it is not fully function or accurate.
Create a new frontend (or incorporate something into the libretro core) with the aim of supporting 3DO homebrew development and debugging
break points
instruction stepping
disassembly
memory viewer
SWI viewer
etc.
-
If you are interested in helping with any of these or on 3DO homebrew please join us over on Discord: https://discord.gg/kvM9cQG