It is currently Sat Sep 22, 2018 7:11 pm

 All times are UTC - 7 hours

 Page 89 of 97 [ 1451 posts ] Go to page Previous  1 ... 86, 87, 88, 89, 90, 91, 92 ... 97  Next
 Print view Previous topic | Next topic
Author Message
 Post subject: Re: 8x16 and whatever else unreg wants to knowPosted: Mon Mar 20, 2017 2:09 pm

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 927
Location: cypress, texas
lidnariq wrote:
Branches can go between 129 bytes forward and 126 bytes backwards, and 197 bytes forward is out of range.

Ah ok, thanks lidnariq!! Why is it limited to 129 bytes forward? It uses positive and negative numbers maybe... so oh ok, windows 10 calculator in programmer's mode is fantastic!! So if... how does that work? How does it differentiate between forwards and backwards? Well, it must use positive and negative numbers... I remember it using negative numbers when it went backwards. But 129 is 1000 0001 and 126 is 0111 1110... but it's confusing to me beyond the fact that those two numbers are inverses. Help? *NVM tepples answered!

tepples wrote:
That's 129 bytes forward or 126 bytes backward from the address of the branch instruction's opcode. The apparent imbalance is because the offset is actually measured from the address of the opcode that would be executed if the branch were not taken, and it has the typical range of an 8-bit signed integer: 127 bytes forward or 128 bytes backward.
Thank you so much tepples!! Makes sense!

---
found Loopy's new site (from Memblers) (through google): http://3dscapture.com/NES/

Top

 Post subject: Re: 8x16 and whatever else unreg wants to knowPosted: Sun May 28, 2017 4:33 pm

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 927
Location: cypress, texas
I'm trying to get a new screen to load when our lady reaches the top of the screen (oY == 00). Almost everything works; as soon as oY reaches 00, currFloor is decremented and stairs is jsred. Stairs tries to disable vblank by anding my copy of \$2000 with #01111111b. Then see is jsred correctly.

The only problem is that see never finishes because a vblank is activated and see is called again... the hex editor shows the stack is constantly decremented because see keeps being run because vblanks keep being called.

My function see sets up the screens before the game starts. It works wonderfully. Do you have any advice for me to turn off vblanks successfully? I have found where the wiki advises reading \$2002 before turning on bit 7 of \$2000, but I`m trying to turn bit 7 of \$2000 off.

Top

 Post subject: Re: 8x16 and whatever else unreg wants to knowPosted: Sun May 28, 2017 6:55 pm

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10814
Location: Rio de Janeiro - Brazil
I'm of the opinion that it's better to leave NMIs always on and control what happens each vblank entirely in software. You can even use the shadow \$2001 register to detect when rendering is off, in which case the vblank handler skips all code related to the PPU (after updating register \$2001 with the shadow value, that is), so it doesn't interfere with any PPU operations the main thread may be doing (e.g. large updates between levels), but still updates the APU so that music and sound effects aren't interrupted by screen transitions.

Top

 Post subject: Re: 8x16 and whatever else unreg wants to knowPosted: Sun May 28, 2017 10:09 pm

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 927
Location: cypress, texas
That's brilliant tokumaru!! Will definitely try using shadow \$2001; I didn't even consider the music needing vblank updates. Thank you!

Top

 Post subject: Re: 8x16 and whatever else unreg wants to knowPosted: Mon May 29, 2017 12:10 am

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10814
Location: Rio de Janeiro - Brazil
If you wanted to disable rendering for a big update using this method, you'd first change the \$2001 shadow value, and then wait for vblank (using whatever communication system you have between the main thread and the NMI thread), when \$2001 will effectively be written to and rendering will be disabled. From then on you can update VRAM freely (keep in mind that palette and OAM updates should only take place during vblank, to completely avoid colorful glitches and OAM corruption), because the NMI thread will know not to do any PPU operations other than copying the shadow \$2001 value to register \$2001, a write that should be harmless even if it interrupts other PPU operations the main thread might be doing.

Top

 Post subject: Re: 8x16 and whatever else unreg wants to knowPosted: Wed May 31, 2017 10:48 am

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 927
Location: cypress, texas
So I need to wait for NMI so soft2001shadow can be copied to \$2001 because then rendering will be disabled. And that will help me to be able to run see in the main thread! That`s so cool!

Is it ok to just set \$2001 each vblank without checking first to see if I can? All the pointless cycles wasted; it makes me so happy to not waste cycles. Thank you tokumaru for all of your wisdom you share.

Top

 Post subject: Re: 8x16 and whatever else unreg wants to knowPosted: Wed May 31, 2017 11:42 am

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20564
Location: NE Indiana, USA (NTSC)
Rewriting \$2001 in every vblank is perfectly fine. So is \$2000 as long as the main thread isn't in the middle of a bulk upload.

Top

 Post subject: Re: 8x16 and whatever else unreg wants to knowPosted: Wed May 31, 2017 11:46 am

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10814
Location: Rio de Janeiro - Brazil
unregistered wrote:
Is it ok to just set \$2001 each vblank without checking first to see if I can?

As far as I know, yes. Writing to \$2001 shouldn't have any undesirable side effects, even if it happens in the middle of other PPU operations. But you do need to test whether rendering is on or off to decide whether to do other potentially dangerous PPU operations (updating VRAM, setting the scroll, etc.). Your NMI handler could contain something like this:

Code:
sta \$2001
and \$%00011000
beq PPUStuffDone
PPUStuffDone:
;(APU and other mandatory updates here)

Top

 Post subject: Re: 8x16 and whatever else unreg wants to knowPosted: Wed May 31, 2017 5:19 pm

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 927
Location: cypress, texas
Just wanted to quickly say that your helpful advice made the screen appear. It's not the correct screen, but it is a screen! Tons better than the black screen. Thank you tokumaru so much!!

Have to go make supper; thanks tepples for confirming that 2001 can be assigned every frame.
Thank you all so very much!

Top

 Post subject: Re: 8x16 and whatever else unreg wants to knowPosted: Thu Jun 01, 2017 9:26 am

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 927
Location: cypress, texas
tokumaru wrote:
unregistered wrote:
Is it ok to just set \$2001 each vblank without checking first to see if I can?

As far as I know, yes. Writing to \$2001 shouldn't have any undesirable side effects, even if it happens in the middle of other PPU operations. But you do need to test whether rendering is on or off to decide whether to do other potentially dangerous PPU operations (updating VRAM, setting the scroll, etc.). Your NMI handler could contain something like this:

Code:
sta \$2001
and \$%00011000
beq PPUStuffDone
PPUStuffDone:
;(APU and other mandatory updates here)
Thank you tokumaru for this extra help! Someone recommended I name my 2001 shadow variable soft2001; I also like your PPUMaskShadow but soft2001 is less characters. That won't affect the ROM size, but it will cause my trace log files to be smaller when I want to write the variable name before its address; that helps me to quickly read through certain sections of code when I return to the file.

edit: I made a mistake. I posted somewhere that trace log files would be smaller if they were recorded before hitting frame 1000, but that isn't true because there are 6 characters allotted for the frame #. If it is frame 1 then there's a "1" followed by five spaces. I didn't notice this when I made that untrue statement; I'm sorry. I'm using FCEUX 2.2.2

Top

 Post subject: Re:Posted: Fri Jun 16, 2017 10:23 am

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 927
Location: cypress, texas
tepples, on page 41, wrote:
tokumaru wrote:
The reason why (\$XX, x) is rarely used is because it can't index the target data in any way. Once the address of the pointer is calculated (\$XX + x) and the pointer is used, the target is a single byte. There's no way to access any bytes after that one. If you do wish to access the next bytes, you have to manipulate the pointer itself (INC the lower byte, if it overflows INC the higher byte), which is terribly slow.

But if you do have an array of pointers, such as one pointer for each sound channel, and you only consume a few bytes per frame, 10.02 cycles per increment (INC ptr,x BNE :+ INC ptr+1,x : ) isn't too much slower than 5.02 cycles per increment for (d),y (INY BNE :+ INC ptr+1 : ).

EDIT: cycle count corrected per tokumaru's clarification

I've never understood what the colons are there for in the code
Code:
inc ptr,x
bne :
+ inc ptr+1,x
:

Is that what y'all mean tepples and tokumaru?

Top

 Post subject: Re: 8x16 and whatever else unreg wants to knowPosted: Fri Jun 16, 2017 10:29 am

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20564
Location: NE Indiana, USA (NTSC)
The function of the colon is described in ca65 Users Guide: Unnamed labels. The + goes on the same line as the :, not on the next line.

This code:
Code:
inc ptr,x
bne :+
inc ptr+1,x
:

Is equivalent to this code:
Code:
inc ptr,x
bne @ptr_hi_does_not_need_to_be_incremented
inc ptr+1,x
@ptr_hi_does_not_need_to_be_incremented:

Top

 Post subject: Re: 8x16 and whatever else unreg wants to knowPosted: Fri Jun 16, 2017 10:40 am

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 927
Location: cypress, texas
Thanks tepples! :+ doesnt work in asm6 and + is one character less

edit: (Fewer characters to look at makes it easier for me to comprehend what is going on. )

Top

 Post subject: Re: 8x16 and whatever else unreg wants to knowPosted: Fri Jun 16, 2017 11:19 am

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10814
Location: Rio de Janeiro - Brazil
In ASM6 that'd be:
Code:
inc ptr,x
bne +
inc ptr+1,x
+

+ (plus) is for forward references, - (minus) is for backward references. If you need more than one unnamed label in the same area you can use ++, +++, and so on.

You shouldn't use these types of labels too much, otherwise your code can get really confusing. I only use unnamed labels for really short jumps and in the same "logic block".

Top

 Post subject: Re: 8x16 and whatever else unreg wants to knowPosted: Fri Jun 16, 2017 2:01 pm

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 927
Location: cypress, texas
I guess you already know this, tokumaru, but I use unnamed labels most of the time. They really help with padding!

+jDS means to me that the label is only branched to from < #\$81 bytes before the label. +jDS jmp DrawSprite is paddable afterwards because everything reaching it will jump to DrawSprite.

Top

 Display posts from previous: All posts1 day7 days2 weeks1 month3 months6 months1 year Sort by AuthorPost timeSubject AscendingDescending
 Page 89 of 97 [ 1451 posts ] Go to page Previous  1 ... 86, 87, 88, 89, 90, 91, 92 ... 97  Next

 All times are UTC - 7 hours

#### Who is online

Users browsing this forum: Google [Bot] and 5 guests

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

Search for:
 Jump to:  Select a forum ------------------ NES / Famicom    NESdev    NESemdev    NES Graphics    NES Music    Homebrew Projects       2018 NESdev Competition       2017 NESdev Competition       2016 NESdev Competition       2014 NESdev Competition       2011 NESdev Competition    Newbie Help Center    NES Hardware and Flash Equipment       Reproduction    NESdev International       FCdev       NESdev China       NESdev Middle East Other    General Stuff    Membler Industries    Other Retro Dev       SNESdev       GBDev    Test Forum Site Issues    phpBB Issues    Web Issues    nesdevWiki