Could someone explain such behaviour of $4016 and DMCs, regarding an extra read?
Zepper wrote:
Could someone explain such behaviour of $4016 and DMCs, regarding an extra read?
In the case that a DMC DMA cycle falls on a 6502 bus read cycle (say a read from $4016/7), the processor will be stalled for 3 bus cycles (so here, $4016 will be read 3 times with the bus data thrown away), then on the 4th cycle the DMA address is put on CPU bus (DMC data is read in), and on the 5th cycle the processor will continue on from where it was stalled (making this a fourth read from $4016/7 that actually counts).
In short, when DMC DMA coincides with a read from $4016/7, you don't simply lose one joypad button read, you lose 3 button reads.
The way most games handle this issue, is to read the joypad buttons in twice and compare the results (all buttons match = good joypad data, otherwise read joypad a 3rd time and use that). The caveat of this is more wasted CPU time, and the fact that the joypad buttons may change from the first read to the second, and a DMA cycle might effect the 3rd reading of the joypads (meaning that you will still get corrupted joypad data, but this is a highly improbable scenario).
digilogistist wrote:
(...) the processor will be stalled for 3 bus cycles (so here, $4016 will be read 3 times with the bus data thrown away), then on the 4th cycle the DMA address is put on CPU bus (DMC data is read in), and on the 5th cycle the processor will continue on from where it was stalled (making this a fourth read from $4016/7 that actually counts).
Interesting. The CPU isn't "suspended", but "stalled"... meaning extra reads using the address on CPU bus.
digilogistist wrote:
In short, when DMC DMA coincides with a read from $4016/7, you don't simply lose one joypad button read, you lose 3 button reads.
This statement appears to conflict with blargg's test case for this exact scenario. Referring to dmc_dma_during_read4/source/dma_4016_read.s it clearly shows the expected pattern is 1 lost read [expected pattern is 8 8 7 8 8], not 3, during a DMC DMA interrupted LDA $4016.
I currently have it implemented exactly as you suggest--I lose three controller reads and fail blargg's test with the pattern: 8 8 8 5 8. I haven't bothered yet to go back and figure out why I haven't got it right.
It's one deletion, not three. This can be seen in the signature bits row in the Eighty demo.
tepples wrote:
It's one deletion, not three. This can be seen in the signature bits row in the Eighty demo.
Thanks tepples. Just trying to quell the spread of disinformation.
Where were you since then? :-/
Zepper wrote:
Where were you since then? :-/
I interpret this as "why didn't I speak up earlier". If that interpretation is correct, it is because the purported behavior matched my results. I had forgotten that that was a test I have yet to pass.
If my interpretation is incorrect...I don't get it.
That's ok. 
I meant "you were away".
I will try such test at home.
I meant "you were away".
I will try such test at home.
tepples wrote:
It's one deletion, not three. This can be seen in the signature bits row in the Eighty demo.
OK, I stand corrected. I wonder however, would only one joystick button deletion (DMC DMA coincidence) happen on a Nintendo machine like this? (is this even an official Famicom schematic?) I guess I would just like a bit of a technical explanation as to how 3 consecutive CPU reads from $4016/7 turn into only 1 joypad read caused by a DMC DMA coincidence.
- Is $4016/7 only being read once, instead of 3 times? (so... DMC DMA lasts only 2 clocks in this special case of a $4016/7 address coincidence?)
- Is the phi 2 signal held high for 3 clocks in a row during $4016/7 access?
- Are the 2A03's $4016/7 address decoder signals (pins 35 & 36) not internally decoding the phi 2 signal? (this would explain the additional logic used on the Famicom joypad schematic to include the phi 2 signal decoding into the controller clock signals, but why is this is not done on the NES?)
If it is relevant that a DMC DMA joypad coincidence causes one button deletion and not three, then perhaps someone can enlighten me as to the logic behind this behaviour, because I was obviously wrong about something I thought I knew about the NES.
Perhaps your answer lies here...?
http://visual6502.org/JSSim/index.html
http://visual6502.org/JSSim/index.html
When the DMC wants to read a byte, the 6502 needs to be pulled off of the bus so it doesn't create bus conflicts with the address lines. The best way to do this is to suspend the CPU by using the CPU's RDY pin. (In computer systems, the RDY pin is used for things like floppy disk access, where the byte you want to read may not immediately be ready.)
So if the CPU is being suspended, there's no way it can be reading from an address 3 times while the DMC is using the same bus to access a different address.
I'm not certain how the bit deletion from 4016/4017 works, but it seems to be something like the CPU trying to access an address (it sends out the address and a clock cycle occurs), and then is suspended (so the DMC can send out an address), and when the CPU resumes, it puts its address back out with another clock cycle. I could be wrong though.
So if the CPU is being suspended, there's no way it can be reading from an address 3 times while the DMC is using the same bus to access a different address.
I'm not certain how the bit deletion from 4016/4017 works, but it seems to be something like the CPU trying to access an address (it sends out the address and a clock cycle occurs), and then is suspended (so the DMC can send out an address), and when the CPU resumes, it puts its address back out with another clock cycle. I could be wrong though.
Zepper wrote:
Perhaps your answer lies here...?
http://visual6502.org/JSSim/index.html
http://visual6502.org/JSSim/index.html
More likely it's here...
www.qmtpro.com/~nes/chipimages/visual2a03/expert.html