6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 10, 2024 7:42 pm

All times are UTC




Post new topic Reply to topic  [ 9 posts ] 
Author Message
PostPosted: Sun Aug 28, 2022 10:41 pm 
Offline

Joined: Sun Oct 03, 2021 2:17 am
Posts: 114
The INX, DEX, INY, and DEY instructions not affecting the overflow flag makes sense to me - the index registers are not designed for doing arithmetic.

But what about INC and DEC? Why don't they affect the overflow flag? Is this an oversight? These are what I refer to as strict New Zealand instructions - they only clobber the n and z flags. Is the overflow flag in a place conveniently accessible by the ALU, but not the accumulator incrementing circuit?

Taking a look at viewtopic.php?p=15729, it does appear that the ALU is adjacent to the accumulator, but the the incrementing circuit is not.


Top
 Profile  
Reply with quote  
PostPosted: Mon Aug 29, 2022 3:24 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8539
Location: Southern California
I don't know the answer, but I've never found it to be a problem. A related question is why didn't they make INC and DEC work in BCD when the d flag is set. I had to find that out by experience, 35 years ago.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
PostPosted: Mon Aug 29, 2022 5:23 am 
Offline

Joined: Sat Feb 19, 2022 10:14 pm
Posts: 147
Seems like a design choice. The E&L manual provides some interesting clues: INX and INY are
Quote:
a special purpose, implied addressing form of the INC instruction.
and
Quote:
Unlike adding a one with the ADC instruction, however, the increment instruction is neither affected by nor affects the carry flag. You can test for wraparound only by testing after every increment to see if the result is zero or positive. On the other hand, you don’t have to clear the carry before incrementing.
This seems to imply that using the ALU circuitry would require doing something with the carry flag, either internally or by the user.

GARTHWILSON wrote:
A related question is why didn't they make INC and DEC work in BCD when the d flag is set. I had to find that out by experience, 35 years ago.
Is that the meaning of this cryptic quote from E&L?
Quote:
The INC instruction is unaffected by the d (decimal) flag.
I'll have to test this out. My emulator doesn't handle that.


Top
 Profile  
Reply with quote  
PostPosted: Mon Aug 29, 2022 6:28 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8539
Location: Southern California
tmr4 wrote:
GARTHWILSON wrote:
A related question is why didn't they make INC and DEC work in BCD when the d flag is set. I had to find that out by experience, 35 years ago.
Is that the meaning of this cryptic quote from E&L?
Quote:
The INC instruction is unaffected by the d (decimal) flag.
I'll have to test this out. My emulator doesn't handle that.

Yes; even with d set, INC & DEC still do their thing in binary. The d flag is ignored.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
PostPosted: Mon Aug 29, 2022 8:06 am 
Offline

Joined: Sat Feb 19, 2022 10:14 pm
Posts: 147
GARTHWILSON wrote:
Yes; even with d set, INC & DEC still do their thing in binary. The d flag is ignored.

Ah. That's clearer.


Top
 Profile  
Reply with quote  
PostPosted: Mon Aug 29, 2022 8:06 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10976
Location: England
For me it does seem like a design choice. In a sense, incrementing is doing something other than arithmetic - if you needed to increment a counter or index during a multibyte sequence, then it's handy to leave the carry bit out of it. Similarly overflow - one might plausibly need to increment and test a counter after a final arithmetic operation and still want to be able to see whether the overall calculation overflowed.

But note that increment does use the ALU: the carry machinery and the BCD machinery is already close by. The only incrementer on the 6502 is for the program counter, and only for that.

I can't see that it would be good to have BCD in use for increment and decrement: it would make counters and address offsets be treated as decimal. Very often this would be confusing or a source of bugs


Top
 Profile  
Reply with quote  
PostPosted: Mon Aug 29, 2022 9:07 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8539
Location: Southern California
BigEd wrote:
I can't see that it would be good to have BCD in use for increment and decrement: it would make counters and address offsets be treated as decimal. Very often this would be confusing or a source of bugs

That totally makes sense for X & Y; but my early (1988?) effort to increment the accumulator in decimal was to shorten the CLC, ADC #1 sequence for an arithmetic operation unrelated to indexing or addresses. It was just a minor inconvenience to find out INA didn't do decimal. The performance hit was negligible. This was in that computer that spent most of its time at 170kHz to save battery power, and bumped it up to 1MHz when it had a set of floating-point decimal calculations to get through. If I had to do it over with knowledge I've gained since then, I would have done a lot of things radically differently. I was totally green to such a project, and so was the boss.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
PostPosted: Mon Nov 21, 2022 11:49 am 
Offline
User avatar

Joined: Tue Aug 11, 2020 3:45 am
Posts: 311
Location: A magnetic field
I would have guessed that INC and DEC were sensitive to decimal mode and that even INX, DEX, INY and DEY might be affected. My reasoning is quite simple. 6502 was covered by an elegant decimal mode patent, all computation goes via ALU and 6502 was conceived as a minimal microcontroller where decimal output is important. Decimal inhibit requires additional transistors which is contrary to other goals while precluding useful functionality.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!


Top
 Profile  
Reply with quote  
PostPosted: Fri Dec 16, 2022 4:06 pm 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1949
Location: Sacramento, CA, USA
Unlike all of the other 8-bitters I've encountered over the last 40 years, the 65c02's flag behavior has always coincided 100% with my personal programmer's intuition. 65c816 addressing mode behavior ... not nearly as much.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 10 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: