We're using cookies to ensure you get the best experience on our website. More info
Understood
1,430 Replies made

diisco wrote:
.
.
.
USA tap requires NES/SNES PSU lead.
Japan tap requires Famicom/Super Famicom lead.
.
.
.

In the U.S., the NES and SNES use different plugs (and voltages; I think the NES one outputs 9V A.C. and the rectification/regulation is done in the console; THIS KIND COULD DAMAGE A VB!) on their respective A.C. adapters.

I don’t know about the Japanese systems.

Yes. The controllers are exactly the same, so the port where the battery box/tap connects is also the same. The only difference is the barrel-jack (on the tap) into which the AC adapter itself is plugged.

The U.S. tap uses the proprietary SNES adapter while the Japanese one (I think) uses a standard barrel-plug, but I don’t own one, so I don’t know the dimensions, pinout, etc.

Maybe a FAQ should be started for stuff like this…

Well, I can always use a microcontroller, I was just trying to come up with something cheap and simple so that we can get some analog controls into the hands of the community.

I’m trying to get a nunchuk cheap on ebay. If anyone here is also looking, please don’t outbid a*****m on a nunchuk! (or my black silicone case) 😉 There’s plenty of them on there!

I would say that you have a pretty firm grasp on what is cool… 😉

(Except that that camera/tape is definitely NOT cool! 😛 )

Also, PENTUPLE-POST FTW! 😛

Any plans to try a “Wii Motion Plus” attachment? Of course, it’s just a little box, so it would probably have to be attached to a VB pad or some other controller – or to a head-mounted VB – to be very useful. I haven’t heard what specifically it adds in the way of sensors, though.

As an addendum to my “PS[1/2] controller and link port” question: Would it be possible to do software i2c on the link port enough to talk to these Wii accessories with no Propeller?

*/me goes to refresh his knowledge of the protocol*

EDIT: Okay, here’s what I found out:

I2C uses two open-drain lines: SCL (clock) and SDA (data) and the link port only has one (COMCNT) which means some external hardware is required (a 3v3 source would be needed, in any case) but it still seems doable, especially since there are no strict clock rate requirements.

EDIT: Okay, nevermind…

I just went over the docs again and only the COMCNT pin can be directly written/read. But, the controller port should work.

  • This reply was modified 17 years, 2 months ago by RunnerPack.
  • This reply was modified 17 years, 2 months ago by RunnerPack.

It would be extra cool if someone could get a good enough (monochrome scan through a red filter gel, maybe?) scan of the in-game text for someone to translate.

Hey, that’s a pretty cool find, jojobean!

Someone should make some clones of that and have a contest to find the best hands-free gamer 😀

They could use SNES, Flash or maybe some custom-made games. They could even use ROMs of the contest games that Nintendo has done in the past, like the “Nintendo World Championship”.

BTW, Dan, unlike a copyright, a trademark doesn’t just cover the content of a word or phrase but also the font or other design in which it’s presented.

Wikipedia wrote:
A trademark is […] typically a name, word, phrase, logo, symbol, design, image, or a combination of these elements.

Just FYI… 😉

Sweet! Great minds think alike. 😉

I’m curious about how you send data to the uC, though.

And yes, I would be interrested in having a PCB layout for this. What make/model of uC are you using? If it’s a PIC, maybe I could just adapt the code/circuit to the 16F877A sample I have lying around.

BTW, you should think about adding this and all your other projects to the wiki 😀

That’s pretty sweet, DogP!

I think you and KR155E covered all the “wacky ideas” I could come up with 😛 except maybe:

A) It could be used with a regular VB pad to remap the buttons (and maybe make Mario Clash playable, finally :-P)

B) It could be used to implement the idea I just posted to the Wiki: http://www.vr32.de/modules/dokuwiki/doku.php?id=analog_control

C) Mattel/PAX Power Glove!!!!1111one 😉

On a related note, have you ever tried hooking a PSX pad directly to the link port? It’s one of the many things I’m sure is possible but have never found the time to do. 😛 It wouldn’t require a uC, so it might be more accessable to the average user.

Again, nice job!

Do you mean there is a picture but it’s very dark, or that there is no picture at all?

Is this your first time using a VB? Maybe it’s working fine and your brightness expectations are set too high 😉

What game(s) are you playing? Some games have brightness settings that you can try to adjust, but there’s not really any reason it should get dimmer over time. LEDs generally either work or don’t…

As an aside, you could probably use a little more patience when using a message board 😛

If you’re handy with a soldering iron, it would be possible to power it up with an AC adapter and use an SNES pad to give it a bit of a test.

Here’s the pinout:

Attachments:

What a great idea!

*Note to self: start setting aside more VB dev’ing time*

😀

Well, I understand how to use them, I was just explaining that I don’t like how they work. 😛

Whatever…

I couldn’t even finish watching that stupid deodorant one 😛

So… I guess you got my vote by default, but yours was still pretty funny.

D’oh! I was thinking of the German diphthong “ei”…

Here is a good page for Japanese pronunciation: http://www.fonetiks.org/sou3ja.html

It is very hard to make a stereoscopic image that small with such a limited palette!

I would gladly trade sixteen Worlds and 512 Chars for one more bit of color depth!

Anyway, here’s what I have so far. It’s quite ugly, but maybe you can use it for a skeleton to build on, or something…

The left image is on the right (I’m in the “cross-eyed” camp when it comes to free-viewing ;-))

Attachments:

I would just check the X and Y distances from the center of the sub to the center of the chest.

if ((abs(treasurexpos - xpos) < sub_width) && (abs(treasureypos - ypos) < sub_height))
{
	you_win = true;
}

(The function returning the absolute value of a number is left as an exercise for the reader. ;-))

P.S. I could make an attempt at a 3D sub sprite for you.

There’s your problem, then. Don’t declare functions inside others.

You’re doing great, so far, but maybe it’s time for a C primer; just to get the basics.

Did you insert the getBGMapChar function inside your main function?

Which line has the mentioned error, the function declaration or the if statement?

Also, you don’t need to rename the arguments used in the function to match your main program.

That looks pretty good, KR155E. BTW, what tab width do you use? I like four column tabs, myself.

I think the pronunciation of “seiryu” is more like sire-you (which I think I put in a newer local version of the header).

I’ve been sitting on the rest of this post for a few days, so it’s not a direct reply to your post, but here are some thoughts I had after reading VirtualChris’s experiences with the lib and reading this thread again:

1. Let’s assume that the “veterans” (KR155E, DogP, jorgeche, et al.) will not be using the new lib and will instead continue to use and mutate their already mutated versions.

2. Let’s forget about the existing library and example code base and let them coexist with the new one. One or two examples can be ported to/created for the new lib.

3. We can start over and implement everything discussed in this thread in the best (and most future-proof) way we know how based on the current state of VB knowledge, which includes (IMO):

a. Making (at least two) layers of functions:

i. The basic, low-level stuff (switching on/off the display, copymem, etc.) can be in a static library because it won’t change much, if at all. It should also be optimized as much as possible (asm, etc.).

ii. The utility functions (fading the BRT regs, reading the pad, etc.) should be as now (except split into a .C and a .H) so that they are optional. This layer could also exist in multiple files. They should be optimized, but not at the expense of readability. It goes without saying that every “layer” should be commented profusely.

b. Wrapping functions in #ifndef’s to allow overriding by the user (especially useful for the dummy interrupt handlers).

c. Fixing/standardizing the synch/delay stuff, etc.

d. Unifying the notation scheme, tab size, formatting, etc.

e. Adding dasi’s sprintf and standardizing the font situation (esp. W.R.T. handling international characters).

f. (Optional) Selecting and optimizing a set of affine-transform functions, sound functions, etc.-basically anything that seems handy.

g. (Optional) Designing non-copyright-infringing default warning and adjustment screens.

h. Discuss and add to this list…

Well, theoretically, the 400-500 MHz ARM and PowerVR chip should be able to handle it, the problem is finding someone familiar with iPod/Phone development and a desire to port it and spend the time to optimize it for playable speed.

But, if someone like that is found, there’s no reason 3D can’t be done with anaglyph just like the PC versions.

  • This reply was modified 17 years ago by RunnerPack.