Forums

Attached a new build
- Updated meka.nam with lots of stuff.
- Fixed ABOUT box crashing.
- Fixed rendering when VDP display is disabled and backdrop color rendering.
- Early TilemapViewer support for video mode 2 used by SG-1000 games, etc.
- Fixed a glitches in FileBrowser when using the mouse to open the ".." directory.
- Fixed light phaser hit position in game mode.
- SMS/GG ROM images smaller than 48KB default to using no mapper.
- Added support for variant of MSX-based Korean 8KB mapper used by Nemesis.

*EDIT* Build updated with a minor fix.

meka-2011-08-21-win32-proto.zip (755.48 KB)

Oh man, new MEKA is much slower. There is a way to force to start MEKA in Fullscreen instead of Windowed?

Sonic of 8! wrote

Oh man, new MEKA is much slower. There is a way to force to start MEKA in Fullscreen instead of Windowed?

ALT-ENTER switch to Fullscreen, it should be saved.

How slower ? Whats your framerate ? (and your CPU/video card, roughly)
There's still various issues to solve with different video drivers etc but maybe your computer has such issue, in which case I'd be happy to look for a fix.
Thanks!

Bock wrote

Meman87: it is the actual standalone Hang On ROM or the Hang On / Safari Hunt one?
Hang On / Safari Hunt behave differently and has those glitches in NTSC systems as far as I know. However having checked it now the glitches happens in MEKA evens in PAL emulation mode which is incorrect. In the meanwhile you can use the standalone Hang On version and it should be OK.

Done a quick check on what one I was playing and was Hang On / Safari Hunt one, so my bad. So checked the other one as you suggested and no problems (like on actual hardware).

Anyway sorry for not getting back to you on it sooner.

musuruan:
I made lots of fixes to the codebase today and got MEKA to compile and work on MacOSX with sound using the Makefile. There's still issues due to the missing X86 files that i will fix soon (as i have now bought and using a Mac).

I have now implemented the Decode_Tile() function in C so it should work on non X86 machines.

Again, MEKA is slower. I was running on a Pentium 4 at 2.66 Ghz and my video card is VIA/S3G UniChrome Pro IGP.

How slower? What is the framerate unthrottled?
Are you using directx or opengl driver?
There's lots of issues with the video system right now so any precision is welcome.

Just I starts the exe and MEKA was going on a black window... And it drain my free DRAM quickly and the only thing that I do, is summon the Windows Task Manager. I was using DirectX 9.0c and OpenGL on my PC is much slower (I was used on NO$ZOOMER and my PC freeze).

And I was executed the setup.bat and nothing was appeared at boxes.

Sonic of 8! wrote

Just I starts the exe and MEKA was going on a black window... And it drain my free DRAM quickly and the only thing that I do, is summon the Windows Task Manager. I was using DirectX 9.0c and OpenGL on my PC is much slower (I was used on NO$ZOOMER and my PC freeze).

It sounds tricky to find the reason of that bug.. hmm.
Could you please try to edit mekaw.cfg and change the video driver to use OpenGL instead?

Find the 'video_driver = directx' line and change to:
'
video_driver = opengl
'

Thanks a lot!

Quote

And I was executed the setup.bat and nothing was appeared at boxes.

Yes sorry this was broken, i will fix it soon hopefully.

Again, is slower.

And MEKA don't create a config file at all times (I copied from 0.73).

Sonic of 8! wrote

Again, is slower.
And MEKA don't create a config file at all times (I copied from 0.73).

You said previously it ran on a black window. I don't understand clearly. What it showing the interface? What kind of framerate do you have? (you can press CTRL-F to see framerate)

It is faster if:
- you press ESC to switch to game only mode?
- you stay in interface and close all windows apart from game window?

Thank you.

No. And I thin that MEKA runs a frame at 40 sec.

On my new Mac running Vista it also runs at 40 FPS which is strange. I will investigate the problem.

OK, I wait.

But a request: Add the Hidden FM PAR Codes that found by me at meka.pat file, please (found in Super Basketball FM VGM Pack, I think)?

Sonic of 8! wrote

OK, I wait.

But a request: Add the Hidden FM PAR Codes that found by me at meka.pat file, please (found in Super Basketball FM VGM Pack, I think)?

Yes that's cool. Can you send me new lines to add to meka.pat? other games that Super Basketball? (i forgot if there was other games you found it on)

I cannot send the codes in a meka.pat form, because I was in a Mobile WAP Connection. But, there is the codes:

Battle Out Run: 00DE00:01
Double Hawk: 00DD00:01
Dynamite Dux: 00D000:01
Rambo III: 00DE80:01
Summer Games: 00C001:01

Lovely, that's quite an impressive amount of games. I didn't know about some of them.

Bock wrote

musuruan:
I made lots of fixes to the codebase today and got MEKA to compile and work on MacOSX with sound using the Makefile. There's still issues due to the missing X86 files that i will fix soon (as i have now bought and using a Mac).

Sorry for the late response but I just read this thread again. I'll try to have a look soon.

Please also consider installing VirtualBox on the Mac and run a Linux distribution inside it.

Thanks for your hard work on meka.

That's what I found out trying to compile latest svn on a Fedora 15/x86_64:

If you set SYSTEM = unix in the Makefile you get the following error:

[...]
g++ -I. -Ilibs -I../include -DARCH_UNIX -DX86_ASM -DASM_SYMBOLS_REQUIRE_UNDERSCORE -Wall -O3 -ffast-math -fno-strength-reduce -funroll-all-loops -fomit-frame-pointer -c tvtype.c -oobj/tvtype.o
make: *** No rule to make target `obj/mappersa.o', needed by `../meka'. Stop.

If you set X86_ASM = no in the unix section, it will compile but it won't link because an ix86 system seems to be still needed to compile meka.

[...]
/usr/bin/ld: i386 architecture of input file `obj/eagle.o' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `obj/hq2x16.o' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `obj/hq2x32.o' is incompatible with i386:x86-64 output
obj/debugger.o: In function `Debugger_Applet_Layout(bool)':
debugger.c:(.text+0x47a): undefined reference to `al_set_target_bitmap'
debugger.c:(.text+0x48f): undefined reference to `al_clear_to_color'
[...]

Bock, will meka support x86_64 systems? If yes, I'll have another look when the transition will be made. Otherwise, I'll try to get my hands on a ix86 system to make further tests.

Can you remove mappersa.o and the other files from the link list? They aren't used required AFAIK.

The latest svn has some problems with the makefile:

make: *** No rule to make target `z80marat/Z80DebugHelpers.c', needed by `obj/z80marat.a'. Stop.

This is due to the fact that Z80DebugHelpers is a cpp file, but even correcting this issue didn't get me far.

So I did my test against svn r305. With this patched Makefile I could compile meka under Fedora 15 on a x86_64 system:

$ svn diff
Index: srcs/Makefile
===================================================================
--- srcs/Makefile (revision 305)
+++ srcs/Makefile (working copy)
@@ -36,8 +36,8 @@
#------------------------------------------------------
# SYSTEM = dos
# SYSTEM = win32
-# SYSTEM = unix
-SYSTEM = macosx
+SYSTEM = unix
+# SYSTEM = macosx
#------------------------------------------------------
BUILD = release
# BUILD = debug
@@ -84,9 +84,9 @@
MV = mv
MKDIR = mkdir
#--- Definitions
-DEF_OS = -DARCH_UNIX -DX86_ASM -DASM_SYMBOLS_REQUIRE_UNDERSCORE
+DEF_OS = -DARCH_UNIX #-DX86_ASM -DASM_SYMBOLS_REQUIRE_UNDERSCORE
INC_OS = -Ilibs -I../include
-X86_ASM = yes
+X86_ASM = no
#--- Libraries
LIB_OS = -Llibs -L/usr/X11R6/lib -lX11 -lXext -lm -lpthread -L../lib # This may require an update
LIB_OS += -lXcursor -lXpm
@@ -187,7 +187,8 @@
endif

ifeq ($(SYSTEM), unix)
-LIB_ALLEG = `allegro-config --libs`
+#LIB_ALLEG = `allegro-config --libs`
+LIB_ALLEG = -lallegro -lallegro_font -lallegro_audio -lallegro_primitives -lallegro_main -lallegro_image
endif

ifeq ($(SYSTEM), macosx)
@@ -217,7 +218,8 @@
OBJ_FEAT = $(OD)/checksum.o $(OD)/db.o $(OD)/vlfn.o $(OD)/patch.o $(OD)/saves.o
OBJ_CFG = $(OD)/config.o
OBJ_MISC = $(OD)/allegro4to5.o $(OD)/misc.o $(OD)/build.o $(OD)/fonts.o $(OD)/file.o $(OD)/data.o $(OD)/tools.o $(OD)/keyinfo.o $(OD)/drivers.o $(OD)/message.o $(OD)/capture.o $(OD)/errors.o $(OD)/sdsc.o $(OD)/setup.o
-OBJ_BLIT = $(OD)/blit.o $(OD)/blitintf.o $(OD)/eagle.o $(OD)/hq2x.o $(OD)/hq2x16.o $(OD)/hq2x32.o
+#OBJ_BLIT = $(OD)/blit.o $(OD)/blitintf.o $(OD)/eagle.o $(OD)/hq2x.o $(OD)/hq2x16.o $(OD)/hq2x32.o
+OBJ_BLIT = $(OD)/blit.o $(OD)/blitintf.o $(OD)/hq2x.o
OBJ_CPU = $(OD)/machine.o $(OD)/cpu.o
OBJ_VIDEO = $(OD)/video.o $(OD)/video_m2.o $(OD)/video_m5.o $(OD)/video_c.o $(OD)/vdp.o $(OD)/palette.o $(OD)/effects.o $(OD)/fskipper.o
OBJ_MACH = $(OD)/sg1ksc3k.o $(OD)/sf7000.o $(OD)/coleco.o $(OD)/fdc765.o

Please note that allegro-config is no longer available under allegro5 AFAIK therefore I had to explicitly specify the libraries as you did for the Mac.

Then I could run meka. I heard sound - a very good think for me after all these years of silence :-)

Problem I noticed:

* the fullscreen option isn't really a fullscreen - it just uses the entire meka window for the emulator window
* I couldn't use the joystick although it seems correctly detected at startup
* Pressing CTRL + ALT + arrow keys (required by some games like wonderboy in monsterland makes Fedora switching workplace - this is really annoying

Bock wrote

Can you remove mappersa.o and the other files from the link list? They aren't used required AFAIK.

The latest svn has some problems with the makefile:

[...]
make: *** No rule to make target `z80marat/Z80DebugHelpers.c', needed by `obj/z80marat.a'. Stop.

This is due to the fact that Z80DebugHelpers is a cpp file, but even correcting this issue didn't get me far.[/quote]

This you did try adding this file in the object list?
The makefile it is bound to always have missing or non-existing files here because I don't use it. It should be trivial to update that list when a file gets added or removed but i tend to forget it since i don't use the Makefile myself.

All the files in Meka sources are now C++ even though their extension is .c. The makefile should be calling g++ and eventually i will rename this.

Great to hear it is running :)
I will apply your patch thanks!
I have been comtemplating changing the default buttons to Z/X instead of CTRL/ALT.

Are you able to investigate the joystick problem further?

Thanks! Exciting times!

musuruan wrote

Please note that allegro-config is no longer available under allegro5 AFAIK therefore I had to explicitly specify the libraries as you did for the Mac.

Now it uses pkg-config. Something like this:

pkg-config --libs allegro-5.0 allegro_image-5.0

musuruan wrote

* the fullscreen option isn't really a fullscreen - it just uses the entire meka window for the emulator window

I didn't test this version because I use Debian (testing version) and it doesn't have Allegro5 in its packages =P
But at version 0.70, while running meka fullscreen at my wide-screen, the image is rendered with wrong aspect ratio (distortion/stretch)[/code]

musuruan wrote

* the fullscreen option isn't really a fullscreen - it just uses the entire meka window for the emulator window

Pressing ESCAPE switch between rendering the GUI or the Game only.
Pressing ALT-ENTER enable fullscreen mode (in either of them)

Some updates. I am still using r305 because I haven't yet found the time to have a closer look at the problem there are with HEAD under Linux.

The joystick problem is probably caused by the meka.inp file. By default Joypad 1 is "stick #2". If have only one stick you'll have to manually configure the Joypad. After doing this the joystick works as expected. Probably this setting can be better detected.

I can go to fullscreen pressing ALT+ENTER, but pressing these keys again will render the Gnome session broken. The screen will be restored to your previous resolution, but you can only see a portion of the screen of the size of the meka fullscreen window (I think it was 800x600 in my case), the rest of the screen is black and you cannot access it.

Using pkg-config to detect allegro libraries works as RodolfoRG kindly noticed.

Sonicof8: can you tell me if the performance are better now?
I also added options in the Setup screen so maybe you can try different drivers (DirectX/OpenGL).

Changes since previous build:

- Preliminary MacOSX port. [Omar]
- Changed default key mapping for Player 1 buttons to use Z/X. [Omar]
- Setup panel allows to select display driver and resolution. [Omar]
- Emulation:
- Added support for 4 PAK All Action mapper. [Omar]
- Hardware reset leaves RAM cleared with $F0 patterns on Japanese SMS.
This allow 'Ali Baba' to run properly. Better clearing pattern could be
implemented for other systems/countries after we've done more research. [Omar]
- Added support for mirrored VDP ports in $80..$BF range, as required by some
Korean games such as 'Pooyan', 'Sky Jaguar' or 'E.I.'. [Omar]
- Debugger:
- Added CR command ("Continue to next RET* instruction"). [Omar]
- Improved the range of disassembly before PC cursor when running loops. [Omar]
- Tools:
- TileViewer: support for showing full 16 KB range of tiles in legacy graphic modes. [Omar]

My next priority is to fix sound for non-60 Hz modes and get rid of the sound latency issues that accumulate sometimes.

meka-2011-10-23-win32-proto.zip (758.94 KB)

Wow, this was a pain to get going...

First, you have to checkout about 500 MB worth of files for Allegro. There's two hours shot to hell. Then the code needs fixing to compile on linux.

Rename: "srcs/z80marat/Z80DebugHelpers.cpp" to "srcs/z80marat/Z80DebugHelpers.c"

Next edit the Makefile:

#-----------------------------------------------------
# Option : Debugger
#-----------------------------------------------------
OBJ_CPU += $(OD)/debug.o $(OD)/debugger.o $(OD)/debughelper.o $(OD)/datadump.o

See that $(OD)/debughelper.o? That's new...

$(OD)/debug.o : z80marat/Debug.c z80marat/Z80.h
$(CC) $(CFLAGS) -c z80marat/Debug.c $(CC_OUT)$@

$(OD)/debughelper.o : z80marat/Z80DebugHelpers.c z80marat/Z80.h
$(CC) $(CFLAGS) -c z80marat/Z80DebugHelpers.c $(CC_OUT)$@

If you don't make that debughelper.o for after debugger.o, debugger.o fails during link saying the function in Z80DebugHelpers.c is missing. The z80marat.a looks like it was SUPPOSED to have that file, but it doesn't because it's not making an archive, it's merely making Z80.c:

$(CC) $(CFLAGS) z80marat/Z80.c $(CC_OUT)$@

See that? It compiles Z80.c to the output name (z80marat.a) and that's it!

Make those changes and now it compiles!! And promptly aborts due to a buffer overflow... which if you look into it closer is NOT a buffer overflow. The crazy nuts who maintain libc have added a thing called "Fortify" that checks for buffer overflows on "dangerous" commands... except they don't - they look for POSSIBLE buffer overflows and abort if one is POSSIBLE, not if it really occurs! So the realpath() command in the file init function was aborting because a buffer overflow was POSSIBLE.

So back to the editor... change the CFLAGS:

DEF_OS = -DARCH_UNIX -D_FORTIFY_SOURCE=0 #-DX86_ASM -DASM_SYMBOLS_REQUIRE_UNDERSCORE

That "-D_FORTIFY_SOURCE=0" turns off the checking in libc. And NOW it runs... at one frame per second. Even the gui is only running one frame per second. What kind of requirements does meka have? I'm running a 1.6 GHz CoreDuo with 945GM chipset/video. That should be WAY more than is needed for an SMS emulator. I can run N64 emulators on it! Maybe it's a timing error...

Chilly Willy wrote

First, you have to checkout about 500 MB worth of files for Allegro. There's two hours shot to hell.

Can't you get precompiled Allegro binaries+header somewhere?

Quote

Rename: "srcs/z80marat/Z80DebugHelpers.cpp" to "srcs/z80marat/Z80DebugHelpers.c"

I don't quite understand the need for all of this apart from the initial renaming (which is due to the fact that the Makefile doesn't have rules for .cpp files). If you just rename to .c what happens?

Quote

So the realpath() command in the file init function was aborting because a buffer overflow was POSSIBLE.

I will look into fixing that. Can you tell of other functions that are tagged as unsafe by the library you are using?

Quote

And NOW it runs... at one frame per second. Even the gui is only running one frame per second. What kind of requirements does meka have? I'm running a 1.6 GHz CoreDuo with 945GM chipset/video. That should be WAY more than is needed for an SMS emulator. I can run N64 emulators on it! Maybe it's a timing error...

It is certainly an issue we have to fix but it should be running decently fast. During the porting to Allegro 5 i had a lot of problems to deal with with the fact that Allegro 5 currently doesn't have any software rasterizer which leads to a lot of CPU<>GPU transfers given how Meka render some buffers. The problems is that Allegro does a lot of voodoo magic in our back instead of notifying of performances issues, so often things appears to works but of course they are very slow.

For reference, on my new iMac running Windows 7 playing Psycho Fox with GUI disabled, unthrottled 1/1, I get 350 FPS with DirectX driver and 1200 FPS with OpenGL. One could argue it should be way faster than that but its reasonably enough. The problem is that it takes one occurence of Allegro does black voodoo magic somewhere in the pipe to bottleneck everything down.

- Do you get performance difference in GUI and Game mode (pressing Escape?)

- In meka.c look for :
g_configuration.video_game_format_request = ALLEGRO_PIXEL_FORMAT_ANY_16_NO_ALPHA;
g_configuration.video_gui_format_request = ALLEGRO_PIXEL_FORMAT_ANY_NO_ALPHA;

Can you experiment changing those values (respectively for game and GUI modes) with some of the other Allegro defines and see if it does better?
Namely, trying without the NO_ALPHA variants, or trying the GUI format to match the game format, etc. But the pixel format for 'video_game_format_request' has to be a 16-bits format for now.

Thanks a lot for your help :)

I' d be so happy if it used SDL instead of Allegro... ;)
I could help on it if you want to (except sound :P)

Bock wrote

Chilly Willy wrote

First, you have to checkout about 500 MB worth of files for Allegro. There's two hours shot to hell.

Can't you get precompiled Allegro binaries+header somewhere?

4.x, not 5.x. That wasn't too bad other than all the junk the document dependencies pulled.

Quote

Quote

Rename: "srcs/z80marat/Z80DebugHelpers.cpp" to "srcs/z80marat/Z80DebugHelpers.c"

I don't quite understand the need for all of this apart from the initial renaming (which is due to the fact that the Makefile doesn't have rules for .cpp files). If you just rename to .c what happens?

If you just rename the file, everything compiles, but when it goes to link meka, it gives an error that debugger.o couldn't find Z80DebugHelper_IsRetExecuting(). I gave the reason why - the file that function is in is not linked into the executable. My debughelper.o target provides the file that has that function.

Quote

Quote

So the realpath() command in the file init function was aborting because a buffer overflow was POSSIBLE.

I will look into fixing that. Can you tell of other functions that are tagged as unsafe by the library you are using?

There's a method to print all the functions discussed along with fortify here:
https://wiki.kubuntu.org/ToolChain/CompilerFlags?action=show&redirect=Compil...

Quote

Quote

And NOW it runs... at one frame per second. Even the gui is only running one frame per second. What kind of requirements does meka have? I'm running a 1.6 GHz CoreDuo with 945GM chipset/video. That should be WAY more than is needed for an SMS emulator. I can run N64 emulators on it! Maybe it's a timing error...

It is certainly an issue we have to fix but it should be running decently fast. During the porting to Allegro 5 i had a lot of problems to deal with with the fact that Allegro 5 currently doesn't have any software rasterizer which leads to a lot of CPU<>GPU transfers given how Meka render some buffers. The problems is that Allegro does a lot of voodoo magic in our back instead of notifying of performances issues, so often things appears to works but of course they are very slow.

For reference, on my new iMac running Windows 7 playing Psycho Fox with GUI disabled, unthrottled 1/1, I get 350 FPS with DirectX driver and 1200 FPS with OpenGL. One could argue it should be way faster than that but its reasonably enough. The problem is that it takes one occurence of Allegro does black voodoo magic somewhere in the pipe to bottleneck everything down.

- Do you get performance difference in GUI and Game mode (pressing Escape?)

No, it runs the same speed. Might be something in allegro... maybe I needed to set some flag when I compiled it. I could just see them using a software renderer unless you tell it otherwise. :D

Quote

- In meka.c look for :
g_configuration.video_game_format_request = ALLEGRO_PIXEL_FORMAT_ANY_16_NO_ALPHA;
g_configuration.video_gui_format_request = ALLEGRO_PIXEL_FORMAT_ANY_NO_ALPHA;

Can you experiment changing those values (respectively for game and GUI modes) with some of the other Allegro defines and see if it does better?
Namely, trying without the NO_ALPHA variants, or trying the GUI format to match the game format, etc. But the pixel format for 'video_game_format_request' has to be a 16-bits format for now.

Thanks a lot for your help :)

I'll try a few things to see if I can't find the issue and report back. Thanks for the tips. :)

I (or you should be able to) will fix the Makefile to get rid of the library and just link all the Z80 stuff as regular objects files directly

Allegro 5 does actually have a software renderer my bad for the confusion, it is just that it is extremely slow. A lot of things in Allegro 5 seems terribly slow when I browse the code, i was a bit disappointed by the state of things to be honnest. Although doing the Allegro 5 port made MEKA much closer to be able to use lower-level library such as SDL so maybe I'll eventually switch to that.

Found my problem - it's the throttling. When I turn it to unthrottled, it's "full speed" - I put it in quotes because my old 1.6GHz CoreDuo isn't fast enough to run it at 60 Hz. I probably get 40 to 50 Hz out of it. So if you try to throttle on a slow system, it goes HORRIBLY SLOW!

Chilly Willy wrote

Found my problem - it's the throttling. When I turn it to unthrottled, it's "full speed" - I put it in quotes because my old 1.6GHz CoreDuo isn't fast enough to run it at 60 Hz. I probably get 40 to 50 Hz out of it. So if you try to throttle on a slow system, it goes HORRIBLY SLOW!

Thanks for the pointer, i will look into that. Were you able to tweak the video format parameters by any chance?

Note that it seems OK (if not full speed in the UI) on my 800MHz Atom CPU.

Bock wrote

Chilly Willy wrote

Found my problem - it's the throttling. When I turn it to unthrottled, it's "full speed" - I put it in quotes because my old 1.6GHz CoreDuo isn't fast enough to run it at 60 Hz. I probably get 40 to 50 Hz out of it. So if you try to throttle on a slow system, it goes HORRIBLY SLOW!

Thanks for the pointer, i will look into that. Were you able to tweak the video format parameters by any chance?

I've tried a few things, but the only thing that seems to make a difference between allegro and meka is the frameskip.

Oh - I just noticed something in the meka makefile... it doesn't turn on X86_ASM for the unix target. I should enable that and recompile.

And... it makes almost no difference. Any suggestions?

X86 code has a completely minor effect, in fact i am about to delete most of it. The slowdown seems to be do to Allegro locking/unlocking too many bitmaps. I'm working on it.

Bock wrote

X86 code has a completely minor effect, in fact i am about to delete most of it. The slowdown seems to be do to Allegro locking/unlocking too many bitmaps. I'm working on it.

Okay, I'll keep an eye on updates then. Nice work so far - it seems pretty solid, if a bit slow on my PC. :)

Sorry about a new release with no response. But tomorrow I test this.

Sonic of 8! wrote

Sorry about a new release with no response. But tomorrow I test this.

A #000000 (black) screen again (all of three video modes). And sometimes it gives a error.

Sonic of 8! wrote

Sonic of 8! wrote

Sorry about a new release with no response. But tomorrow I test this.

A #000000 (black) screen again (all of three video modes). And sometimes it gives a error.

What do you mean "again" ? You said it was slow the last time, not a black screen. What error does it give?

Sometimes, the window came black or transparent. And the error is one of that was give an instruction error on 0x???????... And may give the options of close or debugging the program. And again, slow.

Which window, the full MEKA window or the game window in the interface?
How can you tell that something is slow if it doesn't show?
When does the error show?

Bock wrote

Which window, the full MEKA window or the game window in the interface?
How can you tell that something is slow if it doesn't show?
When does the error show?

MEKA goes slow on interface. For a example, it don't show all the options/windows at time.

The error appears with:

A memória não pode ser "writen" (the memory cannot be "writen").

I might think that when mekaw was created the cfg and another files like meka.dsk, he tries to open but the mekaw don't was concluded themselves.

Later, I can record a video on my Mobile Phone, and I show how MEKA is slow.

Edit the config file and set it to unthrottled. Super-slow meka was (for me, at least) an issue with the throttle speed code.

Nope. The problem remains.

So, I finally decided to try this here (it means: compile allegro 5 by myself - as said, Debian doenst have it on its repositories).

I have the same issue mentioned about the file z80marat/Z80DebugHelpers.c as rule for $(OD)/z80marat.a: it doesn't exist . The real file has the .cpp extension. So I renamed the file, as its actually a .c file anyway.

I got a lot of warnings about enumeration values not being handled by switch statements, but I didn't look at them.

There were simple mistakes that usually don't harm anyone, like:

capture.c:79:21: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]

I don't know if v_start field is used when there's no scroll, but here's a warning:

g_widget.c: In function ‘void widget_scrollbar_update(t_widget*)’:
g_widget.c:498:13: warning: ‘v_start’ may be used uninitialized in this function [-Wuninitialized]

app_cheatfinder.c: In function ‘u32 _ZL21CheatFinder_ReadValueP14t_cheat_finderPK14t_memory_rangeP20t_cheat_finder_match.isra.1(const t_memory_range*, t_cheat_finder_match*)’:
app_cheatfinder.c:409:9: warning: ‘v’ may be used uninitialized in this function [-Wuninitialized]

As I use x86_64 architecture, I always pay attetion for error like that:

g_menu_i.c: In function ‘void gui_menus_init()’:
g_menu_i.c:157:136: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]

app_cheatfinder.c:167:181: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
app_cheatfinder.c:192:153: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
app_cheatfinder.c:207:178: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]

app_cheatfinder.c: In function ‘void CheatFinder_Update(t_cheat_finder*)’:
app_cheatfinder.c:318:43: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
app_cheatfinder.c:346:42: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]

Then I got another compilation error:

app_cheatfinder.c: In function ‘void CheatFinder_CallbackMemtypeSelect(t_widget*)’:
app_cheatfinder.c:535:40: error: cast from ‘void*’ to ‘int’ loses precision [-fpermissive]
app_cheatfinder.c: In function ‘void CheatFinder_CallbackValuetypeSelect(t_widget*)’:
app_cheatfinder.c:541:54: error: cast from ‘void*’ to ‘int’ loses precision [-fpermissive]
app_cheatfinder.c: In function ‘void CheatFinder_CallbackComparerSelect(t_widget*)’:
app_cheatfinder.c:547:51: error: cast from ‘void*’ to ‘int’ loses precision [-fpermissive]
app_cheatfinder.c: In function ‘void CheatFinder_CallbackCompareToSelect(t_widget*)’:
app_cheatfinder.c:553:55: error: cast from ‘void*’ to ‘int’ loses precision [-fpermissive]
app_cheatfinder.c: In function ‘void CheatFinder_CallbackSelectOneMatch(t_widget*)’:
app_cheatfinder.c:580:34: error: cast from ‘void*’ to ‘int’ loses precision [-fpermissive]

app_memview.c: In function ‘void MemoryViewer_ViewPaneCallback(t_widget*)’:
app_memview.c:627:49: error: cast from ‘void*’ to ‘int’ loses precision [-fpermissive]

We should avoid those pointer<->integer conversions for portability ;) Maybe you should make a struct+union to check when it's a real pointer or just an integer? Here, for a quick (and so ugly) fix, I've change it for (long).

In the Makefile, I've removed all the LIB_OS definitions for unix target, leaving it empty: they were useless and cause a link error here.
I've also changed the line for Allegro flags:

LIB_ALLEG = `pkg-config --cflags --libs allegro-5.0 allegro_image-5.0 allegro_audio-5.0 allegro_font-5.0 allegro_primitives-5.0`

I've got the same error said (and solved) by Chilly Willy.

obj/debugger.o: In function `Debugger_Hook(Z80*)':
debugger.c:(.text+0x4634): undefined reference to `Z80DebugHelper_IsRetExecuting(Z80 const*)'
collect2: ld returned 1 exit status

I did what he said and it works.

And when everything compiled... No Meka sound :P It keeps still when

Initializing sound system...
- Initializing sound card @ 44100 Hz

I can't launch Meka... =/

Thanks for your help. If you can make a patch with some of the change I'll apply them. I guess i should get myself a Linux box sometimes :)
.

RodolfoRG wrote

And when everything compiled... No Meka sound :P It keeps still when

Initializing sound system...
- Initializing sound card @ 44100 Hz

I can't launch Meka... =/

Can you run with GDB and see where it hangs?
Thanks a lot!

Bock wrote

Thanks for your help. If you can make a patch with some of the change I'll apply them.

I'll try to clean all the warnings, then I send you a patch.

Bock wrote

Can you run with GDB and see where it hangs?
Thanks a lot!

After I send a SIGINT (CTRL+C):

(gdb) bt
#0 0x00007ffff64367f1 in ppoll (fds=<optimized>, nfds=<optimized>,
timeout=<optimized>, sigmask=<optimized>)
at ../sysdeps/unix/sysv/linux/ppoll.c:57
#1 0x00007ffff46f1637 in pa_mainloop_poll ()
from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#2 0x00007ffff46f1c09 in pa_mainloop_iterate ()
from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#3 0x00007ffff79cdaa4 in pulseaudio_open ()
at /home/rodolfo/testes/allegro/5.0/addons/audio/pulseaudio.c:81
#4 0x00007ffff79c5ee2 in do_install_audio (mode=<optimized>)
at /home/rodolfo/testes/allegro/5.0/addons/audio/audio.c:268
#5 0x00007ffff79c5f5a in do_install_audio (mode=<optimized>)
at /home/rodolfo/testes/allegro/5.0/addons/audio/audio.c:186
#6 0x000000000045ec02 in Sound_Init() ()
#7 0x000000000040477c in main ()

Do the Allegro audio samples works for you?

Author	Message
Bock Site Admin Joined: 08 Jul 2001 Posts: 8731 Location: Paris, France	Test build 2011-08-21 Posted: Sun Aug 21, 2011 6:14 pm
	Attached a new build - Updated meka.nam with lots of stuff. - Fixed ABOUT box crashing. - Fixed rendering when VDP display is disabled and backdrop color rendering. - Early TilemapViewer support for video mode 2 used by SG-1000 games, etc. - Fixed a glitches in FileBrowser when using the mouse to open the ".." directory. - Fixed light phaser hit position in game mode. - SMS/GG ROM images smaller than 48KB default to using no mapper. - Added support for variant of MSX-based Korean 8KB mapper used by Nemesis. EDIT Build updated with a minor fix. meka-2011-08-21-win32-proto.zip (755.48 KB)

Sonic of 8! Joined: 21 Jun 2010 Posts: 200 Location: Earth Planet	Posted: Tue Sep 06, 2011 8:19 pm
	Oh man, new MEKA is much slower. There is a way to force to start MEKA in Fullscreen instead of Windowed?

Bock Site Admin Joined: 08 Jul 2001 Posts: 8731 Location: Paris, France	Posted: Tue Sep 06, 2011 8:26 pm
	Sonic of 8! wrote Oh man, new MEKA is much slower. There is a way to force to start MEKA in Fullscreen instead of Windowed? ALT-ENTER switch to Fullscreen, it should be saved. How slower ? Whats your framerate ? (and your CPU/video card, roughly) There's still various issues to solve with different video drivers etc but maybe your computer has such issue, in which case I'd be happy to look for a fix. Thanks!

meman887 Joined: 31 Aug 2006 Posts: 38 Location: United Kingdom, Glasgow	Posted: Sun Sep 11, 2011 2:40 am
	Bock wrote Meman87: it is the actual standalone Hang On ROM or the Hang On / Safari Hunt one? Hang On / Safari Hunt behave differently and has those glitches in NTSC systems as far as I know. However having checked it now the glitches happens in MEKA evens in PAL emulation mode which is incorrect. In the meanwhile you can use the standalone Hang On version and it should be OK. Done a quick check on what one I was playing and was Hang On / Safari Hunt one, so my bad. So checked the other one as you suggested and no problems (like on actual hardware). Anyway sorry for not getting back to you on it sooner.

Bock Site Admin Joined: 08 Jul 2001 Posts: 8731 Location: Paris, France	Posted: Sun Sep 11, 2011 10:09 pm
	musuruan: I made lots of fixes to the codebase today and got MEKA to compile and work on MacOSX with sound using the Makefile. There's still issues due to the missing X86 files that i will fix soon (as i have now bought and using a Mac).

Bock Site Admin Joined: 08 Jul 2001 Posts: 8731 Location: Paris, France	Posted: Sun Sep 11, 2011 11:03 pm
	I have now implemented the Decode_Tile() function in C so it should work on non X86 machines.

Sonic of 8! Joined: 21 Jun 2010 Posts: 200 Location: Earth Planet	Posted: Fri Sep 23, 2011 6:04 pm
	Again, MEKA is slower. I was running on a Pentium 4 at 2.66 Ghz and my video card is VIA/S3G UniChrome Pro IGP.

Bock Site Admin Joined: 08 Jul 2001 Posts: 8731 Location: Paris, France	Posted: Fri Sep 23, 2011 8:41 pm
	How slower? What is the framerate unthrottled? Are you using directx or opengl driver? There's lots of issues with the video system right now so any precision is welcome.

Sonic of 8! Joined: 21 Jun 2010 Posts: 200 Location: Earth Planet	Posted: Fri Sep 23, 2011 11:29 pm
	Just I starts the exe and MEKA was going on a black window... And it drain my free DRAM quickly and the only thing that I do, is summon the Windows Task Manager. I was using DirectX 9.0c and OpenGL on my PC is much slower (I was used on NO$ZOOMER and my PC freeze). And I was executed the setup.bat and nothing was appeared at boxes.

Bock Site Admin Joined: 08 Jul 2001 Posts: 8731 Location: Paris, France	Posted: Fri Sep 23, 2011 11:44 pm
	Sonic of 8! wrote Just I starts the exe and MEKA was going on a black window... And it drain my free DRAM quickly and the only thing that I do, is summon the Windows Task Manager. I was using DirectX 9.0c and OpenGL on my PC is much slower (I was used on NO$ZOOMER and my PC freeze). It sounds tricky to find the reason of that bug.. hmm. Could you please try to edit mekaw.cfg and change the video driver to use OpenGL instead? Find the 'video_driver = directx' line and change to: ' video_driver = opengl ' Thanks a lot! Quote And I was executed the setup.bat and nothing was appeared at boxes. Yes sorry this was broken, i will fix it soon hopefully.

Sonic of 8! Joined: 21 Jun 2010 Posts: 200 Location: Earth Planet	Posted: Sat Sep 24, 2011 12:19 am
	Again, is slower. And MEKA don't create a config file at all times (I copied from 0.73).

Bock Site Admin Joined: 08 Jul 2001 Posts: 8731 Location: Paris, France	Posted: Sat Sep 24, 2011 9:47 am
	Sonic of 8! wrote Again, is slower. And MEKA don't create a config file at all times (I copied from 0.73). You said previously it ran on a black window. I don't understand clearly. What it showing the interface? What kind of framerate do you have? (you can press CTRL-F to see framerate) It is faster if: - you press ESC to switch to game only mode? - you stay in interface and close all windows apart from game window? Thank you.

Sonic of 8! Joined: 21 Jun 2010 Posts: 200 Location: Earth Planet	Posted: Sat Sep 24, 2011 5:27 pm Last edited by Sonic of 8! on Sat Sep 24, 2011 5:30 pm; edited 1 time in total
	No. And I thin that MEKA runs a frame at 40 sec.

Bock Site Admin Joined: 08 Jul 2001 Posts: 8731 Location: Paris, France	Posted: Sat Sep 24, 2011 9:31 pm
	On my new Mac running Vista it also runs at 40 FPS which is strange. I will investigate the problem.

Sonic of 8! Joined: 21 Jun 2010 Posts: 200 Location: Earth Planet	Posted: Sun Sep 25, 2011 1:57 am
	OK, I wait. But a request: Add the Hidden FM PAR Codes that found by me at meka.pat file, please (found in Super Basketball FM VGM Pack, I think)?

Bock Site Admin Joined: 08 Jul 2001 Posts: 8731 Location: Paris, France	Posted: Sun Sep 25, 2011 10:58 am
	Sonic of 8! wrote OK, I wait. But a request: Add the Hidden FM PAR Codes that found by me at meka.pat file, please (found in Super Basketball FM VGM Pack, I think)? Yes that's cool. Can you send me new lines to add to meka.pat? other games that Super Basketball? (i forgot if there was other games you found it on)

Sonic of 8! Joined: 21 Jun 2010 Posts: 200 Location: Earth Planet	Posted: Sun Sep 25, 2011 7:27 pm
	I cannot send the codes in a meka.pat form, because I was in a Mobile WAP Connection. But, there is the codes: Battle Out Run: 00DE00:01 Double Hawk: 00DD00:01 Dynamite Dux: 00D000:01 Rambo III: 00DE80:01 Summer Games: 00C001:01

Bock Site Admin Joined: 08 Jul 2001 Posts: 8731 Location: Paris, France	Posted: Sun Sep 25, 2011 11:51 pm
	Lovely, that's quite an impressive amount of games. I didn't know about some of them.

musuruan Joined: 14 May 2006 Posts: 34	Posted: Wed Oct 05, 2011 7:58 am
musuruan Joined: 14 May 2006 Posts: 34	Bock wrote musuruan: I made lots of fixes to the codebase today and got MEKA to compile and work on MacOSX with sound using the Makefile. There's still issues due to the missing X86 files that i will fix soon (as i have now bought and using a Mac). Sorry for the late response but I just read this thread again. I'll try to have a look soon. Please also consider installing VirtualBox on the Mac and run a Linux distribution inside it. Thanks for your hard work on meka.

musuruan Joined: 14 May 2006 Posts: 34	Posted: Sun Oct 09, 2011 1:54 pm
musuruan Joined: 14 May 2006 Posts: 34	That's what I found out trying to compile latest svn on a Fedora 15/x86_64: If you set SYSTEM = unix in the Makefile you get the following error: [...] g++ -I. -Ilibs -I../include -DARCH_UNIX -DX86_ASM -DASM_SYMBOLS_REQUIRE_UNDERSCORE -Wall -O3 -ffast-math -fno-strength-reduce -funroll-all-loops -fomit-frame-pointer -c tvtype.c -oobj/tvtype.o make: *** No rule to make target `obj/mappersa.o', needed by `../meka'. Stop. If you set X86_ASM = no in the unix section, it will compile but it won't link because an ix86 system seems to be still needed to compile meka. [...] /usr/bin/ld: i386 architecture of input file `obj/eagle.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `obj/hq2x16.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `obj/hq2x32.o' is incompatible with i386:x86-64 output obj/debugger.o: In function `Debugger_Applet_Layout(bool)': debugger.c:(.text+0x47a): undefined reference to `al_set_target_bitmap' debugger.c:(.text+0x48f): undefined reference to `al_clear_to_color' [...] Bock, will meka support x86_64 systems? If yes, I'll have another look when the transition will be made. Otherwise, I'll try to get my hands on a ix86 system to make further tests.

Bock Site Admin Joined: 08 Jul 2001 Posts: 8731 Location: Paris, France	Posted: Sun Oct 09, 2011 10:31 pm
	Can you remove mappersa.o and the other files from the link list? They aren't used required AFAIK.

musuruan Joined: 14 May 2006 Posts: 34	Posted: Sat Oct 15, 2011 6:07 pm
musuruan Joined: 14 May 2006 Posts: 34	The latest svn has some problems with the makefile: make: *** No rule to make target `z80marat/Z80DebugHelpers.c', needed by `obj/z80marat.a'. Stop. This is due to the fact that Z80DebugHelpers is a cpp file, but even correcting this issue didn't get me far. So I did my test against svn r305. With this patched Makefile I could compile meka under Fedora 15 on a x86_64 system: $ svn diff Index: srcs/Makefile =================================================================== --- srcs/Makefile (revision 305) +++ srcs/Makefile (working copy) @@ -36,8 +36,8 @@ #------------------------------------------------------ # SYSTEM = dos # SYSTEM = win32 -# SYSTEM = unix -SYSTEM = macosx +SYSTEM = unix +# SYSTEM = macosx #------------------------------------------------------ BUILD = release # BUILD = debug @@ -84,9 +84,9 @@ MV = mv MKDIR = mkdir #--- Definitions -DEF_OS = -DARCH_UNIX -DX86_ASM -DASM_SYMBOLS_REQUIRE_UNDERSCORE +DEF_OS = -DARCH_UNIX #-DX86_ASM -DASM_SYMBOLS_REQUIRE_UNDERSCORE INC_OS = -Ilibs -I../include -X86_ASM = yes +X86_ASM = no #--- Libraries LIB_OS = -Llibs -L/usr/X11R6/lib -lX11 -lXext -lm -lpthread -L../lib # This may require an update LIB_OS += -lXcursor -lXpm @@ -187,7 +187,8 @@ endif ifeq ($(SYSTEM), unix) -LIB_ALLEG = `allegro-config --libs` +#LIB_ALLEG = `allegro-config --libs` +LIB_ALLEG = -lallegro -lallegro_font -lallegro_audio -lallegro_primitives -lallegro_main -lallegro_image endif ifeq ($(SYSTEM), macosx) @@ -217,7 +218,8 @@ OBJ_FEAT = $(OD)/checksum.o $(OD)/db.o $(OD)/vlfn.o $(OD)/patch.o $(OD)/saves.o OBJ_CFG = $(OD)/config.o OBJ_MISC = $(OD)/allegro4to5.o $(OD)/misc.o $(OD)/build.o $(OD)/fonts.o $(OD)/file.o $(OD)/data.o $(OD)/tools.o $(OD)/keyinfo.o $(OD)/drivers.o $(OD)/message.o $(OD)/capture.o $(OD)/errors.o $(OD)/sdsc.o $(OD)/setup.o -OBJ_BLIT = $(OD)/blit.o $(OD)/blitintf.o $(OD)/eagle.o $(OD)/hq2x.o $(OD)/hq2x16.o $(OD)/hq2x32.o +#OBJ_BLIT = $(OD)/blit.o $(OD)/blitintf.o $(OD)/eagle.o $(OD)/hq2x.o $(OD)/hq2x16.o $(OD)/hq2x32.o +OBJ_BLIT = $(OD)/blit.o $(OD)/blitintf.o $(OD)/hq2x.o OBJ_CPU = $(OD)/machine.o $(OD)/cpu.o OBJ_VIDEO = $(OD)/video.o $(OD)/video_m2.o $(OD)/video_m5.o $(OD)/video_c.o $(OD)/vdp.o $(OD)/palette.o $(OD)/effects.o $(OD)/fskipper.o OBJ_MACH = $(OD)/sg1ksc3k.o $(OD)/sf7000.o $(OD)/coleco.o $(OD)/fdc765.o Please note that allegro-config is no longer available under allegro5 AFAIK therefore I had to explicitly specify the libraries as you did for the Mac. Then I could run meka. I heard sound - a very good think for me after all these years of silence :-) Problem I noticed: * the fullscreen option isn't really a fullscreen - it just uses the entire meka window for the emulator window * I couldn't use the joystick although it seems correctly detected at startup * Pressing CTRL + ALT + arrow keys (required by some games like wonderboy in monsterland makes Fedora switching workplace - this is really annoying

Bock Site Admin Joined: 08 Jul 2001 Posts: 8731 Location: Paris, France	Posted: Sun Oct 16, 2011 12:15 pm
	Bock wrote Can you remove mappersa.o and the other files from the link list? They aren't used required AFAIK. The latest svn has some problems with the makefile: [...] make: *** No rule to make target `z80marat/Z80DebugHelpers.c', needed by `obj/z80marat.a'. Stop. This is due to the fact that Z80DebugHelpers is a cpp file, but even correcting this issue didn't get me far.[/quote] This you did try adding this file in the object list? The makefile it is bound to always have missing or non-existing files here because I don't use it. It should be trivial to update that list when a file gets added or removed but i tend to forget it since i don't use the Makefile myself. All the files in Meka sources are now C++ even though their extension is .c. The makefile should be calling g++ and eventually i will rename this. Great to hear it is running :) I will apply your patch thanks! I have been comtemplating changing the default buttons to Z/X instead of CTRL/ALT. Are you able to investigate the joystick problem further? Thanks! Exciting times!

RodolfoRG Joined: 08 Mar 2005 Posts: 8 Location: Brazil	Posted: Sun Oct 16, 2011 6:37 pm
RodolfoRG Joined: 08 Mar 2005 Posts: 8 Location: Brazil	musuruan wrote Please note that allegro-config is no longer available under allegro5 AFAIK therefore I had to explicitly specify the libraries as you did for the Mac. Now it uses pkg-config. Something like this: pkg-config --libs allegro-5.0 allegro_image-5.0 musuruan wrote * the fullscreen option isn't really a fullscreen - it just uses the entire meka window for the emulator window I didn't test this version because I use Debian (testing version) and it doesn't have Allegro5 in its packages =P But at version 0.70, while running meka fullscreen at my wide-screen, the image is rendered with wrong aspect ratio (distortion/stretch)[/code]

Bock Site Admin Joined: 08 Jul 2001 Posts: 8731 Location: Paris, France	Posted: Sun Oct 16, 2011 7:21 pm
	musuruan wrote * the fullscreen option isn't really a fullscreen - it just uses the entire meka window for the emulator window Pressing ESCAPE switch between rendering the GUI or the Game only. Pressing ALT-ENTER enable fullscreen mode (in either of them)

musuruan Joined: 14 May 2006 Posts: 34	Posted: Sun Oct 23, 2011 6:11 pm
musuruan Joined: 14 May 2006 Posts: 34	Some updates. I am still using r305 because I haven't yet found the time to have a closer look at the problem there are with HEAD under Linux. The joystick problem is probably caused by the meka.inp file. By default Joypad 1 is "stick #2". If have only one stick you'll have to manually configure the Joypad. After doing this the joystick works as expected. Probably this setting can be better detected. I can go to fullscreen pressing ALT+ENTER, but pressing these keys again will render the Gnome session broken. The screen will be restored to your previous resolution, but you can only see a portion of the screen of the size of the meka fullscreen window (I think it was 800x600 in my case), the rest of the screen is black and you cannot access it. Using pkg-config to detect allegro libraries works as RodolfoRG kindly noticed.

Bock Site Admin Joined: 08 Jul 2001 Posts: 8731 Location: Paris, France	Test build 2011-10-23 Posted: Sun Oct 23, 2011 7:29 pm
	Sonicof8: can you tell me if the performance are better now? I also added options in the Setup screen so maybe you can try different drivers (DirectX/OpenGL). Changes since previous build: - Preliminary MacOSX port. [Omar] - Changed default key mapping for Player 1 buttons to use Z/X. [Omar] - Setup panel allows to select display driver and resolution. [Omar] - Emulation: - Added support for 4 PAK All Action mapper. [Omar] - Hardware reset leaves RAM cleared with $F0 patterns on Japanese SMS. This allow 'Ali Baba' to run properly. Better clearing pattern could be implemented for other systems/countries after we've done more research. [Omar] - Added support for mirrored VDP ports in $80..$BF range, as required by some Korean games such as 'Pooyan', 'Sky Jaguar' or 'E.I.'. [Omar] - Debugger: - Added CR command ("Continue to next RET* instruction"). [Omar] - Improved the range of disassembly before PC cursor when running loops. [Omar] - Tools: - TileViewer: support for showing full 16 KB range of tiles in legacy graphic modes. [Omar] My next priority is to fix sound for non-60 Hz modes and get rid of the sound latency issues that accumulate sometimes. meka-2011-10-23-win32-proto.zip (758.94 KB)

Chilly Willy Joined: 23 Jan 2011 Posts: 65 Location: The Land of Enchantment	Posted: Mon Oct 24, 2011 12:05 am
	Wow, this was a pain to get going... First, you have to checkout about 500 MB worth of files for Allegro. There's two hours shot to hell. Then the code needs fixing to compile on linux. Rename: "srcs/z80marat/Z80DebugHelpers.cpp" to "srcs/z80marat/Z80DebugHelpers.c" Next edit the Makefile: #----------------------------------------------------- # Option : Debugger #----------------------------------------------------- OBJ_CPU += $(OD)/debug.o $(OD)/debugger.o $(OD)/debughelper.o $(OD)/datadump.o See that $(OD)/debughelper.o? That's new... $(OD)/debug.o : z80marat/Debug.c z80marat/Z80.h $(CC) $(CFLAGS) -c z80marat/Debug.c $(CC_OUT)$@ $(OD)/debughelper.o : z80marat/Z80DebugHelpers.c z80marat/Z80.h $(CC) $(CFLAGS) -c z80marat/Z80DebugHelpers.c $(CC_OUT)$@ If you don't make that debughelper.o for after debugger.o, debugger.o fails during link saying the function in Z80DebugHelpers.c is missing. The z80marat.a looks like it was SUPPOSED to have that file, but it doesn't because it's not making an archive, it's merely making Z80.c: $(CC) $(CFLAGS) z80marat/Z80.c $(CC_OUT)$@ See that? It compiles Z80.c to the output name (z80marat.a) and that's it! Make those changes and now it compiles!! And promptly aborts due to a buffer overflow... which if you look into it closer is NOT a buffer overflow. The crazy nuts who maintain libc have added a thing called "Fortify" that checks for buffer overflows on "dangerous" commands... except they don't - they look for POSSIBLE buffer overflows and abort if one is POSSIBLE, not if it really occurs! So the realpath() command in the file init function was aborting because a buffer overflow was POSSIBLE. So back to the editor... change the CFLAGS: DEF_OS = -DARCH_UNIX -D_FORTIFY_SOURCE=0 #-DX86_ASM -DASM_SYMBOLS_REQUIRE_UNDERSCORE That "-D_FORTIFY_SOURCE=0" turns off the checking in libc. And NOW it runs... at one frame per second. Even the gui is only running one frame per second. What kind of requirements does meka have? I'm running a 1.6 GHz CoreDuo with 945GM chipset/video. That should be WAY more than is needed for an SMS emulator. I can run N64 emulators on it! Maybe it's a timing error...

Bock Site Admin Joined: 08 Jul 2001 Posts: 8731 Location: Paris, France	Posted: Mon Oct 24, 2011 12:31 am
	Chilly Willy wrote First, you have to checkout about 500 MB worth of files for Allegro. There's two hours shot to hell. Can't you get precompiled Allegro binaries+header somewhere? Quote Rename: "srcs/z80marat/Z80DebugHelpers.cpp" to "srcs/z80marat/Z80DebugHelpers.c" I don't quite understand the need for all of this apart from the initial renaming (which is due to the fact that the Makefile doesn't have rules for .cpp files). If you just rename to .c what happens? Quote So the realpath() command in the file init function was aborting because a buffer overflow was POSSIBLE. I will look into fixing that. Can you tell of other functions that are tagged as unsafe by the library you are using? Quote And NOW it runs... at one frame per second. Even the gui is only running one frame per second. What kind of requirements does meka have? I'm running a 1.6 GHz CoreDuo with 945GM chipset/video. That should be WAY more than is needed for an SMS emulator. I can run N64 emulators on it! Maybe it's a timing error... It is certainly an issue we have to fix but it should be running decently fast. During the porting to Allegro 5 i had a lot of problems to deal with with the fact that Allegro 5 currently doesn't have any software rasterizer which leads to a lot of CPU<>GPU transfers given how Meka render some buffers. The problems is that Allegro does a lot of voodoo magic in our back instead of notifying of performances issues, so often things appears to works but of course they are very slow. For reference, on my new iMac running Windows 7 playing Psycho Fox with GUI disabled, unthrottled 1/1, I get 350 FPS with DirectX driver and 1200 FPS with OpenGL. One could argue it should be way faster than that but its reasonably enough. The problem is that it takes one occurence of Allegro does black voodoo magic somewhere in the pipe to bottleneck everything down. - Do you get performance difference in GUI and Game mode (pressing Escape?) - In meka.c look for : g_configuration.video_game_format_request = ALLEGRO_PIXEL_FORMAT_ANY_16_NO_ALPHA; g_configuration.video_gui_format_request = ALLEGRO_PIXEL_FORMAT_ANY_NO_ALPHA; Can you experiment changing those values (respectively for game and GUI modes) with some of the other Allegro defines and see if it does better? Namely, trying without the NO_ALPHA variants, or trying the GUI format to match the game format, etc. But the pixel format for 'video_game_format_request' has to be a 16-bits format for now. Thanks a lot for your help :)

RodolfoRG Joined: 08 Mar 2005 Posts: 8 Location: Brazil	Posted: Mon Oct 24, 2011 12:40 am
RodolfoRG Joined: 08 Mar 2005 Posts: 8 Location: Brazil	I' d be so happy if it used SDL instead of Allegro... ;) I could help on it if you want to (except sound :P)

Chilly Willy Joined: 23 Jan 2011 Posts: 65 Location: The Land of Enchantment	Posted: Mon Oct 24, 2011 6:13 am
	Bock wrote Chilly Willy wrote First, you have to checkout about 500 MB worth of files for Allegro. There's two hours shot to hell. Can't you get precompiled Allegro binaries+header somewhere? 4.x, not 5.x. That wasn't too bad other than all the junk the document dependencies pulled. Quote Quote Rename: "srcs/z80marat/Z80DebugHelpers.cpp" to "srcs/z80marat/Z80DebugHelpers.c" I don't quite understand the need for all of this apart from the initial renaming (which is due to the fact that the Makefile doesn't have rules for .cpp files). If you just rename to .c what happens? If you just rename the file, everything compiles, but when it goes to link meka, it gives an error that debugger.o couldn't find Z80DebugHelper_IsRetExecuting(). I gave the reason why - the file that function is in is not linked into the executable. My debughelper.o target provides the file that has that function. Quote Quote So the realpath() command in the file init function was aborting because a buffer overflow was POSSIBLE. I will look into fixing that. Can you tell of other functions that are tagged as unsafe by the library you are using? There's a method to print all the functions discussed along with fortify here: https://wiki.kubuntu.org/ToolChain/CompilerFlags?action=show&redirect=Compil... Quote Quote And NOW it runs... at one frame per second. Even the gui is only running one frame per second. What kind of requirements does meka have? I'm running a 1.6 GHz CoreDuo with 945GM chipset/video. That should be WAY more than is needed for an SMS emulator. I can run N64 emulators on it! Maybe it's a timing error... It is certainly an issue we have to fix but it should be running decently fast. During the porting to Allegro 5 i had a lot of problems to deal with with the fact that Allegro 5 currently doesn't have any software rasterizer which leads to a lot of CPU<>GPU transfers given how Meka render some buffers. The problems is that Allegro does a lot of voodoo magic in our back instead of notifying of performances issues, so often things appears to works but of course they are very slow. For reference, on my new iMac running Windows 7 playing Psycho Fox with GUI disabled, unthrottled 1/1, I get 350 FPS with DirectX driver and 1200 FPS with OpenGL. One could argue it should be way faster than that but its reasonably enough. The problem is that it takes one occurence of Allegro does black voodoo magic somewhere in the pipe to bottleneck everything down. - Do you get performance difference in GUI and Game mode (pressing Escape?) No, it runs the same speed. Might be something in allegro... maybe I needed to set some flag when I compiled it. I could just see them using a software renderer unless you tell it otherwise. :D Quote - In meka.c look for : g_configuration.video_game_format_request = ALLEGRO_PIXEL_FORMAT_ANY_16_NO_ALPHA; g_configuration.video_gui_format_request = ALLEGRO_PIXEL_FORMAT_ANY_NO_ALPHA; Can you experiment changing those values (respectively for game and GUI modes) with some of the other Allegro defines and see if it does better? Namely, trying without the NO_ALPHA variants, or trying the GUI format to match the game format, etc. But the pixel format for 'video_game_format_request' has to be a 16-bits format for now. Thanks a lot for your help :) I'll try a few things to see if I can't find the issue and report back. Thanks for the tips. :)

Bock Site Admin Joined: 08 Jul 2001 Posts: 8731 Location: Paris, France	Posted: Mon Oct 24, 2011 8:50 am
	I (or you should be able to) will fix the Makefile to get rid of the library and just link all the Z80 stuff as regular objects files directly Allegro 5 does actually have a software renderer my bad for the confusion, it is just that it is extremely slow. A lot of things in Allegro 5 seems terribly slow when I browse the code, i was a bit disappointed by the state of things to be honnest. Although doing the Allegro 5 port made MEKA much closer to be able to use lower-level library such as SDL so maybe I'll eventually switch to that.

Chilly Willy Joined: 23 Jan 2011 Posts: 65 Location: The Land of Enchantment	Posted: Fri Oct 28, 2011 2:49 am
	Found my problem - it's the throttling. When I turn it to unthrottled, it's "full speed" - I put it in quotes because my old 1.6GHz CoreDuo isn't fast enough to run it at 60 Hz. I probably get 40 to 50 Hz out of it. So if you try to throttle on a slow system, it goes HORRIBLY SLOW!

Bock Site Admin Joined: 08 Jul 2001 Posts: 8731 Location: Paris, France	Posted: Fri Oct 28, 2011 8:45 am
	Chilly Willy wrote Found my problem - it's the throttling. When I turn it to unthrottled, it's "full speed" - I put it in quotes because my old 1.6GHz CoreDuo isn't fast enough to run it at 60 Hz. I probably get 40 to 50 Hz out of it. So if you try to throttle on a slow system, it goes HORRIBLY SLOW! Thanks for the pointer, i will look into that. Were you able to tweak the video format parameters by any chance?

Maxim Site Admin Joined: 19 Oct 1999 Posts: 15006 Location: London	Posted: Fri Oct 28, 2011 9:00 am
	Note that it seems OK (if not full speed in the UI) on my 800MHz Atom CPU.

Chilly Willy Joined: 23 Jan 2011 Posts: 65 Location: The Land of Enchantment	Posted: Fri Oct 28, 2011 5:27 pm
	Bock wrote Chilly Willy wrote Found my problem - it's the throttling. When I turn it to unthrottled, it's "full speed" - I put it in quotes because my old 1.6GHz CoreDuo isn't fast enough to run it at 60 Hz. I probably get 40 to 50 Hz out of it. So if you try to throttle on a slow system, it goes HORRIBLY SLOW! Thanks for the pointer, i will look into that. Were you able to tweak the video format parameters by any chance? I've tried a few things, but the only thing that seems to make a difference between allegro and meka is the frameskip. Oh - I just noticed something in the meka makefile... it doesn't turn on X86_ASM for the unix target. I should enable that and recompile. And... it makes almost no difference. Any suggestions?

Bock Site Admin Joined: 08 Jul 2001 Posts: 8731 Location: Paris, France	Posted: Fri Oct 28, 2011 5:56 pm
	X86 code has a completely minor effect, in fact i am about to delete most of it. The slowdown seems to be do to Allegro locking/unlocking too many bitmaps. I'm working on it.

Chilly Willy Joined: 23 Jan 2011 Posts: 65 Location: The Land of Enchantment	Posted: Fri Oct 28, 2011 6:06 pm
	Bock wrote X86 code has a completely minor effect, in fact i am about to delete most of it. The slowdown seems to be do to Allegro locking/unlocking too many bitmaps. I'm working on it. Okay, I'll keep an eye on updates then. Nice work so far - it seems pretty solid, if a bit slow on my PC. :)

Sonic of 8! Joined: 21 Jun 2010 Posts: 200 Location: Earth Planet	Posted: Fri Oct 28, 2011 10:13 pm
	Sorry about a new release with no response. But tomorrow I test this.

Sonic of 8! Joined: 21 Jun 2010 Posts: 200 Location: Earth Planet	Posted: Sat Oct 29, 2011 6:59 pm
	Sonic of 8! wrote Sorry about a new release with no response. But tomorrow I test this. A #000000 (black) screen again (all of three video modes). And sometimes it gives a error.

Bock Site Admin Joined: 08 Jul 2001 Posts: 8731 Location: Paris, France	Posted: Sun Oct 30, 2011 11:03 am
	Sonic of 8! wrote Sonic of 8! wrote Sorry about a new release with no response. But tomorrow I test this. A #000000 (black) screen again (all of three video modes). And sometimes it gives a error. What do you mean "again" ? You said it was slow the last time, not a black screen. What error does it give?

Sonic of 8! Joined: 21 Jun 2010 Posts: 200 Location: Earth Planet	Posted: Sun Oct 30, 2011 3:05 pm
	Sometimes, the window came black or transparent. And the error is one of that was give an instruction error on 0x???????... And may give the options of close or debugging the program. And again, slow.

Bock Site Admin Joined: 08 Jul 2001 Posts: 8731 Location: Paris, France	Posted: Sun Oct 30, 2011 3:12 pm
	Which window, the full MEKA window or the game window in the interface? How can you tell that something is slow if it doesn't show? When does the error show?

Sonic of 8! Joined: 21 Jun 2010 Posts: 200 Location: Earth Planet	Posted: Sun Oct 30, 2011 3:57 pm
	Bock wrote Which window, the full MEKA window or the game window in the interface? How can you tell that something is slow if it doesn't show? When does the error show? MEKA goes slow on interface. For a example, it don't show all the options/windows at time. The error appears with: A memória não pode ser "writen" (the memory cannot be "writen"). I might think that when mekaw was created the cfg and another files like meka.dsk, he tries to open but the mekaw don't was concluded themselves. Later, I can record a video on my Mobile Phone, and I show how MEKA is slow.

Chilly Willy Joined: 23 Jan 2011 Posts: 65 Location: The Land of Enchantment	Posted: Sun Oct 30, 2011 5:18 pm
	Edit the config file and set it to unthrottled. Super-slow meka was (for me, at least) an issue with the throttle speed code.

Sonic of 8! Joined: 21 Jun 2010 Posts: 200 Location: Earth Planet	Posted: Sun Oct 30, 2011 5:50 pm
	Nope. The problem remains.

RodolfoRG Joined: 08 Mar 2005 Posts: 8 Location: Brazil	Posted: Sun Oct 30, 2011 8:25 pm
RodolfoRG Joined: 08 Mar 2005 Posts: 8 Location: Brazil	So, I finally decided to try this here (it means: compile allegro 5 by myself - as said, Debian doenst have it on its repositories). I have the same issue mentioned about the file z80marat/Z80DebugHelpers.c as rule for $(OD)/z80marat.a: it doesn't exist . The real file has the .cpp extension. So I renamed the file, as its actually a .c file anyway. I got a lot of warnings about enumeration values not being handled by switch statements, but I didn't look at them. There were simple mistakes that usually don't harm anyone, like: capture.c:79:21: warning: deprecated conversion from string constant to ‘char’ [-Wwrite-strings] I don't know if v_start field is used when there's no scroll, but here's a warning: g_widget.c: In function ‘void widget_scrollbar_update(t_widget)’: g_widget.c:498:13: warning: ‘v_start’ may be used uninitialized in this function [-Wuninitialized] app_cheatfinder.c: In function ‘u32 _ZL21CheatFinder_ReadValueP14t_cheat_finderPK14t_memory_rangeP20t_cheat_finder_match.isra.1(const t_memory_range, t_cheat_finder_match)’: app_cheatfinder.c:409:9: warning: ‘v’ may be used uninitialized in this function [-Wuninitialized] As I use x86_64 architecture, I always pay attetion for error like that: g_menu_i.c: In function ‘void gui_menus_init()’: g_menu_i.c:157:136: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] app_cheatfinder.c:167:181: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] app_cheatfinder.c:192:153: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] app_cheatfinder.c:207:178: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] app_cheatfinder.c: In function ‘void CheatFinder_Update(t_cheat_finder)’: app_cheatfinder.c:318:43: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] app_cheatfinder.c:346:42: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] Then I got another compilation error: app_cheatfinder.c: In function ‘void CheatFinder_CallbackMemtypeSelect(t_widget)’: app_cheatfinder.c:535:40: error: cast from ‘void’ to ‘int’ loses precision [-fpermissive] app_cheatfinder.c: In function ‘void CheatFinder_CallbackValuetypeSelect(t_widget)’: app_cheatfinder.c:541:54: error: cast from ‘void’ to ‘int’ loses precision [-fpermissive] app_cheatfinder.c: In function ‘void CheatFinder_CallbackComparerSelect(t_widget)’: app_cheatfinder.c:547:51: error: cast from ‘void’ to ‘int’ loses precision [-fpermissive] app_cheatfinder.c: In function ‘void CheatFinder_CallbackCompareToSelect(t_widget)’: app_cheatfinder.c:553:55: error: cast from ‘void’ to ‘int’ loses precision [-fpermissive] app_cheatfinder.c: In function ‘void CheatFinder_CallbackSelectOneMatch(t_widget)’: app_cheatfinder.c:580:34: error: cast from ‘void’ to ‘int’ loses precision [-fpermissive] app_memview.c: In function ‘void MemoryViewer_ViewPaneCallback(t_widget)’: app_memview.c:627:49: error: cast from ‘void’ to ‘int’ loses precision [-fpermissive] We should avoid those pointer<->integer conversions for portability ;) Maybe you should make a struct+union to check when it's a real pointer or just an integer? Here, for a quick (and so ugly) fix, I've change it for (long). In the Makefile, I've removed all the LIB_OS definitions for unix target, leaving it empty: they were useless and cause a link error here. I've also changed the line for Allegro flags: LIB_ALLEG = `pkg-config --cflags --libs allegro-5.0 allegro_image-5.0 allegro_audio-5.0 allegro_font-5.0 allegro_primitives-5.0` I've got the same error said (and solved) by Chilly Willy. obj/debugger.o: In function `Debugger_Hook(Z80)': debugger.c:(.text+0x4634): undefined reference to `Z80DebugHelper_IsRetExecuting(Z80 const*)' collect2: ld returned 1 exit status I did what he said and it works. And when everything compiled... No Meka sound :P It keeps still when Initializing sound system... - Initializing sound card @ 44100 Hz I can't launch Meka... =/

Bock Site Admin Joined: 08 Jul 2001 Posts: 8731 Location: Paris, France	Posted: Sun Oct 30, 2011 9:58 pm
	Thanks for your help. If you can make a patch with some of the change I'll apply them. I guess i should get myself a Linux box sometimes :) . RodolfoRG wrote And when everything compiled... No Meka sound :P It keeps still when Initializing sound system... - Initializing sound card @ 44100 Hz I can't launch Meka... =/ Can you run with GDB and see where it hangs? Thanks a lot!

RodolfoRG Joined: 08 Mar 2005 Posts: 8 Location: Brazil	Posted: Sun Oct 30, 2011 10:04 pm
RodolfoRG Joined: 08 Mar 2005 Posts: 8 Location: Brazil	Bock wrote Thanks for your help. If you can make a patch with some of the change I'll apply them. I'll try to clean all the warnings, then I send you a patch. Bock wrote Can you run with GDB and see where it hangs? Thanks a lot! After I send a SIGINT (CTRL+C): (gdb) bt #0 0x00007ffff64367f1 in ppoll (fds=<optimized>, nfds=<optimized>, timeout=<optimized>, sigmask=<optimized>) at ../sysdeps/unix/sysv/linux/ppoll.c:57 #1 0x00007ffff46f1637 in pa_mainloop_poll () from /usr/lib/x86_64-linux-gnu/libpulse.so.0 #2 0x00007ffff46f1c09 in pa_mainloop_iterate () from /usr/lib/x86_64-linux-gnu/libpulse.so.0 #3 0x00007ffff79cdaa4 in pulseaudio_open () at /home/rodolfo/testes/allegro/5.0/addons/audio/pulseaudio.c:81 #4 0x00007ffff79c5ee2 in do_install_audio (mode=<optimized>) at /home/rodolfo/testes/allegro/5.0/addons/audio/audio.c:268 #5 0x00007ffff79c5f5a in do_install_audio (mode=<optimized>) at /home/rodolfo/testes/allegro/5.0/addons/audio/audio.c:186 #6 0x000000000045ec02 in Sound_Init() () #7 0x000000000040477c in main ()

Bock Site Admin Joined: 08 Jul 2001 Posts: 8731 Location: Paris, France	Posted: Sun Oct 30, 2011 10:51 pm
	Do the Allegro audio samples works for you?

Forums

View topic - Meka 0.80 with new sound engine *TESTERS WANTED!*

View topic - Meka 0.80 with new sound engine TESTERS WANTED!