 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Controllers - here's an approach
Page 1 of 2   |
|||||
| Author | Message | ||||
| matherp Guru  Joined: 11/12/2012 Location: United KingdomPosts: 9118 |
We seem to end up in never ending discussions about controllers and interface standards with no resolution so I'll try and confuse things even more  The one standard we have across all variants of MMBasic is Serial I/O I propose we forget everything thus far and start by defining a simple serial interface protocol that a MMBasic controller will adhere to One message per event, button down, button up, analogue change value so messages could be: a1,a0,b1,b0,x1,x0,y1,y0 etc. Then any game or utility using a controller would only ever have to deal with one standard. The community could then over time develop multiple small I/F applications on dedicated processors for the actual physical H/W (MM2 would be ideal for this for many applications) For example I would be happy to code a Wii Classic I/F on an ATTiny85 Mick is well on the way to designing a system for individual buttons More advanced controllers could be interfaced using something like this with an additional PIC to convert the protocol The key to making this work would be to define up-front the exact serial protocol and then stick to it. If this makes sense I would be prepared to have a first go at defining a protocol for comment Views? |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4040 |
It's a solution only a hardware engineer would come up with , and I suspect it is not going to work, only hackers are going to want specific interface hardware for each controller.Also: https://xkcd.com/927/ I've already demonstrated an extensible MMBasic only approach to digital control (admittedly I didn't extend it to analog) where the game code doesn't give two figs about what the actual controller is, e.g. Lazer Cycle which between CMM2, PicoMiteVGA and Game*Mite supports keyboard input through INKEY$, KEYDOWN and ON PS2 and controller input through Nunchuck, Wii Classic, Atari, {S}NES and Game*Mite controllers. A couple of relatively simple additions to MMBasic, i.e. DEVICE JOYSTICK and DEVICE GAMEPAD which I previously described to you would even eliminate most of my code. For MMB4W, the One Lone Coder library has controller extensions, e.g. https://github.com/gorbit99/olcPGEX_Gamepad. As ever YMMV, Tom Edited 2023-12-19 19:44 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4040 |
Though the PORT function and some bit-twiddling can do most of what is required from DEVICE JOYSICK and DEVICE GAMEPAD might more generally be DEVICE PISO to read from a Parallel In, Serial Out shift-register. Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4238 |
It's a little bit funnny. Commercial controllers are based on a/ parallel digital b/ analog + parallel digital c/ SPI (NES/SNES) d/ I2C (Wii) e/ Bluetooth (yip wireless) f/ USB (controllers, but also mouse/mice and keyboards) g/ PS2 (if you count a keyboard as a controller) The only protocol NOT in this list is UART. If I understand well, the idea is to standardize on UART, and convert everything (depending the needs) to UART. I understand the need for standardisation. Otherwise each shedder will require his/her own version of a game/program. In such I support your effort Peter. And UART is supported on all mites, and UART is simple to code for. But .. you would require an interface for every commercially available controller before that controller can actually be used. For me (personally), who is not a "gamer". I think I have played maximum some 50 hours during the last 5 years. All games keyboard related (and a bit N64 with my grand children, from who I loose constantly). I would like to invest in a single controller, and stick to that. If that is Wii, then it is Wii. If that is SNES, then I will buy SNES. I have no "muscle memory" so any controller I must get used to. I will support whatever the forum direction is, but I do not intend to change controller ever once the choice is set. Volhout P.S. Peter, I thought you implemented the Wii classic I2C in firmware, to do just that: preference a standard controller. In line with CMM2. So the default controller for the "new generation" pico/cmm2 would be Wii classic. Edited 2023-12-19 20:40 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6792 |
For this sort of thing the hardware is the easy bit. :) My only problem in using COM ports is in the cases where you would like to use more than one controller. There is no addressing system so you are tied to having to use more IO pins. On the bigger chips that's not a problem, but when you only have two COM ports (if they are both available) then that's your limit - and four pins tied up. Whether having buffers on a controller interface is a good idea I'm not entirely sure. All the MMBasic platforms, apart from MMB4W, have at least one I2C port. You only ever need two pins, even with a few controllers. A I2C to virtual COM port over USB on a PC would fix the platform issue. I think such modules are already available, but I don't know how to use them. I'm in favour of the message string "button down...button up" and it's one I was looking at for Circuit Python. It's the only way to get simultaneous key presses over a normal serial interface AFAIK and is the system used for MIDI. Having finally got hold of a WII Classic, I rather like it. If it wasn't for the stupid plug... Incidentally, the "shoulder" buttons on it are analogue until you get close to the bottom then there's a switch. The Classic Pro is only switched. Edited 2023-12-19 20:49 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9118 |
I did but it seems to get a decidedly lukewarm reception and given that I'm not going to support multiple other controllers in firmware and given that Tom's code is too complex for most people (me included - after looking at the Lazer cycle github), I was trying to find an alternative solution |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6792 |
Just off the top of my head... OPTION GAMEE I2C <sda>,<scl> READ GAME <address>, <var0> [,var1] [,var2] up to 8 vars. The controller doesn't matter. Address is any legal I2C address. Each var is a byte, so it's a straight I2C transfer. How the vars are used is something to be sorted out, but would suggest that var0 contains the type of controller, telling the program how to decode the rest of the vars. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4040 |
I feel that is rather like me complaining that the firmware is too complex  :#Include "ctrl.inc" Dim CTRL_DRIVER$ = "nes_a" ' Change to the desired driver SUB Dim k% Call CTRL_DRIVER$, ctrl.OPEN ' Initialise the controller Dim t% = Timer + 5 * 60 * 1000 ' 5 minutes Do While Timer < t% Call CTRL_DRIVER$, k% ' Read the controller If k% Then Print ctrl.bits_to_string$(k%) ' Print human-readable list of buttons that are down Loop Call CTRL_DRIVER$, ctrl.CLOSE ' Terminate the controller The main problem is that on the PicoMite we have no #INCLUDE so you have to copy in the driver routines you want verbatim. I think (not necessarily easily and not quite the same way the CMM2 does it) we could have #INCLUDE now that EDIT can handle files, but I can understand why it isn't being done, and nor am I asking you to do it. Best wishes, Tom Edited 2023-12-19 21:07 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6792 |
USB to UART and I2C converter Here :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
stanleyella Guru Joined: 25/06/2022 Location: United KingdomPosts: 2129 |
I can't see a a problem using mcp23017 i2c and digital only. 8 buttons is plenty but could be 16 using both ports. If you used 2 chips it could be 32 buttons and unlike a keyboard all pressed same time seen. Just a beginner hobbyist view but think nice chip. thanks again for the forum help getting it to work. stan |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6792 |
1: you can't rely on having 16 inputs with a MCP23017. Only 14 are guaranteed as bit 7 is officially output only. It might work and it might not. 2: you can't have analogue at all. Neither of these is a deal breaker, but the software to configure the chip and read it is quite an overhead in MMBasic - more complicated than a SNES controller and the chip is more expensive than two CD2021 with pullups. The MCP23008 *does* give you 8 inputs. Remember, the RP2040-Zero is only about £1.80 from AE. No pullups needed. No complex initialisation - it's an intelligent controller and you get a free reset button and multicolour LED!. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| stanleyella Guru Joined: 25/06/2022 Location: United KingdomPosts: 2129 |
What's it do? I got usb to ttl. looks interesting. |
||||
vegipete Guru Joined: 29/01/2013 Location: CanadaPosts: 1109 |
I quite like the Wii Classic (Pro?) I have. It interfaced easily to the PicoGame VGA Mini by Mixtel90. (Thanks, Lizby!) I chopped a wii extension cord in half, buzzed out the pins and soldered the jack end to the appropriate pins of a 9-pin d-sub. Works painlessly. I would be very hesitant about a comm port interface because of buffering. I want to know what the controller is doing now, not some time ago when the state went into the buffer. That's why using the keyboard (especially via console) on the PicoMite is such a pain - the input buffer has to be constantly flushed, and the last character, if present, noted and acted upon. This is better on the CMM2 because I can look at a number of possible keys being pressed now, plus the modifiers. Is this possible on the PicoMite with a directly connected keyboard? Could it be? The only Wii Classic issue seems to be the question of how many at once. The I2C address is fixed, so more pins or other hardware trickery is required more multiple controllers. Visit Vegipete's *Mite Library for cool programs. |
||||
| stanleyella Guru Joined: 25/06/2022 Location: United KingdomPosts: 2129 |
how do you get it to work? think I asked before and not easy. |
||||
PeteCotton Guru Joined: 13/08/2020 Location: CanadaPosts: 368 |
I like this idea a lot. Otherwise we're going to end up trying to support 5 different protocols for every game. Do you anticipate the reading of the input to be built into the firmware (e.g. IF Joystick1.Up = 1 THEN ), or would we poll it from within our own BASIC code (reading the serial port). View 1: We have the decision of do we have the controller sending data all of the time or do we have it only respond to a poll of the current state (from the maximite)? My gut tells me that a poll would be less processor intensive. In most game loops, if we poll at the start of the loop, there's plenty of time to do other things, copying background graphics etc. that the couple of milliseconds it would take for the response to appear on the serial port would be irrelevant. Usually we're aiming for 30 frames per second - which is obviously 33ms per frame. Tonnes of time to get the response back from the poll and still move the player sprite/world. It also means that we are only dealing with the controller data that we are interested in (e.g. a game pad with two joysticks and 12 buttons - but we're only using one joystick and one of those buttons - so we get sent a lot less data to parse through). But if we spew data all of the time, there would be no need to poll - however, do we end up filling the serial port buffer with junk that hasn't been processed, and then when the program wants to see what state the controller is in, we have to wade through a backlog of out of data messages to find the newest one. It's unlikely that a user would be able to press the fire button more than 30 times per second, but something like an analog joystick could easily create a tonne of data that is being sent faster than the program can handle with a single game loop/frame. View 2: Either way, parsing the data is also going to be time consuming. I don't have my CMM2 to hand to test, but I imagine that trying to parse a string of data is much slower than polling an array of bytes. If we read the data as bytes from the port, then we could use individual bits to identify button states. It makes the protocol far less human readable, but would probably be significantly faster than string parsing. But, like I said - I haven't done a speed test on my CMM2 so I could be very wrong here. View 3: Finally, (and this one might be a bridge to far) would this controller also support a mouse and keyboard? I know that may seem pointless when we already have solutions for those - however does this controller interface become the defacto channel for all user interface devices. Obviously this would require that changes were made to the firmware, and I don't know the practicalities - but I thought I'd throw it out there as an off the wall idea. |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6792 |
To keep a game running properly any controller really needs to be polled. That can either be at an opportune moment in the loop or, even better, during the frame flyback period while the screen is being updated. Generally the returned string wouldn't be long and would only consist of changed states (probably). ================================ Stan: It sits in a loop updating a set of variables, which are the output registers. When it gets a I2C character an interrupt is triggered and the character is compared wit the controller address. If it's different the interrupt is aborted. If it's the same the next character is examined to see what the command is (it's only one character). That decides how many output registers are sent. I took it a bit further than this, but that's the general idea. Edited 2023-12-20 04:08 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4040 |
Look at ON PS2 and MM.INFO(PS2). Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| stanleyella Guru Joined: 25/06/2022 Location: United KingdomPosts: 2129 |
maybe relevance to rpi pico as it's new and popular... price cheap? rpi pico is an idea for a standard controller as it's newish. but unless you want to share your code then your controller is your own,you can't expect others to have the same hardware as you,hence back to universal controller doh. i2c controllers seem the way imho |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6792 |
The code is no problem - I just haven't finished writing it yet. You'll be welcome to it once it's done. :) I've had an early version running so I'm happy that it's possible. I do need to standardize on the IO pins though and I can't do that without a PCB design. There's no point in releasing the code so that everyone can build incompatible controllers with it. :) I've used the RP2040-Zero for several reasons: It's less than half the price of a Pico It has USB-C It has a built in WS LED & reset button It's a lot smaller than a Pico. There's plenty of IO available for a controller, including four ADC ports so you could have two analogue joysticks if you wanted to. I could have used a standard Pico but it simply doesn't fit mechanically where I want it to go. Unfortunately it's not veroboard friendly, but as I've no intention of using it like that it doesn't matter. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| stanleyella Guru Joined: 25/06/2022 Location: United KingdomPosts: 2129 |
I can get by with testing mcp23017 and masking to test but think your ideas are better for "universal" controller and the idea is it's only about games is yours. that's why I like a port expander... all 5 from microchip work.. dunno to what frequency but testing switches ok and no debounce used yet. I looked up port expanders and cost. Is serial the way to go now? stan |
||||
| Page 1 of 2 |
|||||
 Print this page |
