What's new
One thing, which I'm not complaining nor fussed about, it seems I need to hit buttons B and C simultaneously on the Retrobit controller before it's detected and responsive. Normal behaviour?
I also experience this problem. It has to do with the controller detection routine. It's supposed to detect a controller when plugged in without any external input but it's not quite working properly. I'm still investigating the cause. The reason that pressing B and C works is because the detection routine looks for a low signal on those same data lines but on a different part of the select cycle. A stock Saturn controller has those 2 data lines tied low internally when on that same cycle which I believe is how the Saturn console detects when a controller is plugged in. I hope that makes sense.
 
Last thing, how on earth did you generate that Hex file? I'm having a terribly difficult time compiling my own working HEX. I've tried every board from the board menu, as well as downloading the breadboard folder from the Arduino site (placing in hardware folder) and selecting Atmega328 with 8MHz clock from the menu, then sketch, compile binary etc with no success.
 
I use MCUdude's Minicore package. It lets you select from a wide variety of AtmegaXX8 variant chips and you can set the correct clock settings, bootloader settings etc. Just compile it for your particular chip at 8mhz and you should get a good HEX.

Also a small update. I located the problem that was preventing automatic controller detection from working. It was a minor timing issue with the routine. Now controllers are fully hotpluggable including the Retro Bit wireless receiver and you no longer have to hold B and C to trigger controller detection.
 
Last edited:
Tested and confirmed working, perfectly. Thanks for your hard work and for including a HEX file, appreciate it.
 
Tested and confirmed working, perfectly. Thanks for your hard work and for including a HEX file, appreciate it.
No problem. I'm so glad that the Retro Bit wireless controllers didn't work with my code because that's what pushed me to pull the trigger on the logic analyzer and really get an accurate representation of the Saturn controller protocol in my adapter code. Now I have the tools to do the same with the SNES and Playstation code.

In other news, the Retro Bit fix version of the adapter code is now working on with Brook Retro Boards also, so it's going to officially become the main branch of the project now. It turns out that the problem was not the code, but rather the tighter timings of the code revealed that the 15 foot Saturn RJ45 cable I was using was too long to work reliably with this high speed code. Switching to a 6 foot cable produced perfect results from the Retro Board.
 
Hi @Arthrimus. I recently got ahold of your SNES to DB15 adapter via @Frank_fjs. I've been having issues pulling off really basic moves (fireballs, shoryukens) in any street fighter (Street Fighter Alpha and Super Street Fighters) games on my CPS2 setup. I'm using the Brooks Retro Board and the 8bitdo wireless snes controller with your adapter. With @'Frank_fjs''s suggestion, I tried enabling/disabling the Brooks fix without having any success. As soon as I switch the adapter over to the UD Decoder, I'm able to do fireballs and uppercuts all day.

Do you have any ideas on what's going on or any suggestions on how to fix it?

Thanks!
 
Given the conversation Frank and I had above, I'm not sure that the compiled HEX that he has installed on the adapters that he built is running at the correct speed. This is just speculation, but if that is true then it's possible that the adapter is not sampling your inputs fast enough to keep up with the CPS2, resulting in bad input timing.

I know that the code has sub 1 frame lag from my own testing so if the firmware is compiled correctly and the ATMEGA is running at the correct speed you should have no problems.

I'm going to compile a HEX for the SNES adapter and add it to the Github. If you have a way to flash the firmware you can try it out. All you need is a usbasp and the extreme AVR burner software that Frank recommends in this post

EDIT: I've updated the Github with the compiled HEX file for the adapter. You can download it here.

I've thought about this some more and if Frank's HEX was compiled for 16mhz timing, but is running on an 8mhz chip, then the sampling rate for the adapter would fall slightly below 30 samples per second. That would definitely mess with your ability to do basic Street Fighter moves because the CPS2 Samples inputs at least 30 times per second if not more. When the SNES adapter is operating normally it samples almost exactly 60 times per second. This is to keep it in line with the SNES console's controller protocol for maximum compatibility.
 
Last edited:
Thanks for the quick reply @Arthrimus. This is completely new to me but I don't mind giving it a try. I'll purchase a programmer and give it a whirl.
 
Received everything to flash my adapter today. Looks like my issue is fixed with the provided HEX and all is well in Street Fighter land.

Thanks again @Arthrimus and @Frank_fjs for all your hardwork and expertise. This is what the hobby is all about and I love this community!

https://imgur.com/a/EXsOgtr

uOhdIRl.jpg

iTOfUgA.jpg


WTIwpB9.jpg


SHORYUKEN!!
https://i.imgur.com/4j4GV8D.mp4
 
Although the code compiles without any issue using Minicore, the provided .hex is really handy. This way I can test the firmware without turning on my Windows machine. Maybe you could add this to the documentation? this is the command line to burn the hex from commandline using avrdude:


Code:
avrdude -c usbasp -p m328p -e -U flash:w:firmware.hex -U lfuse:w:0xe2:m
I've just tested the RMAF .hex with three HSS-0101 official saturn controllers using Atmega328p (both DIP and SMD) and it works fine. Good job! :thumbup:

It's maybe psychological after reading "DigitalWriteFast" library is used, but I feel the pads respond better now.
 
I'm not terribly comfy soldering SMT/SMDs or very tiny resistors/caps. Would there be a completely through-hole option, or perhaps a headered version for prefabbed arduinos to fit on top of, or is that unlikely?
 
I also finished assembling my adapters for SNES. Flashed with the Arduino IDE with miniCore, worked without problems. The adapter works great.

Good job and thanks @Arthrimus and @Frank_fjs

I have disabled reading and saving the auto fire function in the EEPROM. After a restart, the adapter always runs without auto fire. This is better for me.
 

Attachments

  • 20200126_133322.jpg
    20200126_133322.jpg
    201.7 KB · Views: 204
  • 20200126_133423.jpg
    20200126_133423.jpg
    203.8 KB · Views: 200
I'm not terribly comfy soldering SMT/SMDs or very tiny resistors/caps. Would there be a completely through-hole option, or perhaps a headered version for prefabbed arduinos to fit on top of, or is that unlikely?
I'd offer help but I live in other continent so it's not viable.

Maybe you can use the DIP version and solder normal resistors from pin to pin instead of the tiny SMD? anyway I'd consider using some aid like a magnifying glass - if you don't have physical handicaps, soldering small SMD is not as difficult as it seems at first glance.
 
I'd offer help but I live in other continent so it's not viable.
Maybe you can use the DIP version and solder normal resistors from pin to pin instead of the tiny SMD? anyway I'd consider using some aid like a magnifying glass - if you don't have physical handicaps, soldering small SMD is not as difficult as it seems at first glance.
No worries on the help, but thank you for the suggestions! I had tiny resistors on a kit I ordered for another project and went through about 10 of them before the pad ripped off, making the unit worthless to me. I don't know if resistors and caps come that small without being that kind of package though.
 
I'm having trouble with the latest snes2neo adapter hex. After flashing, I lose the led indicator and am unable to remap buttons, however all buttons work on input tests. I'm using the 328p and flashing back to frank's hex brings everything back.
 
Back
Top