Originally posted by Koopster
lol, I just read your entire tutorial like 2 weeks ago. I already knew some of the basics by reading up 65c816 manuals, but it definitely helped me situate myself on some stuff (notably the banks diagram, which I couldn't find anywhere else).
That banks diagram was something I drew up in paint real quick. I plan to replace it with a... better-looking image, soon. Of course, the exact memory mapping depends per cartridge but the one I use in the tutorial is the general consensus in SMW hacking.
Originally posted by Tahixham
Great to see you're still actively working on this sorta thing too
To be honest, everytime I think I'm done with the tutorial, I just find something to improve about it. For me, it's a continuous process of learning new things. Not just in ASM, but everything around that context too. Writing tutorials, proofreading text, and so on.
Originally posted by WhiteYoshiEgg
Skimming over it, this looks like a really well-written tutorial, and coming from you, why wouldn't it be. You can be sure this is where I'll point newbies to from now on.
Also, I just *love* how professional this looks! I love thinking about writing tutorials, and Gitbook (hadn't heard of it before) is a service I definitely need to keep in mind for that.
Thanks, that's awesome to hear!
And well, I'd say don't think too much about it. Rather, just writing down a few words or topics and slowly work on it. The most important part is that you get started at all.
Originally posted by imamelia
Nice. Even though I already know all this stuff, I'm reading through it just for fun. Do you need a proofreader to catch typos and grammar errors?
Thanks for the offer. It's all good for now; maybe once I consider the tutorial to be complete/non-WIP.
Originally posted by Major Flare
from a MS. researcher, I have to give to you: great work.
Now, I have two suggestions/additions you could make as is: first, Asar actualy comes with a .xml that, set in Notepad++, enables 65c816 syntax highlighting. Second, and this could be not necessarily a basic thing, but I feel it could be explained in the binary section: two's complement. Your tutorial already deals with complicated things in a programmer's point of view (let's be sincere here, assembly is a hard language already), and adding the two's complement would be a nice thing not only to know about it, but it has its applications in SMW, the most common one being sprite. That is, you would make it more clear for novices and even lower-intermediate coders why some speeds are in the range $80-$FF (the significance of the MSB when dealing with negative numbers). We could debate, too, the fixed point for more advanced lessons, albeit SMW uses them less (I can think about SMW's trigonometry routine and accumulated fraction bits for Mario and sprites' motions).
MS. researcher, as in, Microsoft researcher? I sort of got the inspiration from Microsoft Docs, when I was looking around the documentation for one of my projects. It was just so easy to navigate to places, I thought my tutorial should have that as well.
I didn't notice asar has the XML file. I'll definitely mention it in my tutorial. As for the two's complement, I do mention "signed" and "unsigned" values in the hexadecimal
chapter, although not super in-depth.
Originally posted by Telinc1
This is incredible. What I like the most is that you explain ASM and its runtime behavior before you touch any of Asar's compile-time (assembly-time?) features. One of the most common mistakes I've seen beginners make is confusing ASM and Asar's directives (e.g. trying to use if or read1 with a RAM address), which is why I think it's so important to make the distinction clear not just with an explanation, but with the structure of the tutorial itself.
Is there a particular reason you use the term "bytecode" instead of "machine code"? In my experience, "bytecode" is more often an intermediate representation meant to be interpreted (e.g. Java bytecode or bytecode for Ignition in the V8 JS engine), while "machine code" is bytes that are directly run by the processor.
Something I'd add is a rule of thumb for cycle counting - each byte accessed costs a single cycle. An 8-bit LDA $7E0019 needs one cycle to read the opcode, three to read the address, and one to read the value at that address - or five total. AFAIK this isn't how the processor actually interprets the instructions, but it works well enough if you want a quick estimate.
I can understand the confusion. This is why I have dedicated a (new) chapter just for the most commonly used asar directives, such as getting a table's size and using compile-time math.
To be honest, I do not know why I went for bytecode when in the glossary I also mention it's "machine code". I'll just change it to machine code instead. I'm not too much into low level programming languages actually, so it could be that some of my terminologies are a bit off. I'll fix this.
That rule of thumb is pretty interesting. I'll add it to the tutorial for sure.
Thanks everyone for the kind words and feedback so far! Once again, I got shown that this tutorial is super helpful and valuable in the community, so I'll do my best to keep it as good as possible.
. I could post stuff now and then
My Assembly for the SNES
tutorial (it's actually finished now!)