Hi. Any1 knows what kind of protection the game conkers bad fur day have ? the cic bootcode is 6105, when im converting it to 6102 it still not working, cant find any cracks at dextrose or anywhere else. Thanks
i think you had to use one of these carts as bootcart to make it work: Donkey Kong 64 Jet Force Gemini Kiosk Jet Force Gemini Legend of Zelda: Ocarina of Time, The Perfect Dark no crack as i recall.
You can't just dump the 4k 6105 bootcode at the beginning, most RARE titles have tons of checks throughout the code that will stop the game if it doesn't see a real 6105.
Conkers on the Gameboy had an interesting bit of design. Rare needed more than 8K of work-RAM but less than 8K save-game space so they used some of the save-game RAM. Nintendo were non too keen and insisted that the coders read 1 byte in every 256 to do some kind of refresh (it must of been battery-backed RAM and they were forcing a refresh I assume).
SRAM runs at the same speed as work RAM, they're actually the same chip. ??? about refresh, the whole point of SRAM is that it doesn't need refreshing.
Smell more like them (nintendo) trying to make sure it was harder to copy the hardware than any kind of refresh. SRAM do not require refresh at all.
SRAM was, I assume, DRAM with a battery so it does need refreshing. I know on the C64 that a page was 256 bytes (so 256 pages) and you could mess with the HBlank to mess up the refresh. Result, memory lost. I only know what I was told by the guy who wrote the engine. Dont forget, Nintendo and Rare were in bed together. On the other hand, Nintendo often ask for odd things. Remember that save games cannot use vowels because it may spell out a rude word! On the N64, Rare were, initially, the only people allowed to reprogram the RCP so they could, initially, write faster games than anyone else. I suggest someone takes apart Conkers and takes a look, that way not disputes can arise.
Initially RARE was the only developer granted access to the microcode tools (which were reportedly extremely poorly documented and obscenely hard to use) However I know of three others, Factor 5 wrote their own rendering microcode specialized for texture streaming and terrain generation for Rogue Squadron and Battle for Naboo. They also did the Indiana Jones game. BOSS Games wrote World Driver Championship (IMHO the only realistic N64 racer) which allowed them to not only draw twice as many polygons but also decode mp3 music in real-time. Finally Angel Studios wrote a MPEG-1 video decoder for the RSP which allowed them to fit nearly all the cutscenes for Resident Evil 2 into 64Mbytes of cartridge space. The initial Fast3D microcode that all first-gen games shipped with was very precise, and as a result pretty damn slow. Even still, z-buffer accesses and transparency kill framerate. Nintendo addressed this by revising it into the F3DEX and F3DEX2 microcodes. However as Boss Games found out, you could get awesome results by rebuilding it from the ground up. Sacrificing some precision at 320x240 is well worth it for the performance gain.
Yes, they wanted some 'wiggle room' in case they found a way of making the chip-set cheaper. I seem to remember Sony doing the same thing on the Playstation in the early days. You had to do system calls rather than adding in-line assembly code accessing the co-processor. Think how much of a slow down that was. Everyones belover RotTransPersp didn't take 29 cycles, more like 100!
Thanks. I bought some of the games you've mentioned simply because of the optimizations used in the game.
