uze6666 wrote:Are you referring to that 2.5ms between the 16bit chunks? I can fix that in no time, but I though the real problem was more that the atmega was not fast enough.
Yes. The delay between the both 16bit protocols will help. But I need then also the recompiled controller tester and if possiblle a recompiled Wack-a-mole...
The speed of the ATMEGA is really a problem, but solved in my actual hardware with two 4021
Hmmm 2.5ms is about a 70K cycle delay or 8 scanlines! I guess it can be more than 2.5ms since the clock master in the console. I'll think of a way to not waste all that time.
Trying to fix the timing I realized the whole mouse does not work with the current kernel. However, the original HEX I posted on the forums works fine. I'll have to turn on the scope to see what is going on. That will indeed go after Maker Faire. On the bright side, this made me think about bringing the mouse.
uze6666 wrote:Trying to fix the timing I realized the whole mouse does not work with the current kernel. However, the original HEX I posted on the forums works fine. I'll have to turn on the scope to see what is going on. That will indeed go after Maker Faire. On the bright side, this made me think about bringing the mouse.
Don't stress yourself out! I'm on a business trip to China this week - no time to go on working before next weekend.
Good luck in New York. (and don't forget the mouse)
I was thinking, do you want to make this Wii adapter just for the Uzebox or you would expect it to also work on a real SNES? Because otherwise, I can alter the protocol timing to include enough delays between bytes for you to reload the SPI.
yes it is my intention to make this adaptor for SNES and Uzebox. But it is not so important, that the time between the 2 protocols is exactely 2,5ms. It is more important, that the 2nd 16bit protocol with the mouse data is in the time window before the next protocol with the first 16bit is send...
I've looked at the timing issue and there's not much ways to introduce that delay without making a mess in the code. Since the use of the mouse is, well, inexistant and probably will stay like that, I reckon it's not worth spending much time on that. That said, I could do a simple thing to add a gap between the two 16 bit chunks: read the regular buttons first then process the sprites & music and finally read the extended mouse buttons. Depending on the CPU required for ramtiles & mixing, this introduces a delay between ~600us and 1ms. Would that be enough for you?
