Tuesday, March 30, 2010

assembler tutorial: intro 1 of 2

assembled 'neath a dark, foreboding sky

as promised, a little dos and linux assembly language tutorial in several verses for your consideration. mostly dos though, for that is where my dark past lies, but a little linux is good for the soul (and the understanding.) before we begin in earnest, two things:

first, assemble (huh) your 'a' team, the tools you will need to code along with me. since i work on mac, linux and vista platforms i find great comfort in the familiarity of a singular environment across all machines that i (might) happen to be writing code on at the moment. for this, i use dosbox, a great little dos + x86 emulator. it may have been primarily designed for running classic games like wolfenstein or ega trek, but it makes for a pretty decent development platform, too.

to write your code you'll need a text editor. alas, a good dos text editor for writing assembler is only a pipe dream (this used to not be the case, but i can't find my old tools anymore.) editv, however, does provide must-have line numbering and is one of the easiest editors to use. i still prefer vim, but the dos version of it is really lame and i don't intend to teach vi editing in this blog.

we'll be writing code specifically to be assembled by nasm, the netwide assembler. Hello World Text there is no such thing as "standard assembler syntax," so every assembler has its own idiosyncrasies. one of the reasons i'm writing these tutorials is to teach myself nasm: i actually learned on tasm and worked on masm in the bronze age of computing. the concepts are the same and linguistic differences are often minor, so it's nothing to break a sweat over.

some of the programs we write will require a linker. i'm using the public domain warplink for this. and finally, since most of these utilities are packaged as .zip files, we'll snag the darling of dos bbses the world over, pkzip (the second-finest piece of dos shareware ever written.)

install dosbox and create a folder in your home directory to keep your work in. i called mine dos. edit the dosbox configuration file by adding a few lines after the [autoexec] section at the very end. mine automatically mounts my dos directory as drive c and adds several directories to my path variable, like this:

# Lines in this section will be run at startup.
@echo off
mount c ~/dos

once you've done this you can start dosbox (which should drop you into your c drive) and use the dos command md to create the directories nasm, warplink, editv, pkzip, bin, and mycode. run the command dir and ensure that eight directories exist (this number includes the . and the .. directories.)

copy pk250dos.exe to the dos/PKZIP directory and run the executable inside dosbox. you will find that when you modify the dos filesystem from your host operating system outside dosbox, those changes don't appear when you list the directory inside dosbox. dos likes to cache the directory lists to speed things along, so if it is unaware of changes you made from outside the environment it pretends that they aren't there (they really are.) to force the changes to appear you can clear the directory cache with the rescan command.

copy the rest of the programs listed above to their respective directories and, in dos, run rescan and unzip each of them like this example:

C:\EDITV>pkunzip editv41u.zip

when all this is done, close and reopen dosbox (you can type 'exit' at the dos prompt to close) and verify that you can run all these programs from the root directory of drive c by just typing their names: editv, nasm, and warplink. if you run into any dosbox trouble, refer to this little article. if everything works as expected, your path is set up correctly, your team is assembled (huh) and you're… almost… ready to begin…

Sunday, March 21, 2010

small packages, part 2

a while back i said that i like small programs that waste neither space nor cpu cycles. from the file on stupid computer tricks comes the extreme case: the smallest possible linux program that actually does something.

the exercise documented in this article (updated for 2009) is purely academic, but it demonstrates some uncommon ingenuity, and i think that's cool. and this recent blog post is moving along the same lines: programming in c with no cumbersome libraries. not really practical for large projects where the standard library accounts for a negligible part of program size and the benefits far outweigh the drawbacks, but still this is an interesting effort. it also caused me to dig out my old assembly language books. i think i'm going to write some tutorials on intel assembler over the next few months. we'll look at making programs for dos and linux.

aww, c'mon! it'll be fun!