Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

License-compatible code we might want to import #838

Open
rb6502 opened this issue Apr 27, 2016 · 14 comments
Open

License-compatible code we might want to import #838

rb6502 opened this issue Apr 27, 2016 · 14 comments
Labels
spike Discussion based issues with no clear "close" condition

Comments

@rb6502
Copy link
Contributor

rb6502 commented Apr 27, 2016

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.
@DopefishJustin
Copy link
Member

  • 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.

@fuel-pcbox

This comment was marked as abuse.

@wilbertpol
Copy link
Contributor

FWIW, I started working on the gameboy sound core last night. Not sure when and if it will be finished.

@rb6502
Copy link
Contributor Author

rb6502 commented Apr 28, 2016

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.

@fuel-pcbox

This comment was marked as abuse.

@rb6502
Copy link
Contributor Author

rb6502 commented May 11, 2016

How so? MAME has disc switch support now on PC. (I recall that was your hobby-horse, anyway).

@NULUSIOS
Copy link

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).

@mmicko
Copy link
Member

mmicko commented May 11, 2016

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 notifications@github.com
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
#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
#838 (comment)

@NULUSIOS
Copy link

fs-uae.

@rb6502
Copy link
Contributor Author

rb6502 commented May 13, 2016

If we pull from UAE, it'll be from upstream WinUAE. Toni's pretty friendly as long as we're doing the work :)

@Bavarese
Copy link
Contributor

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").

@angelosa
Copy link
Member

Any kind of open source & loseless video codec, that is better than our current heavyweight raw codec as option for -aviwrite or video playback.

@galibert
Copy link
Member

Lagarith looked like a candidate.

OG.

On Sat, Jul 23, 2016 at 6:07 PM, Angelo Salese notifications@github.com
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
#838 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AI0i8fP6DUWN8K85TFCHm3XwW7YPb08Vks5qYjxEgaJpZM4IRTCP
.

@vadosnaprimer
Copy link
Contributor

vadosnaprimer commented Dec 30, 2016

@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:
#1894

@angelosa angelosa added the spike Discussion based issues with no clear "close" condition label Jan 28, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
spike Discussion based issues with no clear "close" condition
Projects
None yet
Development

No branches or pull requests

10 participants