Quick question, will there be anyway to put the code onto an existing adapter that I own without having to buy a new one or no? Just wondering, if I need to buy another adapter it's fine with me but it'd be nice to not have to buy another one.
This should be possible. I use the same schematics for the adapter (on purpose). You would have to cut off the shrink wrap from your Raphnet adapter and temporarily solder a programmer to your pcb. You can get a programmer for 3 bucks from Ebay. If you think you are capable of doing this procedure, please let me know, because it is convenient to get some feedback.
This should be possible. I use the same schematics for the adapter (on purpose). You would have to cut off the shrink wrap from your Raphnet adapter and temporarily solder a programmer to your pcb. You can get a programmer for 3 bucks from Ebay. If you think you are capable of doing this procedure, please let me know, because it is convenient to get some feedback.
I will only supply the binaries for now. I haven't really decided if I am going to release the source code, because I am afraid people will start modding it, to make ess even easier. I don't know how the community would feel about mods like this, so I will wait with releasing the source code a bit. It also shouldn't really be a problem if I don't release the source code when people agree the adapter does its job well.
Do you already have the equipment to program it? You need an isp programmer for this. If you need help with any of this, please let me know. I can't guarantee that my code will work with Raphnet's pcb, but I am 99% sure it will, because his code also worked on my own pcb.
I'll upload the binaries when I am on my laptop. It would be really nice to get some feedback from a more experienced Zelda player. :)
I would also like to have the binaries. I already have an adapter so if it's relatively easy to insert the binaries into my own adapter then I'd like to do that so I can play VC with good controls ASAP.
I will only supply the binaries for now. I haven't really decided if I am going to release the source code, because I am afraid people will start modding it, to make ess even easier. I don't know how the community would feel about mods like this, so I will wait with releasing the source code a bit. It also shouldn't really be a problem if I don't release the source code when people agree the adapter does its job well.
Do you already have the equipment to program it? You need an isp programmer for this. If you need help with any of this, please let me know. I can't guarantee that my code will work with Raphnet's pcb, but I am 99% sure it will, because his code also worked on my own pcb.
I'll upload the binaries when I am on my laptop. It would be really nice to get some feedback from a more experienced Zelda player. :)
If people really want to cheat they will. Hiding your source is just going to make it a tiny bit harder, and make it far less likely anyone will consider the possibility when someone just rewrites it their self.
Here are the binaries. These should work with the Raphnet adapter that has an ATmega8 microcontroller. If any of you guys have an ATmega88 version, then I'll try to port the code asap.
I'll post some explanation and images of how you can reprogram your Raphnet adapter later.
Allright here are some instructions for if you want to reprogram your Raphnet Adapter yourself:
To reprogram your adapter you need an isp programmer. You can get one for four bucks here.
Once you have received your programmer you need drivers for it. You can get them from this page. Also, you are gonna need a program to be able to program your adapter. I recommend using Khazama AVR Programmer.
To be able to program your adapter you are gonna have to carefully remove the heat shrink from it. Once you have removed it, you have to verify that your adapter uses an ATmega8. You can verify this by looking at the text on the chip. If you turn out to have an ATmega88, then let me know and I will try to port the code for your adapter, but as long as no one has an ATmega88 version I do not plan on porting the code.
Now that you have a bare PCB, you are gonna have to connect the programmer to your PCB. I recommend putting some solid metal core wires (stripped of course) into the connector from the programmer and solder the other side of wires to the corresponding pads of the PCB. There are six different wires you have to connect: VCC, GND, MOSI, MISO, SCK and RESET. VCC and GND probably have some wires connected to them already. These will have to stay either connected or have to be reconnected once you are done programming the adapter. Here are two images that show where these connections are positioned on the connector from the programmer and the PCB:
PCB with pads that need to be connected to the programmer: Original image
Once you have everything connected it's time to start Khazama AVR Programmer. I'll post a video soon demonstrating the steps you need to take. Basically it goes like this: first thing you do is check if you are able to read the chip's signature, so you can be assured that everything is working and connected correctly. After this you are ready to program the .HEX which can be found here.
Once your adapter is programmed there is a big chance the analog stick acts really weird. This is because you first have to select the preferred mapping. You can do this by holding the d-pad while plugging in the adapter. D-up is for OoT and D-down for MM. :P
I successfully programmed mine. The Ocarina of Time controls feel perfect aiming and ESS angle changing are very easy. Majora's Mask still feels a bit too sensitive, angle changing is still pretty difficult (I know the ESS range is small on N64 too, but I don't usually have trouble doing a HESS with angle changing on that). Aiming is fine though.
Hm... maybe try both mappings for MM and see if the other one works better?
I should really get a programmer and do this mod myself. Only thing is I'm afraid of soldering the wires :(
It's about the same. I can do it with angle changing, it's just marginally more difficult than OoT. Also, using the OoT mapping in MM causes weird things like being unable to backflip.
It's about the same. I can do it with angle changing, it's just marginally more difficult than OoT. Also, using the OoT mapping in MM causes weird things like being unable to backflip.
OoT mapping indeed doesn't work for MM.
I'll have another look at MM. I can verify if the ess range is still the same, because I wrote a program that is able to send fixed analog stick values to my Wii. That way I am able to check for which GC value Link starts and stops turning. I can also check these values for the N64 version with an emulator and that way I can compare them and see if they correspond in the mapping table. I am pretty sure I did this last time, but it's been some time. I will check this for US version first.
I can also change the mapping table and make ess just as easy as on Ocarina of Time, but I don't know how people would feel about this.
Edit: maybe you just need to get comfortable with VC? I can imagine VC feels different from the N64 version in general.
I think I have figured out what is wrong with Majora's Mask. It's pretty awful, but don't worry, because it is fixable and I fixed it already in the sense that I am able to angle change really easy now. Basically Nintendo has a different mapping for when you hold your analog stick diagonal. I have confirmed this by sending fixed analog stick values to my Wii (with the mapping table I can then lookup which N64 value would actually be held) and see when Link starts and stops ess-ing. I did the same on an N64 emulator with a TAS plugin. The values I acquired didn't match. With the current mapping table when you hold diagonal you don't have to push the analog stick as far as on the N64 version. I checked the distance the analog stick would be removed from the center for when Link starts walking and in a lot of cases Link already starts walking for a distance of 20. On the N64 version I checked this and it was more like a distance of 30. In Majora's Mask Link starts essing when you only change one axis at a value of 16. What this means is that when you are gonna angle change you are gonna cross the x-axis and you have like a distance of 4 as a margin of error, which is way too less. I hope this is clear, but it probably isn't.
Making the field of ess-ing bigger in the mapping table isn't gonna work. The mapping for the diagonals is just too different, which means that the diagonals just expect way different GC values than the normal x- and y-axis, so it would never fit in one mapping table.
Right now I am fixing this problem by checking if the analog stick is held diagonal and accounting for what I send to the Wii. With this I am able to angle change really easy. During the writing of this post I came up with another method: a corrected mapping table for the diagonals. That last option will probably be easiest and best.
Hm... maybe try both mappings for MM and see if the other one works better?
I should really get a programmer and do this mod myself. Only thing is I'm afraid of soldering the wires :(
It would be really convenient if you were able to program your adapter. It isn't very hard and the adapter is pretty useless with the Raphnet code for the Zelda games. I am pretty sure your feedback is one of the best I can get. Perhaps you know someone that can help you solder it?
Edit2: above one isn't that good either. Right now I am gathering some data and plotting some graphs, to figure out how I can fix this nicely. This will take some time, because I am also pretty busy with university, or at least should be lol.
Screw it, I want this working well so badly that I tried to fix it just now. Here's a link to the version in which even I can angle change really easily in mm.
Edit: It worked at first, then it didn't work anymore after rebooting. Got it working now. It was just bad programming. I'll upload it once I have tested it a little better.
I still need to play around with it some more, but as far as HESS goes -- that one was practically perfect.
The one I have right now is much better in my opinion and the fix actually makes sense. The one I sent to you was just guessing some values and finding out what works. I'll upload the new one very soon, once I have tested it a little more, I don't want you to flash something that gives really weird issues like it did for me yesterday.
Allright, I have tested and improved the last one, which I ended up taking offline. ESS region is pretty big on this one, and you don't have to hold the control stick as far as on the N64 version, it's almost like in OoT now. The older versions also suffered from being way more responsive when you held the analog stick diagonal. Basically this means that when you aim and you hold diagonal the response is way different from holding straight up, down, left or right. I account for this so that it doesn't react so heavily when you hold diagonal.
My thoughts on this version: ESS is really easy now probably and easier than on N64. Aiming is also pretty good, but it will never be as good as on N64, but a million times better than on VC. I fix a lot of stuff using an algorithm that checks how far the stick is away from its center and the value of the angle the stick is making, and sending different values to the Wii based on that. Because of this you might notice a little that when you aim your stick transitions from a certain state. It's not really that bad and it's still much better than on VC, as already said. I might look if I can have these transition zones a little more detail to them, so it's not noticeable at all anymore.
ESS is really easy now probably and easier than on N64. Aiming is also pretty good, but it will never be as good as on N64, but a million times better than on VC.
I don't know if I like this. The whole point of the mod was to make the VC controls at least closer to N64 controls. If we end up making it easier than N64 controls then I would argue that it gives an unfair advantage.
I don't know if I like this. The whole point of the mod was to make the VC controls at least closer to N64 controls. If we end up making it easier than N64 controls then I would argue that it gives an unfair advantage.
I suppose that's true. One of the reasons I made it easier, was because I am not very good at the angle change in MM, so it would be kinda hard to verify if it's working well. I am pretty sure I can make the ess region smaller again, but a lot of unpredictable stuff happened before, so I am kinda scared to make any claims. :P
Edit: just tested it. If I change the settings so that Link will be in ess position when the stick has a distance from 16 till around 30 (these are approximately the values on N64) from its center I can still do the angle change fairly easy. Once again, I agree it's a bit fishy to make ess extremely easy. I'll wait untill Pheenoh has tested the most recent one I posted and if he likes it I'll let him try the one I just tried that is closer to the actual N64 version.
Hi. Sorry, I was busy yesterday. I've been playing with this one for a few hours, and it feels a bit tighter than the one you removed, but it's still really easy to angle change. In regards to it being easier than N64, I can't really say. If it is easier, the difference is so small I can't tell.
Allright, made the ess range more like on the N64 now and angle changing still no problem. Right now I am gonna try to make aiming better. Aiming will probably stay a little different from N64, but it's still beter than with GameCube controller.
ING, any chance you might still want to try to program yours? Your feedback would be pretty convenient. If you don't want to risk it, I fully understand though.
Thanks for the feedback so far by the way, Pheenoh. :)
I'll try to program my adapter, but I can't make any promises on when I'll be able to do so.
If you need any help, just let me know. If I would have to build you an adapter first it would take much longer, because getting the PCBs fabricated would take a few weeks already (the one I show in the video that I built myself is very fragile, so I wouldn't want to send that to someone).
I don't know if I like this. The whole point of the mod was to make the VC controls at least closer to N64 controls. If we end up making it easier than N64 controls then I would argue that it gives an unfair advantage.
Right, because having less lag is totally not an unfair advantage. ::)
Allright, just confirmed with a memory editor that the mapping for MM isn't as simple as just translating the X- and Y-axis individually. When I have the value on the Y-axis on the Dolphin TAS plugin with Majora's Mask fixed and I start moving the X-axis the value for the Y-axis will increase. This is basically already what I thought the problem was. I might have a new approach of fixing this than I had before. It would be to gather a lot of GameCube X and Y-values and the corresponding X and Y-values for N64. If I would then calculate a function that (if this is possible) approaches the gathered data, it could become a really nice mapping. I think that when I have a lot of data from the ess positions, this should work very well hopefully. This will take some time, but I think it's the best solution if it works.
I want to step away from a mapping table, because with a mapping table I will have to hardcode some stuff to keep the ess-region. This is a pretty arbitrary process and I find it very hard to make aiming feel good when you hold your controller in ess position, or when you go from ess position to walk position.
Edit: just a quick update. Just did some thinking on this. If I would want to do it with a mapping table I would need to make one that is 70x70 bytes. This doesn't fit in the RAM from the chip, but it could possibly fit into the flash memory. Right now I am busy writing a program that retrieves all the memory data I need. With this a 100% correct mapping should be possible, if we ignore the N64 values that are lost in the conversion project, since the GC stick only uses about 40% of the possible values. I hope this works, cause in theory it would be perfect.
I also cancelled the pcb designing for the adapter for now, because it could change, if it were to turn out that it doesn't fit on the chip. In that case I would have to get a new chip. Sorry if this project is starting to take a little long, but I want to do this as good as possible.
OK, I think I've got it. Here's a long story so people can see if it makes sense that I think I have fixed it:
Basically the N64 X and Y-value were dependent on both the GC X- and Y-value. This basically means that when, for example, you hold the Y-axis in position 30 on GC (which is 16 on N64) and you start moving over the X-axis, the N64 Y-value will change with it, even if your GC Y-value is still the same. What I did to fix this was make a lookup table of 70 times 70. In this table all GC-values are listed that correspond with the N64 value. I can use this really big lookup table for both the N64 X-axis and Y-axis, because the transformation to GC is symmetrical. The lookup table is 70 times 70, because this way it fits. Link will be running at full speed when you hold your N64-stick at value 70 anyways, and higher values just take the GC value at N64 place 70.
I got the mapping table by writing a program that would change the value of the GC analog stick in the Dolphin TAS plugin and then read out the N64 X and Y-values. When I got all this data a problem occured. A lot of N64 combinations don't exist. For example, combination N64 X=10 and Y=11 could very well not exist in the VC MM version. All the N64 combinations that did not exist were zero in the lookup table, so I somehow had to put in the best possible data in there. I wrote a little algorithm that checks which values are zero and then looks which N64 combinations do exist and chooses the one that lies close and has about the same angle.
After all this worked I tested it and aiming is super good now and the margin you have for superslides feels about the same as on my N64 PAL MM cart. Angle changing is also easily possible. I will check later if the region of ess is the same as on N64, by sending fixed GC analog stick values to my Wii and check when Link starts to turn.
The hex is here. Pheenoh, before you try this one, try the older one one last time and see if aiming when you hold your analog stick in ess position makes any sense and then try it with the new one. :P
Yeah, the aiming feels alot less awkward now (it had good control on a small scale, but was pretty sensitive once you pushed the control stick all the way in one direction). HESS/angle changing and leniency on the diagonals feels close to the same (it's tighter than the one similar to OoT but still easily manageable). Are you gonna do a large mapping table for the OoT one too? I finally sat down and put in some time with one of the older mappings and realized the aiming was a bit strange, despite my first impression.
Yeah, the aiming feels alot less awkward now (it had good control on a small scale, but was pretty sensitive once you pushed the control stick all the way in one direction). HESS/angle changing and leniency on the diagonals feels close to the same (it's tighter than the one similar to OoT but still easily manageable). Are you gonna do a large mapping table for the OoT one too? I finally sat down and put in some time with one of the older mappings and realized the aiming was a bit strange, despite my first impression.
I'll have a look if OoT acts the same as MM, meaning the X and Y-values are dependent. If this is the case then I'll do the same as for MM. I actually doubt that the X and Y-values are dependent in OoT, but we'll see. Only problem is that two big mapping tables won't fit on an Atmega8. This would mean the raphnet adapters wouldn't be able to use the best conversion possible, but of course the .hex file in my last post can be used. As for my own adapter that I'll hopefully will be producing any day soon, I'll just choose a chip with larger memory, since the extra costs aren't that high anyways.
Just confirmed it: X and Y-values are also dependent in OoT; if you have a fixed GC X-value and you start changing the GC Y-value, the N64 X-value will also change. It's a lot less worse than in MM though, but definitely something worth fixing. What the hell, I never expected this was the case for OoT too. Next update will probably be a new mapping table for OoT. It will not include MM since it won't fit.
