Joypads 3/6 Button Response Timings

[r57shell]

Hooray! I made this nice ROM powered with SGDK. (edit: ROM updated)
edit2: Now it outputs even numbers. There is no way to wait odd count of cycles. And, now instead of 1/2/3 it shows 4 because smallest is NOP = 4 cycles.
edit3: ROM updated, added 4 more variants for test: using new move.w a2,(a0) trick. Old fixed ROM here.
It does read responses. I have recieved one feedback already.
Responses for that 6 joypad was 0,0,0,0,0x35,0,0,0,0x35,0,0,0x3C70. (edit: this was caused by bug)

Hmmm... I guess I need to put some explanation, what it does.
It does figure out minimum cycles of M68k timeouts needed between

Code: Select all

move.b #p,(a0) ; p = current phase.
<delay>
move.b (a0),d0
<delay>

to achieve correct data read. It starts from phase 0x40, then 0x00 and then altering until end of joypad reading process.
No Reset means, that it ends up in state where 0x00 was writen last time into port.
So, for 6 button pad it is 15 delays. And, last one, is delay that counts expiration time of reset-timer inside of 6 button pad.

Stef, if you see this, I can share sources if you wanna include it into SGDK samples.

I would like to see as many as possible other results.

Notes:
1) Port should be selected correctly!
2) Joypad type should be selected correctly!
3) "No Reset" mode - I'm unsure about it, but as far as I see, it works.

Please write:
1) what model of Genesis was used for test.
2) is it official console or clone.
3) what joypad used, and again, is it official or nope.

[Sik]

And for what matters, two NOPs should be guaranteed to work because that's what Sonic 1 uses and nobody in their right mind would make a controller that doesn't work with that game.

You don't need a delay after reading from the port (only after writing) so testing for that is useless.

[MetalliC]

perhaps this bit of Eke's tech info will be useful
https://github.com/ekeeke/Genesis-Plus- ... -172347221

[r57shell]

And for what matters, two NOPs should be guaranteed to work because that's what Sonic 1 uses and nobody in their right mind would make a controller that doesn't work with that game.

If it's true, then it should show not bigger than 4 for appropriate delays.

Reason is: there are many implementations, and many of them using long-time reading opcodes.
And all of them varying NOPs count.

You don't need a delay after reading from the port (only after writing) so testing for that is useless.

I was suspicious about that fact, and because I can test it too... I decided to TEST it, why not?! Proofs better then theory.

Ok, will see.

Official 3 button pad, official console:
No Reset: 4, 0, 0, 0, 4, 0, 0, 0, 4, 0, 0, 0
With Reset: 0, 0, 0, 0, 4, 0, 0, 0, 4, 0, 0, 0
Official 6 button pad, official console: same but last timeout is 0x4201, 0x4159.
Same for pirate 6 button pad, but last timeout is 0x2B7B, 0x2C28.
So, it means, for this three pads one nop "inside" is enough

[Sik]

I believe there were some 6-pads that don't work well with less than one NOP, but I could be wrong.

The four NOPs thing comes from Sega telling developers to add a 2µs delay, which happens to be equivalent to about four NOPs. The thing is though that MOVE in itself already has a delay (fetching the opcode and operands) so using less NOPs actually works. For example, MOVE.B #$40, (A0) would have 8 cycles of delay before the actual write (4 cycles spent reading the opcode, 4 cycles spent reading the #$40). Most developers didn't bother with this (or placed other operations in its place), it looks like Yuji Naka did though.

You could probably shave off four cycles by using something like MOVE.B D0, (A0) (and having the $40/$00 in the register beforehand). You can't avoid those initial four cycles reading the opcode though, so that's as fast as it gets.

[r57shell]

You could probably shave off four cycles by using something like MOVE.B D0, (A0) (and having the $40/$00 in the register beforehand). You can't avoid those initial four cycles reading the opcode though, so that's as fast as it gets.

Problem is that I'm using all d0-d7 to store results of joypad reading cycle.

Hmm actually, after thinking a bit more, I have idea.
I was using

Code: Select all

@loop:
move.w #time, d7
dbf d7, @loop

for long delays, and actually I can set up d7 into 0x40 before whole request, and then, if I insert loop, I'll add moveq #$40, d7.
So, after any delays it will store 0x40. But I have to solve sending zero into port. And here is solution: move.b a2, (a0) where a2 is zero
Will try that soon

[Sik]

I don't think that's a valid combination... (address registers can't have byte operations done on them)

EDIT: actually, you could just do a word operation, right? (high byte goes ignored by the port)

[r57shell]

I don't think that's a valid combination... (address registers can't have byte operations done on them)

Yeah, when I check reference first, I somehow missed note for source:
"For byte size operation, address register direct is not allowed"
Because I thougth as in all other places it should be marked right in table. So, probably yes.

EDIT: actually, you could just do a word operation, right? (high byte goes ignored by the port)

It's possible workaround. Depends, does it rely on LSB/MSB signals or not. If it's not, then word into 0xA10002 should work
Hmmm then, it require move.w a2,-1(a0), that is longer.
Maybe... just use everywhere word size, and 0xA10002 as port... Will see.