Works in BIOS, not ingame

[sirjeannot]

Hello,

first thanks for your library, it's really a saver.

Based on your lib and usbhost, I've connected a ps3 controller to the gamecube.
Everything works inside the gamecube bios, but ingame (fzero) no input are registered.

Code is here : https://github.com/sirjeannot/GamecubeBT/blob/main/GamecubeBT/GamecubeBT.ino
The only thing I've changed from the templates:

• the gcwrite is called only when necessary, otherwise I have continuous gcwrite errors (loop probably too slow, based on your previous messages in other issue discussions, but the usb operations are slow :( ) > possible disconnect? I'm trying to get mario football to verify. For the record I managed to send only one keypress right after the controller is connected...
• (PS3BT / USB HOST v2) rather than using getButtonClick (single event) I'm using getButtonPress (trigger event as long as a button is pressed, I don't want to be mashing direction buttons to move around) > should not have any impact

I was wondering if the behavior of the console with the controllers is different within the BIOS and ingame.
I was wondering also if the gcwrite should be called on every loop. If yes, my only way out is to use an arduino for BT, one for the Gamecube and send keypresses on different pins.

Thanks!

[NicoHood]

1. Every Game handles the controller on its own. So polling times are different
2. Mostly you need to answer EVERY call from the console, so the loop needs to be fast
3. USB Host is expensive

I'd recommend using 1 arduino for gamecube communication and use a serial connection with a lot of (custom) error connection to transfer the data from a 2nd arduino. For example:

Arduino with USB:

1. Poll usb data
2. Send Data to 2nd arduino with a start/stop mark + checksum
3. Repeat

Arduino with gamecube connection:

1. Discard serial buffer (read until nothing is available)
2. Read serial data until a valid package was received
3. Talk with the gamecube
4. Repeat

You can use up to 2M for serial speed, you must experiment with that. You have to be fast!

[sirjeannot]

Hello,

thanks for your reply.

I did some quick testing with the following (useless) loop (serial at 25000000). When the controller is off I don't get any error. When the controller is on, ... it spits continuously errors.

void loop()
{
  Usb.Task();
  if (!GamecubeConsole1.write(d))
      Serial.println(F("Error writing Gamecube controller."));
}

Using two arduinos was also the last resort idea I had and wanted to avoid.
I was also thinking about using (many) pins to transmit button states, but you mentionned digitalRead/Write are too slow. And it's not a great way to handle R+L.

Anyway I'll give it a shot :)

[NicoHood]

You can use direct port manipulation. You'd need tons of ports for the x/y axis, but thats doable. If done right, this is actually quite handy and SUPER fast, but you'd need a mega and lots of cables.

So you have:

• Complex, but "fancy" Serial option
• Ugly, but nobrainer mega wiring solution

[sirjeannot]

I've attached the GamecubeConsole1.write(d) to timer1 as an interrupt and I get pretty good results. The trick is to get the right timing but so far it works pretty well. Still looking for the right/best values.
so the logic would be calling the function every x ms (so far timer1 OCR1A=70 and prescaler at 1024 works well), and just manage the button values updates in the loop.
I'll post the code once I get satisfying results:

• not too often so USB still works
• not too often so the arduino has time at actually go through the GamecubeConsole1.write(d) routines
• not too late so I don't get disconnects.

in setup()

  cli(); //stop interrupts
  TCCR1A = 0;// set entire TCCR1A register to 0
  TCCR1B = 0;// same for TCCR1B
  TCNT1  = 0;//initialize counter value to 0
  OCR1A = 70;// = (16*10^6) / (70*1024) - 1 (must be <65536)
  // turn on CTC mode
  TCCR1B |= (1 << WGM12);
  // Set CS10 and CS12 bits for 1024 prescaler
  TCCR1B |= (1 << CS12) | (1 << CS10);  
  // enable timer compare interrupt
  TIMSK1 |= (1 << OCIE1A);
  sei();//allow interrupts

interrupt attachment (serial is disabled otherwise it just doesnt work)

ISR(TIMER1_COMPA_vect) {
  if (!GamecubeConsole1.write(d))
    Serial.println(F("Error writing Gamecube controller."));
}

[sirjeannot]

This is the current version using the timer1 interrupt.
I'm reaching limits:

• either the interrupt delay is too long, and I get disconnects. It really depends on the game/homebrew used.
• either the interrupt delay is too short, and I get increasing input delay (no time to handle usb bus). that is around 1.9ms.

#define TIMER1_MAX 60

//Nintendo gamecube bus
#include "Nintendo.h"
//PS3 controller bt
#include <PS3BT.h>
#include <usbhub.h>
#include <SPI.h>

//Define a Gamecube Controller and a Console
CGamecubeConsole GamecubeConsole1(8);
CGamecubeController GamecubeController1(7);
Gamecube_Data_t d = defaultGamecubeData;

USB Usb;
USBHub Hub1(&Usb); // Some dongles have a hub inside
BTD Btd(&Usb); // You have to create the Bluetooth Dongle instance like so
PS3BT PS3(&Btd); // This will just create the instance
#define pinLed LED_BUILTIN

//reset function for failed usb host init
void(* resetFunc) (void) = 0;

ISR(TIMER1_COMPA_vect) {
  GamecubeConsole1.write(d);
}

void setup()
{
  //pinMode(pinLed, OUTPUT);
  GamecubeController1.read();
  //Serial.begin(250000);

  while (Usb.Init() == -1) {
    Serial.print(F("\r\nOSC did not start"));
    delay(500);
    resetFunc();
  }
  Serial.println(F("\r\nPS3 Bluetooth Library Started"));

  cli();
  //set timer1 interrupt at 1Hz
  TCCR1A = 0;// set entire TCCR1A register to 0
  TCCR1B = 0;// same for TCCR1B
  TCNT1 = 0;//initialize counter value to 0
  // set compare match register for 1hz increments
  OCR1A = TIMER1_MAX;// = (16*10^6) / (1*1024) - 1 (must be <65536)
  //testing. lowest working without killing IO for usb on timer1 : 40-1024, highest working
  //testing. lowest working without sending twice state : 70-1024. 40 barely works
  //testing. highest working without disconnect :
  // turn on CTC mode
  TCCR1B |= (1 << WGM12);
  // Set CS10 and CS12 bits for 1024 prescaler
  TCCR1B |= (1 << CS12) | (1 << CS10);
  // enable timer compare interrupt
  TIMSK1 |= (1 << OCIE1A);
  sei();//allow interrupts
}

void loop()
{
  Usb.Task();
  if (PS3.PS3Connected || PS3.PS3NavigationConnected) {
    //out of deadzone
    if (PS3.getAnalogHat(LeftHatX) > 147 || PS3.getAnalogHat(LeftHatX) < 107 || PS3.getAnalogHat(LeftHatY) > 147 || PS3.getAnalogHat(LeftHatY) < 107 || PS3.getAnalogHat(RightHatX) > 137 || PS3.getAnalogHat(RightHatX) < 117 || PS3.getAnalogHat(RightHatY) > 137 || PS3.getAnalogHat(RightHatY) < 117) {
      d.report.xAxis = PS3.getAnalogHat(LeftHatX);
      d.report.yAxis = (PS3.getAnalogHat(LeftHatY) * -1 ); //yaxis values are inverted
      d.report.cxAxis = PS3.getAnalogHat(RightHatX);
      d.report.cyAxis = (PS3.getAnalogHat(RightHatY) * -1 ); //yaxis values are inverted
    }
    //in deadzone
    else {
      d.report.xAxis = 128;
      d.report.yAxis = 128;
      d.report.cxAxis = 128;
      d.report.cyAxis = 128;
    }
    d.report.left = PS3.getAnalogButton(L2);
    d.report.left > 200 ? d.report.l = 1 : d.report.l = 0 ;
    d.report.right = PS3.getAnalogButton(R2);
    d.report.right > 200 ?  d.report.r = 1 :  d.report.r = 0 ;
    d.report.x = PS3.getButtonPress(CIRCLE);
    d.report.y = PS3.getButtonPress(TRIANGLE);
    d.report.a = PS3.getButtonPress(CROSS);
    d.report.b = PS3.getButtonPress(SQUARE);
    d.report.dup = PS3.getButtonPress(UP);
    d.report.dright = PS3.getButtonPress(RIGHT);
    d.report.ddown = PS3.getButtonPress(DOWN);
    d.report.dleft = PS3.getButtonPress(LEFT);
    d.report.z = PS3.getButtonPress(R1);
    d.report.start = PS3.getButtonPress(START);
    if (PS3.getButtonClick(PS))
      PS3.disconnect();
  }
  //GamecubeConsole1.write(d); //disabled, run by timer1
}

I'm thinking about moving to teensy LC (I have two collecting dust) : much quicker and has a usb controller embedded (I don't feel like rewriting everything though). The tricky part is to get the timings in the asm code of Gamecube_N64.c tweaked for that controller.

[Skuzee]

Just some info that might help you. Taking Ocarina of Time VC gamecube game as an example I'm most familiar with.

• The console polls the controller twice quickly with about 1ms between updates, then waits 16ms and polls twice again.
• The console asking for an update, and the sending of the controller data over serial takes about 380us. This does not include any added time that it takes you to read the controller data to the arduino. This means you might only have 620us to do everything without missing an update.
• The console.write() function effectively halts the processor and waits for the Gamecube data wire to change state. It's waiting for a command, and will try to respond to it immediately. This can hang your program, so it's best to call this after everything else is done.
• Nicohood mentioned, its important to answer every call from the gamecube. If the gamecube does not get a response (even if the controller hasn't changed states) then it will mess with the game. If you're missing updates you will see flickering inputs in your game. This is probably why you can navigate some menus, because the "blinking" buttons are enough, but that wont allow you to play the game.

It looks like you update data "d" with the button events, and only send it when it's updated, then you re-zero the buttons.
Instead try something like this to set the button status:
d.report.start=PS3.getButtonPress(START);
Then call GamecubeConsole1.write(d) at the end of every loop and send whatever the current status is (regardless if it's changed.) Do not zero the buttons out each time.

I'm not familiar with the ps3 library you're using, but use whichever event returns true while the button is held down.
I hope this helps! <3

[sirjeannot]

thanks a lot for the timing info, I'll use to to get the timing right.

edit: so the idea is rather than running many ifs for each button, it's simpler to remove the conditions and update anyway. it'll get rid of the many long ifs > will try it right away. this is form the former dirty program I wrote in which I only wrote when there was activity on the controller (which is the wrong way). thanks! 👍

yes, the last point you mention on the input flickering still happens, but much less with the timed interrupt. I've updated the code so the input are directly changed in the data structure without the zero reinit.

[sirjeannot]

#define TIMER1_MAX 70
(+ some code cleaning)
it works : no lag, no disconnect (zelda twilight and fzero)
so happy :)

[NicoHood]

Is this something we can share as an example or maybe as a link to your project page?

[sirjeannot]

feel free to do so, it's all about sharing :)

[NicoHood]

So would you like to prepare a full working example? Or a link to your project, If you have one?

[sirjeannot]

I've added the link to the related project list in your wiki. my github repo is updated.

[NicoHood]

The wiki was public writeable? :-D
I though I disabled that for every project, but well, that was ok anyways XD