mame
mame copied to clipboard
mamedev
License-compatible code we might want to import
This is not a comprehensive list or a specific to-do, more like a brainstorm. Add more if you know of them.
- Virtual Jaguar. Custom chip cores are based on MAME's and GPLed. Kind of ugly code in parts, and currently not maintained.
- ~~The ARM core and/or complete Archimedes emulation from a standalone? Or at least adapt it to have enough debugger visibility so we can compare execution to MAME and bugfix our support.~~ (updated Nov. 2 2016 - Archimedes now runs in MAME)
- Bochs has an enhanced version of SoftFloat with full exception reporting. This will eventually be necessary for true, 100% x87 and 680x0 FPU emulation, among others.
- Mini vMac has a more complete 680x0 FPU emulation than we do, which is also based on SoftFloat.
- The original author has released SoftFloat 3, which has a nice BSD license and is much faster on some operations. Maybe look into that?
- ReSID. Our current SID emulation is... not good. And there apparently are hostile licensing intentions surrounding at least one effort that's working from decap images.
- Our Game Boy sound emulation is not very good. blargg has an LGPL library at http://www.slack.net/~ant/libs/audio.html#Gb_Snd_Emu and the Mednafen tree has what looks like a more updated version. It's tied into his whole band-limited synthesis thing which could be hard to untangle and/or at odds with OG's plans for a general-purpose resampler. Judge or Lord_Nightmare may also have some WIP in this area.
@DopefishJustin That core uses a bunch of weird time-skip bullshit to kludge the timings into working right, according to byuu.
My suggestion is importing the PCI code from PCem!
FWIW, I started working on the gameboy sound core last night. Not sure when and if it will be finished.
We have an excellent PCI framework, currently used by iteagle.cpp and (minimally) by atlantis.cpp. The ES137x sound card and the 3dfx cards are available as pluggable devices thus far. We just need to emulate the PCI host, which is usually part of the south bridge.
@rb6502 Okay, what about the ATAPI code from PCem? After all, it does work a lot better than MAME's. :^)
How so? MAME has disc switch support now on PC. (I recall that was your hobby-horse, anyway).
Aside from assimilating emulation related open source code, it might be useful to find and incorporate libraries that will make the whole I/O as portable as possible. Like BGFX for graphics rendering, look what's out there for audio output and generic input handling. Also VLC code can be used to add videosnap feature to new GUI (see #840). Also fs-uae is open source which could take Amiga (and related) emulation years ahead. That said, I've contacted the author and he is not interested to help (but that doesn't change the fact that the code is GPL-2.0).
Nick: " author and he is not interested to help" is that related to PCem or fs-uae ?
On Wed, May 11, 2016 at 5:32 PM, Nick Sardelianos [email protected] wrote:
Aside from assimilating emulation related open source code, it might be useful to find and incorporate libraries that will make the whole I/O as portable as possible. Like BGFX for graphics rendering, look what's out there for audio output and generic input handling. Also VLC code can be used to add videosnap feature to new GUI (see #840 https://github.com/mamedev/mame/issues/840). Also fs-uae is open source which could take Amiga (and related) emulation years ahead. That said, I've contacted the author and he is not interested to help (but that doesn't change the fact that the code is GPL-2.0).
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/mamedev/mame/issues/838#issuecomment-218496359
If we pull from UAE, it'll be from upstream WinUAE. Toni's pretty friendly as long as we're doing the work :)
Thumbs up for Bochs CPU code. "Design and Testing of a CPU Emulator", a paper from Microsoft Research, located at http://research.microsoft.com/pubs/102035/techeport%20cpu_test%20v4.pdf suggests there are unemulated 808x quirks Bochs handles correctly (see paragraph 5.1 "When the Specs Are Wrong").
Any kind of open source & loseless video codec, that is better than our current heavyweight raw codec as option for -aviwrite or video playback.
Lagarith looked like a candidate.
OG.
On Sat, Jul 23, 2016 at 6:07 PM, Angelo Salese [email protected] wrote:
Any kind of open source & loseless video codec, that is better than our current heavyweight raw codec as option for -aviwrite or video playback.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mamedev/mame/issues/838#issuecomment-234726014, or mute the thread https://github.com/notifications/unsubscribe-auth/AI0i8fP6DUWN8K85TFCHm3XwW7YPb08Vks5qYjxEgaJpZM4IRTCP .
@angelosa It's very handy to just use gzip. Here's an example of its implementation: http://repo.or.cz/lsnes.git/blob/HEAD:/src/video/avi/codec/video/cscd.cpp The same method if used in camstudio lossless codec. It allows gzip compression levels, not all other lossless codecs can do that.
Otherwise, here's my post with a bit more details: https://github.com/mamedev/mame/issues/1894
