nesdev.comhttp://forums.nesdev.com/ 8x16 and whatever else unreg wants to knowhttp://forums.nesdev.com/viewtopic.php?f=10&t=7451 Page 87 of 98

 Author: unregistered [ Thu Dec 18, 2014 6:25 pm ] Post subject: Re: 8x16 and whatever else unreg wants to know Ok... I want to make our sprite character disappear... my goal is also to have her stop being animated when she reaches the end of my sister's level. In the past I've been told to set her sprite y coord to "F0" and since she is the only sprite right now I have the codeCode:  lda #\$F0  sta sprite+0... ...it runs right after Code:  sta onscreenX+1 ;onscreenX+1 should always be 0.  If ever it is nonzero than it's also off the screen.  beq @continue. This code worked before... but I changed or fixed something else and it stopped working. It continues to not work... she continues to run across the screen after, being teleported to the other side of the screen and, memory location \$0200 holds a #\$F0. That's verified. Before, when it worked, her last frame would just remain on the screen but she would not be on the screen anymore! Well, I don't remember what I changed or fixed... please help me. Supper time!

 Author: unregistered [ Thu Jan 01, 2015 2:29 pm ] Post subject: Re: 8x16 and whatever else unreg wants to know Hello good people. How do I divide by 6 in assembly? My sister suggested I could divide by 2 three times... but that doesn't work in assembly... I think... because dividing by 2 three times is dividing by 8.

 Author: tepples [ Thu Jan 01, 2015 2:44 pm ] Post subject: Re: 8x16 and whatever else unreg wants to know The most efficient method depends on what you need to divide by 6 for. You could multiply by \$2A. Or use an actual divide loop. Or if you're doing random number generator, multiply by 6 instead of mod 6.

 Author: unregistered [ Thu Jan 01, 2015 4:28 pm ] Post subject: Re: 8x16 and whatever else unreg wants to know I found a nice divide by 6 routine in this thread by Omegamatrix. I will reply to his thread in a bit.

 Author: tokumaru [ Thu Jan 01, 2015 7:21 pm ] Post subject: Re: 8x16 and whatever else unreg wants to know More importantly, you should think hard and decide whether you really need a division by 6. So far it seems you're programming a platform engine, and I can't really think of any reason to divide by 6 in such an engine. Why exactly do you need that division? The best thing to do would be to avoid divisions altogether.

 Author: tomaitheous [ Thu Jan 01, 2015 10:23 pm ] Post subject: Re: 8x16 and whatever else unreg wants to know Tokumaru makes a great point. This is low level optimization vs higher level optimization. Maybe think of a way to use divide by 8; come at it with a different approach. But for low level, I would look at factors in the original expression. As in, what's the range for the value that's divided by 6? Is it something between 0 and 31, or such? Is speed a concern (this is done more than once per frame)? Then use a small look-up table.On a side note, there's: A/6 = A/2 - A/3. But it has a side effect of rounding up/down depending on if the results of the two operations before subtraction (if your division results in tourniqueting the decimal part). It's based on A/C - A/(C+1) = A/C*(C+1) = A/C^2+C.

 Author: unregistered [ Sat Jan 03, 2015 12:06 am ] Post subject: Re: 8x16 and whatever else unreg wants to know tomaitheous wrote:Tokumaru makes a great point. This is low level optimization vs higher level optimization. Maybe think of a way to use divide by 8; come at it with a different approach.tokumaru does make a great point. Maybe I could use a divide by 8... I thought of doing that... but then I asked my question.tomaitheous wrote:But for low level, I would look at factors in the original expression. As in, what's the range for the value that's divided by 6? Is it something between 0 and 31, or such?That's an interesting question... um the value divided by 6 ranges from 20 to 67.tomaitheous wrote:Is speed a concern (this is done more than once per frame)? Then use a small look-up table.Speed is always a concern. Thank you that's a great idea... a small lookup table... I have a good idea about how to make one. This page helped me to understand what a lookup table is. Thank you tepples, tokumaru, and tomaitheous for your responses and tokumaru you do make a great point... like tomaitheous said... but I can't tell you why I think I need my divide by 6. It makes sense to me to use it right now so yall will just have to trust me.

 Author: tokumaru [ Sat Jan 03, 2015 6:51 am ] Post subject: Re: 8x16 and whatever else unreg wants to know unregistered wrote:I can't tell you why I think I need my divide by 6. It makes sense to me to use it right now so yall will just have to trust me. Then definitely use a look-up table, since the range of numbers is so small. With the number to be divided loaded in the X register you can simply do LDA DivideBy6Table-20, x to get the result.

 Author: unregistered [ Sat Jan 03, 2015 8:40 pm ] Post subject: Re: 8x16 and whatever else unreg wants to know tokumaru wrote:unregistered wrote:I can't tell you why I think I need my divide by 6. It makes sense to me to use it right now so yall will just have to trust me. Then definitely use a look-up table, since the range of numbers is so small. With the number to be divided loaded in the X register you can simply do LDA DivideBy6Table-20, x to get the result. Thank you tokumaru and tomaitheous! How do I start my lookup table? Maybe I can figure this out... I'll play with it.

 Author: tokumaru [ Sat Jan 03, 2015 8:49 pm ] Post subject: Re: 8x16 and whatever else unreg wants to know unregistered wrote:How do I start my lookup table?You could write all the values by hand, but it's usually a better option to let the assembler do the hard work. If you're using ASM6, this should do it:Code:DivideBy6Table:   Value = 20   .rept 48 ;there are 48 values between 20 and 67   .db Value / 6   Value = Value + 1   .endrThere's nothing special about look-up tables, they simply contain pre-calculated values so that you don't have to calculate them during runtime, which saves you some CPU time. Whether you should use look-up tables for specific tasks depends on how much ROM you're willing to dedicate to such tables and how often said tasks are performed. Sometimes they can be prohibitively large, but for something as small as 48 bytes it just makes sense to have all the results pre-calculated.

 Author: unregistered [ Sat Jan 03, 2015 11:46 pm ] Post subject: Re: 8x16 and whatever else unreg wants to know tokumaru wrote:unregistered wrote:How do I start my lookup table?You could write all the values by hand, but it's usually a better option to let the assembler do the hard work. If you're using ASM6, this should do it:Code:DivideBy6Table:   Value = 20   .rept 48 ;there are 48 values between 20 and 67   .db Value / 6   Value = Value + 1   .endr !!!!!!!!!!!!!!!!!WOW!!!!!!!!!!!!!!!!!!!!!!!!!!tokumaru wrote:There's nothing special about look-up tables, they simply contain pre-calculated values so that you don't have to calculate them during runtime, which saves you some CPU time. Whether you should use look-up tables for specific tasks depends on how much ROM you're willing to dedicate to such tables and how often said tasks are performed. Sometimes they can be prohibitively large, but for something as small as 48 bytes it just makes sense to have all the results pre-calculated.Thank you incredibly much tokumaru! I feel everyone can benefit and learn everything there is to know about lookup tables! Those words are gold and a fitting close to this lookup table grandness... THANKS SO MUCH TOKUMARU!! ...AND THANK YOU TOMAITHEOUS FOR MENTIONINGRECOMMENDING LOOKUP TABLES! edit.edit2.

 Author: tomaitheous [ Mon Jan 05, 2015 3:26 pm ] Post subject: Re: 8x16 and whatever else unreg wants to know LUTs or look-up tables, are the magic elixir of the 65x processors. Free indexing is really nice They can really speed up the processor operations (albeit at the expense of memory). I tend to have LUTs just for shift+Add or shift+OR for quick address translation for larger tables (it gets the upper address bits for larger tables). Don't forget split tables too (lsb/msb), for faster access. But yeah, a table could have multiple operations/calculations in them.