In the past few months, we’ve made significant progress on the Wii64 dynarec. Most of the bug fixes are pretty minor fixes like correcting off-by-one or other various memory errors; however, there are several substantial changes to both the infrastructure and features of the dynarec.

On the N64, there is a register called Count which keeps track of how many cycles the system has been running. This is primarily used to determined when interrupts can be taken. In Mupen64, Count is estimated as 2 cycles per instruction executed. Some emulators actually increment Count differently depending on which instruction ran (because on the hardware, some instructions will take longer to execute). The fact that Mupen was doing really well with the Count estimate led me to believe that getting an exact Count was unnecessary, and I initially tried playing some tricks to estimate without explicitly keeping track of Count. However, I quickly discovered that even deviating from the way Mupen counts will quickly result in crashes and freezes. Several major fixes have involved correcting edge-cases which caused Count to be somewhat off.

Initially only 32-bit integer instructions were supported in the dynarec (they comprise most of the ISA, and I just wanted to get something working before I tried anything too complicated). Once I got the dynarec running with just those basic instructions, it was still fairly slow because a lot of instructions were still being interpreted (thus trumping any performance benefits of the dynarec). Getting the floating-point and 64-bit instructions (which aren’t used all that often as the name N64 would lead you to believe) supported in the dynarec were important for improving the dynarec performance beyond that of the pure interpreter.

With the exception of the way floating-point comparisons and conversions are done in MIPS vs PPC and MIPS’s sqrt, floating-point was fairly straightforward to implement in the dynarec as most instructions had a 1-1 mapping. Even the comparisons were relatively simple although they do not take advantage of what I feel is a more rich FP comparison on the PPC. However, since the Wii does not have a floating-point square root instruction, it was difficult to support the MIPS sqrt instruction in only a few instructions. We did manage to get it working with what seems to be good-enough precision using the PPC frsqrte (floating reciprocal sqrt estimate), Newton-Raphson refinement, and a fmul. The only floating-point instructions left to support are conversions to and from 64-bit integers which are nearly impossible to generate code for because there is no hardware support on the Wii and the process is rather complex.

64-bit instructions were a similar story: most of the instructions had a straightforward translation from MIPS to PPC (even though the PPC in the Wii is 32-bit), but there were a few which were difficult to emulate. The simple addition, subtraction, and logical instructions were very simple: you simply need to use two PPC registers to store a 64-bit value and there are instructions which will keep track of and use the carry bit so that a 64-bit add/sub can be performed in two 32-bit add/sub. The 64-bit shifts were relatively complicated because you have shift both 32-bit words separately, and then determine what would have spilled from one into the other and or it into that word, but it can be done in around 10 instructions in PPC. Like with FP, there were a few 64-bit instructions that we couldn’t reasonably generate code for: the 64-bit multiply and divide are too complicated for generating code using only 32-bit operations.

However, even with most of the ISA implemented, there was still significant room for improvement in performance. I have since made some other significant improvements which I will be detailing in more posts to come soon.

I am sure you saw the news post item about certain GPL violation.

Let me present here some more details about the case.



Disclaimer

Fingolfin and cyx are bound by the agreement signed by the lawyers. They are not allowed to talk about the case. Other developers are not, and there is pretty handful of them who know at least beginning of the situation. We are not happy about the outcome, cyx and Fingolfin included.


Short story

As you may imagine, we are closely watching the market for ScummVM-supported games. One of the main reasons is provide an up to date information on our Where to buy games list. Thus, we were pretty glad and interested to hear that there are upcoming Humongous Entertainment titles on Wii. Thus, as soon as the games were on sale, couple of developers bought them.

Suddenly something quite unexpected happened. I got 2 independent reports from 2 completely different sources, even from different countries that apparently there is ScummVM inside. I was not surprised by the fact of ScummVM usage, as there are already Revolution games and GOG.com who sell ScummVM as part of their distributions, still a surprise was that there were the SCUMM-based games. Thus, I quickly requested to inspect the box for copyright statements, and as such, there came a surprise.

Clearly, it was a violation. Further inspection showed that it was even a blatant violation. I addressed to my friend, google.com search engine, and I found following facts:

Apparently Atari contracted porting work to their long time partner, Majesco Entertainment.

Majesco Entertainment in turn subcontracted the work to Mistic Software, a Canadian-based game shop

Mistic Software has its development office in Chernigov, Ukraine, locally presented as Mistic Soft LLC who did the actual work



These Mistic Soft guys got the game assets and sources (this is obvious from the fact that they were able to insert their names into game credits seamlessly), but instead of performing actual work they went a cheap way.

Inspection of the game binary (we dumped it on SD Card on Wii with homebrew channel, it's pretty small) showed that they based their work on ScummVM 0.9.0, inside there were full credits to ScummVM Team (with couple placeholders for their names, though they left them empty), as well as such goodness as "This might be broken -- please report where you encountered this to Fingolfin" or "Tell sev how to reproduce it". Judging from the symbol names they rolled out their own backend, and used Nintendo tools for that.

Then we performed some playtesting on the real thing in order to find clues that ScummVM is inside. Pretty fast we found a 0.9.0-era bug in Freddi Fish. Let me demonstrate it:



Note that gfx glitch on Freddi's left eye. It is right at the beginning of the game, when Freddi reads a letter from the bottle, and is easy to spot on the console. There could be other bugs, but that was enough. Now this bug is fixed in ScummVM.


The development


We were quite shocked. It looks like Mistic Soft took money for all the porting efforts but instead of that just stacked together a ScummVM build! Of course, it was easier (my estimate, that it requires about 2 full time weeks to port ScummVM to new platform), since as I suspect, original interpreter is not very alignment-safe and is not endianness-agnostic as ScummVM is.

Thus, we started to discuss what should we do with the case, and decided to approach gpl-violations.org. We got a lawyer which specializes on such violations, and pretty soon we sent a letter to Atari in Germany (the fact that the games being sold in Germany eased the work considerably).

First they started to deny everything. This is a pretty common thing among the lawyers, and also as I understand, they were not aware of the issue. Consider this: These programmers from Mistic Soft just provided the binaries to their Quality Assurance department, and the games worked well (as ScummVM does). They found no bugs, passed the work to Majesco, and those reported about successful project completion to Atari. Of course nobody except the developers (and perhaps their immediate managers) knew whose code is in there.

So, first Atari lawyers thought that we are going to sue them for zillions of Euros, and they prepared well for the fight. Once they got to know that only thing we are demanding is stick to GPL, they relaxed and the negotiations went much better.

We discussed that they could put stickers on those games which are being sold, and put ScummVM copyrights on new prints, mention us on their site. And it was really nice at first, but pretty soon the lawyers found that Nintendo explicitely prohibits use of open source software together with their Wii SDK, and as such it was a big fault from Atari side.

Thus, instead of being nice they decided to go and hit us badly.

At this very point let me go a bit astray and explain some things about ScummVM. ScummVM is a collection of game engines. There are two major categories of them. Part of the

Sorry for the slow updates. I've had to deal with lots of unexpected trouble during testing of dual-boot, plus school finished recently and thus my two daughters require more attention.

I appreciate your support very much and I know you're all holding your breath for the dual-boot functionality, so, please excuse me for the delay.

This is what's been done:

Dual boot code has been moved from U-Boot to the SPL: removes tiny delay introduced when booting the original firmware.
LCD support implemented both in SPL and U-Boot (both ILI9325 and ILI9331). The LCD now goes live immediately on bootup, which is great when loading linux because otherwise you would see a black LCD for a couple of seconds until the kernel framebuffer driver kicks in, and it is a bit confusing.
Implemented access to the SPL area (first eraseblock of NAND) in the linux kernel. This allows flashing the dual-boot binaries from linux.
Streamlined the flashing of the dual-boot binaries from linux.
This is what needs to be done:

Add a simple dialog that shows a disclaimer and asks for confirmation before flashing the dual-boot binaries.
That is very easy and I just need a couple of hours to do it, so I can assure there will be a release tomorrow or the day past tomorrow.

One final note: someone posted a comment pointing out that lingoox might sound a bit offensive in some contexts. If this is a problem we're on time to change it... so please let me know.