Custom pcb??

[Ilavos]

I started work on a custom PCB that'll include dreamcast,ps/ps2 and xbox controllers. I'm still in the documenting phase though. My idea was basically to program a microcontroller with all the outputs and have a switch that determines which output to generate. Has anyone tried this before?U know,just so that i dont waste my time.
I does seem possible though.Keep you guys posted on my research.

[tau]

I started work on a custom PCB that'll include dreamcast,ps/ps2 and xbox controllers. I'm still in the documenting phase though. My idea was basically to program a microcontroller with all the outputs and have a switch that determines which output to generate. Has anyone tried this before?U know,just so that i dont waste my time.
I does seem possible though.Keep you guys posted on my research.

Don't give up, despite what any people, corporations, or supervillains might say. I believe in you.

[NiteWalker]

If you get it to work you have struck gold. I'd order about 40.

[Ilavos]

Damn you guys make it seem like the holy grail or sumthin. Its that hard? Good! I love challenges!

[Taiki]

Yes, it's hard. I sure hope you know something about ASIC or FPGA design, quite frankly.

But the documentation is out there if you know what you're doing! Good luck!

[Ilavos]

I am familiar with ASIC and FPGA but i'm not rich enough nor do i have the time to use those types of IC's. Like i said in my first post my intention was to use a microcontroller.More specifically a Microchip or Cypress brand 8 bit one. Asics would be a bitch and FPGA are way too powerfull for what i need to be done.Plus my intention is to make a DIY available to everyone and I doubt most people have 50000$ FGPA programmers in their basement( Fuck you to anyone who actually does...rich brats.)Thanks for the support!!

[UnholyKnight]

I'm not sure how you could make it work, although it may be possible. The easiest way would be to somehow get information from the console, but that doesn't happen. If the console were to communicate backwards (send electricity to the controller) it would be dead.

MAYBE each system uses a different voltage when powering the control which could be measured by a multimeter, and then you could build in a multimeter type device that would detect the power being given to the controller and distinguish which console it is that way.

[Ilavos]

Good point.From what I see all controllers seem to be running under about 5V.But other than the power issue, the main thing i'm struggling with is actually coding the chip right now.The controllers seem to be running at different clock cycles.Getting all that into place as well as giving the right response is the main issue. I figured i'd leave it to the user to choose between which console to operate under.

[Numbski]

While we're talking about custom PCB's there's a custom PCB I wouldn't mind taking a crack at, but it requires someone to "donate" a Sanwa FLASH. That upgrade board....that's the only difference between the standard JLF and flash. It's probably not too difficult to reproduce, and do a group purchase from whomever is contracted to build them.

Too bad I'll never get my hands on a board... :\

[Taiki]

Good point.From what I see all controllers seem to be running under about 5V.But other than the power issue, the main thing i'm struggling with is actually coding the chip right now.The controllers seem to be running at different clock cycles.Getting all that into place as well as giving the right response is the main issue. I figured i'd leave it to the user to choose between which console to operate under.

GC, Xbox, Dreamcast and most other pcbs use 5v, the ps2 seems to use 3.3v

[Toodles]

While we're talking about custom PCB's there's a custom PCB I wouldn't mind taking a crack at, but it requires someone to "donate" a Sanwa FLASH. That upgrade board....that's the only difference between the standard JLF and flash. It's probably not too difficult to reproduce, and do a group purchase from whomever is contracted to build them.

Too bad I'll never get my hands on a board... :\
I already posted the schematic for the sanwa flash in the p360 thread a long time ago.

Each transmitter portion:
+5v-------220 Ohm--LED---GND
Each receiver portion:
+5v----Receiver*----+-----|>o------output to jamma/pcb
|
+--4700 Ohm----GND

|>o is an inverter gate from the HC14.

The hard part is getting it laid out in such a way that some manufacturing house would actually make it. Take some measurements for the size and shape of a normal JLF pcb and try to fit it in a way that doesn't require 2 mil tracks and 2 mil spacing between tracks :)

[0746]

I am familiar with ASIC and FPGA but i'm not rich enough nor do i have the time to use those types of IC's. Like i said in my first post my intention was to use a microcontroller.More specifically a Microchip or Cypress brand 8 bit one. Asics would be a bitch and FPGA are way too powerfull for what i need to be done.Plus my intention is to make a DIY available to everyone and I doubt most people have 50000$ FGPA programmers in their basement( Fuck you to anyone who actually does...rich brats.)Thanks for the support!!

Its possible both with ASIC/FPGA and microcontrolers. But you will save yourself a lot of design time doing the microcontroler way. And well...hmmm...you dont need $50000 programmers for programming FPGAs lol. Last FPGA board I bought, had a built in programmer with usb <--> pc connection. I could program the entire fpeg in minutes and the entire thing cost me like $150USD ish. So it should not be that expensive unless you are buying top of the line programmers that program 5000 FPEGs per second or soemthing lol.

[Ilavos]

GC, Xbox, Dreamcast and most other pcbs use 5v, the ps2 seems to use 3.3v

Thats what I though.Thanks for confirming that for me.Based on the ps1 schematics, the controller gets 7v from the cd-rom drive and 3.3 from the system.Guessing the 3.3v is what is used for the controller.

Its possible both with ASIC/FPGA and microcontrolers. But you will save yourself a lot of design time doing the microcontroler way. And well...hmmm...you dont need $50000 programmers for programming FPGAs lol. Last FPGA board I bought, had a built in programmer with usb <--> pc connection. I could program the entire fpeg in minutes and the entire thing cost me like $150USD ish. So it should not be that expensive unless you are buying top of the line programmers that program 5000 FPEGs per second or soemthing lol.


I did make it sound like they all cost $50k huh?lol.I have no doubt it could be done with either asic or fpga.But 20$ microcontrollers would be easier for everyone to get a hold of.Like i was saying earlier I want anyone to be able to use this.

[0746]

Microcontroller is probably your only venue. I am yet to see FPGA used in a practical application rather than prototyping or whatever. And unless you have a lot of funding, it wont be possible for you to print those tiny chips you find inside controller pcbs. And well, you said it yourself. Controllers are running at different frequencies and different voltages. So you cant really do much with FPGAs without making things extra complicated.

You should stop worrying about the cost and focus on the system. If you are really worried about cost then printing your pcb (the board itself without any circuitry) should cost you a bulk unless you are printing like thousands at a time or open up a company in china.

And well, really good project. Good luck with it. You will never fail before you give up =)

[Taiki]

Thats what I though.Thanks for confirming that for me.Based on the ps1 schematics, the controller gets 7v from the cd-rom drive and 3.3 from the system.Guessing the 3.3v is what is used for the controller.




I did make it sound like they all cost $50k huh?lol.I have no doubt it could be done with either asic or fpga.But 20$ microcontrollers would be easier for everyone to get a hold of.Like i was saying earlier I want anyone to be able to use this.

What you could do is that on the PlayStation input lines, have it accept 3.3v and have a voltage regulator regulate it to 5v.

Of course, the PS controller also works from 3.3v -> 5v, so...

[Numbski]

I already posted the schematic for the sanwa flash in the p360 thread a long time ago.

Each transmitter portion:
+5v-------220 Ohm--LED---GND
Each receiver portion:
+5v----Receiver*----+-----|>o------output to jamma/pcb
|
+--4700 Ohm----GND

|>o is an inverter gate from the HC14.

The hard part is getting it laid out in such a way that some manufacturing house would actually make it. Take some measurements for the size and shape of a normal JLF pcb and try to fit it in a way that doesn't require 2 mil tracks and 2 mil spacing between tracks :)

I've never seen the flash board, so I'm having a hard time visualizing how it functions. Getting the layout done isn't a problem. I have friends who are electrical engineers that would be more than happy to work that out for me. In exchange for some of my services, that is. ;) You have Reciver with an asterisk there, and an HC14 is mentioned, but not in your layout. :\ Is the fully schematic in another thread?

[Numbski]

Actually...we're making this harder than it is, aren't we (regarding the flash)?

If we can get just one PCB (preferably off of a flash that has died, I hate sacrificing a working one....), desolder the components using a heat gun, clean the plain pcb up really good, and scan it in at high resolution, and then use that either in a vector-tracing program or whatever to generate an etching template. Then wherever you take it, all they have to do is etch the traces. Of course, I don't know how difficult the surface-mount solders are on the flash board, so who knows. Perhaps it could be modified to use hole-through so that we could get the boards etched, and then go in on a group buy of the component kits and just assemble them ourselves. *shrug*

[Ilavos]

Microcontroller is probably your only venue. I am yet to see FPGA used in a practical application rather than prototyping or whatever. And unless you have a lot of funding, it wont be possible for you to print those tiny chips you find inside controller pcbs. And well, you said it yourself. Controllers are running at different frequencies and different voltages. So you cant really do much with FPGAs without making things extra complicated.

You should stop worrying about the cost and focus on the system. If you are really worried about cost then printing your pcb (the board itself without any circuitry) should cost you a bulk unless you are printing like thousands at a time or open up a company in china.

And well, really good project. Good luck with it. You will never fail before you give up =)


Lol. Thanks for the advice. I was thinking MC from the beginning.And i have no intention of giving up either.I'll see this thing to the end!

What you could do is that on the PlayStation input lines, have it accept 3.3v and have a voltage regulator regulate it to 5v.

Of course, the PS controller also works from 3.3v -> 5v, so...

I'll try that thanks. I think I have about enough info on how to set this up. I really hate the theory part anyways.I'm gonna start putting everything togheter soon.Hope my controller ports dont give up on me...It wont be the first time though lol. Thanks for everything Taiki.Keep you guys posted on whatever comes up.

[chippermonky]

concerning a custom flash PCB: you really don't need to mimic the original flash schematics or even the PCB shape. You just need to make something that fits and doesn't get in the way. The only thing that you really need the original PCB for is the exact placement of the optical encoders. The schematics for how to hook up the HC14 could also be taken from a p360.

That's actually not a bad idea. Shit, it's actually pretty damn simple. I'm willing to try and etch a PCB and cut it to shape to fit a JLF. anyone know where I can get HC14s for cheap?

edit: did a google and I can't find any distributors, anyone else know of an apropriate opto encoder I can use?

And Ilavos: That's awesome, pity that they use different clock cycles: I think you should just add a switch rather than try and integrate all the consoles and their respective clock cycles. I mean, honestly, no one is going to use more than one console at the same time (although it would be nice for finding discrepancies in ports). I'm not sure if I'm oversimplifying the problem here.

[chippermonky]

bump

[Ilavos]

And Ilavos: That's awesome, pity that they use different clock cycles: I think you should just add a switch rather than try and integrate all the consoles and their respective clock cycles. I mean, honestly, no one is going to use more than one console at the same time (although it would be nice for finding discrepancies in ports). I'm not sure if I'm oversimplifying the problem here.

Yeah, the switch was pretty much what i was going for. But I do need to add the different clock cycles for each controller.Or else it's going to be way too much stuff at one time for the console to really handle.It doesnt need to be an exact match. But since the MCU is running faster than any of the controllers, my guess is i'll have to add some empty loops to kill time in between executions.Thanks for the input!

[Rufus]

I think each of the controller busses supplies the clock anyway. (I know the PS2 does.)

[Ilavos]

I just though that the controllers must be read by the game console.So basically if it is running faster or slower than the regular cycles of the controller,what appears on screen (i.e what is executed) might not be the same has what the person is expecting to see. Besides out of all the controllers the craziest one is by far the dreamcast one! lol.

[chippermonky]

hey ilavos, are you gonna have to rewrite the code from scratch based on documentation or are you going to be able to reuse/rewrite already written code? Just curious

[Ilavos]

I'm going to be using the asm language of the mcu so yeah i'll pretty much have to re-write everything.But having source to look at or use as reference would be great help if you can provide me with anything!

[chippermonky]

I'm going to be using the asm language of the mcu so yeah i'll pretty much have to re-write everything.But having source to look at or use as reference would be great help if you can provide me with anything!

well, this is the only source of info I have. You've probably found it already

http://www.gamesx.com/controldata/gencont.htm

and their hidden PSX page: http://www.gamesx.com/controldata/psxcont/psxcont.htm (it has working code on the site, but the link is dead)

[Ilavos]

Didnt know about the Hidden page thanks.It also seems they have some kind of controller converter tutorial coming up.I might look at it if i'm not done by then.Thanks alot.

[Toodles]

The uber simple one line per button/direction (Neo-geo, atari), the 157 based controlers (Genesis, Saturn, TG-16) have been done bunches and simple, and the clock based ones (NES, SNES, PSX/PS2) have been done bunches and documented.

Work on the others that aren't so easy. N64 and Gamecube has some documentation about how they communicate on the web, and should be pretty easy as a single bidirectional serial line. Sadly, it has no clock, and each bit is sent 3us low 1us high for a low bit, and 3us high 1us low for each high bit. Dreamcast is uberfast and pretty complicated, and no source code for PICs has been found for it (There is however compiled .HEX files for SX microcontrollers for a cool converter. Wish I knew how to decompile it. Id love to see it implimented in PIC.) The whole 'two wire no clock' is bad enough, but to embed commands by breaking that pattern (hold one line down and 5 or 7 high-low transistions on the other line, for things like system reset) make it a bitch. Xbox, PS3, and Xbox360 all have USB based implimentations that quickly change from the normal implimentations.

If you're wanting to work at the bottom and build your way up, you can start with code from http://devcast.dcemulation.com/mods/unicont/maincont.php here. The best single source of controller porotocol is the gamesx.com site, but go into the wiki instead of just the main page. I was very happy to see they put up the PS2 (dualshock 2) data format as well as the dualshock 1 and digital formats we've had forever.

Im working on something similiar of course. Pick your system and an order implimentation and I'll bet money I get it implimented faster :) Maybe a little challenge will kick things into gear.

[chippermonky]

I think it'd be easier just to slap two ICs in there instead of integrating the DC code with the rest seeing how the .hex is already available. By the way toodles, where is the .hex for the SX controllers, I might actually try using that instead of salvaging for precious non analog DC PCBs. Oh and aren't there tons of ASM decompilers out there? I'm not too familiar with this sort of stuff sorry.

And damn, I suppose I shouldn't even bother trying to join the race :P. Toodles, I thought you said you were being uber lazy about the whole ultimate controller IC thing, is the challenge spirit getting to ya ;)?

[Toodles]

Just prioritizing the projects, but recent talks got me thinking I should try for the sanwa flash replacement first. Either TDC Final2 -> Sanwa Flash -> Universal PCB, or TDC Final2 -> Universal PCB -> Sanwa Flash. Im trying to keep focused on one project at a time :)

The SX code I mentioned is here: http://park7.wakwak.com/~huye/kaihatu.html
There isn't a direct replacement for a controller pcb. He has a ton of stuff dealing with the DC, including a hardware bot for leveling up in Phantasy Star Online :) and converters, but Im not 100% sure on which ones convert which way. If I could just see the damn code, Id be willing to learn enough SX assembly to document it, at least to see the minimum amount I could get away with for the DC to properly recognize. There's enough code there to make one, but unless its decompiled, I can't do anything with it; its not a controller replacement. The only other source of information on how the maple bus works is a little bit from Marcus Comstedt's site which is incomplete for implementing it all but nice to check for another viewpoint on how the bus works, and the patent documents, which are long and painful but complete.

Id also like to see the code for the gamecube controller stuff. I have yet to find a decompiler for SX code though. I found one for Microchip's PIC code, but none for SX code. If there is, PLEASE let me know. The only other option decompiling it would be by hand, if the datasheets for the SX chip included the byte code for the instructions like PIC datasheets do. I think I'd rather try to create it from scratch.

The DC works at 2 megabits/sec, but the way the data is sent, you're going to want well more then 2 MIPs to make sure you catch the data right. The PIC I had planned to use (because 1. USB HID code for it is easily available 2. Lotsa lotsa I/O pins 3. The USB bootloader available for it means people without PIC burners can update it with just a USB cable, the same one they'd use for playing the stick on MAME or whatnot) Is 12 MIPS(48MHz. PIC's run one instruction per four cycles), which may be enough. The SX chips are one instruction per cycle, so they can run one helluva lot faster than the equivalent PICs, but I havent found any resources for setting them up a USB devices, and that's a major selling point for me. Oh, and you can sample the PICs for free. :)

Actually, I just realized, if that one Im looking at actually does Saturn->Dreamcast conversion, it COULD be a controller replacement. Youd need the schematic it shows, and a couple of 74XX153's for the saturn replacement. (But Toodles, wouldn't that lag?) The 153's would not cause lag; they have changing times rated in nanoseconds. Whatever delay or problems would be caused by the SX chip. Damn, now I gotta figure out if my cheap ass programmer can program that SX chip. Thanks for giving me more work, dick! :)

EDIT: Scratch that. The Saturn->DC converter is 1. Huge and 2. For sale only. No hex or schematic. Definitely other DC stuff, if I can figure it out.

[chippermonky]

no problem toodles! Oh, and your like stealing my flash project that I stole from numbski. But could you point me to where I can get the light sensors if you know? It should be pretty easy after I get the sensors, but I have no idea where I can find those except maybe rip them off from my p360. I guess I should do a little bit of research but it's easier if you've already done it for me :).

by the way, I'm trying to get into pic programming because I want to make a hardware QWERTY-DVORAK switch for my keyboard. How tough is it to learn? And also, you seem really fond of using assembly, I suppose it is more efficient, but is that the only reason why you choose assembly over C?

[Toodles]

no problem toodles! Oh, and your like stealing my flash project that I stole from numbski. But could you point me to where I can get the light sensors if you know? It should be pretty easy after I get the sensors, but I have no idea where I can find those except maybe rip them off from my p360. I guess I should do a little bit of research but it's easier if you've already done it for me :).

by the way, I'm trying to get into pic programming because I want to make a hardware QWERTY-DVORAK switch for my keyboard. How tough is it to learn? And also, you seem really fond of using assembly, I suppose it is more efficient, but is that the only reason why you choose assembly over C?
I dont remember the part numbers, but Im pretty sure I saw ones very similar if not identical to the ones on my flash in the digikey catalog. The part looked the same, no idea if the specs are the same. Sorry, no idea on the part number. The digikey page, if I remember right, had all of the parts (optical tranceiver? Optical transistor? Dont remember the name) were laid out in a nice table that had the receiving field (180 degrees, 90 degrees, 30 degrees, etc. You do not need a wide field at all so keep it tight) along with the wavelengths that activated it (so you can compare to the LED transmitter you're planning on.). When I was trying for a flash previously, I just marked down a pair that looked like it was the best fit and closest match physically to whats on the flash. When getting your spacings on the pcb, remember that its setup to activate that line with the light is NOT broken. The default is all light paths are broken when the stick is in nuetral.

Are you trying to replace the pcb in an existing keyboard, or rig an interface between keyboard and PC? If keyboard and pc, I wouldnt even want to deal with an interface if it was a USB connection, since itd have to be a USB host and a USB device. An interface for a PS/2 connection wouldn't be bad at all; its pretty slow serial communication if I remember right. Replacing the existing pcb in a keyboard wouldn't be hard software wise, but machining everything to physically layout right in the keyboard would be painfull.

As for C vs assembly I just go with what's easiest. A lot of the USB code for the PIC I planned on is in C, and I can inline the assembly whenever I need so I suspect the universal pcb, if/when I work on it, will be a mix. Dreamcast is the only system I expect to have to use assembly one, because of the speed needed (6 instructions per each bit to/from the DC, including knowing which line(s) to raise or drop)

[Ilavos]

My initial plan was to only keep it to DC,PSX/PS2 and Xbox.It seems you are going for somekind of universal one that includes all controllers.Once i get this part done i might consider that,but i think this is complicated enough to start out with.

The DC protocol IS a bitch.It is beautiful in the way it works,but it's a pain to try and reproduce or keep up with.But it seems that other than having to setup the code so that it actually cuts up the data and sends it on 2 different output pins every 5us and sending the right checksum,it should be fine (hoping marcus' info isnt wrong,but i totally trust the guy as far as DC stuff go.He's like the king of DC reverse engineering lol.)

I've never really looked into SX mcu's and quite frankly learning another programming language is the last thing i feel like doing lol ,although asm is pretty simple once you got one down.Besides,buying another programmer....:sad:

Anyways thanks for all the info guys.And Toodles, just giving me the money would save you a lot of trouble.I have paypal.:wgrin:

[Toodles]

Happy to be proven wrong; just please release whatever code you come up with, and Ill do the same.

[Ilavos]

I'm no codehog don't worry.I intented on sharing everything from the start.Good luck to you.Let's see where this takes us!

[chippermonky]

I'm no codehog don't worry.I intented on sharing everything from the start.Good luck to you.Let's see where this takes us!

And I'm definitely not modest about using other people's code ;)

thanks toodles for the info, I'll look into it right now.

edit: Oh, and toodles, I plan on making it external. so something that goes between the ps/2 port output of the keyboard and the input of the PC. I don't even want to touch USB right now, I'll do that when I have more experience. But thanks, you answered my question, my overpriced controller board is coming in soon so I'll have something to play with :).

[Numbski]

Hey chipper, is this the same HC14 you're referring to? The texas instruments part?

http://eecue.com/images_archive/eecue-images-24157-Furby_Opto_encoder_TI_01CJ4CK_HC14.html

[Unreallystic]

*cracks knuckles*
I'm working on huge project, its in the prototype stage, but I'm trying to create a method for allowing multiple console access to the same joystick. The concept isn't new - PSX/DC/PC/XBox are the main systems I'm looking at, with as it becomes available, an add-on for XBox360. I could take a switch system using transistors, and wire up all these controllers internally, but 1. Thats going to be a BITCH in terms of man-power hours 2. a wire fuck fest no matter how well I try to sort them 3. I'd need four of them *4 player setup - prototype will only have 2 though*. So I'd prefer to program them to a MC, however I only took one MC programming class, I've forgotten most of the shit I learned *we did 75% of are stuff in assembly yuck started doing it in C++ write before finals time so that was minimal*. I remember reading this thread maybe a month ago, and was curious where people are in this and what I could do to help out - double E with a computer science background *C, C++, basic, perl *minimal*, and assmebly*.

So yeah, let me know what I could do to help...
- :bluu:

[chippermonky]

I thought the main advantage to using an IC was that wiring would be a whole lot easier. In some MAS sticks, they just take an IC and solder straight to the i/o pins of it. You'd have to add on an oscillator, regulator and a few resistors at most I'd imagine.

Numbski: I'm hoping that's it, I actually googled and found the same thing, but where the hell am I gonna get those. I'm just ebaying cheap photodiodes for this project. I kinda bought the wrong ones though so that's 10 bucks gone :(.

[deadfrog]

I don't really have anything tangible to contribute, as I'm only just beginning to learn about pad hacking and PCB's, but I thought of an interesting possibility and I'm really not sure how feasible it would be.

Take a look at one of Byrdo's customs, called Gief: Top (http://www.byrdo.org/images/Arcade%20Stiks/Zangief%201.jpg) | Angle (http://www.byrdo.org/images/Arcade%20Stiks/Zangief%202.jpg) | Close-up (http://www.byrdo.org/images/Arcade%20Stiks/Gief%20panel.jpg)
He used the switches " to enable/disable button layouts for various games." It made me wonder...

The idea of a plug-and-play solution is undoubtedly very cool, but expecting the machine to detect for itself to what it's hooked up sounds ambitious. Would it be feasible, to use switches and have the player specify what it's plugged into without expecting the machine to detect it? I don't know if this would be a nightmare on one PCB or not...

[Toodles]

The idea of a plug-and-play solution is undoubtedly very cool, but expecting the machine to detect for itself to what it's hooked up sounds ambitious. Would it be feasible, to use switches and have the player specify what it's plugged into without expecting the machine to detect it? I don't know if this would be a nightmare on one PCB or not...
Having the microcontroller detect the cable type would be as easy to as the switches you showed, and would never run the risk of accidental or short.

Let's say you hooked those five switches up to the microcontroller. You'd prolly pull them high with a pull up resistor, and ground the other pin so that the PIC would always see it as HIGH (on) or LOW (off). Your five switches would have 32 possible combinations, and every time it was plugged in, the PIC would check those lines and determine which system was connected.

From the PIC's point of view, this is exactly what I'm doing with the detection lines. Let's say pins 1-5 are the pins I dedicate for system detection. WHen I make the connector and cable for that system, I either ground those lines (LOW or off) or tie them high to the power line (HIGH or on), for the exact same 32 possible combinations.

For those curious about where I'm at on the projects, Im in the middle of the sanwa flash project, got the parts scoped out and tested on the breadboard. Sucker pulls more mA than I'd like, but its less than the original flash pulled. The original idea from ShinAce was to assume 3.3v to everthing and drop the voltage if 5v was supplied with diodes. It didnt work to my liking. The amount of voltage dropped by the diodes was unreliable and the LED's wanted too much power at 3.3v. So instead, Im putting a dc-dc converter ( MAX631 - 8 pin DIP chip, only the chip + 2 components required) right on the board. So uber easy into anything, since it can be powered with anything from 2v to 15v just fine. Flash on a PSX without worry. BatchPCB.com will route out the funky shape for me easy, but won't do the inside circle, so I'm gonna have to dremel that out by hand.

Unreally: Do what you feel like doing. If you want to work with microcontrollers, go ahead and do so; I'd kill to see dreamcast support in a PIC without having to try from scratch. If youd rather work with just the electronics, I could sure use more information on the protocols used by the N64, gamecube, the 'gamepad' addition to the Wii controller, and the PSX memory cards. There's also the almost impossible problems like the Xbox360 controller's protection.

[Numbski]

http://focus-webapps.ti.com/general/docs/sitesearch/searchdevice.tsp?partNumber=hc14