Mednafen Members Members   Search Search   Help Help   Register Register   Login Login   Home Home
Home » Site » News » Mednafen 0.9.18-WIP
Show: Today's Messages  :: Show Polls :: Message Navigator
Switch to threaded view of this topic Create a new topic Submit Reply
Mednafen 0.9.18-WIP [message #2203] Thu, 11 August 2011 22:14 Go to next message
Administrator  [PM]
This release has the beginnings of PlayStation 1 emulation, however it's not particularly usable at the moment, though it can play PSF(PSF1) files reasonably well. If compiling from source, you'll have to enable it manually by passing "--enable-psx" to the configure script; but, the code may take an excessively-long time to compile, and PS1 emulation doesn't support big-endian systems currently.

This release supports custom palettes for GameBoy(mono/color) games, but per-game custom palettes are currently broken with GB mono/color games. This issue should be resolved in the next WIP release.

Changes since 0.9.16-WIP(0.9.17-WIP was a fork off of 0.9.16-WIP, so there will be some overlap with the 0.9.17-WIP changelog in the earlier entries):

-- 0.9.18-WIP: --

August 11, 2011:
	SexyAL: Added support for reversed-byte-order(relative to CPU endianness) sample formats to the ALSA driver; this
	will allow for better support for non-native soundcards(such as a little-endian sample format "PC" soundcard plugged
	into an old PowerPC Mac big-endian system running Linux).

	SNES: Added support for custom palettes.

	GB: Added support for custom palettes.

August 9, 2011:
	The "P" subchannel is now simulated along with the Q subchannel in the CD read functions.  This shouldn't have any
	effect on emulation now, as the P subchannel data isn't used by any system emulation code in Mednafen, but it may
	be used in the future.

	Improved accuracy of simulated Q subchannel data for pregap areas, in the
	CD read functions.

August 8, 2011:
	Added path checks to files referenced in CUE sheets and PSF files, controlled(enabled/disabled) via the
	setting "filesys.untrusted_fip_check".

	Added untested support for the "POSTGAP" directive in CUE sheets.

	Added support for specifying absolute file paths in PSF files and CUE/TOC files.

August 7, 2011:
	When loading a state, if the recorded variable/datum size is not equal to the expected size of the variable,
	it will be treated as missing and not loaded.

	Removed redundant function "CDIF_GetTrackStartPositionLBA()".

	Removed mostly-redundant, and inconsistent across disc images and physical discs, functions
	"cdrfile_get_track_sec_count()" and "CDIF_GetTrackSectorCount()".

	GB: Fixed coarse instruction timing and flag behavior for several instructions, based on blargg's CPU tests and
	on code in the VBA-M SVN repository.

	Fixed a file descriptor leak in the save state preview code, that could cause file descriptor exhaustion
	if multiple save states are used extensively in one session.  Thanks to raz0red for reporting the bug.

August 5, 2011:
	SNES: Implemented RAM cheats and cheat search via the common interface.

	WonderSwan: Cart save RAM is now available to the cheat engine code(it was supposed to be before, but the code
	was passing the pointer before it was initialized).

	Genesis: Updated EEPROM code to newer code from Genesis Plus GX, and fixed most of the EEPROM database entries
	that were previously broken in Mednafen.

August 4, 2011:
	Genesis: Refactored and tweaked input device emulation a bit to fix input unresponsiveness issues in
	"Samurai Spirits/"Samurai Shodown".

August 3, 2011:
	Genesis: Revamped 6-button gamepad emulation, and made it actually work.

August 1, 2011:
	Fixed a lack of mutex locks in the debugger's memory viewer when editing memory, that could cause crashes or wrong
	behavior in certain cases.

	Began work on supporting comments in the disassembled code in the debugger.

July 29, 2011:
	Genesis: Made H-counter reading less completely wrong, but it's likely still mostly wrong(added a TODO entry
	for fixing it).

	WonderSwan: Fixed(made considerably less broken at least!) debugger's fubar branch
	history(it only took a few years, I guess no one used the WonderSwan debugger much :b).

July 28, 2011:
	WonderSwan: Cleaned up debugger code a bit.

	WonderSwan: Encapsulated in a namespace.

	The music player interface's waveform display will now saturate the Y coordinate to the screen boundaries
	rather than forcing it to the middle of the screen(not sure why it was doing that before, doesn't make much sense).

	NES: Tweaked the audio resampling algorithms a bit to prevent degraded audio quality on high-amplitude input
	samples.

	NES: Corrected audio resampler filter setup debug printfs to use more-correct labels, and added more information.

	NES: Added AltiVec support to the audio resampler.

July 27, 2011:
	Internal text renderer now truncates text with pixel granularity rather than glyph granularity.

July 26, 2011:
	NES: Reduced fb_height from 256 to 240.

	GBA: Changed "gba.bios" setting to use Mednafen's firmware path construction semantics rather than specifying a
	path used directly.

	GBA: The "gba.bios" setting is now ignored when playing a GSF, fixing GSF playback with a real BIOS ROM
	image is used.

July 25, 2011:
	PCE_FAST: Changed x86 inline assembly to manually push and pop rbx/ebx, rather than listing it in the clobber list,
	to work around pedanticness in compilers in certain cases.

	Added a test to make sure "char" type is signed to "tests.cpp".

	Added a quick and dirty signed overflow test to "tests.cpp".

July 18, 2011:
	Lynx: ROM image headers are now read out field-by-field rather than memcpy()'ing into a packed struct.

July 16, 2011:
	Genesis: A loaded file with an extension of "md" will now be treated as a Sega Genesis/Megadrive game.

July 8, 2011:
	WonderSwan: Added "Code Segment", "Stack Segment", "Data Segment", and "Extra Segment" logical address spaces
	to the debugger's memory editor.

July 5, 2011:
	Added highlighting to the instruction disassembly for the instruction that PC is pointing to, to avoid confusion
	when the disassembly cursor is moved off in step mode from the current PC.

	Debugger disassembly will now be forcibly resynchronized to PC, in addition to the current disassembly cursor
	address(currently, only the latter was synched).

	PCE: Revamped branch history to show the old PC in addition to the new PC, not to add an entry when a conditional
	branch isn't taken, to show reset and IRQ events/"branches", and to show branch count when repeatedly branching to
	the same target from the same source with no other branches in-between.  These changes necessitated reducing the
	number of entries in the branch history from 32 to 24.
	T = timer, 1 = IRQ1, 2 = IRQ2, R = reset.

	Increased the available area for branch history display in the debugger.

	Halved the size(and number of bytes displayed) of the memory watch section in the debugger when the disassembly
	list is selected(and offseted the watch address by -0x80 when the register list is selected).

Jun 26, 2011:
	Replaced the old CPU flag testing code with newer code from libavutil from ffmpeg.

	Restructured architecture detection code in configure.ac.

Jun 19, 2011:
	Fixed a minor(it's unlikely to have noticeably affected any commercial games) LFO emulation bug in the HuC6280 sound
	core emulation code, reported by "mic_".

Jun 13, 2011:
	GBA: GSF playback now uses new PSF loading code developed for the PS1 emulation module.

	Changed the music player overlay to use std::string instead of C-strings.

Jun 7, 2011:
	Fixed a lack of variable initialization in the WAV recording code, which could cause WAV recordings to have an
	erroneous value in a size field in the header.

Jun 5, 2011:
	PC-FX, VB: Implemented a minor CPU optimization that could cause regressions. TODO: Test games.

Jun 2, 2011:
	Changed "INLINE" #define in the SoftFloat target definition file from "extern inline" to "static inline" to resolve
	issues user "mziab" reported with gcc 4.6.0.

May 30, 2011:
	NGP: Fixed the "ngp.language" setting to work properly with the non-numeric setting values("english" and "japanese")
	(previously it was always Japanese language selection for both strings).

May 28, 2011:
	Genesis: Fixed a bug in the 68K emulation core that caused major problems in some games("Instruments of Power",
	"The Lost Vikings", perhaps others) when running on big-endian platforms.

May 20, 2011:
	PCE: Loading Games Express CD games will now automatically load the Games Express CD Card BIOS; BIOS filename
	is specified by the new "pce.gecdbios" setting, default value of "gecard.pce".

	PCE: Added Games Express CD game detection based on CRC32s for the remaining handful of games that the previous
	method didn't detect.

May 18, 2011:
	Tweaked CD simulated read ahead to read farther ahead, but incrementally instead of all at once as before.

April 28, 2011:
	SNES: Fixed PAL video output size, and frame rate when using netplay.

April 27, 2011:
	SexyAL: Rewrote the channel and format conversion code, now allowing for output channel count up to 8; and,
	tweaked the ALSA code to work with devices that only support > 2(but code is limited to <= 8) channels.
	(The Audigy 2's "p16v" sub-device in ALSA can now be used directly by Mednafen)

April 23, 2011:
	Fixed a crash on exit when one audio file(FLAC, WAV, Vorbis, etc.) is used for multiple tracks in a CUE sheet.

April 17, 2011:
	NES, PCE: Fixed relative branch target address 16-bit wrapping in the debugger's disassembler.

	PCE: Added "SET" instruction to the debugger's disassembler(can't believe it's been missing all this time).

April 15, 2011:
	Fixed "--disable-vb" option to ./configure, thanks to Rakashazi for reporting the bug.

April 8, 2011:
	PC-FX: Fixed debugger's timer register text, and hooked up sound chip register setting in the debugger.

	PCE: Altered VDC line timing to fix raster effects in "Camp California" and "Shape Shifter".  The changed way probably
	still isn't right, but it's something commercial games are unlikely to rely on anyway(except in maybe those
	hidden "four-screen" modes), and the previous way WAS breaking commercial games.

	PCE: Fixed a timing bug in the maximum VDC wait state calculation code(wasn't taking into account VCE-controlled
	events like hsync and vsync changing state).

April 5, 2011:
	VB: Fixed register 30 state during and after *bsu instructions.  Thanks to blitter for pointing the bug out
	and submitting a patch.

	PCE: Improved ADPCM emulation based on more tests run on the real system.  Fixes a lockup bug in "Hyper Wars".
	(The changes made have the potential to cause regressions, however, if any are found please report them)

Mar 7, 2011:
	Hackish fix for problems with CUE/BIN disc images(particularly bad with multiple BIN style images) that contain
	"INDEX 00" statements in the CUE sheet.  (Problems ranging from incorrect Q subchannel data for the pregap
	to wrong track start LBAs)

February 12, 2011:
	PC-FX, MD: Factored the deinterlacing code out of the individual emulation modules and into the core Mednafen code.

	PCE: Adjusted ADPCM emulation slightly, fixes massive A/V sync problems with "Sherlock Holmes".

January 29, 2011:
	NGP: Masked NGP BIOS syscall code properly, thanks to SANiK for pointing it out.

	MD: Changed line timings so vertical refresh rates are the same in both 256 and 320-wide modes.

	PCE: Fixed a Seiya Monogatari ADPCM-related lockup, thanks to Rakashazi for pointing the problem out.

January 15, 2011:
	Began adding PlayStation 1 emulation.

January 5, 2011:
	Fixed "volatile" placement on several pointer declarations.

[Updated on: Fri, 14 November 2014 21:54]

Re: Mednafen 0.9.18-WIP [message #2212 is a reply to message #2203 ] Sun, 21 August 2011 14:23 Go to previous messageGo to next message
mistydemeo  [PM]
I'm unable to build 0.9.18 on Mac OS X 10.7, using either GCC 4.2 or LLVM-GCC. I get the following errors building cputest/x86_cup.c:

#	source='cputest/x86_cpu.c' object='cputest/x86_cpu.o' libtool=no 
/usr/bin/cc -DLOCALEDIR=\"/usr/local/Cellar/mednafen/0.9.18-WIP/share/locale\" -DHAVE_CONFIG_H -ffast-math -I../include -I../include/blip -I../intl -I..   -I/usr/local/Cellar/libcdio/0.82/include   -I/usr/local/Cellar/libsndfile/1.0.25/include    -fsigned-char  -Wall -Winline -Wshadow -Wempty-body  -fomit-frame-pointer -finline-limit=6000 --param large-function-growth=800 --param inline-unit-growth=175 --param max-inline-insns-single=10000 -fno-strict-overflow   -I/usr/local/Cellar/libcdio/0.82/include   -I/usr/local/Cellar/libsndfile/1.0.25/include    -fsigned-char  -Wall -Winline -Wshadow -Wempty-body  -fomit-frame-pointer -finline-limit=6000 --param large-function-growth=800 --param inline-unit-growth=175 --param max-inline-insns-single=10000 -fno-strict-overflow -O3 -march=core2 -w -pipe -c -o cputest/x86_cpu.o cputest/x86_cpu.c
{standard input}:17:suffix or operands invalid for `pushf'
{standard input}:18:suffix or operands invalid for `pop'
{standard input}:21:suffix or operands invalid for `push'
{standard input}:22:suffix or operands invalid for `popf'
{standard input}:23:suffix or operands invalid for `pushf'
{standard input}:24:suffix or operands invalid for `pop'
make[2]: *** [cputest/x86_cpu.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [install-recursive] Error 1
make: *** [install-recursive] Error 1


I was able to get 0.9.16 and 0.9.17 to build with the same build tool and libraries.
Re: Mednafen 0.9.18-WIP [message #2213 is a reply to message #2203 ] Mon, 22 August 2011 05:55 Go to previous messageGo to next message
Administrator  [PM]
Paste/attach your config.log.
Re: Mednafen 0.9.18-WIP [message #2214 is a reply to message #2213 ] Mon, 22 August 2011 08:08 Go to previous messageGo to next message
mistydemeo  [PM]
Sure - here it is.

It seems to be a platform/architecture detection issue. When I added `--build=x86_64-apple-darwin10.0.0` to the config args, it built without a problem.

  • Attachment: config.log
    (Size: 198.39KB, Downloaded 382 time(s))

Re: Mednafen 0.9.18-WIP [message #2215 is a reply to message #2203 ] Wed, 24 August 2011 00:01 Go to previous messageGo to next message
haikai  [PM]
Quote:

This release has the beginnings of PlayStation 1 emulation


Well /that/ was unexpected! pcsx-r isn't bad but it would be great to have something else on the field. Compiles and works fine here on amd64. On what system should I spend my time testing?
Re: Mednafen 0.9.18-WIP [message #2238 is a reply to message #2203 ] Wed, 07 September 2011 05:48 Go to previous messageGo to next message
vanfanel  [PM]
I'm unable to build a working version in Snow Leopard (10.6.8, gcc 4.2.1, libsdl 1.2.14).
First I had to edit configure.ac after a distclean to change the line:
AX_CFLAGS_GCC_OPTION([-fno-strict-overflow], OPTIMIZER_FLAGS)

with this:
AX_CFLAGS_GCC_OPTION([-fwrapv], OPTIMIZER_FLAGS)


Then I ran autogen.sh, and no errors were reported, but then I ran the configure script:
./configure --without-SDL_net --without-libcdio --without-libsndfile --disable-jack --disable-debugger --disable-pcfx --disable-snes --build=x86_64-apple-darwin10.8.0


..and I got errors:
./configure: line 24110: syntax error near unexpected token `JACK,'
./configure: line 24110: `        PKG_CHECK_MODULES(JACK, jack, have_jack=yes, have_jack=no)'


I also tried the configure script without the jack disabling parameters, with no parameters at all, etc.


Re: Mednafen 0.9.18-WIP [message #2253 is a reply to message #2214 ] Sat, 10 September 2011 13:06 Go to previous messageGo to next message
mistydemeo  [PM]
mistydemeo wrote on Mon, 22 August 2011 08:08

Sure - here it is.

It seems to be a platform/architecture detection issue. When I added `--build=x86_64-apple-darwin10.0.0` to the config args, it built without a problem.


You may have noticed in the config.log, but I saw that without specifying `--build`, my arch is detected as i386. Presumably that's why the CPU tests fail when running against an incorrect arch.

I also found out that Mednafen fails when compiling with LLVM-GCC (LLVM acting as a front-end to GCC). It builds OK, but when trying to launch it, it halts with this error:

Assertion failed: ((a + 0x7FFFFFFE) < a), function TestSignedOverflow, file tests.cpp, line 308.
Abort trap: 6

This only happens when building 0.9 - 0.8 is fine. I can compile correctly using normal GCC. The LLVM-GCC version is build 2335, as installed by Xcode 4.1. Just as a note, it's *possible* that LLVM-GCC will be the only build option (alongside clang) in future versions of Xcode.

Edit:

Just noticed another unrelated bug. When I launch Mednafen it fails on startup with the following errors:

Math test failed: tests.cpp:154
Math test failed: tests.cpp:154

I could have sworn I could run 0.9.18-WIP before, but I can't seem to build a version without getting this now.

Edit 2:

HOPEFULLY my last edit for the time being. Thought it was better than triple-posting.

0.9.17 builds correctly with LLVM-GCC, and also runs correctly without the math test errors. The problem seems to be isolated to 0.9.18.

[Updated on: Sat, 10 September 2011 15:13]

Re: Mednafen 0.9.18-WIP [message #2254 is a reply to message #2203 ] Sat, 10 September 2011 20:18 Go to previous messageGo to next message
Administrator  [PM]
It's not a "problem" with 0.9.18 per-se, I added new math tests to weed out compilers producing bad binary code so it doesn't pop up as subtly broken emulation.
Re: Mednafen 0.9.18-WIP [message #2255 is a reply to message #2254 ] Sat, 10 September 2011 20:50 Go to previous messageGo to next message
mistydemeo  [PM]
Aha. Yes, turning off optimizations lets it to build correctly without tripping those tests. It would be great if the error message on the math tests was more clear about the reason for failure.
Re: Mednafen 0.9.18-WIP [message #2256 is a reply to message #2203 ] Sun, 11 September 2011 06:05 Go to previous messageGo to next message
vanfanel  [PM]
I finally got it to compile: I had to hand-fix the configure script to disable the PKGCONFIG tests against JACK and LIBCDIO: the configure file generated after running autogen.sh (wich is needed after editing configure.ac to remove the maths optimizations) was wrong. Even with the right atomake/atoconf/libtool versions.

Maybe you're ignoring me because my english is somewhat strange, but I'm right on this.
Re: Mednafen 0.9.18-WIP [message #2257 is a reply to message #2256 ] Sun, 11 September 2011 10:52 Go to previous messageGo to next message
mistydemeo  [PM]
You don't need to edit configure to disable optimization. You can set an -O level in your CFLAGS (or leave it out, e.g. "-w -pipe") and the Mednafen compile will respect it.
Re: Mednafen 0.9.18-WIP [message #2258 is a reply to message #2203 ] Mon, 12 September 2011 02:41 Go to previous messageGo to next message
megadriver  [PM]
Hello there.

Could this be added to src/sms/romdb.cpp?

{ 0xA109A6FE, MAPPER_SEGA, DISPLAY_PAL, TERRITORY_EXPORT, -1, "Power Strike II" },


Power Strike II for the Master System is PAL only, and a a completely different game than Power Strike II for the Game Gear.

Thanks is advance, and keep up the good work!
Re: Mednafen 0.9.18-WIP [message #2259 is a reply to message #2203 ] Mon, 12 September 2011 05:09 Go to previous messageGo to next message
vanfanel  [PM]
I'm not talking about -O level optimization, but about this one:
Quote:


There's a bug in older versions of gcc that produces bad code when a certain optimization is turned off.

Around line 96-ish of configure.ac should be
AX_CFLAGS_GCC_OPTION([-fno-strict-overflow], OPTIMIZER_FLAGS)


You can try replacing it with
AX_CFLAGS_GCC_OPTION([-fwrapv], OPTIMIZER_FLAGS)




Re: Mednafen 0.9.18-WIP [message #2281 is a reply to message #2259 ] Wed, 19 October 2011 21:23 Go to previous messageGo to next message
billb  [PM]
Ran into a problem building 0.9.18-WIP:

g++ -DLOCALEDIR=\"/usr/share/locale\" -DHAVE_CONFIG_H -ffast-math -I../../include -I../../intl   -fsigned-char  -Wall -Winline -Wshadow  -fomit-frame-pointer -finline-limit=6000 --param large-function-growth=800 --param inline-unit-growth=175 --param max-inline-insns-single=10000 -I -O2 -g -fsigned-char   -maltivec  -maltivec  -O2 -g -fsigned-char -MT filter.o -MD -MP -MF $depbase.Tpo -c -o filter.o filter.cpp &&\
        mv -f $depbase.Tpo $depbase.Po
filter.cpp: In function ‘void DoMAC_AltiVec(int16*, int16*, int32, int32*)’:
filter.cpp:257: error: ‘vec_splats’ was not declared in this scope


My config.log is attached.

  • Attachment: configlog.zip
    (Size: 18.40KB, Downloaded 248 time(s))

Re: Mednafen 0.9.18-WIP [message #2282 is a reply to message #2203 ] Wed, 19 October 2011 22:45 Go to previous messageGo to next message
Administrator  [PM]
That intrinsic might not be supported on the older version of gcc you're using; try passing --disable-altivec to the configure script to work around it.
Re: Mednafen 0.9.18-WIP [message #2283 is a reply to message #2282 ] Wed, 19 October 2011 23:51 Go to previous messageGo to next message
billb  [PM]
Thanks -- that got it to build OK. However, I get an error when running it:

./mednafen-wip
Starting Mednafen 0.9.18-WIP
 Base directory: /home/zerogame/.mednafen
 Internal emulation modules: nes snes gb gba pce pce_fast lynx md pcfx ngp vb wswan sms gg cdplay
 External emulation modules: 
mednafen-wip: tests.cpp:308: void TestSignedOverflow(): Assertion `(a + 0x7FFFFFFE) < a' failed.
Aborted

Re: Mednafen 0.9.18-WIP [message #2284 is a reply to message #2203 ] Thu, 20 October 2011 00:35 Go to previous messageGo to next message
Administrator  [PM]
That's a sign the compiler produced machine code Mednafen isn't expecting in the case of some undefined/implementation-defined semantics.

Try setting the env vars "CFLAGS" and "CXXFLAGS" to "-fwrapv" and re-running configure and recompiling.

An interesting semi-related page I found while Googling around: http://thiemonagel.de/2010/01/signed-integer-overflow/


I may just make changes to require gcc 4.1+ to compile Mednafen, and use -fwrapv if -fno-strict-overflow isn't available...

[Updated on: Thu, 20 October 2011 00:41]

Re: Mednafen 0.9.18-WIP [message #2285 is a reply to message #2284 ] Thu, 20 October 2011 09:37 Go to previous messageGo to next message
billb  [PM]
That works -- thanks again!

EDIT: actually I better double-check that this evening ... I think I ended up overriding my CFLAGS instead of appending that so it built without any optimization (-O2) ... I blame it on not having enough coffee yet.

EDIT2: OK -- runs great (rebuilt with -O2)! Tested 6-button controller support for md and see that's fine, too. Nice how it apparently uses a 3 or 6 button gamepad depending on whether the game supports it.

If I'm missing anything from having altivec disabled I don't see it.

[Updated on: Thu, 20 October 2011 19:33]

Re: Mednafen 0.9.18-WIP [message #2300 is a reply to message #2203 ] Thu, 10 November 2011 09:59 Go to previous messageGo to next message
ktrhn  [PM]
Does not compile. Sad Strange thing is: 0.9.16 does not compile anymore too. (worked "before", but already deleted it Embarassed ).

In file included from compress/unzip.h:57:0,
                 from file.cpp:36:
compress/ioapi.h:38:44: error: expected initializer before ‘OF’
compress/ioapi.h:39:44: error: expected initializer before ‘OF’
compress/ioapi.h:40:45: error: expected initializer before ‘OF’
compress/ioapi.h:41:44: error: expected initializer before ‘OF’
compress/ioapi.h:42:44: error: expected initializer before ‘OF’
compress/ioapi.h:43:45: error: expected initializer before ‘OF’
compress/ioapi.h:44:49: error: expected initializer before ‘OF’
compress/ioapi.h:48:5: error: ‘open_file_func’ does not name a type
compress/ioapi.h:49:5: error: ‘read_file_func’ does not name a type
compress/ioapi.h:50:5: error: ‘write_file_func’ does not name a type
compress/ioapi.h:51:5: error: ‘tell_file_func’ does not name a type
compress/ioapi.h:52:5: error: ‘seek_file_func’ does not name a type
compress/ioapi.h:53:5: error: ‘close_file_func’ does not name a type
compress/ioapi.h:54:5: error: ‘testerror_file_func’ does not name a type
compress/ioapi.h:60:26: error: expected initializer before ‘OF’
In file included from file.cpp:36:0:
compress/unzip.h:122:45: error: expected initializer before ‘OF’
compress/unzip.h:135:32: error: expected initializer before ‘OF’
compress/unzip.h:146:33: error: expected initializer before ‘OF’
compress/unzip.h:153:29: error: expected initializer before ‘OF’
compress/unzip.h:160:37: error: expected initializer before ‘OF’
compress/unzip.h:168:40: error: expected initializer before ‘OF’
compress/unzip.h:181:37: error: expected initializer before ‘OF’
compress/unzip.h:187:36: error: expected initializer before ‘OF’
compress/unzip.h:194:34: error: expected initializer before ‘OF’
compress/unzip.h:226:42: error: expected initializer before ‘OF’
compress/unzip.h:252:39: error: expected initializer before ‘OF’
compress/unzip.h:258:47: error: expected initializer before ‘OF’
compress/unzip.h:266:40: error: expected initializer before ‘OF’
compress/unzip.h:279:40: error: expected initializer before ‘OF’
compress/unzip.h:294:40: error: expected initializer before ‘OF’
compress/unzip.h:300:39: error: expected initializer before ‘OF’
compress/unzip.h:314:32: error: expected initializer before ‘OF’
compress/unzip.h:319:27: error: expected initializer before ‘OF’
compress/unzip.h:324:42: error: expected initializer before ‘OF’
file.cpp: In member function ‘bool MDFNFILE::MakeMemWrap(void*, int)’:
file.cpp:313:51: error: ‘unzGetCurrentFileInfo’ was not declared in this scope
file.cpp:328:55: error: ‘unzReadCurrentFile’ was not declared in this scope
file.cpp:344:25: error: ‘unzCloseCurrentFile’ was not declared in this scope
file.cpp:345:14: error: ‘unzClose’ was not declared in this scope
file.cpp: In member function ‘bool MDFNFILE::Open(const char*, const FileExtensionSpecStruct*, const char*, bool)’:
file.cpp:381:23: error: ‘unzOpen’ was not declared in this scope
file.cpp:386:36: error: ‘unzGoToFirstFile’ was not declared in this scope
file.cpp:389:15: error: ‘unzClose’ was not declared in this scope
file.cpp:402:71: error: ‘unzGetCurrentFileInfo’ was not declared in this scope
file.cpp:405:17: error: ‘unzClose’ was not declared in this scope
file.cpp:427:37: error: ‘unzGoToNextFile’ was not declared in this scope
file.cpp:432:18: error: ‘unzClose’ was not declared in this scope
file.cpp:436:39: error: ‘unzGoToFirstFile’ was not declared in this scope
file.cpp:439:18: error: ‘unzClose’ was not declared in this scope
file.cpp:448:38: error: ‘unzOpenCurrentFile’ was not declared in this scope
file.cpp:451:15: error: ‘unzClose’ was not declared in this scope
make[2]: *** [file.o] Error 1
make[2]: Leaving directory `/opt/mednafen/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/opt/mednafen/src'
make: *** [all-recursive] Error 1

this is on gentoo, gcc-4.5.3
Re: Mednafen 0.9.18-WIP [message #2301 is a reply to message #2203 ] Thu, 10 November 2011 17:50 Go to previous messageGo to next message
altoiddealer  [PM]
I am a Linux noob. Cool

I am running Ubuntu 11.04 Natty, and I want to upgrade to a WIP version for the Genesis emulation.

Installing from source looks scary. Could someone please tell me where I may download the package?

Many thanks in advance!


**EDIT**

I understand how to install from source.
I compiled and "made" it, but I didn't "make install" because I got cold feet~ I have never installed anything from source so I do not understand what can go wrong.

If no one can provide a link to a pre-compiled package, could someone at least advise if installing from source is a bad idea? Will installing from source create complications when upgrading in the future?

[Updated on: Fri, 11 November 2011 13:10]

Re: Mednafen 0.9.18-WIP [message #2303 is a reply to message #2301 ] Sun, 13 November 2011 16:59 Go to previous messageGo to next message
skitt  [PM]
I've prepared a package of 0.9.18 for Debian, which should appear in the archives in the near future. It should be installable on Ubuntu Natty as-is.

You could also try installing the 0.9.17.1 package, available at http://packages.debian.org/experimental/mednafen - scroll down to the bottom, click on amd64 or i386 depending on your computer, choose a download location and open the .deb file. If it doesn't install automatically, save it and install it using gdebi or "dpkg -i"...
Re: Mednafen 0.9.18-WIP [message #2304 is a reply to message #2303 ] Sun, 13 November 2011 19:36 Go to previous messageGo to next message
altoiddealer  [PM]
Thanks! I actually came across that page in my searching but I couldn't even find the download link~ its a little inconspicuously tucked away down there, eh? Maybe I'll wait for 0.9.18. Thanks for packing it!

**EDIT** I upgraded to 0.9.17, and I am very, very happy with the Genesis emulation. I swear this must be the only Genesis emulator that supports hotkey remapping.

Mednafen rocks.

[Updated on: Sun, 13 November 2011 21:46]

Re: Mednafen 0.9.18-WIP [message #2307 is a reply to message #2304 ] Wed, 16 November 2011 00:30 Go to previous messageGo to next message
skitt  [PM]
The 0.9.18 package is now building on Debian's infrastructure; you can download the amd64 package from http://ftp.debian.org/debian/pool/main/m/mednafen/ and the rest should appear there soon.

While I'm at it, I've got some patches (which are applied in the Debian package)...

The following allows building with strict string format checking:
--- mednafen.orig/src/ngp/TLCS-900h/TLCS900h_disassemble.cpp
+++ mednafen/src/ngp/TLCS-900h/TLCS900h_disassemble.cpp
@@ -209,7 +209,7 @@
 
        if (size == 0 && first == 0xC7)
        {
-               sprintf(str_r, extra);
+               sprintf(str_r, "%s", extra);
                return;
        }


The following only enables PlayStation emulation on little-endian systems:
--- mednafen.orig/configure.ac
+++ mednafen/configure.ac
@@ -246,9 +246,12 @@
                AM_CONDITIONAL(WANT_PCFX_EMU, true)
 fi
 
-AC_ARG_ENABLE(psx,
- AC_HELP_STRING([--enable-psx], [build with PlayStation emulation [[default=no]]]),
-                  , enable_psx=no)
+dnl PlayStation only on little-endian systems for now
+AC_C_BIGENDIAN([enable_psx=no], [
+ AC_ARG_ENABLE(psx,
+  AC_HELP_STRING([--enable-psx], [build with PlayStation emulation (little-endian systems only) [[default=no]]]),
+                   , enable_psx=no)
+])
 
 if test x$enable_psx = xyes; then
                 AC_DEFINE([WANT_PSX_EMU], [1], [Define if we are compiling with PlayStation emulation.])


I've also got a patch to build with an external libvorbisidec, but that's much larger (see http://patch-tracker.debian.org/package/mednafen/ once 0.9.18 shows up).

[Updated on: Wed, 16 November 2011 10:15]

Re: Mednafen 0.9.18-WIP [message #2308 is a reply to message #2307 ] Wed, 16 November 2011 18:01 Go to previous messageGo to next message
skitt  [PM]
Another thing: the following .desktop file can come in handy!

[Desktop Entry]
Type=Application
Version=1.0
Name=Mednafen
GenericName=Emulator
Comment=Multi-system video game emulator
# mednafen doesn't display a file chooser, no point displaying it in
# the menus
NoDisplay=true
Exec=/usr/games/mednafen %f
MimeType=application/x-gameboy-rom;application/x-gba-rom;application/x-genesis-rom;application/x-nes-rom;application/x-sms-rom;application/x-snes-rom


It should be saved as mednafen.desktop, either in /usr/share/applications (system-wide) or in ~/.local/share/applications. The Exec line needs to match wherever mednafen is installed.
Re: Mednafen 0.9.18-WIP [message #2310 is a reply to message #2203 ] Tue, 22 November 2011 03:05 Go to previous messageGo to next message
inukaze  [PM]
Hi there , plz , someone can make a mirror , in a Public Server or for example , can make a download from Public Dropbox Address ???

i really wanna make a script with a download ever the lastest version , man you can make something like that

With a dropbox Account , use a Public Link , and the name of file something like mednafen-lastest-wip.tar.bz2 & mednafen-lastest-wip.zip

and i can use for example

wget http://dl.dropbox.com/u/3277777/mednafen-lastest-wip.tar.bz2

to make a mini-script

I wanna know if possible , make "On Live" support with Strecht image , and resize , and change of Game , to make a new GUI , in python or something like that , its possible ???

Sorry for my bad english i just speak spanish
Re: Mednafen 0.9.18-WIP [message #2311 is a reply to message #2203 ] Wed, 23 November 2011 22:24 Go to previous messageGo to next message
MarioMan181  [PM]
Hello people and developers.

I have noticed this new update to mednafen and I have heard that this emulator can emulate virtual boy roms and games.

I see that the sound for this emulator compared to another emulator, realityboy, is much better.

However, I have seen that speed may be a bit slow for some reason during transitions of one game, Mario Clash.

With this game during the transitions, such as transitioning from virtual boy intro and title screen, it is a bit slow and in Mario Clash some pixels are missing in the title screen. While compared to the emulator reality boy, this game has no problem with the transitions.

But this emulator mednafen does have advantage in the sound and framerate and/or speed of the gameplay.

Overall, I just want to know if it is possible to fix this small problems or if this will be fixed with future versions for this emulator.

I would also appreciate if someone would be kind to send this message to the developers, if this message being written is not already.

Re: Mednafen 0.9.18-WIP [message #2355 is a reply to message #2203 ] Fri, 13 January 2012 17:12 Go to previous messageGo to next message
goldenegg  [PM]
Anyone seen this problem when compiling on OS X?


g++ -DLOCALEDIR=\"/usr/local/share/locale\" -DHAVE_CONFIG_H -ffast-math -I/opt/local/include/SDL -D_GNU_SOURCE=1 -D_THREAD_SAFE -I../../include -I../../intl -I../.. -I/opt/local/include -I/opt/local/include -fsigned-char -Wall -Winline -Wshadow -Wempty-body -fomit-frame-pointer -finline-limit=6000 --param large-function-growth=800 --param inline-unit-growth=175 --param max-inline-insns-single=10000 -fno-strict-overflow -g -O2 -MT shader.o -MD -MP -MF $depbase.Tpo -c -o shader.o shader.cpp &&\
mv -f $depbase.Tpo $depbase.Po
shader.cpp: In function ‘void SLP(GLenum)’:
shader.cpp:185: error: invalid conversion from ‘GLenum’ to ‘void*’
shader.cpp: In function ‘bool InitShader(ShaderType)’:
shader.cpp:253: error: invalid conversion from ‘void*’ to ‘GLenum’
shader.cpp:253: error: initializing argument 1 of ‘void SLP(GLenum)’
shader.cpp:254: error: invalid conversion from ‘void*’ to ‘GLenum’
shader.cpp:254: error: initializing argument 1 of ‘void SLP(GLenum)’
shader.cpp:256: error: invalid conversion from ‘void*’ to ‘GLenum’
shader.cpp:256: error: initializing argument 1 of ‘void SLP(GLenum)’
shader.cpp:260: error: invalid conversion from ‘void*’ to ‘GLenum’
shader.cpp:260: error: initializing argument 1 of ‘void SLP(GLenum)’
shader.cpp:264: error: invalid conversion from ‘void*’ to ‘GLenum’
shader.cpp:264: error: initializing argument 1 of ‘void SLP(GLenum)’
shader.cpp:268: error: invalid conversion from ‘void*’ to ‘GLenum’
shader.cpp:268: error: initializing argument 1 of ‘void SLP(GLenum)’
shader.cpp:272: error: invalid conversion from ‘void*’ to ‘GLenum’
shader.cpp:272: error: initializing argument 1 of ‘void SLP(GLenum)’
shader.cpp:278: error: invalid conversion from ‘void*’ to ‘GLenum’
shader.cpp:278: error: initializing argument 1 of ‘void SLP(GLenum)’
make[2]: *** [shader.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1

[Updated on: Fri, 13 January 2012 18:31]

Re: Mednafen 0.9.18-WIP [message #2356 is a reply to message #2203 ] Fri, 13 January 2012 18:18 Go to previous messageGo to next message
Administrator  [PM]
Around line 89 of src/drivers/shader.cpp, change the SLP() bit from:

static void SLP(GLenum moe)

to

static void SLP(GLhandleARB moe)
Re: Mednafen 0.9.18-WIP [message #2357 is a reply to message #2356 ] Fri, 13 January 2012 18:27 Go to previous messageGo to next message
goldenegg  [PM]
Administrator wrote on Fri, 13 January 2012 19:18

Around line 89 of src/drivers/shader.cpp, change the SLP() bit from:

static void SLP(GLenum moe)

to

static void SLP(GLhandleARB moe)



That fixed that problem. Running in to one more Smile


depbase=`echo cputest/x86_cpu.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
gcc -DLOCALEDIR=\"/usr/local/share/locale\" -DHAVE_CONFIG_H -ffast-math -I../include -I../include/blip -I../intl -I.. -I/opt/local/include -I/opt/local/include -fsigned-char -Wall -Winline -Wshadow -Wempty-body -fomit-frame-pointer -finline-limit=6000 --param large-function-growth=800 --param inline-unit-growth=175 --param max-inline-insns-single=10000 -fno-strict-overflow -I/opt/local/include -I/opt/local/include -fsigned-char -Wall -Winline -Wshadow -Wempty-body -fomit-frame-pointer -finline-limit=6000 --param large-function-growth=800 --param inline-unit-growth=175 --param max-inline-insns-single=10000 -fno-strict-overflow -g -O2 -MT cputest/x86_cpu.o -MD -MP -MF $depbase.Tpo -c -o cputest/x86_cpu.o cputest/x86_cpu.c &&\
mv -f $depbase.Tpo $depbase.Po
/var/folders/4m/sk9zrj6j7ns87xxr82xp8h_80000gn/T//cc8FiOa0.s:52:suffix or operands invalid for `pushf'
/var/folders/4m/sk9zrj6j7ns87xxr82xp8h_80000gn/T//cc8FiOa0.s:53:suffix or operands invalid for `pop'
/var/folders/4m/sk9zrj6j7ns87xxr82xp8h_80000gn/T//cc8FiOa0.s:56:suffix or operands invalid for `push'
/var/folders/4m/sk9zrj6j7ns87xxr82xp8h_80000gn/T//cc8FiOa0.s:57:suffix or operands invalid for `popf'
/var/folders/4m/sk9zrj6j7ns87xxr82xp8h_80000gn/T//cc8FiOa0.s:58:suffix or operands invalid for `pushf'
/var/folders/4m/sk9zrj6j7ns87xxr82xp8h_80000gn/T//cc8FiOa0.s:59:suffix or operands invalid for `pop'
make[2]: *** [cputest/x86_cpu.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1


EDIT:

Fixed it.

I used the '--build=x86_64-apple-darwin10.0.0' parameter for the config and now it builds fine.

Thanks for the help!!!

[Updated on: Fri, 13 January 2012 18:37]

Re: Mednafen 0.9.18-WIP [message #2358 is a reply to message #2203 ] Fri, 13 January 2012 18:47 Go to previous messageGo to next message
goldenegg  [PM]
Celebrated too soon. Looks like the compiled binary doesn't work.

MacBook-Pro:src goldenegg$ ./mednafen
Starting Mednafen 0.9.18-WIP
 Base directory: /Users/goldenegg/.mednafen
 Internal emulation modules: nes snes gb gba pce pce_fast lynx md pcfx ngp vb wswan sms gg cdplay
 External emulation modules: 
Assertion failed: ((a + 0x7FFFFFFE) < a), function TestSignedOverflow, file tests.cpp, line 308.
Abort trap: 6


Seen this before?
Re: Mednafen 0.9.18-WIP [message #2359 is a reply to message #2357 ] Fri, 13 January 2012 18:47 Go to previous messageGo to next message
mistydemeo  [PM]
goldenegg: See my post above. You're probably on 64-bit, and Mednafen's configure script is incorrectly detecting your architecture. You can override the detection by specifying '--build=x86_64-apple-darwin`uname -r`'
Re: Mednafen 0.9.18-WIP [message #2360 is a reply to message #2359 ] Fri, 13 January 2012 18:49 Go to previous messageGo to next message
mistydemeo  [PM]
The math test failures occur if your compiler produced bad code. Try reducing the optimization level until you find a build that works without errors. You may have to build -O0 for no optimization at all.

[Updated on: Fri, 13 January 2012 18:50]

Re: Mednafen 0.9.18-WIP [message #2361 is a reply to message #2360 ] Fri, 13 January 2012 18:54 Go to previous messageGo to next message
goldenegg  [PM]
mistydemeo wrote on Fri, 13 January 2012 19:49

The math test failures occur if your compiler produced bad code. Try reducing the optimization level until you find a build that works without errors. You may have to build -O0 for no optimization at all.


Where do I pass the -O# parameter?
Re: Mednafen 0.9.18-WIP [message #2362 is a reply to message #2361 ] Fri, 13 January 2012 19:15 Go to previous messageGo to next message
mistydemeo  [PM]
Add it to your CFLAGS and CXXFLAGS environment variables. They're probably empty - if so, you can, e.g.

export CFLAGS=-Ox

I think the default -O level is 2. Using gcc-4.2 and llvm-gcc-4.2, I had to use -O0; -O1 didn't work.
Re: Mednafen 0.9.18-WIP [message #2363 is a reply to message #2203 ] Fri, 13 January 2012 19:22 Go to previous messageGo to next message
goldenegg  [PM]
Thank you so much! That worked!

Any idea what the performance impact is with the lower optimization setting?
Re: Mednafen 0.9.18-WIP [message #2364 is a reply to message #2363 ] Fri, 13 January 2012 19:26 Go to previous messageGo to next message
mistydemeo  [PM]
Performance is one of the things the optimization settings are for. No optimization does mean worse performance.
Re: Mednafen 0.9.18-WIP [message #2367 is a reply to message #2203 ] Sat, 14 January 2012 08:30 Go to previous messageGo to next message
Administrator  [PM]
Just an FYI, 0.9.18-WIP and earlier configure scripts mangle CFLAGS, CXXFLAGS, and CPPFLAGS together in wrong ways.

For when 0.9.19-WIP is released, you'll want to set both CFLAGS and CXXFLAGS, or just CPPFLAGS.

[Updated on: Sat, 14 January 2012 08:31]

Re: Mednafen 0.9.18-WIP [message #2372 is a reply to message #2203 ] Sun, 15 January 2012 10:31 Go to previous messageGo to next message
MrRockchip  [PM]
A small tip about installing SDL-1.2.14 on Mac OS X Lion :
if you will do plain
./configure

then you receive a lot of errors while making.
To avoid that, use
./configure --disable-assembly


Mac OS X Lion 10.7.2
Re: Mednafen 0.9.18-WIP [message #2378 is a reply to message #2203 ] Mon, 16 January 2012 10:40 Go to previous messageGo to next message
goldenegg  [PM]
MrRockchip wrote on Sun, 15 January 2012 12:33

I have problems when trying to compile Mednafen under Mac OS X Lion.
Resolved some issues, but ran into a new issue and got stuck.

My message contains quite a lot of code, so I decided to post it as a new thread.
Please, visit it: http://forum.fobby.net/index.php?t=tree&th=695

You could reply to me right here, or in the new thread I have created.


You need to run configure list this

./configure --build=x86_64-apple-darwin`uname -r`
Re: Mednafen 0.9.18-WIP [message #2379 is a reply to message #2378 ] Mon, 16 January 2012 11:18 Go to previous messageGo to previous message
MrRockchip  [PM]
goldenegg wrote on Mon, 16 January 2012 11:40


You need to run configure list this

./configure --build=x86_64-apple-darwin`uname -r`


Does not help. Probably because it is equal to
./configure --build=x86_64-apple-darwin11.2.0
in my case (I have found out my Darwin version with uname command earlier)

What are your permissions? Why does it allow your "./configure" to access
"/usr/local/lib" for libcdio and libsndfile , but does not allow mine? Confused

[Updated on: Mon, 16 January 2012 11:19]


Mac OS X Lion 10.7.2
Pages (2): [1  2    »]  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic:Mednafen 0.9.16-WIP
Next Topic:Mednafen 0.9.19-WIP
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ ]

Current Time: Tue Apr 23 11:46:09 CDT 2024
.:: Contact :: Home ::.

Powered by FUDforum.
Copyright © FUDforum Bulletin Board Software