This shows you the differences between two versions of the page.
software:emulation_improvement_opportunities [2022/11/07 14:49] – created trapexit | software:emulation_improvement_opportunities [Unknown date] (current) – external edit (Unknown date) 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | The only actively developed, open source 3DO emulator is the [[https:// | ||
+ | |||
+ | 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. | ||
+ | |||
+ | Here is a list of enhancements and improvements | ||
+ | |||
+ | * Top hotspots found while profiling | ||
+ | * freedo_arm_execute | ||
+ | * freedo_dsp_loop | ||
+ | * TexelDraw_Arbitrary | ||
+ | * dsp_operand_load | ||
+ | * vdlp_render_line* | ||
+ | * < | ||
+ | * 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 " | ||
+ | * 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' | ||
+ | * Auto set mode (NTSC, | ||
+ | * 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 [[documentation: | ||
+ | * 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 ([[documentation: | ||
+ | * < | ||
+ | * [[documentation: | ||
+ | * Understand why the VDLP needs a hard coded VDL to see software' | ||
+ | * 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: | ||
+ | * 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 " | ||
+ | * 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. | ||
+ | * [[https:// | ||
+ | |||
+ | If you are interested in helping with any of these or on 3DO homebrew please join us over on Discord: [[https:// | ||
+ | |||