The figures 6 and 1 just signify which PCB in the panel these were. The same figures can be found on Game Boy and SNES game PCBs.

The circled letter is supposedly where the PCB was manufactured.

The different ROM IC labeling is probably, because the NFR cartridges were produced using a different batch of ROMs or a smaller run that was given to Toshiba instead of Sharp.

Wasn’t it because the USB isn’t routed all that well and that’s why you have to keep cable lengths short? Maybe a ferrite would help, too.

The VUE-AA3A games use CR-1616 batteries with two leads, like these.

You might want to check out the following two threads:

[list]
[*]Homemade Link Cable
[*]Link Cable project interest
[/list]

cYa,

Tauwasser

Are these dumped and/or preserved for the future? How is each unit different from the other — just ROM, peripherals, too, etc.?

cYa,

Tauwasser

thunderstruck wrote:
If you look at the sales numbers of the original Kincet it was quite successful. It sold sold 8 million units in its first 60 days and has received the Guinness World Record of being the “fastest selling consumer electronics device”. I think it sold something like 24 million units. The new Kincet (that came with the XBox One) didn’t sell that well. It is hard to say if that is the Kincets fault or because it was bundled with the XBox One (which didn’t sell that great). However, the XBox One sales doubled after removal of Kinect from the bundle.

To be fair, there was also huge interest in the scientific and hobbyist community, because it was the first time that such a high-resolution depth sensor came attached with such a low price tag. I know my department at university alone bought 20+ Kinects right when they came out.

cYa,

Tauwasser

P.S.: Nice to see you sober up between the first and second paragraphs *Kincet :P*

RunnerPack wrote:
BTW, Tauwasser, why did you ask “why does it have to be RF?”, and then only offer RF-based solutions?

Sorry, I was making a distinction between RF as in home-automation, where you define the protocol yourself and BT with HID, where the protocol is fixed. I should have been more clear about that.

RunnerPack wrote:
I think Tauwasser’s idea to use the ISM-band radio modules makes the most sense for use on an actual SNES (or VB). AFAIK, there are no cheap BT host modules you can use for the receiving end.

It depends on what you mean by cheap. I’ve used WT12 chips by bluegiga to host the Wiimote before. While it’s true that it doesn’t have an HID host mode, there is very little decoding to do in software, meaning you can just connect using L2CAP. That’s ~30 EUR.

The iWrap stack is documented, but the documentation is a bit wonky in terms of optional arguments, argument lengths or expected formats — but workable. Bluegiga even have their own way of reading/writing GPIOs of the modules.

The WT12 is a bit old and not BLE, but you get the point. Look at the various standard profiles, particularly HID.

For prototyping, you might want to get a breakout board for some device with the right profiles, play around a bit and get it working initially. Also, aren’t there already bluetooth SNES pads available? If so, it might be easier to use one of those and only implement the BT2SNES controller bridge.

As for the actual implementation, you’ll need to know the data format the SNES uses. I think one of your previous forums posts even covered this. Then, choose a microcontroller and have it act like a shift register, i.e. SPI slave.
Bluetooth chips can usually be controlled via UART text commands from the microcontroller. So have a UART connection, a button for pairing and the proper mating connector for the SNES pad and you should get something off the ground.

It might be worth looking into one of the bluetooth SoC solutions out there, possibly saving some components/work, because the SoC would replace the microcontroller and dedicated bluetooth chip.

RunnerPack wrote:For IR, the transmitter just needs a transistor to blink one or more LEDs at the right rate. Actually, I would use two set up like an AND gate. One input would be the 38KHz (or whatever) carrier generated by one microcontroller pin, and the other would be the actual data coming from another pin.

The receiver is even easier, since you can just use one of those IR receivers they put in consumer electronics (which can be had for pennies or even free if you can scrounge) to demodulate the IR back into a stream of data.

No matter what medium you use, this sounds like a very fun project!

Well, and you need analog filters, probably simulate them, and you have the usual IR problems, i.e. lost button presses, noisy environment, other IR sources screwing you, etc.

I’m not saying it’s impossible, but it’s definitely more involved, because you need to know your stuff, the various encoding schemes etc.

cYa,

Tauwasser

Why does it have to be RF? Do you want to interface with an existing host or do you just need to send the control commands wirelessly?

I suggest moving to either 435 MHz or 868 MHz (frequently used in home automation) as sender and receiver units are available and they don’t need to regulatory approval.

However, if you just want wireless transmission, look into Bluetooth or Bluetooth Low-Energy (BLE). Chips and pre-made boards are available, less knowledge is required and when transmitting an HID-compliant profile, you don’t need to write a PC driver.

cYa,

Tauwasser

Bump. Let’s bring this back to page 1.

Any news are welcome, even if it’s just a keep-alive.

cYa,

Tauwasser

HonkeyKong wrote:
Are the pins numbered on the circuit board? Will take it appart and poke around when I get home.

It’s fairly easy to find. The pins aren’t numbered IIRC, but the keying of pin 4 (i.e. the absence of pin 4) will clue you in.

Power Good (PG) is actually used as #RESET (goes to all most chips) and goes out to the cartridge. So definitely you want to make sure that’s at a high level when VOUT has settles to 5V.

cYa,

Tauwasser

How about porting V810 to LLVM instead of trying to fix the gcc port? Added benefit of re-usability, clang, etc.

cYa,

Tauwasser

Take the VB apart, take macro shots of the mainboard. From both sides. You might get lucky and a member here can point out something obvious through visual inspection.

You might get even luckier and have the problem magically disappear once you re-assemble the VB.

It’s worth a try.

cYa,

Tauwasser

Interesting discussion. Just wanted to say that the Code39 barcode also checks out. It’s a mystery to everybody.

cYa,

Tauwasser

And now you place online poker adverts? :P?

Seriously, tho, is there a financing gap?

cYa,

Tauwasser

KR155E wrote:
Oh, I had no idea the wiki was offline. I’ll do my best to get it reprinted on PM.net!

Whoa, thanks for the quick fix, should’ve asked sooner 🙂

cYa,

Tauwasser

KR155E wrote:
64DD.net was PVB’s sister site for over a decade, and the decision to close it was not as easy to make as for Planet 3DS. But the forums have been pretty much dead for years, the code is rotting and the site is overrun by spammers. It was only work and not much fun lately.

Does this mean permanent closure but still everything accessible for posterity or deletion at the end of the month/quarter/whenever 64dd.net runs out?

KR155E wrote:
Pokemon-Mini.net is the only active PM community and requires next to zero maintenance work, it will stay where it is.

Any chance a backup of http://wiki.sublab.net/ or its information exists and could be made available?

cYa,

Tauwasser

[Tauwasser]

DogP wrote:
The VB already talks the same protocol as the SNES, so there’s no need for another MCU. […] If you pulled apart the SNES pad, you might be able to fix it by jumpering some wires…

Well, I’d imagine the different inputs doing different kinds of debouncing, maybe even different hold states (i.e. report pressing start only once, while D-PAD is reported continuously etc.)

So I’d say it’s a pretty big jump from “might be hot-wirable” to “no MCU required”. An MCU will definitely work. Also, you could do cool settings like “mirror right D-PAD onto left D-PAD”, have the battery monitoring right etc.

@L___E___T wrote:
Wah, that’s well outside the realm of how far I can get with this 🙁

It’s not as hard as it sounds. With a little initial investment you can rig something up, learn some electronics in the process and have a great time!

EDIT: While I’m not in any position to take on additional work or even commissions right now, I would like to point out that qwertymodo over at byuu’s site has some experience with the SNES protocol as well as hardware engineering.
Check this out. I remember him selling a few of his boards, so maybe he’d be willing to take on a commission on this SNES2VB adapter board.

cYa,

Tauwasser

• This reply was modified 9 years, 6 months ago by Tauwasser.

DogP wrote:
But just FYI… it’s not all that useful. The controller mapping has overlap, but obviously the VB has more buttons than the SNES.

Finally somebody mentions this! I was thinking this might be a problem, but couldn’t find SNES documentation in time before my brain popped this thread from the stack.

L___E___T wrote:
That might be really simple to you DogP but I already got lost when you got to ground, clock, data etc…

Basically, you would need a little adapter board that converts from SNES to VB format for you. Depending on the maximum clock rate of the VB joypad chip (BU3613F?), you can
[list]
[*]oversample the joypad
[*]sample way faster than the original VB[/list]

A little ATtiny would be able to do this trick, for instance.

cYa,

Tauwasser

Umm, thanks for the research, Guy Perfect. I wasn’t talking console-specific, but that doesn’t matter.

So it seems somewhat historic for sei to just mean ‘set the appropriate bit in the status word’ instead of ‘set enable interrupt [bit]’ (which is how I read it up to now) and thus is opposite of what it means on many current platforms including AVRs…

Weird. Anyway, do you immediately jump after sei? If so, you might want to insert a nop and see if that helps. Some platforms will only disable interrupts after the next opcode.

cYa,

Tauwasser

Guy Perfect wrote:
Other way around. The bit being set in the status register is called [font=Courier New]ID[/font], standing for Interrupt Disable. When the bit is set, not cleared, interrupts will be ignored.

So they use the same mnemonic as all the other platforms out there and make it mean the opposite of what it does on every other platform? That’s fucking brilliant…

cYa,

Tauwasser