ShootersForever.com Forum Index

GoldenEye 007 Nintendo 64 Community, GoldenEye X, Nintendo 64 Games Discussion
GoldenEye Cheats, GoldenEye X Codes, Tips, Help, Nintendo 64 Gaming Community


How does a Gameshark actually work?

 
Post new topic   Reply to topic    ShootersForever.com Forum Index -> Console Workshop
View previous topic :: View next topic  
Kerr Avon
007
007


Joined: 26 Oct 2006
Posts: 913

 PostPosted: Mon Apr 04, 2011 2:50 pm    Post subject: How does a Gameshark actually work? Reply with quote Back to top

I have the X-ploder 64 and the Equaliser (I'm a PAL user), and I was just wondering how they worked (not how I should work them, but how they work in relation to the N64). Am I right in thinking that the Gameshark (I'll use that generic name to mean all of them on the N64) is basically a computer that exists independently of the N64, but it (the Gameshark) constantly monitors the N64's RAM, and can write to the RAM without otherwise interfering with the N64 (and the N64 doesn't even know it's RAM has been altered, as the only change is the value that's been altered in the RAM), and can also monitor the N64's joypads, and all of this is both independant of the N64, and totally invisible to the N64 (other than the intended changes to RAM, I mean)?

On the 8-bit computers, their cheat devices used to be much simpler - when the game had loaded (from tape or disc) into RAM, then you'd press the buton on the device, and the CPU would stop what it was doing, store it's present location (and memory bank page information, if needed), page in the ROM of the cheat device, and jump to the start of the code in the cheat device's ROM, which was alway a menu allowing you to insert cheats, save a memory snapshot, return to the current game, etc. When you selected Return [to current game], then the device's ROM was paged out, the memory pages were set as before, and the program counter jumped to the location it was at just prior to the user pressing the device's button, and execution continued as normal, with the host computer totally unaware that it had even been interrupted.

They were relatively very simple cheat devices, and they didn't need to be any more complicated. The host computer's CPU did all of the work, the device was basically just a page of ROM, and another of RAM, with circuitry to allow the swapping of the lower ROM for the new pages both from hardware (via a switch), and from software, and of course when the switch is pressed, the program (game) in the computer's RAM' is suspended as the computer's CPU jumps to the cheat device's ROM routines. These devices were very reliable, and I don't remember offhand hearing or reading about any of them ever playing up or dying.

But I imagine that Gamesharks are much more complicated, as they can monitor and alter memory values constantly, not just when the user calls up the device, and this prompts a few questions:

1) Is the reason why Gamesharks (all types on the N64) are so unreliable - not so much that they are so complicated, but that they are so complicated and so inexpensive (being niche items they have to be as cheap as possible, but their limited sales potential alone would have the reverse effect of making their prices higher, as they'd need to sell for more just to break even). I'd imagine that if cost wasn't a factor then the Gamesharks would have better designs and/or better components, but that's just wishful thinking, of course.

2) Why are Gamesharks so unreliable? Even people who look after their stuff (as opposed to the idiots who think that electronics, and optical discs, are indestructible and so mistreat them like anything) report their Gamesharks malfunctioning or dying.


3) Why does the Gameshake (at least the two I have) not have the needed 4MB of memory (needed for making your own codes) built in, instead of using the N64's expansion pak (which of course means (a) it only works for people who have the pak, and (b) you lose the use of the pak when using it for hacking? Is it just to reduce manufacturing costs of the Gameshark even more?
 
View user's profile Send private message
Dragonsbrethren
Hacker
Hacker


Joined: 23 Mar 2007
Posts: 3058

 PostPosted: Mon Apr 04, 2011 2:54 pm    Post subject: Reply with quote Back to top

All I can say is the N64 GameShark was notoriously poor compared to the ones for other consoles with similar capability. Last I used it my PSX GS was still alive and kicking almost ten years after I bought it. Can't say the thing about any of the ones I bought for the N64. (Think five total.)
 
View user's profile Send private message
radorn
007
007


Joined: 23 Sep 2007
Posts: 1424

 PostPosted: Tue Apr 05, 2011 8:07 pm    Post subject: Re: How does a Gameshark actually work? Reply with quote Back to top

The N64 cheat devices work like this:

When the N64 cart slot has one particular line called /read.
When this like is active, the memory chips on the cart return the data for whatever address the N64 requests.
Cheat carts impose their control on this line to boot. the rest of the lines reach the cart on top directly.
When you power on, this line is not allowed to reach the cart on top so that the cart won't reply to reads and only the cheat cart does so it can run it's program, the menu.
After you boot a game, this line is allowed to reach the gamepak.

When you activate cheats or load the code generator, a loader program is loaded on the N64's ram which captures some of the standard N64 OS calls (the libs from the official SDK) and possibly other hardware signals in order to keep control of the console and do it's thing.
it also loads the cheats in memory.
everything runs within the N64.

The reason everything runs on the standard hardware and also the reason why the cart doesn't include it's own ram is because cart access is VERY SLOW on the N64, unlike on previous cart consoles.
In basic terms the cart is used like more like secondary storage and not for direct execution (there are some complex exceptions to this, but basically that's how things are).

for the GS/AR button and parallel port comms, the cart is just used as a device (like a PCI card on a computer).
The cheat device includes some memory mapped I/O for these things.
It will keep checking for changes in them so it can detect when you press the button or attempt parport comms from a PC.

the unreliability problem comes from poor coding and an unsafe hardware design.
code list is prone to getting corrupted by the menu and when that happens the menu will crumble (not even restore to factory defaults or just wiping it), and you can potentially even corrupt the "firmware" itself.
When any of that happens there's no mechanism to help you restore it, like a small program on a ROM chip (resistant to corruption by software) from which to perform a parport update.
it's probably a planned obsolescence practice. They would restore nonworking ones for you during it's commercial lifetime, but after that, you are alone.

hope I didn't miss anything important
 
View user's profile Send private message
Kerr Avon
007
007


Joined: 26 Oct 2006
Posts: 913

 PostPosted: Sat Apr 09, 2011 8:44 am    Post subject: Reply with quote Back to top

Dragonsbrethren wrote:
All I can say is the N64 GameShark was notoriously poor compared to the ones for other consoles with similar capability. Last I used it my PSX GS was still alive and kicking almost ten years after I bought it. Can't say the thing about any of the ones I bought for the N64. (Think five total.)


I didn't know that there were Gamesharks for the PS1! I'm glad that they aren't anywhere near as unreliable as the N64 ones, though.





radorn wrote:
The N64 cheat devices work like this:

...


That's very informative, thanks. But why is cartridge access so slow? I'd have thought it would be very fast, being (in effect) simply an extension of the N64's motherboard.

And are all types of N64 Gameshark so unreliable? Is it just the official Gameshark, or the Equaliser and the X-Ploder (and any other type?) too?
 
View user's profile Send private message
radorn
007
007


Joined: 23 Sep 2007
Posts: 1424

 PostPosted: Sat Apr 09, 2011 1:20 pm    Post subject: Reply with quote Back to top

because it's cheaper and it also allows for compression.

the n64 has a fast mechanism to transfer data from cart into RAM, which is DMA (Direct Memory Access) and accounts for the almost non existant load times on N64, but it does load to ram.
The first thing the N64 does after authentication is DMAing the first megabyte of the cart into RAM and execute it (very simplified and probably inaccurate).

The slowness is just a design route that has to do with cost.
it's cheaper to manufacture a cart with fewer lines, a memory chip with no separate data and control lines, and which can also be relatively smaller thanks to the fact that you can compress data and decompress it in software without adding decompression hardware to the cart or console.

Cartridges with the same design style as earlier systems (meant to be accessed directly for execution) and with the size needed for N64 games would be VERY expensive and probably wasteful.
 
View user's profile Send private message
Kerr Avon
007
007


Joined: 26 Oct 2006
Posts: 913

 PostPosted: Sun Apr 10, 2011 6:42 am    Post subject: Reply with quote Back to top

radorn wrote:
because it's cheaper and it also allows for compression.

the n64 has a fast mechanism to transfer data from cart into RAM, which is DMA (Direct Memory Access) and accounts for the almost non existant load times on N64, but it does load to ram.
The first thing the N64 does after authentication is DMAing the first megabyte of the cart into RAM and execute it (very simplified and probably inaccurate).

The slowness is just a design route that has to do with cost.
it's cheaper to manufacture a cart with fewer lines, a memory chip with no separate data and control lines, and which can also be relatively smaller thanks to the fact that you can compress data and decompress it in software without adding decompression hardware to the cart or console.

Cartridges with the same design style as earlier systems (meant to be accessed directly for execution) and with the size needed for N64 games would be VERY expensive and probably wasteful.


I see. I've never seen this information elsewhere, so I doubt it's common knowledge, I imagine most people just assume (as I did) that the N64 could read from the cartridge (i.e. the CPU could read from the cartridge) very quickly, I hadn't realised that the CPU was hindered this way, and it was much quicker to copy the area of cartridge code that you wanted to use into RAM then let the CPU access the copy in RAM.

That must have added another layer of work into writing N64 programs. It's no wonder the N64 had such a reputation for being hard to code for.

I wonder if the CPU to cartridge slowdow was a factor in Nintendo's decision to use discs for it's later consoles?

Thanks for the information, mate.
 
View user's profile Send private message
zoinkity
007
007


Joined: 24 Nov 2005
Posts: 1684

 PostPosted: Mon Apr 11, 2011 7:38 am    Post subject: Reply with quote Back to top

That said, quite a few games do execute directly off the cartridge domain, the GS included. There's this annoying snippet of code that does so., marked in the documentation on it.
_________________
(\_/) Beware
(O.o) ze
(> <) Hoppentruppen!
 
View user's profile Send private message Send e-mail
dugg
Agent
Agent


Joined: 18 Feb 2018
Posts: 24

 PostPosted: Sat May 19, 2018 4:40 pm    Post subject: Reply with quote Back to top

Are there any methods to detect the use of a gameshark on N64 console?
Say for example in a GE speedrun somebody used codes to help the Frigate hostages complete faster or spawn Doak in the best spot or the flight recorder in Statue....
Is it possible to look for anything in a video of the gameplay to suggest a gameshark was used?

I know audio tracks can be analyzed but that is usually to detect splicing of videos I think.

Thought I'd inquire. Thanks!
_________________
Any codes posted were discovered by the original discoverer of said codes.
 
View user's profile Send private message
Wreck
Administrator
Administrator


Joined: 14 Dec 2005
Posts: 7197
Location: Ontario, Canada

 PostPosted: Sat May 19, 2018 4:54 pm    Post subject: Reply with quote Back to top

If the player only needs to submit video footage of the level being completed (sometimes accompanied by a webcam for their reaction), than I doubt GameShark could be noticed. Especially for very subtle changes, like those you suggested on randomly positioned objects or characters. Even other things, like increasing the percent chance for a grenade pull. I'm not sure how someone would know a GS was involved in these circumstances.
 
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    ShootersForever.com Forum Index -> Console Workshop All times are GMT - 8 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Cobalt 2.0 BB theme/template by Jakob Persson.
Copyright © 2002-2004 Jakob Persson


Powered by BB © 01, 02 BB Group

 


Please Visit My Other Sites: GoldenEyeForever.com | GrandTheftAutoForever.com

Got kids? Check out my Dora The Explorer site with games and coloring pages!

Our forums feature Nintendo 64 games, GoldenEye 007 N64 New Maps and Missions, GoldenEye Cheats, N64 Emulator, Gameshark, GoldenEye Multiplayer and more!

[ Privacy Policy ]