Coding NES Subroutines 

Congrats! The patrons chose your code to get pinned! Shout out to the runners up: @dedgzus6808, @kentwidman, and @soulite2574 :D

Thank you so much to everyone who voted for me!

That’ll do nicely for sure.

One tiny and easily fixable issue. It looks like you're storing the player's health and weapon charge on the Stack Page. Just swap out the $0100 and $0101 with $0300 and $0301 and you're perfect! :) Great job though!

@@EvilSandwich Most games don't use the whole stack area so they can store other values there

There are online 6502 assemblers and emulators you can use to begin. I used skilldrick easy 6502, because I was too lazy to dig up my cc65 assembler setup.

Honestly I just think it’s cool that so many people like the things that I like too :)

I always had the same thought to but then after this video I just opened notepad and wrote up some code. Give it a shot.

Programming has been an interest of mine since I was young, but it was super intimidating with no formal education. I started off making copy/paste edits in Super Metroid's speedrun practice hack source and eventually started looking up what the opcodes do. Once I started looking into addressing modes, the doors flew open and everything started to make sense. It's been very rewarding and I wish they'd taught me this stuff in elementary school. Hope you can dig in some day. The 65x processors are awesome.

Honestly and truly: Just start doing it. post about it on rhdn or anywhere else, ask questions, do research, thumb through sections of code and try to understand it. you can make it happen for you, it just takes some focus and a little bit of work. Doing it badly is fine, just doing it at all is fun and rewarding.

Welp that’s how it goes, one sub at a time :)

Agreed 100%

Thanks, I try my best :)

That’s the idea, at least. The hope is that the videos straddle the line between lecture and entertainment, and do it so everyone comes away with something 😀

@@NesHacker You hit it just right! Half way thru, I was like "Yeah, I *should* learn to program in Assembly... for the NES!! "

Maybe you’ll like a lot of my content too. I have a rom of C64 and some Amiga now. And also ARM64 assembly on Linux. But also game hacking cracking which uses 6502, z80 and 68000

Thanks, I put a lot into them so I am glad you like the videos so much 😀

You’re more than welcome, and happy new year to you too, Maverick!

LOL I love your handle! It reminds me of a character from a Yakuza game!

@@jimmyraconteur2522 for all we know, *this* IS a game...

Thanks, I’m happy to oblige :)

The hero, huh? Haha, well I don't know about that, but I am glad I can help!

You’re very welcome, I’m glad to help :)

I considered releasing it yesterday… but I was worried people would be too tired to digest 6502 assembly xD

You’re very welcome :)

Thanks!

-3d on nes-

Nice! It’s definitely work but it is totally doable, just start small and build up from there :)

Nice! This was probably my best editing job thus far, so I hope you like my other videos too.

Haha, yeah… Now that I’ve covered a lot of the basics I feel I can go more briskly and use broader strokes without getting bogged down in the details too much.

Haha, "magnificent" is quite the compliment. Thank you!

Very similar to my method expect you never push values onto the stack to be sure the registers don't get corrupted. also you used a more rigid amount method.

In Super Mario All-Stars (for the Super NES), the lives code for both Super Mario Bros. and Super Mario Bros.: The Lost Levels went like this: lda NumberofLives ; load the current player's lives counter inc NumberofLives ; increase the lives counter by one if Mario/Luigi collects a 1-UP Mushroom, 100 coins, knocks down eight or more enemies in a row with a Koopa shell or Buzzy Beetle, or stomps on a Koopa shell or Buzzy Beetle at least eight times on a stairstep. cmp #$80 ; compare resulting value with 128 bcc EndCheckL ; if A less than 128, we're fine and we can leave the subroutine! lda #$7f ; otherwise, set this value to 127 instead sta NumberofLives ; store whatever number we have, be it 127 or lower, into $075A, EndCheckL: rtl ; and leave! (the RTL at the end means "return from subroutine, long" which indicates we can use this subroutine in other program banks; for example, since the code above is originally in bank 4 at address 0x8596, if we want to jump to it in other program banks we use these four bytes: 22 96 85 04, the leading 22 pointing to JSL, or "jump to subroutine, long")

To answer your question way after you asked it, by convention the $0200-$02FF space in RAM is used for sprite data, which gets written directly to the OAM DMA register on the PPU during VBLANK.

@@Nat-qm5vb Ah, I see. Thank you for answering!

In my version of reality *BRK* , *IRQ* and *NMI* push the processor status register after pushing the return address (three bytes total), but *JSR* stacks only the return address - 1 (two bytes total).

Yeah I am pretty sure JSR doesn't push the processor status. At least according to my 1976 MOS Microcomputers Programming Manual, it doesn't :D

@@NesHacker ah, I'm so sorry for the missinformation, I checked it to, and it appears that I truly confused it with NMI I feel embarrassed, for my irresponsible comment before 😳

Thanks Caleb!

Thanks :D, I’m glad you watched the episode anyway, haha

I'd like to nominate my code for its simplicity and because it gets the job done in only 9 lines of code.

@@dedgzus6808 That was the very reason I chose you as one of the finalists. But now it's in the hands of the patrons ;D

@@NesHacker Haha. Thanks. Also for your information, after I finally got myself around to writing those couple of lines of 6502asm it took hold of me and I've been working on getting a "game" working. Currently messing with getting scrolling working. Thanks for the videos.

I use After Effects for the animations along with Photoshop and Illustrator to create most of the graphics. As far as what I did before the channel? It’s a shocker: I was a software engineer xD

You’re welcome, sounds like you’re in for a world of new fun :)

Thanks!

Thank you, I appreciate that :D

😝

Thanks choom 😉

True, and super useful sometimes!

I guess that’s a lot better than being overrated xD

Thanks! I use Final Cut Pro to edit. After Effects, Illustrator, & Photoshop for graphics.

The plan is to keep going as long as I can ☺️

Atari, C64, and NES programmers are all like cousins. Our choice in console is different, but we all love hacking some 6502 😆

Mhm, I figured some of the newer folks wouldn’t know the term’s origin. So it was a fun thing to throw in there :)

Yeah for sure, it’s always a challenge to figure out what to include and what not to. That’s a super valid and common use for the stack so I should have probably included it!

It's all done as part of the game loop. An event messaging system would be way to heavyweight to implement with such limited system resources. So you would simply do the checks for everything that "can" happen as part of the main game loop logic. Old-school game programming is quite a bit different than modern game engines.

www.nesdev.org/wiki/Nesdev_Wiki - This has a ton of information on programming the NES, but it can be a little hard to get through at times. I don't have any books in particular to share, sorry.

Thanks! I’ll have a look to it.

I mostly use After Effects.

Oh interesting, yeah that's a pretty good idea. I'd have to do the research first, of course (and be able to pull it off myself so I can get a feel for it xD).

Not gonna lie, it’s unreasonable how happy your comment made me xD

So I spend a *lot* of time working on the animations for these videos, usually it is the majority of the work. In some sections I don't want to make things too complicated so the viewer can focus on what I'm saying while using the visual reference to help guide their understanding. That said, leaving still graphics up for too long can make things kinda boring, so I use the jump and camera zooms to keep a sense of motion while focusing on a single shot. If I find a better way to do this in the future, I'll certainly use the bounce less and and less :D

@@NesHacker maybe it's my fault for binge watching all the videos since l discovered your channel yesterday

@@ric8248 Haha I find ZERO fault with you binge watching all of my videos 🤣

Yeah I was pretty happy with the sound design on this one. Glad you liked it! :D

When JSR is called it pushes the address for the RTS onto the stack so you would have to pull that address off of the stack, store it, pull your parameters, store them, run your subroutine, push the return onto the stack and then load your return address, push it onto the stack and then call RTS. I don't know why anyone would do it that way but I am no expert.

@@dedgzus6808 In that calling convention, you would push your arguments before the JSR, and then read them by offset relative to the stack pointer inside the subroutine. (Though as I write this I'm not actually sure if the 6502 has stack-relative addressing. Without that, this would be painful, as you say.)

Reading more, I see that 6502 doesn't have native stack-relative addressing - so yeah, maybe this calling convention wouldn't be very popular for NES programing. I guess in theory you could move the stack pointer into the X register and use it to do indirect addressing. So you could do something like TSX ; Copy stack pointer into X. (I'm assuming that it points to the top of the stack -- if it points to the next free location, we need an extra INX.) INX ; Point one byte below stack pointer, first argument LDA $100,X ; Load argument INX ; Move pointer to next argument CLC ADC $100,X ; Add it to the second argument I suppose it would be easier to achieve reentrancy by passing arguments by known address and having the convention that the caller must preserve and restore those memory locations.

Macros can get really *really* tricky if you use them too much… I plan on doing an episode about my take on them, but here’s the TL;DR: if it’s something where you’d have to write out all the code anyway (e.g. setting parameters for a routine, etc.) then use a macro. If you absolutely have to save the cycles it would cost to perform the JSR and RTS *and* you can significantly improve the readability of your code then use a macro. Otherwise, stick with subroutines.

I’ve done some really small game projects in the past and have been chipping away at a bigger project for a while now, though progress is slow since I started the channel 😂

@@NesHacker Awesome! I can't wait. Do you post dev updates on the project anywhere that I could follow (twitter, etc)?

Mind-blowing, right?

Kinda, so the return values for each routine call will be pushed to the stack and the vectors that define the entry points for interrupt handlers are always located in the same spot of the ROM ($FFFA-$FFFF). It’s a little complicated but if you pause a program at any point you can work out if you’re in the “main” thread or an interrupt handler by working backwards through the call stack until you get either to the main loop or a handler. Though it’s possible to write code that obfuscates this by jumping into an interrupt handler and jumping out before the RTI.

Oops, yeah it's high-byte then low-byte of return address, right?

I use After Effects mostly

I think you might be right... 2023-01-31: 21.2K

Just write a recursive routine without a base case 😛

Well you could, but there’s the issue that they’d be pushed prior to the JSR, so you’d have to do some bespoke stack handling to manage them along with the return address. The approach works fine, but it’s a lot easier to handle parameters in the zero page, especially if you don’t need a generalized and flexible approach (which is usually the case when writing 6502 assembly by hand).

I know I said I was going to make an NES game in a previous comment, but unfortunately I haven't had time. That's going to be my new years resolution I guess, to make an NES game! Currently I only know z80 so I started off with that. I left the z80 in the comment and tried to convert it to 6502 as close as possible. Its my first time using 6502 and I realized using only flags as an input wasn't going to work. Lda modifies the z flag and rol a modifies both the z and c flag. I swapped rol a for lda so I could at least save the carry flag. z80 and 6502 are very similar, just have to forget about the extra registers.

Hey it’s no rush, just start small and chip away at it… But most of all, have fun learning and playing around. Hopefully my videos will help along the way, and know that I’m rooting for ya! :)

dude really went above and beyond with the Z80 code, respect

Z80, nice 😀

@@tr1p1ea Haha, I know you trip, Im the assembly bandit.

I’m hoping to dip into some 16-bit content in the future, I’ll keep you and your wanting to see how sprites work in mind when I do

I think that’s “After Midnight” by Luke Melville. Just so you know, I usually put new songs I use in videos in the description for the video, ordered by when they’re played in the video :)

You can use the stack to hold params, but it's kinda annoying since the jsr instruction pushes the return to the stack. So best case scenario you'd be pulling the stack pointer into the X register and doing some weird offset loads and then finally having to pop them off at the end. Not too bad, but if you're doing something where cycles count (like rendering during a PPU vblank) then it might bite you.

It’s a good point, I considered going in-depth on the stack related registers but I felt it would drag the video a little off topic. That said, no reason I couldn’t do a follow up to give the stack a little more love :)

@@NesHacker I figure you will have a whole video in regards to the stack and all that fun.

I love cake :)

The cake is a lie 😜😆

If you wanted a generalized approach, like an ABI for use by a compiler, you’d basically have to do that. A simple solution would be to have stack frames based on lexical levels to keep track of all the variables in a systematic way based on call. In practice when writing programs at the assembly level you don’t often need to go that deep. For instance, you can store variables elsewhere temporarily when you need to free up the parameter space.

That makes sense, you know… considering 😂

He posted a video which walks you through the environment setup. I recommend checking that out.

I use ca65 which is part of the cc65 suite. Like Randy said, check out my “NES Development Environment” video and I show the tools I use (for the most part, I mostly use Mesen now over FCEUX).

@@NesHacker 👍😃

Hmm… not sure what could be happening. Others have been able to post their code 🤔

@@NesHacker I got it, yt was filtering out if my code contains a link to .asm file

bpl is "branch on plus" or "branch on positive", and ":+" refers to the next label in the code, so that bpl :+ looks at the result of the sbc, cmp's it to the value at $301, and skips the lda #0 if it is greater, presumably to avoid health going negative/underflowing. Hope that helps!

@@grendell Thx man

You’re great @grendell, I’ve been shooting video all day and was finally taking a moment to come answer this and boom! You had me covered :)

Just to add to this answer. :+ refers to the next label. :++ is for the second next label, :- is to go back to the previous label. Usually you use unnamed labels to avoid collisions for some trivial code flow. Like a loop or just whatever you want that you think you don't need to name the label for whatever reason.

No, I put them in the RAM because this is how it is usually done when writing 6502 by hand. If you're working on compiler for a higher level language, this would probably be the way to handle them, but when programming in assembly this would rarely, if ever, be done.

@@NesHacker indeed, that is what a compiler does in general. I wonder why is this strategy not preferred when writing asm by hand.

@@renecura Mostly because of cycle overhead. Using stack manipulation instructions to manage the parameters on the stack adds a lot of cycles. The 2A03 (modified 6502) on the NES clocks in at 1.79 MHz on NTSC, which is really slow. Considering some operations, like VRAM updates, need to be done in roughly 2500 cycles and every little bit of optimization counts. Further, I think doing it that way causes your code to become *less* readable. Since you don't often need recursion, and most subroutines are *not* general purpose. It's best to simply map out the parameters to RAM for the application in most cases, as opposed to using a general purpose approach.

@@NesHacker great! Ty for the explaination!

;After thinking about this for a couple of days, I think this routine should handle all the power-up items. ;I'd like to clean this up while its on my mind ;I'll store the current power-up item info in one masked byte @$0444 ;Edit, I forgot the Etanks currentHealth = $0300 ;current health level currentWeapon = $0301 ;current weapon level currentLives = $0302 ;current number of lives left currentEtanks = $0303 ;current number of etanks left collectedLetters = $0304 ;One byte that has the high 4 bits for the Beat letters collected and we can use the remaining 4 bits for something like the power balancer from MM6 powerUp = $0444 ;power-up ;Weapon/health-up when bit1 is set, bit0=weapon/health modifier (0 is health and 1 is weapon) and bit4/5 determine if its +16 or +32 weapon/health-up ;1-Up/Etank when bit2 is set, bit0 1=Etank, 0=1-Up, the other 6 bits arnt used in this case ;Beat letter (or power balancer) when bit3 is set, bit7=B, bit6=E, bit5=A, bit4=T, bit0=Power Balancer power-up: lda powerUp ; load powerUp byte to A and #$02 ; begin checking if its a health/weapon-up by looking at bit1 beq :Other Item ; if A is 0, branch to then check what kind of item it is lda powerUp ; load powerUp byte to A again and #$01 ; determine if its a health/weapon-up by looking at bit0 tax ; store result of A in X as our health/weapon modifier lda powerUp ; load powerUp byte to A for a 3rd time and #$30 ; so we get only the increase value of +16 or +32 clc adc currentHealth,x ; refill current health/weapon, offset by X cmp #$64 ; is the new value more than 100? bcc:+ ; branch over the next line if the carry is clear, meaning that adding the refill didnt exceed 100 lda #$64 ; load 100 (max refill) to A, we wont run this line unless we've met or exceeded max refill of 100 :sta currentHealth,x ; store new health/weapon amount after adding refill jmp End Sub-routine: ; jump to the end of the sub-routine Other Item: lda powerUp ; load powerUp byte to A, again and #$08 ; begin checking if its a BEAT letter or Power Balancer by looking at bit3 beq :Add 1-Up ; if A is 0, then item must be a 1-Up/Etank by process of elimination, jump to that code to finish it up lda powerUp ; load powerUp byte to A for the third time (didn't I say that already?) eor #$08 ; Exclusive Or out the bit that identifies it being a Beat/power balance item clc adc collectedLetters ; the location in RAM would have the same bit mask BEAT---(PowerBalancer), so I think adding it is okay, non? jmp End Sub-routine: ; jump to the end of the sub-routine Add 1-Up: lda powerUp ; load powerUp byte to A, again and #$01 ; check if its a 1-up/Etank by looking at bit0 tax ; store result of A in X as our 1-Up/Etank modifier inc currentLives, X ;increment lives or Etanks if X is 1 End Sub-routine: rts ; return from sub-routine ; I think that should do it. This time took me less time than the first

Yeah it’s fun, there’s a whole hobby community of folks that do 😁

Any and all feedback would be welcome.

I’m afraid that’s gonna cause a buffer overflow, you forgot the null character at the end! ;D

🥺

Queues are FIFO (First-In First Out). Stacks are very much FILO or LIFO (First-In Last-Out, or Last-In First-Out).

@@NesHacker you’re right. Looking at this again idk what I was thinking when I posted that

I don't know who that is 🤔

Looks good to me. This should be pinned.