Announcement: Cycle-accurate N64 development underway.

[MarathonMan]

Haven't checked back in a while, and as usual progress is made! Great job man, this is nothing short of amazing what you're doing here. Have you emulated the pipeline stalls and slips? I'd be very interested to see your method for doing so, as my implementations left a lot to be desired. Also, side note, is there any documentation of these conditions and how they're handled? I kind of just guessed about what would cause problems, and how they'd be resolved.

If cycle accurate N64 isn't usable at playable frame rates then it will still be a massive boon for the speed running community! I look forward to more progress, you are doing the lord's work

Thanks, man.

Facilities for stalls and slips are in place, but I don't make much use of them ATM. The only faults I really respond to are external interrupts and co-processor unusable (games using the FPU will raise this fault to conditionally acquire a floating-point addition to their context space the first time a CP1 instruction is executed).

The stalls and slips are resolved in the same way any traditionaly RISC-y in-order pipeline is: flush to just before faulting instruction on faults, and freeze the pipeline on slips. To handle faults, I use the ShortCycleTable to conditionally execute parts of the pipeline to ensure that spurious stalls or slips are not raised when flushing, and eventually to call into the fault handler. To handle slips, I just set the 'stalls' variable which prevents the pipeline from doing any work for the next variable number of cycles (I will likely need to change this to be a little more specific in the future... but it works for now).

The VR4300 documentation is really good IMO. They cover most things. Whatever they didn't cover was just principles and whatnot applied from Hennessy and Patterson's.

Heh, still fighting the cycle-accuracy playable barrier, but I have some cards loaded up my sleeves yet. Just want to figure out this bug that's causing some games to come crashing down first...

 

[Nintendo Maniac]

So uh... what ever happened to that 4770k?

 

[MarathonMan]

So uh... what ever happened to that 4770k?

I suppose I never posted benchmarks with that.

A stock 4770 (non-K) typically yields around 25-40 VI/s depending on how much is going on in the particular scene.

 

[Nintendo Maniac]

A stock 4770 (non-K)

Oh, did you not order the K model? Just wondering since, here in the US, it's cheaper to buy the K model from MicroCenter than it is to order the non-K or the K model from elsewhere.

 

[MarathonMan]

Oh, did you not order the K model? Just wondering since, here in the US, it's cheaper to buy the K model from MicroCenter than it is to order the non-K or the K model from elsewhere.

Unfortunately, I don't live near a MicroCenter so I'm not able to take advantages of their sales. The cost of driving to the store is prohibitive for me. Thanks for the tip, though.

In other news, I found a FPU bug. SPLiT's "Nacho" demo now looks much better (but darn does it render slow!).

 

[Nintendo Maniac]

is...is that rendering in "high-res" (640x480) mode? Considering you haven't said anything about a "force high-res mode", I'm assuming the demo in question natively runs in said mode?

 

[MarathonMan]

is...is that rendering in "high-res" (640x480) mode? Considering you haven't said anything about a "force high-res mode", I'm assuming the demo in question natively runs in said mode?

No; that ROM runs in high-res mode as long as 8MB RDRAM is detected.

Fixed a severe VR4300 CP1 bug.

EDIT: This also fixes the health bars and remaining bugs from Star Fox 64.
EDIT 2: The bug in question seems to have prevent a ton of things from working properly prior to it's fix.
EDIT 3: WOW SO MANY ROMS ARE RUNNING NAO.

Bomberman, Kirby 64, several more are now booting to their menus. Probably a lot more stuff, too.

 

[Nintendo Maniac]

No; that ROM runs in high-res mode as long as 8MB RDRAM is detected.

Oh I didn't realize you implemented the expansion pack already. Makes sense since several games and stuff flat-out require it, but it just never crossed my mind for whatever reason.

...and I just had a crazy thought. Considering how accurate CEN64 is looking to be, could that theoretically mean that N64DD support could actually happen? F-Zero X Expansion Kit anyone?

 

[MarathonMan]

...and I just had a crazy thought. Considering how accurate CEN64 is looking to be, could that theoretically mean that N64DD support could actually happen? F-Zero X Expansion Kit anyone?

If somebody provides me with enough data about the 64DD (or is willing to front the cost for one ), it's something that's possible in the distant future. I think MAME does 64DD emulation to an extent, maybe. I've seen references to it in the source, anyways.

Found another SP DMA bug. Darn, I'm on fire tonight. Rampage: World Tour now boots and plays (though it looks like the VI is buggered as the output is "stutter-y".

PS: Sorry, kromy, had to disable your VI_CURRENT_REG patch due to the problems it creates in commercial ROMs. Hopefully I'll find a fix for that soon.

 

[MarathonMan]

Everyone's favorite, yeah?

 

[Nintendo Maniac]

Everyone's favorite, yeah?

Not unless you can force the N64's high-res mode so as to imitate how Master Quest ran on the GameCube.

Though the GameCube also had 4x anisotropic filtering...

(the GameCube also had a deflicker filter as well, but said filter usually looks worse than having no filter on modern non-CRT displays)

 

[Fanatic 64]

That's probably the most accurate screenshot of Ocarina of Time I've ever seen.

...In fact, it's technically more accurate than the output of a real Nintendo 64, since it's the "raw" finished frame, rather than the analog-encoded signal from the N64 (you can emulate the analog encoder chip for "more accuracy", but IMO that's unnecessary and just introduces the otherwise undesirable analog degradation).

 

[MarathonMan]

Video is the best. Notice the VI/s... starting to compete to MESS!

http://www.youtube.com/watch?v=oaWTlqzBFvw&feature=youtu.be

 

[MarathonMan]

That's probably the most accurate screenshot of Ocarina of Time I've ever seen.

...In fact, it's technically more accurate than the output of a real Nintendo 64, since it's the "raw" finished frame, rather than the analog-encoded signal from the N64 (you can emulate the analog encoder chip for "more accuracy", but IMO that's unnecessary and just introduces the otherwise undesirable analog degradation).

If you run it in MESS, you'll get the same output. That's all their renderer's doing. I'm just trying to kick the thing around a make it faster.

TBH, I'm not really a fan of the filters myself, either. I probably won't add them for awhile, and have an option to disable them when I do.

 

[Rodimus Primal]

I never use filters in emulation. Some people love 'em though.

Amazing work MarathonMan. I'm curious how Donkey Kong 64 runs on this. Have you implemented sound yet or is that something down the road?

From what I've been reading on your posts, CEN64 currently only uses one core processor currently(correct me if I'm wrong). Are you working on making it work with dual and quad core machines for better work load?

 

[kromy]

PS: Sorry, kromy, had to disable your VI_CURRENT_REG patch due to the problems it creates in commercial ROMs.

No probs, the needs of many commercial roms running outweigh the needs of a few homebrew roms running!

Great to see Pilot Wings 64 is working & playable now, this should serve as a great benchmark for any future speed improvements.
It's exciting to see so much amazing progress in such a short time, very impressive stuff =D

 

[MarathonMan]

I never use filters in emulation. Some people love 'em though.

Amazing work MarathonMan. I'm curious how Donkey Kong 64 runs on this. Have you implemented sound yet or is that something down the road?

From what I've been reading on your posts, CEN64 currently only uses one core processor currently(correct me if I'm wrong). Are you working on making it work with dual and quad core machines for better work load?

DK64 boots, but there are substantial graphical corruptions.

I tried implementing sound for a short while using OpenAL, but I'm not familiar enough with the interface to get it going without spending more time on it.

I have a unreleased multi-core, "HLE-like" version of CEN64, but the gains aren't that impressive (maybe ~10% or so), and there are race conditions that I haven't bothered fixing.

 

[Butz_]

You probably won rembember me, but no problem, just came here to congratulate you man for you hard work in your emu

 

[GPDP]

TBH, I'm not really a fan of the filters myself, either. I probably won't add them for awhile, and have an option to disable them when I do.

Are you referring to the coverage VI filters? Those are a pain. On the one hand, they are necessary for a truly accurate representation of the N64's visuals. On the other, it makes everything look blurry and crap.

An option to enable or disable them is for the best, I think.

 

[MarathonMan]

You probably won rembember me, but no problem, just came here to congratulate you man for you hard work in your emu

Thanks!

Are you referring to the coverage VI filters? Those are a pain. On the one hand, they are necessary for a truly accurate representation of the N64's visuals. On the other, it makes everything look blurry and crap.

An option to enable or disable them is for the best, I think.

Divot, coverage, scanline... anything that alters the raw image that gets pushed to the VI.