How hard would a PS2 to Apple II joystick adapter MCU be?

Discussion of development of software for any "obsolete" computer or video game system. See the WSdev wiki and ObscureDev wiki for more information on certain platforms.
Post Reply
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

How hard would a PS2 to Apple II joystick adapter MCU be?

Post by tepples »

I've been discussing a microcontroller project with koitsu if anyone's interested. How hard would it be to make an MCU read a DualShock and output PWM?

Several old computers and video game consoles are designed to use paddles (non-centering absolute rotary inputs) or 2-axis analog joysticks:
  • Apple II: DE9, 2 to 4 paddles or 1 to 2 2-axis joysticks, 3 buttons
  • Atari 2600: 2 paddles, 2 buttons
  • Atari 5200: 2 axes, several buttons
  • IBM PC game port: 4 axes, 4 buttons
All these are potentiometers (variable resistors), normally read by passing a voltage through the pot, feeding the output to charge a capacitor and waiting until an NE555 or compatible timing comparator determines that the cap has charged to 2/3 of reference voltage. (See description of Apple II paddle circuit.) The trouble is that the existing stock of paddles and joysticks are wearing out, and it's also becoming hard to find repair parts such as 150 kilohm pots.

So I thought of a solution: use pulse width modulation (PWM) instead of variable resistance. Output high Z on the pin for an amount of time proportional to the position of the stick, and then slam it to Vcc momentarily. The circuit after the comparator shouldn't be able to tell the difference, should it?

In fact, almost the same protocol would work for the Zap Ruder tech demo, which waits between the top of the screen and when the Zapper's photodiode turns on. Except the "zapkernel" (input routine of Zap Ruder) expects a light pulse that dissipates after 25 lines or so, so it can tell the difference among a Zapper pointed at the screen, a Zapper pointed off-screen (dark for the whole frame), and no Zapper at all (always light even during vblank).

So the idea is to make a microcontroller read a DualShock controller and convert the joystick position from PCM to PWM.

Because joysticks are auto-centering and paddles aren't, a useful "paddle mode" for such an MCU may require a different form of input translation where the pulse width is proportional to arctan2(x, y), with readings held when the stick is near the center dead zone.
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: How hard would a PS2 to Apple II joystick adapter MCU be

Post by lidnariq »

I'm not certain whether this "direct emission of time as ADC value" is actually simpler than just using a open-collector pull-up transistor with a current limiter and high PWM frequency to implement an adjustable current source. After all, you have to detect when the hardware discharged the capacitors before you can start your timing loop. But at least the IBM PC joystick port should already have the requisite current limiting resistor on its input to keep the microcontroller's output from getting in a fight with the 558.
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: How hard would a PS2 to Apple II joystick adapter MCU be

Post by koitsu »

Thanks for posting this, tepples.

My main concern right now is for joysticks, specifically a single-player joystick (but from reviewing the pinout, it looks like supporting two wouldn't add much complexity). Paddles are (IMO) more complicated given the design of the PS2 controller, and the games which use paddles on the Apple II are substantially fewer than those which use joysticks.

I also want to point out that the hookup for this should be the DE9 port, not the internal 16-pin port. I realise the 16-pin port or even something in a card slot provides lots more capabilities, but I'm trying to keep this as practical as possible. It also needs to work on an Apple IIC/IIE, so any "IIGS-isms" might need to be configurable in some way.

There are some other resources I wanted to post here for anyone who would be interested in helping with this, in particular the first link, which contains successful homebrew efforts to build a replacement Apple II joystick and contains relevant circuitry schematics. (Please understand: my goal is not to build a replacement joystick -- I strongly feel an adapter for existing joysticks that are easily purchasable is a much more practical and affordable method). These links are just kind of a "brain dump" of stuff I've come across (either read or skimmed) and found relevant:

http://quinndunki.com/blondihacks/?p=2225
http://quinndunki.com/blondihacks/?p=2332
http://apple2.info/wiki/index.php?title ... nnector.29
http://www.dagenbrock.com/blog/?p=130
http://rich12345.tripod.com/OPHP/gameport.html
https://www.kickstarter.com/projects/8b ... oid-mac-pc -- I really don't like this product, too expensive too
http://retroconnector.com/products/appl ... -apple-ii/ -- bad idea IMO (re: USB device compatibility), too expensive
https://lukazisloot.blogspot.com.au/ -- neat, but isn't what I'm aiming for
http://tulip-house.ddo.jp/DIGITAL/AppleJOY/english.html
http://atariage.com/forums/topic/252596 ... -joystick/
http://www.atariarchives.org/ccc/chapter9.php
http://apple2.org.za/gswv/a2zine/faqs/C ... S.html#004 -- for PC-to-Apple-II converter details (diagram)
http://www.classiccmp.org/cini/pdf/Appl ... ystick.pdf -- site is often down but I HAVE gotten this to work before
http://www.goldstarsoftware.com/applesi ... Manual.PDF -- page 2-28 onward is extremely relevant

I can't find it in my browser history right now (argh!), but I did come across a page which went over some of the differences between Apple II models (for example something about the IIGS supporting up to 4 buttons, while the IIC/IIE only support 2 or 3, things like this). The last PDF I link to, however, is for the IIGS and goes over what it offers.

BASIC code for verifying 1st joystick behaviour (this can work from both true Applesoft BASIC as well as the built-in ROM):

Code: Select all

10 PRINT "X= "; PDL(0); TAB(15); "Y= "; PDL(1); TAB(30); 
20 IF PEEK(49249) > 127 THEN PRINT "  B0"; 
30 IF PEEK(49250) > 127 THEN PRINT "  B1"; 
40 PRINT
50 GOTO 10
The two PEEK locations correlate with $C061 and $C062. PDL() makes things easy for getting axis data (it's more complicated otherwise (no real way to do it in BASIC due to timing; certainly possible in 65xx though)).
Post Reply