OSDev.org

Hi,

When I first learned assembly language programming I started with a book called "The Peter Norton Programmer's Guide to the IBM-PC" (written by Peter Norton and Richard Wilton), then later on bought another book called "Advanced Assembly Language" (written by Allen L. Wyatt). Mostly I started with DOS utilities, and went from there.

Of course this is before anyone I knew (including me) had internet access (back when 80486DX was "top of the line"), and things have changed a lot since then - these books mostly dealt with real mode (there's a mostly useless mention of protected mode in the "Advanced Assembly Language" book, but no usable details), DOS is almost entirely obsolete, and I'm convinced that there's better material online for learning assembly language for free (and that's buying books isn't necessary).

So, what I want to do is create a list of suggestions for people that want to learn assembly language programming, and then add this list of suggestions to the wiki. That way when beginners come to the forums we can politely give them a useful link to this information in the wiki.

The Intel (and AMD) programming manuals would be at the top of the list. What other good suggestions are there?


Thanks,

Brendan

There's no teachings without practice

I personally favor a DOS environment and writing .com files (I learnt in win9x, but dosbox should work too)

Hi,

Combuster wrote:There's no teachings without practice

I personally favor a DOS environment and writing .com files (I learnt in win9x, but dosbox should work too)

I did my fair share of DOS *.com files too, but DOS programs don't play nicely with modern OSs - the last OS that supported DOS programs directly was "Windows Me" (almost a decade old now), and if you're going to mess about running DOS (or FreeDOS) in an emulator (including the dodgy/minimal DOS emulator built into Windows XP) then it's much more tempting to forget DOS and go the "bare metal" route.

Let me put it this way - how long has it been since you've written a DOS program? For me, I wrote a simple 3D renderer (solid polygons without textures drawn onto a "320 * 200 * 256 colour" video mode; mostly as an excuse to get practice with FPU instructions) about 9 years ago.

Now that DOS (and DOS programs) are virtually dead; I'd actually be tempted to say that (especially for people interested in OS development) writing your own boot code (and testing/debugging in something like Bochs) is one of the best ways to learn assembly language. I know this is exactly what I'd do if I had to learn assembly language in 2009 (and it's what I will do if/when I want to learn assembly language for a different CPU).

Of course I'd also recommend learning a high level language first, but a lot of beginners have already done that and are ready for the next step.


Cheers,

Brendan

Hello,

FASM Programmer's Manual really helped me to learn Assembly language.

You should also take a look at this unfinished, but good tutorial.


Best regards,
-- Andrew

The e-book Art of Assembly is amazing. It's a little dated, especially the 16-bit DOS edition, but the 32-bit editions are just wonderful. They come in both PDF and HTML formats.

@Troy Martin: lmgtfy link FTW LOL!!!!

I've personally read this tutorial http://www.geocities.com/siliconvalley/ ... les00.html
and then several other random ones from across the internet, including this one: http://www.skynet.ie/~darkstar/assembler/

Although I really have read better ones by far, but I really can't remember the juicy ones right now.

Brendan wrote:Hi,

Combuster wrote:There's no teachings without practice

I personally favor a DOS environment and writing .com files (I learnt in win9x, but dosbox should work too)

I did my fair share of DOS *.com files too, but DOS programs don't play nicely with modern OSs - the last OS that supported DOS programs directly was "Windows Me" (almost a decade old now), and if you're going to mess about running DOS (or FreeDOS) in an emulator (including the dodgy/minimal DOS emulator built into Windows XP) then it's much more tempting to forget DOS and go the "bare metal" route.

That's why I always say that it's illogical for somebody to think about advancing in an OS without having spare machines (they don't have to be old, they can be newly acquired for that specific purpose). I see that it's necessary to be able and having permission to remove the casing and disassemble that testbed machine as much as needed, and try several different peripherals and configurations.

You are of course right about the incompatibility with DOS/WinXP+. But there are things you can do with it if you put it in a bootable media. You can make a lot of snippets to inspect the most microscopic bits of hardware behavior without rebooting or having to make 1001 unusable kernels, but just make a small COM file that does nothing more than watching a single thing until really understanding it. Then when that little piece is working, debugged and watched carefuly to see if everything is OK in RAM even if it works OK (i.e., all code could be reading and writing structures at the same place but with the problem that that wasn't the intended place), it should be integrated in the kernel.

You can even make a set of miniprograms to "talk" about something with the machine and it shows you the results step by step, and so you can see what's really going on without re-writing code but only using different combinations of the different parts of an algorithm, all of them communicating through the state of variables at some high memory area that stays even when each of them terminates their 4 or 5-line task (maybe using Unreal Mode/A20 with care).

It's frustrating for anyone building a system several times from scratch, when a BIOS-like operating system like DOS could used as a testbed for the single "gears", instead of having to debug a new feature in a huge program.

Brendan wrote:Let me put it this way - how long has it been since you've written a DOS program? For me, I wrote a simple 3D renderer (solid polygons without textures drawn onto a "320 * 200 * 256 colour" video mode; mostly as an excuse to get practice with FPU instructions) about 9 years ago.

I'm always in need of writing snippets under it. I DO NOT use DOS interrupts other than INT 21h and INT 20h. I made a very simple "file cutter" program 5 years ago in Turbo C++ 1.0 to split a file in several equally-sized pieces. It had an extremely basic graphical interface and a mouse pointer to click the icons, which could not move or react but were an actions menu to clicks. It was interesting using BGI graphics drivers and using registers through regs.x.ax, etc., which eventually brought more curiosity about assembly language.

Brendan wrote:Now that DOS (and DOS programs) are virtually dead; I'd actually be tempted to say that (especially for people interested in OS development) writing your own boot code (and testing/debugging in something like Bochs) is one of the best ways to learn assembly language. I know this is exactly what I'd do if I had to learn assembly language in 2009 (and it's what I will do if/when I want to learn assembly language for a different CPU).

Yes, but I also see that it's necessary to have Bochs for being able to easily inspect memory and other things, and once everything seems right and in the correct place in RAM, then it's time to test it in several real machines to see if it really keeps working well across "standard" hardware built by different manufacturers.

I don't think DOS is dead for the low level x86 developers, if they wish to use it. You can use BIOS INT 19h if you want to warm-reboot the computer without going to POST again from DOS and cause the boot process (booting from a device) to start.

Brendan wrote:Of course I'd also recommend learning a high level language first, but a lot of beginners have already done that and are ready for the next step.

Very true also, but for that who is curious, there should always be people around to encourage to learn more and more about hardware and assembly, even if those people don't personally know about those topics. Otherwise the person who is willing to learn might never actually take it into real consideration and forget it in some time.

Well it's a bit dated and might not be in print anymore, but I found The 80386 Book to be a great way to actually understand the basics of the x86 architecture and assembly language structure in a way that wasn't too DOS centric.

Sadly I lost my copy after the water heater in our basement busted and damaged it. I've even considered buying another copy as a quick reference over the Intel SDM. It won't cover newer instructions or operating modes, but it's gold for real mode and what most beginners will have to deal with and also offers some good reference on the architecture as a whole.

I know this one doesn't sound very useful, but it's the truth for learning x86 real mode assembly:

MS-DOS DEBUG.EXE.

I like using it for viewing the different 16-bit DOS stubs that different linkers throw into the final executable.

Although I absolutely hate the emu8086 code and its emulator in all of its vastness of missing features, they did a freaking awesome job writing a quick "lets make a freaking hello world" tutorial set..

I'm pretty sure they took the help off of their website, so I host it here http://earlz.biz.tm/old_site/emu8086_help

You have to be smart enough to convert from archaic emu8086 syntax to yasm though...

also, http://www.ousob.com/norton.php and then "x86 reference" has an amazing instruction set reference, complete with cycle counts, opcode numbers, and flags affected. Basically a condensed version of chapter 2 of the Intel Manuals(and more easy to search through)

Brendan wrote:DOS is almost entirely obsolete, and I'm convinced that there's better material online for learning assembly language for free (and that's buying books isn't necessary).

Yes it is, if it is looked from the point of view of using DOS interrupts. That's not the goal.

That's why COM files should be used. In that way you will have an almost bare-metal environment and you should be on your own while the main code of your test is running.

The intention is to use DOS to boot a machine and have a 16-bit unrestricted console to make use of other code and BIOS functions that let you run some test programs. If a test program is so bad that crashes in DOS for any reason, then it would not be any better to try to include it right away into the production code.
======================================
Now, I have some websites. Some of them might be offline but most shouldn't:

Programmers Heaven - Assembler programming zone
http://www.programmersheaven.com/tags/Assembly/Files/

OSRC: Protected Mode:
http://nondot.org/~sabre/os/articles/ProtectedMode

Art of Assembly Language Programming and HLA by Randall Hyde
http://homepage.mac.com/randyhyde/webst ... index.html



Cached:
----------

Intel Instruction Set
http://web.archive.org/web/*/http://www ... ros/intel/

NASM Manual
http://web.archive.org/web/*/home.attbi ... mdoc0.html



Offline:
--------------

MASM Programmer's Reference
http://webster.cs.ucr.edu/Page_Techdocs/MASMDoc



Also, if you can get the text-mode disassembler/hex editor program called HIEW (for DOS) or HIEW32 (for Windows). At least it has helped me a lot and makes things simpler in DOS/Windows. You can't expect to familiarize inspecting binary-mode files and x86 object code if you don't have a program at least as good and simple as this.

Hi,

I think my views on this may be slightly unconventional due to my background. I started programming on my BBC Model B (no 'rich boy' comments, please!). I graduated to QBasic on our 286 Apricot and moved to VB 1 (for DOS - nice ANSI-character boxes) and up through the VB versions (and Windows OSes) to VB5.0. I then made the move to VB.NET despite the advice at the time from several sources being "stick with VB6".

During my time with VB, I occasionally longed for something closer to the metal, and dabbled with the Art of Assembly (already mentioned in this thread) and the HLA system. Because I was used to having a heap of runtime libraries behind me, I just couldn't get my head around ASM.

Then, I discovered this page and MegaTokyo (although I wasn't an active forum member back then). Working with the sample boot loaders (see previous link) gave me the inspiration I needed to realise that assembly is actually very easy. Time consuming, but easy

This means that, against current convention (but as per Brendan's post above), I would advise that anyone wanting to learn assembly language starts with a boot loader. I think that running in such an uncluttered environment with only the BIOS to help you removes all sources of confusion ("is this a feature of assembly, or is it a macro built in to MASM / HLA?").

This has led to a couple of beliefs that may be apparrent in my posts: 1. I think that you can start OSDev with no previous low level programming experience and 2. The best way to learn initially is by practice (later on when learning about optimisation, reading up on the theory becomes much more important).

Cheers,
Adam

Hi,

OK, I've created Learning 80x86 Assembly and added most of the suggestions kindly mentioned here.

Some of the suggestions weren't included, because I decided that there's enough very good information online that people shouldn't really need to purchase (or go to a library and borrow) a "printed on paper" book. Also, I didn't include incomplete/in progress tutorials, as they can be added easily after they're completed.

I should also mention that (except for Intel and AMD programmers reference manuals) I haven't read anything in this list. For most of them I took a quick look and made up some notes. If anyone has actually read them, then I'd appreciate it if you could fix my dodgy notes.

Also, if anyone thinks I've missed something, or if anyone has more suggestions, then it's a wiki - feel free to edit the page...


Huge thanks,

Brendan

Brendan wrote:because I decided that there's enough very good information online that people shouldn't really need to purchase (or go to a library and borrow) a "printed on paper" book.

I think that best resources for learning to program using some language or some api/framework/whatever are books. I think list of books about 80x86 assembly should be added to that page.

But when I start thinking about this, I really don't know are there any good 80x86 assembly books that are rather new and aren't too much only about MS-DOS. But I /believe/ there are some good books that are useful when programming for modern operating systems in protected or long mode, or when writing modern operating systems.

I would also recommend Art Of Assembly.

However, there are a few graphic glitches in the PDF files for the 32bit book. I took some time to do a few fixes to those pages, so if you're going to read that book you might want to download the fixed PDF's:

Linky to the thread (The second post contains the link to the fixes)

Edit: I still haven't been able to contact the original author. So I'm not sure if it would break any licenses if you would link this to the wiki. It's a free book, and all I've done is fixed a dozen or so images, with everything else intact.