Recently I posted evidence that you were given the sandcastle code's in Banjo-Tooie, used them in BK to open secret area's and collect items, then Cold-Swap(while power off) back to Banjo-Tooie to recieve the secret item's in your inventory. I then posted that the only way this could be wrong is if any flag-data set by banjo-Tooie was somehow calculated together with the SNS data in EEPROM. You can read about that here:
http://www.rarewitchproject.com/foru...ad.php?t=15609
Note: I only have shark-food island raised here.
Anyways, I have found what seems to confirm 100% that any data written to the sandcastle code on startup come's directly from EEPROM(save-chip on cart) without any additional calculations being done.
Let's start with the evidence found in the Assembly code that write's to the SNS Address.
Code:
8026Fc04 LWR T9, 0x0007(T6) `Loads sns value from 8026CFC8 BEQ R0, R0, 0x8026CFE0
80285da8. The opcode before this 8026FC00 LWL T9, 0x004(t6) also loads from this address.
8026FC08 SW T9, 0x004(T7) `Stores the sns value to address 0x8027BC2C
8026FC3C LBU T4, 0x002c(T4) `Loads the SNS VAlue from address 0x8027BC2C to register T4
8026FC40 SB T4, 0x0000(T5) `Stores the SNS value to sns address 0x80283400
If you don't understand Assembly language, then allow me to explain it clear and simple. This is all you need to know: "The SNS Variable is initially written to 8026FC05 in RAM(Random Access Memory)"
Okay good, so we have our SNS Variable sitting in memory at 8026FC05. But let's see what happens before it was written to that spot in memory...
http://i177.photobucket.com/albums/w...123/SnsAsm.jpg
So look at the command that the arrow is pointing to. This is the last command called before the SNS value is written to the SNS Address. Now if you don't understand ASM that command is telling the system to store the value in T9(0x1fc007c0) to address T0+0x4(0xA4800004).
Now, 0xA4800004 sure isn't an address in RAM. I believe it is an address in the tiny SPMEM. Anyway's the point here is that apparently the SNS Value doesn't appear to be loaded from RAM. If that's the case, then it has to be loaded directly from EEPROM -> 0x8026CFC8 in RAM. Leaving little question of any Flag data being calculated with that value.
However if Subdrag, Icemario, or Coolboyman had a quick look(just to be safe) that would be great.
Evidence 2:
If you try to change the initial value written to the SNS Address, the code will revert to 0 meaning that you wouldn't have any of the areas unlocked or items collected.
This tells me two things. One, that there is some sort of Checksum which means that if the SNS Value being written to RAM isn't the same as the data in EEPROM, then the N64 flags that data as corrupt and clears it from RAM and EEPROM. Two, it would probably be impossible for flag data to combine with EEPROM because it would fail the checksum by having the new data differ from the data found in EEPROM.
Evidence 3:
Finally, I have figured out where SNS data is stored to in the EEPROM file.
First, take a look at this picture:
http://i177.photobucket.com/albums/w.../SnsEEprom.jpg
The addresses I'm showing here can be found in the EEPROM file (.sav in nemu). I'm showing two different instances here, the top image show's SNS data with Sharkfood Island Raised, and bottom shows both sharkfood island raised and pink sns egg collected.
The green value is our SNS variable and it appears the same as it does in RAM. More importantly, in the red is our check-sum values. Again, the SNS Value will need to match the Check-sum values or the check-sum will fail and all SNS data will be deleted.
Also, I can confirm that the flag data set by Banjo-Kazooie(starts at 0x803fff00 in ram) uses the same type of check-sum value technique. That way, Banjo-Tooie wouldn't use any corrupt flag data on startup.
So there you have it, I'm pretty much confirming it as 99.9% fact that Stop N Swop was only a One-way swap process. Now Rare just needs to admit it
.
Here is how it truly worked:
1)Obtain sandcastle codes in BT
2)Enter Code in BK, open secret area
3)Collect secret Item
4)Cold-swap with Banjo-Tooie which would utilize BK flag data.
5)Have item's in inventory.
If I'm correct, then we should finally have all the info we need to successfully re-create our own version of Stop-N-Swop. The only problem is, we would need some type of re-writable N64 cartridge to store a patched version of Banjo-Tooie on. I don't know a great deal of rom-hacking but if someone can make a four-player ocarina of time patch, then it's possible for someone to patch Banjo-Tooie to read and utilize flag data set by Banjo-Kazooie, I'm just not sure how possible