Hello World

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

User avatar
tokumaru
Posts: 11519
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru » Mon Nov 28, 2011 8:42 am

FinalZero wrote:What if overflow does *not* occur, is the carry bit cleared then? or simply left untouched?
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.

tepples
Posts: 21839
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Mon Nov 28, 2011 9:37 am

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?

Wave
Posts: 110
Joined: Mon Nov 16, 2009 5:59 am

Post by Wave » Mon Nov 28, 2011 9:49 am

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 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.

User avatar
FinalZero
Posts: 152
Joined: Thu Dec 03, 2009 7:27 am
Contact:

Post by FinalZero » Mon Nov 28, 2011 12:22 pm

ADC and SBC touch all flags NVZC.
I mean, what is the condition that causes the overflow to be set for those instructions?
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.
Okay.
What would SEV be needed for?
That is a good question.
BIT immediate does not exist on the original 6502.
How about some place in memory then?

tepples
Posts: 21839
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Mon Nov 28, 2011 2:52 pm

FinalZero wrote:
ADC and SBC touch all flags NVZC.
I mean, what is the condition that causes the overflow to be set for those instructions?
C: Bit 8 of the sum, that is, (sum >> 8) & 1.
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.
BIT immediate does not exist on the original 6502.
How about some place in memory then?
You can BIT any RTS to set N to 0 and V to 1.
Last edited by tepples on Mon Nov 28, 2011 7:41 pm, edited 1 time in total.

User avatar
FinalZero
Posts: 152
Joined: Thu Dec 03, 2009 7:27 am
Contact:

Post by FinalZero » Mon Nov 28, 2011 6:32 pm

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.
Yes, I know that already. By "overflow", I meant unsigned overflow. Is there a term like "carryage" or something to use instead?

So, again: If there is no *unsigned* overflow, is the carry bit cleared then? or simply left untouched?
V: I'll let someone else explain, if you don't mind.
Thank you, though I'm still not sure how to add two signed 16-bit integers.
You can BIT any RTS to set N to 0 and V to 1.
You mean BIT an RTS ($60) instruction? That's sort of breaking the distinction between code and data...

What does "page" mean in documentation like:
http://6502.org/tutorials/6502opcodes.html wrote:+ add 1 cycle if page boundary crossed
Does it mean bank?

User avatar
tokumaru
Posts: 11519
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru » Mon Nov 28, 2011 6:49 pm

FinalZero wrote:By "overflow", I meant unsigned overflow. Is there a term like "carryage" or something to use instead?
I don't think the name maters much as long as you understand what's going on underneath.
So, again: If there is no *unsigned* overflow, is the carry bit cleared then? or simply left untouched?
It's cleared.
Thank you, though I'm still not sure how to add two signed 16-bit integers.
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).
You can BIT any RTS to set N to 0 and V to 1.
You mean BIT an RTS ($60) instruction? That's sort of breaking the distinction between code and data...
I also have no idea what tepples meant with this comment...
What does "page" mean in documentation like:
http://6502.org/tutorials/6502opcodes.html wrote:+ add 1 cycle if page boundary crossed
Does it mean bank?
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.

User avatar
Dwedit
Posts: 4251
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Post by Dwedit » Mon Nov 28, 2011 7:09 pm

tokumaru wrote:
You can BIT any RTS to set N to 0 and V to 1.
You mean BIT an RTS ($60) instruction? That's sort of breaking the distinction between code and data...
I also have no idea what tepples meant with this comment...
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.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

User avatar
tokumaru
Posts: 11519
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru » Mon Nov 28, 2011 7:21 pm

Ah, I see... The way it was worded really threw me off! And I just noticed FinalZero did understand what he meant, I was the only one that was confused! :oops:

User avatar
FinalZero
Posts: 152
Joined: Thu Dec 03, 2009 7:27 am
Contact:

Post by FinalZero » Mon Nov 28, 2011 7:54 pm

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.
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?

User avatar
Dwedit
Posts: 4251
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Post by Dwedit » Mon Nov 28, 2011 8:00 pm

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!

User avatar
FinalZero
Posts: 152
Joined: Thu Dec 03, 2009 7:27 am
Contact:

Post by FinalZero » Mon Nov 28, 2011 8:08 pm

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.
Okay. I see.

User avatar
FinalZero
Posts: 152
Joined: Thu Dec 03, 2009 7:27 am
Contact:

Post by FinalZero » Wed Nov 30, 2011 12:53 am

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?

tepples
Posts: 21839
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Wed Nov 30, 2011 6:34 am

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.

Code: Select all

reset:
  sei
  ldx #$FF
  txs
  inx
  stx $2000
  stx $2001
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.

User avatar
FinalZero
Posts: 152
Joined: Thu Dec 03, 2009 7:27 am
Contact:

Post by FinalZero » Wed Nov 30, 2011 3:23 pm

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.
What do you mean "where $FFFC-$FFFD says."? How do I set where? Why are you setting the interrupt flag in your code?
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.
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.

Post Reply