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!
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 ?? ()
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.
-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
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.
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
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.
Allow me to congratulate you for the astonishing work you've done 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)
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!
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).
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.
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'...
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.
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.
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
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)
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)
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.
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.
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.
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...
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 (exampleexample 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.
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:
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.
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
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
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
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++
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
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.
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.
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.
* 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.
* 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.
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)?
auto_alloc is freed when the machine object is torn down. Nothing would work multisession if that wasn't the case
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.
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.
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)
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
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
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.
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...
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.
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!
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.
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?
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
ETA: actually Mario 64 behavior seems random 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!
ETA: actually Mario 64 behavior seems random 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.
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.
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...
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.
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
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?
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.
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
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.
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.
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 :-)
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
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.
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
I haven't dig further, 'cause it's 12AM and I have to wake up early tomorrow
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.
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.
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.
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? 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...
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.
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.
well, you are right I have misused the word culprit and call (probably part of the misunderstanding ). 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.
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 ) so that next time I check if my brain is correctly plugged-in before posting such embarrassing things...
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!
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 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.
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!
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:
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.
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.
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.
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.
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.
frankly annoying!
