8x16 and whatever else unreg wants to know
Moderator: Moderators
Re: 8x16 and whatever else unreg wants to know
VRC1, Bisqwit's MMC4 subset (doesn't use tile switching), and NINA-001 seem to all be reasonable ways to get 4+4 CHR banking with PRG banking, for less overhead than MMC1.
Other than the complication of possibly needing to handle interrupting MMC1 writes, I'm not clear the extra 4×(4+2)=24 cycles per bankswitch is particularly worth caring about, though.
Other than the complication of possibly needing to handle interrupting MMC1 writes, I'm not clear the extra 4×(4+2)=24 cycles per bankswitch is particularly worth caring about, though.
Re: 8x16 and whatever else unreg wants to know
Depends on how often you switch banks. If you do it 20 times or more per frame, it really starts to add up! 20 x 24 = 480 cycles, which's 1.7% of the 240 scanlines of picture. And it should actually be a little slower than that, because if you switch banks in the NMI for playing music, for example, the bankswitching routine used in the main thread has to do some additional steps to verify whether it was interrupted.lidnariq wrote:I'm not clear the extra 4×(4+2)=24 cycles per bankswitch is particularly worth caring about, though.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: 8x16 and whatever else unreg wants to know
Just wanted to say that this code was reduced by one more character:unregistered[color=#00FFFF], on top of page 92[/color] wrote: edit2 20171006: thought it would be good to say that the code I mentioned "posted above" was reduced tobecause the beginning of the first 15 banks in our game always start at $8000Code: Select all
.rept 256 .db <$ .endr
Code: Select all
.rept 256
.dl $
.endr
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: 8x16 and whatever else unreg wants to know
This is not true for our game. The end of my VBlank handler looked something like this:tokumaru[color=#00BFFF], on page 43,[/color] wrote:Setting the scroll should ALWAYS be the very last thing in your VBlank handler.
Code: Select all
jsr update_vram
;modify the flag
inc FrameReady
SkipUpdates:
jsr FamiToneUpdate
;"Setting the scroll should ALWAYS be the very last thing in your VBlank handler." -tokumaru pg 43
lda needscroll
beq +end
lda FORWARD_scroll
beq +
jsr scroll_screen
jmp +end
+ jsr scroll_screen_left
+end ;return from the NMI (vblank)
pla
tax
pla
tay
pla
rti
edit: tokumaru, I understand now that there was a hidden reason behind your words that are quoted above... posted this to help others who read your quoted statement. I really respect you tokumaru; thank you so much for all of your fantastic help and ideas!
edit3: changed a "to" to "too" and changed text referring to page 92 to refer to page 91. Two mistakes corrected
Last edited by unregistered on Fri Oct 27, 2017 8:42 am, edited 2 times in total.
Re: 8x16 and whatever else unreg wants to know
Correcting myself: setting the scroll should be the last PPU-related thing in your vblank handler. And you must keep track of how much time your vblank handler takes, because the scroll has to be set before the vertical blank ends. After setting the scroll, you're free to do things that do not affect rendering, such as playing music, reading the controllers, and whatever else you need to do at 60/50Hz.
If you know what you're doing, you can do a number of PPU operations outside of vblank, but if you're not sure, it's better to ask.
If you know what you're doing, you can do a number of PPU operations outside of vblank, but if you're not sure, it's better to ask.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: 8x16 and whatever else unreg wants to know
^Thanks tokumaru!!
tokumaru, your page of low bytes of the address, it has helped me to save two cycles and a zero page variable!
in some code like this:
adc $8000, y takes 4 cycles and is 3 bytes big
adc ejectLRvalue took 3 cycles and was 2 bytes
but, being able to comment the sty ejectLRvalue saved 3 cycles and 2 bytes! So the code is the exact same size with the changes and it is 2 cycles faster! (it will never run both sides of the branch)
tokumaru, your page of low bytes of the address, it has helped me to save two cycles and a zero page variable!
in some code like this:
Code: Select all
;sty ejectLRvalue
;code affected by y here
lda altoX
ldx FORWARD
beq +zero
clc
adc $8000, y;will add whatever value is in y :) ;was adc ejectLRvalue
;rest of addition to 16bit value altoX here
jmp DrawSprite
+zero
sec
sbc $8000, y ;was sbc ejectLRvalue
;rest of subtraction from 16bit value altoX here
DrawSprite:
adc ejectLRvalue took 3 cycles and was 2 bytes
but, being able to comment the sty ejectLRvalue saved 3 cycles and 2 bytes! So the code is the exact same size with the changes and it is 2 cycles faster! (it will never run both sides of the branch)
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: 8x16 and whatever else unreg wants to know
Code: Select all
0C1FC A6 60 ldx FORWARD
0C1FE 4C 01 C2 jmp +
0C201 .pad $c201
0C201 F0 0F + beq +zero
But, the jmp, being 3 cycles, is faster than two nops, 4 cycles. For me, it is important that beq +zero not branch to a different page. And, if bytes are ever removed from before 0C1FC, the code would still work fine.
edit.
Re: 8x16 and whatever else unreg wants to know
That's called relative addressing. Since most conditional jumps don't need to go very far, the 6502 was designed to make these jumps smaller and faster, by encoding the target address as an 8-bit displacement rather than a 16-bit absolute address. The downside of that is that when you do have to conditionally jump to an address that's far away, you have to branch (testing for the opposite condition) over a JMP instruction.unregistered wrote:You know how branches start with the following address and then add the second byte to reach the address branched to?
JMP uses absolute addressing, so the actual destination address is the instruction's operand.Does jmp act the same way? No, I think, because why would the 6502 waste time thinking about the next address? Just set the PC to the address in bytes three and two.
People normally use macros to ensure that no unwanted page-crossing happens... In ca65 it's trivial to write a macro that checks whether a branch instruction's address is in the same page as its destination address, and throws an error/warning if it isn't.For me, it is important that beq +zero not branch to a different page.
I personally tend to put code with this kind of sensitive timing near the start of the bank, where it's easier to predict where things will end up, and there are less things changing and shifting addresses.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: 8x16 and whatever else unreg wants to know
Relative and Absolute addressing... thank you tokumaru, I forgot about those terms. A macro that gives an error if the branch crosses a page? That's interesting; thanks for introducing me to that! The assembler always gives an error if the code before a .pad overflows the pad address... so that has been working well for me.
Branches used at the start of pages is a great idea, that's what I try to do too; this branch is in the middle of my main loop so it just needs to be moved to the next page. My knowledge of code that needs to have perfect timing is pretty vague. It really helps sometimes when branches are moved/changed to prevent page-crossings so all of my branches are imprisoned within their respective pages. After doing that for a while it's not hard, or painful, and just part of the journey.
Branches used at the start of pages is a great idea, that's what I try to do too; this branch is in the middle of my main loop so it just needs to be moved to the next page. My knowledge of code that needs to have perfect timing is pretty vague. It really helps sometimes when branches are moved/changed to prevent page-crossings so all of my branches are imprisoned within their respective pages. After doing that for a while it's not hard, or painful, and just part of the journey.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: 8x16 and whatever else unreg wants to know
shiru[color=#FF8000], in famitone's readme,[/color] wrote:- Only Volume, Arpeggio, and Pitch envelopes (no Pitch for noise channel) supported
Does that change from "envelopes" to "sequences" mean that shiru has added support, in famitone2, for using the "Duty / Noise" effect when "#" is 1? For me a sequence implies 2 or more; I'm hoping shiru thinks the same way.shiru[color=#FF8000], in famitone2's readme,[/color] wrote:- Only Volume, Arpeggio, and Pitch sequences (no Pitch for noise channel) supported
I don't have famitone2 set up; I tried to set it up once, but failed to get it to act normally; have set up a new instrument in famitracker 0.4.6 and checked the box next to "Duty / Noise" so that the same notes following each other, when assigned different instruments, are recognizable; sounds pretty cool; hence my question.
edit: I guess the answer is no because the window is titled "sequence editor" and so I have a sequence of 1 and "Duty / Noise" sequences aren't supported.
Last edited by unregistered on Wed Jan 17, 2018 4:21 pm, edited 1 time in total.
Re: 8x16 and whatever else unreg wants to know
I understand "sequence" and "envelope" in FamiTracker to refer to the same concept. FamiTone2 supports only sequences of length 1 in Instrument editor > Instrument settings > Duty / Noise > Sequence editor. Some other NES audio drivers, including some that can import from FamiTracker, do not have this limit.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: 8x16 and whatever else unreg wants to know
^tepples, that's great news, THANK YOU SO MUCH! So, if "sequence" and "envelope" refer to the same concept in famitracker... does famitone support a "Duty / Noise" sequence of length 1 too? I'll try that tomorrow.
Re: 8x16 and whatever else unreg wants to know
As far as I can tell, in both major versions, a "Duty / Noise" sequence has a maximum length 1. This means instruments' attacks are slightly less interesting than they'd otherwise be. You can't, say, make a piano patch that starts at duty 2 and switches to 1, or a brass patch that starts at 1 and switches to 0, or a hi-hat patch that alternates duty 0 and 1.
Two years ago, I ran a poll about which features not in FamiTone2 are most important to composers. The winners were "Cymbal duty" and "Pulse duty sweep".
Two years ago, I ran a poll about which features not in FamiTone2 are most important to composers. The winners were "Cymbal duty" and "Pulse duty sweep".
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: 8x16 and whatever else unreg wants to know
Wow, tepples, after following your link to your poll, I understand now that FamiTone failed to include the 1/8 1/4 1/2 pulse duty sweep; but, FamiTone does include setting a "Duty / Noise" sequence to 1 and that's exactly what I need!! Thank you so much for your replies! You seem to be extremely experienced in forming an exhaustive range of sounds on the NES!
I turned up the sound on Thwaite, never have played it with loud volume, and your sound expertise is so much fun to listen too!
I turned up the sound on Thwaite, never have played it with loud volume, and your sound expertise is so much fun to listen too!
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: 8x16 and whatever else unreg wants to know
Why doesn't FamiTone (or FamiTone2) support Bxx forward references? It's crucial for the song that was just finished. Why must FamiTone songs always require full frames? It's so restrictive and unfair, to me.
edit: FamiTone supports Bxx backward references, if that is the correct term, so how much bigger would it have to be to support forward references? Could I easily add that ability to Famitone? Well, maybe no cause I bet I'd have to rewrite the TextExporter.dll and changing a dll file doesn't make sense to me.
edit2: There is only one Bxx forward reference in the song... it happens at the end of frame 02, but the third frame has Pulse 1 04 and that's repeated in another frame so can't simply move the notes backwards to fill up the rest of Pulse 1 04.
final edit: Does Famitone support just 1 forward reference? Maybe my file isn't being exported by TextExporter because Pulse 1 starts with 01 instead of 00? My mistake.
edit: FamiTone supports Bxx backward references, if that is the correct term, so how much bigger would it have to be to support forward references? Could I easily add that ability to Famitone? Well, maybe no cause I bet I'd have to rewrite the TextExporter.dll and changing a dll file doesn't make sense to me.
edit2: There is only one Bxx forward reference in the song... it happens at the end of frame 02, but the third frame has Pulse 1 04 and that's repeated in another frame so can't simply move the notes backwards to fill up the rest of Pulse 1 04.
final edit: Does Famitone support just 1 forward reference? Maybe my file isn't being exported by TextExporter because Pulse 1 starts with 01 instead of 00? My mistake.