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

This is pretty incredible! Never thought it would have been done this way. I just figured there had to be a way to turn it off. I have been playing the Ultra HDMI a lot and like it. But to be able to play this on my BVM would be nice without the filter. I have a N64 everdrive version 2. For some reason I cannot get any of the gameshark codes to work. I at one time got Ocarina Of Time working and could see the clarity. But it crashed. I then updated the firmware to the latest. After which...I could not get Ocarina to load again with the gamegenie code
Xdaniel supplied. Anyways still incredible stuff!!! Would have like to add this find to my Ultra HDMI review. Awesome stuff guys!! :-D

 

I'd kill for pre-patched roms for my ED64, or IPS patches to apply myself

 

I was messing with a version of Game Genie Guy that accepted N64 Game Shark codes. It would theoretically allow you to patch these to roms. The N64 is probably the only system I own that I don't have a flash cart for. This would give me an incentive to buy one for sure. Feel free to give this a spin.

http://srktt.com/files/GGGN64.exe

 

This is really interesting. I don't much like the VI deblur on my UltraHDMI as it's just too pixellated for me, but it seems to me that using these codes to remove the filters from the source while still using a CRT could sharpen the image while still retaining that 'organic' CRT look. I'm looking forward to seeing how this looks on my BVM & NEC monitors.

I've never used a Gameshark before so excuse my ignorance:

Will any N64 Gameshark version do?

Also will the Gameshark work with both my PAL & NTSC N64s? (assuming I input PAL codes on the PAL N64 and NTSC codes on the NTSC console).

 

Got some codes working:

Banjo-Kazooie (USA) (Rev A)
802761FD 0000
802761FE 0033
8027622D 0000
8027622E 0033

Castlevania (USA) (Rev B)

800A28CD 0000
800A28CE 0033
800A28FD 0000
800A28FE 0033



And those I wasn't able to make it work (using 8bit or 16bit codes). Someone could test those?

007 - The World Is Not Enough (USA) - not working

810D10FC 0000
810D10FE 3312
810D112C 0000
810D112E 3312

*also tried with 32



Castlevania - Legacy of Darkness (USA) - game crashed when selecting high resolution

800BB8BD 0000
800BB8BE 0032
800BB8ED 0000
800BB8EE 0032

*33 causes vertical lines

 

Not sure about the GameShark version, but I can say that I'm using mine (a GS Pro v3.3) on both, an American NTSC N64 and a European PAL machine. Just make sure you use the right codes, with the right games and game versions, on the right system.

 

I had similar problems with Rainbow Six. However it does work fine when you activate the code only once. You can solve it by converting the code into a GS button code:

880D10FD 0000
880D10FE 0032
880D112D 0000
880D112E 0032

Wait until you are in the first level. Then push the button on the GameShark and the code will be activated for one time.
The difference between a standard code and this code is, that it will be only executed when you press the button. A standard code will be executed continuous. Overwriting the values over and over again might cause trouble with some games.

The disadvantage with the GS button method is, that you might have to push the button again in the next level or after a cutscene.

 

@xdaniel - Thanks for that

 

more GameShark codes:

Forsaken (PAL):
80028E5D 0000
80028E5E 0032

Goldeneye (PAL)
8102316C 0000
8102316E 3216
8102319C 0000
8102319E 3216

Mario Kart 64 (PAL):
810EB51C 0000
810EB51E 3216
810EB54C 0000
810EB54E 3216

Mario Kart 64 on an LCD Monitor with cheat code enabled:


Mission Impossible (PAL):
800904ED 0000
8009051D 0000
800904EE 0032
8009051E 0032

Rainbow Six (PAL):
load first level and then push GS button to activate code
88086C4D 0000
88086C4E 0032
88086C7D 0000
88086C7E 0032

Star Wars Shadows of the Empire (PAL):
810E910C 0000
810E913C 0000
810E910E 3216
810E913E 3216

Twisted Edge Snowboarding (PAL):
80083BAD 0000
80083BAE 0032

 

Aero Gauge (PAL):
80096C9D 0000
80096C9E 0032

Blast Corps (PAL):
I recommend NOT to enter the first 2 lines of codes, because this will result in horrible dithering
8030682D 0000
8030685D 0000
8030682E 0032
8030685E 0032

Chameleon Twist (PAL):
8011524D 0000
8011527D 0000
8011524E 0032
8011527E 0032

Cruis'n USA (PAL):
8013AD9E 0032
8013ADCE 0032

Hexen (PAL):
8006A42D 0000
8006A42E 0032

Mystical Ninja Starring Goemon (PAL):
8007B14D 0000
8007B17D 0000
8007B14E 0032
8007B17E 0032

Pilotwings 64 (PAL):
8024C19D 0000
8024C19E 0032
8024C1CD 0000
8024C1CE 0032

 

Can we Wikify this? I think some site needs to host this. Its sooo awesome!

 

So it seems that the filter/s can be removed to varying degrees - to me, this is a kind of holy grail as you could choose your level of sharpness. So for me, I would want to sharpen the image to a milder degree so it doesn't look over-pixelated like a Playstation game. Do all/most games have the ability to have varying degrees of filter removal? And what would be the method to finding the various levels of sharpness/filter removal in a game - is it just trial and error?

 

If you want to go down the rabbit hole, you can directly manipulate the patcher.asm of n64hijack. ^^

https://github.com/jfktrey/n64hijack/blob/master/patcher.asm
https://github.com/jfktrey/n64hijack

win32 port of n64hijack
http://a.pomf.se/pemhky.zip

Is this fuction really redundant or just called at serveral places. ^^
Maybe we can make signatures of library functions to autopatch roms at all necessary spots.

One problem could be that there were different versions of the devkit used in the wild over the years.

 

The N64 uses 2 processors, the main MIPS CPU and a co-processor. The gDPSetRenderMode command is a co-processor 'microcommand' and those didn't change too much throughout the lifespan of the N64. The way that you would control the co-processor is by sending it lists of microcommands which would set various modes, create vertices etc.

Anyway, there weren't too many microcode versions. There was one called F3DEX for which the gDPSetRender mode command is 0xB900031D followed by another 32-bit value indicating the settings - this version of microcode was used in e.g. Super Mario 64. Later games, e.g. the Zelda games, used F3DEX2, for which the same microcommand was represented by 0xE200001C, again followed by a 32-bit value indicating the desired mode.

There are a bunch of constants that define the possible values for the 32-bit mode, but it looks like AA is bit 3. From the SDK:
#define AA_EN 0x8

The reason there were so many of these commands is not due to redundancy though. It is because each object that is drawn on screen may have its own particular render settings, which would need to be set before drawing of that object started.

Patching the display list gDPSetRenderMode commands in the ROM to disable AA may be able to get rid of internal AA, but it won't disable external AA. External AA was controlled by OS functions (osViSetMode and osViSetSpecialFeatures) which, as you mentioned, changed a lot during the N64 lifespan. However, in each version of the OS, these functions *should* ultimately reduce to a single point where the 0xA4400000 register is modified with the new settings, so we may not necessarily need to identify the osVI* functions and patch them. We would just need to find that one instruction that changes the settings and patch it.

One more thing though - some games (e.g. Ocarina of Time) did some compression. If the library calls that change the settings are compressed, patching becomes more complicated, and it makes a general solution that can patch all ROMs impossible.

 

Thanks very much

 

Here is another comparison of the different settings:

Jet Force Gemini (PAL) 00013016


Jet Force Gemini (PAL) 00003216


Jet Force Gemini (PAL) 00013316


With N64 Utilities Ver. 3 it's possible to dump the N64 VRAM. I've dumped the VRAM for comparison. The picture in the VRAM is not affected by any filters. It does look amazing and I hope that we can get that picture quality out of the N64 in the future

 

here are more codes. btw, if you don't like the dithering effect just remove the lines of code which ends with 0000


Wave Race 64 (PAL):
800EA79D 0000
800EA7CD 0000
800EA79E 0032
800EA7CE 0032

Super Mario 64 (PAL):
80302E8D 0000
80302EBD 0000
80302E8E 0032
80302EBE 0032

Turok 2 (PAL):
800B9D2D 0000
800B9D5D 0000
800B9D2E 0032
800B9D5E 0032

Lylatwars (PAL):
DE000480 0000 (required, otherwise cartridge won't boot)
800C8AAE 0032
800C8ADE 0032

Shadowman (PAL):
8002772D 0000
8002775D 0000
8002772E 0032
8002775E 0032

Yoshi's Story (PAL):
DE000400 0000 (required, otherwise cartridge won't boot)
800AC29D 0000
800AC2CD 0000
800AC29E 0032
800AC2CE 0032

Jet Force Gemini (PAL):
push GS button to activate code
880AA13D 0000
880AA16D 0000
880AA13E 0032
880AA16E 0032

 

i did a bit research and found out, that __osViInit() checks the tv_type at 0x80000300 and store the matching ctrl bytes of OS_VI_XXX_LAN1 in in modep of __osViNext. after that i searched for the first appearance (and checked the following bytes, too) of 0x0000324e (ctrl NTSC_LAN1) and replaced it with 0x0000320e (NTSC_LPN1).

than i recaled the header checksum and guess what, (software) AA was off.

sure osViSetMode can overwrite modep but if it is called with the constants, it might be as simple as patching the videotable.

 

Just a follow up question: The VRAM is inside the Rambus? So it's not hidden away somewhere in the Coprocessor but directly accessable for example by an FPGA? I want that.

 

I've dumped it with the N64 Version 3 Utilities software and a GameShark 3.2: