Is it possible to disable anti-aliasing in N64 games via GameShark cheats?

Locked
User avatar
Archive
Posts: 891479
Joined: June 25th, 2019, 11:00 am

Is it possible to disable anti-aliasing in N64 games via GameShark cheats?

Post by Archive » June 27th, 2019, 12:44 pm

posted by Poregon on Feb 20, 2016:

hyperterminal said:






saturnu, I patched the rom GoldenEye 007 (U) [!] (MD5: 70C52588 0240C1E8 38B8B1BE 35666C3B) with your universal aa-patcher v0.2 beta and the game freezes every time I press start in game to look at the Bond watch. The PAL version works fine though.

Goldeneye works fine for me and is hideous with AA off, like the other Rare games... but does not crash when the watch comes up/goes down. Your patch must have done something screwy. Use the IPS files I linked.
 

User avatar
Archive
Posts: 891479
Joined: June 25th, 2019, 11:00 am

Is it possible to disable anti-aliasing in N64 games via GameShark cheats?

Post by Archive » June 27th, 2019, 12:44 pm

posted by S3M on Feb 20, 2016:

It's great to see what you guys are doing here as the N64 fog is the bane of the system. To think it was just some crappy filter Nintendo had the N64 output much like the original Xbox. Tempted to test this out on a few games myself.

As a UK member will these codes work with an Action Replay for the system or only a Gameshark? The reason I ask this is that looking at amazon and ebay here in the UK the Action Replay is cheap and easy to find where as the Gameshark is rather hard and pricey much more common in the USA. That said looking at the N64 AR and GS I'm wondering if they are the same device and it's just that AR was the European branding and GS was the USA.
 

User avatar
Archive
Posts: 891479
Joined: June 25th, 2019, 11:00 am

Is it possible to disable anti-aliasing in N64 games via GameShark cheats?

Post by Archive » June 27th, 2019, 12:44 pm

posted by rso on Feb 20, 2016:

Same devices under different branding afaik.
 

User avatar
Archive
Posts: 891479
Joined: June 25th, 2019, 11:00 am

Is it possible to disable anti-aliasing in N64 games via GameShark cheats?

Post by Archive » June 27th, 2019, 12:44 pm

posted by Try4ce on Feb 26, 2016:

Hey everyone. This is Try from My Life in Gaming. I don't know if any of you are familiar with our videos, but we do a series on getting the best picture quality out of retro consoles. We were lucky enough to have an opportunity to include the Ultra HDMI in our N64 episode ahead of its release:


We've been getting a lot of comments about what you all have going on here, and it's something our audience would definitely like to see addressed. There seems to be a misconception that this is an alternative to the Ultra HDMI's de-blur effect, but as far as I can tell, they're actually two completely different things (I bought my own Ultra HDMI in December). I tested the Mario Kart 64 code last night with my very outdated GameShark 1.06, and the result was exactly what I expected.

Here's Ultra HDMI, no de-blur, no GameShark:
Image

Turning on the de-blur effect gives us this, which has VERY clean HUD elements:
Image

OK, so let's turn the de-blur off again, but add the GameShark code. As I expected, this does NOT improve 2D elements:
Image

Combining the power of the Ultra HDMI de-blur with the GameShark code, we get this:
Image

Please correct me if I'm wrong, but as far as I know, the N64's "blur" is essentially a two-step process.

1. There's the basic anti-aliasing, which is completely outside the scope of the Ultra HDMI's capability to "fix." This is what the GameShark can change.

2. Then there's an additional horizontal blur added before the final video output. Through whatever witchcraft, the Ultra HDMI is able to restore the image to a much cleaner state in its final output. I suspect this process happens past the point where the GameShark could have any influence, but again, correct me if I'm wrong.

If I were to throw in my personal opinion, I don't think I'm too into the GameShark anti-aliasing removal, but I LOVE the Ultra HDMI's de-blur. I love seeing the sprites in the way they were originally drawn, and it improves the clarity of the overall scene as well. While I am certainly a fan of the PlayStation look as well, I feel like the N64's basic anti-aliasing, combined with the de-blur, makes a nice middle-ground, and that the complete removal of anti-aliasing isn't necessary. But since my GameShark is so old, there's not a ton of games that I can test, so I'd need to see more games to really form an opinion (I think GoldenEye is the "newest" game that mine works with).

Regardless, this is pretty fascinating stuff, and we'd love to address it in a shorter video on our channel. If anyone would like to collaborate to help us come to a better understanding of what's going on here, how to explain to people how they could generate their own codes (you're figuring this out with some sort of software?), and help us come up with more codes to feature, that would be great! I'm in the US, and Mario Kart 64 was the only code I could find in this thread that was for a game old enough to work on my GameShark. We would also like to be able to point people to an easy-to-browse resource that includes the codes... is anyone planning to make one?

To be honest, most of the talk in here flies over my head... flipping the flags, generating the codes, etc. We always like to break things down in such a way so that people who, like us, aren't modders and hackers, can enjoy the results. So any help that could be provided to clarify things would be much appreciated!
 

User avatar
Archive
Posts: 891479
Joined: June 25th, 2019, 11:00 am

Is it possible to disable anti-aliasing in N64 games via GameShark cheats?

Post by Archive » June 27th, 2019, 12:44 pm

posted by saturnu on Feb 26, 2016:

Hm lets try to explain this a bit more, feel free guys to correct me. ^^
I don't think i get all this stuff correctly written down. ^^


GS-Codes
8102316C 0000
8102316E 3216


The GS-Code 81XXXXXX YYYY means, that 16Bit (2Byte) at addr 0xXXXXXX are continuously written to this memory location.
This example code writes at 0x2316C the value 0x00003216 to one of the mostly two buffered VI_STATUS_REG settings for each framebuffer?
i think it's read, bufferd, altered and written back by the vi_register.

binary translation:
0x00 0x00 0x32 0x16
MSB-> 00000000 00000000 00110010 00010110 <-LSB
(a byte mostly has 8 Bit, the bytes here are filled up with zeros to the left)

The LSB (least significant byte) is right and you read it to the left side.

In the following description the first number is the posituon in decimal from the right to the left. counting starts at 0 e.g. like it's done on an c array.
the functions are disabled with 0 or enabled with 1, if there is more than one bit you have to convert the dec value to binary. e.g. 3d to 11b

0x04400000 - VI_STATUS_REG or VI_CONTROL_REG - VI status/control (Read/Write)
Bit Expl.
0-1 Type (Pixel Size) (0-3, see below)
>>> 0 = blank (no data, no sync)
>>> 1 = reserved
>>> 2 = 5/5/5/3 ("16" bit)
>>> 3 = 8/8/8/8 (32 bit)
2 Gamma Dither Enable (normally on, unless "special effect") adds noise to lsbs of the pixels
3 Gamma Enable (normally on, unless MGEG/JPEG)
4 DIVOT Enable (normally on if antialiased unless decal lines) this is part of the aa algo and adds in some median valued pixels around outlines
5 reserved - always off <- don't turn this on, hardware damage can be a result
6 serrate (always on if interlaced, off if not)
7 reserved - diagnostics only
8-9 anti-alias (aa) mode
>>> 0 = aa & resamp (always fetch extra lines)
>>> 1 = aa & resamp (fetch extra lines if needed)
>>> 2 = resamp only (treat as all fully covered)
>>> 3 = neither (replicate pixels, no interpolate)
10 <- reserved
11 reserved - diagnostics only
12-15 reserved -> this should always be 3
Extra: 16 dither filter enabled: this bit is in the next byte and the next gs-code (the third one)
you have to clear this to get rid of AA?
what this does is reversing the dither filtering and leave it to the rdp, it's used on 16bit mode but not on 32bit mode.

Here is a normal low res vi_status_reg setting, look how the "dither filter" is enabled in the 3rd byte.
0x0001311e

if all bits are set, you can convert these binary numbers back to hexadecimal

n64.icequake.net/mirror/www.ji…N64TEK.htm#videointerface
 

User avatar
Archive
Posts: 891479
Joined: June 25th, 2019, 11:00 am

Is it possible to disable anti-aliasing in N64 games via GameShark cheats?

Post by Archive » June 27th, 2019, 12:44 pm

posted by AtomizerZero on Feb 26, 2016:

I thought there was no text in your post, but it turns out you're using white. I'm using the white/blue theme, so I can't see your text without highlighting it first.. minor annoyance, but thought i'd let you know.

To be honest, the website should have something in place to stop this from occurring (like, If using XTHEME -> White text = Black, or something like that). Yellow is hard to see on white too, as well as lime green.. Maybe I should make a suggestion post about this.
 

User avatar
Archive
Posts: 891479
Joined: June 25th, 2019, 11:00 am

Is it possible to disable anti-aliasing in N64 games via GameShark cheats?

Post by Archive » June 27th, 2019, 12:44 pm

posted by Try4ce on Feb 26, 2016:

saturnu said:






Hm lets try to explain this a bit more, feel free guys to correct me. ^^
I don't think i get all this stuff correctly written down. ^^

Thanks for the info! I have to admit that it doesn't make much sense to me, but I showed it to a friend who understands coding stuff, and I'm kinda starting to understand.

So each game is going to have different codes, different memory addresses to tweak, right? What are you using to analyze the game to determine what address to tweak? How are people figuring these out? Is there trial and error involved, or is it easy to find, for people who are used to this? I would definitely like to see more US codes to test out!

Sorry to ask questions like these, I'm just trying to figure out how to translate this stuff into layman's terms for our video.
 

User avatar
Archive
Posts: 891479
Joined: June 25th, 2019, 11:00 am

Is it possible to disable anti-aliasing in N64 games via GameShark cheats?

Post by Archive » June 27th, 2019, 12:44 pm

posted by xdaniel on Feb 26, 2016:

Try4ce said:






Regardless, this is pretty fascinating stuff, and we'd love to address it in a shorter video on our channel. If anyone would like to collaborate to help us come to a better understanding of what's going on here, how to explain to people how they could generate their own codes (you're figuring this out with some sort of software?), and help us come up with more codes to feature, that would be great! I'm in the US, and Mario Kart 64 was the only code I could find in this thread that was for a game old enough to work on my GameShark. We would also like to be able to point people to an easy-to-browse resource that includes the codes... is anyone planning to make one?

I can try to help a bit with the "how to generate your own codes" part. There's two ways to create the GameShark codes I know of: the first would be using an emulator with memory viewing/editing capabilities (ex. Nemu64) and ROMs of the games, while the second would be using a GameShark capable of linking up to a PC for code generation.

The first way, via emulation, is probably the easiest as it just requires a copy of Nemu64 v0.8 and the game's ROM image. Leaving the matter of acquiring the ROM aside, it's quite simple. Boot up the game in Nemu, then go into the "Plugins" menu, then select "Debugger: Memory..." to open up the Memory window. There, use the "Address" textbox to go to address A4400000, which is the system's VI_STATUS register, and take note of the 4-byte/32-bit value there - in Mario Kart 64's case, it's 00013016. Now, click the "Search..." button, put that value into the "Search value" textbox (making sure "Hex" is checked and "32 bits (aligned)" selected to the right of it) and click "Search". You'll hopefully wind up with only two possible results, both exactly 0x30 hexadecimal (48 decimal) bytes apart. Make note of both addresses. If you want, you can also double-click them to go to the address in question in the memory editor. For MK64, the two results are 000EB3DC and 000EB40C. I'll get to what to do with these two addresses after describing the alternate way.

Screenshots:




Spoiler

Image
Image
Image
Image



The second way is more involved, as it requires some hardware, as stated before: namely an N64 (obviously), a GameShark Pro with a functioning parallel port on the back, a PC with a parallel port (I believe USB adapters for connecting printers won't work), the game you want to find codes for, and, if the game requires a GS keycode to boot (Zelda, F-Zero, etc.), another game like Super Mario 64, Mario Kart 64 and most others to boot the system, to select the correct keycode, then turn the system off again, swap in the cart that needs the keycode, and then turning everything back on. I should note that the whole procedure can be quite unstable regardless of the setup, and I, personally, have had the best luck using a Windows 98 setup on an old laptop, although at least the "Game Software Code Creator" tool, GSCC for sort, is supposed to also work under Windows XP, at least. See the Kodewerx EnHacklopedia for more details about the PC connection.

With the N64 booted up and on the GameShark's main menu screen, have the GSCC software on the PC detect the proper settings for communication in its configuration screen, then start the game on the N64 with the Code Generator turned ON. Once somewhere in-game, go to GSCC's RAM editor via the menu "Ram Edit", then "Open Window". Once there, click the "Goto Address" button, then enter "0xA4400000" as the address and click "Goto". The main editor window will now show the memory starting at address A4400000, where you should find the same values as with the Nemu64 method, i.e. 00013016 for MK64. Now, press the "Find Memory" button next to Goto Address, put the value into the "Find What" textbox, make sure "Hex" is selected for "Value" and press "Find Now". This'll freeze the game until the value has been found in memory, so don't be alarmed. Once the value has been found, the game resumes and the RAM editor jumps to the value's location, in this case, again, 000EB3DC (or rather 000EB3D0, as that's how the display works, but the result is in fact at 000EB3DC). Once again, there's another copy of the same value 0x30 bytes away.

Screenshots:




Spoiler
Sorry it's only two, as I mentioned this setup can be kinda unstable, plus that old laptop isn't the fastest, etc.

Image
Image



Now, what values to write to these addresses, and how to turn them into GameShark codes. My codes so far have done two things: one, disable the dither filter (which removes dithering in 16bpp display modes), and two, change the anti-aliasing mode to only resample, not anti-alias. What exactly the four AA modes do I honestly can't say for certain; other people like saturnu or Zoinkity know much more about the N64 hardware than I do. Also, this'll be a very simplified breakdown, so you might want to refer to saturnu's post above for more details about the bits in the register, etc.

First, let's remove the anti-aliasing. The AA mode is encoded in bits 8 and 9 of the VI_STATUS value, which in MK64's case are set to 0, 00013016. Note that this digit could theoretically be something higher than 3, in which case you'd need to do some math to modify only the bits you need. Changing this to 00013216 will disable AA while keeping resampling enabled. I'm not sure if this is an issue on my end, but if I set this to 3, i.e. 00013316, I tend to get scrambled video output on my NTSC system and some distortion on my PAL machine (see the comparison photos below and this previous post of mine).





Spoiler

Image
Image



Next, removing the dither filtering. Bit 16 in the VI_STATUS value controls this, which is set to 1 in our MK64 example, 00013016. Thus, disabling the filter is as simple as changing 00013016 to 00003016, and putting the two together, we turn 00013016 into 00003216.

Finally, the easiest way to turn this into a GameShark code is by turning it into two 16-bit writes. Split the changed value of 00003216 into two, i.e. 0000 and 3216. 16-bit writes are prefixed with 81 before the address, so the addresses we've written down, 000EB3DC and 000EB40C, become 810EB3DC and 810EB40C, and because we need to use two writes per location, we'll need four codes in total, 810EB3DC, 810EB3DE, 810EB40C and 810EB40E. Thus, the final codes are 810EB3DC 0000, 810EB3DE 3216, 810EB40C 0000 and 810EB40E 3216.

I hope this is in any way useful, no matter to whom. If there's anything wrong with my explanations, feel free to correct me, or if there's any questions, I'll try to answer them.

(Edit: fixed some minor errors)
 

User avatar
Archive
Posts: 891479
Joined: June 25th, 2019, 11:00 am

Is it possible to disable anti-aliasing in N64 games via GameShark cheats?

Post by Archive » June 27th, 2019, 12:44 pm

posted by saturnu on Feb 26, 2016:

i would like to add, that so called master codes or enable codes are often needed in addition to get the aa codes working.
if you are using roms to create the codes you should keep in mind, that games - beside the obvious region can have different internal game versions. this can result in different memory locations for the same game.

i'm using a modifed version of mupen64plus with a 2.5 debugging core to create codes.
it plays a lot of games but it's not very userfriendly. ^^
 

User avatar
Archive
Posts: 891479
Joined: June 25th, 2019, 11:00 am

Is it possible to disable anti-aliasing in N64 games via GameShark cheats?

Post by Archive » June 27th, 2019, 12:44 pm

posted by xdaniel on Feb 26, 2016:

saturnu said:






i would like to add, that so called master codes or enable codes are often needed in addition to get the aa codes working.
if you are using roms to create the codes you should keep in mind, that games - beside the obvious region can have different internal game versions. this can result in different memory locations for the same game.

i'm using a modifed version of mupen64plus with a 2.5 debugging core to create codes.
it plays a lot of games but it's not very userfriendly. ^^

Right, I forgot to mention the Master codes and game revisions. If the game in question already has codes stored in the GameShark's default code list, then it'll already have its master code stored (listed as "(M)" codes on my GS Pro v3.3) if one is required, otherwise no codes would work. If the game's not already on the list and the codes won't work when you try them without a master code, you'll have to look up the proper code on the internet. I did have some issues finding the proper one for my PAL copy of Smash Bros., but you should be able to find the right codes (by trial and error, if need be) for most games online.

Some games, like Zelda: Ocarina of Time, have had multiple revisions - NTSC had three, PAL had two - so you'll have to make sure to use the ROM corresponding to your cartridge's version, as there can be (and in OoT's case, there are) memory location differences, as saturnu said.

Also, I forgot to mention that I used the US NTSC version of Mario Kart 64 in my example above, just to make that clear.
 

Locked