Home Page Forums MAME MAME N64 Discussion Station

So, me and a user by the name of Happy are nosing around at the N64 again. He pointed out an RSP DMA bug which I've since fixed this afternoon, but interestingly enough this bug was masking another bug which causes Ocarina of Time 1.2 - and a number of ROMs using the CIC-6105- not to boot.

The reason is a clever little bit of copy protection, which I'm in the process of accommodating in the N64 driver. I'll let Happy explain it:


As an interesting aside - and an unfortunate one, for performance reasons - with the current CPU interleave of 600Hz, the R4300's time slice lasts long enough that the DMA completes and it releases the semaphore before the RSP even gets to it, causing an R5 value of 0x200000, which is way out of range and causes it to stop.

I'm currently tweaking the interleave values, and with any luck something good will soon happen!

testrun links copied from http://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=76126#Post76126

http://mess.redump.net/tools:mame_regtest:results:mess:r14028:gcc:x64:standard:n64
http://mess.redump.net/tools:mame_regtest:results:mess:r14030:gcc:x64:standard:n64:str10

Regarding the conker issue it asserts when compiling with FORCE_DRC_C_BACKEND=1:

c:\Emulation\mess>gdb --batch --eval-command="set target-harset UTF-8" --eval-command="set demangle-style auto" --eval-command=run --eval-command=bt --return-child-result --args "c:\Emulation\mess\messd_nodrc.exe" n64 -cart "conker" -artpath c:\Emulation\mess\artwork -video none -nosound -nothrottle -nodebug -nomouse -window -seconds_to_run 4 -rompath "s:\_roms\mess;s:\_roms\mess_software" -hashpath "c:\Emulation\mess\hash"
[New Thread 9004.0x20c8]
CIC-NUS-6105 detected
warning: assert: src/emu/cpu/drcbeut.c:383: mapvar >= MAPVAR_M0 && mapvar < MAPVAR_END

Program received signal SIGTRAP, Trace/breakpoint trap.
0x7676280d in KERNELBASE!DeleteAce () from C:\Windows\syswow64\KernelBase.dll
#0 0x7676280d in KERNELBASE!DeleteAce () from C:\Windows\syswow64\KernelBase.dll
#1 0x01984670 in osd_break_into_debugger (message=0x9bd2c3c "assert: src/emu/cpu/drcbeut.c:383: mapvar >= MAPVAR_M0 && mapvar < MAPVAR_END") at src/osd/windows/winmisc.c:187
#2 0x01bfd9dd in emu_fatalerror::emu_fatalerror(char const*, ...) ()
#3 0x015576a5 in _ZNK17drc_map_variables9get_valueEPhj (this=0xfdc372c, codebase=0x150e9024 "\264Q\336\017,\220\016\025\001", mapvar=<unknown type>) at src/emu/cpu/drcbeut.c:383
#4 0x0154ec22 in _ZN7drcbe_c7executeERN3uml11code_handleE (this=0xfdc36dc, entry=0xfde46dc) at src/emu/cpu/drcbec.c:641
#5 0x01b00dd5 in drcuml_state::execute(uml::code_handle&) ()
#6 0x01344ba8 in _ZL17cpu_execute_mips3P17legacy_cpu_device (device=0x7f2cfdc) at src/emu/cpu/mips/mips3drc.c:541
#7 0x017a8035 in _ZN17legacy_cpu_device11execute_runEv (this=0x7f2cfdc) at src/emu/devcpu.c:260
#8 0x01d8ff8c in device_execute_interface::run() ()
#9 0x0162dd43 in _ZN16device_scheduler9timesliceEv (this=0x28f270) at src/emu/schedule.c:487
#10 0x0158bdf6 in _ZN15running_machine3runEb (this=0x28edb8, firstrun=True) at src/emu/machine.c:414
#11 0x015587dc in _Z12mame_executeR11emu_optionsR13osd_interface (options=0x28fb90, osd=0x28fe74) at src/emu/mame.c:176
#12 0x01794ba7 in _ZN12cli_frontend7executeEiPPc (this=0x28fe68, argc=19, argv=0x352ff8) at src/emu/clifront.c:246
#13 0x00fc967d in _Z9utf8_mainiPPc (argc=19, argv=0x352ff8) at src/osd/windows/winmain.c:482
#14 0x0198442e in wmain (argc=19, argv=0x351518) at src/osd/windows/main.c:88
#15 0x00401422 in __tmainCRTStartup () at ../mingw-w64-crt/crt/crtexe.c:282
#16 0x7699339a in KERNEL32!BaseCleanupAppcompatCacheSupport () from C:\Windows\syswow64\kernel32.dll
#17 0x7efde000 in ?? ()
#18 0x77ca9ef2 in ntdll!RtlpNtSetValueKey () from C:\Windows\system32\ntdll.dll
#19 0x7efde000 in ?? ()
#20 0x77ca9ec5 in ntdll!RtlpNtSetValueKey () from C:\Windows\system32\ntdll.dll
#21 0x00401550 in __tmainCRTStartup () at ../mingw-w64-crt/crt/crtexe.c:288
#22 0x00000000 in ?? ()

I ran Conker under Valgrind a couple times but the results were not too useful-looking:

http://pastebin.ca/2103723
http://pastebin.com/raw.php?i=sfMTrBDL

Yeah, there's nothing useful in that, we already tried that. The assert() is a much more interesting/important clue.

Not sure why, but Conker doesn't segfault for me. It never displays anything (game stuck in idle loop), but it doesn't segfault. I am running 64 bit on Linux, if that gives anyone any clues.

I am also running 64-bit on Linux. It takes a few seconds at 500% unthrottled for me but it does crash every time.

OK, it just takes about a minute before it happens for me.

-str 4 is enough on windows to hit the crash (JD isn't seeing it either) and the assertion might be happening even faster.

Never said I didn't see it, in fact I corrected myself and said that the crash is build-dependent, and I had managed to make a build that crashes for me. :P