Home Page Forums MAME MAME N64 Discussion Station

Ah I see, I'll take off my Captain Obvious suit then

Sorry for the noise.

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.

r14518: A triangle that generates no spans shouldn't try to draw itself.

Nice progress, JD !

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





Looked nicer last time I tried (yesterday).

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!

I'm not sure... but now it's gone at least (SVN r14528), no more polygon corruption.

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.

You can't cut back on funding! You will regret this!

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?

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.