@goodie
Perhaps building this adaptor would allow you to program the PIC12F629 using the 'Extra Low Cost JDM programmer' or 'uJDM programmer': http://www.qsl.net/dl4yhf/winpic/#adapt12f675
I haven't tested this personally, though if it works we'd have an easy way to program both versions of the Cube64.
Getting slightly off-topic here; has anyone ever used a charge-pump like the one described in the Cube64 Mini's documentation? By my understanding it can take in 3.3V and output 5V. If this is the case why isn't anyone using it in their portable?!! Surely this would lower the amount of batteries required, make the entire unit lighter, and give off less heat than a 7805...
Gamecube Controller on N64
Moderator: Moderators
Charge dumps, from what I know (it isn't a whole lot) about them are designed for what they sound like - dumping some voltage over a short period. They usually cannot output a lot of current (>1 amp) and I don't believe they are terribly efficient. Also, I don't think they are really supposed to (or designed to) be run constantly.
Now, step up regulators do exist, but for 5V you'd be better off using 4-5 AAs and a good switching regulator than a stepup regulator running off of 2 AAs, because the switching regulator will be fairly efficient and you'll get a longer runtime (because of more batteries).
That being said, it might make more sense to use a step up for 12V (like Ben did with his NeoGeo) just because getting 12V can take a lot of batteries and the weight/space required is often not worth it.
Now, step up regulators do exist, but for 5V you'd be better off using 4-5 AAs and a good switching regulator than a stepup regulator running off of 2 AAs, because the switching regulator will be fairly efficient and you'll get a longer runtime (because of more batteries).
That being said, it might make more sense to use a step up for 12V (like Ben did with his NeoGeo) just because getting 12V can take a lot of batteries and the weight/space required is often not worth it.
Sorry about the double post.
I too would rather have a GC controller in a N64p, but the fact that the memory card is not supported in this mod is a little annoying. So I have a question - is the memory card circuitry seprated from the controller on an N64? That is, can you use a GC controller (using this mod) but also wire up the memory card ciruitry from an N64 controller so that both would be on a portable? This would make using a GC controller on an N64p a shoo-in, as far as I am concerned.
I too would rather have a GC controller in a N64p, but the fact that the memory card is not supported in this mod is a little annoying. So I have a question - is the memory card circuitry seprated from the controller on an N64? That is, can you use a GC controller (using this mod) but also wire up the memory card ciruitry from an N64 controller so that both would be on a portable? This would make using a GC controller on an N64p a shoo-in, as far as I am concerned.
-
usbcd36
- Posts: 1293
- Joined: Sun May 15, 2005 5:04 pm
- Location: Inside Samus's arm cannon [gulp]___ Gender: Male
The power board in the GameCube actually gives off 3.4v and 5v, which results in slightly garbled sound. A resistor might make it work though…dudasquid wrote:Getting slightly off-topic here; has anyone ever used a charge-pump like the one described in the Cube64 Mini's documentation? By my understanding it can take in 3.3V and output 5V. If this is the case why isn't anyone using it in their portable?!! Surely this would lower the amount of batteries required, make the entire unit lighter, and give off less heat than a 7805...
Are you sure it wouldn't work with the PIC12F629? The site seems to say it can. 
EDIT: Hmm, they have this one too. It seems to be a little better, but is $10 more.That site I linked to wrote:We have successfully used this device to program PIC12F629, PIC16F627, PIC16F628, and PIC16F84 devices.
mnbvcxzlkjhgfdsapoiuytrewq
@goodie
The programmer you are referring to is the 'JDM programmer', I linked to the 'Extra Low Cost JDM programmer' which is a stripped-down version... Hence the need for an adaptor.
I suppose it would be possible to hack off a memory pak slot and the chip from a N64 controller and wire them in parallel, though I'm unsure that it would work as the original N64 controller's chip would be sending signals that there is no button activity and the Cube64's one would be sending signals that there is... You'd also be faced with the problem of trying to tell the N64 that there is both a rumble pak and memory pak plugged in at the same time... I'll email Micah and ask!
**EDIT**
The memory pak's circuitry probably isn't seperated from the N64 controller's circuitry as it sends all of it's data down the same wire. Why not just rewire a N64 controller's chip and memory pak slot to the player 2 socket?
The programmer you are referring to is the 'JDM programmer', I linked to the 'Extra Low Cost JDM programmer' which is a stripped-down version... Hence the need for an adaptor.
I suppose it would be possible to hack off a memory pak slot and the chip from a N64 controller and wire them in parallel, though I'm unsure that it would work as the original N64 controller's chip would be sending signals that there is no button activity and the Cube64's one would be sending signals that there is... You'd also be faced with the problem of trying to tell the N64 that there is both a rumble pak and memory pak plugged in at the same time... I'll email Micah and ask!
**EDIT**
The memory pak's circuitry probably isn't seperated from the N64 controller's circuitry as it sends all of it's data down the same wire. Why not just rewire a N64 controller's chip and memory pak slot to the player 2 socket?
"He just spends all day shooting off his powerbands to supervillans..."
Setting the facts straight
Hi Everybody,
This is Micah- I designed the Cube64, and did most of the reverse engineering to make it possible. It's great to see so many people interested in it- I built it just for my own use, not really expecting anyone to stumble upon it and try it.
It's also cool to see dudasquid's photos. If anyone's interested in seeing my prototypes and such, I have my original photo gallery on a server with a bit more bandwidth now: http://zero.navi.cx/gallery/cube64
Anyway, I have a few things to add...
Cost: Cheap PIC programmers are good. I do a lot of microcontroller development so I have the $200 whiz-bang PICstart Plus programmer, but the $10 programmers mentioned above will work fine if you just want to build the cube64. I designed the Cube64 Basic to use the extremely popular PIC16F84A processor mostly so that it would be accessible to people without fancy hardware. One thing to note is that you can get free samples of the PICs themselves from Microchip. Just head over to their web site (microchip.com) and hit the 'request samples' link on the products you need. Lots of semiconductor companies do this as a way of encouraging folks to create designs with their chips, assuming that later on these designs will be mass-produced.
Power: The Cube64 Mini uses a tiny but still fairly efficient charge pump. Check out its data sheet if you really care, but it seems to power a rumble motor nicely. It helps that there aren't any sensitive electronics powered by it, so you don't have to worry about ripple. Charge pumps are just one form of DC-DC converter. Most DC-DC converters you hear about are buck/boost converters, which store energy in inductors. Charge pumps are much simpler- they store energy in multiple capacitors, then connect those capacitors in series to get the sum of each capacitor's voltage. This happens very rapidly, so it appears that you get a steady high (or negative) voltage out. Charge pumps are mostly used for low-current applications, like generating the high voltages necessary for an RS-232 serial port or an LCD. A portable console would be better off with a buck/boost converter. You can buy pre-made DC-DC converters if you have money to burn (or you're good at shopping around at surplus stores) but you can also build your own pretty easily using chips from Maxim or Linear Tech.
And I think this is what people have been waiting for...
An explanation of the N64's memory pak support, and how the Cube64 relates to it.
1. Yes, it would be possible to create a cube64 adaptor that lets you plug in memory paks.
2. No, it wouldn't be as easy as you think. I had to reverse engineer the CRC algorithm that's used by the N64 and the controller to ensure reads and writes to the memory pak bus happened successfully. I didn't discover exactly how the N64 hardware generates the CRC, I just discovered an equivalent algorithm that produces compatible results. This equivalent algorithm isn't quite efficient enough to run at the required speed on a PIC microcontroller.
3. With either a much faster microcontroller or some dedicated hardware (on an FPGA) it would be possible to perform the CRC in real-time and provide a memory pak interface along with the existing controller emulation.
4. It would be possible to use parts from an N64 controller as the memory pak interface, but this would require some software changes. Remember that the Cube64 emulates a rumble pak, and the rumble pak attaches to the memory pak interface. The Cube64 *does* emulate the memory pak interface, it just takes some very serious shortcuts that make the emulation good enough for rumble but unsuitable for a real memory-pak. This is why it can avoid using a version of the CRC algorithm that would run too slowly. You would need to modify the firmware to remove all memory pak emulation, and pass through memory-pak related commands to a "slave" N64 controller. The timing on this would be tricky. You'd have to buffer some data, because by the time you know a memory pak command has arrived it's too late to get a response out immediately.
Hopefully this clears up a few things. My email is micah at navi dot cx if you have other questions, or want a better explanation of the controller's internals. Also, the source code includes a directory full of reverse engineering notes- this includes the process I used to emulate the CRC, and some proof-of-concept Python code that implements it.
--Micah
This is Micah- I designed the Cube64, and did most of the reverse engineering to make it possible. It's great to see so many people interested in it- I built it just for my own use, not really expecting anyone to stumble upon it and try it.
It's also cool to see dudasquid's photos. If anyone's interested in seeing my prototypes and such, I have my original photo gallery on a server with a bit more bandwidth now: http://zero.navi.cx/gallery/cube64
Anyway, I have a few things to add...
Cost: Cheap PIC programmers are good. I do a lot of microcontroller development so I have the $200 whiz-bang PICstart Plus programmer, but the $10 programmers mentioned above will work fine if you just want to build the cube64. I designed the Cube64 Basic to use the extremely popular PIC16F84A processor mostly so that it would be accessible to people without fancy hardware. One thing to note is that you can get free samples of the PICs themselves from Microchip. Just head over to their web site (microchip.com) and hit the 'request samples' link on the products you need. Lots of semiconductor companies do this as a way of encouraging folks to create designs with their chips, assuming that later on these designs will be mass-produced.
Power: The Cube64 Mini uses a tiny but still fairly efficient charge pump. Check out its data sheet if you really care, but it seems to power a rumble motor nicely. It helps that there aren't any sensitive electronics powered by it, so you don't have to worry about ripple. Charge pumps are just one form of DC-DC converter. Most DC-DC converters you hear about are buck/boost converters, which store energy in inductors. Charge pumps are much simpler- they store energy in multiple capacitors, then connect those capacitors in series to get the sum of each capacitor's voltage. This happens very rapidly, so it appears that you get a steady high (or negative) voltage out. Charge pumps are mostly used for low-current applications, like generating the high voltages necessary for an RS-232 serial port or an LCD. A portable console would be better off with a buck/boost converter. You can buy pre-made DC-DC converters if you have money to burn (or you're good at shopping around at surplus stores) but you can also build your own pretty easily using chips from Maxim or Linear Tech.
And I think this is what people have been waiting for...
An explanation of the N64's memory pak support, and how the Cube64 relates to it.
1. Yes, it would be possible to create a cube64 adaptor that lets you plug in memory paks.
2. No, it wouldn't be as easy as you think. I had to reverse engineer the CRC algorithm that's used by the N64 and the controller to ensure reads and writes to the memory pak bus happened successfully. I didn't discover exactly how the N64 hardware generates the CRC, I just discovered an equivalent algorithm that produces compatible results. This equivalent algorithm isn't quite efficient enough to run at the required speed on a PIC microcontroller.
3. With either a much faster microcontroller or some dedicated hardware (on an FPGA) it would be possible to perform the CRC in real-time and provide a memory pak interface along with the existing controller emulation.
4. It would be possible to use parts from an N64 controller as the memory pak interface, but this would require some software changes. Remember that the Cube64 emulates a rumble pak, and the rumble pak attaches to the memory pak interface. The Cube64 *does* emulate the memory pak interface, it just takes some very serious shortcuts that make the emulation good enough for rumble but unsuitable for a real memory-pak. This is why it can avoid using a version of the CRC algorithm that would run too slowly. You would need to modify the firmware to remove all memory pak emulation, and pass through memory-pak related commands to a "slave" N64 controller. The timing on this would be tricky. You'd have to buffer some data, because by the time you know a memory pak command has arrived it's too late to get a response out immediately.
Hopefully this clears up a few things. My email is micah at navi dot cx if you have other questions, or want a better explanation of the controller's internals. Also, the source code includes a directory full of reverse engineering notes- this includes the process I used to emulate the CRC, and some proof-of-concept Python code that implements it.
--Micah
Re: capacitors
goodie:
The schematics mark polarized capacitors with a (+) on one side, non-polarized don't have this. All the capacitors in the cube64-basic are non-polarized, and should be ceramic. Please remember the 0.1uF decoupling capacitor. It should be placed as close to the PIC's power pins as practical. This is a common practice used to isolate individual chips in a digital circuit from power supply noise.
In the cube64-mini, the 0.1uF decoupling cap and the crystal load capacitors (the ones in the picofarad range) are still ceramic. The three polarized caps (C4-C6) can be electrolytic. You may want to make C6 a Tantalum cap if you can. I forget whether it's required by that particular charge pump, but since it's only driving a motor it probably doesn't matter too much whether you make it tantalum or a regular electrolytic.
--Micah
The schematics mark polarized capacitors with a (+) on one side, non-polarized don't have this. All the capacitors in the cube64-basic are non-polarized, and should be ceramic. Please remember the 0.1uF decoupling capacitor. It should be placed as close to the PIC's power pins as practical. This is a common practice used to isolate individual chips in a digital circuit from power supply noise.
In the cube64-mini, the 0.1uF decoupling cap and the crystal load capacitors (the ones in the picofarad range) are still ceramic. The three polarized caps (C4-C6) can be electrolytic. You may want to make C6 a Tantalum cap if you can. I forget whether it's required by that particular charge pump, but since it's only driving a motor it probably doesn't matter too much whether you make it tantalum or a regular electrolytic.
--Micah
-
nos_slived
- Higher Idiot
- Posts: 3476
- Joined: Mon Mar 21, 2005 6:32 pm
- Location: Burnaby, BC, Canada
- Contact:
Cube64 was basically a two-weekend project, with most of that time spent on reverse engineering. A month later I went back and designed the Cube64 mini (after I got tired of running power cables for rumble...)
As for connecting any controller X to any console Y, I did start a "Unicone" project that would pretty much do this. It was an FPGA-based Universal Controller Emulator. It's still in its early stages and I haven't worked on it in a while, but I do have a working Gamecube controller core for it. I was able to plug the Unicone into the Gamecube, the controllers into a Gamecube to USB adaptor I designed, then connect the controllers to the console over Ethernet. Still plays nice and fast over a LAN, and we can enjoy a game of Mario Kart without controller wires traversing the living room
Here is a quick timeline, from looking back on the Subversion commit logs:
<b>Friday June 4, 2004:</b>
Project started
<b>Saturday June 5, 2004:</b>
N64 controller emulation starts to work on some games.
Implemented button mapping.
Discovered that at least partial memory pak bus emulation is necessary for most games to start up properly.
Started reverse engineering the memory pak bus.
Drew the original schematic.
<b>Sunday June 6, 2004:</b>
Lots more reverse engineering. This is when I ripped apart an N64 controller, soldered a bunch of pins to it, and spent the day with one of the school's logic analyzers...
<b>Thursday June 10, 2004:</b>
Finished a small-table-size version of the reverse engineered CRC algorithm. This one fits in the PIC's memory, but is still a little too slow.
<b>Friday June 11, 2004:</b>
Successfully reverse engineered the smaller error detection code that protects addresses in memory pak read/write commands.
<b>Saturday June 12, 2004:</b>
Wrote some tools to read and write data on a real N64 controller's memory pak. Did a tiny bit of saved game reverse engineering for fun.
Implemented the first working rumble pak emulation!
<b>Saturday June 19, 2004:</b>
Implement button remapping and calibration support, with preferences saved to the onboard EEPROM.
<b>Saturday July 3, 2004:</b>
Finished a port to the PIC12F629, renamed the existing design "cube64 basic" and the smaller one "cube64 mini".
As for connecting any controller X to any console Y, I did start a "Unicone" project that would pretty much do this. It was an FPGA-based Universal Controller Emulator. It's still in its early stages and I haven't worked on it in a while, but I do have a working Gamecube controller core for it. I was able to plug the Unicone into the Gamecube, the controllers into a Gamecube to USB adaptor I designed, then connect the controllers to the console over Ethernet. Still plays nice and fast over a LAN, and we can enjoy a game of Mario Kart without controller wires traversing the living room
Here is a quick timeline, from looking back on the Subversion commit logs:
<b>Friday June 4, 2004:</b>
Project started
<b>Saturday June 5, 2004:</b>
N64 controller emulation starts to work on some games.
Implemented button mapping.
Discovered that at least partial memory pak bus emulation is necessary for most games to start up properly.
Started reverse engineering the memory pak bus.
Drew the original schematic.
<b>Sunday June 6, 2004:</b>
Lots more reverse engineering. This is when I ripped apart an N64 controller, soldered a bunch of pins to it, and spent the day with one of the school's logic analyzers...
<b>Thursday June 10, 2004:</b>
Finished a small-table-size version of the reverse engineered CRC algorithm. This one fits in the PIC's memory, but is still a little too slow.
<b>Friday June 11, 2004:</b>
Successfully reverse engineered the smaller error detection code that protects addresses in memory pak read/write commands.
<b>Saturday June 12, 2004:</b>
Wrote some tools to read and write data on a real N64 controller's memory pak. Did a tiny bit of saved game reverse engineering for fun.
Implemented the first working rumble pak emulation!
<b>Saturday June 19, 2004:</b>
Implement button remapping and calibration support, with preferences saved to the onboard EEPROM.
<b>Saturday July 3, 2004:</b>
Finished a port to the PIC12F629, renamed the existing design "cube64 basic" and the smaller one "cube64 mini".
-
S q u e e !
- Posts: 835
- Joined: Wed Feb 16, 2005 11:31 am
- Location: Lost. Are you my mommy?