Implementing timing/cycle interupts and delays

Discuss miscellaneous N64-related matter here.
Post Reply
User avatar
OldGnashburg
Posts: 91
Joined: Tue Nov 19, 2013 3:00 pm
Location: Sherwood Park, Alberta, Canada: A place with free universal healthcare, and lots and lots of oil.

Implementing timing/cycle interupts and delays

Post by OldGnashburg » Thu Nov 20, 2014 4:17 pm

From reading emulation forums I know that in hardware, at certain points there are (either an entire cycle or within a cycle) timing delays or whatever (I can't really explain it because I really don't know much about it) which are put in place so everything runs smooth and there are no discrepencies. I have read that with CEN64 the multiple threads have to be totally interlocked (I am not sure of the name) and if one of them goes out of sync, than the entire thing fails. Anywho, with implementing certain hardware delays (which I'm not sure you have done yet), how would that affect your whole multithreading, or does it not matter when everything is finished and polished, because the delays will slide into place and keep perfect thread interlocking.
Gnash, Gnash, Gnash...

User avatar
MarathonMan
Site Admin
Posts: 691
Joined: Fri Oct 04, 2013 4:49 pm

Re: Implementing timing/cycle interupts and delays

Post by MarathonMan » Sat Nov 22, 2014 12:32 pm

OldGnashburg wrote:I have read that with CEN64 the multiple threads have to be totally interlocked (I am not sure of the name) and if one of them goes out of sync, than the entire thing fails.
This was a former approach I was trying; a software-transactional approach (http://en.wikipedia.org/wiki/Software_t ... nal_memory). Unfortunately, I never got too far with it and have more or less gone back to running everything from within two threads. A simulation thread simulates all the devices (looping over them in lockstep fashion), while the other thread manages the user-interface -- periodically polling for input, performing the actual OpenGL (and soon, OpenAL/audio calls), etc. -- things that can easily be piped from one thread to another.

Fortunately, with the rewrite, CEN64 is still written in a way that is transactionally friendly with some arm lifting, but it'd still be an immense research effort and take a lot of ingenuity to get it done. If somebody were to implement something like this and prove speedups over traditional emulation, I think it would have the potential to be one of the biggest achievements since dynamically-recompiled code.
OldGnashburg wrote:Anywho, with implementing certain hardware delays (which I'm not sure you have done yet), how would that affect your whole multithreading, or does it not matter when everything is finished and polished, because the delays will slide into place and keep perfect thread interlocking.
Now that multi-threading is gone from the simulator proper, this is a non-issue.

User avatar
OldGnashburg
Posts: 91
Joined: Tue Nov 19, 2013 3:00 pm
Location: Sherwood Park, Alberta, Canada: A place with free universal healthcare, and lots and lots of oil.

Re: Implementing timing/cycle interupts and delays

Post by OldGnashburg » Wed Nov 26, 2014 3:51 pm

Did you just say "OpenAL" soon? Wow, so we're soon going to have audio? That is amazing, is this of your own design or is it an external thing? I remember reading a conversation on these forums (I think) between you and another person who wanted to write the audio portion of CEN64, so that is why I am asking. Also do you have any plans yet on writing your own RDP? I remember you saying that the current RDP you have is just a substitute until you wrote your own, or are you doing something different?
Gnash, Gnash, Gnash...

beannaich
Posts: 149
Joined: Mon Oct 21, 2013 2:43 pm

Re: Implementing timing/cycle interupts and delays

Post by beannaich » Fri Nov 28, 2014 12:13 pm

OldGnashburg wrote:I remember reading a conversation on these forums (I think) between you and another person who wanted to write the audio portion of CEN64, so that is why I am asking.
That was probably me. Audio in the current CEN64 would be trivial to implement, since it's more than likely already being mixed properly by the RSP. All one has to do is simulate the AI (Audio Interface) and get the few (3-4?) memory mapped I/O registers implemented. As I recall, the AI is little more than a simple D/A converter and a configurable count-down timer that is used to push out the next buffered sample. The timer is controlled by the "sample rate" registers, meaning the sample rate varies, and some form of sample rate conversion would need to be implemented at some point (most games I tested with seem to pick the ~32KHz option, but there are most certainly over achievers).

The other problem with software like CEN64, is that most games currently aren't expected to run at full speed, so some sort of sample-stretching would also need to be implemented. So for example, if a playthrough were being recorded, it could be sped up to full speed and the audio would sound like it should.

Those two minor issues aside, audio requires nothing more than taking samples that are already processed by the RSP, and sending them to an audio device in some manner at the right time.

User avatar
OldGnashburg
Posts: 91
Joined: Tue Nov 19, 2013 3:00 pm
Location: Sherwood Park, Alberta, Canada: A place with free universal healthcare, and lots and lots of oil.

Re: Implementing timing/cycle interupts and delays

Post by OldGnashburg » Mon Dec 01, 2014 11:14 pm

Oh, that was you? May I ask how it's going? Or is that between you and MarathonMan,
Gnash, Gnash, Gnash...

beannaich
Posts: 149
Joined: Mon Oct 21, 2013 2:43 pm

Re: Implementing timing/cycle interupts and delays

Post by beannaich » Fri Dec 19, 2014 1:09 am

OldGnashburg wrote:Oh, that was you? May I ask how it's going? Or is that between you and MarathonMan,
I have no time to work on projects like this at the moment.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest