Announcement: Cycle-accurate N64 development underway.

[gokuss4]

This would be particularly useful for USF-based playback in Winamp and Foobar2000. I've personally noticed that the USFs for Mario Kart 64 playback a little bit slower than the music actually does on a console.

It's like night and day with me.. but I'm an audiophile so any minor detail is huge to me .

Speaking of audio for the N64, is this the general layout of how sound is done?

ROM stores sound data --> R4300i fetches --> RCP processes --> DAC --> Output

Is that right?

 

[MarathonMan]

It's like night and day with me.. but I'm an audiophile so any minor detail is huge to me .

Speaking of audio for the N64, is this the general layout of how sound is done?

ROM stores sound data --> R4300i fetches --> RCP processes --> DAC --> Output

Is that right?

The following steps are not prescriptive; there's no one way that audio is handled. However, this is one means by which audio could be generated:

0) Game logic requests audio not present in RDRAM.
1) Cart data is loaded: ROM data -> RDRAM via DMA. Interrupt raised when copy is complete.
2) VR4300 starts DMA-ing audio task and data for waveform: RDRAM -> RSP via DMA (task -> IMEM, data -> DMEM). Interrupt raised when each copy completes.
3) RSP mixes and processes waveforms, DMAs the resulting waveforms in small chunks to RDRAM. The RSP may also DMA more data into DMEM as it processes the waveform due to the limited DMEM size.
4) RCP raises interrupt after audio task is finished
5) VR4300 forward information about waveform's length, location, etc. to AIF. VR4300 RDRAM -> AIF via DMA
6) The AIF is then responsible for communicating with the DAC.

 

[beannaich]

I've been talking to a dev who has expressed interest in working on the audio.

I have the audio code ready, just not sure how to read the samples from memory at all. I still have the 2 files I modified if you'd like me to PM them to you.

EDIT: Also the audio sample clock generator is tied to the 48,681,818.18~ Hz VI clock, not sure how that is being generated (If at all). The audio divider register divides this clock to determine when to output the next sample. For example, Majora's Mask writes 1,521 to that register, 48~ MHz / 1521 = 32KHz sampling rate. So for the time being I just doubled the divider, which I'm sure is wrong, and is certainly not cycle accurate. All the other things like bit-rate, etc are handled, and TODO's are placed where what I should do was either unclear or undocumented. I also didn't add OpenAL, because I figured you'd probably have a way you'd like to do it (You also said you'd do it if I wrote the AI code, so ). I guess I'll look up some vr4300 docs and see how DMAs are done in the meantime.

 

[MarathonMan]

I have the audio code ready, just not sure how to read the samples from memory at all. I still have the 2 files I modified if you'd like me to PM them to you.

EDIT: Also the audio sample clock generator is tied to the 48,681,818.18~ Hz VI clock, not sure how that is being generated (If at all). The audio divider register divides this clock to determine when to output the next sample. For example, Majora's Mask writes 1,521 to that register, 48~ MHz / 1521 = 32KHz sampling rate. So for the time being I just doubled the divider, which I'm sure is wrong, and is certainly not cycle accurate. All the other things like bit-rate, etc are handled, and TODO's are placed where what I should do was either unclear or undocumented. I also didn't add OpenAL, because I figured you'd probably have a way you'd like to do it (You also said you'd do it if I wrote the AI code, so ). I guess I'll look up some vr4300 docs and see how DMAs are done in the meantime.

Great, PM it over and I'll look at it.

Concerning the 48MHz clock -- I'm not sure that you even need this -- you aren't able to feed the sound card data on the granularity of a cycle anyways, right? I'm not audio guy by any means, but... err... anyways, a 48Mhz clock will be extremely challenging to generate as it is in no way a multiple of the 62.5MHz that the rest of the console uses. If you really need each cycle, you'll have to do some clever math to do either 2 or 1 audio sampling cycles depending on the period by which the RCP clock has elapsed.

Yeah, I'll get the OpenAL port done whenever you wrangle the SDL? DX? or whatever you're using.

As for DMAs, use these functions:

void DMAFromDRAM(struct BusController *bus, void *dest, uint32_t rdramAddress, uint32_t length);
void DMAToDRAM(struct BusController *bus, uint32_t rdramAddress, const void *src, size_t length);

You may need to nab the bus pointer somehow -- see how I do it in the other plugins.

 

[Nintendo Maniac]

So I must ask, will the supported sampling rate output of different sound cards make a difference? In other words, most modern sound cards (integrated and/or discrete) can handle 24bit 96KHz, while the older stuff usually topped out at 16bit 48KHz. I'm just thinking that 32KHz would match up to 96KHz better than it would to 48KHz...

It's like night and day with me.. but I'm an audiophile so any minor detail is huge to me .

Normally I would consider myself an audiophile as well, but considering the flack I got for saying I knew even the tiniest bit about software, I figured it'd be better to not say that I know something about anything at all.

 

[Fanatic 64]

Good luck trying to run something with OpenAL on FreeBSD...

 

[MarathonMan]

Good luck trying to run something with OpenAL on FreeBSD...

http://www.freshports.org/audio/openal-soft

 

[Fanatic 64]

Good luck trying to cycle-accurate emulate the N64 and reproduce sound all on the CPU at full speed.

(Not trying to be an ass or anything...)

 

[Reznor007]

The 48.681812MHz clock is what is provided to the RCP chip. On early N64 units, there is a pair of MX8330MC RAMBUS clock generator IC on the system, one with a 14.31818MHz crystal. This chip outputs 243.40906MHZ(clock*17) and also has a FSO/5 output connected to the RCP clock input giving it 48.681812MHz(this also goes to the video DAC). The 2nd one has a 14.705882MHz crystal generating 250MHz for the RDRAM. Later N64 units use a single MX8350MC which was a 2 in 1 RAMBUS clock generator.

Where the 62.5MHz system clock comes from, IDK. But I did measure that exactly as 62.5MHz on a real running system using a frequency counter.

On PAL N64 units, the 14.31818MHz crystal would probably be replaced with a 17.734475MHz crystal, and a config pin on the chip set low, giving an output clock of 49.65653MHz to the RCP and video DAC.

 

[MarathonMan]

Good luck trying to cycle-accurate emulate the N64 and reproduce sound all on the CPU at full speed.

(Not trying to be an ass or anything...)

Never said it was possible, I just can't really condone an operating system that has troubles supporting the most basic of libraries in 2013, let alone the hundreds of other devices and libraries that FreeBSD can't seem to support.

 

[Fanatic 64]

Well, they can't support OpenAL (Hard) because it is proprietary, not because they don't want to. I agree FreeBSD sucks, though.

 

[MarathonMan]

Well, they can't support OpenAL (Hard) because it is proprietary.

You sure... ?

http://www.freshports.org/audio/openal

Methinks it's just because FreeBSD has terrible hardware support.

 

[Fanatic 64]

That's the archaic pre-1.1 version. Modern stuff requires Creative Labs' proprietary version, which is about as free and portable as DirectX.

 

[beannaich]

Great, PM it over and I'll look at it.

Concerning the 48MHz clock -- I'm not sure that you even need this -- you aren't able to feed the sound card data on the granularity of a cycle anyways, right? I'm not audio guy by any means, but... err... anyways, a 48Mhz clock will be extremely challenging to generate as it is in no way a multiple of the 62.5MHz that the rest of the console uses. If you really need each cycle, you'll have to do some clever math to do either 2 or 1 audio sampling cycles depending on the period by which the RCP clock has elapsed.

You wouldn't be feeding the samples on a cycle basis, they would of course be buffered (the size of which depends on what latency you find acceptable, usually 60-100ms is fine). So the clock divider is only important when determining the access times for sample data. Too early and your sound will be screwy, too late and it may be overwritten depending on how late you are. Approximations can be made, but it would be best to get it as close to exact as possible.

EDIT: What you could do is use the 1375:1071 ratio to synchronize RCP and AI ((62,500,000 * 1071) / 1375) = 48,681,818.18~

Yeah, I'll get the OpenAL port done whenever you wrangle the SDL? DX? or whatever you're using.

Not using anything, since I didn't even know how to get the sound data from memory. All that really needs to be added before testing is memory access and buffering/sending audio to the API.

As for DMAs, use these functions:

void DMAFromDRAM(struct BusController *bus, void *dest, uint32_t rdramAddress, uint32_t length);
void DMAToDRAM(struct BusController *bus, uint32_t rdramAddress, const void *src, size_t length);

You may need to nab the bus pointer somehow -- see how I do it in the other plugins.

I think the bus pointer is passed to the InitializeAI function.

The 48.681812MHz clock is what is provided to the RCP chip. On early N64 units, there is a pair of MX8330MC RAMBUS clock generator IC on the system, one with a 14.31818MHz crystal. This chip outputs 243.40906MHZ(clock*17) and also has a FSO/5 output connected to the RCP clock input giving it 48.681812MHz(this also goes to the video DAC). The 2nd one has a 14.705882MHz crystal generating 250MHz for the RDRAM. Later N64 units use a single MX8350MC which was a 2 in 1 RAMBUS clock generator.

And that 14.31818~ MHz is 4 x NTSC Color Subcarrier, which makes absolute sense.

 

[Nintendo Maniac]

Before CEN64 gets too much attention, it may be a good idea to include a benchmark mode or something. This should (hopefully) greatly reduce anything like the large amounts of "will this be fast enough?" that the Dolphin forum gets.

Also having a benchmark mode could help in the future to mitigate a CEN64 equivalent of the impression that bsnes needs a 3GHz CPU.

Of course, if CEN64 continues with the Mupen64plus development style of "no binaries", then the above two issues might not even be an problem in the first place.

 

[MarathonMan]

Before CEN64 gets too much attention, it may be a good idea to include a benchmark mode or something. This should (hopefully) greatly reduce anything like the large amounts of "will this be fast enough?" that the Dolphin forum gets.

Also having a benchmark mode could help in the future to mitigate a CEN64 equivalent of the impression that bsnes needs a 3GHz CPU.

Of course, if CEN64 continues with the Mupen64plus development style of "no binaries", then the above two issues might not even be an problem in the first place.

Thanks for the suggestion but IMO this is just yet another feature that I don't have time to implement considering the state of the core and everything else.

I'm not trying to condone or sell the project, so if anyone wants to complain about it being too slow, or is too lazy to go to youtube and see things running at ~40VI/s+, too bad.

EDIT: With emucr on Windows, and repositories on Linux/BSD, I have no plans of releasing binaries.

 

[tim4490]

by all means please just focus on finishing the project whenever you can. I'd rather wait patiently and have a finished emu than see this project become overloaded by extras and features and just plain die. Not that its not a good idea, but with limited resources I understand your priorities must be maintained. This is the closest we have come to having an actual N64 emulator that doesn't completely suck.

That's the beauty of open source though, someone else can add all that in later if they so choose so no worries In my personal opinion though, I don't really care if it is newb friendly or popular. Just as long as you give it your best shot and create the best work of art and science that you can I will be happy, and the community will benefit from your code. I just wish I was a more experience coder so I could actually contribute some code. Might be a few years before I reach that point. I can barely get simple programs to compile and function properly.

 

[ExtremeDude2]

Do you plan on CEN64 having plugins? (I ask because someone insists that you are, but I by no means am asking you to support them)

Edit: When I say that I mean in the way one usually thinks on plugins when they think of n64 emus

 

[Fanatic 64]

No. It has already been explicitly stated in the past.

 

[MarathonMan]

Forums are now up at cen64.com

I'm having problems with my mailer, so check your spam folder after registering as your mail is probably there.

No. It has already been explicitly stated in the past.

Correct, but it does allow "static" plugins (the plugins are integrated into the binary and are not configurable at runtime).