|
Post by Stan on Apr 8, 2009 19:35:53 GMT
Phew, I've been adding some more things to the assembly section, including some breakdowns of assembly code in relation to C code to show how it works. Again, this is going to be very, very basic stuff for a number of you, this is assuming the reader has zero knowledge of assembly. Almost done.
|
|
|
Post by Shin on Jul 10, 2009 4:05:50 GMT
Are u still writing these tutorials Stan?
|
|
|
Post by Stan on Jul 11, 2009 14:23:07 GMT
Yep, I'm almost finished with the assembly section. I'm debating whether or not I want to include in there talk about indirect addressing and a few other issues. I'm not sure it's necessary for a basic entry into assembly, that's something that can likely be explained later. Once I get this section up things will run a lot more smoothly because I can start posting some of the code I've made for usage in the tutorial.
|
|
|
Post by Stan on Jul 13, 2009 13:15:47 GMT
Well, Shin my man, the Assembly tutorial is finished. Tonight I should have time to finish the table of contents box and add pictures and it's good to go. Things will move faster after this one, I took a lot of time deciding on what to put up there and writing small, fake programs to show different things. I decided against indirect addressing, it can wait until we actually use it. The code I had written for it was way more complicated than I needed for that step. After this one we're going to go into the first program I have written for people to mess with, followed by backgrounds, sprites and then further. That stuff won't take as long because it will involve me simply showing what I have done, explain it, show you how to work with it and then set you off to make your own.
|
|
|
Post by Stan on Jul 15, 2009 0:07:42 GMT
Horray. Without further ado, check out my assembly basics tutorial a here and get started. Some things to keep in mind: 1. YES, I'm aware there's no actual code to actually work with in this part yet. What there is are examples to show how assembly looks and works, that's the important issue I wanted to tackle. The next section, which I'm a good way into already, will be the first program to work with using actual code you can manipulate and put through an emulator. 2. Though I could have selected a number of topics, based on how I've seen various books and websites set up, the format I've used here for presenting the information should be easy enough for the novice to grasp without seeming too daunty. Assembly isn't easy, but the way I have it organized should make it seem a hell of a lot easier to grasp. 3. C code is included in the tutorial, ONLY for contrast. I explain several times that it's just being used for this purpose, so don't worry if you don't know it. I feel I've explained what you need to know about it anyway, but in case there are any problems with what you read let me know how to make it clearer. 4. The instruction set at the end is currently only there for reference. Over time I will be attaching separate files to each one detailing how they're used so you have a general reference guide in one place when you need it. Most of this stuff will be learned in context, but it's something I want to slowly build on so it's all there. As such, it's just a list now, so don't complain!
|
|
Aypok
Sonic the Hedgehog
Posts: 2,372
|
Post by Aypok on Jul 15, 2009 8:00:32 GMT
A few niggles on page two:
Penultimate paragraph:
No, we use languages because they're quicker - in terms of development time. Coding in binary is far from impossible, it's just not worth it when there are languages which speed up development (at no performance cost).
In the final paragraph, you say "C+" instead of "C++". Minor typo, but it's probably worth correcting.
Also in the final paragraph:
Not strictly true, since haroldoop (?) converted some C compiler to output SMS-compatible binaries. :)
/me Aypok resumes reading.
|
|
|
Post by Stan on Jul 15, 2009 13:36:56 GMT
Hahha, yeah, I suppose so. Thanks for picking out those errors, I'll get on them. Let me know if you notice any problems in the rest. It will probably be worthless to you since, as far as I remember, you already know how to mess with sprites and stuff, but let me know anyway if you find anything else I missed. Yeah, binary is possible, but I was always under the assumption that working specifically from it in even older programs like this was near impossible unless you wanted your eyes to melt.
|
|
Aypok
Sonic the Hedgehog
Posts: 2,372
|
Post by Aypok on Jul 15, 2009 14:45:58 GMT
It will probably be worthless to you since, as far as I remember, you already know how to mess with sprites and stuff Yeah, but it's always worth reading since I may pick up something I didn't already know. Plus, I can proof-read and check for technical errors. :P Yeah, binary is possible, but I was always under the assumption that working specifically from it in even older programs like this was near impossible unless you wanted your eyes to melt. I agree, but it's not impossible. :) That's all I was saying. In fact, you go on to say as much on the next page of your guide. Heh.
|
|
|
Post by Maxim on Jul 15, 2009 17:39:52 GMT
Gah, these huge blocks of text saying almost nothing...
1. Traffic light sensors use inductance, not sound. Not all lights have them, and most continue to change even if no car is detected (sucks to be a cyclist otherwise).
2. Why are there 7 bits in your bytes? It might be better to show "programming in binary" by referring to something like an Altair 8800 which you programmed by flipping the switches in binary, rather than suggesting some guy sat at a text editor typing in 0s and 1s.
3. Hex wasn't invented to avoid typing binary. Different number bases have been used for millennia. The Babylonians apparently used base 60 as their primary system. The main reason we use hex is that it maps 8 bits to exactly 2 characters, which is handy. Base 4 and base 256 are the only other options, and they suck.
4. If you've been at it for long enough, you do remember a few opcodes. C9 = ret is always useful. FF = rst $38, 00 = nop... but yes, you don't need to learn them.
5. "Currently, assembly isn't really used by anymore anymore" - couldn't be more wrong. It's used whenever speed is critical or you need to do something inexpressible in higher-level languages, for example in video processing algorithms and in device drivers.
6. "the bear minimum" - I tihnk yuo hvae smoe ltetres mxied up
7. "Assembly language starts with instructions" Could very well have been the first sentence of the guide without losing anything
8. Organising things into fields is not very helpful (then again, nor is mentioning directives at this point). In the olden days you may have had a fan-fold printout with the labels in field 1, opcodes in column 2, parameters in column 3 and comments in field 4, but (as in your example) these days we just whitespace more creatively by having labels (and often comments) on their own lines.
9. ";load value into A" - this is a great example of a bad comment, because it's just the code read out loud.
10. "Labels are always followed by the symbol : and do not have any size restrictions" - wrong and wrong. I think WLA DX has a 63-char limit by default. Colons are optional.
11. "operation code" - opcode usually refers to the binary/hex value rather than the instruction mnemonic. If nothing else, "ld" is not an opcode because the interpretation depends on the parameters.
12. "look at the last link above" - where?
13. "This is short for 'accumulator, (VALUE)'" - but if you typed that, it wouldn't work. I think most people think "register a", not "accumulator".
14. "whatever you want to do in Z80 Assembly, you will be writing it in the reverse order" - no, you generally specify things in the order "dest, source". The use of the "load" mnemonic helps here - "load dest with source" is more English than "load source from dest". Intel went with "mov" for "move", which arguably is more confusing this way around.
15. "ld a, value is our operand here" - I thought it was ld a, (value), i.e. you were using indirection. Better not to use brackets here.
16. If you're going to only talk about line comments then you ought to say that they apply from the semicolon to the end of the line. As it is it's ambiguous as to where the comment ends.
17. "ld hl, 65D" - not acceptable to WLA-DX.
18. "We're only going to be working with binary and hex" - that'll make it harder. Decimal constants are very useful.
19. add hl, number - not a valid opcode.
20. "Whatever is in hl at this time is added to number2" - I'd go with "number2 is added to whatever is in hl at this time" to make it clear that the result goes into hl.
21. "we move the current value of hl into another variable" - I'd hesitate to use the word "variable". I know you're trying to be vague and ambiguous here rather than nail it down, but it's either going to memory or a register; there's no real concept of variables in assembler precisely because you have to differentiate between the two.
22. "int i, j, k:" "i = 1" - punctuation matters, even in pseudo-code.
23. "i dw ? ; variable defintion " - not in WLA DX, more so not on the SMS because we assemble to ROM; you don't just .db to reserve some RAM!
24. Using i, j, k as if they are registers seems odd. Most good programming books compile and test all the sample code, even if it's just a snippet. It's hard work but it will help beginners not to post stuff that simply doesn't work.
25. "compare whether a value in register pair hl is the same as one in a (accumulator)" - how do you compare 16 bits to 8?
26. "cp (hl) ; compare hl to a " - no no no no no... if you don't understand what brackets mean then don't use them in your tutorial. "To compare a to hl, hl must be enclosed in parenthesis. This isn't a special trick, just a syntax requirement. Remember, every language has its rules, and if you want to compare the accumulator to register pair hl, you put hl in parenthesis in Z80 Assembly." Stop digging.
27. "jp NextNext" - is a no-op. (Also, you ought to inc/dec rather than add/sub 1. Premature optimisation FTW!)
28. "'jr' stands for 'jump relative', meaning that the program flow will only jump to a specified location if a result is achieved" - nope. Relative jumps are either for relocatable code or for space/speed optimisation. You can attach conditions to both relative and absolute jumps - in fact, the latter can take more conditions (sign and parity).
29. "'low memory', like the operating system itself, and then high memory, which typically ends with the stack" - what operating system? You can create your stack at $c100 if you want (some games do), having it at the top is just a convention. Low and high memory does not mean anything here.
30. "push is taking the value stored in hl in our example and moving it to the stack, it's not there anymore" - I actually laughed out loud at that one.
31. "will go on top of what we just placed there from hl" - "above" might be a better word, the point you're trying to make is that it's not overwriting. (I won't get into the confusion of using "above", "top" to refer to a downward-growing stack.)
32. "When you load $A534 into hl, the high end goes into register h (34), while the other part, the low end, goes into register l (A5)" - you got them the wrong way round. It's only in memory that they get "reversed".
33. You talk about return addresses and ret usage of the stack to explain the dangers of messing it up, but you never really explained how the stack is used for function calls.
34. "emluator"
35. A lot of the WLA DX directives are not relevant to SMS programming. "ENDSNES"?
|
|
|
Post by Stan on Jul 15, 2009 17:51:20 GMT
Thanks! I'm actually not referring to the actual usage of WLA DX in this part of the tutorial, that's why some of the things I mention are not applicable. I also need to go through that list and remove anything that won't be used, but, as I said, it's just there for now, there is nothing you can do with it yet.
The most important thing I wanted to do here is take what I used to figure things out before I actually started to make programs and put it into an easy to read format. The important thing in this part was just just illustrate how assembly looks and BASICALLY how it functions, as I state numerous times the "code" can't be used for anything. I could have used real examples, but I wanted to simplify it as much as possible without losing too much. I had it written in some parts using actual code, but it required explaining more than was necessary for a basic understanding of it. Thanks for the corrections, I'll get on them! I see there were a few things I went through and added but forgot to correct, like where I mention comparing hl with a and where I used the add opcode. Anyway, all I needed was an eye to spot them.
|
|
|
Post by Stan on Jul 19, 2009 18:49:37 GMT
Well, since I keep getting PMs with some questions and also people asking when I'll have the stuff done so they can get started, I've decided to start putting this up page by page, instead of waiting until I have the whole shebang done each time as I did before. Therefore, without further ado, you can access the new part of the tutorial HERE. For now, it is the introduction page, followed by the page with all the tools and references you need to download with instructions on what to do with them. What will be following as I go along will be a program to download and work with, how to mess with it, learning a bit about timing, the 'include' directive and other things. All the basic stuff before doing some more detailed programs like backgrounds and sprites.
|
|
|
Post by Maxim on Jul 20, 2009 17:47:51 GMT
It's not super-necessary to let people download the WLA DX source. The Linux maniacs will be happy, though. The win32 binaries include everything you need.
I ought to update compile.bat, there's a voodoo win32 batch thing involving the text "%~dp0" that avoids the need to edit it.
I honestly don't remember giving permission to snaffle my stuff but I imagine I'd have agreed to it anyway.
Dega is a relatively inaccurate emulator (so things that work in there may not work on a real system, and vice versa), and has no debugger! How long can you develop like that? Switching to Emukon gets you some of the way but its debugger is much less powerful (and slower) than Meka's.
|
|
|
Post by Stan on Jul 20, 2009 19:02:23 GMT
Cool, I'll place a link to a Meka download in there as well. Dega is just what I've always used since it requires hardly anything. I have the PM that you sent to me originally. At any point if there is something in there you don't approve of, just let me know.
|
|
|
Post by Shin on Jul 21, 2009 13:05:56 GMT
Thx for taking the time to write all these i appreciat it
|
|
|
Post by Stan on Jul 21, 2009 13:20:27 GMT
Who is this mysterious Shin and why don't you register with us? I must know the secret.
|
|