It is currently Sat Nov 25, 2017 2:45 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 34 posts ]  Go to page 1, 2, 3  Next
Author Message
PostPosted: Thu Aug 24, 2017 9:50 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 987
Location: Pennsylvania, USA
Not too long ago I created a minimal NES emulator targeted at homebrew games.

After supporting 10+ games, I never implemented calculating the V flag after any add or subtract operation, only setting it after "bit," commonly used for vblank waits.

I've never used it, myself, after any add or subtract operation. Is it ever useful?


Top
 Profile  
 
PostPosted: Thu Aug 24, 2017 10:03 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 585
Grepping the cc65 source, it's used for 32-bit int handling, and some non-nes platform-specific things.


Top
 Profile  
 
PostPosted: Thu Aug 24, 2017 10:04 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 987
Location: Pennsylvania, USA
calima wrote:
Grepping the cc65 source, it's used for 32-bit int handling, and some non-nes platform-specific things.


I guess I'm mostly curious about whether it's ever useful for game development purposes. I've never used anything bigger than 24 bits when coding NES games, myself...


Top
 Profile  
 
PostPosted: Thu Aug 24, 2017 10:48 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10120
Location: Rio de Janeiro - Brazil
It's useful to detect signed overflows/underflows (while the carry is used for unsigned overflows/underflows). If you take 120 and add 10, you get 130, a perfectly valid unsigned result, but it's larger than 127, the largest signed value a byte can hold. So yeah, even with smaller 8-bit numbers the V flag might still be useful. I hardly use it though, but that's because I hardly ever have to bother about signed overflows.


Top
 Profile  
 
PostPosted: Thu Aug 24, 2017 11:01 am 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1925
Location: WhereverIparkIt, USA
I can't think of a very practical example, but the Vflag could be used to store one bit of branch info you'd like to hang onto through a chunk of code that doesn't contain ADC/SBC/BIT instructions.

EDIT: also to correct the topic, CMP doesn't affect V flag.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Last edited by infiniteneslives on Thu Aug 24, 2017 11:11 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Thu Aug 24, 2017 11:08 am 
Offline
User avatar

Joined: Sat Jan 09, 2016 9:21 pm
Posts: 247
Location: Central Illinois, USA
tokumaru wrote:
It's useful to detect signed overflows/underflows (while the carry is used for unsigned overflows/underflows). If you take 120 and add 10, you get 130, a perfectly valid unsigned result, but it's larger than 127, the largest signed value a byte can hold. So yeah, even with smaller 8-bit numbers the V flag might still be useful. I hardly use it though, but that's because I hardly ever have to bother about signed overflows.


I've used it for this reason before. Not often though.

_________________
My games: http://www.bitethechili.com


Top
 Profile  
 
PostPosted: Thu Aug 24, 2017 11:31 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19259
Location: NE Indiana, USA (NTSC)
GradualGames wrote:
After supporting 10+ games, I never implemented calculating the V flag after any add or subtract operation, only setting it after "bit," commonly used for vblank waits.

I've never used it, myself, after any add or subtract operation. Is it ever useful?

Yes. I use it to determine whether an addition or subtraction involving a signed number overflowed. This is useful for ensuring an entity's position doesn't leave the bounds of the screen or map and wrap to the other side, or that acceleration doesn't cause velocity to wrap past (say) +127 to -128.

Code:
clc
lda signed_velocity
adc signed_acceleration
bvc no_clamping_needed
  ; OMITTED: clamping code
no_clamping_needed:
sta signed_velocity

clc
lda unsigned_displacement
eor #$80
adc signed_velocity
eor #$80
bvc no_clamping_needed
  ; OMITTED: clamping code
no_clamping_needed:
sta unsigned_displacement


Top
 Profile  
 
PostPosted: Thu Aug 24, 2017 12:09 pm 
Offline
User avatar

Joined: Fri Jan 24, 2014 9:05 am
Posts: 138
Location: Hungary
The effect of BIT is probably why I use it the most. The way I handle the math doesn't really need the V flag because most of the time I add signed 16-bit values to unsigned 16-bit values... so I still only ever need the carry for that (though I have to interpret the carry differently based on the sign of what I was adding to the unsigned value).


Top
 Profile  
 
PostPosted: Thu Aug 24, 2017 12:42 pm 
Offline
User avatar

Joined: Sat Jan 09, 2016 9:21 pm
Posts: 247
Location: Central Illinois, USA
tepples wrote:
This is useful for ensuring an entity's position doesn't leave the bounds of the screen or map and wrap to the other side, or that acceleration doesn't cause velocity to wrap past (say) +127 to -128.

Yup, that's exactly where I've used it as well.

_________________
My games: http://www.bitethechili.com


Top
 Profile  
 
PostPosted: Thu Aug 24, 2017 1:38 pm 
Offline

Joined: Tue May 28, 2013 5:49 am
Posts: 885
Location: Sweden
The V flag isn't affected by CMP (or CPX/CPY), but it's affected by ADC, SBC, BIT and of course CLV.

I just asked about it myself and from what I understand it's used mostly for the following things:

    * Signed comparisons
    * Manual fixing in signed math (normally not needed)
    * Simulation of a branch always instruction (for relocatable code and such)
    * Used in a special feature of the BIT instruction

There's also a SET V pin on stock 6502 chips (though not on 65816) but I don't think the pin is available in the NES.

Also while it indicates a signed overflow, you don't use it in signed math like you use Carry in unsigned math as one might think, signed math is done the same way as unsigned math on the 6502. However signed comparisons won't work correctly just using CMP like with unsigned comparison. I learned how to do signed comparisons in this article using SBC and the V flag, and I'm using it in my game to compare signed 16-bit numbers (for things like preventing the player from running faster than the allowed max speed).

So I guess my game (can be found somewhere in the above linked thread if you want to test it in your emulator) won't work in your emulator if it doesn't support the V flag after an SBC. I don't know how common it is to do things like I did it, but I imagine that using signed numbers is very common in action games, so signed comparisons can't be THAT uncommon.


Top
 Profile  
 
PostPosted: Thu Aug 24, 2017 3:54 pm 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 987
Location: Pennsylvania, USA
Pokun wrote:
So I guess my game (can be found somewhere in the above linked thread if you want to test it in your emulator) won't work in your emulator if it doesn't support the V flag after an SBC. I don't know how common it is to do things like I did it, but I imagine that using signed numbers is very common in action games, so signed comparisons can't be THAT uncommon.

The scope of ggvm was intended to be insanely narrow and only support "one game at a time," so I just added features as I went. Adding support for the V flag would be pretty easy if someone needed it. That said though the scope of ggvm is so constrained the ppu doesn't even emulate scanline per scanline, which means things like status bars and the like have to be accomplished via special fake hardware registers that enable/disable features. Also there's no apu emulation either. (plays back mp3s instead) So as long as a game uses "mainly the basics" you can get it to where it's indistinguishable from a full emulator, for that specific game. But it'll never be a full emulator. I did it to get my games on something other than NES and it wound up helping out a few other people, which is cool. Didn't expect that to happen.


Top
 Profile  
 
PostPosted: Thu Aug 24, 2017 4:41 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5843
Location: Canada
In my opinion this is an essential component of the CPU. I don't really understand any desire to leave out the V flag from instructions that are supposed to affect it. There is nothing to gain from that, and a lot of stuff will be broken without it. Why wouldn't you put it in???

This isn't like the illegal opcodes, every 6502 has this function and it's a standard part of signed computations! If you think it doesn't seem to be needed, the only thing I could say is you haven't used it very thoroughly. The stuff that breaks could be subtle, like in my game it would probably cause a lot of the enemy AI to make incorrect decisions about which way to move, but unless you know how they're supposed to move this would be a hard error to spot casually. Like, you've made a silent error condition here; if you really want to see for sure what it's breaking maybe put in a test condition on BVC to fire if the last V instruction was SBC, I'm sure you'd start to accumulate examples fairly quickly if you did that on a variety of games.


Top
 Profile  
 
PostPosted: Thu Aug 24, 2017 4:49 pm 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 987
Location: Pennsylvania, USA
rainwarrior wrote:
In my opinion this is an essential component of the CPU. I don't really understand any desire to leave out the V flag from instructions that are supposed to affect it. There is nothing to gain from that, and a lot of stuff will be broken without it. Why wouldn't you put it in???

This isn't like the illegal opcodes, every 6502 has this function and it's a standard part of signed computations! If you think it doesn't seem to be needed, the only thing I could say is you haven't used it very thoroughly. The stuff that breaks could be subtle, like in my game it would probably cause a lot of the enemy AI to make incorrect decisions about which way to move, but unless you know how they're supposed to move this would be a hard error to spot casually. Like, you've made a silent error condition here; if you really want to see for sure what it's breaking maybe put in a test condition on BVC to fire if the last V instruction was SBC, I'm sure you'd start to accumulate examples fairly quickly if you did that on a variety of games.

I had no desire to leave it out, I just had no reason to implement it yet. My approach to developing ggvm is insanely amateurish if you haven't figured that out yet. To debug it, I typically need the full source code of a game, so that I can set breakpoints while ggvm runs and get an idea where I am in the running game's code. If I made it my 100% focus maybe I could write a series of tests or get some non homebrews working, but as it is I could not devote very much time to it. Just enough to get my games and a few homebrews working perfectly. *edit* I've actually grepped every single game's code that I've adapted to make sure it's not using bvs bvc except after bit.


Last edited by GradualGames on Thu Aug 24, 2017 4:55 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Thu Aug 24, 2017 4:54 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19259
Location: NE Indiana, USA (NTSC)
I apologize for not being able to provide test cases at the moment. I made Thwaite in 2011 before I learned EOR-ADC-EOR-BVC, though there were several places that could have used it. By the time I programmed Haunted: Halloween '85, I knew the trick, but its source code is a trade secret. I forget whether I used it in Zap Ruder or RHDE; I haven't cloned them since my other laptop's battery died a couple weeks ago.


Top
 Profile  
 
PostPosted: Thu Aug 24, 2017 5:16 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5843
Location: Canada
GradualGames wrote:
I've actually grepped every single game's code that I've adapted to make sure it's not using bvs bvc except after bit.

That... sounds like a lot more effort than it would take to just implement V. O_o


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google [Bot] and 11 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:  
cron
Powered by phpBB® Forum Software © phpBB Group