MAME, MESS, and Other Fun

I was rather intrigued by David Link’s project to resurrect the Manchester Mark I, and commenced digging up more info about the Manchester Mark I and its predecessor, the Manchester Small Scale Experimental Machine, or “Baby”.

As it turns out, there’s already a Java-based emulator out there.  Inspiration struck, and I decided to see how easy it would be to emulate the SSEM in MESS.  It was, historically, the first electronic stored-program computer (if I read my sources right), so it seems like a prime candidate for support in MESS.

Without further ado, here is the Manchester Small Scale Experimental Machine displaying the results of Tom Kilburn’s “Highest Common Factor for 989″ program, including the correct answer (43).

Chances are good I’ll be able to get clearance to add this to MESS.  Fingers crossed!

On a weekend with nothing better to do thanks to a deathly head cold, I decided to bolt USF support onto MESS.

So far things seem semi-promising. It’s too slow to be listened to in realtime, but that can probably be fixed with an RSP recompiler. Some games work, some games don’t work, some games work but in strange manners.

Here’s a quick rundown on the USF sets I’ve tried so far, and their relative working or unworking status:

• Banjo-Kazooie: Works fine.
• Beetle Adventure Racing: Works fine.
• Blast Corps: Works fine.
• Bomberman 64: Plays nothing.
• Buck Bumble: Plays a very short click, then nothing.
• Donkey Kong 64: Exits MESS almost immediately with an unknown RSP opcode, presumably due to the game running off into the weeds.
• Dr. Mario 64: Plays garbage for around 2 seconds, then causes MESS to fatalerror.
• Conker’s Bad Fur Day: Works fine.
• Diddy Kong Racing: Works fine.
• Goldeneye: Plays the music at around 10 to 20 times the correct tempo.
• Jet Force Gemini: Works fine.
• The Legend of Zelda: Ocarina of Time: Plays nothing.
• Mario Kart 64: Works fine.
• The New Tetris: Works fine.
• Perfect Dark: Works fine.
• Pokemon Stadium: Plays nothing.
• Sim City 2000: Works fine.
• Space Station: Silicon Valley: Plays nothing.
• Super Mario 64: Plays garbage for around 2 seconds, then causes MESS to fatalerror.
• Super Smash Brothers: Works fine.
• Tetrisphere: Works fine.
• Yoshi’s Story: Plays nothing.

I suppose the next step is to either figure out why some games are playing nothing, or why some games are just running off into the weeds, resulting in MESS fatalerroring!

I finally decided to figure out why the scene geometry in The Legend of Zelda: Ocarina of Time is so screwed up.  As it turns out, RSP DMA transfers should have their length rounded up to the next 8 bytes, not the next 4.

Since it’s kind of hard to get the dramatic change across with still shots, I broke out the -aviwrite parameter and uploaded a couple of videos to YouTube.

Before: http://www.youtube.com/watch?v=OUwwBc3G1h0

After: http://www.youtube.com/watch?v=7_9L0G7IsRY

PIN64 proves its usefulness once again!

I’ve always had some slight suspicions that 1-Cycle mode uses the Color Combiner setup for Cycle 1 rather than Cycle 0, mostly because I’ve observed some games setting different parameters for Cycle 1 versus Cycle 0, even when in 1-Cycle mode.

Sure enough, I finally found one game that proves my theory: F-1 Pole Position 64.  Here’s what its menus originally looked like:

Aaaaand after:

As it turns out, there was a rather significant bug in the way MESS was loading textures using the Load Block command when a line-swap delta  was specified.  I’m actually surprised it worked at all.  Now the secondary texture loaded into the CC_TEX1 input is loaded properly.

Before:

After:

A bunch of miscellaneous fixes today:

After making the decision to remove my original alpha-rejection code as it was causing more bugs than it was fixing, I began the arduous process of tracking down the multitude of ways in which the Nintendo 64 can handle textures that need an alpha border to be cut out.

First, I ran across Quake 64, which uses the RDP’s Alpha Compare functionality to cut out its font.  Alpha Compare is relatively simple - it takes place after the Color Combiner stage and before the Blender stage.  If the alpha value of the color output by the Color Combiner is less than or equal to the alpha value specified in the Blend Color register, the RDP will not pass that pixel into the Blender.  If the combined alpha is greater than the alpha value specified in the Blend Color register, the RDP will rasterize the pixel through the Blender.

Sure enough, the UI’s text is now fine:

Next, I finally came to the realization that there is no other form of automatic pixel rejection based on an alpha value, thanks to a tip from a fellow who goes by the nickname of ‘Happy’.  He put forth the idea that the N64 only supports Alpha Compare and no other method for automatic pixel rejection, which caused me to look a bit closer at things like the karts in Mario Kart 64 and the trees in Super Mario 64.

Sure enough, it turns out that I had to emulate the effects of the “Coverage Times Alpha” bit in the Set Other Modes command.  I was only emulating the “Use Coverage As Alpha” bit, and since the transparent pixels were fully covered, they were being rasterized due to their coverage being non-zero.  However, the pixel alpha value was, in fact, zero, so multiplying the coverage value by zero resulted in a final blended alpha of zero!  Brilliant!  Mario Kart 64 and Super Mario 64 now look much better:

I then turned to Space Station: Silicon Valley, wherein the Take 2 logo was completely black.  It turns out that if both alpha values of the second Blend cycle are zero, the pixel does not become zero - in fact, the cycle is then just ignored.  A quick fix later and the logo sprang to life:

Lastly is a personally controversial fix in that it wasn’t until this blog post that I realized that the fix I came up with causes problems in other games.  In Bust-A-Move 2, there is an animated ground plane that is drawn line-by-line down the screen.  The topmost line of the plane actually has a T coordinate of 160.0, and as a result the Set Tile Size command sets the tile’s T base to be 160.0.  However, the S and T mask bits were set to 7, which results in the coordinates mirroring from 0 to 127 and back.  Since the texture coordinates were being adjusted by the values in the Set Tile Size command after mirroring, and the mirroring was affecting the coordinates, they were not remaining at the appropriate position.

Before my modification to the order of coordinate adjustment, the ground plane looked like this:

After my change, the ground plane looked like this:

Unfortunately, I discovered when writing this blog post that the same change seems to affect the text in some games, so it will need further examination.  Still, I feel I’m on the right track.

A number of N64 games in MESS have suffered from a strangle hall-of-mirrors effect, or assorted missing graphics.  Since I’ve had some time off from work, I decided to look into it.

As it turns out, I wasn’t properly emulating the fact that the most significant coverage bit is stored in CPU-visible memory as the least significant bit in a 16-bit RGB555 triplet.  This didn’t have much of an effect on things unless a game was copying the framebuffer contents into RAM, in which case the low bit was used as the alpha bit in a 16-bit RGB555 texture that was used in the following frame.

In addition, I’ve had it re-confirmed in my mind that in at least some cases the N64 does not choose not to blend a pixel if its alpha value is 0; this along with the coverage bit fix has the following effects on the following games that I’ve tested:

- Mario Kart 64: The full backgrounds in menus now appear, rather than the first 16 lines or so, and the jumbotron in the Luigi Raceway and Wario Speedway venues work:

Dr. Mario 64: The playfield no longer becomes all white and hall-of-mirror-y when playing:

Pokemon Puzzle League: The scrim around the playfield and HUD is now visible.

Tetrisphere: There’s no longer a hall-of-mirrors effect between the gaps in the undulating background tiles.

I have a strong feeling that in some cases the N64 does reject pixels prior to color-combination and blending if they have an alpha value of0, it just may be controlled by a mechanism I do not fully understand (Force Blend bit in the Set Other Modes command?).

No new discoveries for tonight, but to appease all two of my fans, I recorded some AVIs with MAME and then encoded them with XviD.  Surprisingly, the driver actually looks and sounds decent when sped up to full speed:

Mario 64 (attract mode): http://moogle-tech.com/mario64.avi

Diddy Kong Racing (attract mode and some gameplay): http://moogle-tech.com/dkr.avi

Tetrisphere (opening): http://moogle-tech.com/tetrisphere1.avi

Tetrisphere (credits): http://moogle-tech.com/tetrisphere2.avi

On Sunday evening I added a new “Tweak” viewing mode to the PIN64 Player:

It’s somewhat of a hack, as it relies on two triangles being in those two precise locations, but with any luck it will allow me to figure out precisely how coordinate rounding works on a real N64.

The upper-left grid of numbers and dots corresponds to the coverage values of the left-hand triangle, likewise the right-hand grid of numbers and dots correpsonds to the right-hand triangle, which is of the same dimensions as the left-hand triangle, but offset 0.25 pixels to the right.

The reason for this discrepancy is the fact that the full coverage value - that is, the covered / uncovered state of all 16 subpixels rather than a mask of only 8 - can be reverse-engineered by rendering two triangles of exactly the same dimensions offset by 0.25 pixels from each other and then observing the coverage values for each one.  By plotting the points in MS Paint (or any other image editor) that correspond to the covered subpixels for each triangle, the second triangle’s pixels can be shifted left by exactly one pixel, resulting in the second triangle’s mask filling in the missing pixels from the first triangle’s.

Observe this crappy diagram that I’ve come up with:

In the case of a perfect right triangle, it is first drawn aligned to a whole pixel, and is then drawn shifted right by 0.25 pixels.  A full column of pixels goes missing from the left-hand side of the triangle, due to the way the N64 rounds left-hand edges, but the rest is fully visible.  The second set of points can then be shifted left and intersected, to form a fully complete coverage mask.

To put it another way, with every other pixel missing from the coverage mask, one cannot accurately determine whether a given span ends on the sub-pixel included in the coverage mask or the sub-pixel directly to the right of the one in the coverage mask.  By intersecting the two masks, it is possible to precisely determine the ending subpixel of a given span.

Going back to the original screenshot, one can see a series of hex values in the upper-right.  These correspond to the fractional portion of the X-High, X-Middle, and X-Low coordinates for both of the triangles, and there is a seventh value that specifies an amount by which to tweak those starting values.  To that end, once I have time to do so (work has been keeping me busy!), I should be able to slowly increment the tweak value and see exactly when a coverage value changes, indicating that the new value for a span rounds differently from the previous value.

We’ll see how that pans out.

A few tweaks gets MESS looking markedly more like a real N64:

Click the second screenshot for a bigger version.