The carry flag and the overflow flag are entirely different things. In a way, the C flag can be used to detect unsigned overflow, while the V flag is used to detect signed overflows. If an addition causes a number to go past 255 and wrap back to 0 and up, that‘s an unsigned overflow, and the C flag will indicate whether this happened or not. But when a number goes past 127 and wraps back to -128 (or vice versa), that‘s a signed overflow, indicated by the V flag.FinalZero wrote:What if overflow does *not* occur, is the carry bit cleared then? or simply left untouched?
Hello World
Moderator: Moderators
I take the the unsigned number and adc the positive value of the signed number if it's positive or sbc the positive value of the signed number if it's negative. At least that's what I'm planning to do on my objects core. I think this way you can use the normal flags.tepples wrote:Is there an idiom to detect overflow when adding a signed number to an unsigned number, such as when adding an instantaneous velocity to a critter's position?
I mean, what is the condition that causes the overflow to be set for those instructions?ADC and SBC touch all flags NVZC.
Okay.Pretty much all NES games (except for a few obscure ones that almost nobody in my country probably has) use the NMI to detect the start of vertical blanking.
That is a good question.What would SEV be needed for?
How about some place in memory then?BIT immediate does not exist on the original 6502.
C: Bit 8 of the sum, that is, (sum >> 8) & 1.FinalZero wrote:I mean, what is the condition that causes the overflow to be set for those instructions?ADC and SBC touch all flags NVZC.
N: Bit 7 of the sum, that is, (sum >> 7) & 1.
Z: Bits 7-0 of the sum NOR'd together, that is, !(sum & 0xFF).
V: I'll let someone else explain, if you don't mind.
You can BIT any RTS to set N to 0 and V to 1.How about some place in memory then?BIT immediate does not exist on the original 6502.
Last edited by tepples on Mon Nov 28, 2011 7:41 pm, edited 1 time in total.
Yes, I know that already. By "overflow", I meant unsigned overflow. Is there a term like "carryage" or something to use instead?The carry flag and the overflow flag are entirely different things. In a way, the C flag can be used to detect unsigned overflow, while the V flag is used to detect signed overflows. If an addition causes a number to go past 255 and wrap back to 0 and up, that‘s an unsigned overflow, and the C flag will indicate whether this happened or not. But when a number goes past 127 and wraps back to -128 (or vice versa), that‘s a signed overflow, indicated by the V flag.
So, again: If there is no *unsigned* overflow, is the carry bit cleared then? or simply left untouched?
Thank you, though I'm still not sure how to add two signed 16-bit integers.V: I'll let someone else explain, if you don't mind.
You mean BIT an RTS ($60) instruction? That's sort of breaking the distinction between code and data...You can BIT any RTS to set N to 0 and V to 1.
What does "page" mean in documentation like:
Does it mean bank?http://6502.org/tutorials/6502opcodes.html wrote:+ add 1 cycle if page boundary crossed
I don't think the name maters much as long as you understand what's going on underneath.FinalZero wrote:By "overflow", I meant unsigned overflow. Is there a term like "carryage" or something to use instead?
It's cleared.So, again: If there is no *unsigned* overflow, is the carry bit cleared then? or simply left untouched?
It's exactly the same as if they were unsigned. In some cases, like when comparing multi-byte signed integers, you must treat the lower bytes as unsigned, and only the most significant byte as signed (i.e., the carry flag is used to propagate overflows up until the highest byte, and only when the last byte has been calculated you can expect something meaningful in the V flag).Thank you, though I'm still not sure how to add two signed 16-bit integers.
I also have no idea what tepples meant with this comment...You mean BIT an RTS ($60) instruction? That's sort of breaking the distinction between code and data...You can BIT any RTS to set N to 0 and V to 1.
The CPU doesn't know anything about "banks", so no. Pages are sections of 256 bytes. $8000 is the start of one page, $8100 is the start of the following page, for example. Some instructions take longer to execute when pages are crossed because the CPU needs more time in order to update the high byte of the address as well as the low byte.What does "page" mean in documentation like:Does it mean bank?http://6502.org/tutorials/6502opcodes.html wrote:+ add 1 cycle if page boundary crossed
I'm sure he meant exactly what it looks like, making up for the lack of a SEV instruction by using BIT against some value of $60 sitting somewhere in the code. RTS is $60.tokumaru wrote:I also have no idea what tepples meant with this comment...You mean BIT an RTS ($60) instruction? That's sort of breaking the distinction between code and data...You can BIT any RTS to set N to 0 and V to 1.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
Ah, okay. So then, if it crosses 2 pages, does that mean it takes 2 more cycles? Are there any time-critical procedures that are must be explicitly designed not to cross page boundaries?The CPU doesn't know anything about "banks", so no. Pages are sections of 256 bytes. $8000 is the start of one page, $8100 is the start of the following page, for example. Some instructions take longer to execute when pages are crossed because the CPU needs more time in order to update the high byte of the address as well as the low byte.
It can't cross more than 1 page. "Crossing a page" means when you add an 8-bit value to a 16-bit value, it needs to change the high byte of the 16-bit value. The only time you see crossing a page penalties is in the instructions that add X or Y to an address, or the branch instructions.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
Okay. I see.Dwedit wrote:It can't cross more than 1 page. "Crossing a page" means when you add an 8-bit value to a 16-bit value, it needs to change the high byte of the 16-bit value. The only time you see crossing a page penalties is in the instructions that add X or Y to an address, or the branch instructions.
Questions:
1) When linking, the ines header goes at $0000. To play the game on an emulator, does that mean that all the other segments must be offset by $10? That is, the zero page starts at $10 and ends at $110 instead of it's normal range?
2) On starting up, what's the status of all the flags? Is it common practice to simply clear them? What about the PC/SP/AC/X/Y ?
3) Somewhat unrelated, but I'll ask anyways. I have the opportunity to get my hands on a real NES, but it doesn't work. Iirc, the power cable is broken/touchy (It needed to be bent in just the right position for it to work.), and the screen will just blink/oscillate when I did manage to get the power to work. What kind of thing would cause the second problem, and how much would replacing the first cost?
1) When linking, the ines header goes at $0000. To play the game on an emulator, does that mean that all the other segments must be offset by $10? That is, the zero page starts at $10 and ends at $110 instead of it's normal range?
2) On starting up, what's the status of all the flags? Is it common practice to simply clear them? What about the PC/SP/AC/X/Y ?
3) Somewhat unrelated, but I'll ask anyways. I have the opportunity to get my hands on a real NES, but it doesn't work. Iirc, the power cable is broken/touchy (It needed to be bent in just the right position for it to work.), and the screen will just blink/oscillate when I did manage to get the power to work. What kind of thing would cause the second problem, and how much would replacing the first cost?
1) Only ROM ends up offset after the header, PRG, and CHR are concatenated. For example, $C000-$FFFF of an NROM-128 becomes $0010-$400F in the iNES file, or $8000-$FFFF of an NROM-256 or CNROM becomes $0010-$800F in the iNES file. BSS-type segments such as zero page do not move because they're not stored in the ROM at all.
2) Do not depend on the flags at the time of reset. You'll usually end up clearing X, S, and half of P in the first six instructions anyway. All you can be sure of is that PC points where $FFFC-$FFFD says.
3) The official NES adapter outputs 9 V AC, but it can run just as easily on the -9 V DC that a power supply for the original model Sega Genesis makes. Or you could buy a universal adapter and configure it for -9 V DC.
2) Do not depend on the flags at the time of reset. You'll usually end up clearing X, S, and half of P in the first six instructions anyway. All you can be sure of is that PC points where $FFFC-$FFFD says.
Code: Select all
reset:
sei
ldx #$FF
txs
inx
stx $2000
stx $2001
What do you mean "where $FFFC-$FFFD says."? How do I set where? Why are you setting the interrupt flag in your code?2) Do not depend on the flags at the time of reset. You'll usually end up clearing X, S, and half of P in the first six instructions anyway. All you can be sure of is that PC points where $FFFC-$FFFD says.
Okay, so that's the overlay thing again. I don't understand which segments overlay what. Is it by bank/memory-area? Basically, I still don't understand how my linker file is supposed to be set up.1) Only ROM ends up offset after the header, PRG, and CHR are concatenated. For example, $C000-$FFFF of an NROM-128 becomes $0010-$400F in the iNES file, or $8000-$FFFF of an NROM-256 or CNROM becomes $0010-$800F in the iNES file. BSS-type segments such as zero page do not move because they're not stored in the ROM at all.