Forum - Socoder

-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0\|717\|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
Socoder -> C/C++/C#/Other -> Anyone Arduino?
Page : 1 2 Next Prev
Sat, 19 Mar 2016, 11:25
spinal	As someone of you might have read, I'm attempting to build a PS2 -> N64 controller adapter. However, the only code I can find assumes I'd be using an arduino, rather than an generic Avr. github.com/brownan/Gamecube-N64-Controller/blob/master/gamecube.ino A couple of things are bugging me, the following for example... #define N64_PIN 8 #define N64_HIGH DDRB &= ~0x01 #define N64_LOW DDRB \|= 0x01 #define N64_QUERY (PINB & 0x01) --v From what I can tell, Arduino digital pin 8 is PB0, this isn't much of an issue I think because 1. Its only ever used here -- // Communication with the N64 on this pin digitalWrite(N64_PIN, LOW); pinMode(N64_PIN, INPUT); --v and 2. The other defines suggest to me that its the first bit on port B, which should be PB0. (I think) The next part that bugs me in fact // Communication with the N64 on this pin digitalWrite(N64_PIN, LOW); pinMode(N64_PIN, INPUT); --v Not using Arduino, I don't have these functions. The following is the best I can come up with, assuming this to be correct... // digitalWrite(N64_PIN, LOW); PORTB &= ~(1 << PB0); // Pin PB0 goes low // pinMode(N64_PIN, INPUT); DDRB &= ~(1 << PB0); // PB0 Input --v So fixing those two issues (probably?) my next step if to figure out why nothing is working! Anyone got any ideas? -=-=- Check out my excellent homepage!
Sat, 19 Mar 2016, 12:23
steve_ancell	I thought about getting into Arduino but I need to find a use for it first, they do a compatible board on ebay for about five and half quid.
Sun, 20 Mar 2016, 02:43
Krakatomato	I presume you're using another Atmel AVR. In which case you don't need to change much of the code - just maybe some PIN configuration. Use the Arduino IDE, choose the "Board" that has the same AVR on that you're using. Then choose your "Programmer" to match whatever hardware you're using to program the chip. I've found little USBasp programmers work well and are super cheap. There are other plug-ins that you can add to the Arduino IDE to allow for various other AVR's, but YMMV with some of these. I tend to stick with a common AVR and use the appropriate board. //Andy
Sun, 20 Mar 2016, 10:31
spinal	I'm not using the arduino ide my avr is an atmega32u2 and the board has a build in usb programmer. Makes things a little tricky if you don't know what your doing. From what you can see, would you say those code changes in the first post are correct? -=-=- Check out my excellent homepage!
Mon, 21 Mar 2016, 05:52
spinal	Hmmm, I seem to have the thing hooked up correctly, but something isn't right. According to the code, from what I can tell, I'm getting stuck waiting for the data line to idle before attempting to get a command. This doesn't happen though, it just sits looping waiting for something to not happen -=-=- Check out my excellent homepage!
Mon, 21 Mar 2016, 06:12
Krakatomato	AVR's are generally pretty easy to get your head around - it's always the programming of them that I find a pain in the rear! The target board can sometimes cause issues as they take ownership of some PINs for their own use - particularly for programming the device. Looking at the datasheet for the AVR you're using, the PINs on PORTB are also used for SPI - so entirely possible your board is using these to program the chip too. Something to be aware of. Anyway, I've not looked at the Arduino code you linked to above, but your examples are fairly common tasks. With any AVR, you need to take a look at the datasheet to understand what the PINs do, especially those that are multi-use. Take note of how they're configured for internal sink/source use. From what I can gather, you need to set PIN PB0 as an input on the device: // Set all PINs on Port B as input: DDRB = 0; or // Set PIN PB0 as input on Port B DDRB &= ~(1 << PB0); // Ensure Port B is high impedance (does not source) PORTB = 0; or just do it for that one pin: PORTB &= ~(1 << PB0); now do your main loop: while(true) { if (~PINB & (1 << PB0)) { ... Pin PB0 has gone high, so act on it .... } } --v You should have access to some helper macros that avoid all the bit testing above. Replace with: if (bit_is_clear(PINB, PB0)) { .... } --v There's also bit_is_set(...) Handy functions //ANDY
Mon, 21 Mar 2016, 13:43
spinal	I've got a bit further, I seem to be reading /something/ from the n64, but maybe not the right thing. There's a part of the code waiting for the line to idle before attempting to read the next command, but its just getting stuck there. Looks like I'l have to do a bunch of research into exactly what is going on between the console and a controller... Hoped it wouldnt come to that. -=-=- Check out my excellent homepage!
Thu, 31 Mar 2016, 09:37
spinal	Minor update, discovered the main problem, my avr runs at 1mhz by default, not 16mhz. Never even thought to check that. Anyway, got it running at 16mhz, the timing seems a little off, but me n64-usb adapter seems to think it's a genuine controller, even though it's spitting out random button presses (I'm not sending any) so something's wrong still. -=-=- Check out my excellent homepage!
Mon, 04 Apr 2016, 03:11
spinal	Dammit, its that part I really really really hate. Need the stick range to be different! The N64 stick needs to range from -85 to 85 (ish). Apparently some games act a bit weird if they detect the stick going past 86, so 85 max sounds ok. Currently I'm doing the following - n64_x = (psx_LX)/1.5)-85; --v Which gives me a value from -85 to 85, perfect. However I need to add a deadzone. I was thinking of using the same method that I used last time and use a hand crafted lookup table, but I have almost no storage space left, so that's out of the question. So, if I divide by say 1.4, I can get a range from -91 to 91. So, as I can't quite think of what I'm doing. How the hell do I turn -91 to 91 into -85 to 85 while zeroing the -6 to 6 range? so than 0 to 6 = 0 and 7 to 91 = 0 to 85? -=-=- Check out my excellent homepage!
Mon, 04 Apr 2016, 04:13
cyangames	Is there space left to store an absolute value of n64_x? How much space is left? Are we talking <512b? -=-=- Web / Game Dev, occasionally finishes off coding games also!
Mon, 04 Apr 2016, 04:24
spinal	looking at it again, I probably do have enough space, my data usage is at 639 bytes out of 1kb. but I deleted my data So yeah, there is room. -=-=- Check out my excellent homepage!
Mon, 04 Apr 2016, 04:27
Jayenkai	Do you have enough power/bytes/cpu to do a bit of maths? ATan2() and Sqrt() to work out the angle and distance, scale the distance, re-Sin()Cos() the values, and send "if > Deadzone" -=-=- ''Load, Next List!''
Mon, 04 Apr 2016, 04:42
spinal	I'm not sure I have enough time for sqrt or anything that's known for being slow. I'm not always responding in time to start with. -=-=- Check out my excellent homepage!
Mon, 04 Apr 2016, 05:19
Jayenkai	tries for about half an hour ... Sorry, my brain stopped working about 10 minutes into that! I might give it another go, later. It started off well, then I tried subtracting the deadzone whilst taking care of the original +/- values.. It got kinda messy!!! I'll try again, later. -=-=- ''Load, Next List!''
Mon, 04 Apr 2016, 05:53
Hotshot	Another board!? I see youtube on someone made game for it using C and daunting Assembler!
Mon, 04 Apr 2016, 06:51
Krakatomato	You can do it with a simple linear conversion: linConvRange(v, minv, maxv, new_minv, new_maxv) { return ((v - minv) / (maxv - minv)) * (new_maxv - new_minv) + new_minv; } --v Then: myNewVal = linConvRange(oldVal, -91, 91, -85, 85) --v //Andy
Mon, 04 Apr 2016, 09:16
Hotshot	spinal: Are you coding game for it?
Mon, 04 Apr 2016, 12:24
spinal	Nah, a PS2 -> N64 controller adapter.
Fri, 08 Apr 2016, 05:36
spinal	psx protocol is bugging me I have a wired controller working fine, but I WANT a wireless one to work. the current setup just isn't working. From what I gather from the www, wireless controllers REALLY care if the timing of the signals is perfect. Something I can't quite achieve. Also, data is sent both ways at the same time, which confuses me a little. How does the thing know what data to send back if the command isn't fully sent yet? So anyway, I don't know if consistence is the key with every bit taking up exactly x amount of time, or if speed is the key. Currently each bit is taking about 17 milliseconds to send, which if far far far too slow. A genuine console on the other hand is sending 1 bit per microsecond.... OK, I seem to be communicating with the thing! every now and then it seems to return a couple of random bytes, probably a timing issue. But, being a cheap 3rd party controller, the quality isn't super. The left stick is a bit wonky -=-=- Check out my excellent homepage!
Fri, 15 Apr 2016, 12:04
spinal	Dammit, can't communicate with the wireless controller anymore, don't know what I did, should have backed up the working version. -=-=- Check out my excellent homepage!
Fri, 15 Apr 2016, 12:09
Dabz	Oh, they are the best them ones... I've done that a few times... Something just "Goes wrong" out of the blue and you havent touched it! I had a little spell years ago when I was in a proper programming zone... Every chance... tippy tappy tippy tappy! Turned out on a bank holiday weekend, I was proper minging, like... Cannot remember leaving the pub material. Got up the next morning, fannied on with brekkie, took dog out, pulled myself round... Thought I'll do a bit, open BlitzBasic, just give it a quick build, errors... Thought "Eh?", started to look... Aye... I'd been at it pissed, totally destroyed it! Took me bloody ages to fix it! Dabz -=-=- Intel Core i5 6400 2.7GHz, NVIDIA GeForce GTX 1070 (8GB), 8Gig DDR4 RAM, 256GB SSD, 1TB HDD, Windows 10 64bit
Fri, 15 Apr 2016, 12:17
rockford	Pop up bugs, ones that appear in established working code, are soooo fecking annoying. It worked yesterday. It worked the day before. It even worked a week or more ago. But the bastard thing won't work now. Grrrrrr.... Some minor, insignificant addition to your code somewhere way down the line has affected something else that it had no right to do. Then you realise it's a simple spelling mistake in two similar variables. Of course its taken the last 12 hours to find that "simple" mistake
Sat, 16 Apr 2016, 11:58
spinal	Need to do a little maths on the analog stick, I want the distance in one direction to influence the distance in the other to try to emulate the shape and range of the n64 stick, yes I said emulate the shape. Stupid octagonal restrictor. -=-=- Check out my excellent homepage!
Sat, 16 Apr 2016, 13:47
spinal	If anyone wants to do a little maths... I need to get the psx stick (0-127) to line up roughly with the n64 stick (0-84), especially on the diagonals. Currently I'm roughly dividing by 1.5, but I want the motion in the the opposite axis to be roughly 75% when the current axis is at full length. This wont make the diagonals right, but it 'feels right' when playing the same game with bot n64 controller and my adapted one. Anyone got any nice maths that would give a similar limitation and also make those diagonals line up? -=-=- Check out my excellent homepage!
Tue, 19 Apr 2016, 11:16
spinal	dammit! if its not one thing its another! its starting to pass the double check on the game im using, i assume anyway. im getting 'dont remove rumble pak' anyway. but my old rumble test (was sending the rumble command to the ps2 controller when pressing triangle) is no longer working. poop! -=-=- Check out my excellent homepage!
Mon, 25 Apr 2016, 02:12
spinal	I think I've got the thing working as good as I can get it... -=-=- Check out my excellent homepage!
Page : 1 2 Next Prev