It is currently Tue Oct 17, 2017 10:05 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 21 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Fri Jan 29, 2016 12:19 am 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3941
Sogona wrote:
What's the deal with color $0D of the PPU's palette?

Color 0D is the low part of the square waves it uses to draw any of the dark colors. The waves are between 00 (gray) and 0D (blacker than black). Regular dark colors which happen to use 0D as the low part of the wave don't cause problems.
The other colors are waves between 10 and 1D, 20 and 2D, or 30 and 3D. Column D of the palette isn't supposed to be used though.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
PostPosted: Fri Jan 29, 2016 7:20 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10046
Location: Rio de Janeiro - Brazil
Here's a quick breakdown of the meaning of the CPU flags in a math context:

Carry (C): Indicates overflows and underflows of unsigned numbers. For example, add 1 to 255 and it wraps back to 0, because 256 doesn't fit in a byte. The carry is set to indicate this. Similarly, when you subtract 1 from 0, it wraps back to 255, and the carry is cleared to indicate this underflow.

Negative (N): Indicates the sign of signed numbers. It's merely a copy of bit 7, which is clear for values 0 to 127 ($00 to $7f) and set for values -128 to -1 ($80 to $ff).

Overflow (V): Indicates overflows and underflows of signed numbers. For example, add 1 to 127 and you get 128 ($80), which actually corresponds to -128 if you're working with signed numbers, so the overflow flag Indicates this. The same happens when subtractions give results smaller than -128.


Top
 Profile  
 
PostPosted: Thu Feb 04, 2016 10:10 pm 
Offline

Joined: Thu Jul 23, 2015 7:54 pm
Posts: 145
Location: USA
tokumaru wrote:
Negative (N): Indicates the sign of signed numbers. It's merely a copy of bit 7, which is clear for values 0 to 127 ($00 to $7f) and set for values -128 to -1 ($80 to $ff).

Overflow (V): Indicates overflows and underflows of signed numbers. For example, add 1 to 127 and you get 128 ($80), which actually corresponds to -128 if you're working with signed numbers, so the overflow flag Indicates this. The same happens when subtractions give results smaller than -128.

So you can't just do:
Code:
lda myvariable
clc     ;(is this necessary for signed math?)
adc #$02
bpl +     ;skip if didnt roll over
  ;run code if did roll over
+:


instead of
Code:
lda myvariable
clc     ;(would it be clv here?)
adc #$02
bvc +
  ;run code if rolled over
+:


Top
 Profile  
 
PostPosted: Thu Feb 04, 2016 10:16 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19086
Location: NE Indiana, USA (NTSC)
Yes, you still need clc for signed math, and no, you don't need clv. Carry is both an input and an output to every adc instruction; overflow is only an output.


Top
 Profile  
 
PostPosted: Thu Feb 04, 2016 10:23 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10046
Location: Rio de Janeiro - Brazil
Sogona wrote:
Code:
lda myvariable
clc     ;(is this necessary for signed math?)
adc #$02
bpl +     ;skip if didnt roll over
  ;run code if did roll over
+:

This doesn't catch all the errors. For example, if you take -45 ($d3) and add -120 ($88), you get $5b, which is positive and is the wrong result. The correct result needs more bits to be represented ($ff5b = -165), and the V flag indicates this. And yes, the CLC is necessary.

Quote:
Code:
lda myvariable
clc     ;(would it be clv here?)
adc #$02
bvc +
  ;run code if rolled over
+:

This is the correct way to detect overflows and underflows of signed numbers.


Top
 Profile  
 
PostPosted: Sat Dec 17, 2016 9:36 pm 
Offline

Joined: Wed Nov 30, 2016 4:45 pm
Posts: 86
Location: Southern California
Sogona wrote:
4. Are there any situations when programming the NES where (indirect,x) addressing would come in handy?

(ZP,X) gets used a lot in virtual stacks, where the virtual stack (a data stack, separate from the return stack) is in ZP, and X is the index into it, and stack cells often have addresses. This is discussed a lot in my 6502 stacks treatise (notice, "stacks," plural, not just the page-1 hardware stack) starting in chapter 4, on virtual stacks and various ways to implement them, at http://wilsonminesco.com/stacks/virtualstacks.html . Here's a little bit quoted from near the top of the page there:


      So far, we've only been talking about the 6502's hardware stack which:

      • resides in page 1 of the memory map,
      • has a dedicated processor register (S) as its stack pointer, and
      • built-in microprocessor instructions automatically take care of the indexing into the stack area and the incrementing and decrementing of the stack pointer.

      You can implement virtual stacks too though. This just means you will synthesize the stack in software, typically using an index register as a pointer, and you'll have to use separate instructions to increment and decrement the index register and to store individual bytes of a multi-byte cell.


      Ok, so why would you want to, if the 6502's built-in hardware stack operations already do this for you automatically? Well, it turns out that using an additional stack to handle data separately from return addresses has major attractions:

      • It makes parameter-passing between routines implicit and more efficient since routines won't have to keep stepping over return addresses. This becomes especially important when parameters are passed to a subroutine which may in turn pass one or more parameters to another one which won't know how many return addresses are sprinkled in unless each routine does more stack juggling!

      • It makes stack handling much easier than trying to put the data on the return (hardware) stack, partly for the reason above.

      • There are more addressing modes in ZP (zero page), so more operations can be done in place rather than having to do an intermediate move to ZP. There are plenty of things you can't do directly with the hardware stack anyway, like pull a value off to add to the contents of the accumulator.

      • The resulting easier stack operations reduce the number of variables needed along with the risk of overwriting data that another pending routine expects to find still intact. (This is true of the hardware stack too, but having the separate data stack carries it further.)

      • It improves nestability and re-entrancy of routines. (This is true of the hardware stack too, but having the separate data stack carries it further.)

      • It reduces bugs and crashes, improving development time.


      The data stack becomes a workspace for arithmetic and logic operations.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 21 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group