Understanding RESPx

[andre_nho]

Hello,

 

I'm new to this forum and to Atari programming, and I'm still trying to understand a few things.

 

Let's say that in my kernal I have the following simple code (I set GRP0 in the VBLANK):

 

  SLEEP 23
  sta RESP0
  sta WSYNC

  REPEAT 191
  sta WSYNC
  REPEND

 

I see that my player 0 sprite appears in the horizontal position 15 (or absolute position 83 [15+68]).

 

My code for positioning my sprite is:

 

SLEEP 23 ; 23 cycles [69 TIA cycles]

sta RESP0 ; 3 cycles [9 TIA cycles]

 

This amounts to 78 TIA cycles. But my sprite is positioning after 83 cycles. Where those 5 cycles come from?

 

Thank you in advance!

 

André

[Cybergoth]

If it helps any, its not your fault. TIA execution time I assume. This delay also differs for the missilies and the ball.

 

One thing I learned lately, is that any 6502 instruction can actually last 2 cycles longer than you think. You just never notice this, as the CPU already piplines the next instruction those 2 cycles earlier. Might be that this effect is responsible for 2 of those delay cycles already.

[andre_nho]

Well, thank you anyway! Atari's hardware is really challenging, specially when things happen without a reason

 

One thing I learned lately, is that any 6502 instruction can actually last 2 cycles longer than you think.

 

How did you find that out??

 

André

[Cybergoth]

How did you find that out??

 

Someone recently quoted the relevant passages from the original MCS6500 manual on nesdev

[Kroko]

I think there is a 5 pixels delay for the players and a 4 pixels delay for ball and missiles

 

EDIT: http://www.atariage.com/forums/index.php?s...st&p=894475

 

And if you really want to know the reason, read this: http://www.bjars.com/resources/tia_hw_notes.doc

Edited September 22, 2006 by Kroko

[SeaGtGruff]

How did you find that out??

 

Someone recently quoted the relevant passages from the original MCS6500 manual on nesdev

Oh

 

My

 

Gawd

 

 

Thanks for the link, I'm going to bookmark this stuff. I wonder if this might help to explain some of the "delays" that need to be accounted for when updating the PF registers in an asymmetrical playfield?

 

MR

[SeaGtGruff]

And if you really want to know the reason, read this: http://www.bjars.com/resources/tia_hw_notes.doc

Yes, that's another excellent doc to have-- although I don't think I've fully grasped all of it yet (and it utterly amazes me that people can figure this stuff out by looking at schematics... but then, schematics look like gibberish to me-- I really ought to take some courses in that stuff, or buy "Schematics for Dummies").

 

MR

[vdub_bobby]

If it helps any, its not your fault. TIA execution time I assume. This delay also differs for the missilies and the ball.

 

One thing I learned lately, is that any 6502 instruction can actually last 2 cycles longer than you think. You just never notice this, as the CPU already piplines the next instruction those 2 cycles earlier. Might be that this effect is responsible for 2 of those delay cycles already.

Hmmm...that actually makes sense, and is somewhat implied from this document.

 

For example, check this out:

Zero page addressing

 Read instructions (LDA, LDX, LDY, EOR, AND, ORA, ADC, SBC, CMP, BIT,
					LAX, NOP)

	#  address R/W description
   --- ------- --- ------------------------------------------
	1	PC	 R  fetch opcode, increment PC
	2	PC	 R  fetch address, increment PC
	3  address  R  read from effective address


 Read-Modify-Write instructions (ASL, LSR, ROL, ROR, INC, DEC,
								 SLO, SRE, RLA, RRA, ISB, DCP)

	#  address R/W description
   --- ------- --- ------------------------------------------
	1	PC	 R  fetch opcode, increment PC
	2	PC	 R  fetch address, increment PC
	3  address  R  read from effective address
	4  address  W  write the value back to effective address,
				   and do the operation on it
	5  address  W  write the new value to effective address

For example, note that ADC is grouped with "Read" instructions but it really should be a Read-Modify instruction - an ADC $80 instruction, according to this chart, first fetches the opcode, then fetches the address, then reads from the address and then...is done? Obviously, it needs to actually perform the addition at some point and then, according to that post on nesdev, transfer that result to the accumulator.

 

Interesting...just looking through that document, it looks like these instructions are pipelined:

EOR, AND, ORA, ADC, SBC, CMP, BIT, and all instructions that use implied addressing.

 

Assuming that document is correct, this generally shouldn't have an effect when writing to the TIA since you generally don't use any of those instructions to write to TIA registers (since you can't read from them).

 

So I don't think this has any effect on the TIA delays.

 

EDIT: Just noticed this for the first time at the very bottom of that "Documentation for the NMOS 65xx/85xx Instruction Set":

				Notes

 See the MCS 6500 Microcomputer Family Programming Manual for less
information.

Edited October 2, 2006 by vdub_bobby

[supercat]

For example, note that ADC is grouped with "Read" instructions but it really should be a Read-Modify instruction - an ADC $80 instruction, according to this chart, first fetches the opcode, then fetches the address, then reads from the address and then...is done? Obviously, it needs to actually perform the addition at some point and then, according to that post on nesdev, transfer that result to the accumulator.

 

The 6502 must know the address for any read cycle, and the address and data for any write cycle, before the previous cycle is complete. The only exception is that the high or low order 8 bits of the address may be taken directly from the data returned by the preceding read. No other modification is possible.

 

Thus, if I do "LDA $84", the CPU fetches the opcode and operand; having just fetched $84, it can route that directly to the LSB of the address bus (the MSB simply gets zeroed). If I do "LDA $1234", the CPU can transfer the $12 directly from the data bus to the MSB of the address bus (having read and buffered $34 the cycle before).

 

Indexed zero-page operations require an extra cycle because the address value to be output isn't the same as the value fetched the cycle before. Indexed non-zero-page operations usually don't require an extra cycle, since the MSB of the address will usually be the last thing fetched from the data bus while the processor was computing the LSB. Note that even if the processor had a 16-bit ALU, indexes across page boundaries would still require the extra cycle; the only thing a 16-bit ALU would do is reduce the cost of a branch across page boundaries from two extra cycles to one.