Previous Thread
Next Thread
Print Thread
Page 1 of 15 1 2 3 14 15
#76132 01/15/12 02:52 AM
Joined: May 2009
Posts: 1,980
Likes: 24
J
Very Senior Member
OP Offline
Very Senior Member
J
Joined: May 2009
Posts: 1,980
Likes: 24
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:

Originally Posted By Happy

The code works like this.

1. CPU sets up transfer of RSP code to IMEM.
2. CPU starts RSP.
3. RSP grabs the SP SEMAPHORE. Meanwhile CPU starts PI transfer.
4. CPU continually polls the PI status until it sees that the PI is no longer busy, i.e. transfer complete. When CPU sees this it releases the SP SEMAPHORE. Meanwhile, the RSP is sitting in a polling loop waiting for the signal from SP SEMAPHORE. Each iteration of the loop decrements a counter.
5. When the RSP starts the validation task (after OS and game have started) the counter value is still there. It starts at a value of 0x200000 and is expected to end up with a value between 0x4C000 and 0x4FFFF.

It you want a look at the code for the RSP counter loop, set up the debugger to pause on the RSP on boot, ('focus 1' and then 'step') The loop is at IMEM 11E8. You can change the value after the loop finishes and see that the game boots properly.


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!

Joined: Sep 2001
Posts: 534
F
Senior Member
Offline
Senior Member
F
Joined: Sep 2001
Posts: 534
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

Joined: Sep 2001
Posts: 534
F
Senior Member
Offline
Senior Member
F
Joined: Sep 2001
Posts: 534
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 ?? ()

Joined: Dec 1999
Posts: 1,177
J
Very Senior Member
Offline
Very Senior Member
J
Joined: Dec 1999
Posts: 1,177
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

Joined: Mar 2001
Posts: 16,841
Likes: 45
R
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,841
Likes: 45
Yeah, there's nothing useful in that, we already tried that. The assert() is a much more interesting/important clue.

Joined: Apr 2010
Posts: 53
H
Member
Offline
Member
H
Joined: Apr 2010
Posts: 53
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.

Joined: Mar 2001
Posts: 16,841
Likes: 45
R
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,841
Likes: 45
I am also running 64-bit on Linux. It takes a few seconds at 500% unthrottled for me but it does crash every time.

Joined: Apr 2010
Posts: 53
H
Member
Offline
Member
H
Joined: Apr 2010
Posts: 53
OK, it just takes about a minute before it happens for me.

Joined: Sep 2001
Posts: 534
F
Senior Member
Offline
Senior Member
F
Joined: Sep 2001
Posts: 534
-str 4 is enough on windows to hit the crash (JD isn't seeing it either) and the assertion might be happening even faster.

Joined: May 2009
Posts: 1,980
Likes: 24
J
Very Senior Member
OP Offline
Very Senior Member
J
Joined: May 2009
Posts: 1,980
Likes: 24
Originally Posted By Firewave
-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

Page 1 of 15 1 2 3 14 15

Link Copied to Clipboard
Who's Online Now
0 members (), 36 guests, and 3 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics8,993
Posts118,153
Members5,005
Most Online890
Jan 17th, 2020
Forum Host
These forums are hosted by www.retrogamesformac.com
Forum hosted by www.retrogamesformac.com