pouët.net

Go to bottom

Tips for x86 assembly-language reference manuals (not Intel manuals)

category: code [glöplog]
 
Hi,

I was wondering if someone knows about any good x86 assembly reference manual or webpage with instruction-references etc from 8086 to 486 and maybe Pentium machines. I dont need those Intel-reference manuals, i think they are too hard to read and I dont need up-to-date internal hardware lines. I use Turbo Assembler for DOS, using DosBox most of the time, and start coding .286 16-bit instruction programs. That is im looking for tips for maybe old books/manual (midst 80 to early 90 or before 99) that cover the basic to advanced level, but easy as reference to look up words that describe interrupt and register-functions for that specific interrupt. Or if there is a good webpage-version thats easy to look up.

Also I have an option to order book online (in paper form) which i prefer, but then I want the best advice for such a easy-to-read, but reference hardcore manual with good describtions.

For eksample that I want to read from keyboard, then I want to know how to easily find a page with interrupt identification and register value paramter descriptions, without googling and searching through massive amounts of other junk online.

Thanks
added on the 2011-08-23 16:03:36 by rudi rudi
Most of what you want is operating-system/hardware specific stuff, not really related to x86 assembly itself. The BIOS interrupts aren't (weren't) really a good way to things back then if you wanted to be efficient and in protected mode they wouldn't work anyway.

For DOS, most of the important stuff you want on interrupts is here: http://www.cs.cmu.edu/~ralf/files.html

(int 21h for DOS-specific stuff, int 10h for switching video modes if you don't want to bang registers directly and if you want to read the keyboard properly, hook up the keyboard interrupt and read from port 60h)
added on the 2011-08-23 16:21:15 by Preacher Preacher
Norton Guide, a tool that can be access in DOS which give you quick and easy access to various information (assembler instructions, BIOS, I/O, DOS INT, ...). http://www.whitetown.com/misc/ng/asm/
added on the 2011-08-23 16:24:27 by F-Cycles F-Cycles
Shit I am old...

But seriously, I understand the appeal of old computers but there's no reason to start learning DOS programming anymore. If you're doing anything more complicated than a 256b intro, the real mode segment:offset addressing is a world of hurt (and won't net you much memory), EMS/XMS were obsolete even back then and for protected mode coding it'd make a lot more sense just to set up a framebuffer in Windows and code on that. Even in assembly if that's what you want to do. If you insist on it though, you can probably download the old PMODE dos extender from somewhere. Then there is the DPMI stuff if you want to get a VESA 2.0 graphics mode and all that...
added on the 2011-08-23 16:26:46 by Preacher Preacher
Here you go without downloading. Interrupt Services for DOS, BIOS, EMS and Mouse:

http://www.htl-steyr.ac.at/~morg/pcinfo/hardware/interrupts/inte1at0.htm
Quote:
Most of what you want is operating-system/hardware specific stuff, not really related to x86 assembly itself.


Preacher:
(to your first post - which is the most usefull one)
yes, you're right. as long as the stuff describes that "this interrupt does that" and these "registers refers to this action", it should be fine.

(second..)
your senseless arguments about not learning DOS, doesn't have anything to do with my question at all. if I wanted to do the same thing on C64, i would have asked for the same thing, only used other words since its a different hardware-system.

windows is not an option for this. i would have asked for message-handling books/references if i wanted that, but i didnt. still senseless..

no about VESA. i dont want to dig into it and i hope i never will. i know that it contains loads of graphic-card compability problems and shit. it is not my intention to go that way.

i don't need much memory. i am doing all this in realmode. it is currently my only option. everything bellow 257 bytes is the a reasonable thing for these kinds of kiddies projects. take a look at what i made about a month ago:
http://www.pouet.net/prod.php?which=57317
i have made this 21b intro in assembler which have beaten all other shortest noise intros. give me the name of one that is shorter and has sound! ok?. maybe one could make it shorter on a C64, but its not my goal of figuring that out now.
anyway im looking for finding some other tiny-project to do, but really wanted to find some reference manual to get some kind of overview of the structures before doing that.

But,.. thanks for the links everyone.
added on the 2011-08-23 18:25:54 by rudi rudi
Congratulations for making a 21b intro that is quite undoubtedly the best <32b thing that fills 0a000h with garbage.

Some quick advice: if you're coding <256b intros, all you need from the interrupt services is int 10h to switch to mode 13h. There's absolutely nothing else there that's useful: for keyboard input there's port 60h, for audio there's the general midi port you can stuff your midi events in (330h IIRC) and for memory allocation you can just take what you need without going through the sucky DOS memory allocation stuff. Well, you might theoretically want to load files in which case int 21h comes in handy. And you can save a few bytes by returning from the .com with a ret call instead of mov ax, 4c00h int 21h, if you intend to return to the prompt properly.

Btw, use NASM. It's by far the better assembler. I used the Borland TASM for years and while I have fond memories of it, it's pretty shit when compared to something more modern.
added on the 2011-08-23 19:04:48 by Preacher Preacher
Preacher: thanks.
well, if you had disassembled the 21b intro i just posted you'd seen that i used 'ret' instead of those instructions. actually, the reason for figuring out keyboard handling is if i some time decide to code some small game. also having some reference can come in handy for other stuff as well.
added on the 2011-08-23 20:10:14 by rudi rudi
fasm manual had a pretty good instruction set overview
added on the 2011-08-24 00:04:59 by ponce ponce
First of all, besides what already has been linked, I'd say give Agner Fog's assembly optimizing manual (http://www.agner.org) a peek. For what you're doing right now you can probably skip 80% of it but it holds some universal truths. It also teaches that when you go beyond the very basics like cache-friendliness and preventing AGI-stalls, you might some day actually be counterproductive towards the CPUs own out-of-order execution mechanisms and other instruction pipelining/reordering strategies.

And start spitting through simple sourcecode: old intros, stuff like that! Hornet! :)

That said, a few things here are wrong: BIOS interrupts work just fine in protected mode, you just have to make a callback to RM :) Most basic interrupts are already supported (i.e. PM interrupt vectors set) by a good DPMI handler; if not, there's examples on how to do it (the gist is returning to real mode for the actual interrupt and converting registers/parameters and memory addresses correctly in the process). That does however not mean that, and I guess that is what Preacher meant, it is a good idea to use most interrupts in any sort of halfway performance-critical code (e.g. loops). Also, VBE (through which one works with VESA video modes) is a real-time 10h-based interrupt interface which works with segmented and physical memory. If anything it's more tedious to operate it from a protected mode program (hence all those buggy VESA extenders in the day, which handled exactly that) -- with the big exception that protected mode programs have access to ample memory and performance that's favorable :)

I think it's a good idea to check this stuff out. If anything it'll teach you a thing or two that can be useful in future performance or system programming *and* starting with 16-bit DOS is not too much fuzz to start with, allowing you to get some results before you get bored (very important). Though when the time comes you start to think about writing VBE-enabled protected mode programs: switch back to a modern platform and perhaps sharpen your skills there by hand-optimizing functions and analyzing compiler output, stuff like that. Knowing your way around VBE and protected mode is something that will hardly see any use in the future, if at all.
added on the 2011-08-24 08:45:01 by superplek superplek
Yeah, interrupts work if you patch them through real mode but that's not exactly fun to do and probably not for someone who just wants to learn a bit of basic x86 assembly. That's what I meant by interrupts not working. I maybe should've said that they don't work out of the box, or without extra work :) And in any case, for intro coding they're useless.

I toyed around with my own dos extender back in 1998 or something... getting DPMI to work correctly was a lot of pain, I never managed to get it all done properly and I left it at that. There's really no reason to go through all that, especially with Tran's extender being around.
added on the 2011-08-24 09:11:03 by Preacher Preacher
I was heavily interested in all this stuff back in the day, but nowadays even *I* have moved to high level.
Preacher: could you please explain what you mean by "patch them through real mode"?
i mostly used dos32, but in retrospect that was a bit stupid since it wasnt any better than pmode/w, if it wasnt miles worse :)

i would advise against focussing on making "small" intros rightaway, that actually takes quite some insight.

hmm.. when i think back of those asm dos days it's not so much the stuff i wrote in pm/vbe that sparks nostalgia. it's the adlib+mode13 (bbs)intros :) and that boxy 386sx25 my grandma had which i used during the summer.
added on the 2011-08-24 09:18:40 by superplek superplek
http://courses.engr.illinois.edu/ece390/books/labmanual/realprot-diff-interrupts.html
added on the 2011-08-24 09:20:02 by superplek superplek
bitnaughty: plek's working link. Basically you need to switch back to real mode to actually call the DOS interrupt and then return to protected mode and while doing that, make sure that your memory mapping between these two works correctly. That link explians how the process actually works from the point of the caller.
added on the 2011-08-24 09:55:07 by Preacher Preacher

login

Go to top