Some questions regarding design #10
Comments
|
Ok, so I've been messing about a bit and can now verify that PS_DATA and PS_ACK can be connected directly to the Arduino (but at least PS_DATA needs a pullup resistor). PS_CMD, PS_ATTN and PS_CLK can be connected by simple voltage divider. |
|
Sorry for the delay, but for some reason github didn't notify me at all that an issue had been opened. I found it by coincidence... Sigh. No problem for opening a non-issue, it's related to the project and that's enough :). I know the bidirectional level shifter is not strictly needed, but that was the kind of shifter I had handy when I started building the first prototype of this thing on a breadboard and I just kept using it, as it was working well. I kept thinking "I'll fix it later", but in the end... It's working very well, it's just a few additional components, a little more time in the assembly and a negligible cost increase. So why should I? There's no big saving in doing it the hackish way. Not to mention that this way I can always hack this PCB for other things (no idea what at the moment, but you never know ;)). I am also aware that a 3v3 input to a 5v microcontroller is mostly fine, but I was just mad at all those "teachers" around saying that driving PSX controllers at 5V is 100% safe. In reaction, I wanted to do this thing as properly as I could, so I level shifted all the signals. That of course also explains why I went for 3v3 regulator. A massive 3v3 regulator, so that I could have lots of current. In the version currently in development (which I first tested 5 minutes ago!) I have changed it to smaller one, providing up to 100mA. Hopefully it'll still be enough. The pull-ups on pins 6 and 9 seem to be needed by the CD32. They weren't there on the very first revision of the board and I never managed to make it work reliably until I added them in. It's weird, because many games seem to go through the whole 7-button polling routine, then just throw away what they read and re-read Buttons 1 and 2 the Atari way. See Banshee for instance. With the pull-ups, the lines are brought high as soon as the console releases them and everything works as it should. The 220p and 820p caps were just carried over from the original CD32 controller design. They are probably there for EMI control or noise filtering, but they are not crucial at all. The first version didn't have these and it was no issue. Hopefully that answers all of your questions! If you want to get the boards made, you'd rather wait a bit so that I can finish testing V4. That one also has analog joystick emulation, with which support for the Flightstick and steering wheels starts to make sense :). The tests I finished 5 minutes ago (I got the PCBs today) are promising, but the firmware needs some work. Or, if you feel lucky, you can just go with V4 right away, it's on the devel branch. Or, if you want, I can send you some PCBs (all revisions!) when this Corona thing is over (May 3rd at least). |
|
Hi! Thank you so much for your reply! Thank you so much for clarifying the reasons for the pull-ups and the caps! It was mainly out of curiosity I asked and I knew there were good reasons for them, just not what the reasons were :) I've been cobbling my own version together for the past few nights. Mainly with parts I had at hand. I only needed to order the PSX connector and lucked out on finding a clearance on extension cables for PS1 & 2 controllers. I just got them in the mail myself and still need to snip one off and solder in some DB9 connectors in the middle. Thank you for your kind offer! (I might take you up on it, if I'm not able make my own mess work reliably, but testing so far has been successful). Again, this is an awesome project! Very nicely written code, excellent features and well documented! A joy to follow! And I really like the PSX controllers and my Commodores, so it is a perfect match! Feel free to close this issue when you like. Stay safe and keep up the excellent work! |
|
You are also allowed to criticize, it's no problem as long as it's meant to be constructive :). Sorry if I seemed annoyed, actually I wasn't, maybe I was just a bit tired. Or yeah, I was definitely annoyed by getting no notification from github, which just happened again btw. I like discussing about my projects and design decisions. I am actually missing that, most of my projects (and they're quite a few by now) have been solo efforts, people have limited themselves to taking my work and selling it, sometimes at outrageous prices. There haven't been many cases where somebody tried to study and improve them. I don't have that much experience in electronics, so I definitely wish I had more help than I do. I'm leaving this open, let me know how your project turns out. I like the idea of an external box where you can just plug an Arduino Pro Mini. It would be nice if someone made a PCB for that ;). |
|
I can relate. A few years ago I wrote a replacement firmware for a (then) popular cheap digital thermostat. It was really fun! Until it wasn't. I did get some useful feedback, but mainly folks didn't want to tinker, they just wanted to buy a product that works. I can see that you indeed have a lot of projects :) Yay! It seems we even have been working on very similar stuff (maybe even around the same time, ~2 years ago) I've never taken the plunge into designing and making PCB's, but I've started KiCAD many times with the intention to. Maybe some day :) |
|
I'll be waiting patiently :). Thanks for the understanding. |
|
Hey, how's your build going? :) |
|
Hi! |
Hi!
First off, sorry for opening an issue for something that clearly isn't an issue. Secondly, thank you so much, this seems like a very interesting project and very well documented, cleanly implemented and open one at that.
So, I'm thinking of cobbling one of these together as I've got most of the parts lying around and I do want a better controller for my Commodore machines. I just have a few questions.
Why the bidirectional level shifting for the controller? ps_data_3v3 and ps_ack_3v3 are outputs and could be directly connected to the MCU (maybe with a weak pull-up and/or a current limiting resistor). ps_cmd_3v3, ps_clk_3v3 and ps_attn_3v3 are inputs and could use a simple voltage divider to get from 5 to 3.3v. Or am I missing something?
Why the pull-up on ami_fire? I guess there is a reason, I'm just curious as to what it is :)
Same for ami_poty (though I can guess that this has to do either with CD32 or possibly C64 button 2)?
Finally, what are the capacitors on ami_potx and ami_poty about? 820p and 220p seems small and very specific. I'm guessing again this has to do with signal conditioning for CD32 mode. How crucial are these (and their values)?
Thanks again for your very cool and very well maintained work!
Best regards from Sweden,
Mats
The text was updated successfully, but these errors were encountered: