Santiago: I agree pretty much with ECM. The best way to learn is to look at the code someone else has written and try to understand it. Unfortunately, most ASM coders aren't very good at comments/documentation, and you really need the comments to help you figure things out. Looking at uncommented code doesn't seem to help me very much -- I need to try and figure out how the coder was thinking, not just the result of the thinking.
I put LOTS of comments in my code -- I'm sure at least some people think too many. Almost every line of the source has a comment, and each "subroutine" has a comment header similar to what ECM has (but my "style" is different than ECM's). The comment header includes details about what the subroutine does, its inputs and outputs, and what it may change. The header MAY also include the "context" of when and where the subroutine should get used, and why the subroutine even exists at all (especially if it is there to address some "special" situation). For example, most of my programs are TSR's and in the most recent versions I'm working on the programs can use different kinds of memory: conventional, upper, Expanded (EMS), and/or Extended (XMS, which I access through a DOS Protected Mode Services or DPMS server). I have comments to try and explain why I do something that requires a special consideration for one of the different types of memory. An example of this would be that you NEVER want a stack to use Expanded memory, so sections of the code related to the stack need to take that into account and should make some comment about it. When I first started (a LONG time ago), modern assemblers like NASM & FASM didn't exist, and I didn't like MASM (though it was and still is kind of "the standard" I find it confusing), so I ended up buying A86/A386 from Eric Isaacson. Unfortunately, Eric hasn't updated those in a long time and it's not possible to do large projects with them because they don't take advantage of extended or expanded memory. I've since switched to NASM, but I think FASM is also pretty good, and they're both free (unlike A86/A386). I've got a couple of books, but really the only "fixed" resource I use is Ralf Brown's Interrupt List (RBIL). I've found looking at other people's actual production code is the best way to learn things. I also think the best way to get started is to actually write a small but useful program from scratch -- a program that you will actually use when you get done. Don't make it try to do too much -- just something relatively simple. The very first program I wrote was a simple version of JOYKEYS, a program that allows you to use a Joystick with almost any DOS program. The first version was pretty basic, and it's changed a lot over the decades compared to how it started. There are lots of things you need to understand (memory, I/O, Interrupts, BIOS, DOS, etc.) to even write a simple program. The ASM part of it, while pretty complicated, is not the hard part. The hard part is figuring out WHY you do (or don't do) certain things. _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
