KTRL CD32 - Amiga CD32 custom gamepad

[thgill]

I would be interested in a couple of these too!

[kazmat]

Wow cool

I need 1 or 2 kits for me

[kgc210]

Good work on the PCB's I would be interested in two replacement board kits.
Would like to get back into using my CD32.

[arananet]

Great kit, congrats!

[tekopaa]

Iam intrested about fully assembled black snescd32 controller and shipping to Finland

Yey! That's look fantastic! I would ask for 2 at least. What price?

[MickGyver]

I had a setback with the replacement PCB version, for some reason it doesn't work and I haven't found the reason why. Everything should be connected properly, might have something to do with the smd versions of the ICs. Anyway I got (what I think is a brilliant) idea and started working on doing a Atmega version with some unique features, more on this later, I just wanted to update you about the progress.

[Amigajay]

Ah shame about the setback, its really annoying when you cant find a reason why!
Cheers for the update, hope all goes better!

[robinsonb5]

Originally Posted by witchmaster

I had a setback with the replacement PCB version, for some reason it doesn't work and I haven't found the reason why. Everything should be connected properly, might have something to do with the smd versions of the ICs. Anyway I got (what I think is a brilliant) idea and started working on doing a Atmega version with some unique features, more on this later, I just wanted to update you about the progress.

That's a great idea - but there are a couple of pitfalls to watch out for.
Because the Amiga's POTX/Y lines do double-duty as analogue input and digital IO they have unusual characteristics, and it's not uncommon for a microcontroller to be unable to pull those lines low enough for the Amiga to see a logic 0. You may need to factor an external transistor into your design.
(Actually, thinking about it, this same issue could be why your existing boards aren't working, if the shift register IC doesn't have exactly the same characteristics as the original?)

You'll also need to make sure your shift register reacts very quickly. I did something similar using a PIC once, but struggled to get it working quickly enough, especially once the extra delays from the external transistor were taken into account. Another interesting option is the Cypress PSOC chips - there's a low-end PSOC4 chip with an Arm M0 CPU and a small amount of programmable logic on board - so with that, it's possible to do the shift register in hardware, which relaxes the timing requirements on the software quite considerably.

Test widely, with as many different models of Amiga and as many different games as possible - there are many variants of the CD32 pad reading code out there, all with slightly different timing requirements!

[MickGyver]

Originally Posted by robinsonb5

That's a great idea - but there are a couple of pitfalls to watch out for.
Because the Amiga's POTX/Y lines do double-duty as analogue input and digital IO they have unusual characteristics, and it's not uncommon for a microcontroller to be unable to pull those lines low enough for the Amiga to see a logic 0. You may need to factor an external transistor into your design.
(Actually, thinking about it, this same issue could be why your existing boards aren't working, if the shift register IC doesn't have exactly the same characteristics as the original?)

Thanks for the help! At the moment I'm thinking of only replacing the shift register with an Atmega microprosessor and leaving the tri-state buffer in place to have better compatibility. I have already have the CD32 gamepad working with the lines going directly to the microprocessor but it's not safe to do it this way because of the input/output on the same pin issue (this could do damage to the microprocessor or the Amiga). Also I'm only testing on my A500 at the moment, it's working on that but I guess the problem with logic zero can show up on other motherboards.

The current design is exactly the same as the small pcb I first made and is identical to the original CD32 gamepad circuitry, the only difference is that I use smd components, they are of the LS family though, as the original. For the first version I confirmed that 74HCT and 74LS worked, 74HC did not work (HC is CMOS, LS and HCT are TTL).

Originally Posted by robinsonb5

You'll also need to make sure your shift register reacts very quickly. I did something similar using a PIC once, but struggled to get it working quickly enough, especially once the extra delays from the external transistor were taken into account. Another interesting option is the Cypress PSOC chips - there's a low-end PSOC4 chip with an Arm M0 CPU and a small amount of programmable logic on board - so with that, it's possible to do the shift register in hardware, which relaxes the timing requirements on the software quite considerably.

In my experiments with the Atmega328 I have set up external interrupts for the clock and latch pins so it should react quite quickly to the clock. I do everything with setting the registers directly (not using the slow attachInterrupt and using direct port manipulation). First I was updating the shift data output on RISING edge but this wasn't reliable, instead updating the data on the FALLING edge of the clock seems to be reliable on the A500 at least, but haven't tried other software then JoyPortTest for the moment. JoyPortTest can work without lowlevel.lib, don't know what the practical difference is. I will look into the Cypress PSOC chips, sounds interesting, I will experiment with the Atmega now and see how it goes (I'm used to that processor).

Originally Posted by robinsonb5

Test widely, with as many different models of Amiga and as many different games as possible - there are many variants of the CD32 pad reading code out there, all with slightly different timing requirements!

Ok, good to know! I guess the timing for when sending the clock signals and reading the data can vary in the code. I have three CD32, two A1200 and three A500 machines I can test on here. Will test with different games also of course, I hope I will get this to work since I have some nice features I would like to implement!

[robinsonb5]

Originally Posted by witchmaster

it's not safe to do it this way because of the input/output on the same pin issue (this could do damage to the microprocessor or the Amiga).

It's always safe to short the pin to ground - since the pin on the Amiga is designed to have a mouse button attached to it - the only danger is if the Amiga's driving the pin low while the uC is driving it high. You can avoid that by using "input with weak pull-up enabled" instead of "output logic high". But using the tristate IC is a much better idea.

Also I'm only testing on my A500 at the moment, it's working on that but I guess the problem with logic zero can show up on other motherboards.

Yes, I never saw this issue on an A500 or my A4000/030 when I had that, but it apparently affected some A1200s and I think A600s too. I don't know about the CD32 (The same problem shows up with some PC mouse adapters whe then right mouse button doesn't work.)

Ok, good to know! I guess the timing for when sending the clock signals and reading the data can vary in the code.

Yes, basically the code polls a CIA register multiple times to create a fixed delay, allowing the shift register to do its thing. Some games poll the register fewer times, cutting the timing to the absolute minimum.

[Amiga1992]

robinsonb5, have you ever worked again on your adapter? I still have your beta

[robinsonb5]

Originally Posted by Akira

robinsonb5, have you ever worked again on your adapter? I still have your beta

Unfortunately not - I've moved house since then and have a lot less time for such projects these days. Hopefully I'll pick it up again some day!

[Amiga1992]

Well I'm here to test any time you need!
I haven't used it in a while, should bust it out.

[MickGyver]

Originally Posted by robinsonb5

Yes, basically the code polls a CIA register multiple times to create a fixed delay, allowing the shift register to do its thing. Some games poll the register fewer times, cutting the timing to the absolute minimum.

Ok, thanks! I was just looking at some CD32 gamepad reading routines but I'm more or less an assembly illiterate. What I know is a serial shift register sets the output to the first "input pin" value directly after loading, then for every clock pulse the output of the shift register will correspond to the next "input pin" value.

So is a "normal" CD32 gamepad read routine something along these lines:?

1. PotX (pin 5) is set low to enable shift mode of the LS165.
2. PotY (pin 9) is read?
3. Button1 (pin 6) is set HIGH and then LOW (clock pulse for the LS165)
4. Small wait then Amiga is reading PotY (the wait varies between games)
5. Repeat 3 and 4 until all data shifted.
6. PotX (pin 5) is set HIGH to enable load mode of the LS165.

[robinsonb5]

Originally Posted by witchmaster

So is a "normal" CD32 gamepad read routine something along these lines:?

1. PotX (pin 5) is set low to enable shift mode of the LS165.
2. PotY (pin 9) is read?
3. Button1 (pin 6) is set HIGH and then LOW (clock pulse for the LS165)
4. Small wait then Amiga is reading PotY (the wait varies between games)
5. Repeat 3 and 4 until all data shifted.
6. PotX (pin 5) is set HIGH to enable load mode of the LS165.

Pretty much. Pin 6 is already high when the routine enters the main loop for the first time, and it's explicity set to output mode before the loop starts. And there's a final step, returning pin 6 to input mode and setting it high again.

Incidentally, remember that you're imitating an eight bit shift register, so when you've shifted out your seven buttons, shift out an extra '1' bit. Some routines use this extra bit to detect the presence of a CD32 pad.

[MickGyver]

Originally Posted by robinsonb5

Pretty much. Pin 6 is already high when the routine enters the main loop for the first time, and it's explicity set to output mode before the loop starts. And there's a final step, returning pin 6 to input mode and setting it high again.

Incidentally, remember that you're imitating an eight bit shift register, so when you've shifted out your seven buttons, shift out an extra '1' bit. Some routines use this extra bit to detect the presence of a CD32 pad.

Thank you, much appreciated! My work continues...

[robinsonb5]

Originally Posted by witchmaster

Thank you, much appreciated! My work continues...

Another subtlety that I'd forgotten about until I saw Daedalus's post in the detect-CD32-controller-from-Blitz thread - as bits are shifted out, they're replaced with zeroes - so you should shift out the seven buttons, a single '1', then zeroes until the shifting has finished.

[papa_november]

Have you checked out this thread?? You may want to change the shape of the D-pad contacts for better performance.

Also, how is the d-pad itself on that SNES clone controller? Lots of cheap d-pads lack the center nub on the bottom that stops all four directions from being pressed at once, or implement it so poorly it might as well not be there.

[MickGyver]

Originally Posted by robinsonb5

Another subtlety that I'd forgotten about until I saw Daedalus's post in the detect-CD32-controller-from-Blitz thread - as bits are shifted out, they're replaced with zeroes - so you should shift out the seven buttons, a single '1', then zeroes until the shifting has finished.

Ok thanks! I have this accounted for in my code now. The shift register on the CD32 pad has the serial input connected to ground (multiple shift registers can be chained). When "shifting" more bits than eight before resetting with the latch will result in zeroes shifted out.

Originally Posted by papa_november

Have you checked out this thread?? You may want to change the shape of the D-pad contacts for better performance.

Also, how is the d-pad itself on that SNES clone controller? Lots of cheap d-pads lack the center nub on the bottom that stops all four directions from being pressed at once, or implement it so poorly it might as well not be there.

Thanks, good spotting! I will change the D-pad contacts accordingly, they are a bit sensitive now when you mention it. The DPAD on the SNES gamepad clones can be pressed down in the center so all directions are pressed, but this hasn't been a problemfor me (I use the usb gamepads on my PC also). It would of course be good to do something about this... Maybe there is a good way of modding the DPAD...