Of course, 'done' is relative. There's so much that can still be done to a 'done' thing. There's lots of revisions I could do to the board to free up pins (like the ATTENTION pin I mentioned previously), save power, make things simpler, and things I could do to the software. But it works, it works, it works. Redesigning the PCB: • Change the DIP components for surface mount. This would result in a smaller, cheaper-to-produce board. Only matters if I wanted to mass-produce it. I use DIP because I can use DIP. I have never worked with surface mount before. • Remove the connection to pin 26 and put ATTENTION on pin 9. It would free up a right-hand-side RPx-able pin, which could be useful. But not really a priority. If I changed the board to surface mount, I'd have a whole different arrangement of pins to work with, and the board layout would be completely different. • I could remove the safety resistors, and add in debouncing pF ceramic capacitors. I like the current-limiting resistors though! I haven't worked with ceramics in this way before. On the Amiga's large rear D ports for Serial, Parallel and Disk Drive, all the pins there have capacitors though. Is that a sign I should emulate that arrangement? • Make the DIP switch less ugly and have a nice printed legend for the modes. I haven't decided what modes I'm going to have yet though. • Move the JOYMODE incoming signal to pin 16. The current system works perfect well as it is for immediately making the PIC enter CD32 joypad emulation mode, but it does so by using INT1 and INT2 resources mapped to an RPx. There's an INT0 I could have used, but it's permanently mapped in hardware to pin 16 on the PIC24FJ32GA002. To make the board design as flexible and extensible as possible, I should use fixed resources that match my requirements before using more flexible ones if possible. • If I change the board, the electrical characteristics will change, and I'll have to investigate the resistor values all over again. • Use a resistor array for the pull ups. If I find one that's cheaper than discretes, that's great. • A smaller voltage regulator than the Micrel big ol' three pin fellow. Between the PS2 pad and the PIC I must be using perhaps 60 mA, not the 1 A or above this 'bulletproof' regulator can provide. But you use what you've got. There's a diagram in the PIC datasheet about reducing power draw by supplying 2.5V to the PIC's logic core by interposing a diode between the 3.3V supply and the PIC's supply pins. Sounds complicated. No thanks. Software changes: • There's a race condition in the PS2 update I think. It's smart-ass to use a struct bitfield for storing the CD32 reply word, but it isn't changed atomically. I should use a bitfield and then copy that into a variable that is always a valid representation of the inputs at some point in time (either the immediate present or immediate past) rather then allowing the SPI module's stronger interrupt to slurp up a potentially half-updated reply word to put into the SPI2BUF. • I haven't implemented autofire yet. • I want to have a different button layout for Up to Jump games that maps Playstation X to Up and Playstation O to Fire1 for games like Wolfchild and Assassin. I think this guy deserves a case. He may be a prototype, but he's done well.