I got refered here, otherwise would never have noticed this.
In an NGEE ROM, memory from 80020D90 - 8005D2E0 is compressed in a file spanning 0x21990 - 0x331E0. This is simple z compression with a nonstandard header, called RareZip internally, and you can de/compress using either the RareWitchProject's standalone tools or the GoldenEye Setup Editor. You'll have to hex it yourself.
However, you don't understand the no-intro code. The code simply allowed you to trigger the "yes the intros have run so please allow me to press buttons to skip to the folder select" flag that does the same. You can not (on a stock ROM) get past the legal screen. This value is handled at runtime and is reset via code.
+_+
The problem is likely more intrinsic. If you can get me addresses of what dies and when, I could tell you precisely what's wrong.
Detecting what's wrong:
If it's TLB support, you won't make it far. The TLB is first established at 80000450. Your first TLB jump is at the end of it, to 70000510. The first jump to a 7F- address is 7F000BD0 at 70005D58, which may cause an issue with imperfect TLB support since this draws a ROM address, not mirrored rdram.
There's three TLB regions set, at least. 70000000-70400000 mirrors its 80- counterpart and is read/write capable (dirty). 7F- everything else in 0x2000 parts. ROM correspondance for the latter two are in the "TLB index NGEE.txt" document.
Otherwise, almost all N64 emulators, including Nintendo's official Wii/Gamecube ones (as far as I know) don't emulate the RCP hardware itself. They instead read and process the microcode at a high level. The up-side is that it runs, and at an appreciable rate. The downsides are accuracy, microcode detection, special per-game settings, and seperate processing types for each microcode version.
Problem is that GE and PD both use a hack of the Mario microcode, basically a new quad triangle draw, special indexing for vertices, and a different vertex index pointer type. PD adds in the rgb index type, a slight variation on the vertex index, and most notably a slightly different combiner.
If the microcode is the problem, you'll be able to boot as far as displaying something, which would be one of the jumps around 700063A0. 7F00A5E8 initializes the legal screen, called from 7F01A61C. Not sure if it draws anything prior to that.
If you can get some debug output or the address of where it finally gacks, I could tell you what's wrong. Most of the game loop and boot sequence, up to the menus and probably further, is all nicely annotated ;*)
+_+
An occationally-updated spattering of GE documentation can be found at:
http://two.xthost.info/zoinkity/GoldenEye/GoldenEye.7zIt may help a bit. I really suggest doing searches in the main directory for file contents. It's impossible to find anything otherwise. Still need to clean out old, useless documents.
+_+
As a side note, GE skies and fog do not run on most plugins because they are assembled with the low-level "generated" commands, C8-CF. I should say these are assembled one half-rdp at a time until complete. Reason being that development-wise they coded this crazy 5-sized triangle thing. Makes you wonder.
We's be working on a code rewrite to generate much smaller and managable skies/water using normal tri writes, R. Should be emu-compatible, maybe ;*)