insane.. i mean inside cycle emu estructure?

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
insane.. i mean inside cycle emu estructure?
by on (#11340)
As i said before im writing a 6502 emulator based on the microarchitecture using pure c++. I have classes ALU,DU,ADDRBUS, EU, DATABUS /etc. What is good of this: breakpoints (and other things). The user can put a breakpoint even when one value of the ALU is about to/after be writed.
But still not sure what machine it will nee..
... sorry im a little enthusiast cos im learining a lot :D .

Well right to the point now:

I wanted to know if this heappen in this way:

i will use vars AddrBUS/DataBUS/PC.
this fragment is taken from 6502_cpu.txt
Code:
     
       #   address R/W description
       ---  -------    ---   ------------------------------------------
        1    PC         R  fetch opcode, increment PC
            - AddrBUS = PC
            - DataBUS = Read from AddrBUS
            - Opcode = DataBUS
            - Increment PC ***
        2   .... (other cycles come here)



*** How does Increment PC? is it passed to the ALU? if it is a 16 bit value is there wrap around on pages.. i think not, its contigous.. but how does the cpu treat a case like "incrementing a 16 BIT register".

Thanks in advance.

by on (#11343)
Yes, the "Increment PC" increments the program counter as a single 16-bit register, since it's doing nothing more than incrementing it.

The reason indexed addressing incurs extra penalties when crossing page boundaries is because the ALU is only 8 bits wide, and the ALU is required in order to add 2 arbitrary numbers - adding 1 to a number is extremely simple to do in hardware, so it was implemented for both halves of the program counter simultaneously.

by on (#11345)
Right. I'm not sure whether its the ALU adder or a different adder which is used, but either way its an 8-bit adder being used. Consider this: if you add an 8-bit index register to the bottom half of a 16-bit register and it doesn't generate a carry, then you already know the top half of the result too (it is the original 8 bits from the top half of your 16-bit register).

However, if you add an 8-bit index register to the bottom half of a 16-bit register and it DOES generate a carry... then you have to add that carry to the top half of the result before you can use it (pushing the effective address into the next page).

I'm not 100% sure about what is occurring in each cycle, but it makes sense to me that the extra cycle is necessary for the carry propagation to be performed.