The state of Emulation on Linux awareness

[ZombieRyushu]

I'd like to raise awareness to the plight of console emulation on Linux. Linux users could use good coders to fix bgs in existing Linux Emulators and other such improvements.

Here is what I have tested so far:

NES/Famicom - fceu or mednafen (mednafen may be superior due to better Turbo, and supports the FF7 for NES ROM)
Famicom Disk System - fceu or mednafen
Super NES - zsnes (sound is messed up/overmodulated) or snes-gtk (better.)
Game Boy Pocket - sdlmess gbpocket
Game Boy Color - VisualBoyAdvance or Mednafen
Game Boy Advance - VisualBoyAdvance or mednafen (mednafen may perform better?)
Super Game Boy - sdlmess (This is the only emulator that properly plays Super Gameboy games such as the first Pokemons in color.)
Nintendo 64 - mupen64plus
Atari 2600 - stella or sdlmess
Atari 5200 - sdlmess
Atari 7800 - sdlmess
Atari Lynx - mednafen
Sega Genesis - gens-gs
Sega 32x - gens-gs
Sega CD - gens-gs (broken. causes errors.)
Sega Master System - xmess.SDL or osmose (dgen is broken)
Sega Game Gear - xmess.SDL
Sega Saturn - Yabause
Sony Playstation - ePSXe or pcsx (won't full screen)
Turbo Grafx 16 - hugo (obsoleted by mednafen)
Commodore 64 - vice
Amiga - UAE (won't exit properly) or E-UAE (No sound.)
MSX - OpenMSX
Windows - wine
Linux games called from xdg-open


Planned for the future

Vectrex
Magnavox Oddessy 2
Sharp X68000
MS-DOS (dosbox.)

Among my concerns:

Gerbilsoft needs help fixing Sega CD Support under Linux.
zsnes needs its sound modulation issue fixed.
There is no viable X68000 emulator for Linux, one existed long ago, but doesn't anymore.

Arcade games have worked with either sdlmame or Xmame - I keep both configured.

For frontends, might I reccommend "WahCade". It is MameWah compatible and supports most of the stuff MameWah does. It is actively developed. Any contributions/support/patches would be appreciated

[Gapporin]

Why exactly is DOSBox "planned for the future"? You can grab Linux packages and binaries right from the web site. (http://www.dosbox.com/download.php?main=1)

[skaar]

OMG my non mainstream OS has less developed software!

The source code's all available - get fixin'!

[ZombieRyushu]

Why exactly is DOSBox "planned for the future"? You can grab Linux packages and binaries right from the web site. (http://www.dosbox.com/download.php?main=1)

DosBox works fine, it just that I don't have it tied into WahCade yet.

[roushimsx]

Mednafen is so excellent. It's a shame that there's really no decent GUI for it...if it had a GUI as sexy and streamlined as Magic Engine, those dudes would have folded up shop years ago.

For GB/SGB/GBC/GBA, you'd probably be best off with VBA-M (http://vba-m.com/), which is basically a heavily updated VBA that incorporates a ton of the various offshoots while improving the hell out of the core to fix accuracy/compatibility problems. Really nice team effort there.

Shame Mupen64 doesn't get updated much. I really like the video recording function on it.

[badinsults]

Anyone who says that Snes9x is better than Zsnes has never played a SNES (of course, if you want near perfection, bsnes also works perfectly fine in Linux)!

Also mednafen = awesome.

[ZombieRyushu]

I'm actively working with Gerbilsoft, the guy who does Gens-gs to fix Sega CD Support. He has found several errors in his code he is working to fix for "Milestone 7" Release.

I am partial to zsnes actually. I liked it better than snes9x-gtk. But it has two serious problems. It won't play some games, it won't build on 64 bit machines. (You have to cross compile 32 Bit)

ZSNES has an issue with modern Linux sound systems causing hissing, popping, whining, and constant 48000 Hz., it sounds awful.

[ZombieRyushu]

And mupen64 has moved to Google Code's mupen64plus. I have it.

[badinsults]

I'm actively working with Gerbilsoft, the guy who does Gens-gs to fix Sega CD Support. He has found several errors in his code he is working to fix for "Milestone 7" Release.

I am partial to zsnes actually. I liked it better than snes9x-gtk. But it has two serious problems. It won't play some games, it won't build on 64 bit machines. (You have to cross compile 32 Bit)

ZSNES has an issue with modern Linux sound systems causing hissing, popping, whining, and constant 48000 Hz., it sounds awful.

There is a problem with the default sound in Linux with upsampling. Try using SDL sound, and it should fix the problem. I personally use the following command to run zsnes, and I don't have sound issues:

zsnes -ad sdl -r 6

Also, the fact that Zsnes uses 32 bit assembly prevents it from being a 64 bit program.

As far as I know, there aren't many games that are not playable in Zsnes. Generally the ones that can't be played in zsnes also don't work in snes9x. I usually switch to bsnes for those.

[ZombieRyushu]

And I still have the problem.

[Jorpho]

ZSNES has an issue with modern Linux sound systems causing hissing, popping, whining, and constant 48000 Hz., it sounds awful.Hey, maybe it's the modern Linux sound systems that are desparately in need of fixing!
http://blogs.adobe.com/penguin.swf/linuxaudio.png

[ZombieRyushu]

Its an inaccurate depiction of the Linux sound system. (And I hate Pulse Audio.)

[badinsults]

Its an inaccurate depiction of the Linux sound system. (And I hate Pulse Audio.)

You must lack a sense of humour.

[tomaitheous]

Mednafen handles SMS and GG emulation as well. It's not listed, but it's there ;) WS/WSC too, but you don't have that system listed. Also, why do you have hugo listed for PCE/TG? That's super old/outdated. Regen (genesis emulator) is supposed to get a port to linux sometime (mednafen had a private version running Genesis emulation, but I doubt that'll go public anytime soon or ever.)

[ZombieRyushu]

I was unaware of this. But still, I still need a Sharp X68000 Emulator.

[ZombieRyushu]

I still need a PSX to USB adaptor.

As far as Physical control interfaces for my Mame Console, I use four Sega Genesis controllers, one PSX Controller, and a WiiMote and a Logitech Flight stick. I tried using a MayFlash Super Joy Box 5, and it malfunctioned under Linux. I wish I had a tested hardware compatibility chart of what game adapter works under Linux and what doesn't.

[ZombieRyushu]

This should fix the Sega CD Support.


commit badf3aa21d55d06b53e1fad713a6f4d4084acd97
Author: David Korth <gerbilsoft@verizon.net>
Date: Fri Jul 31 18:21:05 2009 -0400

[WTF] cpu_68k.c: Use sizeof() when specifying the size of memory blocks to clear.

Kids, there's nothing more cool than clearing a memory block. But if
someone tries to memset() you with too many bytes, that's NO good.
It's your memory; no one has the right to clear too many bytes if you
don't want them to. So, what do you do? First, you say SIGABRT! Then,
you error out with a Buffer Overflow!

This bug was reported by Zombie Ryushu.




diff --git a/src/gens/gens_core/cpu/68k/cpu_68k.c b/src/gens/gens_core/cpu/68k/cpu_68k.c
index 67702f3..453fda8 100644
--- a/src/gens/gens_core/cpu/68k/cpu_68k.c
+++ b/src/gens/gens_core/cpu/68k/cpu_68k.c
@@ -265,12 +265,12 @@ void M68K_Reset(int System_ID)
*/
void S68K_Reset(void)
{
- memset(Ram_Prg, 0x00, 512 * 1024);
- memset(Ram_Word_2M, 0x00, 256 * 1024);
- memset(Ram_Word_1M, 0x00, 256 * 1024);
+ memset(Ram_Prg, 0x00, sizeof(Ram_Prg));
+ memset(Ram_Word_2M, 0x00, sizeof(Ram_Word_2M));
+ memset(Ram_Word_1M, 0x00, sizeof(Ram_Word_1M));

- memset(COMM.Command, 0x00, 8 * 5);
- memset(COMM.Status, 0x00, 8 * 5);
+ memset(COMM.Command, 0x00, sizeof(COMM.Command));
+ memset(COMM.Status, 0x00, sizeof(COMM.Status));

LED_Status = S68K_State = S68K_Mem_WP = S68K_Mem_PM = Ram_Word_State = 0;
COMM.Flag = Init_Timer_INT3 = Timer_INT3 = Int_Mask_S68K = 0;

[ZombieRyushu]

commit dc7837b8a83d938f919de7a4f3ced5148a386603
Author: David Korth <gerbilsoft@verizon.net>
Date: Fri Jul 31 18:08:04 2009 -0400

[WTF] save.cpp: Fixed a buffer overflow when loading savestates.

In the release build, loading a savestate caused glibc to abort with a
buffer overflow error. This occurred because the savestate code was
attmepting to load 512 bytes from the savestate into CRam, which is
defined as 64 WORDs (128 bytes). It probably worked before commit
d8c490aca52c248e455fc4cdbfd2dbae5da0e081, which reduced the size of
CRam from 64 DWORDs (256 bytes) to 64 WORDs (128 bytes). I'm guessing
that the extra space gave it just enough room that it was still able
to save the extra 256 bytes, even though it wasn't allocated for CRam.
(Strangely, this buffer overflow did not occur in the debug build.)

Also, as an interesting note, Gens Rerecording defines CRam as 64 DWORDs
(256 bytes), but saves and loads 512 bytes for CRam anyway.

The SRAM code, which is right next to the CRAM code, now uses sizeof()
instead of hard-coded sizes to prevent this sort of thing from happening.

This bug was reported by Zombie Ryushu.




diff --git a/src/gens/util/file/save.cpp b/src/gens/util/file/save.cpp
index d39e4ee..fa4f7fc 100644
--- a/src/gens/util/file/save.cpp
+++ b/src/gens/util/file/save.cpp
@@ -845,11 +845,11 @@ int Savestate::GsxImportGenesis(const unsigned char* data)
VRam_Flag = le32_to_cpu(md_save_v7.vram_flag);

// Color RAM. [TODO: Is this supposed to be 16-bit byteswapped?]
- memcpy(&CRam, &md_save_v7.cram, 256 * 2);
+ memcpy(&CRam, &md_save_v7.cram, sizeof(CRam));

// Save RAM. [TODO: Is this supposed to be 16-bit byteswapped?]
// it's probably safer sync-wise to keep SRAM stuff in the savestate
- memcpy(&SRAM, &md_save_v7.sram.sram, 64 * 1024);
+ memcpy(&SRAM, &md_save_v7.sram.sram, sizeof(SRAM));
SRAM_Start = le32_to_cpu(md_save_v7.sram.sram_start);
SRAM_End = le32_to_cpu(md_save_v7.sram.sram_end);
SRAM_ON = le32_to_cpu(md_save_v7.sram.sram_on);
@@ -1214,11 +1214,11 @@ void Savestate::GsxExportGenesis(unsigned char* data)
md_save_v7.vram_flag = cpu_to_le32(VRam_Flag);

// Color RAM. [TODO: Is this supposed to be 16-bit byteswapped?]
- memcpy(&md_save_v7.cram, &CRam, 256 * 2);
+ memcpy(&md_save_v7.cram, &CRam, sizeof(CRam));

// Save RAM. [TODO: Is this supposed to be 16-bit byteswapped?]
// it's probably safer sync-wise to keep SRAM stuff in the savestate
- memcpy(&md_save_v7.sram.sram, &SRAM, 64 * 1024);
+ memcpy(&md_save_v7.sram.sram, &SRAM, sizeof(md_save_v7.sram.sram));
md_save_v7.sram.sram_start = cpu_to_le32(SRAM_Start);
md_save_v7.sram.sram_end = cpu_to_le32(SRAM_End);
md_save_v7.sram.sram_on = cpu_to_le32(SRAM_ON);

[AamirM]

Regen (genesis emulator) is supposed to get a port to linux sometime (mednafen had a private version running Genesis emulation, but I doubt that'll go public anytime soon or ever.)

Regen already has a Linux/GTK+ port (http://aamirm.hacking-cult.org/regen-gtk-0.95.tar.bz2) which works very well.

In coming months I'll also be porting my PCE(CD) emulator as well. I have a CLI port of it running using SDL already but I doubt anyone would be interested in that :P .

[Berserker]

This should fix the Sega CD Support.


commit badf3aa21d55d06b53e1fad713a6f4d4084acd97
Author: David Korth <gerbilsoft@verizon.net>
Date: Fri Jul 31 18:21:05 2009 -0400

[WTF] cpu_68k.c: Use sizeof() when specifying the size of memory blocks to clear.

Kids, there's nothing more cool than clearing a memory block. But if
someone tries to memset() you with too many bytes, that's NO good.
It's your memory; no one has the right to clear too many bytes if you
don't want them to. So, what do you do? First, you say SIGABRT! Then,
you error out with a Buffer Overflow!

This bug was reported by Zombie Ryushu.



diff --git a/src/gens/gens_core/cpu/68k/cpu_68k.c b/src/gens/gens_core/cpu/68k/cpu_68k.c
index 67702f3..453fda8 100644
--- a/src/gens/gens_core/cpu/68k/cpu_68k.c
+++ b/src/gens/gens_core/cpu/68k/cpu_68k.c
@@ -265,12 +265,12 @@ void M68K_Reset(int System_ID)
*/
void S68K_Reset(void)
{
- memset(Ram_Prg, 0x00, 512 * 1024);
- memset(Ram_Word_2M, 0x00, 256 * 1024);
- memset(Ram_Word_1M, 0x00, 256 * 1024);
+ memset(Ram_Prg, 0x00, sizeof(Ram_Prg));
+ memset(Ram_Word_2M, 0x00, sizeof(Ram_Word_2M));
+ memset(Ram_Word_1M, 0x00, sizeof(Ram_Word_1M));

- memset(COMM.Command, 0x00, 8 * 5);
- memset(COMM.Status, 0x00, 8 * 5);
+ memset(COMM.Command, 0x00, sizeof(COMM.Command));
+ memset(COMM.Status, 0x00, sizeof(COMM.Status));

LED_Status = S68K_State = S68K_Mem_WP = S68K_Mem_PM = Ram_Word_State = 0;
COMM.Flag = Init_Timer_INT3 = Timer_INT3 = Int_Mask_S68K = 0;




commit dc7837b8a83d938f919de7a4f3ced5148a386603
Author: David Korth <gerbilsoft@verizon.net>
Date: Fri Jul 31 18:08:04 2009 -0400

[WTF] save.cpp: Fixed a buffer overflow when loading savestates.

In the release build, loading a savestate caused glibc to abort with a
buffer overflow error. This occurred because the savestate code was
attmepting to load 512 bytes from the savestate into CRam, which is
defined as 64 WORDs (128 bytes). It probably worked before commit
d8c490aca52c248e455fc4cdbfd2dbae5da0e081, which reduced the size of
CRam from 64 DWORDs (256 bytes) to 64 WORDs (128 bytes). I'm guessing
that the extra space gave it just enough room that it was still able
to save the extra 256 bytes, even though it wasn't allocated for CRam.
(Strangely, this buffer overflow did not occur in the debug build.)

Also, as an interesting note, Gens Rerecording defines CRam as 64 DWORDs
(256 bytes), but saves and loads 512 bytes for CRam anyway.

The SRAM code, which is right next to the CRAM code, now uses sizeof()
instead of hard-coded sizes to prevent this sort of thing from happening.

This bug was reported by Zombie Ryushu.



diff --git a/src/gens/util/file/save.cpp b/src/gens/util/file/save.cpp
index d39e4ee..fa4f7fc 100644
--- a/src/gens/util/file/save.cpp
+++ b/src/gens/util/file/save.cpp
@@ -845,11 +845,11 @@ int Savestate::GsxImportGenesis(const unsigned char* data)
VRam_Flag = le32_to_cpu(md_save_v7.vram_flag);

// Color RAM. [TODO: Is this supposed to be 16-bit byteswapped?]
- memcpy(&CRam, &md_save_v7.cram, 256 * 2);
+ memcpy(&CRam, &md_save_v7.cram, sizeof(CRam));

// Save RAM. [TODO: Is this supposed to be 16-bit byteswapped?]
// it's probably safer sync-wise to keep SRAM stuff in the savestate
- memcpy(&SRAM, &md_save_v7.sram.sram, 64 * 1024);
+ memcpy(&SRAM, &md_save_v7.sram.sram, sizeof(SRAM));
SRAM_Start = le32_to_cpu(md_save_v7.sram.sram_start);
SRAM_End = le32_to_cpu(md_save_v7.sram.sram_end);
SRAM_ON = le32_to_cpu(md_save_v7.sram.sram_on);
@@ -1214,11 +1214,11 @@ void Savestate::GsxExportGenesis(unsigned char* data)
md_save_v7.vram_flag = cpu_to_le32(VRam_Flag);

// Color RAM. [TODO: Is this supposed to be 16-bit byteswapped?]
- memcpy(&md_save_v7.cram, &CRam, 256 * 2);
+ memcpy(&md_save_v7.cram, &CRam, sizeof(CRam));

// Save RAM. [TODO: Is this supposed to be 16-bit byteswapped?]
// it's probably safer sync-wise to keep SRAM stuff in the savestate
- memcpy(&md_save_v7.sram.sram, &SRAM, 64 * 1024);
+ memcpy(&md_save_v7.sram.sram, &SRAM, sizeof(md_save_v7.sram.sram));
md_save_v7.sram.sram_start = cpu_to_le32(SRAM_Start);
md_save_v7.sram.sram_end = cpu_to_le32(SRAM_End);
md_save_v7.sram.sram_on = cpu_to_le32(SRAM_ON);


Welcome to digitpress.sourceforge.net! The appropriate place to paste bug reports and chunks of raw code for random Linux emulators.