ToñoGK
Posts: 4
Joined: Mon Jun 08, 2015 9:19 pm

Controller Pak

Thu Jan 26, 2017 6:10 pm

Hi Marshall and guys!

Just wondering if it is possible to emulate the function of the Controller Pak (CP) from the 64drive on a future update.

Some CPs I have don't work anymore (guess I have to change the battery) and I'm using a GC controller adapter, but everytime I have to save the game asks me to insert the CP... making it impossible to play.. for example Turok, if you die it searches the CP file to continue.

User avatar
byc
Posts: 27
Joined: Sat Dec 13, 2014 9:53 am

Re: Controller Pak

Sat Jan 28, 2017 10:59 pm

Good question. It'd be great to not have to rely on a real pak, what with the shoddy clones, expensive originals, and having to replace batteries, etc.

Sadly though I don't think it's possible (or easy). I'm no expert, but I do know that games (or even homebrew software/apps) that use the Controller Pak have to directly access the controller's serial interface. The game can tell when a controller is unplugged, when a pak is removed and inserted, etc.

It wouldn't be easy to emulate that.. It'd either require extensive game-specific hacks (to switch to SRAM for example), or some very clever tricks to make something work for all games.

User avatar
Tim.
Posts: 35
Joined: Wed Aug 27, 2014 11:56 am

Re: Controller Pak

Mon Jan 30, 2017 1:27 pm

I am no expert but I have been trying to find a solution to this very same issue for quite some time. I was using cube64 adapters and then later cube64-dx adapters to use my Gamecube wavebirds with my N64. Intercepting the controller I/O to route data back to some other device will require a hardware modification and cannot be done with the 64Drive alone.

Back in 2011 I asked darthcloud if he could perhaps integrate Memory Pak passthrough into his cube64-dx code. My idea was instead of trying to come up with a method of emulating and reading/writing Memory Pak data to an SD card, just allow the data for the Memory Pak to pass through the cube64-dx and onto a real physical Memory Pak. You could either solder it directly to the adapter or harvest a connector from a controller. This way you can use a single Memory Pak, then use the 64Drive's 'virtual' Memory Pak feature to backup those saves and have effectively unlimited storage.

Original request: https://github.com/darthcloud/cube64-dx/issues/10 (was moved from from Google Code to GitHub back in 2015)

Unfortunately darthcloud has seems to have abandoned the project (he only took up the cube64 project from Micah who never officially released her work but did publish the code: http://scanlime.org/2011/03/cube64-game ... 4-adaptor/) so no further work on this has been done. Perhaps eventually someone will be able to find a way to let us use Memory Paks with our Gamecube controllers without the need to swap controllers every time you need to save/load.

User avatar
marshallh
Site Admin
Posts: 105
Joined: Fri Jun 13, 2014 12:39 am

Re: Controller Pak

Tue Jan 31, 2017 10:36 pm

Yup, Controller Pak is accessed over SI channels which isn't electrically available from the cart slot.

I did start to add a virtual auto-swapping pak for each game in 64drive menu, but there was some reason it would've been dicey. So at least you could have 1 physical pak yet provide each game its own pak.

User avatar
darthcloud
Posts: 1
Joined: Thu Jan 04, 2018 12:02 am

Re: Controller Pak

Mon Feb 05, 2018 10:32 pm

I am no expert but I have been trying to find a solution to this very same issue for quite some time. I was using cube64 adapters and then later cube64-dx adapters to use my Gamecube wavebirds with my N64. Intercepting the controller I/O to route data back to some other device will require a hardware modification and cannot be done with the 64Drive alone.

Back in 2011 I asked darthcloud if he could perhaps integrate Memory Pak passthrough into his cube64-dx code. My idea was instead of trying to come up with a method of emulating and reading/writing Memory Pak data to an SD card, just allow the data for the Memory Pak to pass through the cube64-dx and onto a real physical Memory Pak. You could either solder it directly to the adapter or harvest a connector from a controller. This way you can use a single Memory Pak, then use the 64Drive's 'virtual' Memory Pak feature to backup those saves and have effectively unlimited storage.

Original request: https://github.com/darthcloud/cube64-dx/issues/10 (was moved from from Google Code to GitHub back in 2015)

Unfortunately darthcloud has seems to have abandoned the project (he only took up the cube64 project from Micah who never officially released her work but did publish the code: http://scanlime.org/2011/03/cube64-game ... 4-adaptor/) so no further work on this has been done. Perhaps eventually someone will be able to find a way to let us use Memory Paks with our Gamecube controllers without the need to swap controllers every time you need to save/load.
I started playing N64 again this fall, and made several update to Cube64.

This include the memory bypass feature :)

## [3.1] - 2018-02-05
### Added
- Slot bypass mode. (Fixes #10)
- GameCube joysticks scaling. (Fixes #7)

### Changed
- Ported Python2 scripts to Python3.

## [3.0] - 2018-01-03
### Added
- Support PIC18F14K22 microcontroller.
- Real-time CRC calculation. (Fixed issue #1)
- Axes remapping.
- Layout modifier function.

### Changed
- Configuration menu.
- EEPROM flexibility.

### Removed
- Support PIC12F683 microcontroller.

https://github.com/darthcloud/cube64-dx/releases

This require a new microcontroller. (PIC18F14K22)

I think the adapter is much more useful now, you can remap axis, rumble work in Banjo & golden eye & proper joystick scaling.

User avatar
Tim.
Posts: 35
Joined: Wed Aug 27, 2014 11:56 am

Re: Controller Pak

Thu Feb 08, 2018 11:06 am

Darthcloud,

Thank you again for all your hard work on the Cube64-DX! I've ordered the new PIC required and will be building the new version of the adapter soon. I'll try and do a write-up of the build process, since the old one from Google Code lost its images, and the build is slightly different this time around.

Return to “General”