tasemulators / mame-rr Goto Github PK

1. Load "osman".
2. Record a movie.

Expected behavior: The game loads, ROM/RAM check.
Actual behavior: The game loads but this message appears on screen:
"THIS PCB IS NOT KILLING."
Even after stopping recording and loading the game again, the message persists.
It appears to be linked to the nvram: clearing nvram/osman.mv makes the game boot fine again.

Mame-rr doesn't compile at all on Linux because there is some win32 code in it.
As Mame and Lua runs on Linux, I think that Mame-rr should run on Linux too.

The following patch should allow you to compile Mame-rr for Linux. So far it 
has only been tested on Ubuntu 10.10 but should work on other distributions too.
The patch just does the minimum, it disables the features that were using win32 
code and fixes the others.
I tested it with Street Fighter 2 and it runs, albeit slowly.

-First, cd to your source directory and apply the patch with the following 
command:
patch -p0 < mame-rr-linux-target.diff

-Then, download the lua 5.1 archive and decompress it in the directory of your 
choice.  

-Finally, you just need to provide LUA source directory like this :
LUA_SRC_DIR=/your/path/to/lua make

After the patch, Mame-rr should still compiles on Windows(not tested).
I hope it helps.

Original issue reported on code.google.com by [email protected] on 5 Apr 2011 at 3:41

Attachments:

• mame-rr-linux-target.diff

1. Open any rom.
2. Open a lua console, and run the included input-display.lua script.
3. Replay a movie file.

Expected behavior: The movie should play from beginning with the input-display script running. (behavior in 0.139)
Actual behavior: MAME-RR crashes with "Fatal error: Input ports cannot be read at init time! (src/emu/inptport.c:1527)"

Mame-rr does compile "out-of-the-box"
Please advise what is the problem. Both mame gcc and mame vs2017 gave the same error.

Pull latest source
Set command in mingw (mame tools build version) to config64
execute both mame gcc build and vs2017 build. Both gave same error.

MAME VS2017 BUILD:
make MSVC_BUILD=1 DEBUG=1 SYMBOLS=1 TARGET=mame REGENIE=1 TOOLS=1 SUBTARGET=mame NOWERROR=1 -j5

MAME GCC BUILD:
make DEBUG=1 SYMBOLS=1

Error:
[MINGW64] C:\DevTools\mamebuildenv\msys64\src\mame-rr-0.1-beta\mame-rr>make DEBUG=1 SYMBOLS=1
Compiling src/osd/windows/winwork.c...
src/osd/windows/winwork.c: In function 'void* compare_exchange_ptr(void* volatile*, void*, void*)':
src/osd/windows/winwork.c:204:63: error: cast from 'void*' to 'LONG {aka long int}' loses precision [-fpermissive]
INT32 result = InterlockedCompareExchange((LPLONG)ptr, (LONG)exchange, (LONG)compare);
^~~~~~~~
src/osd/windows/winwork.c:204:79: error: cast from 'void*' to 'LONG {aka long int}' loses precision [-fpermissive]
INT32 result = InterlockedCompareExchange((LPLONG)ptr, (LONG)exchange, (LONG)compare);
^~~~~~~
src/osd/windows/winwork.c:205:17: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
return (void *)result;
^~~~~~
makefile:720: recipe for target 'obj/windows/mamed/osd/windows/winwork.o' failed
make: *** [obj/windows/mamed/osd/windows/winwork.o] Error 1

from path:
C:\DevTools\mamebuildenv\msys64\src\mame-rr-0.1-beta\mame-rr

mingw vars and paths set:
[MINGW64] C:\DevTools\mamebuildenv\msys64\src\mame-rr-0.1-beta\mame-rr>path PATH=;C:\DevTools\mamebuildenv\msys64;C:\DevTools\mamebuildenv\msys64\win32;C:\DevTools\mamebuildenv\msys64\mingw64\bin;C:\DevTools\mamebuildenv\msys64\usr\bin;"C:\DevTools\mamebuildenv\msys64\win32;C:\DevTools\mamebuildenv\msys64\win32;C:\DevTools\mamebuildenv\msys64;C:\DevTools\mamebuildenv\msys64\mingw64\bin;C:\DevTools\mamebuildenv\msys64\mingw64\x86_64-w64-mingw32\bin;";C:\Devtools\Python\Python37\Scripts;C:\Devtools\Python\Python37;C:\DevTools\mamebuildenv\msys64;"C:\DevTools\mamebuildenv\msys64\win32;C:\DevTools\mamebuildenv\msys64\mingw64\bin;C:\DevTools\mamebuildenv\msys64\usr\bin";C:\Microsoft\Microsoft Visual Studio\Shared\Anaconda3_64;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\iCLS;C:\Program Files\Intel\Intel(R) Management Engine Components\iCLS;C:\Program Files\Microsoft MPI\Bin;c:\Program Files (x86)\Nice Systems\NICE Player Codec Pack;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0;C:\windows\System32\OpenSSH;c:\Program Files (x86)\NICE Systems\NICE Player Release 6\;C:\Program Files\dotnet;C:\Program Files\Microsoft SQL Server\130\Tools\Binn;C:\Program Files\Git\cmd;C:\Program Files (x86)\IncrediBuild;C:\Program Files (x86)\Microsoft Emulator Manager\1.0;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files (x86)\Lua\5.1;C:\Program Files (x86)\Lua\5.1\clibs;C:\Users\nb180957\AppData\Local\Microsoft\WindowsApps

I gave it a try to see if i can do a test TAS, but im not really used of doing savestates and pausing the emulation at normal speed

Is there a way to make the emulation slower for a more accurate TAS?

According to certain representatives of MAMEDev, the MAME license requires that 
you release source "on the same terms as the binary", meaning you must offer a 
direct download of the source tree used to compile the binary that you release. 
According to them it can be either a complete source archive or a diff to an 
official mamedev.org release, but merely offering public SVN access is 
insufficient.

Original issue reported on code.google.com by [email protected] on 14 Aug 2010 at 3:56

1. Load "ddonpach".
2. Save a state.
3. Load the state.

Expected behavior: the state gets loaded.
Actual behavior: the state is not loaded, and mame-rr displays "Unable to load due to pending anonymous timers. See error.log for details." (No error.log seems to be generated.)

1. Open "bgaregga".
2. Record or replay a movie file.
3. Save a state, then wait a few frames/seconds.
4. Load the state.
   Expected behavior: The state loads succesfully, and the replay/record continues. This is what happens on 0.139-rr.
   Actual behavior: Most of the time, mame-rr displays the "savestate loaded" message, then silently crashes after. For certain savestates (such as those in close proximity to the current frame) the savestate loads.

I can't compile mame-rr although the condition that
downloading
・mame-rr-0.139.zip
・mingw-mame-20100102.exe
and setup and compile them
as README.md wrote.

Console outputs are as below.

What should I do?

If there're any question, please tell me.

Best.

========================================================

% make
mkdir.exe -p obj/windows/mame64
mkdir.exe -p obj/windows/mame64/build
mkdir.exe -p obj/windows/mame64/emu/audio
mkdir.exe -p obj/windows/mame64/emu/cpu
mkdir.exe -p obj/windows/mame64/emu/cpu/adsp2100
mkdir.exe -p obj/windows/mame64/emu/cpu/alph8201
mkdir.exe -p obj/windows/mame64/emu/cpu/am29000
mkdir.exe -p obj/windows/mame64/emu/cpu/apexc
mkdir.exe -p obj/windows/mame64/emu/cpu/arm
mkdir.exe -p obj/windows/mame64/emu/cpu/arm7
mkdir.exe -p obj/windows/mame64/emu/cpu/asap
mkdir.exe -p obj/windows/mame64/emu/cpu/avr8
mkdir.exe -p obj/windows/mame64/emu/cpu/ccpu
mkdir.exe -p obj/windows/mame64/emu/cpu/cdp1802
mkdir.exe -p obj/windows/mame64/emu/cpu/cop400
mkdir.exe -p obj/windows/mame64/emu/cpu/cp1610
mkdir.exe -p obj/windows/mame64/emu/cpu/cubeqcpu
mkdir.exe -p obj/windows/mame64/emu/cpu/dsp32
mkdir.exe -p obj/windows/mame64/emu/cpu/dsp56k
mkdir.exe -p obj/windows/mame64/emu/cpu/e132xs
mkdir.exe -p obj/windows/mame64/emu/cpu/esrip
mkdir.exe -p obj/windows/mame64/emu/cpu/f8
mkdir.exe -p obj/windows/mame64/emu/cpu/g65816
mkdir.exe -p obj/windows/mame64/emu/cpu/h6280
mkdir.exe -p obj/windows/mame64/emu/cpu/h83002
mkdir.exe -p obj/windows/mame64/emu/cpu/hd6309
mkdir.exe -p obj/windows/mame64/emu/cpu/i386
mkdir.exe -p obj/windows/mame64/emu/cpu/i4004
mkdir.exe -p obj/windows/mame64/emu/cpu/i8008
mkdir.exe -p obj/windows/mame64/emu/cpu/i8085
mkdir.exe -p obj/windows/mame64/emu/cpu/i86
mkdir.exe -p obj/windows/mame64/emu/cpu/i860
mkdir.exe -p obj/windows/mame64/emu/cpu/i960
mkdir.exe -p obj/windows/mame64/emu/cpu/jaguar
mkdir.exe -p obj/windows/mame64/emu/cpu/konami
mkdir.exe -p obj/windows/mame64/emu/cpu/lh5801
mkdir.exe -p obj/windows/mame64/emu/cpu/lr35902
mkdir.exe -p obj/windows/mame64/emu/cpu/m37710
mkdir.exe -p obj/windows/mame64/emu/cpu/m6502
mkdir.exe -p obj/windows/mame64/emu/cpu/m6800
mkdir.exe -p obj/windows/mame64/emu/cpu/m68000
mkdir.exe -p obj/windows/mame64/emu/cpu/m6805
mkdir.exe -p obj/windows/mame64/emu/cpu/m6809
mkdir.exe -p obj/windows/mame64/emu/cpu/mb86233
mkdir.exe -p obj/windows/mame64/emu/cpu/mb88xx
mkdir.exe -p obj/windows/mame64/emu/cpu/mc68hc11
mkdir.exe -p obj/windows/mame64/emu/cpu/mcs48
mkdir.exe -p obj/windows/mame64/emu/cpu/mcs51
mkdir.exe -p obj/windows/mame64/emu/cpu/minx
mkdir.exe -p obj/windows/mame64/emu/cpu/mips
mkdir.exe -p obj/windows/mame64/emu/cpu/mn10200
mkdir.exe -p obj/windows/mame64/emu/cpu/nec
mkdir.exe -p obj/windows/mame64/emu/cpu/pdp1
mkdir.exe -p obj/windows/mame64/emu/cpu/pic16c5x
mkdir.exe -p obj/windows/mame64/emu/cpu/pic16c62x
mkdir.exe -p obj/windows/mame64/emu/cpu/powerpc
mkdir.exe -p obj/windows/mame64/emu/cpu/rsp
mkdir.exe -p obj/windows/mame64/emu/cpu/s2650
mkdir.exe -p obj/windows/mame64/emu/cpu/saturn
mkdir.exe -p obj/windows/mame64/emu/cpu/sc61860
mkdir.exe -p obj/windows/mame64/emu/cpu/scmp
mkdir.exe -p obj/windows/mame64/emu/cpu/se3208
mkdir.exe -p obj/windows/mame64/emu/cpu/sh2
mkdir.exe -p obj/windows/mame64/emu/cpu/sh4
mkdir.exe -p obj/windows/mame64/emu/cpu/sharc
mkdir.exe -p obj/windows/mame64/emu/cpu/sm8500
mkdir.exe -p obj/windows/mame64/emu/cpu/spc700
mkdir.exe -p obj/windows/mame64/emu/cpu/ssem
mkdir.exe -p obj/windows/mame64/emu/cpu/ssp1601
mkdir.exe -p obj/windows/mame64/emu/cpu/superfx
mkdir.exe -p obj/windows/mame64/emu/cpu/t11
mkdir.exe -p obj/windows/mame64/emu/cpu/tlcs90
mkdir.exe -p obj/windows/mame64/emu/cpu/tlcs900
mkdir.exe -p obj/windows/mame64/emu/cpu/tms0980
mkdir.exe -p obj/windows/mame64/emu/cpu/tms32010
mkdir.exe -p obj/windows/mame64/emu/cpu/tms32025
mkdir.exe -p obj/windows/mame64/emu/cpu/tms32031
mkdir.exe -p obj/windows/mame64/emu/cpu/tms32051
mkdir.exe -p obj/windows/mame64/emu/cpu/tms34010
mkdir.exe -p obj/windows/mame64/emu/cpu/tms57002
mkdir.exe -p obj/windows/mame64/emu/cpu/tms7000
mkdir.exe -p obj/windows/mame64/emu/cpu/tms9900
mkdir.exe -p obj/windows/mame64/emu/cpu/upd7810
mkdir.exe -p obj/windows/mame64/emu/cpu/v30mz
mkdir.exe -p obj/windows/mame64/emu/cpu/v60
mkdir.exe -p obj/windows/mame64/emu/cpu/v810
mkdir.exe -p obj/windows/mame64/emu/cpu/z180
mkdir.exe -p obj/windows/mame64/emu/cpu/z8
mkdir.exe -p obj/windows/mame64/emu/cpu/z80
mkdir.exe -p obj/windows/mame64/emu/cpu/z8000
mkdir.exe -p obj/windows/mame64/emu/debug
mkdir.exe -p obj/windows/mame64/emu/debugint
mkdir.exe -p obj/windows/mame64/emu/drivers
mkdir.exe -p obj/windows/mame64/emu/layout
mkdir.exe -p obj/windows/mame64/emu/machine
mkdir.exe -p obj/windows/mame64/emu/sound
mkdir.exe -p obj/windows/mame64/emu/video
mkdir.exe -p obj/windows/mame64/lib/expat
mkdir.exe -p obj/windows/mame64/lib/lua
mkdir.exe -p obj/windows/mame64/lib/softfloat
mkdir.exe -p obj/windows/mame64/lib/util
mkdir.exe -p obj/windows/mame64/lib/zlib
mkdir.exe -p obj/windows/mame64/mame/audio
mkdir.exe -p obj/windows/mame64/mame/drivers
mkdir.exe -p obj/windows/mame64/mame/layout
mkdir.exe -p obj/windows/mame64/mame/machine
mkdir.exe -p obj/windows/mame64/mame/video
mkdir.exe -p obj/windows/mame64/osd/windows
mkdir.exe -p obj/windows/mame64/tools
Compiling src/emu/cpu/m68000/m68kmake.c...
In function 'int fgetline(char*, int, FILE*)',
inlined from 'void read_insert(char*)' at src/emu/cpu/m68000/m68kmake.c:1172:46:
src/emu/cpu/m68000/m68kmake.c:602:23: error: 'void* memcpy(void*, const void*, size_t)' accessing 199 bytes at offsets 0 and 1 overlaps 198 bytes at offset 1 [-Werror=restrict]
602 | memcpy(buff, buff + 1, nchars - 1);
| ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
In function 'int fgetline(char*, int, FILE*)',
inlined from 'void read_insert(char*)' at src/emu/cpu/m68000/m68kmake.c:1188:24:
src/emu/cpu/m68000/m68kmake.c:602:23: error: 'void* memcpy(void*, const void*, size_t)' accessing 199 bytes at offsets 0 and 1 overlaps 198 bytes at offset 1 [-Werror=restrict]
602 | memcpy(buff, buff + 1, nchars - 1);
| ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
In function 'int fgetline(char*, int, FILE*)',
inlined from 'int utf8_main(int, char**)' at src/emu/cpu/m68000/m68kmake.c:1299:14:
src/emu/cpu/m68000/m68kmake.c:602:23: error: 'void* memcpy(void*, const void*, size_t)' accessing 199 bytes at offsets 0 and 1 overlaps 198 bytes at offset 1 [-Werror=restrict]
602 | memcpy(buff, buff + 1, nchars - 1);
| ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
In function 'int fgetline(char*, int, FILE*)',
inlined from 'int utf8_main(int, char**)' at src/emu/cpu/m68000/m68kmake.c:1305:14:
src/emu/cpu/m68000/m68kmake.c:602:23: error: 'void* memcpy(void*, const void*, size_t)' accessing 199 bytes at offsets 0 and 1 overlaps 198 bytes at offset 1 [-Werror=restrict]
602 | memcpy(buff, buff + 1, nchars - 1);
| ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
In function 'int fgetline(char*, int, FILE*)',
inlined from 'void populate_table()' at src/emu/cpu/m68000/m68kmake.c:1080:14,
inlined from 'int utf8_main(int, char**)' at src/emu/cpu/m68000/m68kmake.c:1362:18:
src/emu/cpu/m68000/m68kmake.c:602:23: error: 'void* memcpy(void*, const void*, size_t)' accessing 199 bytes at offsets 0 and 1 overlaps 198 bytes at offset 1 [-Werror=restrict]
602 | memcpy(buff, buff + 1, nchars - 1);
| ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
In function 'int fgetline(char*, int, FILE*)',
inlined from 'void populate_table()' at src/emu/cpu/m68000/m68kmake.c:1086:14,
inlined from 'int utf8_main(int, char**)' at src/emu/cpu/m68000/m68kmake.c:1362:18:
src/emu/cpu/m68000/m68kmake.c:602:23: error: 'void* memcpy(void*, const void*, size_t)' accessing 199 bytes at offsets 0 and 1 overlaps 198 bytes at offset 1 [-Werror=restrict]
602 | memcpy(buff, buff + 1, nchars - 1);
| ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
In function 'int fgetline(char*, int, FILE*)',
inlined from 'void process_opcode_handlers(FILE*)' at src/emu/cpu/m68000/m68kmake.c:1018:15,
inlined from 'int utf8_main(int, char**)' at src/emu/cpu/m68000/m68kmake.c:1380:27:
src/emu/cpu/m68000/m68kmake.c:602:23: error: 'void* memcpy(void*, const void*, size_t)' accessing 199 bytes at offsets 0 and 1 overlaps 198 bytes at offset 1 [-Werror=restrict]
602 | memcpy(buff, buff + 1, nchars - 1);
| ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1plus.exe: all warnings being treated as errors
make: *** [obj/windows/mame64/emu/cpu/m68000/m68kmake.o] Error 1

Hello,

I am interested to know the chances of get the CPS3 driver updated. Jojo's had a major update on MAME (the P2 meter combo is now showed since for years it has been not showed) and I was wondering if you could update at least this driver in order to use MAME-RR for training mode (some guys did a Training mode fo both FBA and MAME-RR).

Thank you.

This is more of a question than an issue. Did anyone port these Lua scripts for the official MAME?
The fact that you can run a script using mame <rom_name> -autoboot_script <lua_script_filename> makes me naively hopeful that it would be possible. Currently running them will raise errors such as [LUA ERROR] in run: .\lua\garou-hitboxes.lua:37: attempt to index a nil value (global 'memory').

Hello,

i am working on a bot that can play cps1/cps2 games.
The backend is in java, exchanging data through a tcp socket.

However, when the neural network predicts "Button 4", "Button 5" or "Button 6", they do not work for both players.

I created a small test to check this, on the following script:

 local Buttons = {
	"P1 Left",
	"P1 Right",
	"P1 Up",
	"P1 Down",
	"P1 Button 1",
	"P1 Button 2",
	"P1 Button 3",
	"P1 Button 4",
	"P1 Button 5",
	"P1 Button 6"
}

emu.registerstart(function()
	local obj = savestate.create(1)
    savestate.load(obj)

end)


while true do
   local jp ={}
   for i=1, #Buttons do
      jp[Buttons[i]] = false
   end
   local r = math.random(1,10)
   jp[Buttons[r]] = true
   joypad.set(jp)
   emu.frameadvance()
end

Up, Down, Left, Right, Button 1, 2 and 3 works fine, but the kick buttons (4,5,6) are simply ignored when set to 'true' and nothing happens.

I tested this for XmenVsStreetFighter and SFAZ

Apply this patch to compile the latest (r163) version on Linux.
I tested it with Lua 5.1 and gcc version 4.6.1 on a 64 bit Linux Mint.
I only tested mame-rr with sf2-hitboxes.lua and it seems to be working ok.
The patch doesn't support Lua keyboard and mouse functions, I'll try to add it 
in the next version.

to compile:
LUA_SRC_DIR=<path to Lua sources> make

Original issue reported on code.google.com by [email protected] on 28 May 2013 at 9:18

Attachments:

• linux-mame-rr-0144.patch

Functions like `gui_getpixel` index into `XBuf`, but `XBuf` is never assigned. 
I don't see how it could work.

To get screenshots to work, I used `machine->video().save_snapshot(...)`. 
Specifics in attached file.

Original issue reported on code.google.com by [email protected] on 21 Aug 2014 at 7:59

Attachments:

• screenshot.txt