Home Page
Posted By: Just Desserts N64 Discussion Station - 01/15/12 02:52 AM
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!
Posted By: Firewave Re: N64 Discussion Station - 01/17/12 01:22 PM
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
Posted By: Firewave Re: N64 Discussion Station - 01/17/12 01:23 PM
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 ?? ()
Posted By: Justin Re: N64 Discussion Station - 01/17/12 03:43 PM
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
Posted By: R. Belmont Re: N64 Discussion Station - 01/17/12 03:47 PM
Yeah, there's nothing useful in that, we already tried that. The assert() is a much more interesting/important clue.
Posted By: Happy Re: N64 Discussion Station - 01/17/12 05:27 PM
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.
Posted By: R. Belmont Re: N64 Discussion Station - 01/17/12 05:31 PM
I am also running 64-bit on Linux. It takes a few seconds at 500% unthrottled for me but it does crash every time.
Posted By: Happy Re: N64 Discussion Station - 01/17/12 05:34 PM
OK, it just takes about a minute before it happens for me.
Posted By: Firewave Re: N64 Discussion Station - 01/17/12 05:52 PM
-str 4 is enough on windows to hit the crash (JD isn't seeing it either) and the assertion might be happening even faster.
Posted By: Just Desserts Re: N64 Discussion Station - 01/17/12 07:12 PM
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
Posted By: Firewave Re: N64 Discussion Station - 01/17/12 07:27 PM
oh yeah...right...totally forgot that...sorry...was already too tired last night
Posted By: Just Desserts Re: N64 Discussion Station - 01/17/12 07:33 PM
Originally Posted By R. Belmont
Yeah, there's nothing useful in that, we already tried that. The assert() is a much more interesting/important clue.


Not as interesting as you might think, with the C backend it dies immediately, which just proves (as you may have found with having to fix the SDL build repeatedly) that Aaron does not regularly test anything that requires special flags in the source files themselves when making core changes, even when they're source files he wrote. smile
Posted By: Just Desserts Re: N64 Discussion Station - 02/06/12 04:50 PM
Trying something new. I'm in the process of debugging the threaded N64 renderer, and am streaming my desktop here: http://www.twitch.tv/emumoogle

Also, I'm about to go AFK for about 5 minutes.
Posted By: qmc2 Re: N64 Discussion Station - 02/06/12 04:53 PM
That's cool -- I'm watching smile...
Posted By: Just Desserts Re: N64 Discussion Station - 02/06/12 04:58 PM
So, as a quick synopsis of what's going on: I've converted the N64 renderer over to use the poly.h functionality provided by the core library, which should (in theory) provide a bump in speed by threading off individual polygon scanlines onto additional CPU cores. Currently, however, it's much slower due to various factors that I haven't quite ironed out, but more importantly it seems to be fond of crashing MESS, omitting flipped polygons, rendering garbage, and often scribbling over pre-existing pixels, which is not cool, and indicates thread unsafety. Which is bad, because I've been over it with a fine-toothed comb.

In the meantime, I might have to do a clean build, at which point I'll probably limit it to -j3 and entertain any viewers by playing MAME. :P
Posted By: Just Desserts Re: N64 Discussion Station - 02/06/12 05:57 PM
Man, I need a break. Debugging this thing is such bullshit.
Posted By: Just Desserts Re: N64 Discussion Station - 02/11/12 04:06 PM
Allow me to introduce you to my friend, MESS SVN r14424:

Code:
Game		Before		After		Ratio
Mario 64	52.25%		82.75%		1.58
Tetrisphere	46.24%		86.83%		1.88
Mario Kart 64	55.92%		115.81%		2.07
Pokemon Snap	17.66%		49.20%		2.79
Majora's Mask	46.15%		103.49%		2.24


All games tested with multithreading on, the number of CPUs set to 4, and -str 60 on an i7-960 at 3.2GHz.
Posted By: qmc2 Re: N64 Discussion Station - 02/11/12 04:08 PM
Very nice, JD! Will try out now smile...
Posted By: Gregoire Duval Re: N64 Discussion Station - 02/12/12 12:23 AM
Allow me to congratulate you for the astonishing work you've done smile
I'm even surprised by the fact that my "wideboy" carts now shows something
(I know my test to be pointless because the wideboy needs some special hardware but nonetheless it impress me)

Keep up the good work smile
Posted By: Waremonger Re: N64 Discussion Station - 02/12/12 03:48 AM
Nice! Can't wait to try it out.
Posted By: Xor Re: N64 Discussion Station - 02/12/12 04:57 AM
Yes, great performance increase, I got 75.70% on Super Mario 64 with a -str 30 run, full-speed non-hle n64 emulation in Mess seems like a realistic goal all of a sudden!
Posted By: B2K24 Re: N64 Discussion Station - 02/12/12 07:00 AM
/me jaw hits the floor

Amazing Amazing Amazing

Please keep up this wonderful work smile
Posted By: ASH Re: N64 Discussion Station - 02/12/12 10:39 AM
Now that's impressive...nice work JD *insert thumbs up smilie here*
Posted By: Just Desserts Re: N64 Discussion Station - 02/12/12 06:02 PM
Thanks, guys! I'm currently working on some machine-side cleanup that should kick a few stragglers into gear; for example, Rampage: World Tour's display is currently offset by about 80 pixels, but I have a local fix that takes care of that (and more). smile
Posted By: Just Desserts Re: N64 Discussion Station - 02/12/12 11:54 PM
Since this is my de facto blog since I haven't been able to pay my webhosting bill:

Quote:

Why do you think I throw myself into emulation so much, and emulator coding? You can get pissed off at an emulator, get pissed off at what you're writing because it is not working correctly, but there is an unemotional truth to it, there is an objectiveness about it that you do not get with people. If you're pissed at your code, you at least know that it is because of something you did, and only something that you did. There is a straightforwardness to it. Insert Tab A into Slot B: "Am I contributing code to this project that nobody else seemed to be interested in doing?" "Am I preserving hardware functionality for the future?" If yes, continue. If no, stop.

You know that the emulator and the code don't have an emotional investment in how much or how little time you spend with it, it doesn't have a mind in which it can do its own opaque thing and scheme with notepad.exe to take out your bookmarks; lacking malice by other contributors to the code, the code itself cannot be malicious. It can't lie to you, it can't ignore you, it can just be there for you, no matter how many people screw you over, no matter how many people break your heart, no matter how many friends abandon you, no matter how many jobs you lose, that code will be waiting for you there to work on.

Because if nobody else seems interested in keeping company with you, or a friendship with you, or something that lasts after you're gone, at least the code will.
Posted By: Richard Bannister Re: N64 Discussion Station - 02/13/12 05:00 AM
That's fairly deep...
Posted By: Xor Re: N64 Discussion Station - 02/13/12 07:34 AM
Indeed, I needed two cups of morning coffee to be able to get through the first paragraph even (then again I'm barely functional before two cups of coffee).

I get the whole thing with code as a descriptive and functional legacy of how things work and that's what I find so fascinating with REAL emulation as opposed to just 'getting the games to run'.

Then it got a bit too deep for me, same things said about code and it's lack of emotional responsiveness and it's tendency to always 'be there' could also be said about my right shoe.

Then again how about we register code as a religion and get some nice tax deductions and holidays?

I can see the sermons before me -'In the name of the source code, the editor and the holy compiler' or how about -'If your faith is wavering, turn to the debugger, he will give you answers and set you on the right path', or -'even though I walk through the silicon valley of the shadow of segfaults, I will fear no bugs'...
Posted By: Just Desserts Re: N64 Discussion Station - 02/13/12 03:12 PM
Originally Posted By Xor
it's tendency to always 'be there' could also be said about my right shoe.


Swing and a miss. Will your shoe still be here in 100 years, still bearing the changes you made to it while you were alive? No, probably not. I would certainly not choose a shoe to be my legacy when I can contribute code to something that will hopefully be around in some form or other well after I'm not.
Posted By: Haze Re: N64 Discussion Station - 02/13/12 03:50 PM
Originally Posted By Just Desserts
Originally Posted By Xor
it's tendency to always 'be there' could also be said about my right shoe.


Swing and a miss. Will your shoe still be here in 100 years, still bearing the changes you made to it while you were alive? No, probably not. I would certainly not choose a shoe to be my legacy when I can contribute code to something that will hopefully be around in some form or other well after I'm not.


hopefully.. but maybe some people who wrote games which are now long lost thought the same thing?

with the way platforms are being locked down left right and center who is to say home development will be viable 20 years from now? who is to say you'll actually be able to store ROMs on a HDD, not be forced to work in the cloud where your 'illegal files' could be pulled at will?

of course there will always be demand for developers, so development boxes will always exist, but if they end up out of the price range of regular people then what happens?

don't get me wrong, I do like to think I'm making a contribution to society and helping to preserve our culture with MAME and MESS, a mark which will last through the test of time but sometimes you have to wonder, if you look at society as a whole bigger things have been lost than either MAME or MESS.
Posted By: etabeta78 Re: N64 Discussion Station - 02/13/12 03:54 PM
I want to report that your changes produced a noticeable speedup even on MacOSX, where -mt is unsafe (so I don't turn it on)
hence, your work is really appreciated here smile

just for the record, a couple of notes:
- the crash in mario kart seems due to "N64TexturePipeT::Cycle ()" but the backtrace is not really clear here about the culprit,
- AeroFighters now crashes after you select you airplane with a backtrace which points to DrawTriangle doing something invalid (it was working with the old code)

overall, 100% thumbs up for the new code
Posted By: Just Desserts Re: N64 Discussion Station - 02/13/12 04:17 PM
Originally Posted By Haze
if you look at society as a whole bigger things have been lost than either MAME or MESS.


Define "bigger". Duplication implies redundancy. If you want to make some sort of analogy to the libraries sacked in the Roman and Greek times, feel free, but somehow I don't think that's even remotely possible nowadays given the hundreds of thousands or millions of copies of the MESS and MAME source code spread far and wide across the world.

Originally Posted By etabeta78
just for the record, a couple of notes:
- the crash in mario kart seems due to "N64TexturePipeT::Cycle ()" but the backtrace is not really clear here about the culprit,
- AeroFighters now crashes after you select you airplane with a backtrace which points to DrawTriangle doing something invalid (it was working with the old code)


r14446 fixes both. smile
Posted By: Sune Re: N64 Discussion Station - 02/13/12 04:24 PM
eta: -mt works on OS X now and has for some time.

I don't remember by whom or when it was fixed, some time late last year I think.

Actually it always worked, but it would fill up the logs with some error message. It doesn't anymore.
Posted By: R. Belmont Re: N64 Discussion Station - 02/13/12 04:37 PM
No, -mt wasn't fixed, at least by us. Please do not use it on OS X.

Also, because this is commonly confused, drivers that use multiple threads (like the recent N64 work or the Voodoo emulation) are a completely different thing from -mt. You do not need -mt to get the driver-threading benefits.
Posted By: Xor Re: N64 Discussion Station - 02/13/12 04:41 PM
Originally Posted By Just Desserts

Swing and a miss. Will your shoe still be here in 100 years, still bearing the changes you made to it while you were alive? No, probably not. I would certainly not choose a shoe to be my legacy when I can contribute code to something that will hopefully be around in some form or other well after I'm not.

Heh, ok point taken. Still I wasn't referring to the 'legacy' part but rather the 'code is good to me because it doesn't judge or bitch' sentimentality.
Posted By: Haze Re: N64 Discussion Station - 02/13/12 04:45 PM
Originally Posted By Just Desserts
Originally Posted By Haze
if you look at society as a whole bigger things have been lost than either MAME or MESS.


Define "bigger". Duplication implies redundancy. If you want to make some sort of analogy to the libraries sacked in the Roman and Greek times, feel free, but somehow I don't think that's even remotely possible nowadays given the hundreds of thousands or millions of copies of the MESS and MAME source code spread far and wide across the world.


Given that libraries were razed to the ground during the Iraq invasion it's not just Roman and Greek times.

There are millions of copies (probably less of newer versions) which helps, yes, but they rely on a few basic fundamentals.

a) users having control over what runs on their own systems
b) users having control over what can be stored on their own systems
b) users being able to distribute such things easily
c) people actually caring enough to keep things in circulation

you're talking hundreds, not thousand or millions of people downloading the latest 'MAMERoms' torrents which is probably a fair indication of the number of people actively following MAME. For MESS that value is significantly lower.

Nowadays it's a struggle to find disk images of software which was widely pirated back in the day, especially applications. The interest in said software declined to the point where nobody was keeping it, and just because projects like MAME and MESS have revitalized interest in such things doesn't mean that interest is going to last forever. If you combine that with attempts to lock down platforms, censor the internet and the rest, then I don't see it as impossible.

Finding the old source archives for older versions even when MAME was at the peak of popularity was hard. I believe we have a complete untainted set these days however.

As long as the projects remain active it's less of a problem, however have you ever tried looking for the files for some older emulators? all roads end up leading to the same place, that place is often dead (old Geocities account, Domain squatter, or now MegaUpload link..) I've encountered this recently when looking for a couple of things to try playing with in the MESS 486 driver.

At their peak games like Quake 2 had HUGE communities of mods surrounding them. I played a lot of them. These days the files for many of the mods which didn't gain popularity are nowhere to be found, and huge numbers of unofficial maps are missing yet these were things that somebody would have painstakingly constructed over a few weeks, then spend days (in complex cases) compiling due to processor speeds of the period. I doubt the people making thought one day they'd be lost after they'd been spread around the community sites, and were running on a variety of servers. The reality is however a lot are now all but gone now with only the most popular ones remaining. When big hosts (like MegaUpload, Geocities etc.) pull their content the main victim is *old* content from no longer maintained sites. The people pirating modern stuff just reupload it somewhere else while older, forgotten stuff just vanishes for good.

Public domain libraries are no exception either, thankfully in the case of the Amiga a lot of the software ended up on CD-ROMs too, but everything?

All I'm saying is that anything can be lost be it physical items, or digital software. I don't see MAME as an exception to this. (incidentally this is also one reason why I'd prefer a combined project, MAME is only likely to become less active and have less people interested in it due to the natural decline of arcades whereas MESS has a more solid future)

How many places are actually mirroring the MAME source these days? How many are just pointing at MAMEdev.org, or only offering binaries? How many of those places are rock solid reliable sites you KNOW will still be around 20 years from now, with all their old files from now still intact? Most (if not all) of the ones from 15 years ago when MAME first started are long gone.
Posted By: etabeta78 Re: N64 Discussion Station - 02/13/12 04:55 PM
Originally Posted By Just Desserts
r14446 fixes both. smile


Originally Posted By R. Belmont
Also, because this is commonly confused, drivers that use multiple threads (like the recent N64 work or the Voodoo emulation) are a completely different thing from -mt. You do not need -mt to get the driver-threading benefits.


thanks to both.

@Arbee: I got confused by this because the first time I used N64 rewritten driver my system hardlocked and forced me to turn off: I blamed the mt (not being set at all in the ini), but it might have been a series of others factors, given I had ~10 different programs running together at that time and that it never happened anymore...
Posted By: Sune Re: N64 Discussion Station - 02/14/12 12:30 AM
Originally Posted By R. Belmont
No, -mt wasn't fixed, at least by us. Please do not use it on OS X.


Okay, I thought this meant that multithreading was fixed on OS X. I've had it enabled since then and haven't had any issues.

http://mamedev.org/devwiki/index.php/MAME_0.143u2#Specific_Contributions

"Fix autorelease pool warnings when running multithreaded on Mac OS X [Tim Lindner]"
Posted By: Justin Re: N64 Discussion Station - 02/14/12 04:12 AM
Re: Haze, the problem of long-term preservation is definitely one that's starting to crop up, the whole "upload to FTP and let the world be your backup" idea is really showing its limitations now that the Internet has been public for 20-ish years.

Lately I've been helping the Archive Team guys get various file collections backed up onto archive.org for the long term (example example 2). If you're interested in this stuff I would suggest getting in touch with Jason Scott (jason@textfiles.com) who works at archive.org now, they are in this for the long haul, they have loads of storage and they are able to do things like maintain "dark" collections for copyright-sensitive items.
Posted By: Waremonger Re: N64 Discussion Station - 02/14/12 06:45 AM
Amazing work on this driver JD. Not sure if this is the proper thread to post issues in, but All-Star Baseball 2001 (U) crashes during the intro with this message:

Code:
CIC-NUS-6102 detected
  000000000022D518: 0000000000C4C829 (not found)
  000000000022D520: 000007FEFF552D90 (_iob_func)
  000000000022D528: 000000000022D520 (not found)
  000000000022D530: 000000000022D528 (not found)
  000000000022D538: 000000000022C880 (not found)
  000000000022D540: 000000000022D690 (not found)
PC=00001FAE: Unimplemented op 02E0200C (00,0C)


I ran it just to see what would happen with a game that used hi-res mode. It seems to be crashing right as the game is transitioning from the intro into the main game menu. If the driver is not at a stage where bug reports are needed please let me know.
Posted By: dave4mame Re: N64 Discussion Station - 02/14/12 12:01 PM
Originally Posted By Just Desserts
Originally Posted By Haze
if you look at society as a whole bigger things have been lost than either MAME or MESS.


Define "bigger". Duplication implies redundancy. If you want to make some sort of analogy to the libraries sacked in the Roman and Greek times, feel free, but somehow I don't think that's even remotely possible nowadays given the hundreds of thousands or millions of copies of the MESS and MAME source code spread far and wide across the world.




uhm....
lotus 1.0 (or even 2.01) was quite well spread.
try locating a copy :P
Posted By: etabeta78 Re: N64 Discussion Station - 02/14/12 12:12 PM
Originally Posted By Just Desserts
r14446 fixes both. smile


I know you will hate me, but I still get the

Code:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00000001d663ac08
0x0000000100ab3408 in N64TexturePipeT::Cycle ()


crash in mario kart with the latest code...

anyway I can easily live with it, for the time being
Posted By: R. Belmont Re: N64 Discussion Station - 02/14/12 01:02 PM
eta: any time anything is touched anywhere near the n64, you must do a make clean or else all games will crash.
Posted By: Just Desserts Re: N64 Discussion Station - 02/14/12 02:05 PM
Originally Posted By R. Belmont
eta: any time anything is touched anywhere near the n64, you must do a make clean or else all games will crash.


In this case, no you don't, because the relative size of the n64_rdp and n64_periphs classes did not change. Strange, but true.

Originally Posted By etabeta78
crash in mario kart with the latest code...


Gibb0r more information. The crash I fixed was a crash during the opening demo of the game. Where is yours?
Posted By: etabeta78 Re: N64 Discussion Station - 02/14/12 02:55 PM
Originally Posted By R. Belmont
eta: any time anything is touched anywhere near the n64, you must do a make clean or else all games will crash.


done that, even if apparently not needed wink

Originally Posted By Just Desserts
Gibb0r more information. The crash I fixed was a crash during the opening demo of the game. Where is yours?


mine is before even reaching the intro. just type OK and after a bunch of (black) frames, kaboom!

I'm going to compile a SYMBOLS build tonight, but I hoped it was not a local issue, that's why I only reported that the old "N64TexturePipeT::Cycle ()" crash was still there...


EDIT: here the error from a symbol build

Code:
Program received signal EXC_BAD_ACCESS, Could not access memory.

Reason: KERN_INVALID_ADDRESS at address: 0x00000001d77dac08
0x0000000100ca4f4c in N64TexturePipeT::MaskCoupled 
(this=0x122d101d8, S=0x7fff5fbe849c, S1=0x7fff5fbe8494, T=0x7fff5fbe8498, T1=0x7fff5fbe8490, num=0, object=@0x129088000) at 
src/mame/video/rdptpipe.c:57
57                      INT32 maskbits_s = m_maskbits_table[tile[num].mask_s];


and the full backtrace

Code:
(gdb) bt full 3
#0  0x0000000100ca4f4c in N64TexturePipeT::MaskCoupled 
(this=0x122d101d8, S=0x7fff5fbe849c, S1=0x7fff5fbe8494, T=0x7fff5fbe8498, T1=0x7fff5fbe8490, num=0, object=@0x129088000) 
at src/mame/video/rdptpipe.c:57
        maskbits_s = 1
        tile = (const N64Tile *) 0x1290880e0
#1  0x0000000100ca77da in N64TexturePipeT::Cycle 
(this=0x122d101d8, TEX=0x1350fa818, prev=0x1350fa818, SSS=32767, SST=32767, tilenum=0, cycle=0, userdata=0x1350fa000, object=@0x129088000) 
at src/mame/video/rdptpipe.c:287
        sst1 = 0
        sss2 = 1318
        maxt = 0
        upper = false
        sst2 = 1
        invsf = 0
        center = 0
        sfrac = 8
        sss1 = 1317
        invtf = 0
        maxs = 0
        tfrac = 0
        tile = (const N64Tile *) 0x1290880e0
        bilerp = 1
        convert = 0
        t0 = {
  {
    c = 0, 
    i = {
      a = 0 '\0', 
      b = 0 '\0', 
      g = 0 '\0', 
      r = 0 '\0'
    }
  }
}
        t1 = {
  {
    c = 0, 
    i = {
      a = 0 '\0', 
      b = 0 '\0', 
      g = 0 '\0', 
      r = 0 '\0'
    }
  }
}
        t2 = {
  {
    c = 0, 
    i = {
      a = 0 '\0', 
      b = 0 '\0', 
      g = 0 '\0', 
      r = 0 '\0'
    }
  }
}
        t3 = {
  {
    c = 0, 
    i = {
      a = 0 '\0', 
      b = 0 '\0', 
      g = 0 '\0', 
      r = 0 '\0'
    }
  }
}
#2  0x0000000100cab5d4 in n64_rdp::SpanDraw1Cycle 
(this=0x122d10000, scanline=0, extent=@0x1324fa018, object=@0x129088000, threadid=0) 
at src/mame/video/rdpspn16.c:224
        curpixel = 539164783
        zbcur = 0
        zhbcur = 0
        sr = 0
        sss = 32767
        sg = 0
        sa = 0
        ss = 0
        sst = 32767
        sb = 0
        st = 0
        sw = 0
        sz = 0
        valid_x = true
        j = 0
        clipx1 = 0
        clipx2 = 320
        m_rdp = (n64_rdp *) 0x122d10000
        tilenum = 0
        flip = true
        r = {
  {
    w = 0, 
    h = {
      l = 0, 
      h = 0
    }
  }
}
        g = {
  {
    w = 0, 
    h = {
      l = 0, 
      h = 0
    }
  }
}
        b = {
  {
    w = 0, 
    h = {
      l = 0, 
      h = 0
    }
  }
}
        a = {
  {
    w = 0, 
    h = {
      l = 0, 
      h = 0
    }
  }
}
        z = {
  {
    w = 0, 
    h = {
      l = 0, 
      h = 0
    }
  }
}
        s = {
  {
    w = 0, 
    h = {
      l = 0, 
      h = 0
    }
  }
}
        t = {
  {
    w = 0, 
    h = {
      l = 0, 
      h = 0
    }
  }
}
        w = {
  {
    w = 0, 
    h = {
      l = 0, 
      h = 0
    }
  }
}
        zb = 1342184963
        zhb = 1342184963
        offx = 0 '\0'
        offy = 0 '\0'
        tile1 = 0
        userdata = (rdp_span_aux *) 0x1350fa000
        partialreject = false
        bsel0 = false
        drinc = 0
        dginc = 0
        dbinc = 0
        dainc = 0
        dzinc = 0
        dsinc = 0
        dtinc = 0
        dwinc = 0
        dzpix = 1
        xinc = 1
        fb_index = 0
        cdith = 0
        adith = 0
        xstart = 319
        xend = 0
        xend_scissored = 0
        x = 0
        length = 319
        fir = 0
        fig = 0
        fib = 1342177484
(More stack frames follow...)
Current language:  auto; currently c++
Posted By: etabeta78 Re: N64 Discussion Station - 02/14/12 08:20 PM
I think that, more than anything else, he hates accurate n64 emulation because he's the author of a lot of 'improved' texture packs for n64 games
that's the main point, I think

and apparently he had years ago a bad discussion with someone on a MAME-related board where he got ridiculed about accuracy. this by far predates his work on vba-m.
I was in touch with him at vba-m time, and I spent some time writing comments on his blog about accuracy, trying to make clear the flaws on his critics.
but he already hated MAME/MESS even if no gba driver existed officially at time

EDIT: and concerning hate for byuu, he got banned several times from BSNES boards because he can't interact in a civil way with someone else
Posted By: Just Desserts Re: N64 Discussion Station - 02/14/12 09:19 PM
Originally Posted By Stiletto
Now, enough with this off-topic fluff, more cool stuff from J_D plz *munches popcorn*


Okay, here's one: I have games much more reliably detecting the fact that an EEPROM device is hooked up on the PIF, and I've also got Memory Paks formatting properly so you can save things, but only while MESS is on.

I'm in the process of making MESS just write out a .srm and .epr file for all of the games that you run, even ones that have neither. This is where you softlist guys come in - I need someone to conjure me up a softlist that has flags for:
- Whether the game has SRAM on the cart or not
- Whether the game has no EEPROM, 4kbits EEPROM, or 16kbits EEPROM
- Whether the game has an RTC chip on the cart or not
- Whether the game is CIC-6101, CIC-6102, CIC-6103, CIC-6105, or CIC-6106 on the cart
- Whether the game supports the Transfer Pak or not
- Whether the game supports the Rumble Pak or not
- Whether the game supports the Microphone or not

Thanks, and if you could have it done by this evening, that'd be greeeeeeeat. Yeeeeeeah.
Posted By: Gregoire Duval Re: N64 Discussion Station - 02/14/12 10:43 PM
Sorry to interrupt some great work here, just to say that I, too, experience problems with "mario kart 64 (usa)" aka mariokrtu

Quote:
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000001cd9c0c08

VM Regions Near 0x1cd9c0c08:
CG backing stores 00000001c8fbf000-00000001c8fed000 [ 184K] rw-/rw- SM=SHM
-->
MALLOC_TINY 00007ff5fac00000-00007ff5fad00000 [ 1024K] rw-/rwx SM=COW

Application Specific Information:
objc[36520]: garbage collection is OFF

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 mess64 0x000000010850a511 N64TexturePipeT::MaskCoupled(int*, int*, int*, int*, int, rdp_poly_state const&) + 133
1 mess64 0x000000010850d614 N64TexturePipeT::Cycle(Color*, Color*, int, int, unsigned int, unsigned int, rdp_span_aux*, rdp_poly_state const&) + 878
2 mess64 0x0000000108512613 n64_rdp::SpanDraw1Cycle(int, poly_manager<unsigned int, rdp_poly_state, 8, 32000>::extent_t const&, rdp_poly_state const&, int) + 2447
3 mess64 0x0000000108507699 delegate_base<void, int, poly_manager<unsigned int, rdp_poly_state, 8, 32000>::extent_t const&, rdp_poly_state const&, int, _noparam>::operator()(int, poly_manager<unsigned int, rdp_poly_state, 8, 32000>::extent_t const&, rdp_poly_state const&, int) const + 81
4 mess64 0x0000000108507875 poly_manager<unsigned int, rdp_poly_state, 8,


I'ts a clean build, with symbols, 64bit, on mac (lion).
I know my build is evil since it's build with OPTIMIZE=3, but I've tested a non-optimized build beside this one with no more luck.

If needed, just give me pointers on what you want me to test/report.
Posted By: Just Desserts Re: N64 Discussion Station - 02/15/12 03:15 AM
More N64 goodness: More N64 games should detect SRAM, EEPROM and Flash RAM correctly. I can't point directly to any games that didn't boot before that now boot, but at the least I can say that you can save your settings and game progress to a mempak in Rampage: World Tour and successfully reload it.
Posted By: Robbbert Re: N64 Discussion Station - 02/15/12 10:07 AM
I hope you don't mind if I get back on topic...

Tried this on 32-bit, with my meagre collection..

* mario64 - Splash screen, it says "Mario!", then black screen

* castlevania - intro works fine but just before going ingame it crashed mess

* Battle for Naboo - first few seconds are good, followed by white screen, then a few corrupted hexagons, followed by black screen. But the music keeps playing.

* 40 winks - "This game is not designed for use on this system"

* Frogger 2 - works but no sound

* Power Rangers - "This game pack is not compatible with this system"

* WWF No Mercy - this started ok - it's the first time it has ever worked - but just before going ingame, it crashed mess.

** However there is a new problem - whenever a new cart is loaded through the menu, mess exits with the message 'Out of memory!'. When restarted, then it starts to do something.

Overall, it does seem somewhat faster, and i found a demo which not only runs, but easily reaches 100% speed. smile
Posted By: Just Desserts Re: N64 Discussion Station - 02/15/12 01:03 PM
Originally Posted By Robbbert
Tried this on 32-bit, with my meagre collection..

* mario64 - Splash screen, it says "Mario!", then black screen

* castlevania - intro works fine but just before going ingame it crashed mess

* Battle for Naboo - first few seconds are good, followed by white screen, then a few corrupted hexagons, followed by black screen. But the music keeps playing.

* 40 winks - "This game is not designed for use on this system"

* Frogger 2 - works but no sound

* Power Rangers - "This game pack is not compatible with this system"

* WWF No Mercy - this started ok - it's the first time it has ever worked - but just before going ingame, it crashed mess.

** However there is a new problem - whenever a new cart is loaded through the menu, mess exits with the message 'Out of memory!'. When restarted, then it starts to do something.

Overall, it does seem somewhat faster, and i found a demo which not only runs, but easily reaches 100% speed. smile


What I find interesting most of all is that some of the games you listed appear to run and then crash in exactly the way that they do on 64-bit (i.e., Castlevania), and some of them don't.

Unsure of what to say regarding Out Of Memory, I'm wondering if maybe auto_alloc'd memory only gets automatically freed when MESS exits, so it's trying to allocate another batch of span data without unloading the old. I guess don't load carts from the internal menu (for now)? smile
Posted By: Dr. Spankenstein Re: N64 Discussion Station - 02/15/12 01:53 PM
Apologies if this bug is already known. Couldn't find it in the thread.

Mario Tennis (U)

Crashes before launching a single player exhibition match.

Keep pressing 'A' button to get to this point.

64-bit [r14467] Windows 7
Posted By: R. Belmont Re: N64 Discussion Station - 02/15/12 02:05 PM
auto_alloc is freed when the machine object is torn down. Nothing would work multisession if that wasn't the case smile
Posted By: Just Desserts Re: N64 Discussion Station - 02/15/12 03:38 PM
Originally Posted By R. Belmont
auto_alloc is freed when the machine object is torn down. Nothing would work multisession if that wasn't the case smile


Care to speculate on the Out Of Memory, then? That would seem to imply that some allocation is sticking around after the teardown, which implies a memory leak, but none are flagged.
Posted By: R. Belmont Re: N64 Discussion Station - 02/15/12 03:42 PM
Without knowing *what* is running out of memory I can't say. But he's almost certainly using a MESSUI build so bets are generally off anyway.
Posted By: Just Desserts Re: N64 Discussion Station - 02/15/12 03:47 PM
I just made a minor checkin to flag N64 as GAME_NOT_WORKING but remove GAME_IMPERFECT_SOUND, as I'm pretty sure the Rampage: World Tour audio issue is located DMADAC-side and not N64-side, and I don't know of any other games with incorrect audio.

I really don't want to add GAME_NOT_WORKING, especially since I can point to Bust-A-Move 2 or Rampage: World Tour as games that work fine, but with the number of weirdo crashes I'm getting even in run-of-the-mill games, I don't feel like lying to anyone about the state of the driver.
Posted By: Just Desserts Re: N64 Discussion Station - 02/15/12 04:11 PM
Emulated machine crashes in 64-bit

007 - GoldenEye (USA): Freezes when loading into a level, or sometimes when going to the main menu. MESS crashes shortly after with a DRC error about a label not existing.

Banjo-Kazooie (USA): Renders the first frame and then freezes.

Banjo-Tooie (USA): Doesn't boot.

Clay Fighter 63 1/3: Freezes on the first frame with an error to the effect of "START_NEXT_TASK: RSP not yielded!"

Conker's Bad Fur Day (USA): Doesn't boot.

Gex 3 - Deep Cover Gecko (USA): Doesn't boot.

Mario Kart 64 (USA): Freezes when going into the Options menu, changing the audio type to Headphones, and then backing out.

Shin Nihon Pro Wrestling Toukon Road - Brave Spirits (Japan): Doesn't boot.

Shin Nihon Pro Wrestling Toukon Road 2 - The Next Generation (Japan): Freezes at the last screen of the intro.

Stunt Racer 64 (USA): Doesn't boot.

MESS crashes in 64-bit

Castlevania (USA): Crashes when going in-game.

Castlevania - Legacy of Darkness (USA): Crashes after its (very good-looking at hi-res!) in-game intro.

Donkey Kong 64 (USA): Crashes MESS after a very glitchy intro.

Indiana Jones and the Infernal Machine (USA): Crashes MESS after a very glitchy main menu. Also has a really odd issue on the LucasArts logo where all of the letters render in one place rather than separately.

Jet Force Gemini (USA): Crashes on startup.

The Legend of Zelda - Ocarina of Time (USA): Crashes on startup.

Rocket - Robot On Wheels (USA): Crashes after legal screens.

Sim City 2000 (Japan): Crashes on startup.

Super Smash Bros. (USA): Crashes on startup.

Super Mario 64 (USA): Black poly-storm for a few frames originating behind the castle front door after getting briefed on the camera controls by Lakitu, then crashes.

Tetrisphere (USA): Crashed after finishing the second level.

Not Working for weird reasons

Command & Conquer (USA): Doesn't recognize that any controllers are plugged in.

Working more or less fine, possibly with video bugs

Bust-A-Move 2 (USA)

Doubutsu no Mori (Japan) (note, I haven't tested this extensively because I do not speak Japanese, but I have verified that the RTC support is working as when I tested it yesterday it said it was 8:10PM on 2/14)

Legend of Zelda: Majora's Mask (USA) (not tested extensively beyond -str 60, expect crashing)

Pokemon Snap (USA) (has an odd issue where Pikachu does not run across the bottom of the title screen, but stays in one spot)

Rampage - World Tour (USA)

Star Fox 64 (USA)
Posted By: etabeta78 Re: N64 Discussion Station - 02/15/12 05:29 PM
Originally Posted By Just Desserts
Super Mario 64 (USA): Black poly-storm for a few frames originating behind the castle front door after getting briefed on the camera controls by Lakitu, then crashes.


I know it will make you happy, but with MacOSX gcc and PTR64=1, the behavior is different than what you reported
I can pass with no issues Lakitu's briefing and enter the castle. MESS only crashes if I re-exit the castle after entering

also, no text is displayed in either Peach's letter during the intro or in Lakitu's instructions or in other black-boxed tutorial messages...

notice I'm not blaming you in any way, just underlying the fact that these out-of-bound crashes (or whatever else) are not behaving in the same ways across different OSes
Posted By: Just Desserts Re: N64 Discussion Station - 02/15/12 05:32 PM
Yeah, the letters disappeared during my first round of RDP optimization, well before the multithreading.
Posted By: R. Belmont Re: N64 Discussion Station - 02/15/12 05:35 PM
Yeah, my 64-bit Linux build lets me enter the castle and play the first level no problem. Other errors do occur as listed though.
Posted By: etabeta78 Re: N64 Discussion Station - 02/15/12 11:17 PM
a funny behavior can be experienced in J. League Live (basically FIFA based on the Jpn Soccer League): when you start an exhibition match, the camera gets stuck to the first kick view and never scrolls. funniest part is that the action keeps going on away from the screen and you cannot know what's happening smile
Posted By: LordFlux Re: N64 Discussion Station - 02/16/12 12:27 AM
Mortal Kombat Trilogy (USA) works perfectly. Beat the game a couple of times in a row and didn't notice any graphic or audio glitches.
Posted By: Robbbert Re: N64 Discussion Station - 02/16/12 02:06 AM
Originally Posted By R. Belmont
Without knowing *what* is running out of memory I can't say. But he's almost certainly using a MESSUI build so bets are generally off anyway.


I was using the command-line build. When I get home I will search for an 'out of memory' fatalerror, and find what could cause it.
Posted By: Just Desserts Re: N64 Discussion Station - 02/16/12 10:48 AM
Hey RB, when you get up, would you mind using your magic post-deleting powers to nuke the mudlord dogpiling earlier in the thread? Spent the better part of the past 3 hours talking to him on IRC, and... he's actually pretty cool, and reminds me of me to an impressive degree.
Posted By: Robbbert Re: N64 Discussion Station - 02/16/12 10:50 AM
The 'out of memory' comes from machine.c (failure to allocate memory).

The problem can be replicated simply by doing a hard reset, it is not necessary to load another cart.

The failing command is on line 3757 of src/mame/video/n64.c, in the video_start function.

state->m_rdp->AuxBuf[1] = auto_alloc_array_clear(machine, UINT8, EXTENT_AUX_COUNT);
Posted By: Just Desserts Re: N64 Discussion Station - 02/16/12 10:59 AM
What happened to all auto_allocs being freed beteween instances, RB? smile
Posted By: etabeta78 Re: N64 Discussion Station - 02/16/12 02:11 PM
JD: a few of the crashes I experience seems to point to the first call of a function using

Code:
rdp_span_aux *userdata = (rdp_span_aux*)extent.userdata;


as a parameter, e.g. m_rdp->TexPipe.CalculateClampDiffs(tile1, userdata, object); (but the function depends on the game), or more precisely to the first time the called function tries to access userdata items (like userata.ColorInputs or userdata->m_clamp_s_diff)

could there be any uninitialized piece of the "extent_t extent" parameter?

it might be a coincidence, of course, but maybe you could try to check, just to be sure...

a testcase for the above error is 64 Oozumo
Posted By: R. Belmont Re: N64 Discussion Station - 02/16/12 02:16 PM
JD: Note that the failure is on alloc; it doesn't say what hasn't been freed to cause the OOM.
Posted By: Just Desserts Re: N64 Discussion Station - 02/16/12 06:03 PM
Originally Posted By R. Belmont
JD: Note that the failure is on alloc; it doesn't say what hasn't been freed to cause the OOM.


Maybe, but given the size of that allocation (around 100-200 megs, probably), I wouldn't be surprised if borderline systems threw a fit if the aux span buffers haven't been freed when it goes to allocate the new ones. There isn't much else in the N64 driver that requires *that* much memory.
Posted By: Just Desserts Re: N64 Discussion Station - 02/16/12 10:27 PM
r14487 reduces the memory overhead of the RDP system, fixes missing text in Mario 64, takes a crack at a slightly different interrupt scheme that (interestingly) gets Clay Fighter 63 1/3 to boot without needing an insane interleave, and throws in a 64DD skeleton driver to boot. Enjoy!

Posted By: Just Desserts Re: N64 Discussion Station - 02/17/12 02:52 AM
Thanks to kammedo's helpful document on the register structure and command set, we have:

r14489: "Please Insert Disk"



plz to gibbor l33t h04rded MO dumps
Posted By: Just Desserts Re: N64 Discussion Station - 02/17/12 03:04 AM
you must totally give me all the dumps, we needs them

we needs them precious
Posted By: Just Desserts Re: N64 Discussion Station - 02/17/12 05:38 AM
It's purely a conversation piece, but I just checked in warm reset support thanks to Happy's helpful information. I forgot to credit him in the checkin comment, and I'd like to apologize for that.
Posted By: Robbbert Re: N64 Discussion Station - 02/17/12 07:57 AM
Warm reset was always working for me..

anyway just tried a few hard resets, and the first reset worked, the second caused several hundred lines of text to roll past as it crashed. The reason for crashing rolled away, so no idea what happened. I guess there was some sort of loop or stack overflow?
Posted By: R. Belmont Re: N64 Discussion Station - 02/17/12 01:14 PM
N64 warm reset, not the default one-size-fits-all-poorly version the core provides smile
Posted By: etabeta78 Re: N64 Discussion Station - 02/18/12 09:56 AM
Originally Posted By Just Desserts
r14487 reduces the memory overhead of the RDP system


for the record, with latest MESS svn, now also MacOSX build behaves the same as yours in Mario 64: black polygon storm from the castle and then crash with

Code:
Ignoring MAME exception: n64_rdp::DrawTriangle: span aux buffer overflow


you might want to notice that the same error (span aux buffer overflow) now also occurs in AeroFighters after selecting an aircraft

however, the coming back of missing texts and the 64dd progresses are very welcome smile


ETA: actually Mario 64 behavior seems random frown frankly annoying!
on the bright side, I have noticed that Perfect Dark now reaches the spinning Rare logo (and then it hits the span aux buffer overflow as the others)
thumbs up for the progress!
Posted By: Just Desserts Re: N64 Discussion Station - 02/18/12 12:06 PM
Good to know. At least since I'm not double-buffering the aux buffer pool I can increase the aux buffer size again (urgh).

In other news,

Posted By: Just Desserts Re: N64 Discussion Station - 02/18/12 12:31 PM
Originally Posted By etabeta78
ETA: actually Mario 64 behavior seems random frown frankly annoying!


Yes, it appears that sometimes poly_manager::wait() doesn't actually wait, but I'm poking at other things before I go down that particular rabbit hole and rattle Aaron's cage.
Posted By: Just Desserts Re: N64 Discussion Station - 02/19/12 12:45 AM
r14517: Accuracy fixes for the complainiest of the complainy so far that I've (partially) managed to pacify.



Oh yeah, 1.0 and 1.1 of this guy boot again now, too:

Posted By: Dr. Spankenstein Re: N64 Discussion Station - 02/19/12 10:44 AM
r14517 64-bit Windows

Yoshi's Story (U) refuses to boot and constantly displays a black screen.
Posted By: Just Desserts Re: N64 Discussion Station - 02/19/12 10:47 AM
So do a lot of games. smile
Posted By: Dr. Spankenstein Re: N64 Discussion Station - 02/19/12 11:17 AM
Ah I see, I'll take off my Captain Obvious suit then smile

Sorry for the noise.
Posted By: Just Desserts Re: N64 Discussion Station - 02/19/12 11:27 AM
Nah, it's alright, I'm just more interested in crashes or boot failures other than the standard Nintendo / Rare fare. I'm a fan of those games, so I've got them covered as far as bug reports go, but if you have anything off the beaten path that fails in an unusual way, let me know. smile
Posted By: Just Desserts Re: N64 Discussion Station - 02/19/12 11:28 AM
r14518: A triangle that generates no spans shouldn't try to draw itself.








Posted By: qmc2 Re: N64 Discussion Station - 02/19/12 12:30 PM
Nice progress, JD smile!

However, I'm now seeing garbage in "Ridge-Racer 64" and "Super Mario 64" (with SVN r14521):





Looked nicer last time I tried (yesterday).
Posted By: etabeta78 Re: N64 Discussion Station - 02/19/12 02:00 PM
for the record, with the same svn source, neither corruptions happen on MacOSX. could it be some weird OPTIMIZE issue?

OTOH, I get randomly a crash in Super Smash Bros. (again due to issues in N64TexturePipeT::Cycle (), like for Mario Kart, but this time called by SpanDraw2Cycle) either in the character select menu or short before entering a fight

also, for some weird reason, Zelda Ocarina of Time Rev. B does not display anything (neither the Jpn nor the US version), while Rev. A and the older releases work perfectly! In fact emulation of Rev.B works too (you can hear the soundtrack and the sfx when input get recognized) but the screen always remains black...

overall, very nice progress!
Posted By: qmc2 Re: N64 Discussion Station - 02/19/12 02:27 PM
Originally Posted By etabeta78
for the record, with the same svn source, neither corruptions happen on MacOSX. could it be some weird OPTIMIZE issue?

I'm not sure... but now it's gone at least (SVN r14528), no more polygon corruption.
Posted By: Just Desserts Re: N64 Discussion Station - 02/19/12 07:27 PM
Originally Posted By etabeta78
also, for some weird reason, Zelda Ocarina of Time Rev. B does not display anything (neither the Jpn nor the US version), while Rev. A and the older releases work perfectly! In fact emulation of Rev.B works too (you can hear the soundtrack and the sfx when input get recognized) but the screen always remains black...


Yep, Zelda rev. B (1.2) doesn't boot due to failing an RSP / CPU comms issue that I would prefer to leave un-fixed for the time being for speed reasons. It wants a remarkably high RSP/CPU interleave but that causes the driver speed to be halved, more or less.
Posted By: Just Desserts Re: N64 Discussion Station - 02/20/12 06:44 AM
You can't cut back on funding! You will regret this!

Posted By: byuu Re: N64 Discussion Station - 02/20/12 06:51 AM
Quote:
It wants a remarkably high RSP/CPU interleave but that causes the driver speed to be halved, more or less.


Ah, such an awful position to be in. Definitely been there: choosing between playability on modern hardware, or correctness that nobody in the world can yet enjoy smirk

May I ask a rough estimate of the number of synchronizations between the two processors per second required to play Zelda 64 rev B, if you don't mind?
Posted By: Just Desserts Re: N64 Discussion Station - 02/20/12 07:12 AM
Originally Posted By byuu
May I ask a rough estimate of the number of synchronizations between the two processors per second required to play Zelda 64 rev B, if you don't mind?


I'm not quite sure. An interleave of 900kHz doesn't work, but an interleave of about 9MHz works. Relatively speaking, it means interleaving the processors at about every 10 instructions.

I don't think that this is actually going to be necessary, I do think there are certain things that can be done to avoid always syncing at that rate. The general way it works is:

1) Main CPU grabs the atomic CPU/RSP semaphore.
2) Main CPU initiates cartridge DMA.
3) RSP sits in a tight loop polling the semaphore and decrementing a counter.
4) Main CPU is interrupted upon cartridge DMA completion and releases the semaphore.
5) The RSP exits the loop and reports the value of the counter.
6) If the counter is within a fairly narrow range (0x4c000 to 0x4ffff) relative to the starting value, the game proceeds normally. If not, it gives up on DMAing graphics lists.
Posted By: etabeta78 Re: N64 Discussion Station - 02/20/12 11:47 AM
well, we can play Rev.A until you find a way to fix these sync issues or CPUs gets 10x faster wink
Posted By: Just Desserts Re: N64 Discussion Station - 02/20/12 06:23 PM
r14557: Command & Conquer boots (but crashes when starting a new game), and now games are cool with their controller paks:








Posted By: Just Desserts Re: N64 Discussion Station - 02/20/12 07:09 PM
A quick video from a fan:

Posted By: Anna Wu Re: N64 Discussion Station - 02/20/12 07:18 PM
Nice and impossible (speed) on my current hardware. smile
Posted By: etabeta78 Re: N64 Discussion Station - 02/20/12 07:22 PM
useful tip: avi output is fullspeed even if your PC only runs the game at 1FPS wink
Posted By: Anna Wu Re: N64 Discussion Station - 02/20/12 07:26 PM
Is not funny, I want play* a game with reasonable speed and not watch a movie or slideshow*.
Posted By: Anna Wu Re: N64 Discussion Station - 02/20/12 07:34 PM
eta, now I know what you meant. smile
Sorry to be slow on the uptake.
Posted By: paokara91 Re: N64 Discussion Station - 02/20/12 09:08 PM
mess64 (svn r14557)

Mario Golf
(E) = doesn't boot
(U) = hangs after the stage overview finishes
(J) = passes the (U) hang but segmentation fault when hitting the ball hard enough and starts to go down
Posted By: Just Desserts Re: N64 Discussion Station - 02/20/12 09:17 PM
r14558: Added trivial Y rejection to triangle draw commands to prevent the core from trying to draw triangles that are clipped to be fully outside of the scissor window.





Posted By: Just Desserts Re: N64 Discussion Station - 02/20/12 09:39 PM
By the way, I demoted the N64 driver to GAME_NOT_WORKING for a very good reason: It doesn't work. I demoted it so that people would bug me less about non-working games, but since the demotion people have bothered me more, and that's not cool.

There are two or three individual games that run well, the rest are a box full of MESS crashes, hanging on a black screen, hanging while in-game, or fatalerror()s. I have pretty good coverage of all of these issues among the 10-20 games that I regularly test, and I am handling these games on a case-by-case basis, so everyone should feel free to stop bothering me about their favorite games that don't work unless it's to tell me about a game that got fixed by one of my fixes that I didn't specifically mention.

Seriously, I don't care if game X, Y or Z don't work. Know what my targets are? The non-working or significantly graphically buggy games that are currently in my software directory: Goldeneye, The World Is Not Enough, Banjo-Kazooie, Command & Conquer, Conker's Bad Fur Day, Donkey Kong 64, F-Zero X, Gex 64, Gex 3, Indiana Jones and the Infernal Machine, Jet Force Gemini, Majora's Mask, Madden 64, Perfect Dark, Quake 64, Rocket - Robot On Wheels, the two Toukon Road games, Stunt Racer 64, and Super Smash Brothers. Those games are my world right now, and if your games aren't in that list, get in line but leave me well alone about them other than to tell me when I've fixed them.

Alright?
Posted By: Haze Re: N64 Discussion Station - 02/20/12 09:45 PM
people are bothering you more because you're working on it... same with anything really.

and having testers while you're actively working on code tends to be good, you can't be expected to catch everything which changes for every change you make, so it can be a handy indication as to if you're doing things right.

simple as that ;-)

actually you should probably be impressed, considering 100% performance is still out of reach with current CPU speeds it's impressive people are testing the driver enough to give you reports :-)
Posted By: etabeta78 Re: N64 Discussion Station - 02/20/12 09:48 PM
speaking of which, at some point in the past few days or today the camera behavior in J.League Live 64 got fixed and the game is now playable
Posted By: Just Desserts Re: N64 Discussion Station - 02/20/12 10:00 PM
Originally Posted By etabeta78
speaking of which, at some point in the past few days or today the camera behavior in J.League Live 64 got fixed and the game is now playable


Sounds like some of the RSP changes I made the other day I had an effect. smile
Posted By: etabeta78 Re: N64 Discussion Station - 02/20/12 10:45 PM
JD I have found the reason of the crash in mariokrt on MacOSX. there are out of bound accesses in the following routines that you can fix as follows

Code:
N64TexturePipeT::MaskCoupled (and possibly N64TexturePipeT::Mask too)
-		INT32 maskbits_s = m_maskbits_table[tile[num].mask_s];
-		INT32 maskbits_t = m_maskbits_table[tile[num].mask_t];
+		INT32 maskbits_s = m_maskbits_table[tile[num].mask_s & 0x0f];
+		INT32 maskbits_t = m_maskbits_table[tile[num].mask_t & 0x0f];

N64TexturePipeT::Fetch
-	return ((this)->*(TexelFetch[index]))(s, t, tbase, tpal, userdata);
+	return ((this)->*(TexelFetch[index & 79]))(s, t, tbase, tpal, userdata);


however the resulting code produces glitches around (e.g. invisible cars in Mario Kart and broken menus in many games)

also I have noticed two things in the Mask/MaskCoupled routines: you define them for "INT32 num" but Cycle() pass them a "UINT32 tilenum" and I would expect in fact such a tilenum to be in the 0-7 range, given that the n64_rdp class has
Code:
N64Tile		m_tiles[8];

is there any missing mask?

I hope this report might help you to find the proper solution to have both the crash fixed and the cars visible smile
Posted By: AaronGiles Re: N64 Discussion Station - 02/20/12 10:52 PM
Erm, masking against 79 isn't going to give you correct results. wink
Posted By: Just Desserts Re: N64 Discussion Station - 02/20/12 11:20 PM
Not to mention the fact that the issue is that the data structures themselves are trashed. So even if what you're proposing "fixes" the issue, it "fixes" it by prolonging the duration of time the driver is going to be using fucked-up values and doing wrong shit. Your "fix" is, like, MASH-level bad.

Basically, I appreciate the attempt to help, but unless you're a professional N64 programmer who has written microcode, just let me handle it. Guesswork is what's gotten us into this situation, and I at least recognize when I have no idea what I'm doing, which is why I've been trying to solicit information from people who have actually made N64 demos and written N64 games, not random other devs.
Posted By: etabeta78 Re: N64 Discussion Station - 02/20/12 11:22 PM
well, I got 79 from the N64TexturePipeT class

Code:
TexelFetcher		TexelFetch[16*5];


I haven't dig further, 'cause it's 12AM and I have to wake up early tomorrow wink
Posted By: Darkstar Re: N64 Discussion Station - 02/20/12 11:39 PM
Originally Posted By etabeta78

Code:
N64TexturePipeT::Fetch
-	return ((this)->*(TexelFetch[index]))(s, t, tbase, tpal, userdata);
+	return ((this)->*(TexelFetch[index & 79]))(s, t, tbase, tpal, userdata);



you probably meant:
Code:
+	return ((this)->*(TexelFetch[index % 79]))(s, t, tbase, tpal, userdata);

grin

however, as others pointed out, the problem lies elsewhere, i.e. why does the index get larger than 79 in the first place? And why do the masks contain values larger than 0x0f

-Darkstar
Posted By: Just Desserts Re: N64 Discussion Station - 02/20/12 11:43 PM
Originally Posted By etabeta78
I haven't dig further, 'cause it's 12AM and I have to wake up early tomorrow wink


It's corrupted memory, I guarantee it, so any of amount of finagling it into working is just going to mask the issue, not make it more apparent. Better that it should crash closer to the time the memory gets trashed than even farther into the future.
Posted By: Haze Re: N64 Discussion Station - 02/21/12 02:31 AM
Originally Posted By Just Desserts
Not to mention the fact that the issue is that the data structures themselves are trashed. So even if what you're proposing "fixes" the issue, it "fixes" it by prolonging the duration of time the driver is going to be using fucked-up values and doing wrong shit. Your "fix" is, like, MASH-level bad.


nothing wrong with *safer* code in general, but no, people can't understand the basics of masking probably shouldn't even be allowed access to the MAME / MESS code. I guess it was probably just a & / % mixup tho, but using % is *very* expensive on performance so not a good solution anyway.


Posted By: Just Desserts Re: N64 Discussion Station - 02/21/12 03:50 AM
Originally Posted By Haze
nothing wrong with *safer* code in general


One could validly argue that code that's in the middle of a core render loop that gets called four times for every on-screen pixel probably should be written to be fast and correct, not safe.
Posted By: R. Belmont Re: N64 Discussion Station - 02/21/12 04:27 AM
Like I said, you need an #ifdef that drops a megaton of asserts on the N64 renderer to catch bad values immediately when they originate.
Posted By: etabeta78 Re: N64 Discussion Station - 02/21/12 05:10 AM
Originally Posted By Darkstar
you probably meant:
Code:
+	return ((this)->*(TexelFetch[index % 79]))(s, t, tbase, tpal, userdata);

grin


of course yeah, I meant that, but it was late and I pressed Shift+6 (&) on my Italian EEEPC keyboard instead of Shift+5 (%).
Anyway, it seems that having made a mistake in 1943.c (admittedly very stupid) and having 0 understanding of multithreading (which lead me to post a couple of noobish-level messages on forums) automatically labeled me as plainly stupid, as others' replies seem to suggest... for the record I'm not :P

Originally Posted By Just Desserts
It's corrupted memory, I guarantee it, so any of amount of finagling it into working is just going to mask the issue, not make it more apparent.


Originally Posted By Haze
people can't understand the basics of masking probably shouldn't even be allowed access to the MAME / MESS code.


Originally Posted By Darkstar

however, as others pointed out, the problem lies elsewhere, i.e. why does the index get larger than 79 in the first place? And why do the masks contain values larger than 0x0f


did any of you read my message? wink
I did not think there was space for misunderstandings.

I have written "the crash is due to out of bound accesses" which can be fixed by those changes (with %79), in the sense that the crash does not happen anymore when those bounds are enforced and therefore it proves in my eyes that those specific calls are the culprit. period.
I have added that it is obvious it is not a fix because of the several glitches produced as a byproduct (which I noticed because I was looking for further out of bounds calls). having svn access I would have added the code to the repository if I had thought it was a fix, wouldn't I?

otoh, I have never suggested JD nor any other devs to add such masking in the code, I just pointed out which functions ended up with out of bounds values (which I thought it could be of use) and I cannot even understand why I'm wasting this time to explain...
Posted By: Just Desserts Re: N64 Discussion Station - 02/21/12 05:13 AM
Originally Posted By etabeta78
specific calls are the culprit


But they aren't. The calls don't do anything other than access data that's already screwed up because the memory is already trashed when going into it. That's like saying the guy who gives CPR to a corpse is responsible for killing the guy.
Posted By: Matty Re: N64 Discussion Station - 02/21/12 05:24 AM
Originally Posted By etabeta78
I have written "the crash is due to out of bound accesses" which can be fixed by those changes (with %79), in the sense that the crash does not happen anymore when those bounds are enforced and therefore it proves in my eyes that those specific calls are the culprit. period.

I hope this is an issue with language barrier, because if it isn't, you're digging a whole for yourself. Those are not "calls" - they are array accesses. They are not the "culprit" for any definition of the word. The fact that they crash is a symptom. The culprit causing out-of-bound accesses is probably miles away. This is what I jokingly call "forensic debugging" at work. You can easily see that things aren't as they should be, but the trick is working backwards to discover what got them into that state. It isn't easy.

Also, %79 doesn't do what you want, anyway: that produces a number in the range 0..78 so attempting to access the last element in the array would wrap around to the first. You want %80 if anything, but as everyone has already mentioned, it's an expensive non-fix for an issue elsewhere. Treating the symptom doesn't cure the disease.
Posted By: etabeta78 Re: N64 Discussion Station - 02/21/12 05:27 AM
well, you are right I have misused the word culprit and call (probably part of the misunderstanding wink ).
still my original thought was that you could find useful to know that among the hundreds of involved parameters it was the mask_s and mask_t values to be trashed on MacOSX after a couple of frames (respectively one between format/size/en_tlut/tlut_type), e.g. so that you add the fatalerrors suggested by Arbee only to the routines that can affect those quantities and not everywhere.

but apparently my idea was naive and it is not so useful as I hoped. fair enough.
Posted By: etabeta78 Re: N64 Discussion Station - 02/21/12 05:36 AM
Originally Posted By Matty
Also, %79 doesn't do what you want, anyway


I give up. it's not my day and I have a brand new super stupid post to add to my pedigree. I have to check what I had written in the code I was testing last night (to see how stupid I have been), but already not spotting that I was posting %79 instead of %80 in two occasions (last night and this morning), is more than enough to justify any attack directed to me since last night: I deserved them all :P

EDIT: ok, my self esteem is partially safe: the code I tested did not contain %79, but %80, so I don't need to hide my head in a brown paper bag.

Anyway, this does not change at all the fact I had not realized in two separate occurrences I was posting the wrong mask on a public forum, so please keep bashing me a bit more (maybe explaining me how to do operations with two digits, since my fingers are not enough wink ) so that next time I check if my brain is correctly plugged-in before posting such embarrassing things...
Posted By: Vas Crabb Re: N64 Discussion Station - 02/21/12 11:11 AM
Hey, taking the bit about not having enough fingers to do two digits seriously for a moment Koreans have an awesome way of counting from zero to 99 on your fingers: http://en.wikipedia.org/wiki/Chisanbop Definitely worth learning!
Posted By: mudlord Re: N64 Discussion Station - 02/21/12 11:26 AM
Originally Posted By Haze
people are bothering you more because you're working on it... same with anything really.

and having testers while you're actively working on code tends to be good, you can't be expected to catch everything which changes for every change you make, so it can be a handy indication as to if you're doing things right.

simple as that ;-)

actually you should probably be impressed, considering 100% performance is still out of reach with current CPU speeds it's impressive people are testing the driver enough to give you reports :-)


Ain't that the truth wink
Speaking of performance, MG and I made some intriguing discoveries with the current threading in the RDP rendering. Seems with N64 emulation, diminishing returns are done with more than 5 cores.

Like for instance, average of 59% of Mario 64's attract loop on a AMD Phenom II x6 1055T versus around 80% on a non Sandy Bridge Intel i7.

Or it could be AMD just sucks at emulation.
Posted By: Just Desserts Re: N64 Discussion Station - 02/21/12 12:44 PM
Originally Posted By mudlord
Like for instance, average of 59% of Mario 64's attract loop on a AMD Phenom II x6 1055T versus around 80% on a non Sandy Bridge Intel i7.

Or it could be AMD just sucks at emulation.


A little of column A, a little of column B. That sort of performance is known about with regard to MAME's threaded polygon renderer, I just wasn't sure if it would apply in this case given that the threads have more work to do than the Voodoo rasterizer in MAME, which I would have thought would help keep the main CPU thread from getting starved of work to dispatch, but I guess not! smile
Posted By: Just Desserts Re: N64 Discussion Station - 02/22/12 03:39 PM
Just checked in the last N64 update before I move tomorrow, if a MAME guy could please commit it MAME-side I would appreciate it.

Just an assortment of fixes.

More importantly, I found that Goldeneye and Perfect Dark work perfectly (albeit the former without expansion pak support) if you use the MIPS interpreter instead of the DRC, and Conker's boots through the legal screen likewise:



Posted By: etabeta78 Re: N64 Discussion Station - 02/22/12 04:32 PM
thumbs up!
Posted By: mpz Re: N64 Discussion Station - 02/22/12 05:21 PM


Started working a few days ago.
Posted By: Just Desserts Re: N64 Discussion Station - 02/22/12 05:29 PM
Originally Posted By mpz
Started working a few days ago.


Thanks for posting that, sorry I forgot. smile
Posted By: Just Desserts Re: N64 Discussion Station - 02/22/12 11:16 PM
I have not fixed the DRC, this is from the interpreter core, but:



Aaron, any chance of you looking at the DRC while I'm moving?
Posted By: Dr. Spankenstein Re: N64 Discussion Station - 02/22/12 11:26 PM
Super Mario 64 (U) now crashes at the title screen just as Mario's head is getting larger.

SVN [r14580] 64-bit Windows.

Can anyone else confirm/deny?
Posted By: Just Desserts Re: N64 Discussion Station - 02/23/12 12:19 AM
Confirmed, might as well fix on my last night in town. laugh
Posted By: Dr. Spankenstein Re: N64 Discussion Station - 02/23/12 12:22 AM
Awesome! Good luck with the rest of the move smile
Posted By: Just Desserts Re: N64 Discussion Station - 02/23/12 01:03 AM
Fixed.
Posted By: Just Desserts Re: N64 Discussion Station - 02/23/12 01:15 AM
While I move, would someone be so magnanimous as to regress-test my checkins to find which one caused Indiana Jones and the Infernal Machine to stop booting to the title screen?

Edit: Interestingly, Conker's BFD actually runs through the legal screens with the DRC, too - you just need to wait a long time, like 15-20 seconds, or 2-3 seconds at 600% unthrottled.
Posted By: Haze Re: N64 Discussion Station - 02/23/12 01:28 PM
That's suggestive of some kind of interrupt masking / comms type problem to me.


Posted By: Just Desserts Re: N64 Discussion Station - 02/23/12 04:06 PM
Originally Posted By Haze
That's suggestive of some kind of interrupt masking / comms type problem to me.


Me too, even moreso given the fact based on interrupt timing alone, Conker's BFD either runs through the legal screen with polygon storms, runs through the legal screen without polygon storms but without Conker in it and then crashes a few frames after the Cock & Plucker Inn appears, or crashes sometime in the Inn itself.
Posted By: Firewave Re: N64 Discussion Station - 02/23/12 04:26 PM
Just give me a heads up when to do another testrun and which settings to use.
Posted By: Just Desserts Re: N64 Discussion Station - 02/24/12 02:48 AM
Since I'm going to be offline for a few days at least, feel free to do a regression run now.
Posted By: Just Desserts Re: N64 Discussion Station - 02/24/12 02:54 AM
By the way, for all you nuts out there who have an overclocked rig able to run 3D N64 games full-speed, I just checked in a fix for the correct-but-late audio issue that (as far as I know) plagued the majority of games. I also dialed up the PI DMA speed from 10 cycles per word to 3 cycles per word. I'm not sure what exactly this fixes, but sometime between the last time I regressed them and now, the following changes have occurred in my test cases:

- F-Zero X shows the N logo before hanging (black screen before).
- Gex 3 shows the legal screen before hanging (black screen before).
- Quake 64 seemed to run farther in-game before hanging.
- Madden Football 64 seems to run farther in the intro rather than hanging, and it no longer attempts to perform a bunk TLUT upload, thus fixing characters in the "Exhibition" menu.
Posted By: Kale Re: N64 Discussion Station - 02/26/12 08:57 PM
Tower & Shaft (Aleck64) now boots, that is a nice Arcade-only puzzle game:





Posted By: etabeta78 Re: N64 Discussion Station - 02/26/12 09:46 PM
there is a gba version too smile
Posted By: Kale Re: N64 Discussion Station - 02/26/12 09:50 PM




By request.
Posted By: Justin Re: N64 Discussion Station - 02/26/12 09:59 PM
"Kurukuru Fever" and "Don-chan Puzzle Hanabi de Doon!", respectively. I guess Gridle already sorted that out for you though smile
Posted By: Sune Re: N64 Discussion Station - 03/01/12 03:14 AM
Pokémon Puzzle League freezes when entering any game mode, after selecting your Pokémon. MESS still runs and at this point hits about 800% unthrottled.

There's no audio at all after the intro finishes. I didn't try to leave it running long enough to see if the intro plays again with audio.

Before the audio changes audio was playing perfectly during the FMV intro. Now it plays back at what sounds like double speed - pitch did not change though.
Posted By: Just Desserts Re: N64 Discussion Station - 03/01/12 11:56 PM
Yeah, Arbee pointed out that Madden 64 exhibits the same behavior. He can also vouch for the fact that I have a fix in my local tree that somehow rectifies both the audio lag in Mario 64 and doesn't break Madden 64 or Pokémon Puzzle League, but I haven't had the necessary 'net access at home until this evening to do a diff and figure out just what the hell it was that actually fixed it locally. smile
Posted By: Sune Re: N64 Discussion Station - 03/11/12 12:33 AM
The FMV and main menu audio is working again (r14740) but it still doesn't go in-game.

Do I have a bad dump or is this expected behavior right now?
Posted By: Just Desserts Re: N64 Discussion Station - 03/11/12 02:56 AM
The driver is GAME_NOT_WORKING, infer from that what you will.
Posted By: Sune Re: N64 Discussion Station - 03/11/12 05:51 AM
I know. If you need me I'll be inferring in the corner over there.
Posted By: Firewave Re: N64 Discussion Station - 03/11/12 02:11 PM
On a side note I fixed the exit crash of the aleck64 sets in MAME. It was because of trying to write to an non-existing NVRAM device.
Posted By: windwakr Re: N64 Discussion Station - 03/13/12 10:48 PM
Hi, I have a question about the files that MESS requires to emulate N64 games.

From what I understand, pifdata.bin comes from the peripheral interface chip.

But where do normpnt.rom and normslp.rom come from, and what kind of data is contained in them?
Posted By: Just Desserts Re: N64 Discussion Station - 03/14/12 01:09 AM
Originally Posted By windwakr
But where do normpnt.rom and normslp.rom come from, and what kind of data is contained in them?


Small internal ROMs that the RDP uses for normalizing certain values.
© Forums