Yo! I have a dead CD32 controller which I'd like to repair. But just as a challenge to myself, I want to re-implement the internals using an Atmel AVR, probably an ATMega8-16PU. Apart from "for the fun of it", this would mean I could have a switch to maybe use the controller with SNES or Mega Drive or something. *shrugs* Anywho, I found this project: https://github.com/johey/superpad He has implemented the CD32 interface with a polling method, and using the internal 2MHz oscillator. I'd like to use the ATMega8's two external interrupts, and an external 16MHz crystal. All I need to know is if 16Mhz will be fast enough. What is the fastest polling rate the CD32 uses?
I'm not sure how the controller is decoded in the Amiga (if the clock strobe is manual or automatic, or if the controller bus feeds the 68K data bus or a memory-mapped register), but assuming the worst case theoretically the 68K can read memory 4 clock cycles apart. Assuming the clock strobe is de-asserted immediately prior to a read instruction, it would seem you have (1/14.31818)*4 = 279 ns until the bus must be valid. Thankfully the 68K's data strobe is asserted the entire address cycle, which buys you the whole 279 ns. Still, 279 ns isn't much time. At 16 MHz the AVR can perform 4 instructions in that period, actually fewer because the systems aren't synchronous, so you definitely lose one instruction to jitter. You also must lose another instruction to the interrupt. Assuming the instruction pipeline isn't invalidated demanding another instruction period, you will have at most 2 instructions to put the button data on the output and enable it.... Oh crap, assuming the controller bus drives another buffer (to the 68K data bus) you also have to subtract 30 ns or so for the propagation. So, yeah... Personally I'd just use the two logic chips and feed the shift register in parallel with the AVR, which can be trivially tasked with decoding your physical controller at a far far lower rate without concern to latency. It may be acceptable occasionally, but it's never a GOOD idea to implement standard logic with microcontrollers--especially not logic which interfaces with a data bus when you don't have a slave parallel ports AND instructions aren't an order of magnitude faster than the read cycle.
Don't those AVRs have an SPI interface? I would think you could just run the SPI in slave mode and use that to shift out the data... Hm. I guess "SPI interface" is like "ATM machine" or "LCD display". But you know what I mean... Edit: After thinking about this for a bit, you could probably use the USART in synchronous + external clock mode to do the same thing, which would also give you a double-buffered transmitter.
I bit the bullet and built the thing with jellybean components, and so far it works nicely: I discussed it in this thread, because hopefully the information will help the guy. Maybe. :S http://www.assemblergames.com/forum...d-frustrations&p=707662&viewfull=1#post707662
Cool stuff, I've just been messing around with the SNES controller protocol (v. simple) for my PiSNESBot.
