Serisium
Problem with hex files
Hey Garrett, When I compile the source code of the latest shinewave version (0.1.1) I dont get the hex file provided in the post. Instead the resulting hex file lets the controller flash red in random intervalls. When i compile the earlier version (0.1 - falco) I get a working hex file but not the one provided in the posts. In both releases the hex files are identical but I chant get any of the codes to result in this hex file.
How did you get to this hex file?
The reason im asking this is because I found out that even though the code is meant for gamecube and wii only this hex file suprisingly works for wii u too (but in 4x the speed). sincerely, -Shrobo
Hey @Shrobo, thanks for the interest! There are a couple of root causes to the issue you mentioned.
- The Wii U USB adapter polls the controller every 4ms, compared to the Gamecubes 16.6ms(60Hz)
- The bits in messages from the Wii U USB adapter have a slightly different period than bits coming from a Gamecube console
Since the animations I wrote are tied to framerate, polling four times as often will actually cause the animations to run four times faster than intended, like you observed. The solution here would be to decouple animations from framerate by measuring the time passed between frames and progressing the animation in terms of that delta. This would require an increase in resolution in the animation color code(currently 8 bits per channel). Additionally, the Gamecube tends to stop polling during "lag frames", which include loading screens. Ideally, the animation would continue to progress even during lag frames.
Secondly, the slightly different period coming from the Wii U adapter is difficult to account for. As is, the ATTiny85 in the original Shinewave mod is running at 16MHz while the GCC protocol has a period of 4us. This gives a clean 64 clock cycles per signal period. Since the "critical" portion of the signal that actually reads out a "1" or "0" occurs between 1us and 3us each period, we should read the line at 2us to get a good read. This leaves only 32 clock cycles to read the signal, store it in a register, and push the register onto the stack after eight reads. Certainly doable, but difficult.
The issue arises when the period on the line differs significantly from my measured setup. I addressed this in this commit, where I replaced a hardcoded number of nop delays with a dynamic period counter and some bit-shifty math. This appeared to work for both Wii-U and Gamecube messages, but was inconsistent and failed some of the time.
As the project matured a bit, I decided to make a few changes that would allow me to support USB functionality:
- Drop from 5V to 3.3V for easier USB communications
- Drop from 16MHz(crystal-less) to 12MHz(with a crystal) to stay within safe operating frequencies
- Switch from the ATTiny85 to the ATTiny84 for more I/O pins
- Introduce a PCB to facilitate these components and the USB connector
- Rewrite the aforementioned polling loop to operate at the new frequency, giving me 48 clock cycles per instead of 64
Unfortunately, I decided to keep these changes in the main project instead of creating a new one, so it's difficult to see where these changes occur. In retrospect, I should've forked this repo and created a new one on the new platform. My solution to the polling rate was particularly clever, and could be ported pretty easily to work with other operating frequencies. Since it relies on the hardware clock to count cycles and abuse of the Serial peripheral to read data, it can also be tuned at runtime to different polling frequencies.
With this situation in mind, there are a few maintenance fixes that would need to go into place to fix this issue.
- Separate the USB code into a seperate forked repository
- Revert this repo back to the latest ATtiny85 state
- Update documentation and blog posts accordingly
Then, a couple of development changes would be needed.
- Port the timer-based communication from the t84(USB) to the t85
- Add and test code to dynamically update the timer compare value, to support slightly different polling speeds
- Decouple animations from the framerate, so that animations don't appear faster on the Wii U adapter