Discussion in 'The Cutting Edge' started by JacksonS, May 29, 2017.
This is just THE sexiest thing.
This is actually amazing. Literally impossible to top lmao.
I really like what you've done! I just found out about this entire console modding scene last night, and it's so intriguing. For your design (which is astounding btw), why did you use DS Lite buttons? I understand the 3DS joysticks, as I've looked at other projects and seen them, but is there an advantage of the DS Lite buttons?
GameCube buttons are too big for the case. Also, there is a huge supply of buttons from the DS family of consoles due to 3rd party replacement shells but GC buttons must be harvested from a 1st party or 3rd party lookalike controller.
I understand the use of DS buttons - they're not as crazy as the GC ones. I'm just curious why he used the DS Lite buttons on both of his portables, instead of another model. Are there any differences?
The DS lite Is the only one that has squishy buttons and they’re also slightly taller. This makes them easier to use with 3D printed cases
The main reason is what @Aurelio said, the DS Lite buttons have a squishy membrane that I prefer over tactile buttons.
DS Phat buttons are ok. They even come in whatever color you want - as long as that color is gray.
The sexiest thing. Looking forward seeing the finished unit.
Dude, can you do an Okami gameplay video?
I can't quite do that with the internal controllers since there is no nunchuck . But at least I could connect a separate controller for a video. I may do that.
is 4.3 screen too small for gaming? is is 3.5 okay?
The 4.3" screen is good for widescreen games. I wouldn't go any smaller. The 3.5" screen is basically the same height, but a 4:3 ratio instead of 16:9, so it's just as good when you don't need widescreen.
All of these custom PCBs have given me an idea: could you design a board that would translate a button push into shaking a Wiimote? Shaking a portable around generally isn't the smartest thing, but your internals are looking so solid that it probably wouldn't matter!
Doing something like that is definitely possible, although it's not ideal
Yeah, I'm sure you could emulate the accelerometer with a microcontroller or something similar. The accelerometer has a publicly available datasheet, so all the info should be out there. I've been shaking my prototype a lot and not heard any rattling yet, so I think I'm good .
could work well with a versatile controller emulator;
Very nice! It's a weird coincidence because just a couple weeks ago I was looking into emulating the IR camera with a touch screen as well. As for spoofing the accelerometer, I was thinking about using the touch screen microcontroller to calculate the real-time XY rate-of-change and use that as accelerometer data. Don't know how that would feel scribbling on the screen that much though. It would also only leave one hand for buttons and joystick unless you build buttons onto the stylus .
Anyway really clean work. Can't wait to see the completed project
You say it's on the wiimote peripheral I2C bus, which I'm assuming refers to the same bus that hosts the classic controller, motion plus, etc. How is it then passing IR data? Is the camera on that selfsame bus? I was aware it doesn't pass pixel data but blob coordinates, but I wasn't aware it was functionally a peripheral. Care to share your code?
Yes, it's exactly the same bus. The speaker and the EEPROM work on this bus as well. Pretty much the only thing that does not work on this bus is the accelerometer. The read address for the camera is B1 (write address is B0), so the Wii remote sends out this address on the I2C bus whenever it wants to read from/write to the camera. I had to make a microcontroller respond to that address to act as the camera.
What I did was take a single touch screen coordinate and separate it into two blobs equidistant from the actual coordinate. Then the blob data has to be sent in one of three different ways, determined by the Wii remote. I referenced this information a ton because I don't have any logic analyzer or oscilloscope and only had this to go on.
My code is written in C for a PIC microcontroller with a built-in I2C module, so it may not be very helpful. This snippet is the entire interrupt sequence, which runs every time there is an acknowledge detected on the I2C bus. This doesn't include any of the code where I collect data from the touch screen (that part I'm still working on).
Separate names with a comma.