As its been a while since our last binary release, we wanted to clarify why its been so long and what we’re waiting for for our next release. Early on in development we were making relatively big changes which significantly improved the emulator; however, we’ve gotten to the point where a lot of the big things have been done, and only need perfecting (with the exception of the dynarec). Thus, we haven’t felt the need to make several binary releases as most of the users who aren’t interested in compiling the source themselves are mostly uninterested in the kinds of changes that have been made. We do indeed have a milestone for our next release planned: a working, stable dynarec. Most of the work that has gone into the emulator since our last release has been focusing on the dynarec, and since we still don’t have a completely working dynarec, there haven’t been many noticeable changes. So we’re holding out for a dynarec which supports at least most games without crashing before we make our next release. After getting it running initially, there will likely be more room for optimization if there are still any performance issues. In that case, we will likely have frequent releases once again as there will be noticeable improvements with each optimization that is made. As always, please be patient. We’re working hard to make the next release something worth the wait.

On an unrelated technical note, we have managed to free up 1.75MB in RAM by consolidating the various memory LUTs (look-up tables) into a single LUT for all memory operations. In Mupen64, there are 8 different memory LUTs which are used to determine how to handle memory accesses at different addresses. These 8 are split up by read/write byte/half-word/word/double. Instead of having 8 large LUTs, I created one LUT for all memory operations which points to smaller LUTs which handle the different memory operations in the specified segment. Memory operations only require an additional load for the second level LUT so there is no performance impact by this change. We are still looking into other ways to further reduce our memory usage to make sure that we have plenty of room in memory for recompiled code produced by the dynarec.

As its been a while since our last binary release, we wanted to clarify why its been so long and what we’re waiting for for our next release. Early on in development we were making relatively big changes which significantly improved the emulator; however, we’ve gotten to the point where a lot of the big things have been done, and only need perfecting (with the exception of the dynarec). Thus, we haven’t felt the need to make several binary releases as most of the users who aren’t interested in compiling the source themselves are mostly uninterested in the kinds of changes that have been made. We do indeed have a milestone for our next release planned: a working, stable dynarec. Most of the work that has gone into the emulator since our last release has been focusing on the dynarec, and since we still don’t have a completely working dynarec, there haven’t been many noticeable changes. So we’re holding out for a dynarec which supports at least most games without crashing before we make our next release. After getting it running initially, there will likely be more room for optimization if there are still any performance issues. In that case, we will likely have frequent releases once again as there will be noticeable improvements with each optimization that is made. As always, please be patient. We’re working hard to make the next release something worth the wait.

On an unrelated technical note, we have managed to free up 1.75MB in RAM by consolidating the various memory LUTs (look-up tables) into a single LUT for all memory operations. In Mupen64, there are 8 different memory LUTs which are used to determine how to handle memory accesses at different addresses. These 8 are split up by read/write byte/half-word/word/double. Instead of having 8 large LUTs, I created one LUT for all memory operations which points to smaller LUTs which handle the different memory operations in the specified segment. Memory operations only require an additional load for the second level LUT so there is no performance impact by this change. We are still looking into other ways to further reduce our memory usage to make sure that we have plenty of room in memory for recompiled code produced by the dynarec.