emulation - 6502 cycle timing per instruction -

i writing first nes emulator in c. goal make understandable , cycle accurate (does not have code-efficient though), in order play games @ normal 'hardware' speed. when digging technical references of 6502, seems instructions consume more 1 cpu cycle - , has different cycles depending on given conditions (such branching). plan create read , write functions, , group opcodes addressing modes using switch.

the question is: when have multiple-cycle instruction, such brk, need emulate happening in each cycle:

#method 1  cycle - action  1 - read brk opcode 2 - read padding byte (ignored) 3 - store high byte of pc 4 - store low byte of pc 5 - store status flags b flag set 6 - low byte of target address 7 - high byte of target address 

...or can execute required operations in 1 'cycle' (one switch case) , nothing in remaining cycles?

#method 2  1 - read brk opcode, read padding byte (ignored), store high byte of pc, store low byte of pc, store status flags b flag set, low byte of target address, high byte of target address 2 - nothing 3 - nothing 4 - nothing 5 - nothing 6 - nothing 7 - nothing 

since both methods consume desired 7 cycles, there no difference between two? (accuracy-wise)

personally think method 1 way-to-go solution, cannot think of proper, easy way implement it... (please help!)

do 'need' to? depends on software. imagine simplest example:

sta ($56), y 

... happens hit hardware register. if don't @ least write on correct cycle you've introduced timing deficiency. register you're writing written @ wrong time. if it's palette register, , programmer running raster effect? you've moved colour changes. you've changed graphical output.

in practice, clever programmers smarter things — e.g. 1 might use read-modify-write operation read hardware value @ exact cycle, modify it, write @ other exact cycle.

so answer is:

1. most software isn't written difference between (1) , (2) have effect; but
2. some is, because author clever; and
3. some is, because author experimented until found cool effect, regardless of whether cognisant of cause; and
4. in case, when find doesn't work on emulator, how time want spend considering permutations , combinations of potential causes? every 1 can factor out 1 less consider.

most emulators used use method (2). happens work 90% of software. there's few cases don't work, emulator author puts in special case here, special case there. ended interacting poorly , emulator spent rest of life oscillating between supporting different 95% combinations of available software until wrote better one.

so go method (1). cause software otherwise broken not so. it'll teach more, , it'll eliminate potential motivation special cases it'll keep code cleaner. it'll marginally slower think computer can handle it.

other tips: 6502 has few addressing modes, , addressing mode entirely dictates timing. this document need know perfect timing. if want perfect cleanliness, switch table can pick addressing mode , central operation, exit , can branch on addressing mode main action.

if you're going use vanilla read , write methods, smart on 6502 every single cycle either read or write it's need say, careful of method signatures. example, 6502 has sync pin allows observer discriminate ordinary read opcode read. check whether nes exposes cartridges, it's used on systems expose implicit paging , main identifying characteristic of nes there hundreds of paging schemes.

edit: minor updates:

• it's not true 6502 reads or writes; has rdy input. if rdy input asserted , 6502 intends read, instead halt while maintaining intended read address. used in practice because it's insufficient common tasks allowing else take possession of memory — 6502 write regardless of rdy input, it's meant single-stepping — , seemingly not included on nes cartridge pinout, needn't implement machine.
• per same pinout, sync signal doesn't seem exposed cartridges on system.